EtoForms is not native even when using winforms toolkit

Shadowblitz16 commented 5 years ago

Expected Behavior

Winforms looks like the right instead of the left for menus, toolbars, and context strips

Actual Behavior

looks more like the left (not native)

Steps to Reproduce the Problem

Make EtoForms app with winforms toolkit instead of wpf
add menu, toolbar and context strip
Run the program and see how ugly it looks

Code that Demonstrates the Problem

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Eto.Forms;
namespace PureEditor
{
    class Program : Form
    {
        static void Main(string[] args)
        {
            new Application().Run(new Program());
        }

        public Program()
        {
            Width  = 256;
            Height = 240;

            ButtonMenuItem item1 = new ButtonMenuItem();
            item1.Text = "Test1";

            Menu = new MenuBar();
            Menu.Items.Add(item1);

            ButtonToolItem item2 = new ButtonToolItem();
            item2.Text = "Test2";

            ToolBar = new ToolBar();
            ToolBar.Items.Add(item2);

            ButtonMenuItem item3 = new ButtonMenuItem();
            item3.Text = "Test3";

            ContextMenu = new ContextMenu();
            ContextMenu.Items.Add(item3);
        }
    }

}

Specifications

Version: 2.4.1
Platform(s): WinForms
Operating System(s): E.g. Windows 7 Ultimate 64 bit

Notes

I suggested something simular here and was suggested I use the eto winforms toolkit.
I would suggest imitating this in wpf as well by default just for ease of use. it shouldn't be too hard for someone that knows wpf templates well.
I think eto should have the native rendering of mainmenu, toolbar, and contextmenu with the features of menustrip, toolstrip and contextmenustrip.

ManuelHu commented 5 years ago

I suppose the left view is also the default style for winforms projects. The right one looks more similar to the default wpf style... Winforms menus just don't look as native by default. At least that's what I remember...

Shadowblitz16 commented 5 years ago

winforms looks native its just the newer strip versions of mainmenu, toolbar and contextmenu use custom renderers instead of the native system one.

I just suggest using the native renderers that the original versions used while keeping the features of the newer ones

cwensley commented 5 years ago

Hey @Shadowblitz16,

Yes, Eto.Forms uses Windows Forms' MenuStrip and ContextMenuStrip, as they have more features and are more flexible. At the time this was initially implemented (2006/2007), they were viewed as "more modern", as they matched things like Office 2007 at the time. That day may have passed. (;

One could potentially implement (optional) handlers for the MainMenu and ContextMenu instead, so you can decide which version you wish to use.

Shadowblitz16 commented 5 years ago

@cwensley is it possible to create a custom menubar, toolbar, and contextmenu so that we can have both in the same control?

cwensley commented 5 years ago

@Shadowblitz16 why would you want both the MenuStrip and a MainMenu in the same window (if it's even possible)?

It would be much easier to create new handler implementations and just use those instead of the *Strip ones.

Shadowblitz16 commented 5 years ago

the problem is they lack features.. for example mainmenu doesn't support icons and doesn't have a option to disable combining with the first in mdi windows.

so things like that would probably have to be implemented.

cwensley commented 5 years ago

@Shadowblitz16 I'm not sure how that could be implemented then? Eto can't make Windows Forms do things it can't do..

From what I've been reading about MainMenu and ContextMenu is that they are considered obsolete and you should use MenuStrip and ContextMenuStrip instead.

I wouldn't reject any contributions to add the option to use MainMenu/ContextMenu (even though they lack features), but they certainly wouldn't be default.

Shadowblitz16 commented 5 years ago

so eto.forms can't implement a system renderer for strip versions? or implement its own system drawn versions?

cwensley commented 5 years ago

can't implement a system renderer for strip versions? or implement its own system drawn versions?

Youch, I'd hate to have to keep updating something like that for all the styles Microsoft has for the various operating systems. And, this is much more work than could be tackled by this project unfortunately (though you are more than welcome to do it if you are inclined!).

It appears you can add images to the MainMenu with some hackery, so that would be the route I would go.

Another option is to just use Eto.Wpf instead, as it has better menu infrastructure.

Shadowblitz16 commented 5 years ago

@cwensley yes but wpf is not native, it uses custom rendering and microsoft didn't make the correct native styles for it.

cwensley commented 5 years ago

@Shadowblitz16 no problem, it's entirely up to you which platform you use. I personally prefer WPF over WinForms any day.

I really appreciate your feedback on this issue. I won't have time to modify Eto to use a modified MainMenu/ContextMenu approach, but will leave this issue open so the community can provide feedback and/or have someone volunteer to look into it.

cwensley commented 5 years ago

Looks like this will probably not be doable in the future. .NET Core 3.1 came out and the older variations of the mainmenu/toolbar/context menu have been removed. See https://devblogs.microsoft.com/dotnet/announcing-net-core-3-1/

Shadowblitz16 commented 4 years ago

damn Microsoft makes some bad choices

Shadowblitz16 commented 4 years ago

@cwensley so what about overriding the draw routines for newer ones so that it uses an old renderer?

this really needs to be addressed because anything below windows 10 the menus looks horrible however in windows 10 and probably above these newer versions do look better.

so its really just a issue of updating the rendering for menustrip, contextmenustip and toolbarstrip on older windows versions

cwensley commented 4 years ago

Hey @Shadowblitz16, doing something like that is beyond the scope of Eto.Forms. If you want WinForms to use native menus, then you will have to take it up with the WinForms team. Or you can create your own eto handlers to do what you are looking for. With .NET Core 3.1 you'll have to use p/invokes and such to create/manipulate them, since the API's were removed.

Shadowblitz16 commented 4 years ago

@cwensley oh ok thats too bad :(

Shadowblitz16 commented 3 years ago

Reopening this to get opinions.

@cwensley Microsoft has completely botched the WinForms api so that most of its controls don't use the native API or rendering anymore.

I honestly think if you wanted to make eto.forms completely native and compatible with older versions of windows I would suggest implementing a MFC or Win32 wrapper and get rid of WinForms

Shadowblitz16 commented 3 years ago

here is a example... https://github.com/dotnet/winforms/issues/4326#issuecomment-740374994

cwensley commented 3 years ago

Thanks for the feedback, @Shadowblitz16. Unfortunately, creating win32 wrappers for the entire menu infrastructure is not a goal of this toolkit, and there are no resources to do such work.

Feel free to keep this issue open so others can join the discussion. Perhaps there is someone that is willing to add this as an option to Eto.

picoe / Eto