| [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #650
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Core Library |
Summary: | Suggested new widget: Fl_Input_Choice |
Version: | 1.1.6 |
Created By: | greg.ercolano |
Assigned To: | mike |
Fix Version: | 1.1.7 (SVN: v4050) |
Update Notification: | |
Trouble Report Files:
Trouble Report Comments:
|
#1 | greg.ercolano 15:11 Dec 13, 2004 |
| This is basically a single .H file that combines the Fl_Input and Fl_Choice widgets in such a way that the user can either type in a value, or choose values from a menu.
Source and docs are here: http://seriss.com/people/erco/fltk/Fl_Input_Choice/
Core folks may want to modify the API, feel free to do so, or I can make them for you if you have suggestions.
| |
|
#2 | greg.ercolano 15:47 Dec 13, 2004 |
| Followup: Use the Fl_Choice_Input.H at the URL, instead of the attached file which had leftover #includes, and some non-fltk indents. | |
|
#3 | mike 16:28 Dec 13, 2004 |
| Shouldn't the resize() method be public?
Also, I think some more inline methods might be useful:
add() clear() size() value(int) (to replace menuvalue)
But it looks promising, and I have no objections to adding this to 1.1.x whenever I do 1.1.7. | |
|
#4 | greg.ercolano 02:47 Dec 15, 2004 |
| > resize() public?
OK.
> add(), size(), value(int) (to replace menuvalue) clear()
I wasn't sure where to draw the line as to which methods to implement, and which to just leave to the user to get via the internal widget accessors "menubutton()" and "input()".
Seems like there are three ways to approach the API of this widget:
1) Supply *only* the methods whose internal logic is unique
2) Supply #1, plus anything 'convenient' to average use
3) Supply all methods from all widgets, except any that overlap. eg. implement wrappers for methods like popup(), textfont()..
I opted for #1, because it was clear when to stop writing methods. (It was also easiest to stop there ;)
But sounds like you think #2 is the best way to go..?
If so, how do I know when to stop writing methods? eg. do I stop at clear/add/size/value, or should I also do popup(), textfont(), etc?
In other words, not sure where to draw the line between what is a 'convenience method', and what is 'too specific or obscure to bother with'.
I can make guesses, but I suppose I'd always be wrong to somebody ;)
Is there a clear way to decide what to implement and what not? | |
|
#5 | mike 14:18 Feb 06, 2005 |
| Greg,
I've made changes to your implementation and would like you to approve them before I add it to FLTK proper; aside from adding methods to allow manipulation of the value and menu and renaming things, I also changed the input field box type to always be FL_FLAT_BOX and updated the header to conform to the current CMP documentation and coding standards.
If you approve of the changes, I'll add it to the 1.1.7 release.
Thanks!
| |
|
#6 | mike 14:19 Feb 06, 2005 |
| Let's try that again... | |
|
#7 | greg.ercolano 14:27 Feb 17, 2005 |
| > I've made changes to your implementation and would like you to approve > them before I add it to FLTK proper
Just getting to this now.. will check.
| |
|
#8 | greg.ercolano 15:02 Feb 17, 2005 |
| I like your mods -- good changes I think.
I've attached a modified test program (input_choice.cxx) which I used to verify its operation. This might be useful to include in the test directory, or some modified version thereof. | |
|
#9 | mike 13:15 Feb 24, 2005 |
| Fixed in Subversion repository.
Also added to FLUID, demo.menu, and documentation... | |
[ Return to Bugs & Features ]
|
| |