OMEdit subwindow feature faulty?

[massimo ceraolo]

I like to look at several plot windows at a time when I analise simulation outputs.
In OMEdit I have to do the following:

• choose in the Options "tabbed view"
• every time I create a new plot right-click on the tab and choose "restore" (since every time a new plot is created tabbed view is restored))

This is tricky, since every one has to select "restore" continuously: not only when a new plot is created, but also when he switches to diagram view, and again to plot view.
Moreover, one has to manually arrange all the windows (no "arrange all" command is provided). A workaround for this, but still tricky, is to switch to diagram view, and again to plot view and again select "restore".

Maybe what I wish is intended to be done by the program selecting in options "subwindows view", but if I select that (r23316, win version) I can just see one plot even if several are created.

[Adeel Asghar]

You actually do this in subwindows view. When you are in subwindows mode click Restore Down button on the top right corner (note that you should not click on OMEdit Restore Down button but the one below it which belongs to the subwindow).

The problem is I always maximize the selected subwindow when user switches to plotting perspective.

There is something called Cascade Windows & Tile Windows which is quite commonly used with MDI (Multiple Document Interface). I will implement it so that users can do this with one click instead of restore method you explained above.

[massimo ceraolo]

Aha,
you suggestion works well.
Sorry for not having seen this earlier.

Now the situation has changed. A modification that I really recommend is to modify the behaviour so that when perspective is switched back to plotting the windows are kept as they were earlier (i.e. no automatic maximising of the selected window should occur).

Naturally, Cascade&tile is a useful additional feature, and if you implement it you add quality to the subwindows plot display.

[Adeel Asghar]

Fixed in r23414.

[Dietmar Winkler]

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.

[Martin Sjölund]

Removing the pre1.9.4 milestone in favor of 1.9.4.