Author Topic: Menus and dialog boxes (Read 25898 times)

Laurent · « **Reply #15 on:** April 30, 2010, 01:05:22 pm »

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.

tester · « **Reply #16 on:** April 30, 2010, 01:06:56 pm »

You mean I shall have two windows next to each other?

Laurent · « **Reply #17 on:** April 30, 2010, 01:18:09 pm »

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.

Meteorhead · « **Reply #18 on:** February 22, 2012, 09:29:01 am »

Quote from: "Laurent"

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).

Laurent · « **Reply #19 on:** February 22, 2012, 10:30:42 am »

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.

Meteorhead · « **Reply #20 on:** February 22, 2012, 11:56:54 am »

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.

Laurent · « **Reply #21 on:** February 22, 2012, 12:09:58 pm »

Quote

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.

Meteorhead · « **Reply #22 on:** February 22, 2012, 01:02:55 pm »

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.

Laurent · « **Reply #23 on:** February 22, 2012, 01:15:10 pm »

I think that Qt could be a good solution for you.

I just don't know if it's able to do that:

Quote

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

zenroth · « **Reply #24 on:** February 23, 2012, 04:40:29 am »

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.)

chafporte · « **Reply #25 on:** March 05, 2016, 06:45:29 pm »

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.