Home » Archived » Visual Editor (VE) » Questions on the VE feature set
| Questions on the VE feature set [message #3834] |
Fri, 21 November 2003 14:04  |
Eclipse User |
|
|
|
Originally posted by: ddubinsk.optonline.net
First, let me say that I'm really excited about this new feature. Thanks to
everyone involved.
I have a few questions about the expected functionality.
1) Will you be able to add your own beans to the visual component pallette?
2) Will the tool be able to handle custom non-visual components, beans with
no visual presentation, but GUI related functionality? For example a Data
Access Object for loading the data into the edit fields of on a panel.
3) Will the tool be able to handle non-standard layout managers. Where most
of these Java visual painting tools break down is in the fact that they must
use the standard Java layout managers, which tend to be very poor in general
and a disaster for GUI builders. But there are some good ones out there,
like the TableLayout that aren't standard to Java.
|
|
| |
| Re: Questions on the VE feature set [message #3866 is a reply to message #3859] |
Fri, 21 November 2003 18:29  |
| Eclipse User |
|
|
|
Originally posted by: ddubinsk.optonline.net
Hi Joe,
Thanks for your quick reply.
I actually have an open source tool set for building web applications that
we are expanding into the "rich client" area (It's called SOFIA -
http://www.salmonllc.com/sofia). We already have a bunch of data aware
components that extend the basic Swing components and would like to make
them available via the new Eclipse visual editor. Based on your response,
it looks like that won't be a problem.
We also have our own model component that gets the data that the visual
widgets can be bound to. The way a visual widget gets bound to a database
column is by specifying which model and column to use via a set method. I
suppose we can write some custom bean property editors to do that, so long
as the Visual Editor lets you drop any bean on the page, visual or not, and
can provide some context info on the panel so that one bean knows about the
other ones in the page.
"Joe Winchester" <winchest@uk.ibm.com> wrote in message
news:3FBE81D2.86EA4079@uk.ibm.com...
> Hi Dan,
>
> > 1) Will you be able to add your own beans to the visual component
pallette?
>
> We sort of have a hacky way of already doing this. It was designed for
people
> who are Java Beans providers and give a plugin, and a user just adds a
single
> container to a project's build path to enable it to work with the Java
Beans and
> have the palette show them. There is an article that describes this at
>
http://www-106.ibm.com/developerworks/websphere/library/tech articles/0302_winchester/winchester.html
> although this talks about WSAD APIs. The example code is migrated and
exists in
> the org.eclipse.ve.examples projects, so if you look at the article for
the idea
> and then the org.eclipse.ve.examples project you can get a feel for what's
going
> on.
>
> We do need a better way to do this however to support users who want to
just do
> ad-hoc customization in their workspace. Please add a bugzilla for this
> feature.
>
> > 2) Will the tool be able to handle custom non-visual components, beans
with
> > no visual presentation, but GUI related functionality? For example a
Data
> > Access Object for loading the data into the edit fields of on a panel.
>
> How would you like to see this done ? Right now the Visual Editor doesn't
> provide any palette classes over and above what's in the JFC and this has
no
> data-bound controls such as you get with Visual Basic. There is a thing
called
> JNDC that Sun is working on that is designed to fill this space. I think
some
> of the other IDE providers have their own palette of data aware controls -
is
> this what you're looking for ?
>
> > 3) Will the tool be able to handle non-standard layout managers. Where
most
> > of these Java visual painting tools break down is in the fact that they
must
> > use the standard Java layout managers, which tend to be very poor in
general
> > and a disaster for GUI builders. But there are some good ones out there,
> > like the TableLayout that aren't standard to Java.
>
> We have an internal API for this but this needs to be formalized and made
> public. Please add a bugzilla for this feature.
>
> Best regards,
>
> Joe Winchester
>
|
|
| |
| Re: Questions on the VE feature set [message #5601 is a reply to message #3859] |
Wed, 26 November 2003 10:45 |
| Eclipse User |
|
|
|
Hi Joe,
I have some additional questions about how the VE uses the information form
the BeanInfo class :
In VAJ it was possible to specify some custom properties for a
PropertyDescriptor (preferred and design-time for example). I wonder if a
similar feature exists in the VE editor ("preferred" events or properties
would be displayed in a popup menu, "run-time" properties wouldn't be
displayed in the properties view).
I have to admit the one is not supposed to design its BeanInfo class for a
specific target platform, but since there is some specific packaging to do
for the palette, why not customize the BeanInfos and PropertyDescriptors.
That leads to my second question : is it possible to write a Customizer or a
PropertyDescriptor that will use the JDT API ? And if yes, is it reasonable
to do so (actually the only usage I can think of would be to search the
workspace for all the classes that extend or implement a specific
class/interface).
"Joe Winchester" <winchest@uk.ibm.com> wrote in message
news:3FBE81D2.86EA4079@uk.ibm.com...
> Hi Dan,
>
> > 1) Will you be able to add your own beans to the visual component
pallette?
>
> We sort of have a hacky way of already doing this. It was designed for
people
> who are Java Beans providers and give a plugin, and a user just adds a
single
> container to a project's build path to enable it to work with the Java
Beans and
> have the palette show them. There is an article that describes this at
>
http://www-106.ibm.com/developerworks/websphere/library/tech articles/0302_wi
nchester/winchester.html
> although this talks about WSAD APIs. The example code is migrated and
exists in
> the org.eclipse.ve.examples projects, so if you look at the article for
the idea
> and then the org.eclipse.ve.examples project you can get a feel for what's
going
> on.
>
> We do need a better way to do this however to support users who want to
just do
> ad-hoc customization in their workspace. Please add a bugzilla for this
> feature.
>
> > 2) Will the tool be able to handle custom non-visual components, beans
with
> > no visual presentation, but GUI related functionality? For example a
Data
> > Access Object for loading the data into the edit fields of on a panel.
>
> How would you like to see this done ? Right now the Visual Editor doesn't
> provide any palette classes over and above what's in the JFC and this has
no
> data-bound controls such as you get with Visual Basic. There is a thing
called
> JNDC that Sun is working on that is designed to fill this space. I think
some
> of the other IDE providers have their own palette of data aware controls -
is
> this what you're looking for ?
>
> > 3) Will the tool be able to handle non-standard layout managers. Where
most
> > of these Java visual painting tools break down is in the fact that they
must
> > use the standard Java layout managers, which tend to be very poor in
general
> > and a disaster for GUI builders. But there are some good ones out there,
> > like the TableLayout that aren't standard to Java.
>
> We have an internal API for this but this needs to be formalized and made
> public. Please add a bugzilla for this feature.
>
> Best regards,
>
> Joe Winchester
>
|
|
|
| Re: Questions on the VE feature set [message #6347 is a reply to message #5601] |
Fri, 28 November 2003 15:24 |
| Eclipse User |
|
|
|
Originally posted by: mendelgili.netscape.net
Sébastien Alonzo wrote:
> Hi Joe,
>
> I have some additional questions about how the VE uses the information form
> the BeanInfo class :
> In VAJ it was possible to specify some custom properties for a
> PropertyDescriptor (preferred and design-time for example). I wonder if a
> similar feature exists in the VE editor ("preferred" events or properties
> would be displayed in a popup menu, "run-time" properties wouldn't be
> displayed in the properties view).
Yes. look at
org.eclipse.ve.internal.jfc.beaninfo.AbstractButtonBeanInfo for
actionPerformed/PREFERRED... you can create beanInfo for your
components, but in this case it would be your responsibility to return
the additional beaninfo if you need to return inherent properties.
A plugin can overide current beaninfo from the xmi overides files,
though multiple overides to the same object are not supported at this time.
> I have to admit the one is not supposed to design its BeanInfo class for a
> specific target platform, but since there is some specific packaging to do
> for the palette, why not customize the BeanInfos and PropertyDescriptors.
>
VE provides a specific beaninfo for JFC... see the
org.eclipse.ve.internal.jfc.beaninfo package.
> That leads to my second question : is it possible to write a Customizer or a
> PropertyDescriptor that will use the JDT API ? And if yes, is it reasonable
> to do so (actually the only usage I can think of would be to search the
> workspace for all the classes that extend or implement a specific
> class/interface).
>
For a property editors, VE will let you provide a target VM based
property editor, e.g., color (see
org.eclipse.ve.internal.jfc.beaninfo.ColorEditor) or IDE based editor,
e.g., icon (see org.eclipse.ve.internal.jfc.core.ImageIconLabelProvider).
If you use an IDE based (one that runs inside the IDE) property editor,
you whould be able to utilize JDT.
>
> "Joe Winchester" <winchest@uk.ibm.com> wrote in message
> news:3FBE81D2.86EA4079@uk.ibm.com...
>
>>Hi Dan,
>>
>>
>>>1) Will you be able to add your own beans to the visual component
>
> pallette?
>
>>We sort of have a hacky way of already doing this. It was designed for
>
> people
>
>>who are Java Beans providers and give a plugin, and a user just adds a
>
> single
>
>>container to a project's build path to enable it to work with the Java
>
> Beans and
>
>>have the palette show them. There is an article that describes this at
>>
>
> http://www-106.ibm.com/developerworks/websphere/library/tech articles/0302_wi
> nchester/winchester.html
>
>>although this talks about WSAD APIs. The example code is migrated and
>
> exists in
>
>>the org.eclipse.ve.examples projects, so if you look at the article for
>
> the idea
>
>>and then the org.eclipse.ve.examples project you can get a feel for what's
>
> going
>
>>on.
>>
>>We do need a better way to do this however to support users who want to
>
> just do
>
>>ad-hoc customization in their workspace. Please add a bugzilla for this
>>feature.
>>
>>
>>>2) Will the tool be able to handle custom non-visual components, beans
>
> with
>
>>>no visual presentation, but GUI related functionality? For example a
>
> Data
>
>>>Access Object for loading the data into the edit fields of on a panel.
>>
>>How would you like to see this done ? Right now the Visual Editor doesn't
>>provide any palette classes over and above what's in the JFC and this has
>
> no
>
>>data-bound controls such as you get with Visual Basic. There is a thing
>
> called
>
>>JNDC that Sun is working on that is designed to fill this space. I think
>
> some
>
>>of the other IDE providers have their own palette of data aware controls -
>
> is
>
>>this what you're looking for ?
>>
>>
>>>3) Will the tool be able to handle non-standard layout managers. Where
>
> most
>
>>>of these Java visual painting tools break down is in the fact that they
>
> must
>
>>>use the standard Java layout managers, which tend to be very poor in
>
> general
>
>>>and a disaster for GUI builders. But there are some good ones out there,
>>>like the TableLayout that aren't standard to Java.
>>
>>We have an internal API for this but this needs to be formalized and made
>>public. Please add a bugzilla for this feature.
>>
>>Best regards,
>>
>>Joe Winchester
>>
>
>
>
|
|
|
| Re: Questions on the VE feature set [message #6655 is a reply to message #6347] |
Mon, 01 December 2003 11:54 |
| Eclipse User |
|
|
|
"Gili Mendel" <mendelgili@netscape.net> wrote in message
news:bq8aq1$qm0$1@eclipse.org...
> > I have some additional questions about how the VE uses the information
form
> > the BeanInfo class :
> > In VAJ it was possible to specify some custom properties for a
> > PropertyDescriptor (preferred and design-time for example). I wonder if
a
> > similar feature exists in the VE editor ("preferred" events or
properties
> > would be displayed in a popup menu, "run-time" properties wouldn't be
> > displayed in the properties view).
>
> Yes. look at
> org.eclipse.ve.internal.jfc.beaninfo.AbstractButtonBeanInfo for
> actionPerformed/PREFERRED... you can create beanInfo for your
> components, but in this case it would be your responsibility to return
> the additional beaninfo if you need to return inherent properties.
Thanks for your answer, Gili, it works pretty well.
I still don't understand if the VE is using the "getIcon(int iconkind)"
method of the BeanInfo class, but it's not such a big deal. The only side
effect I see is that widgets don't look the same in the Palette and in the
'Java Beans' view.
>
> A plugin can overide current beaninfo from the xmi overides files,
> though multiple overides to the same object are not supported at this
time.
>
Is there some documentation about these xmi overrides files ?
That leads to another question : Will there be a change in API for all these
xmi files (for the palette, override, ...) in the release for Eclipse 3.0 ?
I'm asking this because the palette xmi file is a bit different between WSAD
VEJ and Eclipse VE (ok it's probably just the namespaces, but still I cannot
write a plugin which could work for both).
|
|
|
| Re: Questions on the VE feature set [message #7368 is a reply to message #6655] |
Mon, 01 December 2003 14:58 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.NO.SPAM.us.ibm.com
getIcon() is the one thing we aren't using. We have a feature for that
for the next release. The biggest problem is that getIcon() returns an
AWT icon/image, and we need it to be an SWT image. We just ran out of
time to get this working correctly.
One big problem with using the getIcon on the palette is that we don't
want to force introspection for every bean that shows up on a palette
just to get the icon to show. So the palette will probably always have a
separate pointer to the icon to use in it. If we required introspection,
the editor would never come up :-)
As for the format of the override files, there is a small chance they
will change again when we step up to EMF2.0. The override code is
currently supplied internally by EMF, but EMF is picking it up for their
next opensource release. However, we are trying to make sure it doesn't
change much, if any. I'm in discussion with them on this right now.
We don't have any documentation on them yet. This release was simply to
get everything out there to use. As we work on the next and further
releases, there will be specific API and documentation available for how
to extend the editor. In the meantime there will also be articles
created for this kind of stuff, like we have one for WSAD for palette
extension, which is being updated for VE palette extension.
--
Thanks, Rich Kulp
|
|
|
| Re: Questions on the VE feature set [message #568285 is a reply to message #3834] |
Fri, 21 November 2003 16:21 |
| Eclipse User |
|
|
|
Hi Dan,
> 1) Will you be able to add your own beans to the visual component pallette?
We sort of have a hacky way of already doing this. It was designed for people
who are Java Beans providers and give a plugin, and a user just adds a single
container to a project's build path to enable it to work with the Java Beans and
have the palette show them. There is an article that describes this at
http://www-106.ibm.com/developerworks/websphere/library/tech articles/0302_winchester/winchester.html
although this talks about WSAD APIs. The example code is migrated and exists in
the org.eclipse.ve.examples projects, so if you look at the article for the idea
and then the org.eclipse.ve.examples project you can get a feel for what's going
on.
We do need a better way to do this however to support users who want to just do
ad-hoc customization in their workspace. Please add a bugzilla for this
feature.
> 2) Will the tool be able to handle custom non-visual components, beans with
> no visual presentation, but GUI related functionality? For example a Data
> Access Object for loading the data into the edit fields of on a panel.
How would you like to see this done ? Right now the Visual Editor doesn't
provide any palette classes over and above what's in the JFC and this has no
data-bound controls such as you get with Visual Basic. There is a thing called
JNDC that Sun is working on that is designed to fill this space. I think some
of the other IDE providers have their own palette of data aware controls - is
this what you're looking for ?
> 3) Will the tool be able to handle non-standard layout managers. Where most
> of these Java visual painting tools break down is in the fact that they must
> use the standard Java layout managers, which tend to be very poor in general
> and a disaster for GUI builders. But there are some good ones out there,
> like the TableLayout that aren't standard to Java.
We have an internal API for this but this needs to be formalized and made
public. Please add a bugzilla for this feature.
Best regards,
Joe Winchester
|
|
|
| Re: Questions on the VE feature set [message #568366 is a reply to message #3859] |
Fri, 21 November 2003 18:29 |
| Eclipse User |
|
|
|
Originally posted by: ddubinsk.optonline.net
Hi Joe,
Thanks for your quick reply.
I actually have an open source tool set for building web applications that
we are expanding into the "rich client" area (It's called SOFIA -
http://www.salmonllc.com/sofia). We already have a bunch of data aware
components that extend the basic Swing components and would like to make
them available via the new Eclipse visual editor. Based on your response,
it looks like that won't be a problem.
We also have our own model component that gets the data that the visual
widgets can be bound to. The way a visual widget gets bound to a database
column is by specifying which model and column to use via a set method. I
suppose we can write some custom bean property editors to do that, so long
as the Visual Editor lets you drop any bean on the page, visual or not, and
can provide some context info on the panel so that one bean knows about the
other ones in the page.
"Joe Winchester" <winchest@uk.ibm.com> wrote in message
news:3FBE81D2.86EA4079@uk.ibm.com...
> Hi Dan,
>
> > 1) Will you be able to add your own beans to the visual component
pallette?
>
> We sort of have a hacky way of already doing this. It was designed for
people
> who are Java Beans providers and give a plugin, and a user just adds a
single
> container to a project's build path to enable it to work with the Java
Beans and
> have the palette show them. There is an article that describes this at
>
http://www-106.ibm.com/developerworks/websphere/library/tech articles/0302_winchester/winchester.html
> although this talks about WSAD APIs. The example code is migrated and
exists in
> the org.eclipse.ve.examples projects, so if you look at the article for
the idea
> and then the org.eclipse.ve.examples project you can get a feel for what's
going
> on.
>
> We do need a better way to do this however to support users who want to
just do
> ad-hoc customization in their workspace. Please add a bugzilla for this
> feature.
>
> > 2) Will the tool be able to handle custom non-visual components, beans
with
> > no visual presentation, but GUI related functionality? For example a
Data
> > Access Object for loading the data into the edit fields of on a panel.
>
> How would you like to see this done ? Right now the Visual Editor doesn't
> provide any palette classes over and above what's in the JFC and this has
no
> data-bound controls such as you get with Visual Basic. There is a thing
called
> JNDC that Sun is working on that is designed to fill this space. I think
some
> of the other IDE providers have their own palette of data aware controls -
is
> this what you're looking for ?
>
> > 3) Will the tool be able to handle non-standard layout managers. Where
most
> > of these Java visual painting tools break down is in the fact that they
must
> > use the standard Java layout managers, which tend to be very poor in
general
> > and a disaster for GUI builders. But there are some good ones out there,
> > like the TableLayout that aren't standard to Java.
>
> We have an internal API for this but this needs to be formalized and made
> public. Please add a bugzilla for this feature.
>
> Best regards,
>
> Joe Winchester
>
|
|
|
| Re: Questions on the VE feature set [message #569022 is a reply to message #3859] |
Tue, 25 November 2003 05:06 |
| Eclipse User |
|
|
|
Hi Joe,
Just for your information, there are a couple of mistakes in the
org.eclipse.ve.examples plugin (mainly in the custom palettes) :
1) In the examplecats.xmi file, there is an error in the iconName for the
Area entry ("org.eclipse.ve.examples.java" instead of
"org.eclipse.ve.examples" for the plugin name)
2) The wizzopalette.xmi file is missing
The corrected xmi files are attached.
Hope that helps (sorry if you already know about this "bug")
--
Cordialement / Best regards
=======================================================
S
|
|
|
| Re: Questions on the VE feature set [message #569630 is a reply to message #3859] |
Wed, 26 November 2003 10:45 |
| Eclipse User |
|
|
|
Hi Joe,
I have some additional questions about how the VE uses the information form
the BeanInfo class :
In VAJ it was possible to specify some custom properties for a
PropertyDescriptor (preferred and design-time for example). I wonder if a
similar feature exists in the VE editor ("preferred" events or properties
would be displayed in a popup menu, "run-time" properties wouldn't be
displayed in the properties view).
I have to admit the one is not supposed to design its BeanInfo class for a
specific target platform, but since there is some specific packaging to do
for the palette, why not customize the BeanInfos and PropertyDescriptors.
That leads to my second question : is it possible to write a Customizer or a
PropertyDescriptor that will use the JDT API ? And if yes, is it reasonable
to do so (actually the only usage I can think of would be to search the
workspace for all the classes that extend or implement a specific
class/interface).
"Joe Winchester" <winchest@uk.ibm.com> wrote in message
news:3FBE81D2.86EA4079@uk.ibm.com...
> Hi Dan,
>
> > 1) Will you be able to add your own beans to the visual component
pallette?
>
> We sort of have a hacky way of already doing this. It was designed for
people
> who are Java Beans providers and give a plugin, and a user just adds a
single
> container to a project's build path to enable it to work with the Java
Beans and
> have the palette show them. There is an article that describes this at
>
http://www-106.ibm.com/developerworks/websphere/library/tech articles/0302_wi
nchester/winchester.html
> although this talks about WSAD APIs. The example code is migrated and
exists in
> the org.eclipse.ve.examples projects, so if you look at the article for
the idea
> and then the org.eclipse.ve.examples project you can get a feel for what's
going
> on.
>
> We do need a better way to do this however to support users who want to
just do
> ad-hoc customization in their workspace. Please add a bugzilla for this
> feature.
>
> > 2) Will the tool be able to handle custom non-visual components, beans
with
> > no visual presentation, but GUI related functionality? For example a
Data
> > Access Object for loading the data into the edit fields of on a panel.
>
> How would you like to see this done ? Right now the Visual Editor doesn't
> provide any palette classes over and above what's in the JFC and this has
no
> data-bound controls such as you get with Visual Basic. There is a thing
called
> JNDC that Sun is working on that is designed to fill this space. I think
some
> of the other IDE providers have their own palette of data aware controls -
is
> this what you're looking for ?
>
> > 3) Will the tool be able to handle non-standard layout managers. Where
most
> > of these Java visual painting tools break down is in the fact that they
must
> > use the standard Java layout managers, which tend to be very poor in
general
> > and a disaster for GUI builders. But there are some good ones out there,
> > like the TableLayout that aren't standard to Java.
>
> We have an internal API for this but this needs to be formalized and made
> public. Please add a bugzilla for this feature.
>
> Best regards,
>
> Joe Winchester
>
|
|
|
| Re: Questions on the VE feature set [message #569957 is a reply to message #5601] |
Fri, 28 November 2003 15:24 |
| Eclipse User |
|
|
|
Sébastien Alonzo wrote:
> Hi Joe,
>
> I have some additional questions about how the VE uses the information form
> the BeanInfo class :
> In VAJ it was possible to specify some custom properties for a
> PropertyDescriptor (preferred and design-time for example). I wonder if a
> similar feature exists in the VE editor ("preferred" events or properties
> would be displayed in a popup menu, "run-time" properties wouldn't be
> displayed in the properties view).
Yes. look at
org.eclipse.ve.internal.jfc.beaninfo.AbstractButtonBeanInfo for
actionPerformed/PREFERRED... you can create beanInfo for your
components, but in this case it would be your responsibility to return
the additional beaninfo if you need to return inherent properties.
A plugin can overide current beaninfo from the xmi overides files,
though multiple overides to the same object are not supported at this time.
> I have to admit the one is not supposed to design its BeanInfo class for a
> specific target platform, but since there is some specific packaging to do
> for the palette, why not customize the BeanInfos and PropertyDescriptors.
>
VE provides a specific beaninfo for JFC... see the
org.eclipse.ve.internal.jfc.beaninfo package.
> That leads to my second question : is it possible to write a Customizer or a
> PropertyDescriptor that will use the JDT API ? And if yes, is it reasonable
> to do so (actually the only usage I can think of would be to search the
> workspace for all the classes that extend or implement a specific
> class/interface).
>
For a property editors, VE will let you provide a target VM based
property editor, e.g., color (see
org.eclipse.ve.internal.jfc.beaninfo.ColorEditor) or IDE based editor,
e.g., icon (see org.eclipse.ve.internal.jfc.core.ImageIconLabelProvider).
If you use an IDE based (one that runs inside the IDE) property editor,
you whould be able to utilize JDT.
>
> "Joe Winchester" <winchest@uk.ibm.com> wrote in message
> news:3FBE81D2.86EA4079@uk.ibm.com...
>
>>Hi Dan,
>>
>>
>>>1) Will you be able to add your own beans to the visual component
>
> pallette?
>
>>We sort of have a hacky way of already doing this. It was designed for
>
> people
>
>>who are Java Beans providers and give a plugin, and a user just adds a
>
> single
>
>>container to a project's build path to enable it to work with the Java
>
> Beans and
>
>>have the palette show them. There is an article that describes this at
>>
>
> http://www-106.ibm.com/developerworks/websphere/library/tech articles/0302_wi
> nchester/winchester.html
>
>>although this talks about WSAD APIs. The example code is migrated and
>
> exists in
>
>>the org.eclipse.ve.examples projects, so if you look at the article for
>
> the idea
>
>>and then the org.eclipse.ve.examples project you can get a feel for what's
>
> going
>
>>on.
>>
>>We do need a better way to do this however to support users who want to
>
> just do
>
>>ad-hoc customization in their workspace. Please add a bugzilla for this
>>feature.
>>
>>
>>>2) Will the tool be able to handle custom non-visual components, beans
>
> with
>
>>>no visual presentation, but GUI related functionality? For example a
>
> Data
>
>>>Access Object for loading the data into the edit fields of on a panel.
>>
>>How would you like to see this done ? Right now the Visual Editor doesn't
>>provide any palette classes over and above what's in the JFC and this has
>
> no
>
>>data-bound controls such as you get with Visual Basic. There is a thing
>
> called
>
>>JNDC that Sun is working on that is designed to fill this space. I think
>
> some
>
>>of the other IDE providers have their own palette of data aware controls -
>
> is
>
>>this what you're looking for ?
>>
>>
>>>3) Will the tool be able to handle non-standard layout managers. Where
>
> most
>
>>>of these Java visual painting tools break down is in the fact that they
>
> must
>
>>>use the standard Java layout managers, which tend to be very poor in
>
> general
>
>>>and a disaster for GUI builders. But there are some good ones out there,
>>>like the TableLayout that aren't standard to Java.
>>
>>We have an internal API for this but this needs to be formalized and made
>>public. Please add a bugzilla for this feature.
>>
>>Best regards,
>>
>>Joe Winchester
>>
>
>
>
|
|
|
| Re: Questions on the VE feature set [message #570772 is a reply to message #6347] |
Mon, 01 December 2003 11:54 |
| Eclipse User |
|
|
|
"Gili Mendel" <mendelgili@netscape.net> wrote in message
news:bq8aq1$qm0$1@eclipse.org...
> > I have some additional questions about how the VE uses the information
form
> > the BeanInfo class :
> > In VAJ it was possible to specify some custom properties for a
> > PropertyDescriptor (preferred and design-time for example). I wonder if
a
> > similar feature exists in the VE editor ("preferred" events or
properties
> > would be displayed in a popup menu, "run-time" properties wouldn't be
> > displayed in the properties view).
>
> Yes. look at
> org.eclipse.ve.internal.jfc.beaninfo.AbstractButtonBeanInfo for
> actionPerformed/PREFERRED... you can create beanInfo for your
> components, but in this case it would be your responsibility to return
> the additional beaninfo if you need to return inherent properties.
Thanks for your answer, Gili, it works pretty well.
I still don't understand if the VE is using the "getIcon(int iconkind)"
method of the BeanInfo class, but it's not such a big deal. The only side
effect I see is that widgets don't look the same in the Palette and in the
'Java Beans' view.
>
> A plugin can overide current beaninfo from the xmi overides files,
> though multiple overides to the same object are not supported at this
time.
>
Is there some documentation about these xmi overrides files ?
That leads to another question : Will there be a change in API for all these
xmi files (for the palette, override, ...) in the release for Eclipse 3.0 ?
I'm asking this because the palette xmi file is a bit different between WSAD
VEJ and Eclipse VE (ok it's probably just the namespaces, but still I cannot
write a plugin which could work for both).
|
|
|
| Re: Questions on the VE feature set [message #570974 is a reply to message #6655] |
Mon, 01 December 2003 14:58 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.NO.SPAM.us.ibm.com
getIcon() is the one thing we aren't using. We have a feature for that
for the next release. The biggest problem is that getIcon() returns an
AWT icon/image, and we need it to be an SWT image. We just ran out of
time to get this working correctly.
One big problem with using the getIcon on the palette is that we don't
want to force introspection for every bean that shows up on a palette
just to get the icon to show. So the palette will probably always have a
separate pointer to the icon to use in it. If we required introspection,
the editor would never come up :-)
As for the format of the override files, there is a small chance they
will change again when we step up to EMF2.0. The override code is
currently supplied internally by EMF, but EMF is picking it up for their
next opensource release. However, we are trying to make sure it doesn't
change much, if any. I'm in discussion with them on this right now.
We don't have any documentation on them yet. This release was simply to
get everything out there to use. As we work on the next and further
releases, there will be specific API and documentation available for how
to extend the editor. In the meantime there will also be articles
created for this kind of stuff, like we have one for WSAD for palette
extension, which is being updated for VE palette extension.
--
Thanks, Rich Kulp
|
|
|
Goto Forum:
Current Time: Tue May 13 19:03:06 EDT 2025
Powered by FUDForum. Page generated in 0.05546 seconds |
Home