wxFlatMenu & wxFlatMenuBar
in [wxWindows]
|
From: Eran Ifrah on 19 Oct 2006 14:56 Vadim Zeitlin wrote: > On 17 Oct 2006 00:03:44 -0700 Noel <NoelByron(a)gmx.net> wrote: > > N> Vadim Zeitlin wrote: > N> > On Mon, Oct 16, 2006 at 08:27:08PM +0200, Eran Ifrah wrote: > N> > > It is a generic code indeed, all drawings are done using the regular > N> > > wxDC/wxMemoryDC family (except for the shadows for the menus). > N> > > N> > Maybe it would make more sense to add some new methods to wxRenderer? > N> > N> Eran wrote a renderer class and he decided towards a wxUniv renderer > N> style method signatures. At least to draw a button. But AFAIK this > N> renderer exists only in the wxUniv port. > > Sorry, I'm not sure I understood this correctly. If Eran has a wxRenderer, > then it's, in particular, a wxRendererNative too. > > N> What should Eran do? He wants to see his flat menu on windows together > N> with the native controls and on GTK together with GTK controls. I think > N> you faced the same problem before and decided to create two different > N> renders. One in the wxUniv port and another one in the other ports? > > The problem of mixing universal and native controls is a different, and > more complicated, one. I didn't intend to ask Eran to ask this (if he > could, it would be great, but so far we didn't find any good solution...) > but to just centralize the rendering/drawing functions somehow for ease of > maintenance. > > N> If one wants to do this in a generic way (with a common renderer) > N> doesn't that mean, we would need a common renderer across all the port? > > It already exists, this is wxRendererNative. Many generic controls use it. > > > N> Well as long as this (really good looking and well designed) wxFlat > N> things are in a separate library it is IMHO no problem to maintain. > > It may be if the drawing code is scattered over many different places. > Using wxRenderer(Native) allows to centralize it. > > N> If one wants a flat menu, he simply links against this library and if > N> one doesn't he uses the build in wxWidgets things (I could imagine > N> macros to map from wxFlatMenu to wxMenu). > > I wonder about how does this work in fact. Does wxFlatMenu have exactly > the same API as wxMenu? > > N> My point: can we give advice or a kind of guideline for anybody who > N> wants to reimplement a widget that already exists in wxWidgets? Are > N> there plans or visions regarding the 'themeability' of the wxWidgets > N> ports? > > No, unfortunately I can't give any such guideline, I don't know what would > be the best way to do this myself. But I'm pretty sure that putting common > drawing methods in wxRenderer is still a worthwhile thing to do. > > Regards, > VZ > > >> I wonder about how does this work in fact. Does wxFlatMenu have exactly >> the same API as wxMenu? It depends, I tried to follow the exact same API where possible. However, since, for example, to place a wxMenuBar on a frame one needs to call: SetMenuBar(), and this function expects wxMenuBar as input argument, and my menu bar is of type wxFlatMenuBar I needed to provide an alternative or a workaround: The easiest solution was to place a sizer for the main frame, and then place my menu bar as first child of it. this works nicely for, but, many GUI applications, are using some kind of docking library, in our case wxAUI, So I needed to find a solution for wxFlatMenuBar so it can co exist with wxAUI. So, an additional API is provided when building wxFlatMenu library with wxUSE_AUI=1 enabled: SetAUIManager() this function places the menu bar as non-floating top window of the AUI *not* as toolbar (sample is provided as well). For wxIFM needs a panel to work correctly with frames, so the first sizer solution works well for it as well. Another API change I needed, was calling PopupMenu. The regular wxWindow has a function wxWindow::PopupMenu(), since it expects wxMenu, I needed to provided an alternative for this, so I introduced wxFlatMenu::Popup(wxPoint &pos, wxWindow *owner) function to wxFlatMenu (which seems more logical to me). The function wxFlatMenu::Popup(wxPoint &pos, wxWindow *owner) accepts two parameters: pos - which pretty much self explanatory, and owner, which is the window that will be the first one in the chain to accepts events from the menu (it is not the menu parent!) - this is a feature that could be nice if it was added to wxMenu as well. All of the wxMenu functionality is implemented in wxFlatMenu - including all events, keyboards, accelerators, mnemonics etc, excepts: 1. If menu is too high to fit the screen, it does not provide any scrolling capabilities - will be added next 2. Radio items - not yet implemented The code can be viewed from here (anonymous checkout is enabled): https://opensvn.csie.org/wxFlatMenu/ I am thinking of merging my wxFlatNotebook with wxFlatMenu into single library (wxflatctrls), so maintenance will be much easier for me. Eran --------------------------------------------------------------------- To unsubscribe, e-mail: wx-users-unsubscribe(a)lists.wxwidgets.org For additional commands, e-mail: wx-users-help(a)lists.wxwidgets.org |