Different design: more compact windows and collapsing/closing control on each tab bar

[micfong-z]

Resolves #238. See the issue for a full discussion of this design.

Here's a list of technically missing features in this PR, but I'd like to hear some opinions before carrying on ;)

• Proper styling (especially rounding)
  • After careful checking of the design, this should be done on the user side.
• Dragging tabs to an empty space on the main surface (fd805c9, ccce02f)
• Dragging tabs to a collapsed Leaf (fd805c9, ccce02f)
• Proper CHANGELOG (370e477)
• Update examples (6e56846)

[micfong-z]

This should be feature-complete and bug-free AFAIK.

[Adanos020]

Hi, sorry for the massive delay! My irl stuff has been insane in the last couple of months.

I think the features you've added are great, although I think having a button that lets you collapse a whole window (which we lost in this PR) would be really nice to have. Can we add it back?

I've fixed up a few things following the release of 0.13 and rebasing to the next release branch. Let me know if there's anything I could help you with.

[micfong-z]

I think having a button that lets you collapse a whole window (which we lost in this PR) would be really nice to have.

I'd be glad to add this feature, but I'm not fully certain how this should be designed. Should collapsing a whole window be:

• a shortcut that simply collapses all leaf subnodes (i.e. the collapsed window may still have multiple tab bars), or
• a feature that turns the window into a dedicated state that only have a single line (so really compact)?
  • if this is preferred, what should be displayed on the single line? Active node name like the original design, or just a simple count label like "3 tabs, 2 leafs", or anything better?

[micfong-z]

@Adanos020 I've implemented this feature like this:

Recording.at.2024-07-10.01.04.44.mp4

So essentially all features available in the original design is now in the right-click context menu of the relevant buttons.

I named this feature minimizing a window, to avoid frequent confusions with collapsing a node in the codebase. Let me know if there's a better way to name this ;)

[Adanos020]

@micfong-z This looks good, although it isn't immediately obvious that you can right-click on the buttons. I reckon a tooltip on each button could help with that.

[micfong-z]

@Adanos020 Done – I've also fixed cargo test. I reckon another design of activating these features by shift-clicking (or ctrl/alt/...-clicking?) the buttons might be possible, but I'm not really sure if this applies well to different keyboard layouts, or* if this is even more obscured.

*: I just checked the way how egui handles modifier keys. This shouldn't be a problem now.

[Adanos020]

That sounds good, I'd say let's come up with a few designs and let the library users choose.

One design I've been thinking of is to have separate buttons for windows, but make them look like little bookmarks behind the window (or the tab bar) that'll pull out when you hover over them. How does that sound?

[micfong-z]

That design sounds brilliant! Though I would have to dig deep enough to figure out a way to display some sort of floating panels behind windows. AFAIK, since all Areas in egui are rectangular, these floating panels may mean introducing two auxiliary windows for each window.... I'll give it a try anyways :/

Edit: could tooltip/menu implementations help?