Re: [e4-dev] Certain model selection events not being propagated

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

We've talked about this at the meeting
and rather than changing the event mechanism to forward model events which
are effectively no-ops the fix may be to implement a number of 'events'
that are specifically thrown when particular operations are performed.
The three we've been able to identify so far are (the actual event topics
are still being worked out):

The idea here is that we're publishing
that the *intent* was to make the change, even if it doesn't result in
structural changes...

BringToTopEvent: published whenever
the ModelService's 'bringToTop' method is called (whether or not it was
already on top)

ActivatedEvent: published whenever a
call to the PartService's 'activate' method is called (even if it's already
the active part)

RenderingComplete: published by the
rendering engine once a non-recursive call to 'createGui' completes.

Can anybody think of other situations
where this may be useful ?? This is mostly for cases where simply listening
to the model isn't enough...

Onwards,
Eric

From:	Dean Roberts/Ottawa/IBM@IBMCA
To:	e4-dev@xxxxxxxxxxx
Date:	09/08/2011 10:01 AM
Subject:	[e4-dev] Certain model selection events not being propagated
Sent by:	e4-dev-bounces@xxxxxxxxxxx

---

Currently the UI model does not propagate
selected element events if the selected element is the same element that
was previously selected.  I believe that this decision is being made
too far down the model.  I believe that when modeling a presentation
layer, selection events are important even if the item being selected has
not changed. 

One example is opening and closing a fast view by clicking on its tool
bar item.  In the current code base this works, but only through a
hack that has model service code injecting directly into an add-on.  As
part of work on a different defect, Eric asked me to look at cleaning this
up. 

A more "correct" way to accomplish this would be to have the
TrimStack subscribe to ElementContainer SelectedElement events.  The
problem is that when the tool tips is pressed the first time, a selection
event is sent as the selection changes to the PartStack containing the
fast view tool items.  However, once open, clicking on the tool item
will NOT send an event because the PartStack being selected, is still the
same PartStack. 

Similarly, while working on a fix for (bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=340875
- Opening file from minimized package explorer does not switch to  editor)
I encountered the same kind of problem exists. 

By listening for selection events in the editor area, you can minimize
the package explorer fast view when a new editor is selected.  However,
if the same editor is selected no selection event is sent.

I would argue that while MANY event handlers won't care about selection
events where the selection does not change, it should be left up to each
event handler to make this decision.  There are valid reasons a UI
presentation would care about all selection events.

Perhaps we could make a 2nd selection event that fires for all selections,
even those where the selected item does not change.  This would minimize
the impact on existing code. 

Despite the short notice, perhaps we could talk about this on today's call.

Dean_Roberts@xxxxxxxxxx
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev