Thanks Joe for giving detail explanation.
Any suggestion and feedbacks are welcome. I have noted your
suggestions.
But I think we should not touch the current architecture for two
reasons:
1. Heavy
tasks
2. Break
the compatibility.
And the development UI in Java is very low level. We should
focus on high level and domain oriented solution based on declarative UI, which
could be used by graphic designer and application domain developer.
Best regards
yves
From:
ve-dev-bounces@xxxxxxxxxxx [mailto:ve-dev-bounces@xxxxxxxxxxx] On Behalf Of Joe
Winchester
Sent: Tuesday, July 07, 2009 12:02 AM
To: Discussions people developing code for the Visual Editor project
Subject: Re: [ve-dev] VE 1.5 development plan
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
Checked by AVG - www.avg.com
Version: 8.5.375 / Virus Database: 270.13.5/2220 - Release Date: 07/05/09
17:54:00