New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't link sfml-main to GUI examples #610

Closed
binary1248 opened this Issue May 23, 2014 · 8 comments

Comments

Projects
None yet
6 participants
@binary1248
Member

binary1248 commented May 23, 2014

Time and again, people post on the SFGUI forum and the SFML forum regarding "stuff that doesn't work" or some corrupted graphics etc. When I ask them if their drivers/system is set up properly, they tend to say "the SFML examples work fine" and assume that everything is good. When I tell them to enable the console they find out that SFML has been spamming them with OpenGL errors and what not but they just didn't have the console enabled to see them. Had they seen those errors when running the examples to begin with, I think they would have fixed what was wrong with their system before assuming that something is wrong with the libraries.

Is it a good idea to make the examples display a console in the background? It would be easier and faster for people to diagnose problems that way before starting their own project with a broken environment.

I initially thought about only enabling the console subsystem for the debug build of the examples but CMake doesn't allow setting WIN32_EXECUTABLE based on build-type in multi-configuration mode and the only workaround has been broken for the last 2 years, see here. So if we went ahead and did this, it is all or nothing.

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila May 23, 2014

Member

OpenGL errors usually are meaningful only for us. "An OpenGL called failed in xxx.cpp line yyy" doesn't mean anything for people who start using SFML.

Moreover, what's the difference between seeing the error in an SFML example, and seeing it in a SFGUI example? Answer: the forum on which they'll complain :p

Member

LaurentGomila commented May 23, 2014

OpenGL errors usually are meaningful only for us. "An OpenGL called failed in xxx.cpp line yyy" doesn't mean anything for people who start using SFML.

Moreover, what's the difference between seeing the error in an SFML example, and seeing it in a SFGUI example? Answer: the forum on which they'll complain :p

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 May 23, 2014

Member

The fact that they even see anything (I think no matter beginner or not, you understand seeing a lot of text spammed on a console is a bad thing 😉) helps them to understand that the example, which was designed to work on all systems, shows that something isn't right with their system. How often have we had to reply to people telling them to update their 5 year old driver to fix some "Failed to share context" message that they didn't initially see because the console was not visible. This would probably be a candidate for the Troubleshooting section on the FAQ, because well... it will be an FAQ when people ask what "Failed to share context" means and how to fix it...

This also doesn't apply just to OpenGL errors. If people go ahead and run the pong example, they will not see OpenAL errors as well and might be inclined to post something on the forum instead of making sure they have a functioning sound card in the first place 😉.

Member

binary1248 commented May 23, 2014

The fact that they even see anything (I think no matter beginner or not, you understand seeing a lot of text spammed on a console is a bad thing 😉) helps them to understand that the example, which was designed to work on all systems, shows that something isn't right with their system. How often have we had to reply to people telling them to update their 5 year old driver to fix some "Failed to share context" message that they didn't initially see because the console was not visible. This would probably be a candidate for the Troubleshooting section on the FAQ, because well... it will be an FAQ when people ask what "Failed to share context" means and how to fix it...

This also doesn't apply just to OpenGL errors. If people go ahead and run the pong example, they will not see OpenAL errors as well and might be inclined to post something on the forum instead of making sure they have a functioning sound card in the first place 😉.

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch May 23, 2014

Member

Is it a good idea to make the examples display a console in the background? It would be easier and faster for people to diagnose problems that way before starting their own project with a broken environment.

Yes, most likely. It's also what I always do for my own programs (debug build with console; release build without).

I think worst case we could just add a #pragma to set the subsystem to console for debug builds, although that would be a rather ugly solution. Plus side, it would always work, even if the demo code is put into a new project from scratch.

Also to note, it'd be very important to see the errors in case of the Shader example - even if you're just toying around with the actual shader code.

Edit: Actually, I think this issue title is misleading. The problem isn't linking with sfml-main (it's just a wrapper for the entry point after all). It's about not having a default console window attached.

Member

MarioLiebisch commented May 23, 2014

Is it a good idea to make the examples display a console in the background? It would be easier and faster for people to diagnose problems that way before starting their own project with a broken environment.

Yes, most likely. It's also what I always do for my own programs (debug build with console; release build without).

I think worst case we could just add a #pragma to set the subsystem to console for debug builds, although that would be a rather ugly solution. Plus side, it would always work, even if the demo code is put into a new project from scratch.

Also to note, it'd be very important to see the errors in case of the Shader example - even if you're just toying around with the actual shader code.

Edit: Actually, I think this issue title is misleading. The problem isn't linking with sfml-main (it's just a wrapper for the entry point after all). It's about not having a default console window attached.

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 May 23, 2014

Member

The #pragma solution only applies to MSVC (not gcc) and I don't like adding linker settings into code since it should be kept separate from it.

Member

binary1248 commented May 23, 2014

The #pragma solution only applies to MSVC (not gcc) and I don't like adding linker settings into code since it should be kept separate from it.

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch May 23, 2014

Member

Hm? For GCC (MinGW) it should be enough to ommit WIN32 when defining the target. At least for me that worked all the time. The only problem is MSVC (since that's the buggy thing).

Edit: Think something like this should work for all the other compilers (untested and from memory):

# create the target
#old: if(THIS_GUI_APP AND WINDOWS)
if(THIS_GUI_APP AND WINDOWS AND NOT ${CMAKE_BUILD_TYPE} STREQUAL "Release")
    add_executable(${target} WIN32 ${THIS_SOURCES})
    target_link_libraries(${target} sfml-main)
else()
    add_executable(${target} ${THIS_SOURCES})
endif()

Edit 2: I'm not sure how this affects Linux. You should typically get your console output if you start your program from a terminal window, right?

Member

MarioLiebisch commented May 23, 2014

Hm? For GCC (MinGW) it should be enough to ommit WIN32 when defining the target. At least for me that worked all the time. The only problem is MSVC (since that's the buggy thing).

Edit: Think something like this should work for all the other compilers (untested and from memory):

# create the target
#old: if(THIS_GUI_APP AND WINDOWS)
if(THIS_GUI_APP AND WINDOWS AND NOT ${CMAKE_BUILD_TYPE} STREQUAL "Release")
    add_executable(${target} WIN32 ${THIS_SOURCES})
    target_link_libraries(${target} sfml-main)
else()
    add_executable(${target} ${THIS_SOURCES})
endif()

Edit 2: I'm not sure how this affects Linux. You should typically get your console output if you start your program from a terminal window, right?

@Bromeon Bromeon added the m:config label Jun 6, 2014

@TankOs

This comment has been minimized.

Show comment
Hide comment
@TankOs

TankOs Jun 9, 2014

Member

I think it wouldn't hurt to show the console in the background. The examples are run by developers (or those who want to become one ;)) anyway, so I guess it's pretty normal to see it there. Better safe than sorry.

👍

Member

TankOs commented Jun 9, 2014

I think it wouldn't hurt to show the console in the background. The examples are run by developers (or those who want to become one ;)) anyway, so I guess it's pretty normal to see it there. Better safe than sorry.

👍

@binary1248 binary1248 added s:undecided and removed s:unassigned labels Jul 13, 2014

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Oct 6, 2014

Member

👍

Member

eXpl0it3r commented Oct 6, 2014

👍

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Mar 26, 2015

Member

Superseded by #766

Member

eXpl0it3r commented Mar 26, 2015

Superseded by #766

@eXpl0it3r eXpl0it3r closed this Mar 26, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment