Home » Archived » Visual Editor (VE) » Planning for VE 1.1
| Planning for VE 1.1 [message #66313] |
Mon, 11 October 2004 22:16  |
 David J. Orme
Messages: 291
Registered: July 2009 |
Senior Member |
|
|
VE Developers and Friends,
Last November we launched the Visual Editor Project. Now, just over a
month ago and almost a year later, we have successfully released our
first production release of the Visual Editor with Swing and SWT support.
So what's next?
Right now, you guys have been doing a good job giving VE a workout and
have uncovered a few critical and major bugs. So, our first task is to
complete and release a maintenance release that we will call Version 1.0.2.
After that, we will begin working on VE 1.1, where we are following
Eclipse's numbering pattern of minor releases continuing and refining
the general themes that have been introduced by a x.0 release.
So the developers' first task in doing VE 1.1 is to write our plan
document. This is the process we will follow to write our plan document:
1) Poll everyone and see what folks would ideally like in their
"perfect" VE.
2) Identify dependencies among the wish-list items. For example,
performance work could introduce changes that would break API, so we
probably need to do performance work either before or alongside of API
documentation work.
3) Pare the wish-list down to manageable size, identify themes, publish
a draft plan document, and solicit feedback.
4) Finalize the plan document.
I will follow-up with a message that starts the process identified here
by listing features the developers have already identified. Please read
this list and reply with any and all ideas of your own.
Together I expect we can make VE even better.
Best Regards,
Dave Orme
--
Dave Orme
Eclipse Visual Editor Project Lead
Advanced Systems Concepts' Chief Architect
http://www.swtworkbench.com http://essentialdata.sf.net
|
|
| | |
| Re: Planning for VE 1.1 - suggestions [message #66417 is a reply to message #66334] |
Tue, 12 October 2004 01:59  |
Eclipse User |
|
|
|
Originally posted by: spam.scientifik.com
Some additional suggestions that I've seen while developing Windows Forms
for .NET that I miss while using VE (and some others I made up myself).
Hell, some of these may already exist and I'm too much of a newbie to
realize it, so I apologize if that is the case!
- Grid "snapping" for widgets
- Double-click widget to get most common event auto-created and jumped
to in the code window. (i.e. widgetSelected for Button)
- "align" widgets (ability to marquee a group and line them up)
- "send-to-back" and "bring-to-front" ability for widgets (right-clicking)
- Lock widgets into place so they become uneditable until unlocked.
- More default widgets (include 3rd party widgets?)
- Performance, performance, performance. Sure this has been said but
I've had
some serious problems being productive when VE takes so long to
round-trip
code and design changes.
David Orme wrote:
> David Orme wrote:
> > 1) Poll everyone and see what folks would ideally like in their
> > "perfect" VE.
> The VE developers have identified the following areas (listed in no
> particular order). Please critique and/or add to this list whatever you
> might like to see.
> 1) Performance work. VE is still slow in some areas.
> 2) Object factory support / JFace support
> JFace has taken the lead by creating SWT layouts using a
> public Composite createPartControl(Composite parent);
> factory method pattern. Essential Data and other frameworks have copied
> this good idea and used it all over the place. We need to support this.
> 3) More coding pattern support
> So you can bring your JBuilder project, NetBeans project, etc., into VE.
> 4) Basic RCP support
> Ability to create Eclipse views and editors using VE.
> 5) The ablility to add, move and delete items/categories from the palette.
> 6) API documentation. We should pick (from now on each release) as set
> of development use cases (e.g., extending a palette, adding a layout
> mgr. etc.) document, clean and open the VE API to drive these. Two
> different groups cited this as important.
> 7) Copy/paste controls on the design surface.
> 8) FormLayout and possibly other layout manager support (JGoodies?)
> Best Regards,
> Dave Orme
|
|
| |
| Re: Planning for VE 1.1 - suggestions [message #66602 is a reply to message #66478] |
Tue, 12 October 2004 15:14 |
| Eclipse User |
|
|
|
Originally posted by: gyetko.sedsystems.ca
I would like to see the JGoodies FormLayout supported in the visual editor
as well as performance improvements. JGoodies is becoming more popular
and it deserves representation within the Visual Editor. We have started
using JGoodies at our company and need to standardize on form based
layout. The only thing missing is a tool that will help our developers
build this style of window in a WYSIWYG editor (VE) in an IDE (Eclipse).
Could one of the developers give a target date for the next release of VE
if JGoodies was supported? I know this is difficult because it depends on
the number of features you are planning to support. All I am looking for
is a ballpark figure, 6 months, 1 year, 1 1/2 years etc.
|
|
|
| Re: Planning for VE 1.1 [message #66644 is a reply to message #66334] |
Tue, 12 October 2004 16:52 |
| Eclipse User |
|
|
|
Originally posted by: cdouglas.nospam.oz.net
David Orme <daveo@asc-iseries.com> wrote in
news:ckf0pt$eah$1@eclipse.org:
> David Orme wrote:
>
>> 1) Poll everyone and see what folks would ideally like in their
>> "perfect" VE.
1.4 support (specifically JSpinner and perhaps SpringLayout).
1.5 support, if necessary -- I don't know what changed in terms of layouts,
but I know I will be using 1.5.
I don't know of an editor that does it, but a feature to give a visual
overview of all your dialogs would be very nice, with, of course, the
ability to drill down into individual dialogs/panes.
Better organization of the "non-visual" components would be nice. I'm
working on a project with lots of custom table models and they end up
scattered all over the drawing field. Perhaps a rubber-band line to the
panel they are in? Something to help with a visual assocation, anyway,
would be nice.
Those are the ones that are important to me right this minute.
Chas Douglass
|
|
| |
| Re: Planning for VE 1.1 [message #66860 is a reply to message #66644] |
Tue, 12 October 2004 22:29 |
| Eclipse User |
|
|
|
Originally posted by: fernandez_marce.yahoo.com
Chas Douglass wrote:
> David Orme <daveo@asc-iseries.com> wrote in
> news:ckf0pt$eah$1@eclipse.org:
>
>> David Orme wrote:
>>
>>> 1) Poll everyone and see what folks would ideally like in their
>>> "perfect" VE.
>
> 1.4 support (specifically JSpinner and perhaps SpringLayout).
- Maybe JFormattedTextField too? :D
- Support for defining new models (custom models) to swing components. For
example, if I want to set a new model for a JTable, there should be a
Table1.Model (property, dialog box, or something) to set a custom child of
AbstractTableModel. Now this kind of code throws warnings in Eclipse's
Error Log:
public class CustomTableModel extends AbstractTableModel {
......
}
myModel = new CustomTableModel();
productsTable = new JTable(myModel);
I shouldn't touch the VE's generated code to set a custom model. Maybe this
is related to add new custom components to the palette.
Thanks
Marcelo
|
|
|
| Re: Planning for VE 1.1 - suggestions [message #66888 is a reply to message #66602] |
Wed, 13 October 2004 03:03 |
| Eclipse User |
|
|
|
Originally posted by: weconsul.ptd.net
Brian Gyetko wrote:
> I would like to see the JGoodies FormLayout supported in the visual editor
> as well as performance improvements. JGoodies is becoming more popular
> and it deserves representation within the Visual Editor. We have started
> using JGoodies at our company and need to standardize on form based
> layout. The only thing missing is a tool that will help our developers
> build this style of window in a WYSIWYG editor (VE) in an IDE (Eclipse).
>
> Could one of the developers give a target date for the next release of VE
> if JGoodies was supported? I know this is difficult because it depends on
> the number of features you are planning to support. All I am looking for
> is a ballpark figure, 6 months, 1 year, 1 1/2 years etc.
>
>
I would definitely like to see JGoodies FormLayout supported also in the
next v 1.1. It seems that JGoodies FormLayout is becoming state of the art!
--
Thanks in Advance...
IchBin
____________________________________________________________ ______________
'Laughter is inner jogging'
- Norman Cousins, editor and author (1915-1990)
|
|
|
| Re: Planning for VE 1.1 [message #66952 is a reply to message #66860] |
Wed, 13 October 2004 12:51 |
Joe Winchester
Messages: 496
Registered: July 2009 |
Senior Member |
|
|
Hi Marcelo,
> - Support for defining new models (custom models) to swing components. For
> example, if I want to set a new model for a JTable, there should be a
> Table1.Model (property, dialog box, or something) to set a custom child of
> AbstractTableModel. Now this kind of code throws warnings in Eclipse's
> Error Log:
>
> public class CustomTableModel extends AbstractTableModel {
> .....
> }
>
> myModel = new CustomTableModel();
> productsTable = new JTable(myModel);
>
> I shouldn't touch the VE's generated code to set a custom model. Maybe this
> is related to add new custom components to the palette.
I think this is related to how we handle inner classes. The VE starts a
JVM into which it instanties Java objects, one for the superclass of
the class being edited and others for everything that it uses (its
JavaBeans like the frame, buttons, Strings, colors, numbers, etc....).
This creates a preview of the state that the actual running class will
adopt. One of the issues we run up against quite a bit is the actual
instiation of objects in the target JVM.
First is that we have to be able to parse and recognize the format of
method arguments or initialization Strings. These can be quite complex
(look at a CompoundBorder with a couple of titled borders for example),
or even something like SWT constructors with style bits, or argument
values that are fields that get assigned elsewhere, etc... When we fail
to manage to parse a string we put a blue information sign on the GUI of
the component we can't handle and a status message saying what's gone
wrong. Another thing we can't deal with is inner clases. The reason is
that in Java there is no easy way we could think of to instantiate the
actual inner class. It might not yet even exist in a compiled state (if
the class is new or even if it isn't the .class likely could be stale).
We do however instantiate static inner classes, so if your snippit was
public static CustomTableModel extends ...
the VE should be able to instantiate it.
The VE can't deal with the the kind of construction you've done where an
argument is specified. Try doing
myModel = new CustomModel();
productsTable = new JTable();
productsTable.setModel(myModel);
However we should cope with what you wrote and I've opened a bugzilla
feature request 76156
Best regards and many thanks,
Joe Winchester
|
|
|
| Re: Planning for VE 1.1 - suggestions [message #66961 is a reply to message #66602] |
Wed, 13 October 2004 15:39 |
David J. Orme
Messages: 291
Registered: July 2009 |
Senior Member |
|
|
Brian Gyetko wrote:
> I would like to see the JGoodies FormLayout supported in the visual editor
> as well as performance improvements. JGoodies is becoming more popular
> and it deserves representation within the Visual Editor. We have started
> using JGoodies at our company and need to standardize on form based
> layout. The only thing missing is a tool that will help our developers
> build this style of window in a WYSIWYG editor (VE) in an IDE (Eclipse).
>
> Could one of the developers give a target date for the next release of VE
> if JGoodies was supported? I know this is difficult because it depends on
> the number of features you are planning to support. All I am looking for
> is a ballpark figure, 6 months, 1 year, 1 1/2 years etc.
I'd love to, but this process is all about deciding what we will
support, which will partially determine the time frame. It's also
possible that we will choose to document how to add support for things
like JGoodies FormLayout, but leave that job for someone in the
community to take on. I'm not saying we will do that, just that right
now, all bets are off as to what we will do next. (Of course, we have
our own ideas, but we want to be as open-minded as possible right now to
see if others here have thought of things we haven't.)
Regards,
Dave Orme
--
Dave Orme
Eclipse Visual Editor Project Lead
Advanced Systems Concepts' Chief Architect
http://www.swtworkbench.com http://essentialdata.sf.net
|
|
|
| Re: Planning for VE 1.1 [message #66970 is a reply to message #66334] |
Wed, 13 October 2004 16:44 |
| Eclipse User |
|
|
|
Originally posted by: vickp.retrogui.com
Hi Dave,
A nice feature would be to have more control over the templates used to
create new visual classes. For example, I'd like to be able to specify
a custom constructor, additional methods, additional data members
(loggers,etc).
Regards,
Vick
|
|
| |
| Re: Planning for VE 1.1 - suggestions [message #67401 is a reply to message #66602] |
Mon, 18 October 2004 16:39 |
| Eclipse User |
|
|
|
Originally posted by: mendelgili.netscape.net
Brian Gyetko wrote:
> I would like to see the JGoodies FormLayout supported in the visual editor
> as well as performance improvements. JGoodies is becoming more popular
> and it deserves representation within the Visual Editor. We have started
> using JGoodies at our company and need to standardize on form based
> layout. The only thing missing is a tool that will help our developers
> build this style of window in a WYSIWYG editor (VE) in an IDE (Eclipse).
>
> Could one of the developers give a target date for the next release of VE
> if JGoodies was supported? I know this is difficult because it depends on
> the number of features you are planning to support. All I am looking for
> is a ballpark figure, 6 months, 1 year, 1 1/2 years etc.
>
>
What is the Copywrite lic. for jGoodies?
|
|
|
| Re: Planning for VE 1.1 [message #68632 is a reply to message #66334] |
Tue, 19 October 2004 15:15 |
| Eclipse User |
|
|
|
Originally posted by: erik.n.linux.nu
I like the VE alot since I started using it a couple of weeks ago.
I was thinking about some features I'd like:
x New action creation
I usually have Actions underlying my swing buttons and menu items. When
choosing an action in the properties for the widget, I would like an
alternative for creating a new Action. Just a small thing I guess, but very
useful and keeps my development GUI-centered.
x Action properties
I would like to edit the action properties like icon and text in the same
way I would on a visual widget. This could be achieved either by creating a
properties view for Actions or perhaps even better, by linking the relevant
properties of the widget to it's corresponding properties in the Action.
My guess is that in general a nice coupling between model objects for the
widgets and the widgets would be nice, simplifiying coding nice GUI:s with a
more organized MVC-structure.
// Erik Nilsson
|
|
|
| Re: Planning for VE 1.1 [message #68655 is a reply to message #68632] |
Fri, 22 October 2004 13:12 |
| Eclipse User |
|
|
|
Originally posted by: mendelgili.netscape.net
Erik Nilsson wrote:
> I like the VE alot since I started using it a couple of weeks ago.
>
> I was thinking about some features I'd like:
>
> x New action creation
>
> I usually have Actions underlying my swing buttons and menu items. When
> choosing an action in the properties for the widget, I would like an
> alternative for creating a new Action. Just a small thing I guess, but very
> useful and keeps my development GUI-centered.
>
> x Action properties
>
> I would like to edit the action properties like icon and text in the same
> way I would on a visual widget. This could be achieved either by creating a
> properties view for Actions or perhaps even better, by linking the relevant
> properties of the widget to it's corresponding properties in the Action.
>
> My guess is that in general a nice coupling between model objects for the
> widgets and the widgets would be nice, simplifiying coding nice GUI:s with a
> more organized MVC-structure.
>
> // Erik Nilsson
>
>
Yep. it will be nice to have shared actions support with visual representation...
We need a generic manner for one to extend a default none visual edit part that has a relationship to one or more
visuals. There are many approaches for this kind of support... from a PropertySheet cell editor on steroids.. to
drawing lines... where the lines (and potentially none visual edit part) are visible when the related visual is selected.
Please open a Bugzilla enhancement for Actions... we can use it to drive basic support to generalized "relationships".
|
|
| | |
| Re: improved Picture-Selection-Dialog [message #69108 is a reply to message #69087] |
Mon, 25 October 2004 18:25 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
What kind of path are you talking about here? You can only access file
system or workspace files. What other kind are you talking about. You
should be able to go to subdirectories of your root directory, that is
what the tree if for that is shown for your file system.
Your idea of importing a file once found outside the workspace is a good
one, please open a Bugzilla enhancement for this against the VE.
spunti wrote:
> improved Picture-Selection-Dialog
>
> I like the Picture-Selection-Dialog that opens when assigning an image to a
> button via the properties. But it could be improved. I cannot chose a
> different path than to root-directory of my file-system. (Perhaps this is a
> bug?)
> Perhaps a filesize-filter would be helpful to find just icons.
> I'd also like to be able to copy the chosed images to my eclipse-workspace
> within this selection-Dialog. This feature could also be available direcly
> from the palette or so and not only when selecting a button.
>
> My main problem is, that I don't have an image-viewer which shows me all
> images of a directory AND its subdirectories. This is, what the
> picture-selection-dialog, is really good for.
>
> regards
> spunti
--
Thanks,
Rich Kulp
|
|
| | |
| Re: Planning for VE 1.1 [message #70044 is a reply to message #69905] |
Thu, 04 November 2004 22:55 |
| Eclipse User |
|
|
|
Originally posted by: cdouglas.NOSPAMoz.net
David Orme <daveo@asc-iseries.com> wrote in
news:cmbdk5$7ar$1@eclipse.org:
> David Orme wrote:
>> David Orme wrote:
>>
>>> 3) Pare the wish-list down to manageable size, identify themes,
>>> publish a draft plan document, and solicit feedback.
>>>
>>> 4) Finalize the plan document.
>>
>> Several of the core VE developers have been on vacation, and we will
>> continue this process once everyone's back.
>
> Everyone is back now and we have now published the Visual Editor
> Project version 1.1 draft plan on the web site.
>
> http://www.eclipse.org/vep
>
> Comments/suggestions/constructive criticism is all welcome! Feel free
> to comment here or on the developer mailing list as indicated in the
> plan document itself.
>
I'm happy to see progress, as I have quickly come to rely on the Visual
Editor.
Reflecting on the plan now, and having a few more weeks of usage "under
the belt", I would put forth my new main concern, which is not
explicitly addressed: that is "robustness".
The current implementation seems to me to quickly reach a point of
fragility that is frustrating, and somewhat scary. What if the NEXT
control I add makes it break completely?
My current project has a frame with between 150 and 200 components
(JLabel, JTextField, JTable, JPanel, etc) and yet many, many
"activities of daily programming" confuse the parser.
Simply adding a line of code to an anonymous inner class handling an
event will usually cause the parser to error.
Renaming a field, while much improved in that it no longer crashes,
still usually confuses the parser and forces me to, first of all, NOTICE
it is confused again, and secondly manually press the little button to
try parsing again. It also loses my "context" (that is, which button I
was renaming) so I have to manually find it and select it, again.
And if I don't notice that that silly little icon has changed, I will
click a couple of times on the design view wondering why it's not
working, before I go "oh yeah, need to manually request a re-parse".
Drag and drop in the JavaBeans view is horribly broken. After a couple
of tries that usually result in all my controls dropping off my frame
and into the "free space" in the design window, I give up and go
manually move code around. Sometimes I remember to manually stop
reparsing so it won't get confused yet again, but usually I forget and
step in that pile of doo-doo yet again.
Your top priority "platform performance" would help -- it would allow me
to manually reparse much faster. But I'd rather have the parser
improved to not have these problems.
I hope this doesn't sound hyper-critical. As I stated at the beginning,
I'm relying on VE right now to get paid. Perhaps that explains my
passion.
And perhaps these are bugs and will be addressed in releases prior to
1.1. That would be great.
Thanks for listening.
Chas Douglass
|
|
|
| Re: Planning for VE 1.1 [message #70064 is a reply to message #70044] |
Fri, 05 November 2004 09:52 |
Joe Winchester
Messages: 496
Registered: July 2009 |
Senior Member |
|
|
Hi Chas Douglass,
> The current implementation seems to me to quickly reach a point of
> fragility that is frustrating, and somewhat scary. What if the NEXT
> control I add makes it break completely?
>
> My current project has a frame with between 150 and 200 components
> (JLabel, JTextField, JTable, JPanel, etc) and yet many, many
> "activities of daily programming" confuse the parser.
>
> Simply adding a line of code to an anonymous inner class handling an
> event will usually cause the parser to error.
Can you please provide your class as a test case we can use ? If you
open a specific bugzilla and attach your code this would be great, as
well as reproducible steps so we can observe the problem.
> Renaming a field, while much improved in that it no longer crashes,
> still usually confuses the parser and forces me to, first of all, NOTICE
> it is confused again, and secondly manually press the little button to
> try parsing again. It also loses my "context" (that is, which button I
> was renaming) so I have to manually find it and select it, again.
Again, if you have a test case for this please provide a specific one.
It's possibly related to the first problem, but we should look at it
more closely and try to fix it.
> And if I don't notice that that silly little icon has changed, I will
> click a couple of times on the design view wondering why it's not
> working, before I go "oh yeah, need to manually request a re-parse".
We were thinking of changing the whole GUI when the parser is paused to
better show to the user that it is not going to function. One idea was
for the GUI canvas to grey itself out (to appear in a disabled state),
and likewise some kind of grey wash for the JavaBeans viewer and
properties sheet. Would this be an improvement ?
> Drag and drop in the JavaBeans view is horribly broken. After a couple
> of tries that usually result in all my controls dropping off my frame
> and into the "free space" in the design window, I give up and go
> manually move code around. Sometimes I remember to manually stop
> reparsing so it won't get confused yet again, but usually I forget and
> step in that pile of doo-doo yet again.
Again, if you can provide a test case this would be great. Try to put
this in specfic terms for us to be able to re-create the problem with
the same starting point as you rather than make it an emotional write-up
- that way we can observe and fix the problem
> Your top priority "platform performance" would help -- it would allow me
> to manually reparse much faster. But I'd rather have the parser
> improved to not have these problems.
This is an area that we do intend to work on for the next release and a
bug is a bug, so what you've described will be fixed based on its
priority and severity (pretty high from your write-up), whereas the
feature list is more long term improvements and areas of design.
> I hope this doesn't sound hyper-critical. As I stated at the beginning,
> I'm relying on VE right now to get paid. Perhaps that explains my
> passion.
Passion is good. hyper-critical is good. We're thick skinned, however
we do need repeatable test cases to observe the same effects you are so
please try to provide these, and if possible test them yourself on a new
workspace with the test case and document all the steps so we can easily
re-create it and observe the same you are.
Alternatively if you have issues such as customer confidentialy in your
test cases and you don't want to post them publicly let us know and
there are other ways we can still work together - perhaps a net meeting
so we see the problems happening on your PC.
Best regards and many thanks,
Joe Winchester
|
|
|
| Re: Planning for VE 1.1 [message #70141 is a reply to message #70064] |
Fri, 05 November 2004 18:15 |
| Eclipse User |
|
|
|
Originally posted by: cdouglas.NOSPAMoz.net
Joe Winchester <winchest@uk.ibm.com> wrote in
news:cmfigc$666$1@eclipse.org:
[snip]
> Can you please provide your class as a test case we can use ? If you
> open a specific bugzilla and attach your code this would be great, as
> well as reproducible steps so we can observe the problem.
>
Aye, there's the rub. The class file is 3500+ lines of code (largely
generated by VE), and the project is 12,000 lines of code.
Unfortunately, while not a large project, a tad big for a test case, I
think. As I'm on deadline, I don't have time right now to make a
smaller test case, but it's something I keep in mind because I do want
this stuff to work.
[snip]
> We were thinking of changing the whole GUI when the parser is paused
> to better show to the user that it is not going to function. One idea
> was for the GUI canvas to grey itself out (to appear in a disabled
> state), and likewise some kind of grey wash for the JavaBeans viewer
> and properties sheet. Would this be an improvement ?
Definitely.
>
>> Drag and drop in the JavaBeans view is horribly broken. After a
>> couple of tries that usually result in all my controls dropping off
>> my frame and into the "free space" in the design window, I give up
>> and go manually move code around. Sometimes I remember to manually
>> stop reparsing so it won't get confused yet again, but usually I
>> forget and step in that pile of doo-doo yet again.
>
> Again, if you can provide a test case this would be great. Try to put
> this in specfic terms for us to be able to re-create the problem with
> the same starting point as you rather than make it an emotional
> write-up - that way we can observe and fix the problem
>
Actually, this one is easy to reproduce, so I'll go write the bug up
now. This is a good reminder to me to at least put the effort into
working the system to get the product working for me.
Filed as bug #77976
[remainder snipped]
Chas Douglass
|
|
|
| Re: Planning for VE 1.1 [message #70788 is a reply to message #70141] |
Tue, 09 November 2004 17:07 |
David J. Orme
Messages: 291
Registered: July 2009 |
Senior Member |
|
|
>>Can you please provide your class as a test case we can use ? If you
>>open a specific bugzilla and attach your code this would be great, as
>>well as reproducible steps so we can observe the problem.
>>
> Aye, there's the rub. The class file is 3500+ lines of code (largely
> generated by VE), and the project is 12,000 lines of code.
> Unfortunately, while not a large project, a tad big for a test case, I
> think. As I'm on deadline, I don't have time right now to make a
> smaller test case, but it's something I keep in mind because I do want
> this stuff to work.
Idea: Maybe we should create a scalability test framework.
Joe, how difficult would it to be to script VE to make it generate large
random layouts of configurable sizes? I'm thinking of making a test
harness that would execute something like the following algorithm:
Create a new visual Composite (or JPanel, etc)
currentElement = parent Composite
Generate a random depth between 3 and 5
createControls(depth, currentElement)
method createControls(depth, currentElement) {
if (depth > 0) {
numberOfChildren = a random number between 0 and 10;
for i from 1 to numberOfChildren {
controlType = pick a random control type
child = dropIntoParent(currentElement, controlType)
if (child isA container)
createControls(depth-1, child)
}
}
}
By tweaking the depth and number of children parameters to this
algorithm, we should be able to generate large layouts that we can use
to stress-test VE in some interesting ways.
Perhaps we should add something like this to our plan?
The process of creating such a test framework might also be an
interesting thing to document to help folks who want to hack VE internals...
Good idea? Bad? What does everyone think?
Regards,
Dave
--
Dave Orme
Eclipse Visual Editor Project Lead
Advanced Systems Concepts' Chief Architect
http://www.swtworkbench.com http://essentialdata.sf.net
|
|
|
| Re: Planning for VE 1.1 [message #71127 is a reply to message #70788] |
Wed, 10 November 2004 18:05 |
| Eclipse User |
|
|
|
Originally posted by: cdouglas.NOSPAMoz.net
David Orme <daveo@asc-iseries.com> wrote in
news:cmqter$92p$1@eclipse.org:
>>>Can you please provide your class as a test case we can use ? If you
>>>open a specific bugzilla and attach your code this would be great, as
>>>well as reproducible steps so we can observe the problem.
>>>
>> Aye, there's the rub. The class file is 3500+ lines of code (largely
>> generated by VE), and the project is 12,000 lines of code.
>> Unfortunately, while not a large project, a tad big for a test case,
>> I think. As I'm on deadline, I don't have time right now to make a
>> smaller test case, but it's something I keep in mind because I do
>> want this stuff to work.
>
> Idea: Maybe we should create a scalability test framework.
>
[snip]
> Perhaps we should add something like this to our plan?
>
> The process of creating such a test framework might also be an
> interesting thing to document to help folks who want to hack VE
> internals...
>
> Good idea? Bad? What does everyone think?
>
As a non-VE programmer, it sounds good to me largely on the basis that
more tests are always better.
I fear that the problem may have to do with the large number of my
controls that don't parse, however. Just quickly glancing through it
looks like about 25% of my controls get "too complicated to parse".
Interesting. On inspection I see I have a number of fields getting
either "Illegal Argument Exception" or "Class Not Found Exception". They
have the little yellow triangle with an exclamation point, so I just
assumed they were "too complicated".
This is code that *does* compile and run, so I don't know what those
exceptions are.
Chas Douglass
|
|
|
| Re: Planning for VE 1.1 [message #71739 is a reply to message #71127] |
Sun, 14 November 2004 19:36 |
Joe Winchester
Messages: 496
Registered: July 2009 |
Senior Member |
|
|
Hi Chas,
> I fear that the problem may have to do with the large number of my
> controls that don't parse, however. Just quickly glancing through it
> looks like about 25% of my controls get "too complicated to parse".
>
> Interesting. On inspection I see I have a number of fields getting
> either "Illegal Argument Exception" or "Class Not Found Exception". They
> have the little yellow triangle with an exclamation point, so I just
> assumed they were "too complicated".
>
> This is code that *does* compile and run, so I don't know what those
> exceptions are.
Is this code that the VE created, or is the class written by something
other than the VE (i.e. yourself by hand or another IDE GUI builder tool ?).
When the VE opens it doesn't run you .class, instead it analyzes the
code to see the relationships between JavaBeans and creates its own
object model. This is turned into live instances that you can see
previewed in the graph viewer.
for example, if there is the line
myJScrollbar = new JScrollbar();
jScrollbar.setOrientation(javax.swing.JScrollbar.VERTICAL);
what occurs is that a JScrollbar is created using the null constructor,
and then an int using a public field "VERTICAL" on the class
javax.swing.JScrollbar, and then the set method called.
The exceptions are occuring because when the set method is executed some
kind of problem occured. An example is something like
jScrollbar.setOrientation(9);
where the JScrollbar throws an exception (cause 9 isn't one of 0 or 1
which is the only allowable vlaue).
There should be more detail on the exception in the status bar when you
select the JavaBean, and also a detailed stack trace in the .log file in
the .metadata directory.
The "too complicated" error is for when the code can't be analyzed by
our evaluator, for example non-static inner classes or some kinds on
unqualified statements although we're getting better at handling these.
The "too complicated" error has a blue information sign and is
different to a yellow warning which means "a JavaBean exception occured
on the target JVM" when a set method was called due to a property being
set". The property name is shown in the status bar when you select the
JavaBean, and in newer drivers hovering over the JavaBean in the graph
viewer should show the full error text as well.
It sounds like your test case is too large to get to use to use, however
I'd still like to take a look at it. Is is possible we could get
together via a net-meeting or something to look into this more ? The
fact you have a test case that doesn't work is great as it means we have
something we can observe and then fix.
Best regards,
Joe Winchester
|
|
|
| Re: Planning for VE 1.1 [message #71758 is a reply to message #70788] |
Sun, 14 November 2004 19:38 |
Joe Winchester
Messages: 496
Registered: July 2009 |
Senior Member |
|
|
Hi Dave,
> Joe, how difficult would it to be to script VE to make it generate large
> random layouts of configurable sizes? I'm thinking of making a test
> harness that would execute something like the following algorithm:
>
> Create a new visual Composite (or JPanel, etc)
> currentElement = parent Composite
> Generate a random depth between 3 and 5
> createControls(depth, currentElement)
>
> method createControls(depth, currentElement) {
> if (depth > 0) {
> numberOfChildren = a random number between 0 and 10;
> for i from 1 to numberOfChildren {
> controlType = pick a random control type
> child = dropIntoParent(currentElement, controlType)
> if (child isA container)
> createControls(depth-1, child)
> }
> }
> }
>
> By tweaking the depth and number of children parameters to this
> algorithm, we should be able to generate large layouts that we can use
> to stress-test VE in some interesting ways.
>
> Perhaps we should add something like this to our plan?
I think this is a great idea. The more tests we have to stress the VE
against the better it'll become, and from Chas's posts and others there
are clearly scenarios we're encountering that we've not anticipated.
Best regards,
Joe Winchester
|
|
| |
| Re: Planning for VE 1.1 [message #71834 is a reply to message #71815] |
Mon, 15 November 2004 14:52 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
You can do that through the property sheet. Select both components and
change the size property.
Francesc Rosés Albiol wrote:
> Hello,
> I'll suggest a, I suspect, very simple improvemenet. Now you have the
> possibility to assign the same height and the same width to two or more
> selected components, but if I need to assign the "same size" I need to
> assign first the same height (or width) and then the same width (or
> height) to the selected components. I think may be useful a new button
> to assign "the same size".
> Tnaks in advance,
> Francesc
>
--
Thanks,
Rich Kulp
|
|
|
| Re: Planning for VE 1.1 [message #71867 is a reply to message #71739] |
Mon, 15 November 2004 18:38 |
| Eclipse User |
|
|
|
Originally posted by: cdouglas.NOSPAMoz.net
Joe Winchester <winchest@uk.ibm.com> wrote in
news:cn8c4n$hbt$1@eclipse.org:
[snip]
>> Interesting. On inspection I see I have a number of fields getting
>> either "Illegal Argument Exception" or "Class Not Found Exception".
>> They have the little yellow triangle with an exclamation point, so I
>> just assumed they were "too complicated".
>>
[snip]
> Is this code that the VE created, or is the class written by something
> other than the VE (i.e. yourself by hand or another IDE GUI builder
> tool ?).
>
It's VE created, but hand edited.
One is, for instance, on a JTextField that I added:
textField.setDocument(new CustomDocument());
because the custom document is used for several different textfields.
> The "too complicated" error has a blue information sign and is
> different to a yellow warning which means "a JavaBean exception
> occured on the target JVM" when a set method was called due to a
> property being set". The property name is shown in the status bar
> when you select the JavaBean, and in newer drivers hovering over the
> JavaBean in the graph viewer should show the full error text as well.
>
I also get the yellow-triangle-exclamation-point with a "too
complicated".
> It sounds like your test case is too large to get to use to use,
> however I'd still like to take a look at it. Is is possible we could
> get together via a net-meeting or something to look into this more ?
> The fact you have a test case that doesn't work is great as it means
> we have something we can observe and then fix.
>
I'd be happy to set something up.
Remove "NOSPAM" from my email address to get mail to me.
Chas Douglass
|
|
| |
| Re: Planning for VE 1.1 [message #71942 is a reply to message #71834] |
Mon, 15 November 2004 22:16 |
Francesc Rosés
Messages: 213
Registered: July 2009 |
Senior Member |
|
|
Rich Kulp wrote:
> You can do that through the property sheet. Select both components and
> change the size property.
> Francesc Rosés Albiol wrote:
>> Hello,
>> I'll suggest a, I suspect, very simple improvemenet. Now you have the
>> possibility to assign the same height and the same width to two or more
>> selected components, but if I need to assign the "same size" I need to
>> assign first the same height (or width) and then the same width (or
>> height) to the selected components. I think may be useful a new button
>> to assign "the same size".
>> Tnaks in advance,
>> Francesc
>>
Hi Rich,
Yes, I can set the size property from the properties editor, but I think
is more useful to include a new button in the Customize Layout like the
existing buttons "Match width" and "Match height", doing "Match size".
Francesc Rosés
|
|
| | |
| Re: Planning for VE 1.1 [message #72112 is a reply to message #72034] |
Tue, 16 November 2004 21:18 |
| Eclipse User |
|
|
|
Originally posted by: cdouglas.NOSPAMoz.net
Joe Winchester <winchest@uk.ibm.com> wrote in news:cncrau$p4h$1
@www.eclipse.org:
>> On the subject of the Customize Layout dialog (and with apologies to the
>> OP for thread hijacking) why isn't this a toolbar that can be docked?
>
> Cause we're not perfect. It would be nice if it was dockable however.
> There are a lot of things on the VE queue but if you are feeling brave
> please open a bugzilla for this and if you want to begin coding it
> that'd be great and submit a code patch.
>
> Best regards,
>
> Joe Winchester
My sincere apologies if my question sounded critical. It was an honest
request. As I am not at all familiar with Eclipse coding, I presumed there
was a design decision behind it, and was innocently asking for information.
Chas Douglass
|
|
|
| Re: Planning for VE 1.1 [message #72146 is a reply to message #72112] |
Wed, 17 November 2004 18:29 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
Joe wasn't being snide either. :-) Joe is always respectful to
respondents in the newsgroup. He appreciates and looks forward to their
input. He was just being honest, we aren't perfect. He just forgot the
smiley ( :-) ) after "Cause we're not perfect," that's all.
Chas Douglass wrote:
> Joe Winchester <winchest@uk.ibm.com> wrote in news:cncrau$p4h$1
> @www.eclipse.org:
>
>
>
>>>On the subject of the Customize Layout dialog (and with apologies to the
>>>OP for thread hijacking) why isn't this a toolbar that can be docked?
>>
>>Cause we're not perfect. It would be nice if it was dockable however.
>>There are a lot of things on the VE queue but if you are feeling brave
>>please open a bugzilla for this and if you want to begin coding it
>>that'd be great and submit a code patch.
>>
>>Best regards,
>>
>>Joe Winchester
>
>
> My sincere apologies if my question sounded critical. It was an honest
> request. As I am not at all familiar with Eclipse coding, I presumed there
> was a design decision behind it, and was innocently asking for information.
>
> Chas Douglass
--
Thanks,
Rich Kulp
|
|
|
| Re: Planning for VE 1.1 [message #72356 is a reply to message #71758] |
Mon, 22 November 2004 14:18 |
| Eclipse User |
|
|
|
Originally posted by: mendelgili.netscape.net
Joe Winchester wrote:
> Hi Dave,
>
>> Joe, how difficult would it to be to script VE to make it generate
>> large random layouts of configurable sizes? I'm thinking of making a
>> test harness that would execute something like the following algorithm:
>>
>> Create a new visual Composite (or JPanel, etc)
>> currentElement = parent Composite
>> Generate a random depth between 3 and 5
>> createControls(depth, currentElement)
>>
>> method createControls(depth, currentElement) {
>> if (depth > 0) {
>> numberOfChildren = a random number between 0 and 10;
>> for i from 1 to numberOfChildren {
>> controlType = pick a random control type
>> child = dropIntoParent(currentElement, controlType)
>> if (child isA container)
>> createControls(depth-1, child)
>> }
>> }
>> }
>>
>> By tweaking the depth and number of children parameters to this
>> algorithm, we should be able to generate large layouts that we can use
>> to stress-test VE in some interesting ways.
>>
>> Perhaps we should add something like this to our plan?
>
>
> I think this is a great idea. The more tests we have to stress the VE
> against the better it'll become, and from Chas's posts and others there
> are clearly scenarios we're encountering that we've not anticipated.
>
> Best regards,
>
> Joe Winchester
Peter Walker has been using Abbot to automate smoke tests Swing/SWT. You can extend these automated tests.
|
|
|
| Re: Planning for VE 1.1 [message #72759 is a reply to message #69905] |
Wed, 24 November 2004 16:58 |
David J. Orme
Messages: 291
Registered: July 2009 |
Senior Member |
|
|
David Orme wrote:
> Everyone is back now and we have now published the Visual Editor Project
> version 1.1 draft plan on the web site.
>
> http://www.eclipse.org/vep
It looks like the only new suggestion we have received is the idea about
how to stress-test VE more exhaustively, and we have agreed that we will
do this. Since this seems to be something we should just do as a matter
of course, it will not go on the plan, but we will do it (in fact we
already are implementing this).
So given all of this, I will now declare this to be our VE 1.1 plan and
update the web site accordingly.
However, just as the plan document says, "Plans do not materialize out
of nowhere, nor are they entirely static." If you have a killer idea
about something we should add to VE, please post it on the ve-dev
mailing list and we will add it to the appropriate place in the plan
document.
Best regards,
Dave Orme
--
Dave Orme
Eclipse Visual Editor Project Lead
Advanced Systems Concepts' Chief Architect
http://www.swtworkbench.com http://essentialdata.sf.net
|
|
|
| Re: Planning for VE 1.1 [message #73026 is a reply to message #66370] |
Sun, 28 November 2004 23:31 |
| Eclipse User |
|
|
|
Originally posted by: markbrazil.spymac.com
9) Mac Support !
Yes please, mac support soon.
Jeff Lambourne wrote:
> David Orme wrote:
>> David Orme wrote:
>> > 1) Poll everyone and see what folks would ideally like in their
>> > "perfect" VE.
>> The VE developers have identified the following areas (listed in no
>> particular order). Please critique and/or add to this list whatever you
>> might like to see.
>> 1) Performance work. VE is still slow in some areas.
>> 2) Object factory support / JFace support
>> JFace has taken the lead by creating SWT layouts using a
>> public Composite createPartControl(Composite parent);
>> factory method pattern. Essential Data and other frameworks have copied
>> this good idea and used it all over the place. We need to support this.
> This could tie up with (4) - Basic RCP support. What do the RCP guys
> think?
>> 3) More coding pattern support
>> So you can bring your JBuilder project, NetBeans project, etc., into VE.
>> 4) Basic RCP support
>> Ability to create Eclipse views and editors using VE.
>> 5) The ablility to add, move and delete items/categories from the palette.
>> 6) API documentation. We should pick (from now on each release) as set
>> of development use cases (e.g., extending a palette, adding a layout
>> mgr. etc.) document, clean and open the VE API to drive these. Two
>> different groups cited this as important.
>> 7) Copy/paste controls on the design surface.
>> 8) FormLayout and possibly other layout manager support (JGoodies?)
> 9) Dare I say - support for the mac platform
>> Best Regards,
>> Dave Orme
|
|
| | | |
| Re: Planning for VE 1.1 - suggestions [message #601341 is a reply to message #66334] |
Tue, 12 October 2004 01:59 |
| Eclipse User |
|
|
|
Originally posted by: spam.scientifik.com
Some additional suggestions that I've seen while developing Windows Forms
for .NET that I miss while using VE (and some others I made up myself).
Hell, some of these may already exist and I'm too much of a newbie to
realize it, so I apologize if that is the case!
- Grid "snapping" for widgets
- Double-click widget to get most common event auto-created and jumped
to in the code window. (i.e. widgetSelected for Button)
- "align" widgets (ability to marquee a group and line them up)
- "send-to-back" and "bring-to-front" ability for widgets (right-clicking)
- Lock widgets into place so they become uneditable until unlocked.
- More default widgets (include 3rd party widgets?)
- Performance, performance, performance. Sure this has been said but
I've had
some serious problems being productive when VE takes so long to
round-trip
code and design changes.
David Orme wrote:
> David Orme wrote:
> > 1) Poll everyone and see what folks would ideally like in their
> > "perfect" VE.
> The VE developers have identified the following areas (listed in no
> particular order). Please critique and/or add to this list whatever you
> might like to see.
> 1) Performance work. VE is still slow in some areas.
> 2) Object factory support / JFace support
> JFace has taken the lead by creating SWT layouts using a
> public Composite createPartControl(Composite parent);
> factory method pattern. Essential Data and other frameworks have copied
> this good idea and used it all over the place. We need to support this.
> 3) More coding pattern support
> So you can bring your JBuilder project, NetBeans project, etc., into VE.
> 4) Basic RCP support
> Ability to create Eclipse views and editors using VE.
> 5) The ablility to add, move and delete items/categories from the palette.
> 6) API documentation. We should pick (from now on each release) as set
> of development use cases (e.g., extending a palette, adding a layout
> mgr. etc.) document, clean and open the VE API to drive these. Two
> different groups cited this as important.
> 7) Copy/paste controls on the design surface.
> 8) FormLayout and possibly other layout manager support (JGoodies?)
> Best Regards,
> Dave Orme
|
|
| |
| Re: Planning for VE 1.1 - suggestions [message #601396 is a reply to message #66478] |
Tue, 12 October 2004 15:14 |
| Eclipse User |
|
|
|
Originally posted by: gyetko.sedsystems.ca
I would like to see the JGoodies FormLayout supported in the visual editor
as well as performance improvements. JGoodies is becoming more popular
and it deserves representation within the Visual Editor. We have started
using JGoodies at our company and need to standardize on form based
layout. The only thing missing is a tool that will help our developers
build this style of window in a WYSIWYG editor (VE) in an IDE (Eclipse).
Could one of the developers give a target date for the next release of VE
if JGoodies was supported? I know this is difficult because it depends on
the number of features you are planning to support. All I am looking for
is a ballpark figure, 6 months, 1 year, 1 1/2 years etc.
|
|
| | | |
| Re: Planning for VE 1.1 - suggestions [message #601457 is a reply to message #66602] |
Wed, 13 October 2004 03:03 |
|
Brian Gyetko wrote:
> I would like to see the JGoodies FormLayout supported in the visual editor
> as well as performance improvements. JGoodies is becoming more popular
> and it deserves representation within the Visual Editor. We have started
> using JGoodies at our company and need to standardize on form based
> layout. The only thing missing is a tool that will help our developers
> build this style of window in a WYSIWYG editor (VE) in an IDE (Eclipse).
>
> Could one of the developers give a target date for the next release of VE
> if JGoodies was supported? I know this is difficult because it depends on
> the number of features you are planning to support. All I am looking for
> is a ballpark figure, 6 months, 1 year, 1 1/2 years etc.
>
>
I would definitely like to see JGoodies FormLayout supported also in the
next v 1.1. It seems that JGoodies FormLayout is becoming state of the art!
--
Thanks in Advance...
IchBin
____________________________________________________________ ______________
'Laughter is inner jogging'
- Norman Cousins, editor and author (1915-1990)
|
|
|
| Re: Planning for VE 1.1 [message #601485 is a reply to message #66860] |
Wed, 13 October 2004 12:51 |
Joe Winchester
Messages: 496
Registered: July 2009 |
Senior Member |
|
|
Hi Marcelo,
> - Support for defining new models (custom models) to swing components. For
> example, if I want to set a new model for a JTable, there should be a
> Table1.Model (property, dialog box, or something) to set a custom child of
> AbstractTableModel. Now this kind of code throws warnings in Eclipse's
> Error Log:
>
> public class CustomTableModel extends AbstractTableModel {
> .....
> }
>
> myModel = new CustomTableModel();
> productsTable = new JTable(myModel);
>
> I shouldn't touch the VE's generated code to set a custom model. Maybe this
> is related to add new custom components to the palette.
I think this is related to how we handle inner classes. The VE starts a
JVM into which it instanties Java objects, one for the superclass of
the class being edited and others for everything that it uses (its
JavaBeans like the frame, buttons, Strings, colors, numbers, etc....).
This creates a preview of the state that the actual running class will
adopt. One of the issues we run up against quite a bit is the actual
instiation of objects in the target JVM.
First is that we have to be able to parse and recognize the format of
method arguments or initialization Strings. These can be quite complex
(look at a CompoundBorder with a couple of titled borders for example),
or even something like SWT constructors with style bits, or argument
values that are fields that get assigned elsewhere, etc... When we fail
to manage to parse a string we put a blue information sign on the GUI of
the component we can't handle and a status message saying what's gone
wrong. Another thing we can't deal with is inner clases. The reason is
that in Java there is no easy way we could think of to instantiate the
actual inner class. It might not yet even exist in a compiled state (if
the class is new or even if it isn't the .class likely could be stale).
We do however instantiate static inner classes, so if your snippit was
public static CustomTableModel extends ...
the VE should be able to instantiate it.
The VE can't deal with the the kind of construction you've done where an
argument is specified. Try doing
myModel = new CustomModel();
productsTable = new JTable();
productsTable.setModel(myModel);
However we should cope with what you wrote and I've opened a bugzilla
feature request 76156
Best regards and many thanks,
Joe Winchester
|
|
|
| Re: Planning for VE 1.1 - suggestions [message #601490 is a reply to message #66602] |
Wed, 13 October 2004 15:39 |
David J. Orme
Messages: 291
Registered: July 2009 |
Senior Member |
|
|
Brian Gyetko wrote:
> I would like to see the JGoodies FormLayout supported in the visual editor
> as well as performance improvements. JGoodies is becoming more popular
> and it deserves representation within the Visual Editor. We have started
> using JGoodies at our company and need to standardize on form based
> layout. The only thing missing is a tool that will help our developers
> build this style of window in a WYSIWYG editor (VE) in an IDE (Eclipse).
>
> Could one of the developers give a target date for the next release of VE
> if JGoodies was supported? I know this is difficult because it depends on
> the number of features you are planning to support. All I am looking for
> is a ballpark figure, 6 months, 1 year, 1 1/2 years etc.
I'd love to, but this process is all about deciding what we will
support, which will partially determine the time frame. It's also
possible that we will choose to document how to add support for things
like JGoodies FormLayout, but leave that job for someone in the
community to take on. I'm not saying we will do that, just that right
now, all bets are off as to what we will do next. (Of course, we have
our own ideas, but we want to be as open-minded as possible right now to
see if others here have thought of things we haven't.)
Regards,
Dave Orme
--
Dave Orme
Eclipse Visual Editor Project Lead
Advanced Systems Concepts' Chief Architect
http://www.swtworkbench.com http://essentialdata.sf.net
|
|
|
| Re: Planning for VE 1.1 [message #601499 is a reply to message #66334] |
Wed, 13 October 2004 16:44 |
| Eclipse User |
|
|
|
Originally posted by: vickp.retrogui.com
Hi Dave,
A nice feature would be to have more control over the templates used to
create new visual classes. For example, I'd like to be able to specify
a custom constructor, additional methods, additional data members
(loggers,etc).
Regards,
Vick
|
|
| | | | | | |
| Re: improved Picture-Selection-Dialog [message #602341 is a reply to message #69087] |
Mon, 25 October 2004 18:25 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
What kind of path are you talking about here? You can only access file
system or workspace files. What other kind are you talking about. You
should be able to go to subdirectories of your root directory, that is
what the tree if for that is shown for your file system.
Your idea of importing a file once found outside the workspace is a good
one, please open a Bugzilla enhancement for this against the VE.
spunti wrote:
> improved Picture-Selection-Dialog
>
> I like the Picture-Selection-Dialog that opens when assigning an image to a
> button via the properties. But it could be improved. I cannot chose a
> different path than to root-directory of my file-system. (Perhaps this is a
> bug?)
> Perhaps a filesize-filter would be helpful to find just icons.
> I'd also like to be able to copy the chosed images to my eclipse-workspace
> within this selection-Dialog. This feature could also be available direcly
> from the palette or so and not only when selecting a button.
>
> My main problem is, that I don't have an image-viewer which shows me all
> images of a directory AND its subdirectories. This is, what the
> picture-selection-dialog, is really good for.
>
> regards
> spunti
--
Thanks,
Rich Kulp
|
|
| | |
| Re: Planning for VE 1.1 [message #602622 is a reply to message #69905] |
Thu, 04 November 2004 22:55 |
Chas Douglass
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
David Orme <daveo@asc-iseries.com> wrote in
news:cmbdk5$7ar$1@eclipse.org:
> David Orme wrote:
>> David Orme wrote:
>>
>>> 3) Pare the wish-list down to manageable size, identify themes,
>>> publish a draft plan document, and solicit feedback.
>>>
>>> 4) Finalize the plan document.
>>
>> Several of the core VE developers have been on vacation, and we will
>> continue this process once everyone's back.
>
> Everyone is back now and we have now published the Visual Editor
> Project version 1.1 draft plan on the web site.
>
> http://www.eclipse.org/vep
>
> Comments/suggestions/constructive criticism is all welcome! Feel free
> to comment here or on the developer mailing list as indicated in the
> plan document itself.
>
I'm happy to see progress, as I have quickly come to rely on the Visual
Editor.
Reflecting on the plan now, and having a few more weeks of usage "under
the belt", I would put forth my new main concern, which is not
explicitly addressed: that is "robustness".
The current implementation seems to me to quickly reach a point of
fragility that is frustrating, and somewhat scary. What if the NEXT
control I add makes it break completely?
My current project has a frame with between 150 and 200 components
(JLabel, JTextField, JTable, JPanel, etc) and yet many, many
"activities of daily programming" confuse the parser.
Simply adding a line of code to an anonymous inner class handling an
event will usually cause the parser to error.
Renaming a field, while much improved in that it no longer crashes,
still usually confuses the parser and forces me to, first of all, NOTICE
it is confused again, and secondly manually press the little button to
try parsing again. It also loses my "context" (that is, which button I
was renaming) so I have to manually find it and select it, again.
And if I don't notice that that silly little icon has changed, I will
click a couple of times on the design view wondering why it's not
working, before I go "oh yeah, need to manually request a re-parse".
Drag and drop in the JavaBeans view is horribly broken. After a couple
of tries that usually result in all my controls dropping off my frame
and into the "free space" in the design window, I give up and go
manually move code around. Sometimes I remember to manually stop
reparsing so it won't get confused yet again, but usually I forget and
step in that pile of doo-doo yet again.
Your top priority "platform performance" would help -- it would allow me
to manually reparse much faster. But I'd rather have the parser
improved to not have these problems.
I hope this doesn't sound hyper-critical. As I stated at the beginning,
I'm relying on VE right now to get paid. Perhaps that explains my
passion.
And perhaps these are bugs and will be addressed in releases prior to
1.1. That would be great.
Thanks for listening.
Chas Douglass
|
|
|
| Re: Planning for VE 1.1 [message #602625 is a reply to message #70044] |
Fri, 05 November 2004 09:52 |
Joe Winchester
Messages: 496
Registered: July 2009 |
Senior Member |
|
|
Hi Chas Douglass,
> The current implementation seems to me to quickly reach a point of
> fragility that is frustrating, and somewhat scary. What if the NEXT
> control I add makes it break completely?
>
> My current project has a frame with between 150 and 200 components
> (JLabel, JTextField, JTable, JPanel, etc) and yet many, many
> "activities of daily programming" confuse the parser.
>
> Simply adding a line of code to an anonymous inner class handling an
> event will usually cause the parser to error.
Can you please provide your class as a test case we can use ? If you
open a specific bugzilla and attach your code this would be great, as
well as reproducible steps so we can observe the problem.
> Renaming a field, while much improved in that it no longer crashes,
> still usually confuses the parser and forces me to, first of all, NOTICE
> it is confused again, and secondly manually press the little button to
> try parsing again. It also loses my "context" (that is, which button I
> was renaming) so I have to manually find it and select it, again.
Again, if you have a test case for this please provide a specific one.
It's possibly related to the first problem, but we should look at it
more closely and try to fix it.
> And if I don't notice that that silly little icon has changed, I will
> click a couple of times on the design view wondering why it's not
> working, before I go "oh yeah, need to manually request a re-parse".
We were thinking of changing the whole GUI when the parser is paused to
better show to the user that it is not going to function. One idea was
for the GUI canvas to grey itself out (to appear in a disabled state),
and likewise some kind of grey wash for the JavaBeans viewer and
properties sheet. Would this be an improvement ?
> Drag and drop in the JavaBeans view is horribly broken. After a couple
> of tries that usually result in all my controls dropping off my frame
> and into the "free space" in the design window, I give up and go
> manually move code around. Sometimes I remember to manually stop
> reparsing so it won't get confused yet again, but usually I forget and
> step in that pile of doo-doo yet again.
Again, if you can provide a test case this would be great. Try to put
this in specfic terms for us to be able to re-create the problem with
the same starting point as you rather than make it an emotional write-up
- that way we can observe and fix the problem
> Your top priority "platform performance" would help -- it would allow me
> to manually reparse much faster. But I'd rather have the parser
> improved to not have these problems.
This is an area that we do intend to work on for the next release and a
bug is a bug, so what you've described will be fixed based on its
priority and severity (pretty high from your write-up), whereas the
feature list is more long term improvements and areas of design.
> I hope this doesn't sound hyper-critical. As I stated at the beginning,
> I'm relying on VE right now to get paid. Perhaps that explains my
> passion.
Passion is good. hyper-critical is good. We're thick skinned, however
we do need repeatable test cases to observe the same effects you are so
please try to provide these, and if possible test them yourself on a new
workspace with the test case and document all the steps so we can easily
re-create it and observe the same you are.
Alternatively if you have issues such as customer confidentialy in your
test cases and you don't want to post them publicly let us know and
there are other ways we can still work together - perhaps a net meeting
so we see the problems happening on your PC.
Best regards and many thanks,
Joe Winchester
|
|
|
| Re: Planning for VE 1.1 [message #602651 is a reply to message #70064] |
Fri, 05 November 2004 18:15 |
Chas Douglass
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
Joe Winchester <winchest@uk.ibm.com> wrote in
news:cmfigc$666$1@eclipse.org:
[snip]
> Can you please provide your class as a test case we can use ? If you
> open a specific bugzilla and attach your code this would be great, as
> well as reproducible steps so we can observe the problem.
>
Aye, there's the rub. The class file is 3500+ lines of code (largely
generated by VE), and the project is 12,000 lines of code.
Unfortunately, while not a large project, a tad big for a test case, I
think. As I'm on deadline, I don't have time right now to make a
smaller test case, but it's something I keep in mind because I do want
this stuff to work.
[snip]
> We were thinking of changing the whole GUI when the parser is paused
> to better show to the user that it is not going to function. One idea
> was for the GUI canvas to grey itself out (to appear in a disabled
> state), and likewise some kind of grey wash for the JavaBeans viewer
> and properties sheet. Would this be an improvement ?
Definitely.
>
>> Drag and drop in the JavaBeans view is horribly broken. After a
>> couple of tries that usually result in all my controls dropping off
>> my frame and into the "free space" in the design window, I give up
>> and go manually move code around. Sometimes I remember to manually
>> stop reparsing so it won't get confused yet again, but usually I
>> forget and step in that pile of doo-doo yet again.
>
> Again, if you can provide a test case this would be great. Try to put
> this in specfic terms for us to be able to re-create the problem with
> the same starting point as you rather than make it an emotional
> write-up - that way we can observe and fix the problem
>
Actually, this one is easy to reproduce, so I'll go write the bug up
now. This is a good reminder to me to at least put the effort into
working the system to get the product working for me.
Filed as bug #77976
[remainder snipped]
Chas Douglass
|
|
|
| Re: Planning for VE 1.1 [message #602849 is a reply to message #70141] |
Tue, 09 November 2004 17:07 |
David J. Orme
Messages: 291
Registered: July 2009 |
Senior Member |
|
|
>>Can you please provide your class as a test case we can use ? If you
>>open a specific bugzilla and attach your code this would be great, as
>>well as reproducible steps so we can observe the problem.
>>
> Aye, there's the rub. The class file is 3500+ lines of code (largely
> generated by VE), and the project is 12,000 lines of code.
> Unfortunately, while not a large project, a tad big for a test case, I
> think. As I'm on deadline, I don't have time right now to make a
> smaller test case, but it's something I keep in mind because I do want
> this stuff to work.
Idea: Maybe we should create a scalability test framework.
Joe, how difficult would it to be to script VE to make it generate large
random layouts of configurable sizes? I'm thinking of making a test
harness that would execute something like the following algorithm:
Create a new visual Composite (or JPanel, etc)
currentElement = parent Composite
Generate a random depth between 3 and 5
createControls(depth, currentElement)
method createControls(depth, currentElement) {
if (depth > 0) {
numberOfChildren = a random number between 0 and 10;
for i from 1 to numberOfChildren {
controlType = pick a random control type
child = dropIntoParent(currentElement, controlType)
if (child isA container)
createControls(depth-1, child)
}
}
}
By tweaking the depth and number of children parameters to this
algorithm, we should be able to generate large layouts that we can use
to stress-test VE in some interesting ways.
Perhaps we should add something like this to our plan?
The process of creating such a test framework might also be an
interesting thing to document to help folks who want to hack VE internals...
Good idea? Bad? What does everyone think?
Regards,
Dave
--
Dave Orme
Eclipse Visual Editor Project Lead
Advanced Systems Concepts' Chief Architect
http://www.swtworkbench.com http://essentialdata.sf.net
|
|
|
| Re: Planning for VE 1.1 [message #602927 is a reply to message #70788] |
Wed, 10 November 2004 18:05 |
Chas Douglass
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
David Orme <daveo@asc-iseries.com> wrote in
news:cmqter$92p$1@eclipse.org:
>>>Can you please provide your class as a test case we can use ? If you
>>>open a specific bugzilla and attach your code this would be great, as
>>>well as reproducible steps so we can observe the problem.
>>>
>> Aye, there's the rub. The class file is 3500+ lines of code (largely
>> generated by VE), and the project is 12,000 lines of code.
>> Unfortunately, while not a large project, a tad big for a test case,
>> I think. As I'm on deadline, I don't have time right now to make a
>> smaller test case, but it's something I keep in mind because I do
>> want this stuff to work.
>
> Idea: Maybe we should create a scalability test framework.
>
[snip]
> Perhaps we should add something like this to our plan?
>
> The process of creating such a test framework might also be an
> interesting thing to document to help folks who want to hack VE
> internals...
>
> Good idea? Bad? What does everyone think?
>
As a non-VE programmer, it sounds good to me largely on the basis that
more tests are always better.
I fear that the problem may have to do with the large number of my
controls that don't parse, however. Just quickly glancing through it
looks like about 25% of my controls get "too complicated to parse".
Interesting. On inspection I see I have a number of fields getting
either "Illegal Argument Exception" or "Class Not Found Exception". They
have the little yellow triangle with an exclamation point, so I just
assumed they were "too complicated".
This is code that *does* compile and run, so I don't know what those
exceptions are.
Chas Douglass
|
|
|
| Re: Planning for VE 1.1 [message #603075 is a reply to message #71127] |
Sun, 14 November 2004 19:36 |
Joe Winchester
Messages: 496
Registered: July 2009 |
Senior Member |
|
|
Hi Chas,
> I fear that the problem may have to do with the large number of my
> controls that don't parse, however. Just quickly glancing through it
> looks like about 25% of my controls get "too complicated to parse".
>
> Interesting. On inspection I see I have a number of fields getting
> either "Illegal Argument Exception" or "Class Not Found Exception". They
> have the little yellow triangle with an exclamation point, so I just
> assumed they were "too complicated".
>
> This is code that *does* compile and run, so I don't know what those
> exceptions are.
Is this code that the VE created, or is the class written by something
other than the VE (i.e. yourself by hand or another IDE GUI builder tool ?).
When the VE opens it doesn't run you .class, instead it analyzes the
code to see the relationships between JavaBeans and creates its own
object model. This is turned into live instances that you can see
previewed in the graph viewer.
for example, if there is the line
myJScrollbar = new JScrollbar();
jScrollbar.setOrientation(javax.swing.JScrollbar.VERTICAL);
what occurs is that a JScrollbar is created using the null constructor,
and then an int using a public field "VERTICAL" on the class
javax.swing.JScrollbar, and then the set method called.
The exceptions are occuring because when the set method is executed some
kind of problem occured. An example is something like
jScrollbar.setOrientation(9);
where the JScrollbar throws an exception (cause 9 isn't one of 0 or 1
which is the only allowable vlaue).
There should be more detail on the exception in the status bar when you
select the JavaBean, and also a detailed stack trace in the .log file in
the .metadata directory.
The "too complicated" error is for when the code can't be analyzed by
our evaluator, for example non-static inner classes or some kinds on
unqualified statements although we're getting better at handling these.
The "too complicated" error has a blue information sign and is
different to a yellow warning which means "a JavaBean exception occured
on the target JVM" when a set method was called due to a property being
set". The property name is shown in the status bar when you select the
JavaBean, and in newer drivers hovering over the JavaBean in the graph
viewer should show the full error text as well.
It sounds like your test case is too large to get to use to use, however
I'd still like to take a look at it. Is is possible we could get
together via a net-meeting or something to look into this more ? The
fact you have a test case that doesn't work is great as it means we have
something we can observe and then fix.
Best regards,
Joe Winchester
|
|
|
| Re: Planning for VE 1.1 [message #603077 is a reply to message #70788] |
Sun, 14 November 2004 19:38 |
Joe Winchester
Messages: 496
Registered: July 2009 |
Senior Member |
|
|
Hi Dave,
> Joe, how difficult would it to be to script VE to make it generate large
> random layouts of configurable sizes? I'm thinking of making a test
> harness that would execute something like the following algorithm:
>
> Create a new visual Composite (or JPanel, etc)
> currentElement = parent Composite
> Generate a random depth between 3 and 5
> createControls(depth, currentElement)
>
> method createControls(depth, currentElement) {
> if (depth > 0) {
> numberOfChildren = a random number between 0 and 10;
> for i from 1 to numberOfChildren {
> controlType = pick a random control type
> child = dropIntoParent(currentElement, controlType)
> if (child isA container)
> createControls(depth-1, child)
> }
> }
> }
>
> By tweaking the depth and number of children parameters to this
> algorithm, we should be able to generate large layouts that we can use
> to stress-test VE in some interesting ways.
>
> Perhaps we should add something like this to our plan?
I think this is a great idea. The more tests we have to stress the VE
against the better it'll become, and from Chas's posts and others there
are clearly scenarios we're encountering that we've not anticipated.
Best regards,
Joe Winchester
|
|
| |
| Re: Planning for VE 1.1 [message #603095 is a reply to message #71815] |
Mon, 15 November 2004 14:52 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
You can do that through the property sheet. Select both components and
change the size property.
Francesc Rosés Albiol wrote:
> Hello,
> I'll suggest a, I suspect, very simple improvemenet. Now you have the
> possibility to assign the same height and the same width to two or more
> selected components, but if I need to assign the "same size" I need to
> assign first the same height (or width) and then the same width (or
> height) to the selected components. I think may be useful a new button
> to assign "the same size".
> Tnaks in advance,
> Francesc
>
--
Thanks,
Rich Kulp
|
|
| | |
| Re: Planning for VE 1.1 [message #603121 is a reply to message #71834] |
Mon, 15 November 2004 22:16 |
Francesc Rosés
Messages: 213
Registered: July 2009 |
Senior Member |
|
|
Rich Kulp wrote:
> You can do that through the property sheet. Select both components and
> change the size property.
> Francesc Rosés Albiol wrote:
>> Hello,
>> I'll suggest a, I suspect, very simple improvemenet. Now you have the
>> possibility to assign the same height and the same width to two or more
>> selected components, but if I need to assign the "same size" I need to
>> assign first the same height (or width) and then the same width (or
>> height) to the selected components. I think may be useful a new button
>> to assign "the same size".
>> Tnaks in advance,
>> Francesc
>>
Hi Rich,
Yes, I can set the size property from the properties editor, but I think
is more useful to include a new button in the Customize Layout like the
existing buttons "Match width" and "Match height", doing "Match size".
Francesc Rosés
|
|
| | | |
| Re: Planning for VE 1.1 [message #603177 is a reply to message #72112] |
Wed, 17 November 2004 18:29 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
Joe wasn't being snide either. :-) Joe is always respectful to
respondents in the newsgroup. He appreciates and looks forward to their
input. He was just being honest, we aren't perfect. He just forgot the
smiley ( :-) ) after "Cause we're not perfect," that's all.
Chas Douglass wrote:
> Joe Winchester <winchest@uk.ibm.com> wrote in news:cncrau$p4h$1
> @www.eclipse.org:
>
>
>
>>>On the subject of the Customize Layout dialog (and with apologies to the
>>>OP for thread hijacking) why isn't this a toolbar that can be docked?
>>
>>Cause we're not perfect. It would be nice if it was dockable however.
>>There are a lot of things on the VE queue but if you are feeling brave
>>please open a bugzilla for this and if you want to begin coding it
>>that'd be great and submit a code patch.
>>
>>Best regards,
>>
>>Joe Winchester
>
>
> My sincere apologies if my question sounded critical. It was an honest
> request. As I am not at all familiar with Eclipse coding, I presumed there
> was a design decision behind it, and was innocently asking for information.
>
> Chas Douglass
--
Thanks,
Rich Kulp
|
|
|
| Re: Planning for VE 1.1 [message #603243 is a reply to message #71758] |
Mon, 22 November 2004 14:18 |
Gili Mendel
Messages: 338
Registered: July 2009 |
Senior Member |
|
|
Joe Winchester wrote:
> Hi Dave,
>
>> Joe, how difficult would it to be to script VE to make it generate
>> large random layouts of configurable sizes? I'm thinking of making a
>> test harness that would execute something like the following algorithm:
>>
>> Create a new visual Composite (or JPanel, etc)
>> currentElement = parent Composite
>> Generate a random depth between 3 and 5
>> createControls(depth, currentElement)
>>
>> method createControls(depth, currentElement) {
>> if (depth > 0) {
>> numberOfChildren = a random number between 0 and 10;
>> for i from 1 to numberOfChildren {
>> controlType = pick a random control type
>> child = dropIntoParent(currentElement, controlType)
>> if (child isA container)
>> createControls(depth-1, child)
>> }
>> }
>> }
>>
>> By tweaking the depth and number of children parameters to this
>> algorithm, we should be able to generate large layouts that we can use
>> to stress-test VE in some interesting ways.
>>
>> Perhaps we should add something like this to our plan?
>
>
> I think this is a great idea. The more tests we have to stress the VE
> against the better it'll become, and from Chas's posts and others there
> are clearly scenarios we're encountering that we've not anticipated.
>
> Best regards,
>
> Joe Winchester
Peter Walker has been using Abbot to automate smoke tests Swing/SWT. You can extend these automated tests.
|
|
|
| Re: Planning for VE 1.1 [message #603325 is a reply to message #69905] |
Wed, 24 November 2004 16:58 |
David J. Orme
Messages: 291
Registered: July 2009 |
Senior Member |
|
|
David Orme wrote:
> Everyone is back now and we have now published the Visual Editor Project
> version 1.1 draft plan on the web site.
>
> http://www.eclipse.org/vep
It looks like the only new suggestion we have received is the idea about
how to stress-test VE more exhaustively, and we have agreed that we will
do this. Since this seems to be something we should just do as a matter
of course, it will not go on the plan, but we will do it (in fact we
already are implementing this).
So given all of this, I will now declare this to be our VE 1.1 plan and
update the web site accordingly.
However, just as the plan document says, "Plans do not materialize out
of nowhere, nor are they entirely static." If you have a killer idea
about something we should add to VE, please post it on the ve-dev
mailing list and we will add it to the appropriate place in the plan
document.
Best regards,
Dave Orme
--
Dave Orme
Eclipse Visual Editor Project Lead
Advanced Systems Concepts' Chief Architect
http://www.swtworkbench.com http://essentialdata.sf.net
|
|
|
| Re: Planning for VE 1.1 [message #603443 is a reply to message #66370] |
Sun, 28 November 2004 23:31 |
| Eclipse User |
|
|
|
Originally posted by: markbrazil.spymac.com
9) Mac Support !
Yes please, mac support soon.
Jeff Lambourne wrote:
> David Orme wrote:
>> David Orme wrote:
>> > 1) Poll everyone and see what folks would ideally like in their
>> > "perfect" VE.
>> The VE developers have identified the following areas (listed in no
>> particular order). Please critique and/or add to this list whatever you
>> might like to see.
>> 1) Performance work. VE is still slow in some areas.
>> 2) Object factory support / JFace support
>> JFace has taken the lead by creating SWT layouts using a
>> public Composite createPartControl(Composite parent);
>> factory method pattern. Essential Data and other frameworks have copied
>> this good idea and used it all over the place. We need to support this.
> This could tie up with (4) - Basic RCP support. What do the RCP guys
> think?
>> 3) More coding pattern support
>> So you can bring your JBuilder project, NetBeans project, etc., into VE.
>> 4) Basic RCP support
>> Ability to create Eclipse views and editors using VE.
>> 5) The ablility to add, move and delete items/categories from the palette.
>> 6) API documentation. We should pick (from now on each release) as set
>> of development use cases (e.g., extending a palette, adding a layout
>> mgr. etc.) document, clean and open the VE API to drive these. Two
>> different groups cited this as important.
>> 7) Copy/paste controls on the design surface.
>> 8) FormLayout and possibly other layout manager support (JGoodies?)
> 9) Dare I say - support for the mac platform
>> Best Regards,
>> Dave Orme
|
|
| |
Goto Forum:
Current Time: Sun Nov 03 12:08:06 GMT 2024
Powered by FUDForum. Page generated in 0.18698 seconds |
] 
Search
Help
Register
Login
Home
