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
[..]
>
> That said, I don't know how much existing code exists that tries to
> directly manipulate the child() array of a Fl_Scroll widget.
I'm sure there's some code (mine) that depends on there being
children() - 2 "real" children. I'd be more than happy
to get rid of it; hopefully other users f
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.
>
>
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 e
> Johannes Hofmann wrote:
> > Albrecht Schlosser <[EMAIL PROTECTED]> wrote:
> >> Johannes Hofmann wrote:
> >>> I always wondered why current Fl_Scroll functionality is not implemented
> >>> in two classes both deriving from Fl_Group.
I guess what Johanes tried to suggest is jut encapsulating 2 grou
Johannes Hofmann wrote:
> Albrecht Schlosser <[EMAIL PROTECTED]> wrote:
>> Johannes Hofmann wrote:
>>> I always wondered why current Fl_Scroll functionality is not implemented
>>> in two classes both deriving from Fl_Group.
>>> One class implements scrolling of child widgets and the other
>>> adds
Albrecht Schlosser <[EMAIL PROTECTED]> wrote:
> Johannes Hofmann wrote:
>>
>> I always wondered why current Fl_Scroll functionality is not implemented
>> in two classes both deriving from Fl_Group.
>> One class implements scrolling of child widgets and the other
>> adds scrollbars when needed.
>>
Johannes Hofmann wrote:
>
> I always wondered why current Fl_Scroll functionality is not implemented
> in two classes both deriving from Fl_Group.
> One class implements scrolling of child widgets and the other
> adds scrollbars when needed.
> The latter would have the first as a member and would
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2022
Version: 1.3-feature
Oops, it appears I forgot to upload the patch!
I have posted a patch that applies cleanly to 1.1.x-r6305.
Link: http://www.fltk.org/str.php?L2
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2022
Version: 1.3-feature
Link: http://www.fltk.org/str.php?L2022
Version: 1.3-feature--- FL/Fl_Chart.H.original 2008-09-16 04:26:22.0 -0300
+++ FL/Fl_Chart
Albrecht Schlosser <[EMAIL PROTECTED]> wrote:
> [-- text/plain, encoding 7bit, charset: ISO-8859-15, 84 lines --]
>
> Hi, All,
>
> I'm working on an internal redesign of Fl_Scroll and maybe later
> more widgets, and I'd like to get some developer comments on this.
>
> First, I didn't like the (I
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 w
> 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 c
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
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
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 c
>>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 ..
> 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_Wi
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 stru
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 st
> The basic Composite (in the Design Patterns sense) doesn't have
> this distinction. A component is either a composite with children,
> or it is a leaf. We really need a modified composite with "fixed"
> children and "optional" children.
Even the basic Composite does not prevent you to add childre
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 t
On 21.09.2008, at 22:04, Fabien Costantini wrote:
>> This could easily be done (it's HTML), but Fabien wanted to save
>> space.
>> Houston, we've got a problem! ;-)
>>
>> Albrecht
> I believe it is already not bad if we have this navigation only
> once in a page as we never had before and 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 th
> 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
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 inc
26 matches
Mail list logo
