Opened 10 years ago

Closed 10 years ago

Last modified 7 years ago

#3374 closed discussion (fixed)

Management of Tabs in OMEdit

Reported by: anonymous Owned by: Adeel Asghar
Priority: low Milestone: 1.9.4
Component: OMEdit Version: trunk
Keywords: Cc:

Description

I like tabs in the modelling view in OMEdit a lot.

However I think some improvements are advisable.
In fact, with the current implementation the average user, after some time of activity, tends to have many tabsheets open, that is not optimal: he has to periodically close them with a lot of clicks.

We can take inspiration from Google Chrome and Dymola 2016. What I propose is:

1) when the user clicks on a model name, this should cause that model to be open in the current tab (so a new tab should not be created).
2) a very small empty tab header should be kept always accessible (like in Google Chrome) such that clicking on it a new, empty tab is created
3) in the tab name context menu the item "close all other tabs" can be added
4) when the user right clicks on a library browser model he could find in the context menu an item named "open in a new tab".
5) Tabs should carry the "x" small button to close them immediately.


In this way, normally clicking on models overrides the model displayed in the current tab, and to open a new tab this must be explicitly requested.

For me 1 and 2 (or 1 and 4) are priority features, the others are optional.
Items 2) and 4) do similar things so one of them can be omitted, if this is considered better.

Note that Dymola 2016 has recently added tabs, that operate like in the previous points (point 2 is not there, but point 4 is a good substitute of 2).

Change History (4)

comment:1 by Adeel Asghar, 10 years ago

Resolution: fixed
Status: newclosed

We almost have all of these features available.

1) We have MDI (Multiple Document Interface) implemented which can be used as tabbed or as SubWindow view. In the case of tabbed view (which I believe you are using you will always get new tab for each new model you open), in the case of SubWindow view the same thing will happen but you won't see the tabs, so for the user everything is opening in the current tab.
2) Why in this world we need it when we have a pretty nice New Modelica Class button in the menu toolbar.
3) This is bit tricky to implement since Qt doesn't provide a standard way of doing it. There are hacks available that we can use but I am afraid they won't work on all platforms. So we can't simple extend the tab context menu. However, we still have this functionality available in menu View->Windows->Close All Windows But This.
4) Same as 1.
5) I added this in 180236/OMEdit.

comment:2 by anonymous, 10 years ago

Further comments on point 1).

I think that the MMI should ease the most common tasks.
My suggestions 1 and 4 came from the consideration that the common user much more frequently opens models just to look into and closes them a short while after, than opens several models simultaneously.
Is this true? I'm not sure. I based my suggestion on my personal experience and the experience of some colleagues of mine.

Consider a user that frequently opens models. To avoid the OMEdit desktop to be cluttered with a lot of tabs (in tabbed view) or SubWindows (in SubWindow View) he has to open and close them continuously (or at least frequently).

Every open/close action required, up to yesterday, the following actions:

  • double click to open
  • right-click on the tab to open a context menu
  • scroll the menu and choose close.

My requests 1 and 4 focused on reducing the number of these actions: every open/close pair would just involve double clicking on a new model, that would cause the model displayed in the current tab, and a new model loaded. This is how Dymola 2016 works.

Indeed you've already reduced the number of actions with the modification you made following my point 5. So my points 1 and 4 are partly obsolete now.

Regarding points 2, 3, 5, I agree with you.

comment:3 by Dietmar Winkler, 9 years ago

Milestone: Futurepre1.9.4

It doesn't make sense to keep closed ticket in the "Future" milestone that were simply forgotten to assign to the correct milestone in the past.

comment:4 by Martin Sjölund, 7 years ago

Milestone: pre1.9.41.9.4

Removing the pre1.9.4 milestone in favor of 1.9.4.

Note: See TracTickets for help on using tickets.