wxWidgets Discussion Forum

bigpilot wrote:Please share

Well, you can have the sources from here (using SVN):

https://opensvn.csie.org/wxFlatMenu

I agree that both wxFlatNotebook and wxFlatMenu should become part of the standard CVS tree.

Perhaps traditionally the distribution has favoured native over owner-drawn controls, but the fact is that Windows has abandoned developers by introducing owner-drawn menus, toolbars and notebooks in Office, Visual Studio and other applications.

As far as I can see, Eran's menu and notebook look more 'native' on Windows than the standard XP menu bar and notebook. Nor is it just a matter of what looks right: the standard notebook lacks essential functionality (e.g. drag-and-drop for tabs).

What I do know is that Vadim (one of the core devs) is trying to deprecate the contrib dir. I also believe that the wxWidggets lib should not get too bloated with goodies (and eran, your wxFlatNoteBook & Menu are real GREAT goodies) but, a better solution is make as much as possible modular. Only keep in wxWidgets controls that are present on all platforms (or the majority), and things like wxFlatNoteBook, wxFoldBar, and all other nice controls should really become modular packages that one can add to the wx lib and use them. The advantage of this is if a component is added to the contrib dir, it 'rots'.. not many users have write access to the wxWidgets CVS, and patches are not processed fast enough. I think Franchesco was working on wxPackageManager which will hopefully solve this problem soon.

In any case, good work! But I am sure adding more to the wxWidgets CVS branch should be done with caution in favor of the wxPackageManager.

Regards,
- Jorgen

Jorg wrote:What I do know is that Vadim (one of the core devs) is trying to deprecate the contrib dir. I also believe that the wxWidggets lib should not get too bloated with goodies (and eran, your wxFlatNoteBook & Menu are real GREAT goodies) but, a better solution is make as much as possible modular. Only keep in wxWidgets controls that are present on all platforms (or the majority), and things like wxFlatNoteBook, wxFoldBar, and all other nice controls should really become modular packages that one can add to the wx lib and use them. The advantage of this is if a component is added to the contrib dir, it 'rots'.. not many users have write access to the wxWidgets CVS, and patches are not processed fast enough. I think Franchesco was working on wxPackageManager which will hopefully solve this problem soon.

In any case, good work! But I am sure adding more to the wxWidgets CVS branch should be done with caution in favor of the wxPackageManager.

Regards,
- Jorgen

I don't agree. Windows is still by far the most important platform and it's therefore important that Win32 wxWidgets apps look 'modern' and not outdated. I prefer the normal Win32 controls but in a few more years it will be simply inconceivable to produce a Windows program that doesn't use the new modern controls.

I do agree by looking modern, but that should be done using the DLL's that Windows provides. What Eran made is more then that, it extends the menu so that it can be placed anywhere on your form ..

The goal of wxWidgets is looking native on all platforms. If wxFlatMenuBar is compiled under linux, it still looks the same as under Windows. Which can be nice, and refreshing, but it contradicts the 'native' part.

Thats why it does not (yet) belong in the core of wxWidgets. So it will most probably end up in the contrib dir where it will not be easy to update. If wxPackageManager is finished, you simply download the source from a common repository, install it and use it with wxWidgets.

I'm not against incorporating it, but I do know what the core devs will say.

- Jorgen

Jorg wrote:I do agree by looking modern, but that should be done using the DLL's that Windows provides. What Eran made is more then that, it extends the menu so that it can be placed anywhere on your form ..

The goal of wxWidgets is looking native on all platforms. If wxFlatMenuBar is compiled under linux, it still looks the same as under Windows. Which can be nice, and refreshing, but it contradicts the 'native' part.

Thats why it does not (yet) belong in the core of wxWidgets. So it will most probably end up in the contrib dir where it will not be easy to update. If wxPackageManager is finished, you simply download the source from a common repository, install it and use it with wxWidgets.

I'm not against incorporating it, but I do know what the core devs will say.

- Jorgen

You're right that the new 'modern' controls should preferably be accessed using the normal Windows DLL's but as I stated in another post Microsoft is not making it easy for us, and I believe this is a deliberate act. The modern controls are only accessible (at least easily) through .NET and by Microsoft's own internal development teams. I believe this is to prevent projects like wxWidgets (which are a threat to Microsoft, since it allows software to be developed for multiple, competing platforms) from acquiring the 'modern' look.

You're right that the new 'modern' controls should preferably be accessed using the normal Windows DLL's but as I stated in another post Microsoft is not making it easy for us, and I believe this is a deliberate act. The modern controls are only accessible (at least easily) through .NET and by Microsoft's own internal development teams. I believe this is to prevent projects like wxWidgets (which are a threat to Microsoft, since it allows software to be developed for multiple, competing platforms) from acquiring the 'modern' look.

I agree. But the fact still stands that it does not look native under linux, even when it looks great, it's not the default way of how windows re displayed. I see no reason why not to treat this as a seperate package.

But I do know that Eran was discussing owner drawn controls with Vadim and Rober Roebling on the wx-dev list. It might be a better idea to revise the owner drawn system so for example if you create a wxMenu you simply specify a wxModernMsRenderer class that creates the menus according to the more modern look even when it is not native.

Let's see what the future brings.

- Jorgen

Obviously the flatmenu (whether native or custom-drawn) should only appear in the wxMSW distribution. On Mac and Linux there's also very little reason to have something similar, since the current controls are just fine there (they're not 'outdated').

Let's hope the wxWidgets team is able to figure out a way to use the native implementations on wxMSW. Here's hoping...

same to subject!

Hello, can you share a mingw gcc makefile or something, I didn't manage to get working with my app. I am using a monolithic shared wxwidgets 2.6.3 build.
I am using codeblocks with mingw, I've imported the solution file, compiled it with a static non monolithic wxwidgets build, the libs compile ok, but I can't make them work.
I get these linker errors:
undefined reference to `_imp___ZN13wxFlatMenuBarC1EP8wxWindowib15ToolBarIconSize'

undefined reference to `_imp___ZN10wxFlatMenuC1Ev'

undefined reference to `_imp___ZN13wxFlatMenuBar6AppendEP10wxFlatMenuRK8wxString'

(.text+0x1043f): undefined reference to `_imp___ZN10wxFlatMenu6AppendEP14wxFlatMenuItem'

undefined reference to `_imp___ZN10wxFlatMenu6AppendEP14wxFlatMenuItem'

(.text$_ZN14wxFlatMenuItemC1EP10wxFlatMenuiRK8wxStringS4_10wxItemKindS1_RK8wxBitmapS8_S8_[wxFlatMenuItem::wxFlatMenuItem(wxFlatMenu*, int, wxString const&, wxString const&, wxItemKind, wxFlatMenu*, wxBitmap const&, wxBitmap const&, wxBitmap const&)]+0x164): undefined reference to `_imp___ZN14wxFlatMenuItem8SetLabelERK8wxString'
Thanks

Hi,

Sorry, I am not using MingW (but VS7.1) so I dont have any makefile to share .. maybe someone else here can help you?

Eran

Hello!eranif!

Thanks for your gook work.
I want to use wxflatmenu in VC2005 with wx2.8. it seem some bug.
Could you tell me how to solve them?

Post here your problems, maybe i will have an idea

Eran

The wxFlatMenu code is just not compatible with the latest stable wxWidgets release 2.8.0: AUI class names has changed, some stuff moved to <wx/msw/private.h>

Also the code is not possible to use with wxWidgets DLL builds, as it uses DECLARE_EVENT_TYPE (->DECLARE_LOCAL_EVENT_TYPE) and wxWindowCreationHook (private wx class, not exported from dll).

Using https://opensvn.csie.org/wxFlatMenu, wxMSW 2.8.0, MSVC7.1

Regards
Troels

maybe that's why it doesn't work for me, I am using wxWidgets 2.6.3 as a mono shared build.