Re: [fltk.development] Comments about the branch1.3-composite
Michael Sweet wrote: Greg Ercolano wrote: Albrecht Schlosser wrote: because now the children() widget count would _not_ anymore count the 2 scrollbars if I understood his CHANGES.composite and related topics where he talks about now having to adapt existing code with children-2() offset change. Is 1.3.x supposed to break existing apps? A while ago it sounded like 1.3.0 was going to be the time to implement long pending ABI-breaking fixes, large scale mods like utf8. I wasn't aware we were also going for code breaking mods in this release. What's the general definition of what 1.3 will be bringing? I'd say the goal is to avoid breaking things unnecessarily, but there might be some side-effects of design changes (UTF-8, this Fl_Scroll stuff) which may require small code changes. Yes, both of them break my code, but I know that, and I think that we should document these minor changes. That's why I started that new chapter Migrating Code from FLTK 1.1 to 1.3. It's still empty, however, but the Fl_Scroll stuff should go there (what we have already is Fl_Scroll::scroll_to() instead of the ambiguous position(). That said, I don't know how much existing code exists that tries to directly manipulate the child() array of a Fl_Scroll widget. AFAICS, the only documented behavior is that of Fl_Group, but the child handling methods don't work as one should expect from Fl_Group's documentation. And the internal fix_scrollbar_order() was not called after add()ing children, or using some other documented method like insert(), but only when drawing or handling events. As Stan said: We should get rid of this undocumented and undefined behavior. And, since it's not documented, we wouldn't break contracts, as Greg said some time ago (IIRC). Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fluid supporting Doxygen (SVN 6291)
[...], so I decided to add Doxygen support as a feature. Check out
the current SVN. Opening the function, class, or declaration panel,
you will find a new field for comments. Just type something and it
will be placed (hopefully correctly) in the source or header file.
As a reminder, the first line is repeated in the browser.
The code is mostly untested, so please feel free to comment, and if
this feature is not liked, I'll be happy to reverse the patch :-)
I've been working through the doxygen warnings so that there are no
undocumented warnings that will hide real problems, and had just got
to Fl_File_Chooser. However, Fl_File_Chooser.[H,cxx] are generated
by fluid, so Fabien has added the doxygen comments to the additional
Fl_File_Chooser2.cxx file. There were warnings about various static
members (e.g add_favorites_label, add_files_label, etc) but try as I
might last night, I couldn't get doxygen to recognise more than one
of them at a time.
I've just experimented with the new, improved fluid and was able to
add the doxygen comments for these static member variables, and then
to generate the html with some test text (may be changed by the user).
One comment: on my first attempt I typed in the full doxygen comment
with delimiters (i.e. /** may be changed by the user */ and of course
fluid enclosed this within extra /** and */. So could you change the
tooltip to add (/** and */ will be added) or strip /** and */ from
the comment text if needed?
Earlier this summer I experimented with adding doxygen comments using
the normal fluid comment feature, and found that the code generation
doesn't always output the comments in the places where doxygen expects.
This new doxygen comment feature looks much more promising and is a lot
less awkward to use than New {Class, Function, Declaration} followed by
New Comment, and then a lot of F2/F3 to move it in front of where it
was needed.
Cheers
D,
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Comments about the branch1.3-composite
Michael Sweet wrote:
Greg Ercolano wrote:
Is 1.3.x supposed to break existing apps?
I'd say the goal is to avoid breaking things unnecessarily, but
there might be some side-effects of design changes (UTF-8, this
Fl_Scroll stuff) which may require small code changes.
That said, I don't know how much existing code exists that tries to
directly manipulate the child() array of a Fl_Scroll widget.
Fl_Table does, so I assume it's not a small number.
I'd think any widget deriving from Fl_Scroll that wants
to do anything with children of the group has to know about
skipping over the scrollbars.
And a widget that wants to hide the 'specifics' of Fl_Scroll
underneath has to do things like:
int children() const
{ return(table-children()-2); }// -2: skip Fl_Scroll's h/v
scrollbar widgets
This could break a lot of existing extension libraries and
apps as well.
Many of the extension libs are no longer maintained, so breaking
them would really crimp acceptance of newer fltk releases I think.
It creates a situation where app programmers can 'boxed in' to old
releases; I need utf8, but I also need Fl_SomeExtension which
doesn't support 1.3.x yet..
I'm -1 on modifying base widgets in a way that breaks old apps
for compiling purposes if at all possible.
Can I suggest if API changes are made that affect existing code,
to derive a new widget (eg. Fl_Scroll2, Fl_Scroll_Ex..) or some such?
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Comments about the branch1.3-composite
Greg Ercolano wrote:
Greg Ercolano wrote:
Can I suggest if API changes are made that affect existing code,
to derive a new widget (eg. Fl_Scroll2, Fl_Scroll_Ex..) or some such?
-1 from me, because this would mean that all the actively maintained
code would have to be changed to get the improvements and bug fixes. But
see below ...
I'm just concerned that unmodified old apps will still compile OK,
but will behave strangely. Would be good if we could discuss ways
to avoid this, if possible.
This is also a point for Fl_Scroll::scroll_to(). The change fixes bad
behavior (or should I say properties?) of FLTK, but it breaks existing
code (mine, for example). In fact everybody's code who used
Fl_Scroll::position(int x, int y) to change the scrolling (and not the
widget's) position.
As Stan said: We should get rid of this undocumented and undefined behavior.
And, since it's not documented, we wouldn't break contracts, as Greg
said some time ago (IIRC).
Heh, it's true this behavior is undocumented, so /technically/ it's
not breaking contract to make the change.
However, the fact it's undocumented in this case I think has more to do
with it being a doc omission, likely because the fltk documentation style
is not to document methods for base widgets in high level widgets *unless*
the methods are overridden. Here the methods aren't overridden, but
paradoxically behave differently in Fl_Scroll due to the widget's
internals.
Yes, this is really a bug. This could have been fixed by subtracting 2
from the internal value of the children() method
int Fl_Scroll::children() { return Fl_Group::children()-2; }.
And if the scrollbars would have been sorted to the end after each
modification of the children array (they did _not_, you would have had
to call (re)draw() or resize() first), then nobody would have had to
care ...
In truth, I think anyone that's ever had to use child() and children()
in the context of Fl_Scroll /had/ to encounter this and code around,
either by RTSL or by asking the group and getting an answer of
'yes, you have to skip the scrollbars..'. It's certainly been asked
and answered on the group enough to be considered 'documented'.
Yes, I don't know how I found it, but I new it too. ;-)
To my knowledge, this is the first time fltk will have made a change
to a base level widget, so I think it wise to at least carefully
consider options that avoid silently breaking old code if possible.
I'm not dead set against the improvement, I just think some discussion
about if there's a way to make such a change while minimally impacting
old code would be a worthy exercise.
I can imagine to have a compatibility mode (#define
FLTK_1_1_COMPATIBILITY) that adds 2 to the children() method. That would
be easy :-) But then, if someone used code like
Fl_Scrollbar *my_hscrollbar = scroll-child(scroll-children()-1);
we couldn't help ;-)
Adding the old Fl_Scroll::position(int,int) method would be a simple
inliner in Fl_Scroll.H.
Could this be what you want?
But I don't think that having utf-8 doesn't affect anybody's code. In my
german language code there are lots of german Umlauts (äöüÄÖÜ) and the
sharp s (ß) that don't display correctly now with FLTK 1.3 (they are
ISO-8859-1 encoded). Although I think that I read that they should be
recognized and translated automagically, but maybe I'm wrong. Adding
conversion functions or translating the character constants to utf-8
would be my other options. And I didn't think about input characters yet...
BTW: Nothing has been decided yet, but I would really, really hope that
we decide to fix this. And it is good that we discuss this now - that
was one of the reasons why I wrote it in my CHANGES.branch file that
Fabien cited.
Albrecht
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
