Re: [ve-dev] VE 1.5 development plan

[yves.yang@xxxxxxxxxxx]

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
>