Message Boxes / Alerts

[xerzi]

Saw this was suggested before, would like it to be reconsidered that it is "not in the scope of the project". I require a cross platform way to commute an error to the user when it occurs. There are numerous errors which can occur before the resources to draw text to a window are available, so using a sfml window with OpenGL to display this message simply won't do. I really would rather not have to include a library like Qt or wxWidgets simply for this purpose. The support can be minimal, no icons or configurable buttons, etc.

[Xornand]

I agree that something like a message box would be useful. However, even if it was included in SFML by default, you'd probably still need to link to additional dependencies (either by yourself or implicitly by including SFML).

On the other hand, a message box is something that you usually write only once and then re-use in projects. A simple message box is literally just a couple of lines of code and some preprocessor definitions to make it portable across different platforms.

[Hapax]

I have to admit, message boxes seem to look out of place in a primarily SFML project. I think it's because almost all of SFML's feedback is visual and within the window's boundary, and also nothing to do with OS.
Errors can be reported using graphical objects but, as you already said, errors can fail before these are created. In this case, errors can be output to the error stream but, if you don't have a console window up, it's not likely to do any good (though that could be an error-logging file, for example).
Hmm. What to do then? Yeah, I guess, if it fails at this point, message boxes/alerts/general OS interaction should be used. However, I don't think SFML should, or will, cater for this (at least not until 3.0) in the same way that it doesn't do menus or file system access, for example.

[Laurent]

The only resource needed to display an error message in the window is a font. I don't think it's too hard to ensure that the font file is correctly packaged with your application -- you can even embed it into the source code if you're paranoid.

[xerzi]

I don't use sfml-graphics, i use my own font system which has the font embedded into a larger resource. There could also be issues with creating an OpenGL context, or one of the required functions needed to draw the font aren't supported. They could have not properly copied the files over, so the font doesn't load (permissions, simplify missing a folder, etc...). The bottom line, using OpenGL (sfml) as a window to report an error simply doesn't encompass all possible cases, when there is a solution that does, why not support it?

Embedding it into the source code isn't possible with my implementation. At the very least it would require a bunch of new code to be written to support that kind of loading. This solution also doesn't cover the case in which the window fails to create or required features to draw the font aren't supported.

[Laurent]

Well, I don't know about your own implementation, but with SFML the only thing that can report an error (!= can fail) is the font loading, and this can easily be prevented. So even if your code can fail at several places before being able to draw text in the window, you still have the solution to open a popup SFML window and display your error with sf::Font and sf::Text. Unless you really don't want to depend on sfml-graphics at all, of course.

The only other solution is probably the message box, yes (log files are not very user friendly). I still think that this feature is out of the scope of SFML, but this is just my personal opinion. The discussion is still open

And by the way, if I remember correctly (too lazy to check again), Xlib doesn't even provide standard messages boxes. So the implementation of such a feature could be far more complicated than it seems.

[xerzi]

Well, I don't know about your own implementation, but with SFML the only thing that can report an error (!= can fail) is the font loading, and this can easily be prevented. So even if your code can fail at several places before being able to draw text in the window, you still have the solution to open a popup SFML window and display your error with sf::Font and sf::Text. Unless you really don't want to depend on sfml-graphics at all, of course.

Not just my code, SFML as well. I've run on a system that had bad drivers, in which an OpenGL context couldn't be created. So unless you can draw your sf::Font and sf::Text without a window, then there is more than just the font loading, which tbh your solution of embedding a font into your source or program is a really really bad solution. To be portable that essentially means having a file somewhere that has an array containing the binary information of the font.

And by the way, if I remember correctly (too lazy to check again), Xlib doesn't even provide standard messages boxes. So the implementation of such a feature could be far more complicated than it seems.

Which is why having it in a cross platform library, such as sfml, would make it useful. Oh well, off to C naming conventions with SDL.

[binary1248]

I really never understood what the hype around having support for message boxes was all about.

Yes, I admit that when context creation fails, there isn't much left you can do to convey some useful information to the user. But what would this information contain? SFML context creation already dumps a bit more verbose output as to where it failed directly to the console, so if it is hidden, you will never find out exactly what went wrong. All I can imagine that is said in such a message box is: "Something went wrong. Check the console for more information.". Since it would make sense to check the console after getting shown a message like this, why wouldn't it make sense to just use the console as the standard method of outputting errors all the time?

Message boxes are really only mandatory on Windows, since it has a standard window manager and the UI is the primary environment in which you execute programs and receive feedback about why they fail to initialize properly. The console on Windows is something that is left for debugging at most. Some Windows users might not even know that there still is a command prompt that they can run.

If you compare that to the "standard" way of doing things on UNIX (Linux, BSD, etc.) systems, they are not even similar. Anybody who can call themselves somewhat familiar with any of these UNIX systems will automatically check the console for information when something goes wrong. It is simply convention on those systems. In fact, I can bet with you that they will find it awkward, and maybe even annoying to see small windows popping up in their face time and again when something unexpected happens.

Also, don't forget that it isn't even mandatory to have a window manager running on a UNIX system at all. I've even tried this out of interest, and gotten a fullscreen OpenGL application running straight from the console without any desktop environment active.

If, and this is a really big if, SFML would support a standard way of conveying fatal error messages, it would be via message boxes on Windows and the standard error stream on all other systems. It just follows from what is already considered convention, and SFML doesn't like to fight against that. Since this is more or less trivial to implement in your own code with not too much use of the preprocessor (Windows knows it has to make it easy to use its MessageBox API for obvious reasons), wouldn't this be something that you could write in a utility file somewhere and reuse whenever you need to?

[Laurent]

Not just my code, SFML as well. I've run on a system that had bad drivers, in which an OpenGL context couldn't be created.

Remember, I said "report errors", not "fail". Context creation may fail on broken systems, but with SFML your program will never know. So how would you detect such an error, and what would you show in your message box?