Re: [fltk.development] RFC: Handling ABI features [was: STR #2795: Fl_Tree: needs to be optimized to handle very large contents (10000)]
Moving this thread to fltk.development ... Please post follow-ups to fltk.development. On 05.01.2012 18:15, Greg Ercolano wrote: Looks like fltree.patch would break the ABI, so we can probably not apply this in fltk 1.3.x. Good point. Hmm, we really need a way to get ABI breaking stuff into FLTK, because if we don't, we forget to add it later. Good point, too. However, we could (and should) move STR's with ABI-breaking features to fltk-next-version-feature, and then we *should* look at this thoroughly when we go to the next ABI version. Also, I think a lot of people compile static, and aren't concerned with the ABI. Yep, so do I. And personally I always link static. For interim releases, I have a suggestion. Perhaps we can create a configure(1) controlled macro flag called FLTK_ABI_FEATURE that is default off, and could be used to #ifdef out ABI breaking features. This would prevent a code fork, and leave a clear flag for devs when the version bumps for ABI features that need to be enabled. I would even think of making this a versioned macro, so that we could selectively enable features based on the released FLTK version, e.g. #define FLTK_ABI_VERSION 010300 for FLTK 1.3.0. This way, new features could be enabled by defining the macro to have the value 010302 to enable features introduced in FLTK 1.3.2. Although this looks a little strange, since the default (released) FLTK ABI versions would always end in '..00', this could be interesting for someone who builds his own shared lib based on FLTK 1.3.2 and releases later apps and/or shared FLTK libs with the same ABI version. The sources would then need something like this #if FLTK_ABI_VERSION = 010302 ... #endif This way, code ported to FLTK 3.0 would automatically enable all FLTK 1.3.x features left in the code with these macros. To avoid #ifdef littering in cases where an ABI feature makes many changes to a single file, perhaps too, we could standardize on a file naming convention for ABI-breaking code. For instance, if I decide my ABI feature makes too many changes to a particular .cxx or .H file to use #ifdef's for, I can simply create a copy of the file, and put it in a special ABI_FEATURES directory, and use a single #ifdef in the main file to #include it if the configure(1) feature is enabled. eg: src/Fl_Tree.cxx -- default build file src/ABI_FEATURES/Fl_Tree.cxx -- ABI feature version of this file .or some such. So then inside the normal src/Fl_Tree.cxx there would be: #ifdef FLTK_ABI_FEATURE #include ABI_FEATURES/Fl_Tree.cxx #else [contents of normal file here] #endif /*ABI_FEATURE*/ So I imagine with this arrangement, when FLTK bumps its ABI version, it's clear to the devs what to clean up; the #ifdef's are removed, the feature file is merged into the normal file, and the feature file would be removed. Or something like that. Hmm, for really large changes and additions, this might be a way to go, but for small code changes, duplicating entire files would probable be a maintaining nightmare. Fixes to ABI-independent code parts would have to be duplicated etc.. Although I can see your point here very well. This may have some interesting implications for doxygen, perhaps some discussion is needed on that. Yep, one more point to leave all changes in one file, maybe. Doxygen has one directive \since that could be interesting here. This all might help solve two common issues we've had in the past: o Not being able to add ABI breaking features we want o Forgetting to add ABI breaking stuff when we bump the ABI version Agreed. However, not to forget: testing and bug reporting and fixing could become interesting, since we must also know the ABI version the reporter used for his special case. And dev's might need to check their changes against different ABI versions... Anyway, having such a feature and using it with care would IMHO be an advantage. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Handling ABI features [was: STR #2795: Fl_Tree: needs tobe optimized to handle very large contents (10000)]
On 01/06/12 06:28, Albrecht Schlosser wrote: Moving this thread to fltk.development ... Please post follow-ups to fltk.development. On 05.01.2012 18:15, Greg Ercolano wrote: Looks like fltree.patch would break the ABI, so we can probably not apply this in fltk 1.3.x. Good point. Hmm, we really need a way to get ABI breaking stuff into FLTK, because if we don't, we forget to add it later. Good point, too. However, we could (and should) move STR's with ABI-breaking features to fltk-next-version-feature, and then we *should* look at this thoroughly when we go to the next ABI version. Right, agreed. I'd say perhaps some message in the STR that says it's implemented as an ABI feature, but remains open. (perhaps a new state for the STR that could be 'ABI feature', so that it's not exactly closed, but not unresolved either. Maybe we have such a state already that is close enough) I could see a possibility where an ABI feature might be added that has no corresponding STR. (The feature might have been added as part of normal development) To close that hole, perhaps we should add a requirement to the CMP so that all new .0 releases must first resolve all FL_ABI_FEATURE's are resolved before release. So in other words, make sure any source files that show up in 'grep -r FL_ABI_FEATURE .' get resolved. For interim releases, I have a suggestion. Perhaps we can create a configure(1) controlled macro flag called FLTK_ABI_FEATURE that is default off, and could be used to #ifdef out ABI breaking features. This would prevent a code fork, and leave a clear flag for devs when the version bumps for ABI features that need to be enabled. I would even think of making this a versioned macro, so that we could selectively enable features based on the released FLTK version, e.g. #define FLTK_ABI_VERSION 010300 for FLTK 1.3.0. This way, new features could be enabled by defining the macro to have the value 010302 to enable features introduced in FLTK 1.3.2. I see, hmm, sounds like a neat option. Not sure if it might somehow create strange incompatibilties if a user pulls 1.3.2 but only enables 1.3.0 ABI features. A 1.3.0 feature might have been modified in 1.3.1 to track features added in 1.3.1, so unless the 1.3.0 macro is modified to 1.3.1, it would break. As a dev, I'd kinda expect if someone pulls 1.3.2 and enables ABI features, they'd get /all/ features to date for that stream, so that there are no interdependency issues between ABI features. The sources would then need something like this #if FLTK_ABI_VERSION = 010302 ... #endif This way, code ported to FLTK 3.0 would automatically enable all FLTK 1.3.x features left in the code with these macros. Interesting. As long as it doesn't create weird interdependency issues it should be OK. Not sure. So then inside the normal src/Fl_Tree.cxx there would be: #ifdef FLTK_ABI_FEATURE #include ABI_FEATURES/Fl_Tree.cxx #else [contents of normal file here] #endif /*ABI_FEATURE*/ So I imagine with this arrangement, when FLTK bumps its ABI version, it's clear to the devs what to clean up; the #ifdef's are removed, the feature file is merged into the normal file, and the feature file would be removed. Or something like that. Hmm, for really large changes and additions, this might be a way to go, but for small code changes, duplicating entire files would probable be a maintaining nightmare. Fixes to ABI-independent code parts would have to be duplicated etc.. Although I can see your point here very well. Right; the dev would just use #ifdef's within single code unless it gets too ugly to manage, and only then fall back to making separate file copies if absolutely needed. This may have some interesting implications for doxygen, perhaps some discussion is needed on that. Yep, one more point to leave all changes in one file, maybe. Doxygen has one directive \since that could be interesting here. Good.. This all might help solve two common issues we've had in the past: o Not being able to add ABI breaking features we want o Forgetting to add ABI breaking stuff when we bump the ABI version Agreed. However, not to forget: testing and bug reporting and fixing could become interesting, since we must also know the ABI version the reporter used for his special case. And dev's might need to check their changes against different ABI versions... Right. Hopefully it's a very rare case where ABI changes would affect other widgets, since even ABI changes should still be /API/ compatible. In a case where an ABI feature might affect other widgets, that might be a good reason to do what we do now; defer
Re: [fltk.general] fl_browser scroll problem
If having more lines that the browser can display, the scrollbar is shown. Using the scrollbar does not allow to scroll down all the way to the bottom. I think I found the culprit. After loading my list I change the text font size. This obviously effects the scroll bar length. Which then prevent from scrolling to the bottom. (both via scrollbar and as well programmatically). Is there a way to adjust that? I want to change the font size when going fullscreen and back mattes ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] openSuse 12.1
On Fri, 06 Jan 2012 04:16:06 -0800, Ian MacArthur imacart...@gmail.com wrote: On 6 Jan 2012, at 08:33, Richard Sanders lnr...@gmail.com wrote: I have just done a clean install of Suse 12.1 on a 32 bit box. I compiled fltk-1.3.x-r9217 and then compiled a finished project that runs on XP and Suse 11.3 (64 bit), On the Suse 12.1 I get predictable crashes. I compiled fltk-1.3.x-r8695 and fltk-1.3.x-r9187 with the same predictable results. There seems to be something broken with Suse 12.1, beware. Richard, Summarising your post, you are reporting that Suse 11.3 is OK in 64-bit builds, but that Suse 12.1 is broken in 32-bit builds; is that correct? Can you detail the crash behaviour, i.e. what triggers it, etc... Better yet, run it through gdb to see if that tell's us where the crash originates (though might need to clean and rebuild the FLTK libs with debug enabled to get enough details...) We can't preclude that we might be doing something wrong and in any case it would be useful to understand what causes the crash... FWIW, I only seem to have 32-bit Linux boxes right now and all work fine - though I don't have any Suse boxes, only ubuntu and fedora. I checked the GCC versions. Suse 12.1 has gone up to 4.6 while the previous versions were 4.5. I installed Suse 12.1 on a spare drive and hunted down GCC 4.5 rather than the default install of 4.6. In short, no crashes. Either GCC 4.6 is buggered or my install is. I will try un installing GCC 4.6 tomorrow and then re install and see what that does. I did hunt down the crash points and note the file name and line number but it is a bit premature to be looking at FLTK for errors. A second opinion on GCC 4.6 might be in order. A note on suse 12.1. The XFCE in rather nice neither spartan nor bloated out like the Mint Linux XFCE. Xununtu did not like my raid card when it came to the point of writing GRUB. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Clickable URLs in text
On Fri, 06 Jan 2012 13:52:25 -0800, Ian MacArthur imacart...@gmail.com wrote: On 6 Jan 2012, at 13:55, Albrecht Schlosser ajs856s...@go4more.de wrote: On 06.01.2012 01:01, Johan R wrote: I am using fltk 1.3 and have searched for how to make clickable links in e.g. Fl_Text_Display but havent found anything. Is there a way to make clickable links in text ? No, there's no way, at least not in Fl_Text_Display. The only widget supporting clickable links I know about is Fl_Help_View, a somewhat limited HTML display widget. Maybe this is what you need. Otherwise, you'd have to derive your own widget(s) to allow clickable links. I'm thinking of deriving from Fl_Box to make the label inside the box clickable. You may need to make your own draw() method (or maybe not), and you can do highlighting when the cursor is over the link. However, this needs some programming in the handle() method of the derived widget. If you need more help on this, please describe better what you want to do, maybe we can then find a better way to achieve it. There were some add-on widget sets (I'm thinking of FLU maybe Matt's FL_MM stuff) that provided buttons that appeared as clickable links but, as Albrecht said, I think the only widget we have for doing this in body-text is the help_view. As an aside, once you have your link working, the fl_open_uri() functions might be useful - or not, depending on what you really want to do! I just did a quick and dirty test on Fl_Button, just set button-box(FL_NO_BOX); and also the callback to . ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
