LOL, it's actually OK once you get the hang of it.

> We seem to keep holding back 1.4.0 release

This probably worth a new thread. I'll be happy to do this for 1.5.0, or 1.4.1 in a minor ABI safe version.

> maybe make your code a build option

If users don't choose the option, a branch is probably better. What I propose leaves the old system intact, but it should not make the library much bigger, because the old and new implementation reuse more core code than the current implementation.

> I know that old application code might be using perhaps "unsavory" ways of accessing the internals

That's always possible. I assume that the Menu Item array does not change when a menu is up, but so does the current code. And when the menu pops up the next time, the proxy stuff is rebuilt, reflecting all potential changes.

> Or, should the rewrite have a new API, e.g. Fl_Menubar_V2, Fl_Menu_V2

Not a fan. Both APIs can coexist without causing confusion. 

> I'm really afraid that such massive changes would have unforeseeable effects and might break user code. Once we push them to master it would  be very hard to turn this back. 

That's the main reason for me asking. If it does break user code, at least we will know quickly. If we have a branch and merge in the final 1.4.0, we may mess up a major release which absolutely do not want.

> What I definitely don't want is "trying"  something (in master) that doesn't work and needs to be reverted

Yes, me neither. I was planning on keeping a branch, but once that is tested, I was thinking that milestones are better than one huge change of the core.

> Can we see this code somewhere? Do (did) you push it to your fork? 

Sure: https://github.com/fltk/fltk/compare/master...MatthiasWM:fltk:menu_divider . This removes the limitation that all menu items must be the same height and adds support for a divider item, a menu item without label, but with the divider flag set. All dividers have more space around them. I will add screenshots later.

> I wonder if it wouldn't be easier and cleaner to rewrite a new menu system from scratch

We would have two code blocks that do essentially the same. So improvements to one system would not benefit the other. Just having better dividers in existing apps is worth the effort to me.

> I don't think that horizontal menus are really worth considering.

Yeah, it's at best a "nice to have".

> doing this with "original" menu widgets rather than proxies sound much less complicated and in the end much easier to maintain.

I was back and forth about that. By using proxies, users can just add the already familiar  Fl_Group, Fl_Button, Fl_Radio_Button, and Fl_Check_Button, and none of the internals spills into  the core code (no new types, no overriding ::draw() and ::handle() if we are inside a menubar). I would add Fl_Divider though.