eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

[console] OCL Console Usability #656

Open eclipse-ocl-bot opened 1 month ago

eclipse-ocl-bot commented 1 month ago

| --- | --- | | Bugzilla Link | 339852 | | Status | NEW | | Importance | P3 enhancement | | Reported | Mar 14, 2011 05:16 EDT | | Modified | May 27, 2014 12:35 EDT | | Version | 3.1.0 | | Reporter | Axel Uhl |

Description

The interactive OCL console currently shows two text fields: one for the results, one for the input. The input has a "magic" history function based on the PgUp key event, and currently the "pressed" (not the "released") event is handled which I think is unusual.

I suggest the input text field should show an editable and searchable (e.g., Ctrl-R like in bash and others) history. In particular, Cursor Up/Down should allow users to navigate through the history of previously entered expressions.

Pressing the Enter key while anywhere in a (potentially multi-line) expression should evaluate that expression and show the results in the results view.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Mar 14, 2011 05:30

Unfortunately the input text is multi-line so cursor-up/down are committed to line navigation. Hence the resort to PageUp/Down.

The history problem might go away if the output document was a tree with one top level element per evaluation with self, command, results-tree children. An old command could then be selected and re-used. Displaying the results as a sub-tree would be much more satisfactory for collections and tuples.

The results browser begins to resemble the QVTo debugger variable display.

So then why can't we do single step evaluation so that users can better understand their problems.

Perhaps the Console Status becomes a debugger view and the results a Variables View.

eclipse-ocl-bot commented 1 month ago

By Axel Uhl on Mar 14, 2011 11:28

Sounds like we have two intermingled issues here:

1) providing a tree-like result view which helps in debugging OCL expressions

2) Improving the usability of the input capabilities in the input text field

I consider these unrelated issues and would like to focus this bugzilla on 2). Why don't you open another bugzilla for 1)?

Unfortunately the input text is multi-line so cursor-up/down are committed to line navigation. Hence the resort to PageUp/Down.

What if we by default require an expression to be in one line ("shell-like"), and if it isn't, require the end-of-line to be escaped with a "\" character? Then cursor navigation does pretty much what the user expects, and it's possible to move about all previous OCL expressions, edit, copy, paste them, and when the Enter key is released, this executes the expression the cursor is currently in. Again, this behavior IMHO resembles that of most shells that I know where you can edit in-line, and when you hit Enter, it executes the entire line, no matter in which column the cursor was when Enter was pressed/released/typed.

The history problem might go away if the output document was a tree with one top level element per evaluation with self, command, results-tree children. An old command could then be selected and re-used. Displaying the results as a sub-tree would be much more satisfactory for collections and tuples.

Again, I don't see how result display would change input behavior? I assume we still expect users to enter the OCL expressions textually and not by editing a tree.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Mar 23, 2011 19:33

I've created http://wiki.eclipse.org/MDT/OCL/Debugger in which to try to gather ideas together.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on May 27, 2014 12:35

Debugger now available, so running ir on "self" provides a handy way of browsing a model.

(In reply to Axel Uhl from comment #0)

The interactive OCL console currently shows two text fields: one for the results, one for the input. The input has a "magic" history function based on the PgUp key event, and currently the "pressed" (not the "released") event is handled which I think is unusual.

No. In Package Explorer cursor down unfolds. Here key down types.

I suggest the input text field should show an editable and searchable (e.g., Ctrl-R like in bash and others) history. In particular, Cursor Up/Down should allow users to navigate through the history of previously entered expressions.

Ideas for a smarter Input Pane.

Pressing the Enter key while anywhere in a (potentially multi-line) expression should evaluate that expression and show the results in the results view.

Already the case.