I can't understand GLUI_TreePanel for the life of me. Anyone have a handle on it?

[m-7761]

Tonight I've nearly lost my mind looking at the GLUI_TreePanel code.

I just wanted to understand what the following methods are meant to achieve:

    /* Goes up one level, resets curr_root and curr_branch to parents*/
    void            fb(GLUI_Tree *branch= NULL);
    /* Deletes the curr_branch, goes up one level using fb */
    void            db(GLUI_Tree *branch = NULL);
    /* Finds the very last branch of curr_root, resets vars */
    void            descendBranch(GLUI_Panel *root = NULL);
    /* Resets curr_root and curr branch to TreePanel and lastChild */
    void            resetToRoot(GLUI_Panel *new_root = NULL);
    void            next();

If I didn't lose my mind, I lost my night! Since these methods are cryptic and camelCase, I wanted to change their names.... but I had to first figure out what they do. I'm still unconvinced they are well-formed.

Going by example6.cpp it's possible to arrive at some names. But going by the code it gets much stranger.

It's hard to see what the members curr_root and curr_branch actually represent. Sometimes it looks like the root is the selection, other times the parent. Sometimes it looks like the "branch" is maybe a bookmark, but not the selection. I have a feeling this code's never been used, or is left in an unfinished, untested state. Comments say it's unfinished, and is untraversable without locking the program.

I wonder what to make of it. I ran into trouble with it, because it has a next method, that replaces GLUI_Node::next and so I endeavored to find a new name for it. Before seeing the other names should be changed too, because what does "ab" or "fb" mean? and they don't use underscores like the rest. I think I fell into a trap. You win some, you lose some. I've never seen code quite like GLUI. It's a monument to something, but methodical, thoughtful it's not :)

EDITED: Sorry, I had omitted so many words in this comment. Maybe I hurt my brain (more than usual) tonight.

P.S. For what it's worth, db deletes curr_root and not "curr_branch". It's really hard to say what the others do. They are all very strange. I really don't recommend trying to figure them out. There's also ab:

    /* Adds branch to curr_root */
    GLUI_Tree *     ab(const char *name, GLUI_Tree *root = NULL);

A little easier to decipher. But still unusual for a method name. Though some old Standard Library classes have methods named like this. It's impossible to work with them without a manual on standby.

[nigels-com]

Going by the history, perhaps @baxissimo can remember or shed some light.

[baxissimo]

Ha! Fat chance. --bb

On Fri, Mar 15, 2019 at 4:25 AM Nigel Stewart notifications@github.com wrote:

Going by the history, perhaps @baxissimo https://github.com/baxissimo can remember or shed some light.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/libglui/glui/issues/93#issuecomment-473250775, or mute the thread https://github.com/notifications/unsubscribe-auth/AADmUxchjKK2voQeK5b-PLi3xQ8G-Uz9ks5vW4MOgaJpZM4b1zQt .

[m-7761]

After I have a better feel for the library, I will probably redesign the traversal methods, since they all have funny names/semantics. I've developed numerous tree graphs in my day, and they are very straightforward to work with. I don't want to be obnoxious, but my sense is the author was maybe having either a difficult time conceptualizing the tree data structure, or tried to design too clever methods, in order to keep the number down. They all have very strange side-effects, and at the very least they should have had some comments, in terms of intent, because they are so nonstandard.

I cannot even read the code to be honest. It looks like something obfuscation software generates. But many programmers write code like this, so I can't say. I don't know where they learn to write code like that. It's as-if they are trying to bang out as many words-per-minute like a secretary, without appreciating that code is something other programmers must read; that writing code is a job only done once; and often the writer must read their own code! Anyway, I'm unpacking the code, and the rest of GLUI's code. If you can't read it you cannot even audit it.

Below is tentative names. But I think the methods should probably be redesigned altogether. The terms "root" and "branch" are not used in their idiomatic senses. It's hard to tell what they mean, given that there aren't comments, and the code is scant.

    //2019: EVERYTHING ABOUT TreePanel IS STRANGE
    //
    // Changing camelCase names based on Example6
    // Don't rely on curr_branch... it goes weird
    // places. These methods are most inscrutable
    //  
    /* Goes up one level, resets curr_root and curr_branch to parents*/
    void go_up_tree(Panel *branch=NULL);    
    /* Finds the very last branch of curr_root, resets vars */
    void go_to_leaf(Panel *root=NULL);
    /* Resets curr_root and curr_branch to TreePanel and last_child */
    void go_to_root(Panel *new_root=NULL);
    void go_to_next();
    void refresh();

    void expand_all(),collapse_all();
    void update_all();

    /* Goes to curr_rroot; adds branch to curr_root */
    Tree *add_tree(const char *name, Tree *curr_root=NULL);

    /* Goes to curr_root; goes up one level; deletes/unlinks curr_root 
       NOTE: default argument is removed so it's more like delete_item
       and because the semantics are inconsistent across these methods
     */
    void delete_tree(Panel *curr_root/*=NULL*/);

They take Panel because the curr_root member is a Panel instead of a Tree. I just kept going over and over the code, thinking I would eventually have some insight, and it would make sense. But it doesn't.

[baxissimo]

What about https://github.com/ocornut/imgui ? GLUI was always kind of a mess internally and relying on GLUT seems kind of sad in 2019.

Doesn't look like that imgui has a tree widget, but writing one for them (or some other hot GL gui) seems like a better use of time to me than dealing someone's inscrutable GLUI tree code. But that's just, like, my opinion, man.

--bb

On Fri, Mar 15, 2019 at 12:02 PM Mick Pearson notifications@github.com wrote:

After I have a better feel for the library, I will probably redesign the traversal methods, since they all have funny names/semantics. I've developed numerous tree graphs in my day, and they are very straightforward to work with. I don't want to be obnoxious, but my sense is the author was maybe having either a difficult time conceptualizing the tree data structure, or tried to design too clever methods, in order to keep the number down. They all have very strange side-effects, and at the very least they should have had some comments, in terms of intent, because they are so nonstandard.

I cannot even read the code to be honest. It looks something obfuscation software generates. But many programmers write code like this, so I can't say. I don't know where they learn to write code like that. It's as-if they are trying to bang out as many words-per-minute like a secretary, without appreciating that code is something other programmers must read; that writing code is a job only done once; and often the writer must read their own code! Anyway, I'm unpacking the code, and the rest of GLUI's code. If you can't read it you cannot even audit it.

Below is tentative names. But I think the methods should probably be redesigned altogether. The terms "root" and "branch" are not used in their idiomatic senses. It's hard to tell what they mean, given that their are no comments, and the code is scant.

//2019: EVERYTHING ABOUT TreePanel IS STRANGE // // Changing camelCase names based on Example6 // Don't rely on curr_branch... it goes weird // places. These methods are most inscrutable //
/ Goes up one level, resets curr_root and curr_branch to parents/ void go_up_tree(Panel branch=NULL);
/ Finds the very last branch of curr_root, resets vars / void go_to_leaf(Panel root=NULL); / Resets curr_root and curr_branch to TreePanel and last_child / void go_to_root(Panel *new_root=NULL); void go_to_next(); void refresh();

void expand_all(),collapse_all(); void update_all();

/ Goes to curr_rroot; adds branch to curr_root / Tree add_tree(const char name, Tree *curr_root=NULL);

/ Goes to curr_root; goes up one level; deletes/unlinks curr_root NOTE: default argument is removed so it's more like delete_item and because the semantics are inconsistent across these methods / void delete_tree(Panel curr_root/=NULL*/);

They take Panel because the curr_root member is a Panel instead of a Tree. I just kept going over and over the code, thinking I would eventually have some insight, and it would make sense. But it doesn't.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/libglui/glui/issues/93#issuecomment-473406450, or mute the thread https://github.com/notifications/unsubscribe-auth/AADmUzNgOv5Pe2BKEU0Fu8TpPgZCcTBhks5vW-4wgaJpZM4b1zQt .

[nigels-com]

Indeed, Dear ImGui does appear to be progressing nicely, over the years. It also appears suitable for modern OpenGL (and maybe OpenGL ES). I might give it a spin on a Raspberry Pi sometime.

[m-7761]

If you're asking for my reply? I prefer GLUI because A) it looks like Windows 95. It's kind of an emulator in that regard; B) it's abandoned, and very basic. I'm looking to develop my own UI, so something with lots of baggage is not attractive to me. If you feel it's useless, that's all the better. Nigels was working to expand it with C++11 features (and making it impossible for me to develop it) in 2017.

I have many uses for it, and I think the new library I develop out of it may become quite popular. Or has the potential to. I'm interested in native windows/etc. and Win32 especially. I want a pure graphics option also. And Windows 95 is the first thing I would develop anyway for that. So because GLUI already looks like that, it saves me from getting down on my hands and knees to scrutinize every pixel in the classic Windows layouts. It's easier to adapt existing code. It gives your brain something to glom onto. Or it does mine. It lets you focus on the more important things.

[m-7761]

P.S. @baxissimo see https://github.com/libglui/glui/issues/91 that I gather (from your words) you haven't seen.

[nigels-com]

GLUI isn't abandoned. I still have other projects that use it. I'm interested more in fixing bugs than advancing the functionality. And I don't think there should be incompatible changes made, generally speaking.

[m-7761]

Well that's abandoned. But to the degree there's interest in it (I think it is interesting in principle) it would be better if it were better organized. It can be a teaching resource, as it's quite simple. But not as long as it looks like a tornado blew through it. There's probably room to improve it, but I would keep it simple myself, as GLUT is so. But simple and accessible/practical/functional are not the same. I think it could be improved a lot without adding functionality. Though too, I think it would benefit a lot from clipboard support, and that it should probably use the clipboard code I provided, on an opt-in basis for those who want it. (Still, I'm pulling it out of the new code I will submit, except for the main file. The original PR would need to be reviewed to reconstruct the changes outside the main file, mainly in terms of idle for X Even without X, the Windows clipboard doesn't require idle. It will marshal the value.)

[baxissimo]

Alrighty, that's all cool, just wanted to make sure you had a clear perspective on the situation. Seems like you do! --bb

On Fri, Mar 15, 2019 at 6:13 PM Mick Pearson notifications@github.com wrote:

If you're asking for my reply? I prefer GLUI because A) it looks like Windows 95. It's kind of an emulator in that regard; B) it's abandoned, and very basic. I'm looking to develop my own UI, so something with lots of baggage is not attractive to me. If you feel it's useless, that's all the better. Nigels was working to expand it with C++11 features (and making it impossible for me to develop it) in 2017.

I have have many uses for it, and I think the new library I develop out of it may become quite popular. Or has the potential to. I'm interested in native look & feel, and Win32 especially. I want a pure graphics option also. And Windows 95 is the first thing I would develop anyway for that. So because GLUI already looks like that, it saves me from having to get down on my hands and knees and scrutinize every pixel in the classic Windows chrome one by one. If you already have code, then it's easier to adapt than to develop from thin air. It gives your brain something to glom onto.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/libglui/glui/issues/93#issuecomment-473485129, or mute the thread https://github.com/notifications/unsubscribe-auth/AADmU3BFx5fCKf0gneu2dVxSxDTJ4Kqoks5vXEVQgaJpZM4b1zQt .