|
| Re: Rationale for non-modelChildren links in EDiagram [message #192404 is a reply to message #192356] |
Thu, 18 August 2005 17:40   |
Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
> The normal policy for a hierarchical EditPart is for getModelChildren() to
> returns its child models that get correlated with its EditPart children by
> refreshChildren().
>
> In EDiagram, the nodes (on the FreeForm layer) follow this policy but the
> links (on the Connection layer) do not. Failure to follow the standard
> protocol means that operations such as SELECT_ALL fail to select the
> links.
> Changing getModelChildren() to return both nodes and links leads to a
> variety of disasters as the assumption that the FreeForm layer Figure
> children
> correlate with the EditPart children is then violated.
>
> What is/was the rationale behind this design decision? With hindsight
> was it a good one?
Are you saying that because of the way we intentionally designed one action,
the connection architecture is flawed? It would be simple to write a
different select all action that selected connection with the nodes.
> Possibly related. Neither Selection nor Marquee tools are able to select
> links from a dragged area selection. With a bit of programming effort a
> Marquee
> properties can be changed to support Node+Link selection. The LogicDiagram
> example has 3 Marquees, but all sharing the same icon and text label.
The distinction, both icon and terminology, are application specific and
there is not really anything we could enforce across all GEF clients.
> Is there any longer any useful distinction between the Selection and
> Marquee tools other than to give slightly different imperfections?
I'm not sure I understand the question. The selection tool is in to way
similar to the marquee. There are now three different marquee modes. Are you
saying none of them are correct for your application?
|
|
|
|
| Re: Rationale for non-modelChildren links in EDiagram [message #192441 is a reply to message #192404] |
Thu, 18 August 2005 18:12 |
| Eclipse User |
|
|
|
Originally posted by: sunil_kamath.nohotspammail.com
"Randy Hudson" <none@us.ibm.com> wrote in message
news:de2h6g$sin$1@news.eclipse.org...
[snip]
>
>> Is there any longer any useful distinction between the Selection and
>> Marquee tools other than to give slightly different imperfections?
>
> I'm not sure I understand the question. The selection tool is in to way
> similar to the marquee. There are now three different marquee modes.
> [snip]
Are there any plans to create a marquee behavior like
BEHAVIOR_NODES_TOUCHED? (It should be fairly easy to implement).
Should I file a feature request?
---
Sunil
|
|
|
|
| Re: Rationale for non-modelChildren links in EDiagram [message #192486 is a reply to message #192456] |
Thu, 18 August 2005 22:11 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
> No. I'm saying that because of a design decision to not follow the
> getModelChildren()
> protocol, all other functionality relying on getModelChildren() is
> undermined.
> I tried to 'correct' getModelChildren() without success, so had to pursue
> the
> fix-all-consumers policy. Writing a custom select-all action was indeed
> easy. I
> just don't like having to fix-up consumers of a broken protocol; sometimes
> the
> consumers prove to be in package or private contexts.
Can you please explain what is not following the getModelChildren protocol?
Children is a specific relationship on editpart, it is not "all contents" or
"all owned elements".
> Yes. Nodes and Links looks good. My struggle is to understand what
> 'Marquee'
> means. In English there is no such verb. I can't find any documentation. I
> found one newsgroup reply from you that seemed to suggest that Marquee was
> redundant.
- Selection means *object* selection, so if you click on a part you will
pick it up and drag it
- Marquee means "lasso" selection, meaning no matter what you do (even click
on a part), you will still be dragging a rectangle that selects the parts
inside the rectangle. You typically then have to switch back to the
selection tool to move them.
In many applications, selection is overloaded so that if you click on an
area that is not draggable, a marquee rectangle is activated. This is why
marquee is also a drag tracker.
|
|
|
| Re: Rationale for non-modelChildren links in EDiagram [message #192493 is a reply to message #192441] |
Thu, 18 August 2005 22:12 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
I believe someone has recently filed such an enhancement, quoting the 50%
rule used on the windows desktop. Are you saying you want the >0% rule?
"Sunil Kamath" <sunil_kamath@nohotspammail.com> wrote in message
news:de2j3c$usk$1@news.eclipse.org...
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:de2h6g$sin$1@news.eclipse.org...
> [snip]
>>
>>> Is there any longer any useful distinction between the Selection and
>>> Marquee tools other than to give slightly different imperfections?
>>
>> I'm not sure I understand the question. The selection tool is in to way
>> similar to the marquee. There are now three different marquee modes.
>> [snip]
>
> Are there any plans to create a marquee behavior like
> BEHAVIOR_NODES_TOUCHED? (It should be fairly easy to implement).
> Should I file a feature request?
> ---
> Sunil
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.03240 seconds
] 
Search
Help
Register
Login
Home
