Re: [ve-dev] VE 1.5 development plan

[yves.yang@xxxxxxxxxxx]

> Hello,
>
> So wait are you going to create library on top of swing that will load XML
> files and create the ui from them?

Look at e4 XWT or http://www.soyatec.com/eface. Or there is another
project named as XSWT: http://sourceforge.net/projects/xswt/

> Or are you going to make an XML that the ve edits and generates the ui
> code
> from that?

In this mode, VE will edit directly UI in XML. The render will take care
of the display. It will not deal with UI in Java.

> The only issue with the second approach is editing java gui files from
> other
> programs.

I think you are not familiar with Declarative UI. Please take a look on
the products I mentioned above, it will help you to get in a new paradise.

yves
>
> On Wed, Jul 8, 2009 at 12:00 PM, <yves.yang@xxxxxxxxxxx> wrote:
>
>> > Well the gui code should also exist in the .java file but not really
>> used,
>> > except for compiling and as a backup in case the XML file becomes
>> lost.
>> > It can also be used as a cache to speed up initial loading of the
>> editor
>> > (not recreating the code from scratch every time, but thats a bit
>> desync
>> > prone so it really requires good code that wont cause such desync and
>> if
>> > it
>> > does happen what i said in my previous mail still stands:
>>
>> In eclipse, you can use Local history to come backt o previous version
>> or
>> use CVS/SVN.
>>
>> yves
>>  >
>> >>  Yet the problem is if a desync happens or you lose one of the files
>> >> will
>> >> you be able to continue work?
>> >> If you do than that approach works very well.
>> >> Basically it means being able to restore either one of the files from
>> >> the
>> >> other one. (Including complete user code (events and such) (If
>> possible
>> >> making it handle any .java not just ones originally made by the ve)
>> >> It shouldn't be to hard to achieve (At least the Different file to
>> .java
>> >> part :P)
>> >>
>> >> Better yet is to prevent desyncs in the first place and if they do
>> >> happens
>> >> fix them automatically.
>> >>
>> >> One of the problems i saw in many editors was that they only handle
>> >> files
>> >> that were created in them.
>> >> Since most of the GUI code i saw was made by hand or with a different
>> >> editor it makes them quite pointless unless for projects that you
>> make
>> >> sure
>> >> everybody use the same one or for once made solely by yourself.
>> >>
>> >> Im quite sure you will be able to do it well, and not give us some
>> data
>> >> loss inducing piece of software :P.
>> >
>> >
>> > On Tue, Jul 7, 2009 at 10:05 PM, Eric Clayberg
>> > <clayberg@xxxxxxxxxxxxxxxxxx>wrote:
>> >
>> >>
>> >> 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.
>> >>>
>> >>
>> >> I hope what they mean is to use XML to represent the GUI as a
>> complete
>> >> alternative to Java and not have two files (XML and Java)
>> representing
>> >> the
>> >> same thing. The former can work, but the latter is downright
>> dangerous
>> >> as is
>> >> the case with NetBeans. One of the basic principles of data
>> >> normalizations
>> >> is that it is always a bad idea to have two data structures (or two
>> >> files)
>> >> represent the exact same thing. That is a recipe for disaster as they
>> >> will
>> >> always get out of sync eventually or the primary file (the XML .form
>> >> file in
>> >> the case of NetBeans) will always get lost.
>> >>
>> >> 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)
>> >>>
>> >>
>> >> The NetBeans GUI builder is quite primitive under the covers (with a
>> >> very
>> >> sexy exterior) as it can't even parse its own generated Java code.
>> That
>> >> makes its reliance on .form files particularly dangerous. We have
>> >> rescued
>> >> many dead-in-the-water NetBeans projects with WindowBuilder's ability
>> to
>> >> both read and write the NetBeans GUI style.
>> >>
>> >> Regards,
>> >>
>> >> -Eric Clayberg
>> >>  Sr. Vice President of Product Development
>> >>  Instantiations, Inc.
>> >>  mailto:clayberg@xxxxxxxxxxxxxxxxxx
>> >>  http://www.instantiations.com
>> >>  Eclipse Productivity. Enterprise Quality.
>> >>
>> >>  Author: "Eclipse: Building Commercial Quality Plug-ins"
>> >>  http://www.awprofessional.com/title/032142672X
>> >>  Author: "Eclipse Plug-ins"
>> >>  http://www.awprofessional.com/title/0321553462
>> >> _______________________________________________
>> >>  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
>