There is a branch of fltk2 that does exactly this, however there was
some serious negative reaction so it was never put in the trunk. We
called it the Group/Widget merge.
As you suggest, the children count and array pointer were replaced with
a single pointer to a structure that is only
MacArthur, Ian (SELEX GALILEO, UK) wrote:
I'm not to bothered about Fl_Scroll, but this I do care about...
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
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
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
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
Fabien Costantini wrote:
A composite permits tree walking without having to distinguish groups from
leaves, the latter one having no child as the main difference.
As I wrote in the other thread, I think that this real composite
aspect is a major rewrite of FLTK and is not doable in the FLTK
Not a major rewrite at all, here is how it could work:
1. Get the children() tree handling api to Fl_Widget instead of Fl_Group.
2. Use an API like is_leaf() that will indicate if is terminal to the
external world or a group.
Is it hard ?
Maybe not.
Especially if we don't change
Fabien Costantini wrote:
Your need if I understood you is to get a private children feature.
IMHO this can simply be achieved by what you do now, i.e: your target parent
does
not now that you are its child
Well, it _does_ already know its private children ! :-)
Look at Fl_Scroll. It
AlbrechtS and Fabien discussion snipped.
I don't think this addresses Albrecht's current need to handle
events from outside the current group's boundaries, and maybe
it's too much of a change, but for future consideration...
Rather than using a Composite (in the Design Patterns sense)
would it
Duncan Gibson wrote:
AlbrechtS and Fabien discussion snipped.
I don't think this addresses Albrecht's current need to handle
events from outside the current group's boundaries, and maybe
it's too much of a change, but for future consideration...
Rather than using a Composite (in the
I wrote:
Rather than using a Composite (in the Design Patterns sense)
would it not be possible to extend the current children idea
so that there are actual children and adopted children.
Albrecht replied:
Yes, that's what my implementation does and what I tried to
describe in the other
Fabien Costantini wrote:
But even then, I reviewed recently the Fl_Group code and fortunately for us,
the internal attributes to handle children (array_,children_ and size_) are
all private ; so it could be quite easy to replace that 3 attributes
internally by only one pointer on a
To remove the Fl_Label structure and replace it with a pointer would save even
more space in Fl_Widget. In my app, there can be hundreds of widgets that
don't
have a label at all. This would be a great win!
Concerning that aspect, I totally agree.
If we would derive Fl_Label from Fl_Widget,
it won't create anything at initialization too so that if you don't need
labels at all, you keep a null pointer to that structure internally.
And it could also never create a widget style too like for the default buttons
we use in an app, provided that we can change the defaults but we can ...
Duncan wrote:
Maybe I have misunderstood, but this makes me uncomfortable.
You want to allow a user to create a widget that initially has no children,
but when the users adds X number of children and exceeds
the initial width or height of the widget, or a child resizes when
a font is
Duncan Gibson wrote:
AlbrechtS wrote:
BTW: Fl_Scroll could also be changed to allocate the scrollbars only
when needed, and thus could be much smaller, if there are no scrollbars
(the default when it is created or all widgets fit into it). The next
step would be that every widget can also
The only problem would be, as Fabien already mentioned, that every feature
added to the base class would increase its size.
Not every feature, on a per widget basis, only the new attributes,
and as Mike once pointed out : even new API may not increase the lib size if it
is not used, as most
Fabien Costantini wrote:
Duncan wrote:
Maybe I have misunderstood, but this makes me uncomfortable.
You want to allow a user to create a widget that initially has no children,
but when the users adds X number of children and exceeds
the initial width or height of the widget, or a child
Fabien Costantini wrote:
To remove the Fl_Label structure and replace it with a pointer would save
even
more space in Fl_Widget. In my app, there can be hundreds of widgets that
don't
have a label at all. This would be a great win!
Concerning that aspect, I totally agree.
If we would
Fabien Costantini wrote:
IMHO, it would be nice to split these modifications in two branches like
branch-1.3-scroll and branch-1.3-composite.
As I said, I easily agree with the scroll changes, but the composite widget
aspect is just something else.
We *do* agree here, but I think that my
A composite permits tree walking without having to distinguish groups from
leaves, the latter one having no child as the main difference.
As I wrote in the other thread, I think that this real composite
aspect is a major rewrite of FLTK and is not doable in the FLTK 1.3 time
frame. It
21 matches
Mail list logo
