Commands & Operations about limpet_ops HOT 10 CLOSED

Given the subtract operation example, I think we can use the selection order to define which item is 1 and which is 2. For example click A then B and the operation offered will be subtract B from A, click B then A, the operation will be subtract A from B. In this way there will be no need to offer multiple operations based on selection order.
Regarding

...offering the user multiple options for running the command...

the subtract operation should be split in two - SubtractIndexedQuantityValues and SubtractInterpolatedQuantityValues and both operations are declared. If needed, implementing classes can have common superclass.

from limpet_ops.

RCP doesn't give us the selection order - we just get a structured selection object. I think the items are provided in their comparable order from the source - the tree in our case.

Yes, it's fine to separate them into indexed & interpolated commands.

from limpet_ops.

You are right, the JFace treeviewer does not track selection order. I got confused with GEF (https://eclipse.org/gef/) viewers, which preserve the selection order.
In that case we can either (1) again split each Indexed and Interpolated subtract operation in two - Subtract A from B and Subtract B from A. That means there'll be four subtract operations declared overall, each with own class (probably common parent). Or (2) we can extend the viewer used in the DataManagerEditor with some logic to preserve the selection order (http://stackoverflow.com/a/12978563). Then use this preserved selection when creating the context menu here: https://github.com/debrief/limpet/blob/master/info.limpet.ui/src/info/limpet/ui/editors/DataManagerEditor.java#L541

from limpet_ops.

Hmm, maybe we define some "non commutative" flag, and our logic processing creates multiple operations, for any permissible permutations.

from limpet_ops.

That makes sense. We can even parameterize the operation name, like "Subtract {0} from {1}", then replace with selection on runtime.
I'm not sure how to define the permissible permutations though. Can you give an example for a such operation?
Perhaps assuming there are 3 elements in the selection and 3! permutations, we can just list the numbers of the allowed permutations, like allowedPermutations="1;2;6".

from limpet_ops.

The subtract operation is typical for collections that are either dimensionless, or have the same dimension.

A similar operation is available for two location datasets: "bearing from" could be from the perspective of either of the operands.

If there are more than two operands, we should invite the user to choose "bearing from" any of the operands. If there are 5 in the selection, then 4 new collections will be produced: with each one being the "bearing from" whichever one the user selected.

[Note: the above "5 from 4" situation isn't just this particular to this commutative situation. Range from isn't commutative. So, it's the same distance whichever of the pair comes first. But, a user may select 5 elements, choose which one it's "range from", then 4 new collections will be produced].

from limpet_ops.

I've extended the PoC with support for declaration of non-commutative operations. The commit is f46f7f2. If you launch the PoC view now, you'll see two new numerical operations: Subtract and DistanceFrom. In the example below, user selects two numbers and sees two combination for subtracting the numbers:

DistanceFrom operation is applicable for 2 or more numbers:

I've introduced an optional Java class-typed attribute in the extension point schema, called inputPermutator. Normally non-commutative operations will use this attribute. This class will produce the different permutations of the input. This will be taken in account when building the context menu so that multiple entries will be added for an operation. Possible enhancement would be to introduce a submenu (menu nesting), so that there is a "Subtract >" menu and then "1 from 12", "12 from 1" for example.
Operation name now can be parameterized using Java MessageFormat syntax (https://docs.oracle.com/javase/7/docs/api/java/text/MessageFormat.html), such as "Subtract {1} from {0}".
Important note is that it's best to define the concrete permutators in the base plugin (sampleModel in this case), since it's loaded during building the context menu and before operation execution.

from limpet_ops.

Hi Dinko, that looks just great - nicely done. The submenu will certainly make tidier. Could you develop some submenu thoughts in the demonstrator?

Cheers,
Ian

from limpet_ops.

Non-commutative operations (those that specify an inputPermutator in the schema) are now grouped via submenu: 2dd6dfb. Note the format of the operation name:
Subtract>{1} from {0}

In addition, with commit cf7bb42 I address your concern:

Hopefully the sub-menu won't be too RCP/JFace-centric

There is now a SampleModelOperationRegistry singleton, that resides in the model plugin and handles building the operation library together with an IOperationLibraryBuilder. The latter decouples operation traversal from building the library. The registry does not know anything about the UI/JFace except the org.eclipse.jface.IStructuredSelection. In the sampleView plugin there's a concrete OperationLibraryMenuBuilder that will actually use JFace menu manager to build the menu.

from limpet_ops.

Issue complete - non-commutative operations are now supported.

from limpet_ops.