| |
| |
On 11/20/22 10:34 'melcher...' via fltk.coredev wrote:
tl;dr : I would like to overhaul the menubar code, and I would like to
do it incrementally, so we can find regressions. I want to use the
master branch for that, but I would like to hear you first, since that
may add work.
I replied regarding "master branch or not" in another message. Here I'm
going to ask for some details.
Ok, so if you ever looked into the menu bar code (src/Fl_Menu.cxx),
you know that it is really hard to maintain. It also has some
shortcomings. For example, all menu items in a single menu must have
the same height, which is why the divider always looks like it was
squeezed in as an afterthought.
I implemented code that fixes a lot of these issues when trying to add
better dividers. The code is tested and works, but if I alone test
things, I may miss major regressions.
Can we see this code somewhere? Do (did) you push it to your fork?
I would like to push my code to master when I reach a milestone, so
that I am not the only one testing. Of course, every milestone would
be thoroughly tested in my branch before using it.
See my other reply.
A bit of history:
The menubar code was probably written before the actual FLTK core
became capable enough to do what the pulldown code implements in a
different, undocumented, and badly named way. I would like to fix that
while keeping the old API intact and adding a new way to add menus
that fits the FLTK hierarchical system.
Great idea. I would appreciate this very much if it could be done w/o
changing the API. However, this looks like a big task, and I wonder if
it wouldn't be easier and cleaner to rewrite a new menu system from
scratch. This way only users opting in to the new menu system would be
affected.
Milestone 1, flexible menu item sizes:
To implement this, I create Proxy widgets for every item that may
appear in a pulldown menu. When a menu window is opened, a true FLTK
widget hierarchy is created on the fly using the proxies.
Sounds interesting but also complicated. Maybe rewriting this from
scratch ... ;-)
With proxies, every menu item now has coordinates and sizes, and we
can finally have dividers that don't just draw a line, but also
visually divide groups. We can no easily have the horizontal stacking,
as FL_MENU_HORIZONTAL always promised, but never implemented.
Sounds good, although I don't think that horizontal menus are really
worth considering. Is there anybody that *wants* such menus, or would it
just be "because it can be done"?
Milestone 2, reducing special event handling and drawing:
Now, instead of having a three-page long loop, the menu window and
proxy widgets handle events as FLTK does anyway. We can make the
drawing code a lot simpler with the same results.
That would certainly be the most valuable part and we should try to do
this. Again, rewriting from scratch ... Well, doing this with "original"
menu widgets rather than Fl_Menu_Item arrays and proxies sound much less
complicated and in the end much easier to maintain.
Milestone 3, alternative to Fl_Menu_Item arrays:
And by deriving Fl_Menu_ from Fl_Group instead of Fl_Widget, we can
completely do away with the entire FL_Menu_Item array special
handling. The user just adds buttons and groups to the Fl_Menu_ driver
widget,
These "buttons and groups" would be Fl_Button and Fl_Group widgets, correct?
and the menu window code will take care of generating the proxies and
laying them out.
If the answer to my question above is true, why would we still need
proxies? Can't we just use the new menu widgets?
This solves also all i18n woes, questions of ownership, and inserting
menu items into arrays.
That would be very much appreciated, and I assume, fluid support would
also be done, right?
After all I believe that a full rewrite from scratch [1] would be the
way to go. It would be as easy as it could be: much easier than
integrating the new code into the old, complicated code which would
likely make it even more complicated. Knowing what the goals are we
(you) could use today's FLTK techniques. It would also be fully optional
for users, it would not affect existing (menu) code, and it could be
integrated in git 'master' as soon as "it works", even if we need to
improve it later and fix bugs. As long as it is optional for users and
documented to be in "beta stadium" it doesn't do any harm.
Looking forward to further discussions and other opinions.
[1] IMHO it's similar to the decision whether the new Fl_Flex widget
should be integrated in Fl_Pack or not. For me the decision was obvious:
write a new - hopefully better - widget and forget the old one.
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/abc81de5-6d67-3e14-ba2b-c464f3835d18%40online.de.
[ Direct Link to Message ] | |
|
| |
