Hello,
>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.
There probably is a way in windows as many applications do it but it will probably require some JNI.
On linux im not sure, its probabley in gnome and kde somewhere.
if only java offered a method that achives this in a cross platform manner (handles this stuff by its own)
>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,
>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.
>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)
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
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> wrote:
Hi Nick,
You are absolutely. I'll do it.
yves -----Original Message-----
From: ve-dev-bounces@xxxxxxxxxxx [mailto: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> 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
> 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
_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev Checked by AVG - 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
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
