| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #2040
| Application: | FLTK Library |
|---|
| Status: | 2 - Closed w/o Resolution |
|---|
| Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | Deriving from Fl_Choice |
|---|
| Version: | 1.3-feature |
|---|
| Created By: | alvin |
|---|
| Assigned To: | fabien |
|---|
| Fix Version: | Will Not Fix |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | alvin
09:56 Sep 11, 2008 |
| When trying to derive from Fl_Choice, I noticed that it is impossible for a derived class to intercept when an item has been selected.
I propose a patch that adds
protected:
virtual Fl_Menu_Item* picked(Fl_Menu_Item *v)
picked() is called by Fl_Choice in all the circumstances in which an item is selected (e.g. FL_PUSH, SHORTCUT, KEYBOARD, ...).
I have attached a sample program that contains Fl_Smart_Choice. Fl_Smart_Choice (smart being very subjective ;) ) simply overrides picked() in order to determine if the selected/picked item's text is longer than choice's width (minus dw(box()) and hopefully the arrow buttons :) ).
If the item's text is longer, then the tooltip is set to the item's text. This allows a user to hover over the widget and see the full text via the tooltip. Conversely, if the item's text is shorter, then the tooltip is cleared. There's plenty of special cases that haven't been address (tooltip manually set by developer, etc. etc.)
Without the patch applied, the sample program will act no differently to if the widget were a Fl_Choice. | |
| |
| #2 | matt
15:25 Dec 26, 2008 |
| Um, I beleive that this is not a pretty patch. Overriding the Fl_Menu_ method with the same function, but this time virtual, is not a good idea.
Maybe there is a better way to acheive what you want to do? | |
| |
| #3 | fabien
01:37 Dec 27, 2008 |
| Overriding the handle() method and treating the FL_WHEN_RELEASE event isn't enough?
Why the need of overriding another method here ? | |
| |
| #4 | alvin
04:04 Dec 27, 2008 |
| To be honest, my rationale was two-fold for this STR. (1) Minimising the amount of work a caller would need to do to intercept when the FL_Choice's value changed and (2) minimising the modifications to Fl_Choice itself.
By making picked() virtual, the caller just needs to override one method. In Fl_Choice, picked() is called in all right places dealing with how a choice is selected be it via a FL_SHORTCUT, or FL_PUSH or even a FL_KEYBOARD event. At the time I was looking into this, it appeared that in order to get the same effect, would be to override the handle method of Fl_Choice and to (re)implement all the various ways an item can be selected.
Now, that was my rationale for this STR. However, this all moot if STR #2041 (http://www.fltk.org/str.php?L2041) is adopted. With STR #2041, the same effect can be done with SmartChoiceTest by the usual means of overriding the handle() method. Then it would be a simple matter of capturing the FL_TOOLTIP event. | |
| |
| #5 | fabien
04:29 Dec 27, 2008 |
| FLTK, like many other toolkits and GUI's , is an event driven interface.
In the GUI SoA, events are dispatched and treated by what we called reflexes (callbacks).
In these callbacks, protected methods can be called as part of the treatement but should not be used for polymorphic behavior, unless stated otherwise.
One of the idea behind the event driven approach is that it can evolve rapidly without breaking the API (black box approach as opposed to white box inheritance and overriding approach which reveals the implementation).
Method override may seem at the first glance a simple approach, but are just less flexible/general than event handling. | |
| |
| #6 | alvin
04:46 Dec 27, 2008 |
| You make a good point! Feel free to close this STR. If I could, I would revoke it. Perhaps that would be a good feature to the STR tracking system (the ability for an authour of an STR to mark the STR as revoked)?
I use STR #2041 (http://www.fltk.org/str.php?L2041) now to do the same thing (and more). IIRC, this STR actually lead to the more robust STR #2041 which does follow the reflex model as you describe. | |
| |
| #7 | fabien
08:30 Dec 27, 2008 |
| As requested by the OP. | |
[ Return to Bugs & Features ]
|
| |
