Fl_Tabs

[holm.h...@gmail.com]

Hi,

When making my tabs, the by default appear in the upper left corner.

Is it possible to make them appear in the upper right corner ?

Best regards
Håvard

[imm]

On 14 May 2017 at 19:44, <holm.haavard> wrote:
>
>
> When making my tabs, the by default appear in the upper left corner.
>
> Is it possible to make them appear in the upper right corner ?

Hmm, I don't think we have that; you probably would need to derive
your own subclass to adjust the tab drawing.

Greg has some examples on his Cheat Sheet pages of using tab and
wizard widgets, so he might have something... Always worth a look at
any rate!

[holm.h...@gmail.com]

Ok, thank you for the answer. I will find a solution.

Håvard

[Albrecht Schlosser]

I may add: There are currently several related STR's that suggest
changes in Fl_Tabs to make deriving own classes easier and more
consistent (make some methods public or protected instead of private).
This is intended to be implemented in FLTK 1.4.0.

[Martin McDonough]

Please, this. Myself and several others have run into this while trying to make more advanced tab widgets (and have made STRs about it).

There are a number of method on Fl_Tabs which should really be protected, not private. Making your own tab widget right now requires either rewriting everything, copying the guts of Fl_Tabs, or modifying the source. It's not much fun.

[Greg Ercolano]

> On 05/14/17 15:50, Albrecht Schlosser wrote:
>> I may add: There are currently several related STR's that suggest
>> changes in Fl_Tabs to make deriving own classes easier and more
>> consistent (make some methods public or protected instead of private).
>> This is intended to be implemented in FLTK 1.4.0.

On 05/15/17 11:32, Martin McDonough wrote:
> Please, this. Myself and several others have run into this while
> trying to make more advanced tab widgets (and have made STRs about it).
>
> There are a number of method on Fl_Tabs which should really be
> protected, not private. Making your own tab widget right now
> requires either rewriting everything, copying the guts of Fl_Tabs,
> or modifying the source. It's not much fun.

I'm not sure, but I think there's been several submitted
alternative tab widgets either as standalone, or part of
other FLTK widget library addons.

We should probably eval those, as well as take recommendations
for features other toolkits offer for this type of widget.

FLTK's Fl_Tabs goes back to the original Forms (sgi gl librart)
and XForms origins, known in both toolkits as a 'tabfolder',
e.g. fl_add_tabfolder(). Ours is Bill's C++ port of it, IIRC.

Let's move this discussion over to fltk.coredev whether
to retool or re-implement a new tabs widget.

[Albrecht Schlosser]

On 15.05.2017 22:46 Greg Ercolano wrote:
>> On 05/14/17 15:50, Albrecht Schlosser wrote:
>>> I may add: There are currently several related STR's that suggest
>>> changes in Fl_Tabs to make deriving own classes easier and more
>>> consistent (make some methods public or protected instead of private).
>>> This is intended to be implemented in FLTK 1.4.0.
>
> On 05/15/17 11:32, Martin McDonough wrote:
>> Please, this. Myself and several others have run into this while
>> trying to make more advanced tab widgets (and have made STRs about it).
>>
>> There are a number of method on Fl_Tabs which should really be
>> protected, not private. Making your own tab widget right now
>> requires either rewriting everything, copying the guts of Fl_Tabs,
>> or modifying the source. It's not much fun.

I'm aware of this and prepared a commit for the patch proposed by Teklad
(STR #3211, file #7):
http://www.fltk.org/strfiles/3211/Fl_Tabs.H.patch

Sorry for the long delay; I'll commit this soon, after final testing.

> I'm not sure, but I think there's been several submitted
> alternative tab widgets either as standalone, or part of
> other FLTK widget library addons.
>
> We should probably eval those, as well as take recommendations
> for features other toolkits offer for this type of widget.

Martin, Greg, and others: I'm working on the proposed Fl_Tabs extensions
and I'll report progress ASAP.

> Let's move this discussion over to fltk.coredev whether
> to retool or re-implement a new tabs widget.

I'll open a thread in fltk.coredev if I need assistance for decisions on
how to proceed. Currently I'm evaluating different ways to integrate the
proposals.

I don't know yet how much of the given proposals can be integrated in
Fl_Tabs and which enhancements may require a new derived class...

[Martin McDonough]

In my patch, I originally did not inherit from Fl_Tabs. Later, on a suggestion I did change to inherit, and copied a number of methods right from Fl_Tabs.cxx with a note that they could be made protected and that then the copied versions could be deleted.

The STR is here: http://www.fltk.org/str.php?L3211 (I am the FlyingJester).

[Albrecht Schlosser]

On 16.05.2017 02:34 Martin McDonough wrote:
> In my patch, I originally did not inherit from Fl_Tabs. Later, on a
> suggestion I did change to inherit, and copied a number of methods right
> from Fl_Tabs.cxx with a note that they could be made protected and that
> then the copied versions could be deleted.
>
> The STR is here: http://www.fltk.org/str.php?L3211 (I am the FlyingJester).

Hi Martin,

please check my new posts to STR #3211 and svn r12243.

> Martin, Greg, and others: I'm working on the proposed Fl_Tabs
> extensions
> and I'll report progress ASAP.
>
> > Let's move this discussion over to fltk.coredev whether
> > to retool or re-implement a new tabs widget.
>
> I'll open a thread in fltk.coredev if I need assistance for
> decisions on
> how to proceed. Currently I'm evaluating different ways to integrate
> the
> proposals.
>
> I don't know yet how much of the given proposals can be integrated in
> Fl_Tabs and which enhancements may require a new derived class...

See also STR #3211 for my current thoughts and widget hierarchy model.
This may be changed as appropriate.

All further discussions about this should go to fltk.coredev, thread
"New Fl_Tabs widgets" (started today). Contributions and patches should
bo to STR #3211. Thanks.

http://www.fltk.org/str.php?L3211