[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] [RFE] STR #2951: DoubleSlider for selecting low and high values within min/max range
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2951 Version: 1.4-feature Well, Greg said it all.. ;-) That said, here's one addition from me. It'd be good to have the widget look like the other FLTK slider widgets for integration with other sliders. However, I'd also like it to have its own fancy look. Maybe both (selectable) would be good to have. (The ultimate option would be to provide a hook to enable own draw() functions, but that's probably too much effort.) So I think that making this DoubleSlider widget being able to use only one slider would be simple and offer an opportunity to use it (and its maybe different look) as a normal lider widget as well, depending on an option or flag - need not be its own class name. Link: http://www.fltk.org/str.php?L2951 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fluid - Adding win32 icon
Le 25/03/2013 22:07, David FLEURY a écrit : I found an easy tool (VarilconsRevolve) Here a new patch. I remove all unnecessary lines from the rc file and fluid_resource.h I just remove cygwin (I have no cygwin installed, I can't not test). I have to 2 more icons on the fluid.ico file (48*48 and 64*64) so its not so big. Not sure I can do better. Hi, I reactivate this, just to known if I had to keep it somewhere on my repo to patch my fltk, or something like this will be apply in the official repo. Regards, David ___ 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
Re: [fltk.development] fluid - Adding win32 icon
On 04/15/13 09:53, David FLEURY wrote: I reactivate this, just to known if I had to keep it somewhere on my repo to patch my fltk, or something like this will be apply in the official repo. If I understand this correctly, making a win32 icon for the fluid app so that the fluid.exe will appear in a file browser with an icon? I think the most flexible way of doing this would be to link a resource file with the icon into the binary at link time. Whenever I've needed this, the approach I use is implemented purely in the Makefile, ie: [1] echo 0 ICON /path/to/my/icons/myapp.ico myapp.rc [2] cl myapp.obj myapp.rc $(LIBS) /subsystem:windows This could probably be done as custom build flags in VS as well; step [1] creates a small one line .rc file that defines where the .ico file is, and step [2] links the rc file into the app, which pulls the .ico into the binary. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fluid - Adding win32 icon
Le 15/04/2013 19:52, Greg Ercolano a écrit : If I understand this correctly, making a win32 icon for the fluid app so that the fluid.exe will appear in a file browser with an icon? Correct I think the most flexible way of doing this would be to link a resource file with the icon into the binary at link time. Whenever I've needed this, the approach I use is implemented purely in the Makefile, ie: [1] echo 0 ICON /path/to/my/icons/myapp.ico myapp.rc [2] cl myapp.obj myapp.rc $(LIBS) /subsystem:windows This could probably be done as custom build flags in VS as well; step [1] creates a small one line .rc file that defines where the .ico file is, and step [2] links the rc file into the app, which pulls the .ico into the binary. I don't know this approach. I have used the load resource provided in fltk. You can check the patch if you want. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fluid - Adding win32 icon
On 15 Apr 2013, at 17:53, David FLEURY wrote: Le 25/03/2013 22:07, David FLEURY a écrit : I found an easy tool (VarilconsRevolve) Here a new patch. I remove all unnecessary lines from the rc file and fluid_resource.h I just remove cygwin (I have no cygwin installed, I can't not test). I have to 2 more icons on the fluid.ico file (48*48 and 64*64) so its not so big. Not sure I can do better. Hi, I reactivate this, just to known if I had to keep it somewhere on my repo to patch my fltk, or something like this will be apply in the official repo. Is there an STR for this somewhere? I can't find it... so I can't find the patch. Anyway: what sizes are in the icon file now? We need to be sure there are enough sizes to cover the range expected by XP through Win7 (and I suppose Win8, though I don't know what sizes it likes; I assume same as Win7?) As fas as the patch goes, I imagine the only material change to the code is to add a #ifdef to load the icon, e.g. as is done on the sudoku example in the test folder? That is certainly what I do in my own code, at any rate. Regarding changes to the Makefile, I'm only likely to use the mingw tools any time soon, so if a suitable icon is available I can adjust fluid's Makefile to do the resource compilation and so forth for the mingw (and hence probably cygwin too...) builds. Again, that'll largely be a matter of cloning the suduko build target really...! Which reminds me... whilst we are on the subject of Windows icons; we really need to look at #2816 again and get that merged, as it would be useful... ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fluid - Adding win32 icon
Le 15/04/2013 21:57, Ian MacArthur a écrit : Is there an STR for this somewhere? I can't find it... so I can't find the patch. I am not used to create a STR. I did not create one. Anyway: what sizes are in the icon file now? 32k I have added a 64*64 and a 48*48 icons We need to be sure there are enough sizes to cover the range expected by XP through Win7 (and I suppose Win8, though I don't know what sizes it likes; I assume same as Win7?) I have tested it against win8. The icon look fine (64*64) not succeeded to put a bigger one (size increase to much too) As fas as the patch goes, I imagine the only material change to the code is to add a #ifdef to load the icon, e.g. as is done on the sudoku example in the test folder? Yes exactly That is certainly what I do in my own code, at any rate. Regarding changes to the Makefile, I'm only likely to use the mingw tools any time soon, so if a suitable icon is available I can adjust fluid's Makefile to do the resource compilation and so forth for the mingw (and hence probably cygwin too...) builds. Again, that'll largely be a matter of cloning the suduko build target really...! I have no mingw installed. I have excluded mingw for this patch since I cannot test it. Which reminds me... whilst we are on the subject of Windows icons; we really need to look at #2816 again and get that merged, as it would be useful... ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fluid - Adding win32 icon
On 15 Apr 2013, at 21:28, David FLEURY wrote: Le 15/04/2013 21:57, Ian MacArthur a écrit : Is there an STR for this somewhere? I can't find it... so I can't find the patch. I am not used to create a STR. I did not create one. Ah. That's gong to make it very hard for us to view and comment on it, then. I think the best thing would be to create an STR and post the icon and your patches there, for folk to take a look at. Anyway: what sizes are in the icon file now? 32k The icon file is 32k bytes now? That seems OK, maybe a bit larger than I'd have expected... OK, just checked, and the icon I've been using for my app is 29k, but it has sizes from 16x16 up to 256x256 in it. I have added a 64*64 and a 48*48 icons So, it has 16x16 32x32 48x48 and 64x64 then, is that right? My understanding is that, for Win7 at least, we'd really want a 128x128 as well, possibly even a 256x256 just in case! Is the image you are using for the icon very complex? I'm a bit puzzled why the icon is bigger than mine when it does not have as many sizes in it...? We need to be sure there are enough sizes to cover the range expected by XP through Win7 (and I suppose Win8, though I don't know what sizes it likes; I assume same as Win7?) I have tested it against win8. The icon look fine (64*64) not succeeded to put a bigger one (size increase to much too) Yup, that seems odd. WOnder why it seems to be so big... As fas as the patch goes, I imagine the only material change to the code is to add a #ifdef to load the icon, e.g. as is done on the sudoku example in the test folder? Yes exactly That is certainly what I do in my own code, at any rate. Regarding changes to the Makefile, I'm only likely to use the mingw tools any time soon, so if a suitable icon is available I can adjust fluid's Makefile to do the resource compilation and so forth for the mingw (and hence probably cygwin too...) builds. Again, that'll largely be a matter of cloning the suduko build target really...! I have no mingw installed. I have excluded mingw for this patch since I cannot test it. If you post what you have to an STR, we can certainly look at making it work for mingw too... ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fluid - Adding win32 icon
On 04/15/13 13:28, David FLEURY wrote: Le 15/04/2013 21:57, Ian MacArthur a écrit : Is there an STR for this somewhere? I can't find it... so I can't find the patch. I am not used to create a STR. I did not create one. Ian; he included the patch here on fltk.dev at the head of this thread. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fluid - Adding win32 icon
On 15 Apr 2013, at 22:13, Greg Ercolano wrote: On 04/15/13 13:28, David FLEURY wrote: Le 15/04/2013 21:57, Ian MacArthur a écrit : Is there an STR for this somewhere? I can't find it... so I can't find the patch. I am not used to create a STR. I did not create one. Ian; he included the patch here on fltk.dev at the head of this thread. Oh, OK. I had the sense, from what he was saying, that there were changes to the patch - David and I discussed this patch a few days back, and I think he was tweaking things about, so I wanted to see where we have got to. I also wanted to take a peak at the icon, so I thought that posting all the bits to an STR would be the easiest option. Also, would make it easy for others to pitch in... Cheers, -- Ian ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fluid - Adding win32 icon
On 04/15/13 14:28, Ian MacArthur wrote: On 15 Apr 2013, at 22:13, Greg Ercolano wrote: On 04/15/13 13:28, David FLEURY wrote: Le 15/04/2013 21:57, Ian MacArthur a écrit : Is there an STR for this somewhere? I can't find it... so I can't find the patch. I am not used to create a STR. I did not create one. Ian; he included the patch here on fltk.dev at the head of this thread. Oh, OK. I had the sense, from what he was saying, that there were changes to the patch - David and I discussed this patch a few days back, and I think he was tweaking things about, so I wanted to see where we have got to. I also wanted to take a peak at the icon, so I thought that posting all the bits to an STR would be the easiest option. Also, would make it easy for others to pitch in... Ah, OK, yes, agreed it's time for an STR. FWIW, and as a separate issue, I *think* the .rc file can be a simple one liner. (I'm all about simplicity and understanding everything in the files I build) For instance, with sudoku, it seems I can change the sudoku.rc file to just contain: 101 ICONDISCARDABLE sudoku.ico ..and in the sudoku.cxx: icon((char *)LoadIcon(fl_display, MAKEINTRESOURCE(101))); ..and I think that would get rid of the need for a sudokurc.h file, and shortens the .rc file quite a bit. So with those two things, one can compile from the command line (I use gmake scripts); To compile the one line sudoku.rc - sudoku.res: rc -r sudoku.rc ..and to link: link [..] sudoku.obj sudoku.res [..] ..and then the resulting exe shows up in the browser with the icon, and when executed, the titlebar shows the icon as well. This change seems to work within the vs IDE as well. So perhaps fluid could be just as simple. Just seems like the shorter the better, but I really don't know what all that other cruft is in those files. Heh, does anyone, really? :P ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] RFC: win32 Fl_Window::icon() vs Fl_Window::xclass()
I just noticed a few things on win32: [1] If an app sets the window's xclass() *before* it sets the icon(), the icon won't show up in the title bar. [2] In the win32 osissues page, under Setting the Icon of a Window there's a NOTE: that reads: You must call Fl_Window::show(int argc, char** argv) for the icon to be used. The Fl_Window::show() method does not bind the icon to the window. This no longer seems to be true, at least empirically. And I think Albrecht once commented he noticed this as well, and wondered aloud if this comment was outdated, if ever true. Is [1] known behavior that should be documented? Is [2] really obsolete and should be removed, or are the empirical observations simply undefined behavior? Regarding [1], it was driving me nuts today, so if it really is order dependent, we should document to prevent insanity. In fact, I think when the following three calls are being used together, they have to appear in this specific order or they won't work right.. at least on win32 anyway: 1) icon() -- if used with xclass(), this must be first 2) xclass() -- if used with icon(), this must come after icon() 3) show() -- if any of the above are used, this must come last ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
