Andreas Ekstrand wrote:
> Ok, I understand more about the problem now. I briefly looked at the
> code and I realize that it's not a trivial task to implement what you
> explain.
Looking at the code a bit (I don't have much time free, so can't look
into this properly) I think the way forward might actually be to leave
fl_shortcut.cxx alone and modify Fl_Menu.cxx instead.
It contains a method:
const Fl_Menu_Item* Fl_Menu_Item::test_shortcut()
That more or less "knows" if we are in a top-level menu or not, before
calling the "real" test_shortcut() from fl_shorcut.cxx.
So, it may be possible to have the Fl_Menu_Item::test_shortcut() method
test for the ALT flag and maybe force it set temporarily before it calls
test_shortcut(), when processing what it knows to be a submenu item...
Well, something like that.
I can't test this as I don't have a Windows machine here just now. But
if you want to give it a try, we'd be interested in the results.
> So from my point of view, #2199 is far less serious than
> #2243 and I suggest that the lines of code fixing #2199 can be
> commented out. Who can make such a decision?
Well, if it is for your app - then you can.
1.3 is not released yet, and unlikely to be so in the short term, so
you'll need to work with your own baseline anyway to insulate yourself
from any ABI or API changes that make sneak in before 1.3 is declared
stable.
Also, you will probably want to link your code statically to the
fltk-1.3 lib to insulate against ABI changes in dll/so/dylib, again at
least until the ABI is stable.
So, on that basis, maintaining a one-line local patch seem pretty
trivial for now.
I doubt we will revert either #2199 or #2243 in the meantime - we would
much rather have a proper fix.
Let us know how you get on,
--
Ian
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
