Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 320281 - No SelectionChangeEvent on Graph.setSelection()
Summary: No SelectionChangeEvent on Graph.setSelection()
Status: RESOLVED FIXED
Alias: None
Product: GEF
Classification: Tools
Component: GEF-Legacy Zest (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Fabian Steeg CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-19 11:23 EDT by Christian Sowada CLA
Modified: 2010-09-26 15:08 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Sowada CLA 2010-07-19 11:23:51 EDT
On one side I've registered a SelectionChangeListener on a Graph Object and on another side I've set the selection of the graph by a key event. But after the setSelection i get no SelectionChangeEvent, selecting by mouse works perfect.

In our graph you can navigate withe the arrow keys to select the next GraphNode.

I've fixed this by adding the fireWidgetSelectedEvent() in the loop of the setSelection() method. I think the same for selectAll() method.

Here


	/**
	 * Changes the selection to the list of items
	 * 
	 * @param l
	 */
	public void setSelection(GraphItem[] nodes) {
		clearSelection();
		if (nodes != null) {
			for (int i = 0; i < nodes.length; i++) {
				if (nodes[i] != null && nodes[i] instanceof GraphItem) {
					selectedItems.add(nodes[i]);
					(nodes[i]).highlight();
					fireWidgetSelectedEvent(nodes[i]);
				}
			}
		}
	}


I hope it's right.

By the way, why so many methods are private? So I can't fix or extends classes.
Comment 1 Fabian Steeg CLA 2010-09-03 18:45:45 EDT
(In reply to comment #0)

I wrote some tests to reproduce the problem, and the proposed solution of calling fireWidgetSelectedEvent() from setSelection() and selectAll() looks good to me.

It would also fix bug 322054, which is specifically about the selectAll() part.

Ian, can I commit away on zest.core or would you prefer if I attached a patch?
Comment 2 Fabian Steeg CLA 2010-09-03 21:16:23 EDT
Reading up a bit on events in SWT it seems not sending events on programmatic selection changes is actually by design: http://www.eclipse.org/swt/faq.php#noeventfire

So that probably means resolve as WORKSFORME or WONTFIX.
Comment 3 Fabian Steeg CLA 2010-09-03 23:01:09 EDT
OTOH, if we don't send events on programmatic selection changes, we should probably support programmatically notifying the listeners. Currently, calling notifyListeners() on a Graph with registered SelectionListeners has no effect. If I'm not mistaken, we want to be able to do something like this:

graph.notifyListeners(SWT.Selection, event);

I have tweaked the tests for this and implemented notifyListeners() to pass the event wrapped as a SelectionEvent to the listeners. Does this make any sense?
Comment 4 Anthony Hunter CLA 2010-09-07 11:25:28 EDT
Hi Fabian, you are a committer on the Dot4Zest component, not Zest proper. So before you commit anything, I would ask both you and Ian agree by email on gef-dev that everyone is OK with you being a committer on Zest proper. 

Just a formality I suppose, but Ian needs to confirm as component owner.
Comment 5 Fabian Steeg CLA 2010-09-07 12:51:06 EDT
(In reply to comment #4)

I assumed that formally I already could commit on Zest proper, since my nomination was for Zest and dot4zest - but that I should ask before I break anything and not just commit, so I guess it comes down to the same thing :-)
Comment 6 Ian Bull CLA 2010-09-07 13:14:01 EDT
(In reply to comment #5)
> (In reply to comment #4)
> 
> I assumed that formally I already could commit on Zest proper, since my
> nomination was for Zest and dot4zest - but that I should ask before I break
> anything and not just commit, so I guess it comes down to the same thing :-)

If everything works out, Fabian and I are actually going to see each other next week.  We'll chat then, but having an extra Zest committer is actually a good thing, and Fabian has a good handle on the code.
Comment 7 Anthony Hunter CLA 2010-09-07 13:51:56 EDT
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > 
> > I assumed that formally I already could commit on Zest proper, since my
> > nomination was for Zest and dot4zest - but that I should ask before I break
> > anything and not just commit, so I guess it comes down to the same thing :-)
> 
> If everything works out, Fabian and I are actually going to see each other next
> week.  We'll chat then, but having an extra Zest committer is actually a good
> thing, and Fabian has a good handle on the code.

Hi again, I agree 100%, more committers is good. I just wanted to make sure Ian agreed, and sounds like we are good.
Comment 8 Fabian Steeg CLA 2010-09-17 17:22:39 EDT
So this means go for committing the changes and tests?

Ian, is it correct that when done, I change the status to RESOLVED - FIXED and reassign to you for verification?
Comment 9 Ian Bull CLA 2010-09-25 11:26:15 EDT
(In reply to comment #8)
> So this means go for committing the changes and tests?
> 
> Ian, is it correct that when done, I change the status to RESOLVED - FIXED and
> reassign to you for verification?

As I mentioned to Fabian in Germany last week, he can go ahead and release this.  Fabian knows the Zest code as well as anybody, and he is already a GEF/Dot4Zest committer.

Thanks Fabian.
Comment 10 Fabian Steeg CLA 2010-09-26 15:08:41 EDT
(In reply to comment #9)

Awesome - OK, so programmatic notification can now be triggered in HEAD with:

graph.notifyListeners(SWT.Selection, event);

See GraphSelectionTests#testAddSelectionListenerNotifyListeners() for details.