Re: [ve-dev] VE 1.5 development plan

[yves.yang@xxxxxxxxxxx]

> So as i understood, you are basiclly going to ditch swing in java source
> code entirely.
> Will you still make in importer and exporter for gui in java source files?

Current Version supports already Java source files. We'll keep it of
course. It is about a new module/subproject.

yves
> On Wed, Jul 8, 2009 at 1:21 PM, <yves.yang@xxxxxxxxxxx> wrote:
>
>> About XWT, some useful links:
>>
>>
>> http://dev.eclipse.org/blogs/yvesyang/2008/11/28/xwt-declarative-ui-designed-for-eclipse/
>> http://wiki.eclipse.org/E4/DeclarativeUI/XWT
>> http://wiki.eclipse.org/E4/XWT/Running_the_demos
>>
>> yves
>>  >> 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
>> >>
>> >
>> >
>> > _______________________________________________
>> > 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
>