SFML community forums
Help => Window => Topic started by: tester on April 28, 2010, 09:57:07 am
-
Is there any way to add a menu to an SFML window? And is it possible to show dialog boxes with control elements on them? If no, is it possible to get the platform dependent data for the window (in Windows: HWND)?
-
No, no and no. Sorry :wink:
-
Why not? How shall I create my menus now?
-
Have a look to GUIs (http://www.sfml-dev.org/forum/viewtopic.php?t=2518) ;)
-
Why not?
Because developping a GUI library involves a huge effort. Currently, there are more important, multimedia-related basic features to implement in SFML 2.
-
Because developping a GUI library involves a huge effort. Currently, there are more important, multimedia-related basic features to implement in SFML 2.
Well, I can of course understand why SFML doen't support it directly. But there should be at least a function to get the platform-dependent data of a window. Something like:class Window
{
#ifdef WIN32
HWND GetHwnd();
#elif defined UNIX
UnixSomething1 GetThisStuff();
UnixSomething2 GetThatStuff();
#elif ...
...
#endif
};In this case, even if certain functions are not supported, the programmer can still use them by working with the native frameworks of their operation system.
-
Because developping a GUI library involves a huge effort. Currently, there are more important, multimedia-related basic features to implement in SFML 2.
Well, I can of course understand why SFML doen't support it directly. But there should be at least a function to get the platform-dependent data of a window. Something like:class Window
{
#ifdef WIN32
HWND GetHwnd();
#elif defined UNIX
UnixSomething1 GetThisStuff();
UnixSomething2 GetThatStuff();
#elif ...
...
#endif
};In this case, even if certain functions are not supported, the programmer can still use them by working with the native frameworks of their operation system.
I agree, but this also makes the API a bit more complicated. Let's read Laurent reply.
-
The problem is that your app is no loosing compatibility... Why use SFML therefore ?
What do you want to do exactly ?
Can't you use an existent GUI ?
EDIT : What about Qt or wxWidget ?
-
I agree, but this also makes the API a bit more complicated. Let's read Laurent reply.
It's a very simple function to write. It doesn't exist for design reasons, not technical ones.
The problem is that your app is no loosing compatibility... Why use SFML therefore ?
Not everybody wants to write cross-platform programs ;)
-
Not everybody wants to write cross-platform programs ;)
Gasp ! :shock:
-
The problem is that your app is no loosing compatibility... Why use SFML therefore ?
What do you want to do exactly ?
Can't you use an existent GUI ?
EDIT : What about Qt or wxWidget ?
Well, I do want to write a game, yes. A GUI is not the primary goal, so Qt or wxWidgets are not necessary. It's just that Windows users don't want to enter command line parameters to configure the game options. That's why I would add a native menu and some modal dialog boxes to the Windows version. The game would still be platform independent since I'd enclose every Windows-specific stuff with #ifdef WIN32. And it would still behave identical on every operation system, only that the Windows users have a menu above the window and Linux users don't and need to use command line parameters to change options.
That's similar to the NES emulator FCE Ultra: Compile it as a native Windows and DirectX version and you get a typical Windows interface with a menu and dialog boxes. Compile it as the SDL version and, in Windows and Linux alike, you only have that crappy standard window and you have to enter the options at the command line. Everything from the same source package and with the same configure script.
But it's o.k. I found out a way to do the menu anyway: I'll just use EnumWindows, GetWindowThreadProcessId and GetCurrentProcessId. That will give me the application window as a HWND.
-
And what about a menu inside the SFML window ?
With one of the multipe existing GUIs projects ?
With this solution, the menu will be inside the window, but all the app will be the same on each platform and need only one project and no specific platform things...
-
In this case you wouldn't have the correct look-and-feel. If I intended to use a GUI inside the game area, I would program my own stuff anyway. After all, it won't be much: Keyboard input, screen resolution etc.
-
As you wish, and good luck ;)
-
O.k., I did the menu now, but then I remembered that I somehow have to catch the events. That's why here's my next question: Does SFML provide anything like that?
SDL_EventState(SDL_SYSWMEVENT, SDL_ENABLE);
switch (event.type)
{
case SDL_SYSWMEVENT:
switch (event.syswm.msg->msg)
{
case WM_COMMAND:
if (LOWORD(event.syswm.msg->wParam) == ID_MENU_ITEM)
{
// ...
}
break;
}
break;
}
-
No. Like I said, SFML currently provides no entry point for going deeper into the OS-specific stuff. So you won't be able to handle Win32 events from your SFML event loop.
Why don't you add your configuration dialog as a separate window? This way you won't have to mix SFML and Win32 code.
-
You mean I shall have two windows next to each other?
-
The main window and a dialog box. That's what Ogre does for example.
If you really want an in-game GUI, then you should use one of the OpenGL/SFML based GUIs available, not Win32.
-
No. Like I said, SFML currently provides no entry point for going deeper into the OS-specific stuff. So you won't be able to handle Win32 events from your SFML event loop.
Why don't you add your configuration dialog as a separate window? This way you won't have to mix SFML and Win32 code.
That is quite disappointing. Right now I'm ahead of building a codebase for scientific visualization, where I want to use GPGPU and render in hacky ways. GLUT and the likes hide the low level stuff and are too loser-friendly to use. (Plus MainDisplayLoop is a pain)
I was happy to find SFML, as that is thin enough to access the stuff I need and is native on every OS. However, I'd hate to have config files and seperate windows for that matter.
I was happy to see that wxWidgets has menus as well, but that seems utterly hacky (main function implemented by a macro??). I know it is nothing to fear, but come on... it's 2012 and C++. SFML seems just right in code, but menus are missing badly.
I would decide on learning SFML and stick with config files for the moment, if there would be promise of som sort, that "yes, there are more important isses first, but we'll get to making menus eventually". It's really nothing much people would expect: drop down menus, tick-boxes, text boxes for input-output. I know this is great effort, but it would add serious versatility.
Laurant? Is there really no intention to add menus ever? If not, than I will have to stick with wxWidgets (ugly) or Qt (difficult and serious overkill).
-
It's not about menus, it's about whether SFML is a GUI library or not. And it's not.
But SFML 2 gives access to the native window handle, so you can add whatever is not supported by SFML without modifying it.
Would it help if SFML gave access to the native window events, in a similar way as SDL does (see last post in previous page)? This is something that can be considered.
-
Since I consider myself a cross-platform patriot, and I always write all my applications, so that they compile on both Win7 and linux (I don't have OSX to test) getting handles does not seem like a solution to me.
If I were to create a GUI with SFML at it's base, I would have to create classes that are derived from both SFML and some GUI toolkit. There is an example of this with wxWidgets. The only thing I don't understand in this case, is that how can events spawned on GUI elements created by wxWidgets be handled in an SFML application. Or since wxWidgets requires it's main to be impleted with a macro, how will both applications handle events of their own? Can they be cast to one another? Or should I use function pointers to bridge events caught with one API to call functions of the other?
If not both APIs used support constructing Events from native OS handle, there is not much use to it.
I have found Fox-toolkit as an alternative, however it is incredibly poor when it comes to docuementation or tutorials. Fox seems a little more C++, or at least cleaner, however I have read many bad things about it (intentional and irrational avoidance of STL for eg.) that kinda keep me hesitating.
Can you tell me how such a migrated application would work? (In just a few sentances) If you believe I'm better off using a GUI toolkit natively rather than fusing two, I'm completely fine with that. I'm just looking for a decent tool that does not have an initial cost of 2 months learning time. I don't beilieve that's really viable (or neccessary) for the complexity that I'm looking for.
-
The only thing I don't understand in this case, is that how can events spawned on GUI elements created by wxWidgets be handled in an SFML application
SFML intercepts the events of the window, but still let them be processed by wxWidgets. So both libraries process them and make them available to you, and in the end you can handle them with whichever library you prefer.
Since SFML doesn't support the features that you need, you will have to use another library anyway. What are you planning to do with SFML? Create an OpenGL context? Draw 2D graphics? Maybe you can just use Qt/wxWidgets, they can do OpenGL and 2D too.
-
What I would like to do is create a window with proper menus that let me set options for various simulation/plotting parameters, create OpenGL context and draw to it.
What I would need, is some way of parsing display devices that are available to OpenCL-OpenGL inteop (not all devices found by the OS are capable), and then create a window and draw to contexts with various devices. For this I need to parse devices at OS level and ask for interoperability (there is no library that will do this for me, so I need to implement it no matter what) and once I found some devices, I need to open windows to them (meaning that the library I use must be able to accept OS-specific handles in their constructors and not open something on the default device, like GLUT).
If the application gives some neat form of file handling or anything else is a plus, but not mandatory. I need inputhandling, eventhandling, window management, menus and OpenGL canvas with designated context coming from outside the lib, and all of this in an OS-independant manner.
-
I think that Qt could be a good solution for you.
I just don't know if it's able to do that:
the library I use must be able to accept OS-specific handles in their constructors and not open something on the default device, like GLUT
-
Just wanted to say thanks for making it easy to get a window handle now with SFML 2. I had to use this earlier, in order to do a ShellExecute to do something as simple as open a web browser under windows. (ifdefs and so forth for other platforms of course.)
Not sure how I would of done this cleanly without a windows handle, unless the network library handles this. (which I admittedly totally forgot existed until I started typing this reply.)
-
As a GUI complement, tiny file dialogs offers several function calls. It's a single C C++ cross-platform file to add to your project. It has no init and no main loop.