RE: [Cxxgui-devel] Introduction, Menus, and General Design Question
Brought to you by:
davidturner
From: David T. <dkt...@te...> - 2004-09-30 21:45:20
|
Hi David I'm so glad to know that at least one person is interesting in helping out :-). The fact that the project is mostly inactive is my fault; I've been rather busy with a new startup recently and haven't had time to maintain it. But I seem to have more time on my hands now, so hopefully progress will happen. [snip] > Anyway, so I thought my first project would be menus, under win32 for > now, and this is the usage I've conjured up (I've written the > interface > for it and the beginnings of the win32 impl as well): > > using namespace gui; > window win("Test"); > menu mn; > win.contain(mn); > mn.append( > menu("File").append(menu("New").append(menu_item("Picture",boo > st::bind(on_new_picture,win))) [snip] I like the chaining thing too, and what you've designed is more or less what I had in mind for the menus :-). Please send me the patch so that I can have a look at it! There is an implementation detail which has been bothering me (one of the reasons I haven't approached menus yet). The detail is this: Win32 menus are stupid. They make all sorts of crass assumptions about being bound to windows in certain places, intercepting keystrokes and so on. Good for user-interface consistency, but bad design in general. What I was thinking of doing was containing the menu in a child window of its own, which may or may not work. What are your thoughts? > I'll drop it. But I have an implementation question (assuming > that this > method is acceptable): Should I go ahead and add some kind of set (or > maybe even map?) of Callback ids to signals in the window > implementation? or maybe just a deque? Have a look at what I did with win32/button.cpp. I think this approach might be appropriate for menus, too. The win32/window.cpp:window_dispatch is the main window procedure for all top level gui::windows. This function checks the window long to see if it needs to dispatch the message to the window's object. However, it also checks to see if the message is a WM_COMMAND message; in this case, the message is instead dispatched to the *originating* window (i.e. the control). This way buttons get their own click notifications. The same principle should work for menus, but I haven't looked into it. (There are far too many assumptions and arbitrary decisions in USER32. In my opinion.) > > Finally, there seems to be rather schizophrenic support for > std::string > and std::wstring: it's in the win32 implementation code, but > not in the > interface code (e.g. labels on buttons). Is there a reason for this? Yes. I decided (perhaps wrongly) to use UTF8 exclusively on the interface side. If you grep for utf8_to_unicode you should see what's happening. Regards David Turner |