[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [ve-dev] RE: Sweet BeanInfo for SWT
|
Title: Message
Given the way SUN's introspector is
implemented today, we will have to compromise with some tactical solution for
the short term (v1.0.0 of VE), while pursuing a proper extension of BeanInfo
to support the above through a JSR (at minimum available in JDK 1.6).
If we are to use a tactical solution, it should be one that will work with any
JRE implementation, and one that is very specific, and easy to implement for
SWT.
I have
no problem with this.
To accelerate this discussion so that we can start and drive forward
with VE 1.0.0 I intend to set up a conf. call to iterate some more on this
topic. At a minimum it will be great if Joe, Dave, and Scott would be
available for this discussion.
This
sounds like a good idea to me as long as we have someone keep meeting minutes
and post those back here for everyone else's benefit.
Does any one have any problem with a 2hr
discussion on one of the following dates:
morning of Thur. 3/4/04
morning
of Fri 4/4/04
I'm
fine with both of these so long as we're done by 11:00 AM
CST.
Regards,
Dave
------------
Dr. Gili
Mendel
IBM
Software Development
RTP Raleigh, NC
(919)543 6408,
tie: 441 6408
Dave Orme
<DaveO@xxxxxxxxxxxxxxx>
Sent by: ve-dev-admin@xxxxxxxxxxx
03/02/2004 09:07 AM
|
|
To
| "'ve-dev@xxxxxxxxxxx'"
<ve-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| RE: [ve-dev] RE: Sweet
BeanInfo for SWT |
|
(Please correct me if I'm wrong, but the point of the code
below was that I think it addresses all of the issues you raised.
Yes?)
-----Original
Message-----
From: Dave Orme [mailto:DaveO@xxxxxxxxxxxxxxx]
Sent: Tuesday, March 02, 2004 7:58 AM
To:
've-dev@xxxxxxxxxxx'
Subject: RE: [ve-dev] RE: Sweet BeanInfo for
SWT
>There are 3 kinds of "properties" you have to deal with in
SWT:
>- Traditional JavaBeans properties
>- Style bit
properties
>- Public fields
>The idea with the current spec is to
define a way that lets the builder treat all 3 the same as much as
possible.
>I'm not sure I see a good reason here to abandon
this?
The thinking
is that a java.beans.PropertyDescriptor assumes there is a get and/or set
method associated. With a field or constructor style bit there isn't.
What we're trying to do with BeanInfo is to describe things that the
builder tool can use, so having a java.beans.PropertyDescriptor doesn't mean
it belongs on the property sheet - it means there is a get and/or set method
that the tool knows how to show and set values for.
This is true in the abstract, but in reality a bunch of
things that have public fields do wind up on the property sheet in one form or
another. I'm thinking of org.eclipse.swt.Point and
org.eclipse.swt.Rectangle off the top of my head.
So the original
idea with Sweet was to make it possible for the tool to be able to deal with
all of these things that need to be represented on the property sheet
uniformly as much as possible.
While I follow and agree with your argument from
a pragmatic point of view, my concern is that I don't want us to lose track of
this from the big picture perspective.
<snip/> Therefore - I still
think that the features should be on the BeanDescriptor rather than overload
the java.beans.PropertyDescriptor. I'd hate to see a new release of
java.beans.PropertyDescriptor kill us.
I agree here.
Can you describe the issues with extending
FeatureDescriptor more fully? The intent underlying the original Sweet
specification / implementation was that individual BeanInfo classes would use
java.beans.Introspector as-is, then manually massage them into the state they
needed to be. So, here's how ButtonComponentInfo might look if the style
bit property were added by creating a new StylePropertyDescriptor that extends
FeatureDescriptor:
public class ButtonComponentInfo extends OverrideComponentInfo //
which extends SimpleBeanInfo {
public ButtonComponentInfo() {
// Introspect JavaBeans properties, etc, using
java.beans.Introspector
// This automatically gets us all the standard
java.beans-compliant properties and events
super(Button.class);
BeanDescriptor bd = getBeanDescriptor();
// Set the icons
bd.setValue("iconURLs",
new Object[] {
new Integer(BeanInfo.ICON_COLOR_16x16),
getClass().getResource("icons/Button.gif"),
new
Integer(BeanInfo.ICON_MONO_16x16),
getClass().getResource("icons/ButtonMono.gif")
}
);
// Set the palette page
bd.setValue("categories", "Basic");
// StylePropertyDescriptor extends
FeatureDescriptor
StylePropertyDescriptor stylePropertyDescriptor = new
StylePropertyDescriptor();
stylePropertyDescriptor.setValue("isStyleBit",
new Boolean(true));
// We'll use the grouping
structure you proposed...
styleValues = new Object[][]
{
"style" , new Object[] {
"arrow" , "org.eclipse.swt.SWT.ARROW" , new
Integer(SWT.ARROW) ,
"push" ,
"org.eclipse.swt.SWT.PUSH" , new Integer(SWT.PUSH),
"toggle" , "org.eclipse.swt.SWT.TOGGLE" , new Integer(SWT.TOGGLE)
,
"flat" , "org.eclipse.swt.SWT.FLAT" ,
new Integer(SWT.FLAT) ,
"radio" ,
"org.eclipse.swt.SWT.RADIO" , new Integer(SWT.RADIO) } ,
"alignment" , new Object[] {
"left" , "org.eclipse.swt.SWT.LEFT" , new Integer(SWT.LEFT) ,
"right" , "org.eclipse.swt.SWT.RIGHT" , new
Integer(SWT.RIGHT) ,
"center" ,
"org.eclipse.swt.SWT.CENTER" , new Integer(SWT.CENTER) } ,
"arrowDirection", new Object[] {
"up" , "org.eclipse.swt.SWT.UP" , new Integer(SWT.UP) ,
"left" , "org.eclipse.swt.SWT.LEFT" ,
new Integer(SWT.LEFT) ,
"right" ,
"org.eclipse.swt.SWT.RIGHT" , new Integer(SWT.RIGHT) } ,
} ;
stylePropertyDescriptor.setStyleValues(styleValues);
// Method added in OverrideComponentInfo...
setStylePropertyDescriptor(stylePropertyDescriptor);
}
}
Also - you mention public fields. The only
ones I can think of off hand are things like RowData, GridData, FormData,
Rectangle or Point. These are basically data structures that SWT uses
elsewhere (i.e. in layout managers or controls). For actual subclasses
of org.eclipse.swt.widgets.Widget are there any public fields that the VE has
to be aware of in its model ?
Not
that I can think of right now. Does anyone else know of any?
However, I don't think this changes the fact that we need to find a
suitable way to represent these... I think we're still going to want to
be able to expand the fields of the Rectangle object contained in a Bounds
property and let the user edit the individual fields individually in the
property sheet.
Regards,
Dave
