The 'show on hover' feature should exclude the "FC menu" button

[raindropsfromsky]

At present, the show on hover feature includes the button. In other words, if we hover on this button, the ribbon appears.

Instead, a hover on should display the menu, like this:

[APEbbers]

Hi,

I've implemented this in the develop branch. Now only hovering over the tabbar will show the ribbon. Menu, quickaccess and righttoolbar are excluded.
Also, now when you start FreeCAD, the ribbon is folded by default.

Kind regards,

[raindropsfromsky]

That's wonderful!

BTW Ribbon's autohide function has never given any issues so far, since you activated it.

[APEbbers]

Great! I hadn't any issues either, so I'll introduce it with the next release!

kind regards

[raindropsfromsky]

I've implemented this in the develop branch. Now only hovering over the tabbar will show the ribbon. Menu, quickaccess and righttoolbar are excluded.

IMHO the solution does not work as required:

The Menu button's behavior depends on the direction of approach of the mouse:

1. If the ribbon is visible, and if I move in from the right and hover on the Menu button, the ribbon is NOT turned off.
   (The Menu button still behaves as if it is a part of the ribbon, and does not let the ribbon hide.) [BUG]

2. If the ribbon is NOT visible, and if I bring the mouse on the Menu button from below, the Menu button does not show the ribbon. [OK]

Desired:

Let there be two distinct hover hotspots:

1. The Menu button (a hover on it should reveal the main menu)
2. The WB toolbar (a hover on it should reveal the ribbon)

[APEbbers]

Hi,

(The Menu button still behaves as if it is a part of the ribbon and does not let the ribbon hide.) [BUG]
I'll look into it, but i don't see it as big problem, because as soon as you click on the menu, the ribbon folds anyway.
Actually, it might be a good thing because when you activate the first tab, otherwise you have to move down to prevent the ribbon from folding.

The Menu button (a hover on it should reveal the main menu)

I disagree. Here you have to click on the menu button like with the dropdown commands. This is common behaviour for software with a ribbon. It also prevents the user from accidently showing the menu when clicking on a command below it.

The WB toolbar (a hover on it should reveal the ribbon)

I also disagree. (I'm assuming that you mean the toolbar on the right) This should not trigger the ribbon.

I actually implemented like this. You hover over the tabs, when you want to access the ribbon. All other buttons have their own commands and do not need the ribbon to be visible.

kind regards

[raindropsfromsky]

Here you have to click on the menu button like with the dropdown commands. This is common behaviour for software with a ribbon. It also prevents the user from accidently showing the menu when clicking on a command below it.

Yes, that's fine too. (I should have added "ideally" to my suggested behavior.)

Here, the problem is that when the mouse comes over the Menu button, the ribbon does not hide.

I also disagree. (I'm assuming that you mean the toolbar on the right) This should not trigger the ribbon.

I think we are talking about the same thing.
I call the following structure as "WB toolbar":

I do not call them "tabs" for the simple reason that only the ribbon changes, not the UI below that.
(A 'tab" on the other hand should change everything below it)

[APEbbers]

Ah I see. the "WB toolbar" is actually called tabbar and the buttons with the workbench icons are called tabs. This is the common terminology for a ribbon or tabbed form. Even FreeCAD calls it tabbar.

That's the confusion.

However I have thought about activating a workbench on hover in the past, but it will result in sluggish behaviour, because of the loading time of the buttons. especially on older systems.
Besides that, it is also not that common behaviour. SolidWorks, SolidEdge but also MS office don't have this behaviour.

kind regards

[raindropsfromsky]

Well, the semantics is a trivial detail. We may call it a "tab bar".

But the point is, can you shrink the hotspot on the left side, and limit it to only the "WB tab bar"?

As soon as the mouse goes out of the hot zone (outlined in green in the screenshot below), the ribbon should hide.

Specifically, if the mouse is in the red zone, the ribbon should not pop up.
In fact, if it was showing already, it should hide.

Even if the Menu button does not produce a menu list when the mouse hovers on it, it is ok.

[APEbbers]

I can implement it but I'm thinking about it. point is, that when I leave it as it is now, the user can make a lazier movement to get to the left buttons on the ribbon. (Red in the picture below).

If I implement this, the user is forced to move down first, before go to the left. (Blue arrow).

I think a lazier movement is more user friendly. especially when your mouse movement is not so precise (Like mine).

[raindropsfromsky]

Oh I get it now!

I always turn off the Quick Access toolbar, as I can do all those operations with hotkeys.
So it never entered my mind.

No matter! I'd say the Quick Access toolbar also is part of the WB toolbar.
So we need not skirt around it.

To sum up, only the Menu button should be excluded from the hot zone.
If the mouse is hovering over any other area, the ribbon should show up.

So the user can be as lazy as he wants! 😄

[APEbbers]

Hi,

This is now implemented in the develop branch. Including #317

kind regards

[raindropsfromsky]

I don't see any difference vis-a-vis earlier version. There is a distinct state-dependency in its behavior:

1. If I move the mouse over the tabbar, the ribbon becomes visible. Now if I move the mouse over the Menu button, the ribbon is still visible. It does NOT turn off. In this condition, we can still click on the Menu button to open the menu, but that will not occur to the user because of the ribbon. [BUG]

2. If I move the mouse out of the ribbon area, the ribbon hides. Now if I move the mouse to the Menu button directly from below -- WITHOUT letting the mouse touch the tabbar -- the ribbon stays hidden. Now I can click on the Menu button to see the manu items.. [OK]

Thgus, a part of the problem is still not resolved.

[APEbbers]

Here it is working:
https://github.com/user-attachments/assets/f5f0e2ec-ba9b-469e-b03c-c9fc0982cfca

perhaps another gitt pull?

[raindropsfromsky]

perhaps another gitt pull?

That is quite possible, thanks to the vagaries of the Addon Manager.
First, it always shows the stable version even when I am running 1.8.x
Secondly, if I switch to development branch, it does not pop up the "x updates available" dialog.
I have to restart on my own.

I did all of this, and hoped for the best!

BTW this is why I had posted a feature request to publish the Git revision number.
Currently, it is always 1.7.x (stable) or 1.8.x (Development branch).
So I cannot tell which 1.8.x is running!

Imagine it displays a 4-part number such as 1.8.6.1 vs 1.8.7.4.
It will be easy to tell which version I am using.

[APEbbers]

This is will not happen. The system that you propose is already in the main branch. To do that separatly on the develop branch as well will result in mixups. Besides, you just have to copy the information from the about dialog including the SHA value and i can see which commit you are on. I explained this in issue #314

Other than that, please use the commandline as i have explained in #306. That works better than the add-on maneger.
The add-on manager works best with main branches.

kind regards

[raindropsfromsky]

My About... page shows:

I executed a git pull

To sum up, the git pull does not get me the latest development version.

[APEbbers]

your on the main branch

[raindropsfromsky]

I know! That's the problem: I am unable to switch to the Development branch!

P.S. I found this error in the Report panel:
Invalid version specified for tag version in Addon FreeCAD Ribbon: 1.8.x

Is this the reason?

[APEbbers]

what happens if you type "switch Develop"? and then do a git pull?

You can ignore the message in the report panel. That's not causing it.

[raindropsfromsky]

[APEbbers]

git switch Develop?

[raindropsfromsky]

oops. Since I am not a coder, I just copied what you recommended.

[raindropsfromsky]

Yes, now the behavior is perfect! 👍

Can you trigger menus when we hover on the Menu button? 🤞🏽

[APEbbers]

Perhaps, i can make it an option. But it should be applied to all menus and dropdown buttons. otherwise it is inconsistent.
Please note that is not standard behaviour. Check Windws, Office, SolidWorks, SolidEdge for example. They all need a click.

kind regards

[raindropsfromsky]

Yes, but we should always aim at what is more user-friendly; not what others have implemented.

All the products you mention have a long history, and they may have maintained continuity by not changing the UI drastically.
In fact, most of the large CAD customers do not prefer rapid changes in the UI, because they fear productivity loss.

So we have to look at disrupter products, which do not have legacy baggage.
They offer the most outstanding features. (.g. Plasticity)

[APEbbers]

I'm not sure it is that user-friendly. Also, Windows is an OS which aimed to be user-friendly. I'm a mechanical engineer myself and has used a lot of different cad programs. I personally don't want the menus to be open on hover, because it will be annoying when you want to click on a button close to it.

I believe the current behaviour in Windows, Office, the major CAD programs are actually thought through than only legacy behaviour.