Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - markand

Pages: [1]
1
Feature requests / Re: So, I'm moving away from SFML due to Wayland support
« on: November 12, 2019, 05:15:40 pm »
I think the best thing to do here is to implement a secondary wayland backend and conditionally use the appropriate one depending on the environment variables. SDL, GTK do this (probably by checking DISPLAY). Then after some years we could drop X11 backend completely.

I don't know much wayland internals yet to provide support for it though :( SDL could be a good start I think?

That said, X11 must die especially since running X11 apps under wayland sessions is sometimes problematic.

2
SFML development / Re: C++ standards
« on: October 24, 2019, 03:08:08 pm »
My $0.02, I think C++17 is the way to go. SFML 3 is not about to be released anytime soon and we're almost in 2020.

C++17 is even available in Visual Studio, Android and in major distributions. I think there is no good reasons to stick with C++11 or C++14.

Major features that C++17 offers:

  • destructured bindings (utterly convenient to do const auto [x, y] = getPosition())
  • std::variant
  • std::optional
  • std::string_view
  • if / switch initializers

3
SFML development / Re: Removing dependency binaries
« on: October 24, 2019, 03:02:39 pm »
I also vote for the exclusion of the bundled libraries (either in binary or source form). It's not the purpose of SFML to do this on behalf of the SFML user.

Also, it's just to complex to bring because of:

  • different toolchain versions
  • different architectures
  • different compile options
  • and so on

This is the responsability of the user to provide its dependencies, not SFML one. Less code, less build, less problems :-).

Qt did ship bundled libraries as well but they eventually decided to remove in Qt 6.

4
SFML development / Re: sf::NonCopyable and =delete
« on: October 14, 2019, 03:28:30 pm »
IMHO, a parent class for removing/adding functionality in a subclass is not the good way to do. Especially as explained above. Class inheritance means "IS-A" not "HAS"/"HAS NOT".

5
General discussions / Re: Building SFML 2.1 under FreeBSD
« on: October 31, 2013, 06:14:13 pm »
Yes, I already created a port for 2.0 release but it has never been committed. I'll wait until the 2.2 release so we get full FreeBSD support and then I will send a new port again :)

6
General discussions / Re: Building SFML 2.1 under FreeBSD
« on: October 31, 2013, 10:58:07 am »
Hi,

I don't know what you're doing but it really works for me (just git cloned right now and compiled)

I can see in your output that FreeBSD/JoystickImpl.cpp was not built. Do you correctly have the following at src/Window/CMakeLists.txt around line 73 ?

    elseif(SFML_OS_FREEBSD)
        set(PLATFORM_SRC
            ${PLATFORM_SRC}
            ${SRCROOT}/FreeBSD/JoystickImpl.cpp
            ${SRCROOT}/FreeBSD/JoystickImpl.hpp
        )  
    endif()
 

Could you add anywhere in the CMakeLists.txt something like :

message("OS = ${CMAKE_SYSTEM_NAME} and ${SFML_OS_FREEBSD}")
 

And rerun cmake to see the output ?

Pages: [1]