Latest @ 
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.eclipsezone.com%2Fimages%2Fstd%2Ficons%2Fwrite_16x16.gif)
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.eclipsezone.com%2Fimages%2Fstd%2Ficons%2Fcheck_16x16.gif)
Forum Controls
Spotlight Features
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.javalobby.org%2Fimages%2Fspotlight%2Fdi_heritage.gif "The Rich Engineering Heritage Behind Dependency Injection")
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.eclipsezone.com%2Fimages%2Fstd%2Ficons%2Fwrite.gif "Reply to this Thread")
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.eclipsezone.com%2Fimages%2Fstd%2Ficons%2Fhome.gif "Home")
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.eclipsezone.com%2Fimages%2Fstd%2Ficons%2Ffolder_up.gif "Up to Thread List")
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.eclipsezone.com%2Fimages%2Fstd%2Ficons%2Fnext_thread_off.gif "No Next Thread")
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.eclipsezone.com%2Fimages%2Fstd%2Ficons%2Fnext_messages.gif "Next Page of Replies")
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.eclipsezone.com%2Fimages%2Fstd%2Ficons%2Fprev_messages_off.gif "No Previous Replies")
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.eclipsezone.com%2Fimages%2Fstd%2Ficons%2Fprev_thread_off.gif "No Previous Thread")
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.eclipsezone.com%2Fimages%2Fstd%2Ficons%2Fwrite_off.gif "No Email this thread to a friend")
You are viewing a mobilized version of this site...
View original page here
Matisse for Eclipse, no really: Matisse4MyEclipse
URL: Matisse4MyEclipse Page
At 11:54 PM on Mar 6, 2006, Riyad Kalla
wrote:
Introduction
In July a poll was run, " When will Matisse get Eclipsed? " and the poll received 297 responses:
Depending on how you interpreted the verb "Eclipsed" you could have been right if you were one of the 51 people that guessed in 7-12 months . It looks like the folks over at Genuitec, LLC , creators of MyEclipse did it; they built Matisse4MyEclipse , by porting the Matisse GUI builder from the NetBeans platform to the Eclipse platform and integrating it directly into the Java editing workflow that comes with the Eclipse SDK:
(Click for a larger version)
Platform Interoperability
The analysts at RedMonk had good coverage of this breaking news this morning here in an announcement. RedMonk points out the obvious thought on a lot of developers minds: Is JSR 198 legit? While Genuitec didn't leverage the JSR 198 spec as it is simply not a hard and fast tested API that can be utilized right now, they are using the work done on this project to investigate what it would take to change the 198 spec to make it a feasible drop in compatibility layer to allow more work like this in the future.
Background
This project may look like a science experiment to some, but it was originally intended to and has become part of the MyEclipse 5.0 Pro release package (And 4.1 shortly after EclipseCon ). The price of the Pro license will still remain the same as this is simply a feature Genuitec added as a reaction to user demand for a visual editing tool for thick clients. I think a lot of the readers can agree the general acceptance of Matisse has been outstanding in the community, and this announcement is exciting news. Let's have a look at some screenshots:
(Click for a larger version)
Future Release
Well the plan for the Genuitec group now is to debut Matisse4MyEclipse at EclipseCon and release it for the users of MyEclipse 4.1 Professional shortly there after as well as with the 5.0 Milestone build of MyEclipse around the same time. Moving forward it will be interesting to see what bee hive this stirs up between the two groups. Maybe NetBeans 6.0 will include the JDT compiler and editor, I certainly wouldn't mind that. What other cross-pollination would you want to see between these two products? Maybe the Ant build system from NetBeans in Eclipse? What about the JFluid profiler that is part of NetBeans? What about BIRT or the Debugger from Eclipse? Who knows, but in the end, again, we all end up with fantastic tools, so game on.
39 replies so far (![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.eclipsezone.com%2Fimages%2Fstd%2Ficons%2Fwrite_16x16.gif "Reply to this Thread")
Post your own)
Re: Matisse for Eclipse, no really: Matisse4MyEclipse
Very nice, congratulations.One question: how do you manage the uneditable code areas
that Matisse uses for generated code?
Re: Matisse for Eclipse, no really: Matisse4MyEclipse
That was my first question as well, I don't know at this point yet how they are handling that, but I do know they are dedicated to make this a premier part of MyEclipse so this will be maintained and enhanced moving forward continuously. I'm curious if at some point features/fixes/etc. may branch and it may take on a life of it's own.Re: Matisse for Eclipse, no really: Matisse4MyEclipse
That is a very interesting question.I just got to that from another JavaLobby post (by a NetBeans Evangalist in fact)
http://www.redmonk.com/jgovernor/archives/001350.html
Re: Matisse for Eclipse, no really: Matisse4MyEclipse
Since my post from "RedMonk" contains a vital question on how GUI Editors should work (the problem of non-editable code being one of the most important aspect in it) I decided to post it here, too:Almost more interesting is wheter this is some standalone GUI builder attempt once more, or if it is compatible with VE to some extent?
That demo does not really tell, if the components are based on SWT, Swing or both are possible?
What I am more concerned about, is that infamous .FORM file, that Matisse does not seem to go without either (as earlier NetBeans versions) while real 2-way GUI designers can do that on the fly...
Just remember what JBuilder was compared to Visual Cafe (which had this kind of metadata to a much higher extent)
Or the ongoing discussions and trends to make Java Enterprise more simple, by getting RID of all those XML metafiles.
So why (re)introduce them on the GUI ?!
With that kind of XML GUI definition, other technologies are able to create the GUI on the fly without a need of Java Classes (kind of like XUL) so GUI Builders having to constantly keep Java and XML (or binary) metafiles in sync are not making the client development much simpler or easier...
I do not mean to play the "party pooper", nor bash NetBeans vs. Eclipse.
What I saw and tried myself, Matisse is a really cool tool and "Wizard" (at least that is what I'd rather call a Rapid GUI assistant while an "Editor" should allow ALL of the code to be edited
Those who cover more than just one aspect of Java, will however know well how Sun's standards and innovations were sometimes adopted by the mass of developers or why not (especially EJB and other parts of Enterprise Java)
What is your oppinion on that? (pure "POJO" Java GUI vs. MetaData)
And could GUI editors maybe also make more use of the new Java (5+) Annotations instead of creating separate "helper" files ?
Re: Matisse for Eclipse, no really: Matisse4MyEclipse
I'm somewhat skeptical on this. First, this is still a product under development and so until we can play with the software there's not much to say about it.They say that they ported the Matisse GUI builder from Netbeans to Eclipse. This sounds weird to me. First of all, if they really did the porting how did they solve the licensing issue. Netbeans is open-source. Did they buy from Sun the rights to do this? Or was Sun willing to do it for free?
Secondly, the screenshots look to me like a feature built on top of GEF and most probably EMF. But in the first screenshot from the original post I can see the .form file in the Package Explorer.
I think that Matisse4MyEclipse is a GUI editor that looks like Matisse and probably has a smarter layout management for the controls on the form. It can also read Netbeans .form files. However, since it's built on top of GEF it is NOT a port of the original Matisse to Eclipse.
If this is really the case, then I wonder why the MyEclipse team chose this path instead of extending the Eclipse Visual Editor project. Or did they?
In any case, we need to see the product first.
Re: Matisse for Eclipse, no really: Matisse4MyEclipse
>> What is your oppinion on that? (pure "POJO" Java GUI
> vs. MetaData)
>
I think we can also immagine an alternative way. Do you know Delphi ? Delphi has an additional file too (the .dfm file, like Matisse .Form file or Avalon) but this file is not under the control of the GUI builder, insted this is generated by the component's streaming system. Every Delphi component can stream itself into a .dfm file, so the GUI builder just creates or removes components and uses the components streaming mechanism to write the .dfm file. This approach has several advantages ("two way" tools are very easy to program, form or component resources can be easilly externalized, non huge source file are needed, code errors doesn't breaks the form editor, "visual inheritance" - missed in Matisse and IMHO very usefull for UI programmers - is very easy to implement)
Best regards
sergio sette
Re: Matisse for Eclipse, no really: Matisse4MyEclipse
How does the external resource file make "visual inheritance" implementation easier? Can you explain? I'd say inheritance is more natural if the GUI is represented by a class from which you can inherit.Otherwise I think all the mentioned approaches (java based GUI with metadata, or two-way, or resource based GUI) have their pros and cons and none is clearly superior. But that could be a long debate
Re: Matisse for Eclipse, no really: Matisse4MyEclipse
> How does the external resource file make "visual> inheritance" implementation easier? Can you explain?
The form designer doesn't compiles/runs the source code, it creates the form components using the resource file and the form itself is not the "real" one but a proxy.
Inherited form are at design-time all represented by the same class (the proxy) and just the resource file are used. The Delphi streaming system directly support inheritance so the designer has nothing to do to support it.
The interesting thing in the Delphi architecture is that the form designer can directly use the streaming system to create/modify component at design-time, read and write form resource file etc. without the need to modify/parse/compile source code nor resource file (that for instance are text files).
Using this approach not just the form designer is easier to implement but the source code is much clearer and "safer". Design-time support for component (bean) writers is also powerfull
Sergio sette
Re: Matisse for Eclipse, no really: Matisse4MyEclipse
> I'm somewhat skeptical on this. First, this is still> a product under development and so until we can play
> with the software there's not much to say about it.
>
> They say that they ported the Matisse GUI builder
> from Netbeans to Eclipse. This sounds weird to me.
> First of all, if they really did the porting how did
> they solve the licensing issue. Netbeans is
> open-source. Did they buy from Sun the rights to do
> this? Or was Sun willing to do it for free?
What do you mean by selling the license? I am not sure, if you understand Open Source and all its various licenses, but unlike the "Java Licensing" by Sun NetBeans code is free and under a real Open Source license. Which is one of those that (just like Eclipse or Apache) also allows commercial extensions on top of it (so except direct copies of what is Open Source from NetBeans they could also keep parts on top of that closed)
>
> If this is really the case, then I wonder why the
> MyEclipse team chose this path instead of extending
> the Eclipse Visual Editor project. Or did they?
>
That is a very good question, which I also asked here or in another forum discussing that product.
Re: Matisse for Eclipse, no really: Matisse4MyEclipse
> What do you mean by selling the license? I am not> sure, if you understand Open Source and all its
> various licenses, but unlike the "Java Licensing" by
> Sun NetBeans code is free and under a real Open
> Source license. Which is one of those that (just like
> Eclipse or Apache) also allows commercial extensions
> on top of it (so except direct copies of what is Open
> Source from NetBeans they could also keep parts on
> top of that closed)
I happen to understand open source, I'm just not familiar with the licensing details of Netbeans (the Sun Public License). In short, as far as I understood from here http://www.netbeans.org/kb/faqs/licence.html you can link against the codebase in a closed source product, but if you change the original source code you need to publish the changes (similar to the LGPL licensing).
Re: Matisse for Eclipse, no really: Matisse4MyEclipse
> What I am more concerned about, is that infamous> .FORM file, that Matisse does not seem to go without
> either (as earlier NetBeans versions) while real
> 2-way GUI designers can do that on the fly...
Well, the fact that NetBeans has Matisse and other tools do not, and that MyEclipse is starting to emulate Matisse, suggests that the NetBeans approach can't be that bad
Re: Matisse for Eclipse, no really: Matisse4MyEclipse
>> Well, the fact that NetBeans has Matisse and other
> tools do not, and that MyEclipse is starting to
> emulate Matisse, suggests that the NetBeans approach
> can't be that bad ;-)
IMO the original and interesting thing in Matisse is the layout manager it uses, not the way the GUI Builder supports it.
Sergio Sette
Re: Matisse for Eclipse, no really: Matisse4MyEclipse
Robert,It *is* Matisse, it's not a port in the sense that it was rewritten completely from the ground up to use EMF/GEF, it's still the same animal that is in NetBeans which means form files, GroupLayout and all that jazz.
As far as why they didn't use VE, the reason was because of the communities reaction and demand for Matisse as opposed to VE. I'm sure VE is getting better with each release, but from the get-go Matisse has been the star in the gui-builder limelight and Genuitec knew they had to deliver a GUI builder in MyEclipse for their users, so they went with the more intuitive one that would help developers get from 0-60 fastest. True there is no SWT support out the door, but AFAIK VE still doesn't support FormLayout for SWT anyway, so it's not like it's a dream come true for GUI builder either (I'm personally not much of a fan and on non-windows platforms it's a little less than impressive).
Re: Matisse for Eclipse, no really: Matisse4MyEclipse
> Robert,> It *is* Matisse, it's not a port in the sense that it
> was rewritten completely from the ground up to use
> EMF/GEF, it's still the same animal that is in
> NetBeans which means form files, GroupLayout and all
> that jazz.
Thanks for the info, Riyad. So it uses the SWT_AWT bridge and does not work in MacOS.