[Problem] UI: MDI Selector & Status bar have unused space

C0deKirukkan commented 9 months ago

Is there an existing issue for this?

[X] I have searched the existing issues

Problem description

There is a lot of space being wasted on these two bars. The issue is exaggerated on my bigger screen, even on my smaller 24" 1080p screen there is a considerable amount of wasted space. From a UX/UI perspective, one can save quite a bit of vertical space by combining both the bars, and a lot of people are used to looking at the right bottom corner for their system tray/status. So, moving the contents of the status bar to The MDI selector bar, could make it easier to glance over the information. Example : The MDI Selector | Status Info | Navigation + Units Looking for ideas for handling lots of open tabs and long status messages. The number of tabs could be restricted based on screen size, and a chevron menu showing other open tabs could be added. Clipping of longer status messages can be done based on no. of characters, and onhover/onclick could show the full message in a tooltip.

Full version info

OS: Arch Linux (KDE/plasmawayland)
Word size of FreeCAD: 64-bit
Version: 0.21.1.33694 (Git) AppImage
Build type: Release
Branch: (HEAD detached at 0.21.1)
Hash: f6708547a9bb3f71a4aaade12109f511a72c207c
Python 3.10.12, Qt 5.15.8, Coin 4.0.0, Vtk 9.2.5, OCC 7.6.3
Locale: English/United States (en_US)
Installed mods: 
  * IconThemes
  * FreeCAD_DarkPreferencePack 0.0.1
  * OpenDark 2023.9.24

Subproject(s) affected?

Core

Anything else?

Current (on a 1080p screen): tabView1 Proposed (on a 1440p screen): tabview2

Code of Conduct

[X] I agree to follow this project's Code of Conduct

obelisk79 commented 9 months ago

I think this would optimize use of vertical space quite nicely. There is a lot of wasted unused space to be reclaimed in this area.

Looking at the screenshots, I think one way that length of the status messages could be reduced is limiting the scope of displayed unit precision. In the examples above, the xyz distances could be limited to two or three digits of floating point precision.

Roy-043 commented 9 months ago

For smaller screens the proposal makes no sense obviously. Also consider that there are workbenches that put additional widgets in the statusbar (Arch, Draft and BIM).

obelisk79 commented 9 months ago

Arch WB:

Draft WB:

BIM WB:

Ok, so I agree that the proposed solution causes problems for draft, bim, and arch.

An alternative would be to overlay status-bar messages at the bottom of the 3d view rather than sharing space with tabs and/or functions.
I think the adding/removing of buttons in the status bar while convenient for some is a generally BAD UI/UX practice. Not only that, but the buttons that are always present, navigation style and units, get moved around on the screen rather than remain static.
Status Bar implies it provides information not functions. I normally have it hidden and would be lost not having access to functions I need in that case.
Most of the functions/widgets added to the status bar by the above listed workbenches are duplicated on toolbars or redundant from elsewhere (I see you BIM units selector!)

MisterMakerNL commented 9 months ago

I agree on this, it's definitely also better for smaller screens which is logical since less wasted pixels soo more usefull pixels. I also see a discussion about the use of the status bar. Because I agree with Obelisk, it's not a toolbar. Is there btw any use to quickly switch navigation mode and units? I guess units for those USA people, although I'm normally against stimulating bad behavior. Also why are the dimensions in the info line with 6+ decimals.

Roy-043 commented 9 months ago

Some of the duplication you see are optional features. The user can optionally hide the Draft snap toobar and only use the widget in the status bar. Which makes a lot of sense on smaller screens.

The principle objections against placing widgets in the statusbar seem very ad-hoc. We have a workbench selector that can be squashed into a corner of the menu bar. Why is that weirdness allowed then?

obelisk79 commented 9 months ago

I don't think the workbench selector (which functionally is a menu) belongs on the menu bar, but that isn't necessarily something to address under this particular issue. It's also optional and not default

C0deKirukkan commented 9 months ago

An alternative would be to overlay status-bar messages at the bottom of the 3d view rather than sharing space with tabs and/or functions.

This is even better solution, IMHO. We can still find spaces for widgets & other things. If we go with this.

Most of the functions/widgets added to the status bar by the above listed workbenches are duplicated on toolbars or redundant from elsewhere (I see you BIM units selector!)

Completely agree. I don't know why quick access for these alone exists. Also, the navigation selection & unit selection at least for me is set and forget. I have never changed it after the first setup. (Am also a purely metric hobbyist)

Roy-043 commented 9 months ago

Currently there is no rule that forbids placing widgets in the status bar. Core puts 2 widgets there. When BIM adds widgets these are indeed moved. Again there is no rule regarding that.

luzpaz commented 9 months ago

JFYI, if any solution is proposed codewise, please take #7888 into consideration

PaddleStroke commented 9 months ago

Imo there should be a rule about not adding stuff in random places.

Some time ago I tried to claim the MDI tabs area to increase the 3d view, but to no luck qt does not allow that. Though adding stuff on top of the MDI tabs area is probably possible. The issue is that then you would have tabs stacking under the widgets you put on top. And those tabs would be inacessible. Not sure how this would be solved.

luzpaz commented 7 months ago

What's the status of this discussion ?

obelisk79 commented 7 months ago

I think a tabletop consensus is difficult to reach. The current arrangement works but is far from ideal and a change will have cascading effects on a couple of workbenches which would need to be resolved first.

So, just stuck in a holding status for now.

PaddleStroke commented 7 months ago

So I was looking into it, and it seems that it is actually possible to put a widget in the tabbar (https://forum.qt.io/topic/145522/how-to-display-tab-widget-corner-widget-on-the-left-right-side/2)

So we can implement this. And to avoid any issues with some workbench and so on, we can implement that as an option disabled by default.

luzpaz commented 7 months ago

Any traction here ?

PaddleStroke commented 7 months ago

So I happened to dig this a little bit. The resource I mentioned before is actually for QTabWidget and not for QTabBar. So this doesn't work. I found another topic https://stackoverflow.com/questions/16530952/use-custom-tab-bar-with-qmdiarea that hints about a methode to replace the standard QTabBar of the MDI area. I'm not sure if this can work. Feels hacky

FreeCAD / FreeCAD