|
| Re: MarqueeSelectionTool [message #138772 is a reply to message #138725] |
Fri, 18 June 2004 13:21   |
Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
"Maged Elaasar" <melaasar@ca.ibm.com> wrote in message
news:casut0$b1h$1@eclipse.org...
> Hello,
>
> I wonder if you have feedback about those two issues:
>
> 1- Marquee selection tool does not currently select connectors falling in
> selection box.
This is intentional since the propertysheet shows only common properties.
Nodes and connections would not have very many common properties. Also, the
user can delete the nodes and the connection will be deleted. The same for
moving.
> 2- Marquee selection tool gets the children editparts falling inside the
> selection box starting from the root editpart. That makes the reuse of the
> tool for nested containers hard since it could select editparts falling
> within the selection box but in lower z-order to that of the container.
Open bugzillas with any suggested changes. What is the container in your
scenario?
> Are these by design? defect? Please advise...and by the way it is not easy
> to extend of the tool to change the behavior since a lot of the important
> methods are private.
>
> Maged Elaasar
> melaasar@ca.ibm.com
>
>
|
|
|
|
| Re: MarqueeSelectionTool [message #138819 is a reply to message #138796] |
Fri, 18 June 2004 19:30 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
> I think it depends on the application whether nodes and connectors share a
> lot of common properties or not. Also, there are many reasons a user would
> use the marquee box including for example copy/paste which produces
> different result when having the connectors in the selection than when
not.
So if a connection is selected, but only one of its nodes is selected, does
that connection get copied as well? What happens if I paste into an empty
diagram? You can't paste the node and connection but not the other
endpoint, can you?
> I don't think totally preventing this functionality based on this
assumption
> is justified.
>
> I would suggest for example using a modifier key like (CTRL or ALT) along
> with the marquee tool to distinguish both modes. I would say selecting
every
> thing would be default, and selecting nodes only would go with a modifier
> key but I don't have a strong opinion about that. What do you think?
Other editors have extended the marquee tool such that it selects
connections if the marquee encompasses the nodes at either end. You could
also create actions which select the connections among the currently
selected nodes.
I'm not sure you would like the results. Connections are not rectangular so
using a rectangular marquee is unintuitive. The current behavior is that
you must encompass the bounds, not just intersect it some.
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:cauq94$4l3$1@eclipse.org...
> >
> > "Maged Elaasar" <melaasar@ca.ibm.com> wrote in message
> > news:casut0$b1h$1@eclipse.org...
> > > Hello,
> > >
> > > I wonder if you have feedback about those two issues:
> > >
> > > 1- Marquee selection tool does not currently select connectors falling
> in
> > > selection box.
> >
> > This is intentional since the propertysheet shows only common
properties.
> > Nodes and connections would not have very many common properties. Also,
> the
> > user can delete the nodes and the connection will be deleted. The same
> for
> > moving.
> >
> > > 2- Marquee selection tool gets the children editparts falling inside
the
> > > selection box starting from the root editpart. That makes the reuse of
> the
> > > tool for nested containers hard since it could select editparts
falling
> > > within the selection box but in lower z-order to that of the
container.
> >
> > Open bugzillas with any suggested changes. What is the container in
your
> > scenario?
> >
> > > Are these by design? defect? Please advise...and by the way it is not
> easy
> > > to extend of the tool to change the behavior since a lot of the
> important
> > > methods are private.
> > >
> > > Maged Elaasar
> > > melaasar@ca.ibm.com
> > >
> > >
> >
> >
>
>
|
|
|
| Re: MarqueeSelectionTool [message #139756 is a reply to message #138819] |
Wed, 23 June 2004 18:25 |
 Maged Elaasar
Messages: 529
Registered: July 2009 |
Senior Member |
|
|
In the copy/paste scenario, both connector ends have to be selected for it
to be copied, however it the connectors were not in the selection, copy will
not include them. I guess, what I am saying is that we should not make
assumptions about the intended use of Marquee...it is a tool for selecting
editparts encompassed within a selection box. Therefore, it should get every
thing there, whether it is a shape or connector.
In the case of connectors, the connector has to be fully enclosed within the
box (including all its bend points) to be selected. I wasn't suggesting
partial intersecting as a criteria.
"Randy Hudson" <none@us.ibm.com> wrote in message
news:cavfsc$e7v$1@eclipse.org...
> > I think it depends on the application whether nodes and connectors share
a
> > lot of common properties or not. Also, there are many reasons a user
would
> > use the marquee box including for example copy/paste which produces
> > different result when having the connectors in the selection than when
> not.
>
> So if a connection is selected, but only one of its nodes is selected,
does
> that connection get copied as well? What happens if I paste into an empty
> diagram? You can't paste the node and connection but not the other
> endpoint, can you?
>
> > I don't think totally preventing this functionality based on this
> assumption
> > is justified.
> >
> > I would suggest for example using a modifier key like (CTRL or ALT)
along
> > with the marquee tool to distinguish both modes. I would say selecting
> every
> > thing would be default, and selecting nodes only would go with a
modifier
> > key but I don't have a strong opinion about that. What do you think?
>
> Other editors have extended the marquee tool such that it selects
> connections if the marquee encompasses the nodes at either end. You could
> also create actions which select the connections among the currently
> selected nodes.
>
> I'm not sure you would like the results. Connections are not rectangular
so
> using a rectangular marquee is unintuitive. The current behavior is that
> you must encompass the bounds, not just intersect it some.
>
> > "Randy Hudson" <none@us.ibm.com> wrote in message
> > news:cauq94$4l3$1@eclipse.org...
> > >
> > > "Maged Elaasar" <melaasar@ca.ibm.com> wrote in message
> > > news:casut0$b1h$1@eclipse.org...
> > > > Hello,
> > > >
> > > > I wonder if you have feedback about those two issues:
> > > >
> > > > 1- Marquee selection tool does not currently select connectors
falling
> > in
> > > > selection box.
> > >
> > > This is intentional since the propertysheet shows only common
> properties.
> > > Nodes and connections would not have very many common properties.
Also,
> > the
> > > user can delete the nodes and the connection will be deleted. The
same
> > for
> > > moving.
> > >
> > > > 2- Marquee selection tool gets the children editparts falling inside
> the
> > > > selection box starting from the root editpart. That makes the reuse
of
> > the
> > > > tool for nested containers hard since it could select editparts
> falling
> > > > within the selection box but in lower z-order to that of the
> container.
> > >
> > > Open bugzillas with any suggested changes. What is the container in
> your
> > > scenario?
> > >
> > > > Are these by design? defect? Please advise...and by the way it is
not
> > easy
> > > > to extend of the tool to change the behavior since a lot of the
> > important
> > > > methods are private.
> > > >
> > > > Maged Elaasar
> > > > melaasar@ca.ibm.com
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: MarqueeSelectionTool [message #139778 is a reply to message #139756] |
Wed, 23 June 2004 18:42 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
"Maged Elaasar" <melaasar@ca.ibm.com> wrote in message
news:cbchu4$7pg$1@eclipse.org...
> In the copy/paste scenario, both connector ends have to be selected for it
> to be copied, however it the connectors were not in the selection, copy
will
> not include them. I guess, what I am saying is that we should not make
> assumptions about the intended use of Marquee...it is a tool for selecting
> editparts encompassed within a selection box. Therefore, it should get
every
> thing there, whether it is a shape or connector.
>
> In the case of connectors, the connector has to be fully enclosed within
the
> box (including all its bend points) to be selected. I wasn't suggesting
> partial intersecting as a criteria.
I was suggesting it. I don't think the user thinks of bounding boxes when
he looks at connections in a diagram. I have a painting program with
something similar to marquee, but it only requires interection of the shape.
I find it much easier to use than normal marquee tools. There are tons of
possible options for marquee/grabber tools. You could even offer the user
several in a PaletteStack. Open a bugzilla with the features you want.
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:cavfsc$e7v$1@eclipse.org...
> > > I think it depends on the application whether nodes and connectors
share
> a
> > > lot of common properties or not. Also, there are many reasons a user
> would
> > > use the marquee box including for example copy/paste which produces
> > > different result when having the connectors in the selection than when
> > not.
> >
> > So if a connection is selected, but only one of its nodes is selected,
> does
> > that connection get copied as well? What happens if I paste into an
empty
> > diagram? You can't paste the node and connection but not the other
> > endpoint, can you?
> >
> > > I don't think totally preventing this functionality based on this
> > assumption
> > > is justified.
> > >
> > > I would suggest for example using a modifier key like (CTRL or ALT)
> along
> > > with the marquee tool to distinguish both modes. I would say selecting
> > every
> > > thing would be default, and selecting nodes only would go with a
> modifier
> > > key but I don't have a strong opinion about that. What do you think?
> >
> > Other editors have extended the marquee tool such that it selects
> > connections if the marquee encompasses the nodes at either end. You
could
> > also create actions which select the connections among the currently
> > selected nodes.
> >
> > I'm not sure you would like the results. Connections are not
rectangular
> so
> > using a rectangular marquee is unintuitive. The current behavior is
that
> > you must encompass the bounds, not just intersect it some.
> >
> > > "Randy Hudson" <none@us.ibm.com> wrote in message
> > > news:cauq94$4l3$1@eclipse.org...
> > > >
> > > > "Maged Elaasar" <melaasar@ca.ibm.com> wrote in message
> > > > news:casut0$b1h$1@eclipse.org...
> > > > > Hello,
> > > > >
> > > > > I wonder if you have feedback about those two issues:
> > > > >
> > > > > 1- Marquee selection tool does not currently select connectors
> falling
> > > in
> > > > > selection box.
> > > >
> > > > This is intentional since the propertysheet shows only common
> > properties.
> > > > Nodes and connections would not have very many common properties.
> Also,
> > > the
> > > > user can delete the nodes and the connection will be deleted. The
> same
> > > for
> > > > moving.
> > > >
> > > > > 2- Marquee selection tool gets the children editparts falling
inside
> > the
> > > > > selection box starting from the root editpart. That makes the
reuse
> of
> > > the
> > > > > tool for nested containers hard since it could select editparts
> > falling
> > > > > within the selection box but in lower z-order to that of the
> > container.
> > > >
> > > > Open bugzillas with any suggested changes. What is the container in
> > your
> > > > scenario?
> > > >
> > > > > Are these by design? defect? Please advise...and by the way it is
> not
> > > easy
> > > > > to extend of the tool to change the behavior since a lot of the
> > > important
> > > > > methods are private.
> > > > >
> > > > > Maged Elaasar
> > > > > melaasar@ca.ibm.com
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.03290 seconds
] 
Search
Help
Register
Login
Home
