> 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 <*
