[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [ve-dev] RE: Sweet BeanInfo for SWT
|
Title: Message
Thurs & fris are bad for me... Post some notes and I
can add comments if you'd like -- I'd hate to get in the way of a
discussion.
Have fun!
-- Scott
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
