Re: [ve-dev] VE 1.5 development plan

[Joe Winchester <WINCHEST@xxxxxxxxxx>]

Hi,


>Also there is a task bar item that appears
for the window that ve uses for screen scrape it should be hidden.
We did try to look at hiding this, however we couldn't
find a cross platform way of doing it.  I think there might be a way
on Windows of hiding it - I'll see if I can ping the guys to find the code
to do this - one of the reasons we didn't include it was simply because
we couldn't find a way to do it on Linux.

>Although the best change would be making the ve run
in one vm and getting rid of the screen scraping. basically making
it like all other editors. (The reason for this it runs much faster and
allows instant feedback) but such a thing will probably require
almost a >complete recode :P).
The target VM - a gift and a curse.  The gift is
that you can include JavaBeans or SWT controls, or in fact any POJO, that
is on your project's classpath and have it work with the VE.  The
target VM gets cranked up just the way a Run As>Java Application occurs
(it's in fact the same JDT logic with flags set so you don't see it in
the debug profile) and you get the benefits of having the development environment
be an exact replace (or as close as possible) as the Run As>Java Application,
so any custom classes such as Composite subclasses made by the user, JPanel
subclasses, etc... get included and instantiated correctly so they get
shown.  Also, if the Java component dropped throws a nasty exception
or chews memory or does a System.exit or whatever there is some kind of
IDE protection.  There is a performance hit associated with this target
VM being started and there was work done so that it is pre-emptively started
and the VE attaches to it to lessen this hit.  When you first open
a VE project on a Java class in a project a VM is started to do the introspection
and one for the class being edited, which is where the biggest hit occurs,
however after that the project one remains open and for any other .java
files open the VM is already present.  There is some hit associated
with communicating with the target VM, however this is fairly well optimized
and generally shouldn't be noticable.
The code to not do this target VM instantation is actually
mostly there in VE - the interfaces IBeanProject so forth have two implementations,
one for the target VM and one called IDEBeanProject which is where the
classes run in the IDE's VM.  An implementaition of VE for a while
that used this IDE implementation, however this did it because it safely
knew that all Java classes dropped by the user that needed instantiating
were present in the classpath of the IDE. It shouldn't be too hard technically
to get this back and working again, although there would still be the problem
of how to get a class that the user has written inside the IDE to be dropped.
 If the class loader loads it, what if it gets changed (the user could
be writing the custom component and testing it - sees the button isn't
quite right, change it, and rev the VE class that consumes it).  This
would either need tacking with some nifty class loader logic which I think
is what WindowBuilerPro do.  For VE though we didn't get around to
do this fully, hence the functionally complete but with a performance hit
target VM,

Best regards,

Joe

someone somebody <temp4746@xxxxxxxxx>
Sent by: ve-dev-bounces@xxxxxxxxxxx

06/07/2009 22:07

Please respond to
Discussions people developing code for the Visual Editor project        <ve-dev@xxxxxxxxxxx>

To	Discussions people developing code for the Visual Editor project <ve-dev@xxxxxxxxxxx>
cc
Subject	Re: [ve-dev] VE 1.5 development plan

Hello,

Well i think support for group layout will be nice. Since
it allows free editing that makes life easy when making something simple.
(And it will also help the project stand better against Netbeans).

Also there is a task bar item that appears for
the window that ve uses for screen scrape it should be hidden.

Although the best change would be making the ve run in
one vm and getting rid of the screen scraping. basically making
it like all other editors. (The reason for this it runs much faster and
allows instant feedback) but such a thing will probably require
almost a complete recode :P).

Support for other stuff to edit than Java will be
good since it will make the ve a generic editor for all visual things in
eclipse but perhaps you should be perfecting Java editing first?

I'd recommended you check the bug tracker to, the bugs
have probably been pilling up after the huge period of complete inactivity.

You can also always look at other editors to
see what they have that the ve doesn't, to get ideas for what to do. 

Sorry if i wrote to much i just really wish for eclipse
to have an active GUI designer project, its the only thing that even disturbed
me about Eclipse. 

On Mon, Jul 6, 2009 at 10:45 PM, yves (yingmin) yang <yves.yang@xxxxxxxxxxx>
wrote:
Hi Nick,

You are absolutely. I'll do it.

yves
-----Original Message-----
From: ve-dev-bounces@xxxxxxxxxxx
[mailto:ve-dev-bounces@xxxxxxxxxxx]
On
Behalf Of Nick Boldt
Sent: Monday, July 06, 2009 8:20 PM
To: Discussions people developing code for the Visual Editor project
Subject: Re: [ve-dev] VE 1.5 development plan

Have you set a date for the 1.4.0 release? There needs to be a release
review (complete with slideware that no one will read) and schedule a
call (that no one will attend) in order to be able to release a 1.4.0
R GA build.

Once that's done, you can decide if you want to / need to do 1.4.x
maintenance or just continue in HEAD working on 1.5.0.

N

On Mon, Jul 6, 2009 at 10:54 AM, <yves.yang@xxxxxxxxxxx>
wrote:
> Hi all,
>
> As you know, VE is finally back to eclipse main stream and VE 1.4
ia
> available for download.
>
> It is time to consider the features of nex version 1.5. Here are some
> tropics I have:
>  1. Improve the usability.
>  2. Continue to provide a more generic editing framework, and
supporting
> visual editing of non-java target such as
>     - e4
>     - XSWT
>     - GWT
>     - HTML
>     - XForms
>     - Web pages
>
> Any request/suggestion and contribution are welcome
>
> best regards
> Yves YANG
> ----
> Soyatec - Declarative UI for eclipse
>
> _______________________________________________
> ve-dev mailing list
> ve-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ve-dev
>



--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
Release Engineer :: Dash Athena
http://nick.divbyzero.com
_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev
Checked by AVG - www.avg.com
Version: 8.5.375 / Virus Database: 270.13.5/2220 - Release Date: 07/05/09
17:54:00

_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev
_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU