Why doesn't FLTK provide access to a widget Tree?

[Webb Hinton]

Just wondering, why doesn't FLTK provide access to a global widget tree? Behind the scenes, does FLTK not use a tree like structure to represent the relationship between widgets, in  a fashion similar to HTML?

A simple widget tree for an FLTK app might look like: 

________________________________

        Window

            /     \

    Group     Group 

       /\                 \

Button Button   Button

________________________________

Wouldn't it be great to have access to the FL_Tree functions like root(), insert_above(), set_root(), prev(), next(), etc for all of our widgets?

For example,  what if we wanted to make a Photoshop-style layer panel, a UI feature well suited to represent widgets in a tree data structure:

          Container

            /    \

       Layer    Group

                       /  \

                   Layer  Layer

As things stand, we have to wrap widgets inside of a custom tree structure that we provide. But if behind the scenes FLTK already has some kind of tree like representation of widgets, why not let users leverage this?

    

[Ian MacArthur]

On 10 Jun 2021, at 20:10, Webb Hinton wrote:
>
> Just wondering, why doesn't FLTK provide access to a global widget tree? Behind the scenes, does FLTK not use a tree like structure to represent the relationship between widgets, in a fashion similar to HTML?

I think your intuition about how fltk works may be missing the mark, that’s not really how it is done at all.

[Phil]

Hi Webb,

The F and L refer to Fast and Light. So stuff like you are asking for is an overhead most users might not want. It should be easy enough for you to implement that if you want.

Regards Phil.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/b93d7d20-db4e-4695-8898-aa2bb73a8b02n%40googlegroups.com.

[Webb Hinton]

> I think your intuition about how fltk works may be missing the mark, that’s not really how it is done at all.

Understood, coming from a Web Dev environment, and given the various parent() and child() functions available to our FL::Group widgets, I assumed that behind the scenes some sort of tree structure was managing these relationships. If this is not how it works, then what kind of system FLTK use to keep track of parent/child relationships?

[Ian MacArthur]

On 10 Jun 2021, at 21:54, Webb Hinton wrote:
>
> > I think your intuition about how fltk works may be missing the mark, that’s not really how it is done at all.
>
> Understood, coming from a Web Dev environment, and given the various parent() and child() functions available to our FL::Group widgets, I assumed that behind the scenes some sort of tree structure was managing these relationships. If this is not how it works, then what kind of system FLTK use to keep track of parent/child relationships?

There’s no “master list” anywhere - widgets know who their current parent is and container widgets (groups, windows) know who their current immediate children are (but not their children’s children.) A widget can move from one parent to another pretty much at will.
That’s basically it. That’s about all you need.

[Albrecht Schlosser]

On 6/10/21 10:54 PM Webb Hinton wrote:

> I think your intuition about how fltk works may be missing the mark, that’s not really how it is done at all.

Not really ... exactly ... but very similar, isn't it? At least for single windows.

Understood, coming from a Web Dev environment, and given the various parent() and child() functions available to our FL::Group widgets, I assumed that behind the scenes some sort of tree structure was managing these relationships. If this is not how it works, then what kind of system FLTK use to keep track of parent/child relationships?

There's not one complete tree structure, but for each Fl_Group (derived) widget there is an array of children, and a Fl_Group widget may have a parent() with an Fl_Window as the top-most parent. However, ...

On Thursday, June 10, 2021 at 4:19:42 PM UTC-4 pvr...@btinternet.com wrote:

Hi Webb,

The F and L refer to Fast and Light. So stuff like you are asking for is an overhead most users might not want. It should be easy enough for you to implement that if you want.

That's true, it is basically all there and ...

On 10 Jun 2021 20:10, Webb Hinton <caroli...@gmail.com> wrote:

Just wondering, why doesn't FLTK provide access to a global widget tree? Behind the scenes, does FLTK not use a tree like structure to represent the relationship between widgets, in  a fashion similar to HTML?

A simple widget tree for an FLTK app might look like:

That tree is not for a complete FLTK app, but for a single Fl_Window, yes.

________________________________

        Window

            /     \

    Group     Group 

       /\                 \

Button Button   Button

________________________________

Wouldn't it be great to have access to the FL_Tree functions like root(), insert_above(), set_root(), prev(), next(), etc for all of our widgets?

As Ian wrote, there's no "master" tree, widgets are independent and can be moved around and there can be lots of independent (or dependent) windows coming and going (like menu windows) etc..

PS: please don't top-post, it's hard to comment several different replies in this order.
https://en.wikipedia.org/wiki/Posting_style#Top-posting

[Bill Spitzak]

FLTK certainly uses a list of children and parent pointers just like any other tree representation. As stated above this system puts the "roots" at the level of the outermose Fl_Window objects.

It also knows about all the currently-shown windows in an internal list, I don't remember if that list is available, and there was some work done on making whether a window that was hidden or removed being in this list system-dependent. A window you create and then do nothing with will not be part of any internal tree, it will be it's own independent tree.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/7a8032db-2f7e-ccdb-d8f0-e9e1630d558b%40online.de.

[janezz55]

Get the root node with top_window() and then follow the hierarchy from there with children(), child() and as_group().

[Matthias Melcher]

Fl::first_window() returns the topmost visible window in the app. Fl::next_window(Fl_Wndow*) will return the next visible window that is below the givin window. Calling show() on a window will add it to the list. If hide() is called, the window is removed again. After that, you can walk the tree using the child()/children() methods on all widgets that return non-null for as_group() . In the end, that just is your tree structure. The Fl_Tree widget uses a different setup internally to make life easier for text-only children, but in the end, yes, the UI is just a tree. Other notable API exceptions are Fl_Menu_Item (a list that acts as a tree, for historic reasons), and Fl_Table for the same reasons as Fl_Tree.

FLTK 1.4.0: Windows handling functions

FLTK 1.4.0: Fl_Group Class Reference

FLTK 1.4.0: Fl_Widget Class Reference 

This is always available from within the app. Making the data available to the outside would be a huge security risk(*), but nothing keeps you from having a script interface within your app and give external apps access. 

(*) imagine external apps changing the UI so that a dialog "Overwrite this file: yes, no" simply flips the "yes, no" labels, but keeps functionality the same - woopsie ;-)