Home » Archived » Visual Editor (VE) » VE 1.1 ergonomics suggestions
| VE 1.1 ergonomics suggestions [message #98250] |
Mon, 18 July 2005 14:42  |
 Francesc Rosés
Messages: 213
Registered: July 2009 |
Senior Member |
|
|
Hello,
I'm testing the latest VE 1.1 driver and I
have several ergonomics suggestions may be
interesting to discus in tis list:
1. May be interesting the contents of new
name fields in the "Rename Bean" dialog
is automatically selected to make easy
overwrite the old bean name (otherwise, I
must type, for example, ctrl-a to select
the old bean name and overwrite it).
2. May be interesting to add the possibility
of multiple copy/cut/paste. Now I can only
copy one object at once.
3. When I paste an object only the supported
properties are copied. For example, if
I have a JTextField with the unsupported
property "focusable" set to "false",
the new JTextField is focusable (by default)
4. My be interesting when I paste an object
the "Rename Bean" dialog appears.
5. When I drop an object from the palette to
the design area, and I have a "snap to grid",
must be interesting the object will be positioned
adjusted to the grid.
6. The VE preferences pages allows to specify a default
"X/Y Grid Spacing". May be interesting the user can
specify the "margin" too.
7. When I paste a bean to a container with null layout,
may be interesting the new bean maintains the original
bean size (width and height)
8. If possible, the "snap to grid" property state need
to be preserved between editing sessions.
What do you think about this list?
Francesc Rosés
|
|
|
| Re: VE 1.1 ergonomics suggestions [message #98578 is a reply to message #98250] |
Wed, 20 July 2005 10:29  |
Joe Winchester
Messages: 496
Registered: July 2009 |
Senior Member |
|
|
Hi Francesc,
> 1. May be interesting the contents of new name fields in the "Rename
> Bean" dialog is automatically selected to make easy overwrite the
> old bean name (otherwise, I must type, for example, ctrl-a to select
> the old bean name and overwrite it).
Do you want the old name to be selected when the text field receives
focus ? Sounds like a nicie nugglet (that's what we call a feature
request that isn't tough to implement and has good benefit). If you
would like to code it yourself as an exercise that would be wonderful -
join the ve-dev mailing list and we can give you instructions for how to
get a development workspace set up and you could change it and then once
you like what you've done post the code snippet to this bugzilla (or
e-mail me with it or the ve-dev mailing list) as a patch and we'll file
it in.
> 2. May be interesting to add the possibility of multiple
> copy/cut/paste. Now I can only copy one object at once.
We thought about this and wrestled with what it would mean and couldn't
come up with a good scenario. Here's the problem - when you paste you
are dropping onto the GUI at a particular point. The target
Container/Composite says "aha - I know how to generate a layout
constraint at that point" and adds the new child. This is very
dependent on the layout manager so null is different to Flow which is
different to Grid, etc... If you were pasting >1 child then what
occured could be hard to get right. Say you copied a bunch of controls
from a null layout parent to another null layout that makes sense - we
just bring over the bounds/size/layout. What if they came from a grid
parent to another grid though ? Would we try to somehow preserve the
constraints from the old one - or we would just flow them all into the
new parent at the drop location one after the other ? What if you went
from grid to null - would we try to preserve the relative locations they
occupied in the old grid and make new bounds/size/location to try to
match ?
If you have the time to write a design spec on how you want multiple
copy/paste to work that would be great. Open a bugzilla feature request
and include as much detail as you want and we'll discuss is there and
then hopefully once we agree on how it should work we can implement it
soon thereafter.
> 3. When I paste an object only the supported properties are copied.
> For example, if I have a JTextField with the unsupported property
> "focusable" set to "false", the new JTextField is focusable (by default)
The code only sees the properties that are modelled. This is really a
problem cause "focusable" is a new 1.4 property we don't yet support so
it isn't on the property sheet. Can you please open a bugzilla for
this, or else if you are into the idea of writing patches change the
class JTextFieldBeanInfo to add it and send us a patch.
> 4. My be interesting when I paste an object the "Rename Bean" dialog
> appears.
Totally. I only noticed we didn't the other day when I was doing some
testing so this is really a bug. Please open a bugzilla bug request for
this
> 5. When I drop an object from the palette to the design area, and I
> have a "snap to grid", must be interesting the object will be
> positioned adjusted to the grid.
It should snap to the grid when the snap to grid is on. What part of
this isn't working as you expect it should ?
> 6. The VE preferences pages allows to specify a default "X/Y Grid
> Spacing". May be interesting the user can specify the "margin" too.
You can do this from the "layout dialog". This is opened using the
"Show customize layout window" toolbar option that is on the far right
and the "layout" tab. I think the reason it isn't on the preferences is
because the "show grid" applies to Swing GridBagLayout, SWT GridLayout
and possibly other layouts in the future where the concept of a grid
makes sense, and "margin" only applies to a null grid so rather than
have it on the preferences page it is on the dialog. However the
preferences page could possibly show you all preferences for all
available layout managers and let you globally set them and this would
be a nice feature.
> 7. When I paste a bean to a container with null layout, may be
> interesting the new bean maintains the original bean size (width and
> height)
It should so please open a bugzilla feature request for this. Not only
should bounds be preserved going from null to null, but say you were
going from GridBag (or any other) to null then the bounds should be the
size it used to occupy on the old layout. Likewise GridBag to GridBag
and the stuff like fill, anchor etc... should be brought forward.
> 8. If possible, the "snap to grid" property state need to be preserved
> between editing sessions.
I agree and this sounds like an oversight on our part. Please open a
bugzilla for this as well
> What do you think about this list?
It's great. You've obviously put a lot of thought into these
bugs/features so please open some bugzillas and I'd also urge you to
consider whether or not you want to tackle the first one yourself.
We'll help you get set up with a workspace you can develop in and file
the fix in. Open-source is all about having a community of people who
do everything from coding the tool, using the tool, testing the tool,
reporting bugs, designing and specifying changes. If you go through the
route of speccing changes and coding fixes and patches we can file in
there is the avenue of graduation to a comitter (although there is an
approval and voting process that occurs so it takes time and comittment
on your part), but being part of an open-source tool like VE is fun,
challenging and rewarding and whatever level you wish to particpate, and
the best changes that are made to the tool are ones that folks like
yourself request from real world usage.
Best regards and many thanks,
Joe Winchester
|
|
|
| Re: VE 1.1 ergonomics suggestions [message #609116 is a reply to message #98250] |
Wed, 20 July 2005 10:29 |
Joe Winchester
Messages: 496
Registered: July 2009 |
Senior Member |
|
|
Hi Francesc,
> 1. May be interesting the contents of new name fields in the "Rename
> Bean" dialog is automatically selected to make easy overwrite the
> old bean name (otherwise, I must type, for example, ctrl-a to select
> the old bean name and overwrite it).
Do you want the old name to be selected when the text field receives
focus ? Sounds like a nicie nugglet (that's what we call a feature
request that isn't tough to implement and has good benefit). If you
would like to code it yourself as an exercise that would be wonderful -
join the ve-dev mailing list and we can give you instructions for how to
get a development workspace set up and you could change it and then once
you like what you've done post the code snippet to this bugzilla (or
e-mail me with it or the ve-dev mailing list) as a patch and we'll file
it in.
> 2. May be interesting to add the possibility of multiple
> copy/cut/paste. Now I can only copy one object at once.
We thought about this and wrestled with what it would mean and couldn't
come up with a good scenario. Here's the problem - when you paste you
are dropping onto the GUI at a particular point. The target
Container/Composite says "aha - I know how to generate a layout
constraint at that point" and adds the new child. This is very
dependent on the layout manager so null is different to Flow which is
different to Grid, etc... If you were pasting >1 child then what
occured could be hard to get right. Say you copied a bunch of controls
from a null layout parent to another null layout that makes sense - we
just bring over the bounds/size/layout. What if they came from a grid
parent to another grid though ? Would we try to somehow preserve the
constraints from the old one - or we would just flow them all into the
new parent at the drop location one after the other ? What if you went
from grid to null - would we try to preserve the relative locations they
occupied in the old grid and make new bounds/size/location to try to
match ?
If you have the time to write a design spec on how you want multiple
copy/paste to work that would be great. Open a bugzilla feature request
and include as much detail as you want and we'll discuss is there and
then hopefully once we agree on how it should work we can implement it
soon thereafter.
> 3. When I paste an object only the supported properties are copied.
> For example, if I have a JTextField with the unsupported property
> "focusable" set to "false", the new JTextField is focusable (by default)
The code only sees the properties that are modelled. This is really a
problem cause "focusable" is a new 1.4 property we don't yet support so
it isn't on the property sheet. Can you please open a bugzilla for
this, or else if you are into the idea of writing patches change the
class JTextFieldBeanInfo to add it and send us a patch.
> 4. My be interesting when I paste an object the "Rename Bean" dialog
> appears.
Totally. I only noticed we didn't the other day when I was doing some
testing so this is really a bug. Please open a bugzilla bug request for
this
> 5. When I drop an object from the palette to the design area, and I
> have a "snap to grid", must be interesting the object will be
> positioned adjusted to the grid.
It should snap to the grid when the snap to grid is on. What part of
this isn't working as you expect it should ?
> 6. The VE preferences pages allows to specify a default "X/Y Grid
> Spacing". May be interesting the user can specify the "margin" too.
You can do this from the "layout dialog". This is opened using the
"Show customize layout window" toolbar option that is on the far right
and the "layout" tab. I think the reason it isn't on the preferences is
because the "show grid" applies to Swing GridBagLayout, SWT GridLayout
and possibly other layouts in the future where the concept of a grid
makes sense, and "margin" only applies to a null grid so rather than
have it on the preferences page it is on the dialog. However the
preferences page could possibly show you all preferences for all
available layout managers and let you globally set them and this would
be a nice feature.
> 7. When I paste a bean to a container with null layout, may be
> interesting the new bean maintains the original bean size (width and
> height)
It should so please open a bugzilla feature request for this. Not only
should bounds be preserved going from null to null, but say you were
going from GridBag (or any other) to null then the bounds should be the
size it used to occupy on the old layout. Likewise GridBag to GridBag
and the stuff like fill, anchor etc... should be brought forward.
> 8. If possible, the "snap to grid" property state need to be preserved
> between editing sessions.
I agree and this sounds like an oversight on our part. Please open a
bugzilla for this as well
> What do you think about this list?
It's great. You've obviously put a lot of thought into these
bugs/features so please open some bugzillas and I'd also urge you to
consider whether or not you want to tackle the first one yourself.
We'll help you get set up with a workspace you can develop in and file
the fix in. Open-source is all about having a community of people who
do everything from coding the tool, using the tool, testing the tool,
reporting bugs, designing and specifying changes. If you go through the
route of speccing changes and coding fixes and patches we can file in
there is the avenue of graduation to a comitter (although there is an
approval and voting process that occurs so it takes time and comittment
on your part), but being part of an open-source tool like VE is fun,
challenging and rewarding and whatever level you wish to particpate, and
the best changes that are made to the tool are ones that folks like
yourself request from real world usage.
Best regards and many thanks,
Joe Winchester
|
|
|
Goto Forum:
Current Time: Fri Apr 26 23:45:53 GMT 2024
Powered by FUDForum. Page generated in 0.03271 seconds |
] 
Search
Help
Register
Login
Home
