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?

[micfong-z]

Sorry for not being active on this PR recently due to ... irl stuff ( :( ) – but I think I've caught up a bit.

For now I have implemented the two options I've mentioned for the user to choose (modifier key method and context menu method), but I've been really struggling to get the bookmark button method done.

I have experimented with creating new Areas, tweaking Tooltips, or even creating auxiliary Windows, but all of them have issues with at least one of focusing, anchoring and layering. ChatGPT and Googling didn't help (of course), and the codebase and changelog is getting a bit messy.

I'd be happy to carry on experimenting if someone could give me some directions to work on. Nevertheless, this feature could probably be put in a separate PR instead considering its complexity.

@Adanos020 if creating a separate PR for this specific issue is okay, I'll go on finalizing/cleaning up the codebase then!

---

Edit: I'll layout the issues I've encountered so far.

• Area and Window (same thing under the hood): focusing and layering issues. I couldn't figure out a way to programmatically shift the auxiliary window holding the buttons to the layer "just after the window that has been hovered on", without a change to nearly everything. Anchoring went well.
• Tooltip: well firstly it appears above the window. Plus for some reason setting tooltip delay (ideally to 0) had no effect. Anchoring is also quite difficult in this case.

[Adanos020]

Hey, no worries at all, I've also been dealing with lots of personal issues because of which I didn't have much time to dedicate to this project. Thanks for coming back to this PR!

If the bookmark button is too big of a pain to implement, then I'd say let's drop it for now. We can make do with the current designs.

[micfong-z]

@Adanos020 Everything is good to go now (from my side), but I'll point out a few possible caveats

• the translation examples in lib.rs are translated from an online service, so no guarantee that they would be fully correct
• I used the term "leaf" for ... Leafs on user-side tooltips. Not sure if this would be confusing.

[Adanos020]

I think this is good to go! The machine translations aren't bad, I just made some changes for consistency's sake.

Thank you for working on this :)

[micfong-z]

Thanks for merging! A side note for consistency in JP translations: the lines ending with 。 (CN/JP full stop) are all tooltip texts, so keeping them at the end is more consistent with English/Polish translations.

However, as per Material Design Guidelines, the full stops should not follow single-sentence tooltip texts. Maybe remove all full stops in translations would be good.