Native Menus

[Jarvik7]

I am trying to implement native Win32 menus in my app.
I am able to display and interact with the menus:

auto hMenu = CreateMenu();
auto hSubMenu = CreatePopupMenu();
#define ID_FILE_EXIT 9001
AppendMenu(hSubMenu, MF_STRING, ID_FILE_EXIT, "E&xit");
AppendMenu(hMenu, MF_STRING | MF_POPUP, (UINT)hSubMenu, "&File");
SetMenu(window.getSystemHandle(), hMenu);

and also able to directly receive window messages:

MSG message;
while(PeekMessage(&message, NULL, WM_COMMAND, WM_COMMAND, PM_REMOVE)) {
    //do_stuff();
}

but I never receive any WM_COMMAND messages that the menus should be sending out. (if I change both the WM_COMMAND in the PeekMessage call to 0, I get mouse etc events, but asking for only WM_COMMAND gives me nothing)

I am not very experienced with the Win32 api, so I am not sure if I am using the wrong method for WM_COMMAND messages, or if somehow SFML is eating the message before I can see it. I am doing the PeekMessage stuff before my SFML event handler, if that matters.

[Laurent]

SFML removes the messages that it processes, so I guess that you will miss the ones generated between your PeekMessage and SFML's pollEvent.

This is not a robust way of adding native menus to a SFML window. You should rather create a native window and wrap it in a SFML window, so that you have full control over it, including event handling.

[Jarvik7]

Thank you for the reply.
I am trying to keep my app as cross-platform as possible while still providing a native look (Win32 & OSX, with #ifdef to choose the menu coding), so I think going full-blown Win32 api might be too messy.

Are there any plans to allow the user to handle events that SFML itself doesn't (such as WM_COMMAND)? For example, by adding another EventType enum that just passes through the event number (ex: 0x0111 for WM_COMMAND) and the wparam/lparam when SFML doesn't know it. It would probably be useful for many situations aside from just menuing.

When I was searching for answers to my problem I noticed that you have said on several occasions that SFML is not a GUI API, but that doesn't seem to contradict exposing some functionality so the user can do it themselves.

[Jesper Juhl]

If you want to be cross platform but provide a native look, then the obvious solution (to me at least) is to use QT.

[Jarvik7]

As a simple test I made a modification to WindowImplWin32.cpp that gets menus working 90% 100%:

in WindowImplWin32::processEvent() at the end of the big switch:

case WM_COMMAND :
        if (HIWORD(wParam)!=0) break; // Only handle menu sources
        Event event;
        event.type = Event::MenuitemSelected;
        event.menuAction.identifier = LOWORD(wParam);
        pushEvent(event);
        break;

Along with creating the obvious structures in event.hpp. Now I can use SFML's event handler to handle menu events. I've only tried handling the menubar though, no dialog boxes and whatever else. That is enough for my current project.

The reason I say 90% and not 100% is that my app now hangs on exit. I'm guessing it's something related to it somehow skipping SFML's handling of quit messages, but I don't understand how. (My window closes and the console stays behind, followed by Windows saying the app has hung)

-edit-
Actually, it turned out to be a problem with the SVN (it hangs on exit even with a virgin copy of the source, compiled with MSVC2010).
I applied my same modifications to the 2.1 release source and it works 100% fine now.

[Laurent]

Are there any plans to allow the user to handle events that SFML itself doesn't (such as WM_COMMAND)? For example, by adding another EventType enum that just passes through the event number (ex: 0x0111 for WM_COMMAND) and the wparam/lparam when SFML doesn't know it. It would probably be useful for many situations aside from just menuing.

I'm still not decided about this feature, but it there's no strong argument against it, it could be added in the future.

[Jarvik7]

Although you've said in the past that you don't consider SFML to be a gui api, would you be open to enabling basic cross-platform menu handling? Basic OSX menus were added in a recent commit, so the next logical step would be exposing it in the API.

I do agree that creating "in-game" menus like SFGUI etc do is far beyond the scope of SFML, but native gui would fit in well I think. Creating windows with controls etc may also beyond the scope in that it requires defining layouts, but basic menuing would be quite easy to do.

I've already thrown together such an API myself and modified SFML to do the events through its handler, but it would be nice if it was in mainstream (and cross-platform).

[Nexus]

When you add native menus, why not add native buttons, checkboxes, dropdown lists?

[Jesper Juhl]

When you add native menus, why not add native buttons, checkboxes, dropdown lists?

Are you not basically just reimplementing large parts of libraries like QT, gtk, WxWidgets etc at that point?
In my humble oppinion, this is outside the scope of SFML.

[Nexus]

The question was rhetoric

That's exactly the point I wanted to make: menus are an arbitrary GUI component. I don't see why exactly they, but not other components, should be implemented. They're more complex than one might initially think, especially if the native OS APIs are used. And whether SFML is becoming a GUI library is out of question...

[Laurent]

menus are an arbitrary GUI component

Not exactly. You wouldn't be able to put a checkbox and a sf::Sprite in your window. The window's contents are totally controlled by SFML (OpenGL). The menu is different, it is outside the window area it could be added without interfering with the SFML drawings.

But yes... other than that, I totally agree that it's outside SFML scope

[Jarvik7]

If menuing isn't to be added to SFML (which I can understand, though I see menus as part of the window creation), the support for user handling of events not used by SFML is a must I think. As-is, SFML blocking things like WM_COMMAND from the user actually makes the API lesssimple by requiring the user to re-implement gui from the ground up (instead of using native api), or forcing them to abandon SFML as their core framework and just use it as another lib in addition to qt/wxwidgets/etc.

In any case, for now I will use my 'fork' with the additional menuaction event type.

[MadMartin]

SFML is a libray for multimedia/game development. For these cases it is unusual to use the native GUI API delivered by the OS. Since almost every game uses its own GUI -- often for aesthetical purposes -- it is outside the scope of SFML to use native APIs.

I don't want SFML to be cluttered with those additions that would be necessary to use native GUIs. I wouldn't use it either.

And in those cases where you need such an integration (e.g. maps editors or the like), the current state of integration between Qt and SFML is more than sufficient.

[Jarvik7]

SFML is a libray for multimedia/game development. For these cases it is unusual to use the native GUI API delivered by the OS. Since almost every game uses its own GUI -- often for aesthetical purposes -- it is outside the scope of SFML to use native APIs.

I don't want SFML to be cluttered with those additions that would be necessary to use native GUIs. I wouldn't use it either.

And in those cases where you need such an integration (e.g. maps editors or the like), the current state of integration between Qt and SFML is more than sufficient.

Well, enabling it (for Win32 anyways) is only 10 lines of code, so it's hardly clutter. Also, hardcoded menu drawing is already in SVN for OSX, since OSX requires a menubar. That menubar is just not modifiable and the entries are greyed.

If SFML will not support native guis, it should at least not block it.

[Laurent]

Well, enabling it (for Win32 anyways) is only 10 lines of code, so it's hardly clutter. Also, hardcoded menu drawing is already in SVN for OSX, since OSX requires a menubar. That menubar is just not modifiable and the entries are greyed.

The problem is not about implementation. Of course it can be implemented, like many other features that we don't want

My concern is the public API, I want to keep it clean, simple and focused. Adding features just because they are technically easy, always leads to bloated and inconsistent APIs. Believe me, it's much harder to think about the design than implementing thing that I choose to add.