Home » Archived » Visual Editor (VE) » How to move components to a sub-panel?
| How to move components to a sub-panel? [message #100563] |
Wed, 27 July 2005 20:09  |
 Joel Kamentz
Messages: 30
Registered: July 2009 |
Member |
|
|
Perhaps I'm missing something, but it seems very frustrating trying to
create the layout I want with VE.
I'm designing a dialog. (VE doesn't appear to support dialogs, so I'm using
VE to design a Composite which I then plan to display in a Dialog subclass.
For that matter, even doing this seems more difficult than it should be.
Are there any easy dialog classes to host my content in an ok/cancel
fashion? In Swing, JOptionPane had the option of displaying an arbitrary
component instead of a simple message or text field. And, with Swing/AWT
dialogs in general, it's fairly easy to create a generic dialog and just add
some content to it. For SWT / JFace it seems I'm forced to subclass
Dialog?)
Since VE doesn't support FormLayout, and the other choices -- fill, flow and
grid -- are somewhat limited, achieving the layout I want requires nesting
Composites. However, I keep running into the case where, as I'm
experimenting arranging things, I then decide I need to take some existing
components and nest them and then put the new composite in their place.
Some problems trying to do this are:
1) I can't seem to just drag-n-drop the components / controls in order to
move them into a newly created composite / group or other container
2) Cutting and pasting seems to trash field names and otherwise disrupt any
even handlers I may have created. For example, I have a scale and a label
associated with it which textually displays the value which the scale
represents.
3) Why, why, why is the event for a value change called widget selection?
4) I tried avoiding some of problem 2 by cutting-and-pasting multiple
controls at once. Unfortunately this isn't possible -- can only cut / copy
one thing at a time.
Some other hindrances which I've encountered:
Imagine some nested composites and one of them has a grid layout like:
| A | B | C
_________
| D | B | E
where component B has vertical span of 2 and D is a composite. (Actually,
the problem would probably still occur with a simple 2x2 grid with none of
the cells being occupied by a composite.)
Try swapping D and A, or otherwise dragging to re-arrange things. I've run
into all sorts of slow-downs including explosions of label placeholders,
etc. I've concluded that in many cases the only reasonable way to get
things done is to do cut-and-paste within the source code. Unfortunately,
this tends to lead to orphaned or missing GridData instances and generally
seems to cause VE some confusion or trouble (at least some times).
Am I just ignorant of the proper UI interactions to do some of this stuff?
Would it be possible to add arrangement operations like swapping components
which are siblings? How about being able to marquee-select some stuff and
having group/ungroup commands which would wrap them in a composite?
It would also be cool if I could select a composite in the bean tree (or in
the visual) have a popup menu command that would allow me to change the
Composite to a Group or some other container class.
Joel
|
|
|
| Re: How to move components to a sub-panel? [message #100577 is a reply to message #100563] |
Thu, 28 July 2005 09:27  |
Joe Winchester
Messages: 496
Registered: July 2009 |
Senior Member |
|
|
Hi Joel,
> I'm designing a dialog. (VE doesn't appear to support dialogs, so I'm using
> VE to design a Composite which I then plan to display in a Dialog subclass.
> For that matter, even doing this seems more difficult than it should be.
> Are there any easy dialog classes to host my content in an ok/cancel
> fashion? In Swing, JOptionPane had the option of displaying an arbitrary
> component instead of a simple message or text field. And, with Swing/AWT
> dialogs in general, it's fairly easy to create a generic dialog and just add
> some content to it. For SWT / JFace it seems I'm forced to subclass
> Dialog?)
In Eclipse for a dialog subclassing Dialog is the way to achieve what
you want. The Swing JOptionPane's "component" property is a nice
feature that the VE supports, however as you point our we don't parse
the Dialog subclass pattern at the moment. We do have a bugzilla for
this https://bugs.eclipse.org/bugs/show_bug.cgi?id=100145 so if you add
yourself as a cc member you can track its progress.
> Since VE doesn't support FormLayout, and the other choices -- fill, flow and
> grid -- are somewhat limited, achieving the layout I want requires nesting
> Composites.
For FormLayout we have a bugzilla
https://bugs.eclipse.org/bugs/show_bug.cgi?id=77683. For grid what part
of it do you find limiting ? Release 1.1 has made a number of
improvements to how it works and there is a nice viewlet Gili did at
http://www.eclipse.org/vep/WebContent/docs/v1.1/VE11grid.htm l that shows
how the new feedback creates rows and columns for you automatically
adding spacers. If you have any specific ideas or suggestions for how
Grid could be made better please feed these back to us.
> However, I keep running into the case where, as I'm
> experimenting arranging things, I then decide I need to take some existing
> components and nest them and then put the new composite in their place.
> Some problems trying to do this are:
>
> 1) I can't seem to just drag-n-drop the components / controls in order to
> move them into a newly created composite / group or other container
Right now moving between containers is restricted because there were
issues with code generation. We would have to move the lines of code
for the control between methods, and if this has things like events
attached to it or comments we would also possibly have to move this.
The temporary fix was to disallow moving however we should revisit this
and come up with a good solution that allows moving between containers
whilst preserving the code as much as possible. The bugzilla is
https://bugs.eclipse.org/bugs/show_bug.cgi?id=71661
> 2) Cutting and pasting seems to trash field names and otherwise disrupt any
> even handlers I may have created. For example, I have a scale and a label
> associated with it which textually displays the value which the scale
> represents.
When you copy and paste we don't bring over the field name however we
should. I hadn't appreciated till you pointed it out that for cut and
paste it is even more important, because what you are effectively doing
is deleting and re-inserting so the old field name would be applicable
to bring over. I've opened a bugzilla
https://bugs.eclipse.org/bugs/show_bug.cgi?id=105420 for this so please
add yourself as a cc member and you can track its progress
> 3) Why, why, why is the event for a value change called widget selection?
The names we use on events comes from the method signature of the
control itself. For an SWT Button the API for adding a listener for
when the button is pressed is
button.addSelectionListener(SelectionListener listener);
and the interface
public interface SelectionListener extends SWTEventListener{
public void widgetSelected(SelectionEvent e);
public void widgetDefaultSelected(SelectionEvent e);
}
The VE picks this up by introspection and names the event "widgetSelected".
The VE support runtimes like Swing/AWT/SWT and RCP but we try to avoid
doing things like changing terminology so we use the naming that SWT
itself uses. I think the reason the event is called widgetSelected is
due to how SWT dispatches the event - the Shell gets a top level event
that it dispatches to the control with focus and they all share the same
listener type, but for a proper history of why it is called
"widgetSelected" you might get a better reply from one of the SWT team
on their newsgroup.
> 4) I tried avoiding some of problem 2 by cutting-and-pasting multiple
> controls at once. Unfortunately this isn't possible -- can only cut / copy
> one thing at a time.
This is something we are also planning to support - right now we only
allow copy and paste of one top level control at a time, although if you
select a Composite with children (and children therefor) the entire
graph of ojects is copied. For copy of >1 object there I opened a
bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=105421.
> Some other hindrances which I've encountered:
> Imagine some nested composites and one of them has a grid layout like:
>
> | A | B | C
> _________
> | D | B | E
>
> where component B has vertical span of 2 and D is a composite. (Actually,
> the problem would probably still occur with a simple 2x2 grid with none of
> the cells being occupied by a composite.)
>
> Try swapping D and A, or otherwise dragging to re-arrange things. I've run
> into all sorts of slow-downs including explosions of label placeholders,
> etc. I've concluded that in many cases the only reasonable way to get
> things done is to do cut-and-paste within the source code. Unfortunately,
> this tends to lead to orphaned or missing GridData instances and generally
> seems to cause VE some confusion or trouble (at least some times).
When you use GridLayout there are two kinds of feedback - one where you
get a yellow line because a new row/column is going to be created and
another where you get a grey/black square where something is going to be
inserted/replaced in a cell. I tried some swopping of D and A and
from the feedback I was getting it looks like they aren't being swopped,
but instead the D is being orphaned from its position and the yellow bar
indicates a new row/column is being created. Peter Walker is the
developer on this and knows most about the logic involved so I'll defer
to him when he gets in later (I work in the UK and he works in the US).
> Am I just ignorant of the proper UI interactions to do some of this stuff?
Nope. It's our intention that the GUI feedback should be intuitive so
if it doesn't work for you then it's a failure on our part and your
feedback is great.
> Would it be possible to add arrangement operations like swapping components
> which are siblings?
I think we should support this - wait till Peter replies cause maybe we
intend to and it's a bug, or else it's something deliberately disabled
that we need to think about.
>How about being able to marquee-select some stuff and
> having group/ungroup commands which would wrap them in a composite?
Both of these are great ideas. For the latter other people have asked
for this kind of group/ungroup facility and this is actually one of the
scenarios being covered in a VE tutorial being prepared at this very
moment. This tutorial will have the functionality for grouping and
morphing and also document in detail how these occur so that people
wanting to do their own VE plugins can understand how the actions
manipulate the model.
> It would also be cool if I could select a composite in the bean tree (or in
> the visual) have a popup menu command that would allow me to change the
> Composite to a Group or some other container class.
Right - this is the "morphing" capability that is being covered as part
of the tutorial.
Thanks very much for your feedback. Some of what you want is in plan so
add yourself as a cc member to the bugzilla requests and you can track
when they get implemented as well as give feedback to the discussions
that occur there.
Best regards,
Joe Winchester
|
|
|
| Re: How to move components to a sub-panel? [message #610050 is a reply to message #100563] |
Thu, 28 July 2005 09:27 |
Joe Winchester
Messages: 496
Registered: July 2009 |
Senior Member |
|
|
Hi Joel,
> I'm designing a dialog. (VE doesn't appear to support dialogs, so I'm using
> VE to design a Composite which I then plan to display in a Dialog subclass.
> For that matter, even doing this seems more difficult than it should be.
> Are there any easy dialog classes to host my content in an ok/cancel
> fashion? In Swing, JOptionPane had the option of displaying an arbitrary
> component instead of a simple message or text field. And, with Swing/AWT
> dialogs in general, it's fairly easy to create a generic dialog and just add
> some content to it. For SWT / JFace it seems I'm forced to subclass
> Dialog?)
In Eclipse for a dialog subclassing Dialog is the way to achieve what
you want. The Swing JOptionPane's "component" property is a nice
feature that the VE supports, however as you point our we don't parse
the Dialog subclass pattern at the moment. We do have a bugzilla for
this https://bugs.eclipse.org/bugs/show_bug.cgi?id=100145 so if you add
yourself as a cc member you can track its progress.
> Since VE doesn't support FormLayout, and the other choices -- fill, flow and
> grid -- are somewhat limited, achieving the layout I want requires nesting
> Composites.
For FormLayout we have a bugzilla
https://bugs.eclipse.org/bugs/show_bug.cgi?id=77683 For grid what part
of it do you find limiting ? Release 1.1 has made a number of
improvements to how it works and there is a nice viewlet Gili did at
http://www.eclipse.org/vep/WebContent/docs/v1.1/VE11grid.htm l that shows
how the new feedback creates rows and columns for you automatically
adding spacers. If you have any specific ideas or suggestions for how
Grid could be made better please feed these back to us.
> However, I keep running into the case where, as I'm
> experimenting arranging things, I then decide I need to take some existing
> components and nest them and then put the new composite in their place.
> Some problems trying to do this are:
>
> 1) I can't seem to just drag-n-drop the components / controls in order to
> move them into a newly created composite / group or other container
Right now moving between containers is restricted because there were
issues with code generation. We would have to move the lines of code
for the control between methods, and if this has things like events
attached to it or comments we would also possibly have to move this.
The temporary fix was to disallow moving however we should revisit this
and come up with a good solution that allows moving between containers
whilst preserving the code as much as possible. The bugzilla is
https://bugs.eclipse.org/bugs/show_bug.cgi?id=71661
> 2) Cutting and pasting seems to trash field names and otherwise disrupt any
> even handlers I may have created. For example, I have a scale and a label
> associated with it which textually displays the value which the scale
> represents.
When you copy and paste we don't bring over the field name however we
should. I hadn't appreciated till you pointed it out that for cut and
paste it is even more important, because what you are effectively doing
is deleting and re-inserting so the old field name would be applicable
to bring over. I've opened a bugzilla
https://bugs.eclipse.org/bugs/show_bug.cgi?id=105420 for this so please
add yourself as a cc member and you can track its progress
> 3) Why, why, why is the event for a value change called widget selection?
The names we use on events comes from the method signature of the
control itself. For an SWT Button the API for adding a listener for
when the button is pressed is
button.addSelectionListener(SelectionListener listener);
and the interface
public interface SelectionListener extends SWTEventListener{
public void widgetSelected(SelectionEvent e);
public void widgetDefaultSelected(SelectionEvent e);
}
The VE picks this up by introspection and names the event "widgetSelected".
The VE support runtimes like Swing/AWT/SWT and RCP but we try to avoid
doing things like changing terminology so we use the naming that SWT
itself uses. I think the reason the event is called widgetSelected is
due to how SWT dispatches the event - the Shell gets a top level event
that it dispatches to the control with focus and they all share the same
listener type, but for a proper history of why it is called
"widgetSelected" you might get a better reply from one of the SWT team
on their newsgroup.
> 4) I tried avoiding some of problem 2 by cutting-and-pasting multiple
> controls at once. Unfortunately this isn't possible -- can only cut / copy
> one thing at a time.
This is something we are also planning to support - right now we only
allow copy and paste of one top level control at a time, although if you
select a Composite with children (and children therefor) the entire
graph of ojects is copied. For copy of >1 object there I opened a
bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=105421
> Some other hindrances which I've encountered:
> Imagine some nested composites and one of them has a grid layout like:
>
> | A | B | C
> _________
> | D | B | E
>
> where component B has vertical span of 2 and D is a composite. (Actually,
> the problem would probably still occur with a simple 2x2 grid with none of
> the cells being occupied by a composite.)
>
> Try swapping D and A, or otherwise dragging to re-arrange things. I've run
> into all sorts of slow-downs including explosions of label placeholders,
> etc. I've concluded that in many cases the only reasonable way to get
> things done is to do cut-and-paste within the source code. Unfortunately,
> this tends to lead to orphaned or missing GridData instances and generally
> seems to cause VE some confusion or trouble (at least some times).
When you use GridLayout there are two kinds of feedback - one where you
get a yellow line because a new row/column is going to be created and
another where you get a grey/black square where something is going to be
inserted/replaced in a cell. I tried some swopping of D and A and
from the feedback I was getting it looks like they aren't being swopped,
but instead the D is being orphaned from its position and the yellow bar
indicates a new row/column is being created. Peter Walker is the
developer on this and knows most about the logic involved so I'll defer
to him when he gets in later (I work in the UK and he works in the US).
> Am I just ignorant of the proper UI interactions to do some of this stuff?
Nope. It's our intention that the GUI feedback should be intuitive so
if it doesn't work for you then it's a failure on our part and your
feedback is great.
> Would it be possible to add arrangement operations like swapping components
> which are siblings?
I think we should support this - wait till Peter replies cause maybe we
intend to and it's a bug, or else it's something deliberately disabled
that we need to think about.
>How about being able to marquee-select some stuff and
> having group/ungroup commands which would wrap them in a composite?
Both of these are great ideas. For the latter other people have asked
for this kind of group/ungroup facility and this is actually one of the
scenarios being covered in a VE tutorial being prepared at this very
moment. This tutorial will have the functionality for grouping and
morphing and also document in detail how these occur so that people
wanting to do their own VE plugins can understand how the actions
manipulate the model.
> It would also be cool if I could select a composite in the bean tree (or in
> the visual) have a popup menu command that would allow me to change the
> Composite to a Group or some other container class.
Right - this is the "morphing" capability that is being covered as part
of the tutorial.
Thanks very much for your feedback. Some of what you want is in plan so
add yourself as a cc member to the bugzilla requests and you can track
when they get implemented as well as give feedback to the discussions
that occur there.
Best regards,
Joe Winchester
|
|
|
Goto Forum:
Current Time: Thu Apr 25 13:27:47 GMT 2024
Powered by FUDForum. Page generated in 0.02809 seconds |
] 
Search
Help
Register
Login
Home
