Summary of improvements for OMEdit GUI usability

[Francesco Casella]

This ticket is meant to collect and prioritize the improvements that need to be done to the OMEdit GUI in order to make it usable with the MSL and with most modern Modelica 3.4 compliant libraries. Each item is covered by a specific ticket.

Features requiring the new front end to be in place

All the features listed here depend on the front-end to provide correct information to OMEdit, and to do so rapidly. This is now possible by using the new front-end (see #4138), which is exploited by new API functions which are much faster than previously. Version 1.14.0 will use these features by default.

• #2079 Replaceable classes and replaceable objects (e.g. the Medium package in all Modelica.Fluid models, or the HeatTransfer model in the Modelica.Fluid.Vessels.ClosedVolume) should show up in the parameter window, with a drop-down menu filled in based on the choices or choicesAllMatching annotations. Once a specific choice is made, it should be possible to change the parameters and/or replaceable classes/models of the redeclared model/component, e.g. by clicking on a button. This feature is essential for the Modelica.Fluid library, as well as for many user libraries such as ThermoPower.

• #2081 Conditional connectors should be displayed correctly. This feature is used extensively in the Modelica.Mechanics and Modelica.Electrical libraries. It requires that the API functions return the correct visibility attribute.

• #2891 Hierarchical editing of systems for graphical modification of parameters and replaceable classes in sub-models. Requires substantial work to implement some API function, as well as in OMEdit to display the information properly.

• #3915 Rename feature missing

Other features

• #4645 and #4839 Use blank pixels around lines to enhance readability

• #3776 Allow copying/pasting models across diagrams

• #3287 Allow input of common parameters and replaceable classes in a multiple component selection. This can shorten the time to set up a model dramatically

• #2166 See exact simulation values through snap to curve feature

• #2661 Update parameter-dependent Dialog annotations correctly

• #2132 Display conditional connectors correctly by evaluating the corresponding parameters

Past improvements

• #4508 Reduce the installation time under Windows by making the installation of contributed open source libraries optional

• #2909, #3788 Drastically reduce the waste of HD space by eliminating useless intermediate output files and reducing the number of useful files

• #3054 Clarify "Revert from previous" button

• #2908 Changes in sub-models should be reflected in models using them immediately, not only when changes to the latter models are made.

• #2906 Drop-down choices for enumeration (and possibly boolean) parameters

• #2845 Consistent view between textual view and library browser view of packages should be always guaranteed. Requires to update the views in OMEdit whenever the focus is changed between the different sub-windows.

• #2391 Improved handling of custom modifers (e.g. start attributes) from the GUI. Modifers, once applied, should still show up when the parameter window is re-opened later.

• #2390 Fully support the showStartAttribute annotation, which is widely used in Modelica.Mechanics.

• #2190 Copy class feature within the same package.

• #2903 Add option to output protected variables to simulation setup window, output tag.

• #2477 Better snap-to-grid features when using blocks from the MSL

• #2506 Keep connecting lines manhattanized and allow no-nonsense editing of models copied from the MSL (e.g. it should be possible to move one component without weird side-effects on the diagram)

• #2611 Zoom issue should be fixed.

• #2988 Zoom In/Out with MouseWheel.

• #2392 Show default values differently in the Component Parameters window.

• #2956 Moving a complete model disassembles everything

• #2596 Re-simulate with changed options. Currently if we want to make a new simulation with different simulations options, e.g. a different final time we have to re-build the whole executable, that is a waste of time.

• #2985 Updating submodel icons where they are used. This ticket is not really urgent. But it is related to #2908, that has already been fixed, so fixing this one is sort of completion of the job. In case it is difficult to fix it could be postponed.

• #1900 Handle connections to expandable connectors in OMEdit

• #2250 Support DisplayUnit and unit conversion for parameter input in OMEdit

• #3558: Flip icons with text boxes correctly

• #2676 Handle models in separate files

• #2905 Comment- and formatting-preserving parsing and unparsing is required to avoid that OMEdit scrambles up the code of existing Modelica classes when saving them on file.

• #2892 Undo/Redo feature in the Diagram view of the model editor.

• #2190 Copy class to a different package.

• #2696: Display enhancement of very large and very small numbers on vertical axis

• #2960 Speed up the exploration of the package tree and the drag-n-drop actions.

• #4504 Allow to install OpenModelica anywhere in the file system, including the default installation directories (such as C:\Program Files) that include spaces

• #2395 - Support the connectorSizing annotation. Required by many libraries including Modelica.Fluid, PNLib, iPSL, OpenIPSL

[Lennart Ochel]

I would like to mention #2395 - Support connectorSizing annotation.

[massimo ceraolo]

I've always been a strong supporter of OMEdit GUI improvements.

I understand that if the list gets too long it would become difficult to satisfy all the items.
Therefore I add here only possible improvements that I strongly recommend and that have already appeared in tickets:

• snap to grid connecting wires (ticket #2477)
• keep connecting lines manhattanized (ticket #2506)
• make dymola-created diagrams manageable (comment from Kokert to ticket #2506). In fact when one opens Dymola diagrams in OMEdit they seem ok. But as soon as one moves an icon everything gets messed up
• zoom issue (ticket #2611)

[massimo ceraolo]

Replying to ceraolo:

After a year I can state that all the issues quoted in this comment have been solved:
a great work has been done! Thanks to all developers.

I know that OMEdit is currently under heavy development, so much more is coming. This will make OM and OMEdit even more usable.
I already use it for a one-semester course at my University and will keep doing this.

[Francesco Casella]

Note that there are 14 more fixes ready on Adeel's development branch, they just need a few updates on the front end to be committed to the master version.

[Francesco Casella]

Most of the issues reported in this ticket have been fixed, and at least for some types of projects OMEdit can now be used for serious work.

I have re-organized the ticket so as to show the progress we've made in these last three years, as well as to make it clear what is still missing.

[massimo ceraolo]

I think #2166 should be closed now

[Adeel Asghar]

Replying to ceraolo:

I think #2166 should be closed now

Its been reopened to have some added functionality for overlapping curves.

[massimo ceraolo]

I've created a further ticked relating to the general quality of the plotted output, #4437. @casella, I leave to you whether to include it in this list or not.

[massimo ceraolo]

Moving a diagram up and down can be down by selecting all, and then moving by mouse or keyboard.

The user would think: mouse is coarse, keyboard is more accurate. Thus I use several keystrokes.

Keyboard usage, however, results (for models of average complexity) in a tremendous slowdown, in comparison with mouse usage. This, I suppose, is because after each keystroke OMEdit requests OMC to update its inner image of the model, and this takes time.
I wonder whether the following cache mechanism can be implemented:

• when an arrow-key is stricken wait for a given time (e.g. 200 ms) to see if further keystrokes arrive
• when the sequence of keystrokes finishes send the final position of the diagram to OMC for elaboration.

Naturally, if in the new front-end the OMC movement of diagrams is very-fast, this mechanism is unnecessary.

[massimo ceraolo]

I would recommend to add #3915 to the list of "Other features".

[Francesco Casella]

Version 2.0.0 should have all these improvements in place.

[massimo ceraolo]

I think it is also very important to copy a model (with all its parameter values) from a diagram into another. this is an operation is very frequently done when using other tools (e.g. Dymola), and, for me, is strongly needed. For instance a MSL electrical machine has tens of parameters which would be automatically transferred to the new diagram if this function is in place.
There is already ticket #3776 for this, which is solved for copying/pasting inside the same diagram (see #4585), but is still open for doing the same across diagrams.

@casella, since you agreed to this in comment 5 of ticket #3776, I'm going to modify this ticket description accordingly (i.e. I'll add #3776)

[Francesco Casella]

Replying to ceraolo:

@casella, since you agreed to this in comment 5 of ticket #3776, I'm going to modify this ticket description accordingly (i.e. I'll add #3776)

OK, thanks!

I don't think we will be able to do this in time for 1.14.0, we'll see what we can do in the autumn. Maybe we could have some minor releases 1.14.x that take care of these issues without involving the rest of the source code, or possibly have another 1.x release around October before the big one.

This depends on the progress with the remaining issues of the new front-end, which is currently slowed down by unanticipated difficulties with non-expanded arrays of records.