| [ Return to Bugs & Features | Roadmap 1.3 | Post Text | Post File | Prev | Next ]
STR #3317
Application: | FLTK Library |
Status: | 5 - New |
Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
Scope: | 1 - Specific to a machine/printer |
Subsystem: | Core Library |
Summary: | Fl_Sys_Menu_Bar: needs documentation caveats |
Version: | 1.3-feature |
Created By: | greg.ercolano |
Assigned To: | greg.ercolano |
Fix Version: | Unassigned |
Update Notification: | |
Trouble Report Files:
[ Post File ]No files
Trouble Report Comments:
[ Post Text ]
|
#1 | greg.ercolano 16:02 Jun 17, 2016 |
| As per thread on June 16, 2016 entitled "Subject: RFC: Fl_Sys_Menu_Bar":
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
I just got bit by the issue of Fl_Sys_Menu_Bar checkbox items not changing when adjusted using the usual find_item() and item->set()/item->clear().
This code works fine on Windows + Linux is not working on the mac when Fl_Sys_Menu_Bar is used.
We need to have the Fl_Sys_Menu_Bar docs indicate this and recommend the right approach that works for both Fl_Menu_Bar and Fl_Sys_Menu_Bar.
The way the docs currently read, it gives the impression one need only replace Fl_Menu_Bar with Fl_Sys_Menu_Bar. The docs only warn about cosmetic things, like font styling of the labels. It doesn't mention how e.g. accessing Fl_Menu_Item methods directly doesn't work.
A few questions:
> What /is/ the most compatible way to set/clear menu item checkboxes across Fl_Menu_Bar and Fl_Sys_Menu_Bar? From what I can tell, we should maybe use Fl_Menu_Bar::mode() instead of find_item() and item->set()/clear() If so, can we include some examples in the docs? I'm willing to write this, just want to make sure that's the recommended / most consistent way.
> In the Fl_Sys_Menu_Bar docs, there are references to 'rank', e.g.
void replace (int rank, const char *name) rename an item from the system menu bar
void Fl_Sys_Menu_Bar::remove(int rank) remove an item from the system menu bar
I'm guessing 'rank' means "index"? If so, I suggest we change the docs (and code) to refer to 'index' for consistency,
> Are there no tricks we can do in e.g. item->set() and item->clear() methods to have them work, e.g. detect the parent menu is an Fl_Sys_Menu_Bar, and do whatever extra work is necessary to ensure these changes make it to the GUI? It just seems weird they silently don't work.
> Is there maybe a way we can have an apply() or sync() method in Fl_Sys_Menu_Bar (or some such named method) that can apply any changes made to the menu()[] array so that they're reflected in the GUI? This would make it easier than having to retool apps from using the item techniques.
> It might not be a bad idea to put some warnings in the Fl_Menu_Item methods about which calls aren't compatible with Fl_Sys_Menu_Bar, or maybe \see also references to Fl_Sys_Menu_Bar with the above recommended doc warnings.
This created some really embarrassing bugs in my gui apps that hundreds of customers were encountering.
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- | |
|
#2 | greg.ercolano 16:11 Jun 17, 2016 |
| Manolo + Albrecht provided some answers to the questions: __________________________________________________________________
> What /is/ the most compatible way to set/clear menu item > checkboxes across Fl_Menu_Bar and Fl_Sys_Menu_Bar?
--- Manolo writes: The recommended way is, starting from a menu item: int index = smenubar->find_index(item); // to set: smenubar->mode(index, smenubar->mode(index) | FL_MENU_VALUE); // to clear: smenubar->mode(index, smenubar->mode(index) & ~FL_MENU_VALUE); __________________________________________________________________
> In the Fl_Sys_Menu_Bar docs, there are references to 'rank' [..] > I'm guessing 'rank' means "index"? If so, I suggest we change the docs (and code)..
--- Manolo writes: Yes, please. __________________________________________________________________ > Is there maybe a way we can have an apply() or sync() method > in Fl_Sys_Menu_Bar (or some such named method) that can apply any changes > made to the menu()[] array so that they're reflected in the GUI?
--- Manolo writes: This method exists: Fl_Sys_Menu_Bar::update() but, unfortunately it is protected.
I think we should make it public in 1.4. It can't be done in 1.3.4 because it would break the ABI. (Greg replies this can be done with ABI guards, Albrecht is ok with it if it can be done)
With this, one could write: item->set(); (or item->clear();) smenubar->update(); ..and have the item changed in the Mac menu. __________________________________________________________________ > It might not be a bad idea to put some warnings in the Fl_Menu_Item methods > about which calls aren't compatible with Fl_Sys_Menu_Bar, or maybe \see also > references to Fl_Sys_Menu_Bar with the above recommended doc warnings.
--- Manolo writes: My vision would be to first set the update() method public, and then to explain in class Fl_Sys_Menu_Bar that all operations applied to menu items should be followed by a call to the update() menu method to be visible in the interface.
--- Greg replies: Right, sounds reasonable. I can add mention of this to the existing caveats for Fl_Sys_Menu_Bar.
--- Albrecht replies: +1 | |
|
#3 | greg.ercolano 00:51 Jun 22, 2016 |
| Brought over Manolo's r11785 to make the update() method public with ABI guards (r11794), and his doc mods (r11795). | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |