Re: [fltk.development] Article/video on Widget design - Was Re: [RFE] STR #2951: DoubleSlider...
Me: I'm diverting this to fltk.development rather than this specific RFE... Greg: Sorry about cluttering up your STR, but I was on a roll. I wanted to keep the 'what about a widget creation guide' separate from the RFE, so I split that part into fltk.development. I'm not sure how to manage a collaborative effort in the design of a new widget. People will need to be disciplined to post via the STR system if we want to keep it all within the RFE itself. If we reply via ordinary messages in fltk.development on the other hand, we can go a bit off-topic without polluting the RFE. Also, I don't maintain my own web page anywhere, so actually sharing any initial development could be tricky. Do I simply upload regular patches to the RFE for people to comment on? Do I develop within the FLTK 1.3.x branch, or do I create a project on sourceforge or wherever and keep it as a separate project until it's ready for adoption? D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Article/video on Widget design - Was Re: [RFE] STR #2951: DoubleSlider...
I'm diverting this to fltk.development rather than this specific RFE... Greg wrote: It occurs to me maybe I should write an article or make a video or something on how to make an FLTK widget, all the wacky details and implications. I wish I had one when I was writing Fl_Tree and Fl_Table, as there's a lot of stuff about keyboard nav and when() that I didn't know about until much later.. making it hard to go back and retrofit..! It would certainly be useful to have a set of hints on all of the areas that need to be considered, and in what order they should be addressed during development. For example, I rarely customize a new desktop and always stick to the default themes, so I have no idea whether themes have to be built in from the start, or if they are easy or difficult to retrofit later. It might actually be useful and fun to work through the design and implementation of a new widget, one step at a time, using such a set of hints, and eliciting feedback from the [widget] developers along the way, in order to (a) debug and improve the hints, and (b) give the basis for a Designing your own widget page in the documentation. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Article/video on Widget design - Was Re: [RFE] STR #2951: DoubleSlider...
Greg wrote: It occurs to me maybe I should write an article or make a video or something on how to make an FLTK widget, all the wacky details and implications. I wish I had one when I was writing Fl_Tree and Fl_Table, as there's a lot of stuff about keyboard nav and when() that I didn't know about until much later.. making it hard to go back and retrofit..! It would certainly be useful to have a set of hints on all of the areas that need to be considered, and in what order they should be addressed during development. For example, I rarely customize a new desktop and always stick to the default themes, so I have no idea whether themes have to be built in from the start, or if they are easy or difficult to retrofit later. It might actually be useful and fun to work through the design and implementation of a new widget, one step at a time, using such a set of hints, and eliciting feedback from the [widget] developers along the way, in order to (a) debug and improve the hints, and (b) give the basis for a Designing your own widget page in the documentation. Hi Duncan (and Greg), Yes, sounds like a worthy endeavour. Certainly seems to have rung a bell with Greg too! Cheers! Selex ES Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Article/video on Widget design - Was Re: [RFE] STR #2951: DoubleSlider...
On 04/15/13 00:48, Duncan Gibson wrote: I'm diverting this to fltk.development rather than this specific RFE... Sorry about cluttering up your STR, but I was on a roll. Tried to move it to fltk.dev, but I'd've (*) had to make an intro and write for a wider audience.. just the thought of it was messing up my flow. Greg wrote: It occurs to me maybe I should write an article or make a video or something on how to make an FLTK widget, all the wacky details and implications. I wish I had one when I was writing Fl_Tree and Fl_Table, as there's a lot of stuff about keyboard nav and when() that I didn't know about until much later.. making it hard to go back and retrofit..! It would certainly be useful to have a set of hints on all of the areas that need to be considered, and in what order they should be addressed during development. For example, I rarely customize a new desktop and always stick to the default themes, so I have no idea whether themes have to be built in from the start, or if they are easy or difficult to retrofit later. It might actually be useful and fun to work through the design and implementation of a new widget, one step at a time, using such a set of hints, and eliciting feedback from the [widget] developers along the way, in order to (a) debug and improve the hints, and (b) give the basis for a Designing your own widget page in the documentation. Yes, a short list would be good at least. Your widget is interesting in that it has two moving parts. In that cases it usually helps to split the widget up into separate widgets, one widget per moving part, so that each thing that needs focus will be handled by FLTK's own event delivery system through the widget hierarchy, which would also gracefully handle things like focus, keynav, etc. I think your widget could maybe be a simple Fl_Group that could host two Fl_Valuator widgets to handle the two tabs, but it might get tricky. You wouldn't want to overlap them (that would be bad, as they'd disagree over the common real estate for mouse clicks), but perhaps abutting them side-by-side, and let the parent widget handle changing their sizes to always be abutting. That might get tricky though if you decide to support locked behavior, where dragging in the trough between the two tabs moves both. You'd probably want the parent's handle() method to take control at that point, as the parent will doubtless want to resize both valuator's xywh dimensions to keep them abutting while the range is changing. I suppose another route to go would be to make completely custom tab widgets that only have the tab as their governing real estate, and dragging them just changes their xywh position. The widget could have a VERTICAL | HORIZONTAL flag so that its position could be limited to a single dimension of travel, and could have an xmin/xmax ymin/ymax to limit travel along that axis, which the parent group widget could maintain. Then the parent would own the 'trough' and could handle an optional graticule and 'locking bar' that could be slid around to lock the two tabs together. It's definitely easier to plan and conceive new widgets from the perspective of understanding the big picture of FLTK's underlying mechanisms (when()/focus/handle()/event delivery/etc).. which is why it's so important to have something in our docs on how to write custom widgets. This way when folks go off to write custom widgets, they don't leave stuff out. There should probably be separate sections describing different types of widgets, like buttons vs. text vs. tables vs. browsers vs. file browsers vs. radio buttons vs. simple drawing areas, etc. and describe which fltk features each uses, and explain common programming patterns used by these widgets. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
