Does FLTK have a stacked widget?

[Mark]

I need a widget that manages a collection of one or more other widgets ("pages") just like a Tab widget does: but with no tabs. The reason for no tabs is because this widget is tall and narrow with about 8 "pages", so I want to provide navigation using a combobox (i.e., a Choice widget) above it rather than having tabs.

Thanks.

[Matthias Melcher]

Yes, Fl_Wizard. Sorry, no link as I am writing this on my phone.

[Albrecht Schlosser]

On  2/7/23 14:53 'Matthias Melcher' via fltk.general wrote:

Yes, Fl_Wizard. Sorry, no link as I am writing this on my phone.

https://www.fltk.org/doc-1.4/classFl__Wizard.html

Fl_Wizard allows "navigation" step by step backward and forward and to the first and last "page" which may or may not be sufficient for the OP.

Fl_Wizard is shown in the test/tabs demo program side by side with the Fl_Tabs widget.

@Mark: if you need to implement your own widget, this shouldn't be too difficult. The basics are as in Fl_Tabs or Fl_Wizard: derive from Fl_Group, add several Fl_Group container widgets in the same place and hide() all but the one you want to show(). Whenever you change the view, call redraw() on the container widget.

[Mark]

Thanks for that. But unfortunately the wizard isn't what I want.

Thanks for the tip about deriving a custom widget from Group; I'll have to read up on the fltk-rs (Rust binding) docs to see how to do that.

[Greg Ercolano]

On 2/7/23 05:47, 'Mark' via fltk.general wrote:

I need a widget that manages a collection of one or more other widgets ("pages") just like a Tab widget does: but with no tabs. The reason for no tabs is because this widget is tall and narrow with about 8 "pages", so I want to provide navigation using a combobox (i.e., a Choice widget) above it rather than having tabs.

    Derive a parent class from Fl_Group that's called "pages". Inside that class
    add your Fl_Choice widget (e.g. at the top), and below that, for the rest of the space,
    create another Fl_Group child called 'pages' that will contain all the page content.

    If the pages are literally text, you can probably get away with just making that
    'pages' group a single instance of Fl_Text_Display, and when the Fl_Choice is changed,
    just set the display's text content to the apropriate page content.

    Or, if the pages each have different widgets in them, make each page a separate
    Fl_Group (or a class derived from Fl_Group) that contains the widgets of each page.
    Set the position of all those groups in the SAME position, and hide() all the ones except
    the one to be shown using show(). And whenever Fl_Choice is changed, just hide() all
    the children except the one to be shown, and call pages->redraw() to update the screen.

[Matthias Melcher]

You can show a child directly by calling value(), or if you only know the index of the child, by calling value(child(3)). 

[Mark]

Thank you -- I'll try the "pages" - group approach.

[imm]

I'm late to this, and don't have much of use to offer anyway...
I'm not clear what a "stacked" widget would be, TBH, is that a thing
that everyone knows that I just missed?

Anyway, I think it sounds like a tab widget sort of deal, but without
the tabs showing - now, I have a vague recollection that with the FLTK
tab widget, if you set the tab the same height as the container, you
don't actually get the tabs... So that might be the "Right Thing" in
this case?

Could be worth a shot at any rate!

[Greg Ercolano]

On 2/8/23 10:12, imm wrote:

I'm late to this, and don't have much of use to offer anyway...
I'm not clear what a "stacked" widget would be, TBH, is that a thing
that everyone knows that I just missed?

    The term "stacked widget" comes up pretty quick as a Qt thing:
    https://doc.qt.io/qt-6/qstackedwidget.html

    """
    The QStackedWidget class provides a stack of widgets
    where only one widget is visible at a time.
    """

    So a bunch of widgets arranged on the Z-axis, only one ever
    on at once.

    This is pretty much what Fl_Wizard is; groups stacked on top of
    each other, and the screens can be switched around with application
    calls to the relative movement back() and next() methods,
    or in the OP's case, the value() method could be used  to directly
    show a particular groups.

    I would have recommended Fl_Wizard, but the implementation
    of selecting one-of-n children is pretty trivial to implement, which
    is why I recommended that technique.

    If it wasn't, I'd have recommended the OP re-investigate Fl_Wizard,
    as tying the Fl_Choice to the Fl_Wizard::value() method.

[Mark]

QStackedWidget was what I had in mind since I'm porting an application from Python/Qt4 to Rust/FLTK and want to keep the UI the same if possible so that existing users won't have to change habits or learn anything new when they upgrade.

I discovered by accident that the tabs don't show if you don't leave room for them (as a previous poster said in different words), although returning to my test code I now can't reproduce this.

In the end I just tried it using tabs and what I found was that because of the narrowness it only showed one tab's text. However, it is still perfectly navigable by keyboard or by clicking, so I'm going to stick with it. My test example is shown showing the first, second, and sixth test tabs:

[Matthias Melcher]

Two notes: I looked at QStackedWidget and saw that the API was pretty similar, and functionally the same. But maybe I missed something? Or is there a different behaviour in the widget itself? Arrow keys? I'd love to know how to update Fl_Wizard (silly name, I know) to do what QStackedWidget does.

As for the tabs, current FLTK 1.4 master has probably no propagated to the RUST binder yet, but 1.4 Fl_Tabs has an API where you can choose a pulldown menu if there are more tabs than can be displayed. Maybe that helps with your app?

See Fl_Tabs::handle_overflow() https://fltk.gitlab.io/fltk/classFl__Tabs.html#a9f6136aad01a797b16638223672ae675

[Mark]

Thanks. I've added a feature request to fltk-rs to add the handle_overflow() method.

As for QStackedWidget, it provides _no_ navigation at all. That must be provided by whatever means the programmer prefers, e.g., a combobox (Choice) or list box (browser). It used to be that Qt's QTabWidget was a QStackedWidget subclass that added the tabs.

[Mark]

Just to let you know that Mo added support for Tabs::handle_overflow() in fltk-rs. I tried all the options and found Pulldown does just what I need.

[Matthias Melcher]

Hooray OpenSource. Thanks for letting us know.