RE: [Cxxgui-devel] Introduction, Menus, and General Design Question

[David T. <dkt...@te...>]

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