>
> On Tue, Jul 7, 2009 at 3:31 PM, <
yves.yang@xxxxxxxxxxx> wrote:
>
>> >
>> >>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
>> >
>>
>>
>> _______________________________________________
>> 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
>
_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/ve-dev