Home » Archived » Visual Editor (VE) » JSP/HTML
| JSP/HTML [message #2550] |
Thu, 20 November 2003 14:51  |
Eclipse User |
|
|
|
"The Eclipse Visual Editor project is a framework .... for creating GUI
builders for other languages such as C/C++ and alternate widget sets,
including those that are not supported under Java."
I believe I read somewhere that to generate the swing widgets a seperate
JVM is generated that is used to "draw" the images in the editor by
actually "running" the code (I realize this is probably a gross
oversimplification).
I'm assuming that this is only a possible mechanism to generate the
onscreen view of the widget. From those who have worked with the code
before, is it possible (realistically) to build upon this framework to
create a JSF/HTML GUI editor?
Curious as to what mechanism could be used to generate the widgets on
screen?
Chris....
|
|
| | |
| Re: JSP/HTML [message #3780 is a reply to message #2582] |
Fri, 21 November 2003 08:51  |
| Eclipse User |
|
|
|
Originally posted by: Michael.Dag.removeIFnoSPAM.planet.nl
Joe,
I stumbled upon this, but I am not a programmer, just a not so stupid
user...
<clip>
> Canvas. This means you're working with a cartoon of the live widgets.
One
> thing we want to do as well is leverage this so we can do lots of
techniques
> that are found in other drawing tools where the drawing is exploded to
> exaggerate features or allow additional manipulation points for the GUI,
so
> it's not always a flat direct drawing of the live widgets but instead is
> more of an annotated cartoon.
</clip>
Can you elaborate on what you mean here?
One drawing tool I work with is Visio, which besides excellent drawing
capabilities has 'rich' programming support (from an end-user
perspective...), could a spin-off of VE be an opensource turbo charged Visio
environment?
I know Microsoft in Visio 2003 have enabled the use of Visio drawing
controls from VB .NET for tighter integration with 'custom' solutions
behind the drawing.
Or am I totally off mark here?
Michael
"Joe Winchester" <winchest@uk.ibm.com> schreef in bericht
news:3FBD303F.2EF6913B@uk.ibm.com...
> Hi Chris,
>
> > I believe I read somewhere that to generate the swing widgets a seperate
> > JVM is generated that is used to "draw" the images in the editor by
> > actually "running" the code (I realize this is probably a gross
> > oversimplification).
>
> No - that's a pretty good summary of what occurs. What happens is that a
> separate JVM sandbox is created whose classpath is the buildpath of the
> project. You have an object model in the IDE of the GUI and its elements
> created from parsing the code and then you proxy each component to their
> live ones in the target JVM. The GUI stuff off-screen so you can't see
it,
> and the image of this captured and then drawn in GEF which uses an SWT
> Canvas. This means you're working with a cartoon of the live widgets.
One
> thing we want to do as well is leverage this so we can do lots of
techniques
> that are found in other drawing tools where the drawing is exploded to
> exaggerate features or allow additional manipulation points for the GUI,
so
> it's not always a flat direct drawing of the live widgets but instead is
> more of an annotated cartoon.
>
> > I'm assuming that this is only a possible mechanism to generate the
> > onscreen view of the widget. From those who have worked with the code
> > before, is it possible (realistically) to build upon this framework to
> > create a JSF/HTML GUI editor?
> > Curious as to what mechanism could be used to generate the widgets on
> > screen?
>
> The only real requirement on the live GUI is that you can work out what it
> looks like, and also the size and location of each component. For HTML
one
> idea we were toying around with a while back was having DHTML that can get
> you the bounds of each DOM element, and then some Java script to allow a
> socket to be opened between the IDE and the browser allowing this
> information to go back and forth. There is also the possibility of
> pervasive devices where you want to work with a true cartoon of the
device's
> rendering rather than emulation. Even with just Swing itself you can
> develop for a JRE level that is totally separate to the IDE JRE.
>
> Best regards,
>
> Joe
>
|
|
|
| Re: JSP/HTML [message #3787 is a reply to message #2640] |
Fri, 21 November 2003 09:03 |
| Eclipse User |
|
|
|
Originally posted by: mendelgili.netscape.net
There is a bean model (the center of the universe for VE). For every
widget (or bean) instance there is an EditPart associated with it, as
well as a live instance on the target VM. The target VM can get the
bounds of these instances, as well as listen for changes. The EditPart
associated with an instance will reflect the image on the canvas.
Pascal Rapicault wrote:
> Hi,
>
> I'm just curious: From the "picture" the vm gives you, how do you recognize
> what is a widget, and which type of widget is it to draw it in gef?
> Can you point me at the code that "get the picture "from the VM?
>
> Thank you,
>
> PaScaL
>
> "Joe Winchester" <winchest@uk.ibm.com> a écrit dans le message de news:
> 3FBD303F.2EF6913B@uk.ibm.com...
>
>>Hi Chris,
>>
>>
>>>I believe I read somewhere that to generate the swing widgets a seperate
>>>JVM is generated that is used to "draw" the images in the editor by
>>>actually "running" the code (I realize this is probably a gross
>>>oversimplification).
>>
>>No - that's a pretty good summary of what occurs. What happens is that a
>>separate JVM sandbox is created whose classpath is the buildpath of the
>>project. You have an object model in the IDE of the GUI and its elements
>>created from parsing the code and then you proxy each component to their
>>live ones in the target JVM. The GUI stuff off-screen so you can't see
>
> it,
>
>>and the image of this captured and then drawn in GEF which uses an SWT
>>Canvas. This means you're working with a cartoon of the live widgets.
>
> One
>
>>thing we want to do as well is leverage this so we can do lots of
>
> techniques
>
>>that are found in other drawing tools where the drawing is exploded to
>>exaggerate features or allow additional manipulation points for the GUI,
>
> so
>
>>it's not always a flat direct drawing of the live widgets but instead is
>>more of an annotated cartoon.
>>
>>
>>>I'm assuming that this is only a possible mechanism to generate the
>>>onscreen view of the widget. From those who have worked with the code
>>>before, is it possible (realistically) to build upon this framework to
>>>create a JSF/HTML GUI editor?
>>>Curious as to what mechanism could be used to generate the widgets on
>>>screen?
>>
>>The only real requirement on the live GUI is that you can work out what it
>>looks like, and also the size and location of each component. For HTML
>
> one
>
>>idea we were toying around with a while back was having DHTML that can get
>>you the bounds of each DOM element, and then some Java script to allow a
>>socket to be opened between the IDE and the browser allowing this
>>information to go back and forth. There is also the possibility of
>>pervasive devices where you want to work with a true cartoon of the
>
> device's
>
>>rendering rather than emulation. Even with just Swing itself you can
>>develop for a JRE level that is totally separate to the IDE JRE.
>>
>>Best regards,
>>
>>Joe
>>
>
>
>
|
|
|
| Re: JSP/HTML [message #3813 is a reply to message #3780] |
Fri, 21 November 2003 10:10 |
| Eclipse User |
|
|
|
Hi Michael,
> Can you elaborate on what you mean here?
When you as a developer create a GUI you do stuff like create a frame, put some
buttons on it, etc...
A GUI builder has to do likewise, but it has a slightly different angle. It
doesn't want the button to be a real button that can be pushed, or a text field
to be a real one that can accept keyboard and mouse entry. It wants to show the
user the button and text so they can be previewed based on their initial state.
Two options:
1 - Create the controls (buttons, text fields, etc...) in the IDE itself
so they are owned by a workspace window and actually part of the Eclipse JVM.
You have to then fake out the controls so they don't act as live instances
accepting keyboard and mouse, deal with things like not being able to put a top
level window inside another window so the user can't truly preview things like a
titlebar or maximize/minimize bars, and also deal with the fact that if the user
is modifying the controls at the same time they're using them you have to be
able to unload the class or find another way to sandbox it.
2 - All of the options in 1 are soluble if you do run the widgets inside
the IDE, however another approach which is used by GUI builders (including the
Visual Editor) is to run the controls in a separate JVM entirely. You put them
off screen and hide them from the user as much as you can, and then inside the
IDE you just draw them. This has its disadvantages too over 1, however if it
can be got to work it does offer the ability to draw the GUI any way you want.
You could zoom it, shrink it, draw GridBagLayout controls actually in a grid
with spaces between them. It's sort of like a drawing of a house where in some
modes you want to see the finished result, but in others you want to see the
windows and doors separated out and details of the pipes. The latter kind of
thing is what I was sort of trying to describe when I talked about leveraging
the fact that the Visual Editor is a cartoon layout of the GUI.
Best regards,
Joe
|
|
| | |
| Re: JSP/HTML [message #4821 is a reply to message #4336] |
Tue, 25 November 2003 00:17 |
| Eclipse User |
|
|
|
Originally posted by: scheglov_ke.nlmk.ru
Joe Winchester wrote:
> > Joe, can you please point to classes that create these images and send
> > them to Eclipse JVM? Ideally just class or package names.
> In the IDE
> org.eclipse.ve.internal.jfc.core.ComponentManager
> org.eclipse.ve.internal.jfc.core.ImageDataCollector
> In the targer VM
> org.eclipse.ve.internal.jfc.vm.ComponentManager
> org.eclipse.ve.internal.jfc.vm.ImageDataCollector
Thank you.
--
SY, Kosta.
|
|
|
| Re: JSP/HTML [message #567676 is a reply to message #2550] |
Thu, 20 November 2003 16:21 |
| Eclipse User |
|
|
|
Hi Chris,
> I believe I read somewhere that to generate the swing widgets a seperate
> JVM is generated that is used to "draw" the images in the editor by
> actually "running" the code (I realize this is probably a gross
> oversimplification).
No - that's a pretty good summary of what occurs. What happens is that a
separate JVM sandbox is created whose classpath is the buildpath of the
project. You have an object model in the IDE of the GUI and its elements
created from parsing the code and then you proxy each component to their
live ones in the target JVM. The GUI stuff off-screen so you can't see it,
and the image of this captured and then drawn in GEF which uses an SWT
Canvas. This means you're working with a cartoon of the live widgets. One
thing we want to do as well is leverage this so we can do lots of techniques
that are found in other drawing tools where the drawing is exploded to
exaggerate features or allow additional manipulation points for the GUI, so
it's not always a flat direct drawing of the live widgets but instead is
more of an annotated cartoon.
> I'm assuming that this is only a possible mechanism to generate the
> onscreen view of the widget. From those who have worked with the code
> before, is it possible (realistically) to build upon this framework to
> create a JSF/HTML GUI editor?
> Curious as to what mechanism could be used to generate the widgets on
> screen?
The only real requirement on the live GUI is that you can work out what it
looks like, and also the size and location of each component. For HTML one
idea we were toying around with a while back was having DHTML that can get
you the bounds of each DOM element, and then some Java script to allow a
socket to be opened between the IDE and the browser allowing this
information to go back and forth. There is also the possibility of
pervasive devices where you want to work with a true cartoon of the device's
rendering rather than emulation. Even with just Swing itself you can
develop for a JRE level that is totally separate to the IDE JRE.
Best regards,
Joe
|
|
|
| Re: JSP/HTML [message #567720 is a reply to message #2582] |
Thu, 20 November 2003 20:05 |
| Eclipse User |
|
|
|
Hi,
I'm just curious: From the "picture" the vm gives you, how do you recognize
what is a widget, and which type of widget is it to draw it in gef?
Can you point me at the code that "get the picture "from the VM?
Thank you,
PaScaL
"Joe Winchester" <winchest@uk.ibm.com> a
|
|
|
| Re: JSP/HTML [message #567949 is a reply to message #2582] |
Fri, 21 November 2003 08:51 |
| Eclipse User |
|
|
|
Joe,
I stumbled upon this, but I am not a programmer, just a not so stupid
user...
<clip>
> Canvas. This means you're working with a cartoon of the live widgets.
One
> thing we want to do as well is leverage this so we can do lots of
techniques
> that are found in other drawing tools where the drawing is exploded to
> exaggerate features or allow additional manipulation points for the GUI,
so
> it's not always a flat direct drawing of the live widgets but instead is
> more of an annotated cartoon.
</clip>
Can you elaborate on what you mean here?
One drawing tool I work with is Visio, which besides excellent drawing
capabilities has 'rich' programming support (from an end-user
perspective...), could a spin-off of VE be an opensource turbo charged Visio
environment?
I know Microsoft in Visio 2003 have enabled the use of Visio drawing
controls from VB .NET for tighter integration with 'custom' solutions
behind the drawing.
Or am I totally off mark here?
Michael
"Joe Winchester" <winchest@uk.ibm.com> schreef in bericht
news:3FBD303F.2EF6913B@uk.ibm.com...
> Hi Chris,
>
> > I believe I read somewhere that to generate the swing widgets a seperate
> > JVM is generated that is used to "draw" the images in the editor by
> > actually "running" the code (I realize this is probably a gross
> > oversimplification).
>
> No - that's a pretty good summary of what occurs. What happens is that a
> separate JVM sandbox is created whose classpath is the buildpath of the
> project. You have an object model in the IDE of the GUI and its elements
> created from parsing the code and then you proxy each component to their
> live ones in the target JVM. The GUI stuff off-screen so you can't see
it,
> and the image of this captured and then drawn in GEF which uses an SWT
> Canvas. This means you're working with a cartoon of the live widgets.
One
> thing we want to do as well is leverage this so we can do lots of
techniques
> that are found in other drawing tools where the drawing is exploded to
> exaggerate features or allow additional manipulation points for the GUI,
so
> it's not always a flat direct drawing of the live widgets but instead is
> more of an annotated cartoon.
>
> > I'm assuming that this is only a possible mechanism to generate the
> > onscreen view of the widget. From those who have worked with the code
> > before, is it possible (realistically) to build upon this framework to
> > create a JSF/HTML GUI editor?
> > Curious as to what mechanism could be used to generate the widgets on
> > screen?
>
> The only real requirement on the live GUI is that you can work out what it
> looks like, and also the size and location of each component. For HTML
one
> idea we were toying around with a while back was having DHTML that can get
> you the bounds of each DOM element, and then some Java script to allow a
> socket to be opened between the IDE and the browser allowing this
> information to go back and forth. There is also the possibility of
> pervasive devices where you want to work with a true cartoon of the
device's
> rendering rather than emulation. Even with just Swing itself you can
> develop for a JRE level that is totally separate to the IDE JRE.
>
> Best regards,
>
> Joe
>
|
|
|
| Re: JSP/HTML [message #567992 is a reply to message #2640] |
Fri, 21 November 2003 09:03 |
| Eclipse User |
|
|
|
There is a bean model (the center of the universe for VE). For every
widget (or bean) instance there is an EditPart associated with it, as
well as a live instance on the target VM. The target VM can get the
bounds of these instances, as well as listen for changes. The EditPart
associated with an instance will reflect the image on the canvas.
Pascal Rapicault wrote:
> Hi,
>
> I'm just curious: From the "picture" the vm gives you, how do you recognize
> what is a widget, and which type of widget is it to draw it in gef?
> Can you point me at the code that "get the picture "from the VM?
>
> Thank you,
>
> PaScaL
>
> "Joe Winchester" <winchest@uk.ibm.com> a écrit dans le message de news:
> 3FBD303F.2EF6913B@uk.ibm.com...
>
>>Hi Chris,
>>
>>
>>>I believe I read somewhere that to generate the swing widgets a seperate
>>>JVM is generated that is used to "draw" the images in the editor by
>>>actually "running" the code (I realize this is probably a gross
>>>oversimplification).
>>
>>No - that's a pretty good summary of what occurs. What happens is that a
>>separate JVM sandbox is created whose classpath is the buildpath of the
>>project. You have an object model in the IDE of the GUI and its elements
>>created from parsing the code and then you proxy each component to their
>>live ones in the target JVM. The GUI stuff off-screen so you can't see
>
> it,
>
>>and the image of this captured and then drawn in GEF which uses an SWT
>>Canvas. This means you're working with a cartoon of the live widgets.
>
> One
>
>>thing we want to do as well is leverage this so we can do lots of
>
> techniques
>
>>that are found in other drawing tools where the drawing is exploded to
>>exaggerate features or allow additional manipulation points for the GUI,
>
> so
>
>>it's not always a flat direct drawing of the live widgets but instead is
>>more of an annotated cartoon.
>>
>>
>>>I'm assuming that this is only a possible mechanism to generate the
>>>onscreen view of the widget. From those who have worked with the code
>>>before, is it possible (realistically) to build upon this framework to
>>>create a JSF/HTML GUI editor?
>>>Curious as to what mechanism could be used to generate the widgets on
>>>screen?
>>
>>The only real requirement on the live GUI is that you can work out what it
>>looks like, and also the size and location of each component. For HTML
>
> one
>
>>idea we were toying around with a while back was having DHTML that can get
>>you the bounds of each DOM element, and then some Java script to allow a
>>socket to be opened between the IDE and the browser allowing this
>>information to go back and forth. There is also the possibility of
>>pervasive devices where you want to work with a true cartoon of the
>
> device's
>
>>rendering rather than emulation. Even with just Swing itself you can
>>develop for a JRE level that is totally separate to the IDE JRE.
>>
>>Best regards,
>>
>>Joe
>>
>
>
>
|
|
|
| Re: JSP/HTML [message #568105 is a reply to message #3780] |
Fri, 21 November 2003 10:10 |
| Eclipse User |
|
|
|
Hi Michael,
> Can you elaborate on what you mean here?
When you as a developer create a GUI you do stuff like create a frame, put some
buttons on it, etc...
A GUI builder has to do likewise, but it has a slightly different angle. It
doesn't want the button to be a real button that can be pushed, or a text field
to be a real one that can accept keyboard and mouse entry. It wants to show the
user the button and text so they can be previewed based on their initial state.
Two options:
1 - Create the controls (buttons, text fields, etc...) in the IDE itself
so they are owned by a workspace window and actually part of the Eclipse JVM.
You have to then fake out the controls so they don't act as live instances
accepting keyboard and mouse, deal with things like not being able to put a top
level window inside another window so the user can't truly preview things like a
titlebar or maximize/minimize bars, and also deal with the fact that if the user
is modifying the controls at the same time they're using them you have to be
able to unload the class or find another way to sandbox it.
2 - All of the options in 1 are soluble if you do run the widgets inside
the IDE, however another approach which is used by GUI builders (including the
Visual Editor) is to run the controls in a separate JVM entirely. You put them
off screen and hide them from the user as much as you can, and then inside the
IDE you just draw them. This has its disadvantages too over 1, however if it
can be got to work it does offer the ability to draw the GUI any way you want.
You could zoom it, shrink it, draw GridBagLayout controls actually in a grid
with spaces between them. It's sort of like a drawing of a house where in some
modes you want to see the finished result, but in others you want to see the
windows and doors separated out and details of the pipes. The latter kind of
thing is what I was sort of trying to describe when I talked about leveraging
the fact that the Visual Editor is a cartoon layout of the GUI.
Best regards,
Joe
|
|
|
| Re: JSP/HTML [message #568511 is a reply to message #3813] |
Sun, 23 November 2003 23:43 |
| Eclipse User |
|
|
|
Joe Winchester wrote:
> > Can you elaborate on what you mean here?
[cut]
> modes you want to see the finished result, but in others you want to see the
> windows and doors separated out and details of the pipes. The latter kind of
> thing is what I was sort of trying to describe when I talked about leveraging
> the fact that the Visual Editor is a cartoon layout of the GUI.
Joe, can you please point to classes that create these images and send
them to Eclipse JVM? Ideally just class or package names.
--
SY, Kosta.
|
|
|
| Re: JSP/HTML [message #568760 is a reply to message #3886] |
Mon, 24 November 2003 10:16 |
| Eclipse User |
|
|
|
Hi Kosta,
> Joe, can you please point to classes that create these images and send
> them to Eclipse JVM? Ideally just class or package names.
In the IDE
org.eclipse.ve.internal.jfc.core.ComponentManager
org.eclipse.ve.internal.jfc.core.ImageDataCollector
In the targer VM
org.eclipse.ve.internal.jfc.vm.ComponentManager
org.eclipse.ve.internal.jfc.vm.ImageDataCollector
Best regards,
Joe
|
|
|
| Re: JSP/HTML [message #568949 is a reply to message #4336] |
Tue, 25 November 2003 00:17 |
| Eclipse User |
|
|
|
Joe Winchester wrote:
> > Joe, can you please point to classes that create these images and send
> > them to Eclipse JVM? Ideally just class or package names.
> In the IDE
> org.eclipse.ve.internal.jfc.core.ComponentManager
> org.eclipse.ve.internal.jfc.core.ImageDataCollector
> In the targer VM
> org.eclipse.ve.internal.jfc.vm.ComponentManager
> org.eclipse.ve.internal.jfc.vm.ImageDataCollector
Thank you.
--
SY, Kosta.
|
|
|
Goto Forum:
Current Time: Wed Apr 16 00:22:53 EDT 2025
Powered by FUDForum. Page generated in 0.03784 seconds |
Home