[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ve-dev] VE 1.5 development plan
|
>>
>> 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.
>
> I am talking about swing though...
The same concept can be used to Swing.
> Making an extra file to store the gui in (like netbeans does) is bad if
> that
> file goes out of sync or is lost that .java file basiclly becomes useless.
> (Unless that file can be recreated from the .java file if lost which at
> that
> point makes it only usefull if it makes the editor respond faster.)
> I am not against the idea of delarative ui, im only against what netbeans
> gui desginer does (That extra .form file that sometimes goes out of sync
> or
> is lost and leaves you stuck)
> Although the designer in itself has great useability.
I have an opposite position. The Static UI should be separated in
different file. It is what we said the separation of UI with business
logic.
The synchronization between files are always to keep. You can not develop
an application in one file.
>
> Especially due to group layout which makes gui designing easy and feel
> like
> it feels in visual studio.
Can you contribute the development of group layout in VE ?
yves
>
> 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
>
