Home » Archived » Visual Editor (VE) » extending visual editor
| extending visual editor [message #80868] |
Sun, 20 February 2005 16:53  |
Eclipse User |
|
|
|
Originally posted by: alllee.cs.indiana.edu
(posted to dev mailing list already, double-posting here in the hopes of
a speedier response time)
Hi there:
We've been working on an interface builder for Java for some time now
over at http://developer.knownspace.org/fluency. This semester we
decided to strike the old codebase and convert/refactor it into an
Eclipse RCP project. Towards this end, we'd love to be able to leverage
_just_ the widget layout/graphical editing component of VE - we don't
need the code generation/round tripping stuff due to the design of
Fluency. In short, we want to add our own custom behavior behind the
scenes when a widget is placed on the graphical editor. We still need
to maintain a persistent notion of widget properties and layout, of
course, but these get persisted as properties of the layout graph (or
linkage graph in Fluency terms).
I poked around the help files and these mailing list archives but was
unable to find anything with my punee eyes. The help files appear to be
only concerned with the extension of the widget palette that VE uses so
that you can add your own custom widgets.
So the enormously vague question that I have is.. What is the 'best' way
to extricate the graphical editing and widget palette code from the rest
of the codebase? If this is too enormous of a question, what basic
classes/packages should we be looking for? I've checked out the code
from CVS and have been poking around the org.eclipse.ve.java.core
project,
org.eclipse.ve.internal.java.codegen.editorpart.JavaVisualEd itorPart
looks like it a promising starting point but I haven't delved too deeply
into it yet. At this stage in my investigation it seems like it'd be
easiest to just rip out relevant code (with license/copyright of course)
and modify it within the context of our app (the 'internal' part of the
package name sounds out the big klaxon alarms in my head.. ;). In any
case, any pointers to places to look or tips on what classes we should
focus on would be tremendously helpful.
Thanks for your time!
Allen Lee
|
|
| |
| Re: extending visual editor [message #81180 is a reply to message #80875] |
Mon, 21 February 2005 21:52  |
| Eclipse User |
|
|
|
Originally posted by: alllee.cs.indiana.edu
Thanks for the suggestion. However, we don't want or need all of the VE
functionality. Perhaps that wasn't clear in the message, sorry if that
was the case. We'd like to get an idea of how VE does its graphical
editing, i.e., placing widgets on the graphical editor pane, modifying
their size, position, and layout and so on... Just getting pointers to
relevant packages and classes would be enough. We've done this before
in Swing, we were just hoping to find examples of how to do it in SWT
within VE.
Allen
daniel james wrote:
> why don't you toy around getting a RCP and try to load the VE plugin
> module?
>
> and see what happens.
>
>
> Allen Lee wrote:
>
>> (posted to dev mailing list already, double-posting here in the hopes
>> of a speedier response time)
>>
>> Hi there:
>>
>> We've been working on an interface builder for Java for some time now
>> over at http://developer.knownspace.org/fluency. This semester we
>> decided to strike the old codebase and convert/refactor it into an
>> Eclipse RCP project. Towards this end, we'd love to be able to
>> leverage _just_ the widget layout/graphical editing component of VE -
>> we don't need the code generation/round tripping stuff due to the
>> design of Fluency. In short, we want to add our own custom behavior
>> behind the scenes when a widget is placed on the graphical editor. We
>> still need to maintain a persistent notion of widget properties and
>> layout, of course, but these get persisted as properties of the layout
>> graph (or linkage graph in Fluency terms).
>>
>> I poked around the help files and these mailing list archives but was
>> unable to find anything with my punee eyes. The help files appear to
>> be only concerned with the extension of the widget palette that VE
>> uses so that you can add your own custom widgets.
>>
>> So the enormously vague question that I have is.. What is the 'best'
>> way to extricate the graphical editing and widget palette code from
>> the rest of the codebase? If this is too enormous of a question, what
>> basic classes/packages should we be looking for? I've checked out the
>> code from CVS and have been poking around the org.eclipse.ve.java.core
>> project,
>> org.eclipse.ve.internal.java.codegen.editorpart.JavaVisualEd itorPart
>> looks like it a promising starting point but I haven't delved too
>> deeply into it yet. At this stage in my investigation it seems like
>> it'd be easiest to just rip out relevant code (with license/copyright
>> of course) and modify it within the context of our app (the 'internal'
>> part of the package name sounds out the big klaxon alarms in my head..
>> ;). In any case, any pointers to places to look or tips on what
>> classes we should focus on would be tremendously helpful.
>>
>> Thanks for your time!
>> Allen Lee
|
|
|
| Re: extending visual editor [message #605443 is a reply to message #80868] |
Sun, 20 February 2005 17:57 |
| Eclipse User |
|
|
|
why don't you toy around getting a RCP and try to load the VE plugin module?
and see what happens.
Allen Lee wrote:
> (posted to dev mailing list already, double-posting here in the hopes of
> a speedier response time)
>
> Hi there:
>
> We've been working on an interface builder for Java for some time now
> over at http://developer.knownspace.org/fluency This semester we
> decided to strike the old codebase and convert/refactor it into an
> Eclipse RCP project. Towards this end, we'd love to be able to leverage
> _just_ the widget layout/graphical editing component of VE - we don't
> need the code generation/round tripping stuff due to the design of
> Fluency. In short, we want to add our own custom behavior behind the
> scenes when a widget is placed on the graphical editor. We still need
> to maintain a persistent notion of widget properties and layout, of
> course, but these get persisted as properties of the layout graph (or
> linkage graph in Fluency terms).
>
> I poked around the help files and these mailing list archives but was
> unable to find anything with my punee eyes. The help files appear to be
> only concerned with the extension of the widget palette that VE uses so
> that you can add your own custom widgets.
>
> So the enormously vague question that I have is.. What is the 'best' way
> to extricate the graphical editing and widget palette code from the rest
> of the codebase? If this is too enormous of a question, what basic
> classes/packages should we be looking for? I've checked out the code
> from CVS and have been poking around the org.eclipse.ve.java.core
> project,
> org.eclipse.ve.internal.java.codegen.editorpart.JavaVisualEd itorPart
> looks like it a promising starting point but I haven't delved too deeply
> into it yet. At this stage in my investigation it seems like it'd be
> easiest to just rip out relevant code (with license/copyright of course)
> and modify it within the context of our app (the 'internal' part of the
> package name sounds out the big klaxon alarms in my head.. ;). In any
> case, any pointers to places to look or tips on what classes we should
> focus on would be tremendously helpful.
>
> Thanks for your time!
> Allen Lee
|
|
|
| Re: extending visual editor [message #605503 is a reply to message #80875] |
Mon, 21 February 2005 21:52 |
| Eclipse User |
|
|
|
Thanks for the suggestion. However, we don't want or need all of the VE
functionality. Perhaps that wasn't clear in the message, sorry if that
was the case. We'd like to get an idea of how VE does its graphical
editing, i.e., placing widgets on the graphical editor pane, modifying
their size, position, and layout and so on... Just getting pointers to
relevant packages and classes would be enough. We've done this before
in Swing, we were just hoping to find examples of how to do it in SWT
within VE.
Allen
daniel james wrote:
> why don't you toy around getting a RCP and try to load the VE plugin
> module?
>
> and see what happens.
>
>
> Allen Lee wrote:
>
>> (posted to dev mailing list already, double-posting here in the hopes
>> of a speedier response time)
>>
>> Hi there:
>>
>> We've been working on an interface builder for Java for some time now
>> over at http://developer.knownspace.org/fluency This semester we
>> decided to strike the old codebase and convert/refactor it into an
>> Eclipse RCP project. Towards this end, we'd love to be able to
>> leverage _just_ the widget layout/graphical editing component of VE -
>> we don't need the code generation/round tripping stuff due to the
>> design of Fluency. In short, we want to add our own custom behavior
>> behind the scenes when a widget is placed on the graphical editor. We
>> still need to maintain a persistent notion of widget properties and
>> layout, of course, but these get persisted as properties of the layout
>> graph (or linkage graph in Fluency terms).
>>
>> I poked around the help files and these mailing list archives but was
>> unable to find anything with my punee eyes. The help files appear to
>> be only concerned with the extension of the widget palette that VE
>> uses so that you can add your own custom widgets.
>>
>> So the enormously vague question that I have is.. What is the 'best'
>> way to extricate the graphical editing and widget palette code from
>> the rest of the codebase? If this is too enormous of a question, what
>> basic classes/packages should we be looking for? I've checked out the
>> code from CVS and have been poking around the org.eclipse.ve.java.core
>> project,
>> org.eclipse.ve.internal.java.codegen.editorpart.JavaVisualEd itorPart
>> looks like it a promising starting point but I haven't delved too
>> deeply into it yet. At this stage in my investigation it seems like
>> it'd be easiest to just rip out relevant code (with license/copyright
>> of course) and modify it within the context of our app (the 'internal'
>> part of the package name sounds out the big klaxon alarms in my head..
>> ;). In any case, any pointers to places to look or tips on what
>> classes we should focus on would be tremendously helpful.
>>
>> Thanks for your time!
>> Allen Lee
|
|
|
Goto Forum:
Current Time: Sun Jul 27 02:06:51 EDT 2025
Powered by FUDForum. Page generated in 0.03410 seconds |
Home