Eclipse Community Forums: EMF » Selection order in tree-based EMF editors

Help

Home

Home » Modeling » EMF » Selection order in tree-based EMF editors

Show: Today's Messages :: Show Polls :: Message Navigator

Selection order in tree-based EMF editors [message #417653]

Thu, 20 March 2008 14:08

Dimitrios Kolovos

Messages: 1776
Registered: July 2009

Senior Member

Hi,

I’ve come across the following issue. If I select two elements in the
ECore reflective editor (e.g. EClass A and EClass B) the
StructuredSelection returned by the tree viewer is {A, B}. Now, if I
select the same elements but in a reverse order (i.e. first EClass B and
then EClass A) the StructuredSelection is still {A,B}.

I’ve found
( http://dev.eclipse.org/newslists/news.eclipse.tools/msg03503 .html) that
this is not an EMF problem but a known SWT limitation. However, there
are cases where the selection order is important in EMF editors (e.g.
http://epsilonblog.wordpress.com/2008/03/16/model-refactorin g-in-emf-editors/#comment-24).
Any thoughts on a workaround for this?

Cheers,
Dimitrios

Report message to a moderator

Re: Selection order in tree-based EMF editors [message #417657 is a reply to message #417653]

Thu, 20 March 2008 15:04

Ed Merks

Messages: 33141
Registered: July 2009

Senior Member

Dimitrios,

Since the underlying controls have no mechanism for determining this
order it seems to me that the selection can only be used to prime the
information used to start the process and at the start, you'll need to
allow the user to reorder the selection so that each object is in the
proper role for the operation.

Dimitrios Kolovos wrote:
> Hi,
>
> I’ve come across the following issue. If I select two elements in the
> ECore reflective editor (e.g. EClass A and EClass B) the
> StructuredSelection returned by the tree viewer is {A, B}. Now, if I
> select the same elements but in a reverse order (i.e. first EClass B
> and then EClass A) the StructuredSelection is still {A,B}.
>
> I’ve found
> ( http://dev.eclipse.org/newslists/news.eclipse.tools/msg03503 .html)
> that this is not an EMF problem but a known SWT limitation. However,
> there are cases where the selection order is important in EMF editors
> (e.g.
> http://epsilonblog.wordpress.com/2008/03/16/model-refactorin g-in-emf-editors/#comment-24).
> Any thoughts on a workaround for this?
>
> Cheers,
> Dimitrios

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Selection order in tree-based EMF editors [message #417661 is a reply to message #417657]

Thu, 20 March 2008 17:56

Thomas Schindl

Messages: 6651
Registered: July 2009

Senior Member

I know this limitation and I once had code for JFace which took track of
the selection order for StructuredSelection but it never made it into
the code base. What I'm trying to say is that it is possible (although
it is a bit of work) to track the selections yourself and order it in
the way they occur.

Tom

Ed Merks schrieb:
> Dimitrios,
>
> Since the underlying controls have no mechanism for determining this
> order it seems to me that the selection can only be used to prime the
> information used to start the process and at the start, you'll need to
> allow the user to reorder the selection so that each object is in the
> proper role for the operation.
>
>
> Dimitrios Kolovos wrote:
>> Hi,
>>
>> I’ve come across the following issue. If I select two elements in the
>> ECore reflective editor (e.g. EClass A and EClass B) the
>> StructuredSelection returned by the tree viewer is {A, B}. Now, if I
>> select the same elements but in a reverse order (i.e. first EClass B
>> and then EClass A) the StructuredSelection is still {A,B}.
>>
>> I’ve found
>> ( http://dev.eclipse.org/newslists/news.eclipse.tools/msg03503 .html)
>> that this is not an EMF problem but a known SWT limitation. However,
>> there are cases where the selection order is important in EMF editors
>> (e.g.
>> http://epsilonblog.wordpress.com/2008/03/16/model-refactorin g-in-emf-editors/#comment-24).
>> Any thoughts on a workaround for this?
>>
>> Cheers,
>> Dimitrios

--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------

Report message to a moderator

Re: Selection order in tree-based EMF editors [message #417666 is a reply to message #417661]

Thu, 20 March 2008 18:46

Ed Merks

Messages: 33141
Registered: July 2009

Senior Member

Tom,

I can imagine that tracking selection history might be a way... But what
if some code sets the selection explicitly? You wouldn't know the order
in that case perhaps?

Tom Schindl wrote:
> I know this limitation and I once had code for JFace which took track
> of the selection order for StructuredSelection but it never made it
> into the code base. What I'm trying to say is that it is possible
> (although it is a bit of work) to track the selections yourself and
> order it in the way they occur.
>
> Tom
>
> Ed Merks schrieb:
>> Dimitrios,
>>
>> Since the underlying controls have no mechanism for determining this
>> order it seems to me that the selection can only be used to prime the
>> information used to start the process and at the start, you'll need
>> to allow the user to reorder the selection so that each object is in
>> the proper role for the operation.
>>
>>
>> Dimitrios Kolovos wrote:
>>> Hi,
>>>
>>> I’ve come across the following issue. If I select two elements in
>>> the ECore reflective editor (e.g. EClass A and EClass B) the
>>> StructuredSelection returned by the tree viewer is {A, B}. Now, if I
>>> select the same elements but in a reverse order (i.e. first EClass B
>>> and then EClass A) the StructuredSelection is still {A,B}.
>>>
>>> I’ve found
>>> ( http://dev.eclipse.org/newslists/news.eclipse.tools/msg03503 .html)
>>> that this is not an EMF problem but a known SWT limitation. However,
>>> there are cases where the selection order is important in EMF
>>> editors (e.g.
>>> http://epsilonblog.wordpress.com/2008/03/16/model-refactorin g-in-emf-editors/#comment-24).
>>> Any thoughts on a workaround for this?
>>>
>>> Cheers,
>>> Dimitrios
>
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Selection order in tree-based EMF editors [message #417669 is a reply to message #417666]

Thu, 20 March 2008 18:54

Thomas Schindl

Messages: 6651
Registered: July 2009

Senior Member

Ed Merks schrieb:
> Tom,
>
> I can imagine that tracking selection history might be a way... But what
> if some code sets the selection explicitly? You wouldn't know the order
> in that case perhaps?

Well as long as you are staying at the JFace-level this is not a problem
because JFace is fireing a selection-changed even if you are doing it
programmatically (this is an exception of the SWT-Rule to not
fire-events) :-) but when working at the JFace-Level I even control the
set selection method and I'd say the selection is just the one of the
StructuredSelection you are passing into.

If one uses JFace-Viewers and is interfacing directly with the
SWT-Control there are many sorts of things that can and will go wrong so
it's not really an issue.

Tom

--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------

Report message to a moderator

Re: Selection order in tree-based EMF editors [message #417684 is a reply to message #417669]

Thu, 20 March 2008 22:34

Dimitrios Kolovos

Messages: 1776
Registered: July 2009

Senior Member

Ed: Thanks for your suggestion; that's what I'll probably need to do if
I can't - somehow - get to track the selection order.

Tom: Could you possibly share this selection tracking code? (if you
still have it that is)

Cheers,
Dimitrios

Tom Schindl wrote:
> Ed Merks schrieb:
>> Tom,
>>
>> I can imagine that tracking selection history might be a way... But
>> what if some code sets the selection explicitly? You wouldn't know
>> the order in that case perhaps?
>
> Well as long as you are staying at the JFace-level this is not a problem
> because JFace is fireing a selection-changed even if you are doing it
> programmatically (this is an exception of the SWT-Rule to not
> fire-events) :-) but when working at the JFace-Level I even control the
> set selection method and I'd say the selection is just the one of the
> StructuredSelection you are passing into.
>
> If one uses JFace-Viewers and is interfacing directly with the
> SWT-Control there are many sorts of things that can and will go wrong so
> it's not really an issue.
>
> Tom
>

Report message to a moderator

Re: Selection order in tree-based EMF editors [message #417686 is a reply to message #417684]

Thu, 20 March 2008 23:22

Thomas Schindl

Messages: 6651
Registered: July 2009

Senior Member

This is a multi-part message in MIME format.
--------------040305070501050208080500
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Dimitrios Kolovos schrieb:
> Ed: Thanks for your suggestion; that's what I'll probably need to do if
> I can't - somehow - get to track the selection order.
>
> Tom: Could you possibly share this selection tracking code? (if you
> still have it that is)

Not the original code but I hacked up a short snippet which seems to
work quite well.

Tom
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------

--------------040305070501050208080500
Content-Type: text/plain;
name="Snippet057OrderStructuredSelection.java"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="Snippet057OrderStructuredSelection.java"

/*********************************************************** ********************
* Copyright (c) 2006 Tom Schindl and others.
* All rights reserved. This program and the accompanying materials
* are made available under the terms of the Eclipse Public License v1.0
* which accompanies this distribution, and is available at
* http://www.eclipse.org/legal/epl-v10.html
*
* Contributors:
* Tom Schindl - initial API and implementation
************************************************************ *******************/

package org.eclipse.jface.snippets.viewers;

import java.util.ArrayList;
import java.util.Collections;
import java.util.Iterator;
import java.util.List;

import org.eclipse.core.runtime.ListenerList;
import org.eclipse.jface.viewers.ISelection;
import org.eclipse.jface.viewers.ISelectionChangedListener;
import org.eclipse.jface.viewers.ISelectionProvider;
import org.eclipse.jface.viewers.IStructuredContentProvider;
import org.eclipse.jface.viewers.IStructuredSelection;
import org.eclipse.jface.viewers.LabelProvider;
import org.eclipse.jface.viewers.SelectionChangedEvent;
import org.eclipse.jface.viewers.StructuredSelection;
import org.eclipse.jface.viewers.StructuredViewer;
import org.eclipse.jface.viewers.TableViewer;
import org.eclipse.jface.viewers.Viewer;
import org.eclipse.swt.layout.FillLayout;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;

/**
* A snippet demonstrating how to track the order of selections
*
* @author Tom Schindl <tom.schindl@bestsolution.at>
*
*/
public class Snippet057OrderStructuredSelection {
private class OrderSelectionProvider implements ISelectionProvider {
private ListenerList listener = new ListenerList();
private StructuredSelection currentSelection = StructuredSelection.EMPTY;
private StructuredViewer viewer;
private boolean update;

public OrderSelectionProvider(StructuredViewer viewer) {
this.viewer = viewer;
this.viewer
.addSelectionChangedListener(new ISelectionChangedListener() {

public void selectionChanged(SelectionChangedEvent event) {
if (!update) {
currentSelection = new StructuredSelection(calculateDiff(event));
}

Object[] listeners = listener.getListeners();
SelectionChangedEvent newEvent = new SelectionChangedEvent(
OrderSelectionProvider.this,
currentSelection);
for (int i = 0; i < listeners.length; i++) {
((ISelectionChangedListener) listeners[i])
.selectionChanged(newEvent);
}
}

});
}

private List calculateDiff(SelectionChangedEvent event) {
// TODO Not 100% correct because we might have to use the comparator used
// by the list to decide if 2 elements are equal
List originalList = new ArrayList(currentSelection.toList());
List newList = new ArrayList(((IStructuredSelection) event.getSelection())
.toList());

Iterator it = newList.iterator();

// Add Elements at the end not part of the list and find out which
// elements are not part of the selection anymore
List tmp = new ArrayList(currentSelection.toList());
Object el;
while (it.hasNext()) {
el = it.next();
if( tmp.contains(el) ) {
tmp.remove(el);
} else {
originalList.add(el);
}
}

// Remove elements not part of the List anymore
it = tmp.iterator();
while (it.hasNext()) {
originalList.remove(it.next());
}

return originalList;
}

public void addSelectionChangedListener(
ISelectionChangedListener listener) {
this.listener.add(listener);
}

public ISelection getSelection() {
return currentSelection;
}

public void removeSelectionChangedListener(
ISelectionChangedListener listener) {
this.listener.remove(listener);
}

public void setSelection(ISelection selection) {
update = true;
currentSelection = (StructuredSelection) selection;
viewer.setSelection(selection);
update = false;
}

}

private class MyContentProvider implements IStructuredContentProvider {

/*
* (non-Javadoc)
*
* @see org.eclipse.jface.viewers.IStructuredContentProvider#getElem ents(java.lang.Object)
*/
public Object[] getElements(Object inputElement) {
return (MyModel[]) inputElement;
}

/*
* (non-Javadoc)
*
* @see org.eclipse.jface.viewers.IContentProvider#dispose()
*/
public void dispose() {

}

/*
* (non-Javadoc)
*
* @see org.eclipse.jface.viewers.IContentProvider#inputChanged(org. eclipse.jface.viewers.Viewer,
* java.lang.Object, java.lang.Object)
*/
public void inputChanged(Viewer viewer, Object oldInput, Object newInput) {

}

}

public class MyModel {
public int counter;

public MyModel(int counter) {
this.counter = counter;
}

public String toString() {
return "Item " + this.counter;
}
}

public Snippet057OrderStructuredSelection(Shell shell) {
final TableViewer v = new TableViewer(shell);
v.setLabelProvider(new LabelProvider());
v.setContentProvider(new MyContentProvider());

OrderSelectionProvider selectionProvider = new OrderSelectionProvider(v);
selectionProvider.addSelectionChangedListener(new ISelectionChangedListener() {

public void selectionChanged(SelectionChangedEvent event) {
System.err.println(event.getSelection() + " vs " + v.getSelection());
}

});

MyModel[] model = createModel();
v.setInput(model);
v.getTable().setLinesVisible(true);
}

private MyModel[] createModel() {
MyModel[] elements = new MyModel[10];

for (int i = 0; i < 10; i++) {
elements[i] = new MyModel(i);
}

return elements;
}

/**
* @param args
*/
public static void main(String[] args) {
Display display = new Display();
Shell shell = new Shell(display);
shell.setLayout(new FillLayout());
new Snippet057OrderStructuredSelection(shell);
shell.open();

while (!shell.isDisposed()) {
if (!display.readAndDispatch())
display.sleep();
}

display.dispose();

}

}

--------------040305070501050208080500--

Report message to a moderator

Re: Selection order in tree-based EMF editors [message #417726 is a reply to message #417686]

Tue, 25 March 2008 10:49

Dimitrios Kolovos

Messages: 1776
Registered: July 2009

Senior Member

Thanks! I'll give it a try.

Cheers,
Dimitrios

Tom Schindl wrote:
> Dimitrios Kolovos schrieb:
>> Ed: Thanks for your suggestion; that's what I'll probably need to do
>> if I can't - somehow - get to track the selection order.
>>
>> Tom: Could you possibly share this selection tracking code? (if you
>> still have it that is)
>
> Not the original code but I hacked up a short snippet which seems to
> work quite well.
>
> Tom
>

Report message to a moderator

Previous Topic:	NumberFormatException specifying hex
Next Topic:	Problem with Genmodel with multiple ecores

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 22:41:48 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter