On 13.12.2010, at 20:11, Greg Ercolano wrote:
> Domingo Alvarez Duarte wrote:
>> Here you are pointing one of problems of Fl_Tabs "Guess work", When adding
>> a group to Fl_Tabs the label of the group isn't adapted to the labelsize
>> of Fl_Tabs resulting in strange tabs.
>
> I see, this is handy.
>
> So the proposed client_area() makes it easier to procedurally
> create the child groups without having to mentally calculate
> their sizes, and hard code 'magic numbers' for the group's XYWH. eg:
>
> Fl_Tab *tab = new Fl_Tab(20,20,400,350);
>
> // Create child groups based on client_area()'s return values
> int X,Y,W,H; tab->client_area(X,Y,W,H);
> Fl_Group *g1 = new Fl_Group(X,Y,W,H,"Tab 1"); // no magic numbers for
> xywh
> Fl_Group *g2 = new Fl_Group(X,Y,W,H,"Tab 2"); // no magic numbers for
> xywh
>
> I tried this, and this works nicely..
>
> Except: client_area() uses Fl_Tabs::labelsize() to do its calculations
> when no children exist yet.
>
> Trouble is, Fl_Tabs::labelsize() has nothing to do with the size of the
> tab's labels; each child's labelsize() is what defines each tab's label
> size.
>
> If the child group's label sizes are different, then client_area()
> won't give a correct answer.
I also have used Fl_Tabs with labels that cover two lines of text...
> However, if it accepted an optional font size, then the app
> could pass the maximum font size for more accurate xywh values.
All good points, I also wanted to add a similar comment. I may add that
adding the BORDER offsets seems to be wrong: either they must be
calculated by using the appropriate box type, or (much better) they
must be omitted. According to the docs, the x() and w() of each child
should be the same as that of Fl_Tabs. AFAICT the reason is that you
would otherwise get unwanted resize behavior (unless you set a
resizable()).
> +1 for adding this method, or something like it.
> I'd suggest changing the name of the parameter "top_if_first"
> to "tabs_on_top", which I think might be clearer.
I suggest renaming the parameter "tab_height". It may have these
values:
0 = default (tabs at the top, default label size)
-1 = tabs at bottom, default label size
> 0 = user-defined tab height (top)
<-1 = user-defined tab height (bottom)
Also, this should /always/ only be used if the /first/ child is
added. Otherwise the calculated value tab_height() /should/ be
used, or we could return the values of the first child (group),
because all groups should be exactly of the same sizes. This
would avoid another problem of different children sizes that is
often reported.
Note(OT): We could even offer a method that automatically resizes
a child when add()ed to the Fl_Tabs widget, but this may not be
appropriate because of layout reasons... (just a thought, not
a final suggestion).
> Here's a small test program I used to play with client_area();
> (a modified version of the examples/tabs-simple)
> It currently shows the problem defined above (different sized
> child labels) which could be solved if client_area() accepted
> an optional size parameter. However, it works fine if the children
> label sizes are all the same (which is the more common case).
It would be nice if you could post your demo program to the STR,
so that we have it available for testing, but maybe you should wait
for Domingo's reply first. Maybe he'll update his patch ?
I'll add more comments to the STR later...
Albrecht
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
