Re: [ve-dev] VE 1.5 development plan

[yves.yang@xxxxxxxxxxx]

>
>>But I think we should not touch the current architecture for two reasons:
> 1.       Heavy tasks
> 2.       Break the compatibility.
> So it is possible to make the VE run in a single VM but it will require
> some
> work...
> Well this should be looked at later on cause it will provide a good
> performance increase due to eliminating cross VM communication overhead.
>
I think we agree: 2 JVMs isn't a critical issue. It is nice to have.

>>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.
> Well whatever you do just make sure to keep it working with only the .java
> file (not adding any extra files required to actually load the class,
> adding some for cache and performance boost is OK)

Java is not a good solution to store UI structure:
   1. Difficult to decode and encode
   2. Static aspect and business logic are mixed up, it is always a mass
   3. Very limited to support advanced features such as data binding,
reusable component, etc

Please look at the incubator project - e4 XWT.

yves
> I also remembered adding support for editing some .java GUI files that
> weren't made by the ve will be nice (either by reformatting them or making
> it use them naively(no reformatting))
>

>
>
>
> On Tue, Ju
>
>>
>> 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* <yves.yang@xxxxxxxxxxx>> wrote:
>> Hi Nick,
>>
>> You are absolutely. I'll do it.
>>
>> yves
>> -----Original Message-----
>> From: *ve-dev-bounces@xxxxxxxxxxx* <ve-dev-bounces@xxxxxxxxxxx>
>> [mailto:*
>> ve-dev-bounces@xxxxxxxxxxx* <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*<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* <ve-dev@xxxxxxxxxxx>
>> > *https://dev.eclipse.org/mailman/listinfo/ve-dev*<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* <http://nick.divbyzero.com/>
>> _______________________________________________
>> ve-dev mailing list*
>> **ve-dev@xxxxxxxxxxx* <ve-dev@xxxxxxxxxxx>*
>> **https://dev.eclipse.org/mailman/listinfo/ve-dev*<https://dev.eclipse.org/mailman/listinfo/ve-dev>
>> Checked by AVG - *www.avg.com* <http://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* <ve-dev@xxxxxxxxxxx>*
>> **https://dev.eclipse.org/mailman/listinfo/ve-dev*<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
>> *
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>