Hi Tom
On 08/01/07, Tom Morris <[EMAIL PROTECTED]> wrote:
> I spent quite some time trying to get the drag mechanism
> working from the explorer to the JList in the prop panel but
> I'm now thinking of backing this out before the next release.
I've got to say that changes to such a fundamental mechanism make me nervous
-- particularly when large sections of code get deleted because we
think/hope they aren't used any more. Even more so when the code appears to
have been designed prevent some type of race condition or loop.
I understand the loop problem that was being solved.
We were using listening to selection changed events to detect when the
user has click on the explorer to change the current selection. We
then update the target list.
But updating the target list changes the selection in the tree and
causes another select changed event we change the targets etc etc etc.
The trap to stop this I suspect was not thread safe.
As we no longer listen for selection changed this problem no longer exists.
These appear to be two entirely new user paradigms for creating
relationships. We currently have three ways of doing this: 1) drawing on
the diagram pane, 2) using context menus on a list in the property panels,
and 3) using tool bar buttons on the property panel (usually #3 is a
composite operation creating a new model element and the relationship to
connect to it). I'm strongly in favor of ways of doing things which don't
require drawing on the diagram, but I'd hate to see us fail to finish
implementation of the current user paradigms before moving on to new
paradigms. Doing this will lead to a UI patchwork that's just going to
confuse the users.
I'm not sure I know the whole path that led us here, but I think it had
something to do with creating dependencies between model elements without
using the diagram pane. This seems like perfect application for #2 above.
Is there a reason we can't use it?
A dependency can exist between any 2 model elements. So a context menu
on the dependency list would need to popup some dialog where the user
can browse to any model element in the repository. But this list
already exists, on the explorer. Why popup what we already have.
That is why I started to think about interacting between the explorer
tree already displayed and the JList with the dependencies.
I became less happy with this solution when I realised creating n-ary
associations didn't fit so well. Nor did creating association classes,
associations can be created by dropping a class into the associations
ends list of another class, but how to do the same for association
classes.
Its only then that the solution that should have been far more obvious
occured to me.
The explorer tree allows you to select multiple items. The actions to
create for these are mostly very simple, usually just delegating to
the model facade to create. There's no GUI to build to prompt the user
for anything.
The reason I had volunteered earlier to step back some of my code was
because some of the techniques I used did push the rather awkward
JTree interface in a way that it's not really designed to be used. It
is fairly close to a stable release to do this.
If the concensus is to step this back but I would still like to see
the explorer context menu remain for creating elements.
Linus has already responded but before seeing this fuller explanation.
What do the other devs think? Step back for now and discuss
reimplementing when we have more time to see if it creates other
issues?
After the next stable release, even if we don't reintroduce the whole
drag drop ability, it may still be worth removing the selection change
listener to get rid of the need for the cycle traps.
Bob.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
