Community
Participate
Working Groups
I tend to use JPanels with the BorderLayout to position things, including new JPanels with BorderLayout inside of it, and when you get nested two to three times with this it basically turns hard to work with as you need to position the mouse very, very carefully to put it in the right place. More than once it was easier to put the object in the NORTH and then change it to SOUTH in the source view. My initial brainstorming suggest the following: * It should be possible to zoom in and out of the GUI representation similar to what is possible in Word and Acrobat Reader, i.e. 200% to get in close. This would make it easier to position the mouse. * An intuitive way to use visual classes inside other classes. I did not figure out how to do this? Use one class as a bean in another? Or a JPanel? In this way I could design parts and combine them at the end. A potential problem could be that it would be inconvenient if the embedded visual class had to obey the sizing given by the user at design time. (While writing this I realize that I needed a "Pack current layout to its smallest reasonable size" while designing - I will open a seperate bug on this later). * A "open this component for visual design" mode would be nice. I.e. I could say - now I just want to work on _THIS_ JPanel and it would open in a seperate editor. This might even be synchronized with the original. Sizing information would have to be carefully treated since I want the JPanel to obey the layout manager.
Thorbjørn, Thanks for providing feedback on your use of the Visual Editor... we are always looking at ways to improve the user's experience. Your use case scenarios will be helpful as we design for future releases of VE. Included here is your post to the VE newsgroup and Joe Winchester's response... so we can reference it in the future and use the ideas as a spring board for further discussons: ---------------------------------------------------------------------------------- Hi Thorbjørn, > I just finished my first non-trivial program using Eclipse 3.0.2 with the latest VE, and found it a very pleasant experience as opposed to the tons of hand-written code we had in the last Swing project I worked on. Thanks for the feedback. > I tend to use JPanels with the BorderLayout to position things, including new JPanels with BorderLayout inside of it, and when you get nested two to three times with this it basically turns hard to work with as you need to position the mouse very, very carefully to put it in the right place. This is a good problem you've found. The problem that in WYSIWYG mode the hit target area is sometimes too small. One thing you can do is drop onto the Java Beans tree in which case it will generate a default constraint and then select the Component and use the "constraints" property in the property sheet to move it. > There must be an easier way to work with this - either by putting visual classes inside one another (how would you do that) or by being able to zoom in and out in the VE-view (which I don't think I can do). Another thing I looked for was a way to "Zoom to this component" which would let you work inside of it, and let you zoom out again later. There is an easier way - we hust haven't build it yet. We've toyed with various ideas. One easy one for Border would be that the Tree had five children pre-allocated for it for each region that you dropped onto, but that works well for Border but not for other layout managers. What some other tools do is have a cartoon representaiton of the GUI where the regions are now shown superimposed on the WYSIWYG view but instead are given their own real estate. I think this approach works well but I'd like to see a way to combine this with the WYSIWYG view where as you moved the mouse near an area the VE detected the fact there were multiple drop regions close together and did a sort of local zoom/hover thing that let you get more precise targetting. Please open a bugzilla feature request and we'll discuss it more there and get your input as well as others and try to come up with a good solution. Best regards, Joe Winchester ------------------------------------------------------------------------------
(In reply to comment #0) > needed a "Pack current layout to its smallest reasonable size" while designing - > I will open a seperate bug on this later). This is now bug 92440.