Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: [gef-dev] Re: [Issue 1048] Allow manual adjustment of text label positions on edges

gef
Discussion topic

Hide all messages in topic

All messages in topic

Re: [gef-dev] Re: [Issue 1048] Allow manual adjustment of text label positions on edges

Reply

Author bobtarling
Full name Bob Tarling
Date 2008-12-19 08:05:23 PST
Message 2008/12/19 Dave Thompson <argouml at davet dot org>:
> Contention: Inevitably a new mode implementation will be to add some
> additional functionality on top of the existing feature set. For this reason
> anyone creating a new custom mode will probably want his mode to be first in
> the stack. In an application where everyone assumes that their mode is still
> the first, and takes precedence over the others, we may have a conflict, or
> unexpected behaviour. It probably just means we need to manage this
> carefully, and do thorough regression testing any time we add new Modes.

Yes, that could be a problem. Not so much for a single application
like ArgoUML but more likely for 3rd party module writers.

> Inefficiencies: As I understand it, most of the modes in the stack
> effectively scan the whole of the active diagram in the editor, one Fig at a
> time, in order to see if that Fig was under the mouse for a given click. If
> no event is consumed, the event goes to the next Mode in the stack. My
> concern is that for a large diagram with a lot of modes, there might be a lot
> of scanning before any match was found. This might slow down the UI's
> responsiveness to mouse clicks, worsening the user experience. But we
> needn't worry about this unless it becomes a problem.

Maybe ModeManager should determine the underlying top level Fig and
make that available to each Mode.

I also had an idea for efficient searching of a Layer to find a Fig at
a specific co-ordinate by use of a specialist collection class.

Imagine the layer broken into vertical strips 100 pixels wide. Each
strip has its own Fig collection.

As a Fig is dropped on a layer the layer determines what strips the
Fig overlaps and adds the Fig to each strips collection.

When given a co-ordinate the layer can then determine first which
strip was clicked in and use that smaller collection to find the
actual Fig.

Hopefully the complexities of this can be hidden on a specialist List
class for all Figs in the Layer.

Without knowing we have a need for this it seems complicated
architecture to create for the sake of it though.

Bob.

[gef-dev] Re: [Issue 1048] Allow manual adjustment of text label positions on edges

Reply

Author dthompson
Full name Dave Thompson
Date 2008-12-19 07:48:43 PST
Message Continuing this discussion on gef dev list...

Yes, you are right, the new ModeFactories should make this easier. I do feel
that there may be some contention or possibly inefficiencies that could arise
from using it too much though.

Contention: Inevitably a new mode implementation will be to add some
additional functionality on top of the existing feature set. For this reason
anyone creating a new custom mode will probably want his mode to be first in
the stack. In an application where everyone assumes that their mode is still
the first, and takes precedence over the others, we may have a conflict, or
unexpected behaviour. It probably just means we need to manage this
carefully, and do thorough regression testing any time we add new Modes.

Inefficiencies: As I understand it, most of the modes in the stack
effectively scan the whole of the active diagram in the editor, one Fig at a
time, in order to see if that Fig was under the mouse for a given click. If
no event is consumed, the event goes to the next Mode in the stack. My
concern is that for a large diagram with a lot of modes, there might be a lot
of scanning before any match was found. This might slow down the UI's
responsiveness to mouse clicks, worsening the user experience. But we
needn't worry about this unless it becomes a problem.

My experience is mostly with embedded systems, where efficiencies are
important. I often forget that PC applications can perform several million
instructions in one millisecond, so maybe this doesn't matter to GEF/ArgoUML.

Regards,

Dave


Bob Tarling wrote:
> Yes, Modes are very useful in separating responsibilities to different classes.
>
> They're much underused. The new framework provided by the
> ModeFactories will hopefully allow us to more easily implement other
> interactions.
>
> I'm thinking about using this to allow the user to drag activations
> around on the new sequence diagrams.
>
> Cheers
>
> Bob.
>
>
> 2008/12/17 Dave Thompson <argouml at davet dot org>:
>> Hi Bob,
>>
>> I think the new mode seemed the safest way to go, because it allows me
>> to isolate the new behaviour to one specific action. The way it was
>> working the other way, seemed to be a side-effect, and although it
>> appeared to work, it didn't really, and probably created more problems
>> than it solved.
>>
>> Anyway, I'll keep at it, but I've not been able to spend much time on it
>> over the last week.
>>
>> Dave
Messages per page: