Home » Eclipse Projects » Technology Project and PMC » [PDE]extend the plugin.xml dtd
| [PDE]extend the plugin.xml dtd [message #20104] |
Sun, 01 September 2002 08:22  |
 Xavier Méhaut
Messages: 49
Registered: July 2009 |
Member |
|
|
Hello,
I don't know if it is a good proposal , but I would propose an extension
to PDE. Up to now, we can build all infrastructure of an application in
Eclipse by writing only xml code in the plugin.xml file. Nevertheless we
can "only"(it is already good ;-) ) focus on views, perspectives, editors,
actions, menus, and so on...
I would propose to extend the kind of objects handled. Why not be able to
add a button, a list, a layout, a composite, and so on.., in a view. By
this mean we would have a quite simple GUI builder and most important a
homogeneous declarative way of programming our plugins in eclipse... In a
certain manner, it is quite like XUL with the eclipse xml syntax, isn't it?
I'm waiting for the comments about this proposal.
Xavier
|
|
|
| Re: [PDE]extend the plugin.xml dtd [message #20655 is a reply to message #20104] |
Mon, 02 September 2002 10:13  |
Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
"xavier" <xmehaut@apri-group.com> wrote in message
news:aksinr$3o6$1@rogue.oti.com...
> Hello,
> I don't know if it is a good proposal , but I would propose an extension
> to PDE. Up to now, we can build all infrastructure of an application in
> Eclipse by writing only xml code in the plugin.xml file. Nevertheless we
> can "only"(it is already good ;-) ) focus on views, perspectives, editors,
> actions, menus, and so on...
> I would propose to extend the kind of objects handled. Why not be able to
> add a button, a list, a layout, a composite, and so on.., in a view. By
> this mean we would have a quite simple GUI builder and most important a
> homogeneous declarative way of programming our plugins in eclipse... In a
> certain manner, it is quite like XUL with the eclipse xml syntax, isn't
it?
> I'm waiting for the comments about this proposal.
> Xavier
I'm not so keen on this as a plugin manifest extension, as I'm afraid this
kind of stuff would swamp the poor, old manifest. But the recent discussion
of XUL and friends did suggest to me (as I guess it did to you) that there
should be an Eclipse-specific (or at least SWT/JFace-specific) way to
declaratively specify GUI. This could be the lingua franca for any number of
GUI builders, and should be independent of them all.
Bob
|
|
|
| Re: [PDE]extend the plugin.xml dtd [message #20667 is a reply to message #20655] |
Mon, 02 September 2002 10:16 |
Xavier Méhaut
Messages: 49
Registered: July 2009 |
Member |
|
|
I agree with you Bob ; I think it would be the right way to proceed, and
even to replace the plugin manifest extension by using it...
I would like to hear the position of OTI on such thing too...
regards
Xavier
Bob Foster wrote:
> "xavier" <xmehaut@apri-group.com> wrote in message
> news:aksinr$3o6$1@rogue.oti.com...
> > Hello,
> > I don't know if it is a good proposal , but I would propose an extension
> > to PDE. Up to now, we can build all infrastructure of an application in
> > Eclipse by writing only xml code in the plugin.xml file. Nevertheless we
> > can "only"(it is already good ;-) ) focus on views, perspectives, editors,
> > actions, menus, and so on...
> > I would propose to extend the kind of objects handled. Why not be able to
> > add a button, a list, a layout, a composite, and so on.., in a view. By
> > this mean we would have a quite simple GUI builder and most important a
> > homogeneous declarative way of programming our plugins in eclipse... In a
> > certain manner, it is quite like XUL with the eclipse xml syntax, isn't
> it?
> > I'm waiting for the comments about this proposal.
> > Xavier
> I'm not so keen on this as a plugin manifest extension, as I'm afraid this
> kind of stuff would swamp the poor, old manifest. But the recent discussion
> of XUL and friends did suggest to me (as I guess it did to you) that there
> should be an Eclipse-specific (or at least SWT/JFace-specific) way to
> declaratively specify GUI. This could be the lingua franca for any number of
> GUI builders, and should be independent of them all.
> Bob
|
|
|
| Re: [PDE]extend the plugin.xml dtd [message #20702 is a reply to message #20667] |
Tue, 03 September 2002 03:00 |
| Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
Here are a few more ideas I've been nursing.
The basic idea: A project to deliver an XML syntax for declarative
descriptions of SWT/JFace GUI, with accompanying supporting Java classes to
instantiate a GUI from its XML description. This syntax and supporting
classes could be used to describe extensible user interfaces in Eclipse
plugins and as a common language for Eclipse GUI builders.
The syntax should have intrinsic support for existing SWT controls, JFace
dialogs and wizards, and other JFace components as appropriate. It should
support event listeners specified as user listener classes or methods in
user classes (implemented by proxies). It should be user-extensible to
support user-written controls, and should provide for plugin extension, a la
the plugin manifest extension points. For example, a plugin might add a
control to a dialog provided by another plugin, or a page to an existing
wizard.
Following XUL and unlike bean persistence, the syntax should be easy for
humans to read and write. Unlike XUL, the syntax should not be GUI framework
independent; it should be tailored to the Eclipse GUI framework. This is no
less flexible, as XUL and other more abstract descriptions can be translated
(e.g., by XSLT) into this format, and helps ensure that no features of the
Eclipse GUI are lost. Wherever possible, the syntax should be derivable by a
simple and predictable transformation from the corresponding API, e.g.,
control and property names should be mapped into the same names but for
initial letter capitalization. It should be possible to describe controls at
any level of granularity, e.g., a document might describe an entire wizard
or a single button.
The supporting classes should, at a minimum, perform dynamic and static
translation from XML to Java. That is, a class should be able to read one or
more XML documents and construct a working GUI at runtime. Another should be
able to read the same set of documents and generate Java code which when
compiled provides the same GUI. Optionally, perhaps as separate
sub-projects, a class might generate Java class files directly from XML
documents (compilation), while another might examine existing classes and
produce XML documents (two-way generation).
Bob
"xavier" <xmehaut@apri-group.com> wrote in message
news:akvdqd$pnt$1@rogue.oti.com...
> I agree with you Bob ; I think it would be the right way to proceed, and
> even to replace the plugin manifest extension by using it...
> I would like to hear the position of OTI on such thing too...
> regards
> Xavier
>
> Bob Foster wrote:
>
> > "xavier" <xmehaut@apri-group.com> wrote in message
> > news:aksinr$3o6$1@rogue.oti.com...
> > > Hello,
> > > I don't know if it is a good proposal , but I would propose an
extension
> > > to PDE. Up to now, we can build all infrastructure of an application
in
> > > Eclipse by writing only xml code in the plugin.xml file. Nevertheless
we
> > > can "only"(it is already good ;-) ) focus on views, perspectives,
editors,
> > > actions, menus, and so on...
> > > I would propose to extend the kind of objects handled. Why not be able
to
> > > add a button, a list, a layout, a composite, and so on.., in a view.
By
> > > this mean we would have a quite simple GUI builder and most important
a
> > > homogeneous declarative way of programming our plugins in eclipse...
In a
> > > certain manner, it is quite like XUL with the eclipse xml syntax,
isn't
> > it?
> > > I'm waiting for the comments about this proposal.
> > > Xavier
>
> > I'm not so keen on this as a plugin manifest extension, as I'm afraid
this
> > kind of stuff would swamp the poor, old manifest. But the recent
discussion
> > of XUL and friends did suggest to me (as I guess it did to you) that
there
> > should be an Eclipse-specific (or at least SWT/JFace-specific) way to
> > declaratively specify GUI. This could be the lingua franca for any
number of
> > GUI builders, and should be independent of them all.
>
> > Bob
>
>
>
>
>
|
|
|
| Re: [PDE]extend the plugin.xml dtd [message #20715 is a reply to message #20702] |
Tue, 03 September 2002 07:11 |
Xavier Méhaut
Messages: 49
Registered: July 2009 |
Member |
|
|
Hello Bob,
It was roughly what I had in mind ; nevertheless we can add two additional
requirements :
1) it should be integrated within the current plugin description
architecture in order to be able to be homogeneous with it, or at least
enabling to do the same thing(creation of perspectives, actions, views,
editors, ...)...
2) a GUi builder should be developped right after completing the previous
tasks
regards
Xavier
ps : when will we begin ;-) ?
Bob Foster wrote:
> Here are a few more ideas I\'ve been nursing.
> The basic idea: A project to deliver an XML syntax for declarative
> descriptions of SWT/JFace GUI, with accompanying supporting Java classes to
> instantiate a GUI from its XML description. This syntax and supporting
> classes could be used to describe extensible user interfaces in Eclipse
> plugins and as a common language for Eclipse GUI builders.
> The syntax should have intrinsic support for existing SWT controls, JFace
> dialogs and wizards, and other JFace components as appropriate. It should
> support event listeners specified as user listener classes or methods in
> user classes (implemented by proxies). It should be user-extensible to
> support user-written controls, and should provide for plugin extension, a la
> the plugin manifest extension points. For example, a plugin might add a
> control to a dialog provided by another plugin, or a page to an existing
> wizard.
> Following XUL and unlike bean persistence, the syntax should be easy for
> humans to read and write. Unlike XUL, the syntax should not be GUI framework
> independent; it should be tailored to the Eclipse GUI framework. This is no
> less flexible, as XUL and other more abstract descriptions can be translated
> (e.g., by XSLT) into this format, and helps ensure that no features of the
> Eclipse GUI are lost. Wherever possible, the syntax should be derivable by a
> simple and predictable transformation from the corresponding API, e.g.,
> control and property names should be mapped into the same names but for
> initial letter capitalization. It should be possible to describe controls at
> any level of granularity, e.g., a document might describe an entire wizard
> or a single button.
> The supporting classes should, at a minimum, perform dynamic and static
> translation from XML to Java. That is, a class should be able to read one or
> more XML documents and construct a working GUI at runtime. Another should be
> able to read the same set of documents and generate Java code which when
> compiled provides the same GUI. Optionally, perhaps as separate
> sub-projects, a class might generate Java class files directly from XML
> documents (compilation), while another might examine existing classes and
> produce XML documents (two-way generation).
> Bob
> \"xavier\" <xmehaut@apri-group.com> wrote in message
> news:akvdqd$pnt$1@rogue.oti.com...
> > I agree with you Bob ; I think it would be the right way to proceed, and
> > even to replace the plugin manifest extension by using it...
> > I would like to hear the position of OTI on such thing too...
> > regards
> > Xavier
> >
> > Bob Foster wrote:
> >
> > > \"xavier\" <xmehaut@apri-group.com> wrote in message
> > > news:aksinr$3o6$1@rogue.oti.com...
> > > > Hello,
> > > > I don\'t know if it is a good proposal , but I would propose an
> extension
> > > > to PDE. Up to now, we can build all infrastructure of an application
> in
> > > > Eclipse by writing only xml code in the plugin.xml file. Nevertheless
> we
> > > > can \"only\"(it is already good ;-) ) focus on views, perspectives,
> editors,
> > > > actions, menus, and so on...
> > > > I would propose to extend the kind of objects handled. Why not be able
> to
> > > > add a button, a list, a layout, a composite, and so on.., in a view.
> By
> > > > this mean we would have a quite simple GUI builder and most important
> a
> > > > homogeneous declarative way of programming our plugins in eclipse...
> In a
> > > > certain manner, it is quite like XUL with the eclipse xml syntax,
> isn\'t
> > > it?
> > > > I\'m waiting for the comments about this proposal.
> > > > Xavier
> >
> > > I\'m not so keen on this as a plugin manifest extension, as I\'m afraid
> this
> > > kind of stuff would swamp the poor, old manifest. But the recent
> discussion
> > > of XUL and friends did suggest to me (as I guess it did to you) that
> there
> > > should be an Eclipse-specific (or at least SWT/JFace-specific) way to
> > > declaratively specify GUI. This could be the lingua franca for any
> number of
> > > GUI builders, and should be independent of them all.
> >
> > > Bob
> >
> >
> >
> >
> >
|
|
|
| Re: [PDE]extend the plugin.xml dtd [message #20772 is a reply to message #20715] |
Wed, 04 September 2002 05:52 |
| Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
"xavier" <xmehaut@apri-group.com> wrote in message
news:al1naq$n0b$1@rogue.oti.com...
> Hello Bob,
> It was roughly what I had in mind ; nevertheless we can add two additional
> requirements :
> 1) it should be integrated within the current plugin description
> architecture in order to be able to be homogeneous with it, or at least
> enabling to do the same thing(creation of perspectives, actions, views,
> editors, ...)...
> 2) a GUi builder should be developped right after completing the previous
> tasks
> regards
> Xavier
> ps : when will we begin ;-) ?
If I had time for new projects I'd be working on it instead of talking about
it. ;-}
Bob
>
>
> Bob Foster wrote:
>
> > Here are a few more ideas I\'ve been nursing.
>
> > The basic idea: A project to deliver an XML syntax for declarative
> > descriptions of SWT/JFace GUI, with accompanying supporting Java classes
to
> > instantiate a GUI from its XML description. This syntax and supporting
> > classes could be used to describe extensible user interfaces in Eclipse
> > plugins and as a common language for Eclipse GUI builders.
>
> > The syntax should have intrinsic support for existing SWT controls,
JFace
> > dialogs and wizards, and other JFace components as appropriate. It
should
> > support event listeners specified as user listener classes or methods in
> > user classes (implemented by proxies). It should be user-extensible to
> > support user-written controls, and should provide for plugin extension,
a la
> > the plugin manifest extension points. For example, a plugin might add a
> > control to a dialog provided by another plugin, or a page to an existing
> > wizard.
>
> > Following XUL and unlike bean persistence, the syntax should be easy for
> > humans to read and write. Unlike XUL, the syntax should not be GUI
framework
> > independent; it should be tailored to the Eclipse GUI framework. This is
no
> > less flexible, as XUL and other more abstract descriptions can be
translated
> > (e.g., by XSLT) into this format, and helps ensure that no features of
the
> > Eclipse GUI are lost. Wherever possible, the syntax should be derivable
by a
> > simple and predictable transformation from the corresponding API, e.g.,
> > control and property names should be mapped into the same names but for
> > initial letter capitalization. It should be possible to describe
controls at
> > any level of granularity, e.g., a document might describe an entire
wizard
> > or a single button.
>
> > The supporting classes should, at a minimum, perform dynamic and static
> > translation from XML to Java. That is, a class should be able to read
one or
> > more XML documents and construct a working GUI at runtime. Another
should be
> > able to read the same set of documents and generate Java code which when
> > compiled provides the same GUI. Optionally, perhaps as separate
> > sub-projects, a class might generate Java class files directly from XML
> > documents (compilation), while another might examine existing classes
and
> > produce XML documents (two-way generation).
>
> > Bob
>
> > \"xavier\" <xmehaut@apri-group.com> wrote in message
> > news:akvdqd$pnt$1@rogue.oti.com...
> > > I agree with you Bob ; I think it would be the right way to proceed,
and
> > > even to replace the plugin manifest extension by using it...
> > > I would like to hear the position of OTI on such thing too...
> > > regards
> > > Xavier
> > >
> > > Bob Foster wrote:
> > >
> > > > \"xavier\" <xmehaut@apri-group.com> wrote in message
> > > > news:aksinr$3o6$1@rogue.oti.com...
> > > > > Hello,
> > > > > I don\'t know if it is a good proposal , but I would propose an
> > extension
> > > > > to PDE. Up to now, we can build all infrastructure of an
application
> > in
> > > > > Eclipse by writing only xml code in the plugin.xml file.
Nevertheless
> > we
> > > > > can \"only\"(it is already good ;-) ) focus on views,
perspectives,
> > editors,
> > > > > actions, menus, and so on...
> > > > > I would propose to extend the kind of objects handled. Why not be
able
> > to
> > > > > add a button, a list, a layout, a composite, and so on.., in a
view.
> > By
> > > > > this mean we would have a quite simple GUI builder and most
important
> > a
> > > > > homogeneous declarative way of programming our plugins in
eclipse...
> > In a
> > > > > certain manner, it is quite like XUL with the eclipse xml syntax,
> > isn\'t
> > > > it?
> > > > > I\'m waiting for the comments about this proposal.
> > > > > Xavier
> > >
> > > > I\'m not so keen on this as a plugin manifest extension, as I\'m
afraid
> > this
> > > > kind of stuff would swamp the poor, old manifest. But the recent
> > discussion
> > > > of XUL and friends did suggest to me (as I guess it did to you) that
> > there
> > > > should be an Eclipse-specific (or at least SWT/JFace-specific) way
to
> > > > declaratively specify GUI. This could be the lingua franca for any
> > number of
> > > > GUI builders, and should be independent of them all.
> > >
> > > > Bob
> > >
> > >
> > >
> > >
> > >
>
>
>
>
>
|
|
|
| Re: [PDE]extend the plugin.xml dtd [message #20785 is a reply to message #20772] |
Wed, 04 September 2002 06:30 |
Xavier Méhaut
Messages: 49
Registered: July 2009 |
Member |
|
|
When you're ready, I want well participate ;-)
> "xavier" <xmehaut@apri-group.com> wrote in message
> news:al1naq$n0b$1@rogue.oti.com...
> > Hello Bob,
> > It was roughly what I had in mind ; nevertheless we can add two additional
> > requirements :
> > 1) it should be integrated within the current plugin description
> > architecture in order to be able to be homogeneous with it, or at least
> > enabling to do the same thing(creation of perspectives, actions, views,
> > editors, ...)...
> > 2) a GUi builder should be developped right after completing the previous
> > tasks
> > regards
> > Xavier
> > ps : when will we begin ;-) ?
> If I had time for new projects I'd be working on it instead of talking about
> it. ;-}
> Bob
> >
> >
> > Bob Foster wrote:
> >
> > > Here are a few more ideas I\'ve been nursing.
> >
> > > The basic idea: A project to deliver an XML syntax for declarative
> > > descriptions of SWT/JFace GUI, with accompanying supporting Java classes
> to
> > > instantiate a GUI from its XML description. This syntax and supporting
> > > classes could be used to describe extensible user interfaces in Eclipse
> > > plugins and as a common language for Eclipse GUI builders.
> >
> > > The syntax should have intrinsic support for existing SWT controls,
> JFace
> > > dialogs and wizards, and other JFace components as appropriate. It
> should
> > > support event listeners specified as user listener classes or methods in
> > > user classes (implemented by proxies). It should be user-extensible to
> > > support user-written controls, and should provide for plugin extension,
> a la
> > > the plugin manifest extension points. For example, a plugin might add a
> > > control to a dialog provided by another plugin, or a page to an existing
> > > wizard.
> >
> > > Following XUL and unlike bean persistence, the syntax should be easy for
> > > humans to read and write. Unlike XUL, the syntax should not be GUI
> framework
> > > independent; it should be tailored to the Eclipse GUI framework. This is
> no
> > > less flexible, as XUL and other more abstract descriptions can be
> translated
> > > (e.g., by XSLT) into this format, and helps ensure that no features of
> the
> > > Eclipse GUI are lost. Wherever possible, the syntax should be derivable
> by a
> > > simple and predictable transformation from the corresponding API, e.g.,
> > > control and property names should be mapped into the same names but for
> > > initial letter capitalization. It should be possible to describe
> controls at
> > > any level of granularity, e.g., a document might describe an entire
> wizard
> > > or a single button.
> >
> > > The supporting classes should, at a minimum, perform dynamic and static
> > > translation from XML to Java. That is, a class should be able to read
> one or
> > > more XML documents and construct a working GUI at runtime. Another
> should be
> > > able to read the same set of documents and generate Java code which when
> > > compiled provides the same GUI. Optionally, perhaps as separate
> > > sub-projects, a class might generate Java class files directly from XML
> > > documents (compilation), while another might examine existing classes
> and
> > > produce XML documents (two-way generation).
> >
> > > Bob
> >
> > > \"xavier\" <xmehaut@apri-group.com> wrote in message
> > > news:akvdqd$pnt$1@rogue.oti.com...
> > > > I agree with you Bob ; I think it would be the right way to proceed,
> and
> > > > even to replace the plugin manifest extension by using it...
> > > > I would like to hear the position of OTI on such thing too...
> > > > regards
> > > > Xavier
> > > >
> > > > Bob Foster wrote:
> > > >
> > > > > \"xavier\" <xmehaut@apri-group.com> wrote in message
> > > > > news:aksinr$3o6$1@rogue.oti.com...
> > > > > > Hello,
> > > > > > I don\'t know if it is a good proposal , but I would propose an
> > > extension
> > > > > > to PDE. Up to now, we can build all infrastructure of an
> application
> > > in
> > > > > > Eclipse by writing only xml code in the plugin.xml file.
> Nevertheless
> > > we
> > > > > > can \"only\"(it is already good ;-) ) focus on views,
> perspectives,
> > > editors,
> > > > > > actions, menus, and so on...
> > > > > > I would propose to extend the kind of objects handled. Why not be
> able
> > > to
> > > > > > add a button, a list, a layout, a composite, and so on.., in a
> view.
> > > By
> > > > > > this mean we would have a quite simple GUI builder and most
> important
> > > a
> > > > > > homogeneous declarative way of programming our plugins in
> eclipse...
> > > In a
> > > > > > certain manner, it is quite like XUL with the eclipse xml syntax,
> > > isn\'t
> > > > > it?
> > > > > > I\'m waiting for the comments about this proposal.
> > > > > > Xavier
> > > >
> > > > > I\'m not so keen on this as a plugin manifest extension, as I\'m
> afraid
> > > this
> > > > > kind of stuff would swamp the poor, old manifest. But the recent
> > > discussion
> > > > > of XUL and friends did suggest to me (as I guess it did to you) that
> > > there
> > > > > should be an Eclipse-specific (or at least SWT/JFace-specific) way
> to
> > > > > declaratively specify GUI. This could be the lingua franca for any
> > > number of
> > > > > GUI builders, and should be independent of them all.
> > > >
> > > > > Bob
> > > >
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
> >
> >
|
|
|
| Re: [PDE]extend the plugin.xml dtd [message #574654 is a reply to message #20104] |
Mon, 02 September 2002 10:13 |
| Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
"xavier" <xmehaut@apri-group.com> wrote in message
news:aksinr$3o6$1@rogue.oti.com...
> Hello,
> I don't know if it is a good proposal , but I would propose an extension
> to PDE. Up to now, we can build all infrastructure of an application in
> Eclipse by writing only xml code in the plugin.xml file. Nevertheless we
> can "only"(it is already good ;-) ) focus on views, perspectives, editors,
> actions, menus, and so on...
> I would propose to extend the kind of objects handled. Why not be able to
> add a button, a list, a layout, a composite, and so on.., in a view. By
> this mean we would have a quite simple GUI builder and most important a
> homogeneous declarative way of programming our plugins in eclipse... In a
> certain manner, it is quite like XUL with the eclipse xml syntax, isn't
it?
> I'm waiting for the comments about this proposal.
> Xavier
I'm not so keen on this as a plugin manifest extension, as I'm afraid this
kind of stuff would swamp the poor, old manifest. But the recent discussion
of XUL and friends did suggest to me (as I guess it did to you) that there
should be an Eclipse-specific (or at least SWT/JFace-specific) way to
declaratively specify GUI. This could be the lingua franca for any number of
GUI builders, and should be independent of them all.
Bob
|
|
|
| Re: [PDE]extend the plugin.xml dtd [message #574671 is a reply to message #20655] |
Mon, 02 September 2002 10:16 |
Xavier Méhaut
Messages: 49
Registered: July 2009 |
Member |
|
|
I agree with you Bob ; I think it would be the right way to proceed, and
even to replace the plugin manifest extension by using it...
I would like to hear the position of OTI on such thing too...
regards
Xavier
Bob Foster wrote:
> "xavier" <xmehaut@apri-group.com> wrote in message
> news:aksinr$3o6$1@rogue.oti.com...
> > Hello,
> > I don't know if it is a good proposal , but I would propose an extension
> > to PDE. Up to now, we can build all infrastructure of an application in
> > Eclipse by writing only xml code in the plugin.xml file. Nevertheless we
> > can "only"(it is already good ;-) ) focus on views, perspectives, editors,
> > actions, menus, and so on...
> > I would propose to extend the kind of objects handled. Why not be able to
> > add a button, a list, a layout, a composite, and so on.., in a view. By
> > this mean we would have a quite simple GUI builder and most important a
> > homogeneous declarative way of programming our plugins in eclipse... In a
> > certain manner, it is quite like XUL with the eclipse xml syntax, isn't
> it?
> > I'm waiting for the comments about this proposal.
> > Xavier
> I'm not so keen on this as a plugin manifest extension, as I'm afraid this
> kind of stuff would swamp the poor, old manifest. But the recent discussion
> of XUL and friends did suggest to me (as I guess it did to you) that there
> should be an Eclipse-specific (or at least SWT/JFace-specific) way to
> declaratively specify GUI. This could be the lingua franca for any number of
> GUI builders, and should be independent of them all.
> Bob
|
|
|
| Re: [PDE]extend the plugin.xml dtd [message #574783 is a reply to message #20667] |
Tue, 03 September 2002 03:00 |
| Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
Here are a few more ideas I've been nursing.
The basic idea: A project to deliver an XML syntax for declarative
descriptions of SWT/JFace GUI, with accompanying supporting Java classes to
instantiate a GUI from its XML description. This syntax and supporting
classes could be used to describe extensible user interfaces in Eclipse
plugins and as a common language for Eclipse GUI builders.
The syntax should have intrinsic support for existing SWT controls, JFace
dialogs and wizards, and other JFace components as appropriate. It should
support event listeners specified as user listener classes or methods in
user classes (implemented by proxies). It should be user-extensible to
support user-written controls, and should provide for plugin extension, a la
the plugin manifest extension points. For example, a plugin might add a
control to a dialog provided by another plugin, or a page to an existing
wizard.
Following XUL and unlike bean persistence, the syntax should be easy for
humans to read and write. Unlike XUL, the syntax should not be GUI framework
independent; it should be tailored to the Eclipse GUI framework. This is no
less flexible, as XUL and other more abstract descriptions can be translated
(e.g., by XSLT) into this format, and helps ensure that no features of the
Eclipse GUI are lost. Wherever possible, the syntax should be derivable by a
simple and predictable transformation from the corresponding API, e.g.,
control and property names should be mapped into the same names but for
initial letter capitalization. It should be possible to describe controls at
any level of granularity, e.g., a document might describe an entire wizard
or a single button.
The supporting classes should, at a minimum, perform dynamic and static
translation from XML to Java. That is, a class should be able to read one or
more XML documents and construct a working GUI at runtime. Another should be
able to read the same set of documents and generate Java code which when
compiled provides the same GUI. Optionally, perhaps as separate
sub-projects, a class might generate Java class files directly from XML
documents (compilation), while another might examine existing classes and
produce XML documents (two-way generation).
Bob
"xavier" <xmehaut@apri-group.com> wrote in message
news:akvdqd$pnt$1@rogue.oti.com...
> I agree with you Bob ; I think it would be the right way to proceed, and
> even to replace the plugin manifest extension by using it...
> I would like to hear the position of OTI on such thing too...
> regards
> Xavier
>
> Bob Foster wrote:
>
> > "xavier" <xmehaut@apri-group.com> wrote in message
> > news:aksinr$3o6$1@rogue.oti.com...
> > > Hello,
> > > I don't know if it is a good proposal , but I would propose an
extension
> > > to PDE. Up to now, we can build all infrastructure of an application
in
> > > Eclipse by writing only xml code in the plugin.xml file. Nevertheless
we
> > > can "only"(it is already good ;-) ) focus on views, perspectives,
editors,
> > > actions, menus, and so on...
> > > I would propose to extend the kind of objects handled. Why not be able
to
> > > add a button, a list, a layout, a composite, and so on.., in a view.
By
> > > this mean we would have a quite simple GUI builder and most important
a
> > > homogeneous declarative way of programming our plugins in eclipse...
In a
> > > certain manner, it is quite like XUL with the eclipse xml syntax,
isn't
> > it?
> > > I'm waiting for the comments about this proposal.
> > > Xavier
>
> > I'm not so keen on this as a plugin manifest extension, as I'm afraid
this
> > kind of stuff would swamp the poor, old manifest. But the recent
discussion
> > of XUL and friends did suggest to me (as I guess it did to you) that
there
> > should be an Eclipse-specific (or at least SWT/JFace-specific) way to
> > declaratively specify GUI. This could be the lingua franca for any
number of
> > GUI builders, and should be independent of them all.
>
> > Bob
>
>
>
>
>
|
|
|
| Re: [PDE]extend the plugin.xml dtd [message #574799 is a reply to message #20702] |
Tue, 03 September 2002 07:11 |
Xavier Méhaut
Messages: 49
Registered: July 2009 |
Member |
|
|
Hello Bob,
It was roughly what I had in mind ; nevertheless we can add two additional
requirements :
1) it should be integrated within the current plugin description
architecture in order to be able to be homogeneous with it, or at least
enabling to do the same thing(creation of perspectives, actions, views,
editors, ...)...
2) a GUi builder should be developped right after completing the previous
tasks
regards
Xavier
ps : when will we begin ;-) ?
Bob Foster wrote:
> Here are a few more ideas I\'ve been nursing.
> The basic idea: A project to deliver an XML syntax for declarative
> descriptions of SWT/JFace GUI, with accompanying supporting Java classes to
> instantiate a GUI from its XML description. This syntax and supporting
> classes could be used to describe extensible user interfaces in Eclipse
> plugins and as a common language for Eclipse GUI builders.
> The syntax should have intrinsic support for existing SWT controls, JFace
> dialogs and wizards, and other JFace components as appropriate. It should
> support event listeners specified as user listener classes or methods in
> user classes (implemented by proxies). It should be user-extensible to
> support user-written controls, and should provide for plugin extension, a la
> the plugin manifest extension points. For example, a plugin might add a
> control to a dialog provided by another plugin, or a page to an existing
> wizard.
> Following XUL and unlike bean persistence, the syntax should be easy for
> humans to read and write. Unlike XUL, the syntax should not be GUI framework
> independent; it should be tailored to the Eclipse GUI framework. This is no
> less flexible, as XUL and other more abstract descriptions can be translated
> (e.g., by XSLT) into this format, and helps ensure that no features of the
> Eclipse GUI are lost. Wherever possible, the syntax should be derivable by a
> simple and predictable transformation from the corresponding API, e.g.,
> control and property names should be mapped into the same names but for
> initial letter capitalization. It should be possible to describe controls at
> any level of granularity, e.g., a document might describe an entire wizard
> or a single button.
> The supporting classes should, at a minimum, perform dynamic and static
> translation from XML to Java. That is, a class should be able to read one or
> more XML documents and construct a working GUI at runtime. Another should be
> able to read the same set of documents and generate Java code which when
> compiled provides the same GUI. Optionally, perhaps as separate
> sub-projects, a class might generate Java class files directly from XML
> documents (compilation), while another might examine existing classes and
> produce XML documents (two-way generation).
> Bob
> \"xavier\" <xmehaut@apri-group.com> wrote in message
> news:akvdqd$pnt$1@rogue.oti.com...
> > I agree with you Bob ; I think it would be the right way to proceed, and
> > even to replace the plugin manifest extension by using it...
> > I would like to hear the position of OTI on such thing too...
> > regards
> > Xavier
> >
> > Bob Foster wrote:
> >
> > > \"xavier\" <xmehaut@apri-group.com> wrote in message
> > > news:aksinr$3o6$1@rogue.oti.com...
> > > > Hello,
> > > > I don\'t know if it is a good proposal , but I would propose an
> extension
> > > > to PDE. Up to now, we can build all infrastructure of an application
> in
> > > > Eclipse by writing only xml code in the plugin.xml file. Nevertheless
> we
> > > > can \"only\"(it is already good ;-) ) focus on views, perspectives,
> editors,
> > > > actions, menus, and so on...
> > > > I would propose to extend the kind of objects handled. Why not be able
> to
> > > > add a button, a list, a layout, a composite, and so on.., in a view.
> By
> > > > this mean we would have a quite simple GUI builder and most important
> a
> > > > homogeneous declarative way of programming our plugins in eclipse...
> In a
> > > > certain manner, it is quite like XUL with the eclipse xml syntax,
> isn\'t
> > > it?
> > > > I\'m waiting for the comments about this proposal.
> > > > Xavier
> >
> > > I\'m not so keen on this as a plugin manifest extension, as I\'m afraid
> this
> > > kind of stuff would swamp the poor, old manifest. But the recent
> discussion
> > > of XUL and friends did suggest to me (as I guess it did to you) that
> there
> > > should be an Eclipse-specific (or at least SWT/JFace-specific) way to
> > > declaratively specify GUI. This could be the lingua franca for any
> number of
> > > GUI builders, and should be independent of them all.
> >
> > > Bob
> >
> >
> >
> >
> >
|
|
|
| Re: [PDE]extend the plugin.xml dtd [message #574991 is a reply to message #20715] |
Wed, 04 September 2002 05:52 |
| Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
"xavier" <xmehaut@apri-group.com> wrote in message
news:al1naq$n0b$1@rogue.oti.com...
> Hello Bob,
> It was roughly what I had in mind ; nevertheless we can add two additional
> requirements :
> 1) it should be integrated within the current plugin description
> architecture in order to be able to be homogeneous with it, or at least
> enabling to do the same thing(creation of perspectives, actions, views,
> editors, ...)...
> 2) a GUi builder should be developped right after completing the previous
> tasks
> regards
> Xavier
> ps : when will we begin ;-) ?
If I had time for new projects I'd be working on it instead of talking about
it. ;-}
Bob
>
>
> Bob Foster wrote:
>
> > Here are a few more ideas I\'ve been nursing.
>
> > The basic idea: A project to deliver an XML syntax for declarative
> > descriptions of SWT/JFace GUI, with accompanying supporting Java classes
to
> > instantiate a GUI from its XML description. This syntax and supporting
> > classes could be used to describe extensible user interfaces in Eclipse
> > plugins and as a common language for Eclipse GUI builders.
>
> > The syntax should have intrinsic support for existing SWT controls,
JFace
> > dialogs and wizards, and other JFace components as appropriate. It
should
> > support event listeners specified as user listener classes or methods in
> > user classes (implemented by proxies). It should be user-extensible to
> > support user-written controls, and should provide for plugin extension,
a la
> > the plugin manifest extension points. For example, a plugin might add a
> > control to a dialog provided by another plugin, or a page to an existing
> > wizard.
>
> > Following XUL and unlike bean persistence, the syntax should be easy for
> > humans to read and write. Unlike XUL, the syntax should not be GUI
framework
> > independent; it should be tailored to the Eclipse GUI framework. This is
no
> > less flexible, as XUL and other more abstract descriptions can be
translated
> > (e.g., by XSLT) into this format, and helps ensure that no features of
the
> > Eclipse GUI are lost. Wherever possible, the syntax should be derivable
by a
> > simple and predictable transformation from the corresponding API, e.g.,
> > control and property names should be mapped into the same names but for
> > initial letter capitalization. It should be possible to describe
controls at
> > any level of granularity, e.g., a document might describe an entire
wizard
> > or a single button.
>
> > The supporting classes should, at a minimum, perform dynamic and static
> > translation from XML to Java. That is, a class should be able to read
one or
> > more XML documents and construct a working GUI at runtime. Another
should be
> > able to read the same set of documents and generate Java code which when
> > compiled provides the same GUI. Optionally, perhaps as separate
> > sub-projects, a class might generate Java class files directly from XML
> > documents (compilation), while another might examine existing classes
and
> > produce XML documents (two-way generation).
>
> > Bob
>
> > \"xavier\" <xmehaut@apri-group.com> wrote in message
> > news:akvdqd$pnt$1@rogue.oti.com...
> > > I agree with you Bob ; I think it would be the right way to proceed,
and
> > > even to replace the plugin manifest extension by using it...
> > > I would like to hear the position of OTI on such thing too...
> > > regards
> > > Xavier
> > >
> > > Bob Foster wrote:
> > >
> > > > \"xavier\" <xmehaut@apri-group.com> wrote in message
> > > > news:aksinr$3o6$1@rogue.oti.com...
> > > > > Hello,
> > > > > I don\'t know if it is a good proposal , but I would propose an
> > extension
> > > > > to PDE. Up to now, we can build all infrastructure of an
application
> > in
> > > > > Eclipse by writing only xml code in the plugin.xml file.
Nevertheless
> > we
> > > > > can \"only\"(it is already good ;-) ) focus on views,
perspectives,
> > editors,
> > > > > actions, menus, and so on...
> > > > > I would propose to extend the kind of objects handled. Why not be
able
> > to
> > > > > add a button, a list, a layout, a composite, and so on.., in a
view.
> > By
> > > > > this mean we would have a quite simple GUI builder and most
important
> > a
> > > > > homogeneous declarative way of programming our plugins in
eclipse...
> > In a
> > > > > certain manner, it is quite like XUL with the eclipse xml syntax,
> > isn\'t
> > > > it?
> > > > > I\'m waiting for the comments about this proposal.
> > > > > Xavier
> > >
> > > > I\'m not so keen on this as a plugin manifest extension, as I\'m
afraid
> > this
> > > > kind of stuff would swamp the poor, old manifest. But the recent
> > discussion
> > > > of XUL and friends did suggest to me (as I guess it did to you) that
> > there
> > > > should be an Eclipse-specific (or at least SWT/JFace-specific) way
to
> > > > declaratively specify GUI. This could be the lingua franca for any
> > number of
> > > > GUI builders, and should be independent of them all.
> > >
> > > > Bob
> > >
> > >
> > >
> > >
> > >
>
>
>
>
>
|
|
|
| Re: [PDE]extend the plugin.xml dtd [message #575016 is a reply to message #20772] |
Wed, 04 September 2002 06:30 |
Xavier Méhaut
Messages: 49
Registered: July 2009 |
Member |
|
|
When you're ready, I want well participate ;-)
> "xavier" <xmehaut@apri-group.com> wrote in message
> news:al1naq$n0b$1@rogue.oti.com...
> > Hello Bob,
> > It was roughly what I had in mind ; nevertheless we can add two additional
> > requirements :
> > 1) it should be integrated within the current plugin description
> > architecture in order to be able to be homogeneous with it, or at least
> > enabling to do the same thing(creation of perspectives, actions, views,
> > editors, ...)...
> > 2) a GUi builder should be developped right after completing the previous
> > tasks
> > regards
> > Xavier
> > ps : when will we begin ;-) ?
> If I had time for new projects I'd be working on it instead of talking about
> it. ;-}
> Bob
> >
> >
> > Bob Foster wrote:
> >
> > > Here are a few more ideas I\'ve been nursing.
> >
> > > The basic idea: A project to deliver an XML syntax for declarative
> > > descriptions of SWT/JFace GUI, with accompanying supporting Java classes
> to
> > > instantiate a GUI from its XML description. This syntax and supporting
> > > classes could be used to describe extensible user interfaces in Eclipse
> > > plugins and as a common language for Eclipse GUI builders.
> >
> > > The syntax should have intrinsic support for existing SWT controls,
> JFace
> > > dialogs and wizards, and other JFace components as appropriate. It
> should
> > > support event listeners specified as user listener classes or methods in
> > > user classes (implemented by proxies). It should be user-extensible to
> > > support user-written controls, and should provide for plugin extension,
> a la
> > > the plugin manifest extension points. For example, a plugin might add a
> > > control to a dialog provided by another plugin, or a page to an existing
> > > wizard.
> >
> > > Following XUL and unlike bean persistence, the syntax should be easy for
> > > humans to read and write. Unlike XUL, the syntax should not be GUI
> framework
> > > independent; it should be tailored to the Eclipse GUI framework. This is
> no
> > > less flexible, as XUL and other more abstract descriptions can be
> translated
> > > (e.g., by XSLT) into this format, and helps ensure that no features of
> the
> > > Eclipse GUI are lost. Wherever possible, the syntax should be derivable
> by a
> > > simple and predictable transformation from the corresponding API, e.g.,
> > > control and property names should be mapped into the same names but for
> > > initial letter capitalization. It should be possible to describe
> controls at
> > > any level of granularity, e.g., a document might describe an entire
> wizard
> > > or a single button.
> >
> > > The supporting classes should, at a minimum, perform dynamic and static
> > > translation from XML to Java. That is, a class should be able to read
> one or
> > > more XML documents and construct a working GUI at runtime. Another
> should be
> > > able to read the same set of documents and generate Java code which when
> > > compiled provides the same GUI. Optionally, perhaps as separate
> > > sub-projects, a class might generate Java class files directly from XML
> > > documents (compilation), while another might examine existing classes
> and
> > > produce XML documents (two-way generation).
> >
> > > Bob
> >
> > > \"xavier\" <xmehaut@apri-group.com> wrote in message
> > > news:akvdqd$pnt$1@rogue.oti.com...
> > > > I agree with you Bob ; I think it would be the right way to proceed,
> and
> > > > even to replace the plugin manifest extension by using it...
> > > > I would like to hear the position of OTI on such thing too...
> > > > regards
> > > > Xavier
> > > >
> > > > Bob Foster wrote:
> > > >
> > > > > \"xavier\" <xmehaut@apri-group.com> wrote in message
> > > > > news:aksinr$3o6$1@rogue.oti.com...
> > > > > > Hello,
> > > > > > I don\'t know if it is a good proposal , but I would propose an
> > > extension
> > > > > > to PDE. Up to now, we can build all infrastructure of an
> application
> > > in
> > > > > > Eclipse by writing only xml code in the plugin.xml file.
> Nevertheless
> > > we
> > > > > > can \"only\"(it is already good ;-) ) focus on views,
> perspectives,
> > > editors,
> > > > > > actions, menus, and so on...
> > > > > > I would propose to extend the kind of objects handled. Why not be
> able
> > > to
> > > > > > add a button, a list, a layout, a composite, and so on.., in a
> view.
> > > By
> > > > > > this mean we would have a quite simple GUI builder and most
> important
> > > a
> > > > > > homogeneous declarative way of programming our plugins in
> eclipse...
> > > In a
> > > > > > certain manner, it is quite like XUL with the eclipse xml syntax,
> > > isn\'t
> > > > > it?
> > > > > > I\'m waiting for the comments about this proposal.
> > > > > > Xavier
> > > >
> > > > > I\'m not so keen on this as a plugin manifest extension, as I\'m
> afraid
> > > this
> > > > > kind of stuff would swamp the poor, old manifest. But the recent
> > > discussion
> > > > > of XUL and friends did suggest to me (as I guess it did to you) that
> > > there
> > > > > should be an Eclipse-specific (or at least SWT/JFace-specific) way
> to
> > > > > declaratively specify GUI. This could be the lingua franca for any
> > > number of
> > > > > GUI builders, and should be independent of them all.
> > > >
> > > > > Bob
> > > >
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
> >
> >
|
|
|
Goto Forum:
Current Time: Fri Apr 26 18:42:48 GMT 2024
Powered by FUDForum. Page generated in 0.04337 seconds |
] 
Search
Help
Register
Login
Home
