Please stop pimping Matisse/GroupLayout

[Ernie MacNamara]

Guys, love the show. But please, stop singing the praises of Matisse
and GroupLayout whenver GUI development comes up. Look, I love
Netbeans and user it every day. Matisse is not the best it's not even
the easiest way of putting controls on the screen. Instead, replace
every mention of Matisse with MigLayout. It is the one and only layout
manager that any person developing a GUI should be using.

Thanks!

Ernie

[TorNorbye]

GroupLayout by itself is extremely hard to use. BUT, it was built with
toolability in mind - and when used with NetBeans it works well.

I don't think anyone developing UIs should be writing layout code by
hand.

Perhaps MigLayout works with other IDEs - I don't use IntelliJ so I
couldn't say for sure - but the reason I and others like GroupLayout
so much is not because it's an elegant constraint system (it might
well be, I don't know) but because it's really easy to use to bang out
dialogs quickly which both have good baseline alignment as well as
proper resize behavior (e.g. textfields stretch by default, radio
buttons don't, etc.)

-- Tor

[Jess Holle]

Of course your response really argues for a Matisse-like tool for JavaFX -- one that a corporate developer would use for an internal app.

It seems like the design tool is really not this.  It might double as this -- but only if someone puts on that hat and ensures it really makes sense as such, has good drag-and-drop layout management of complex forms, etc.

[Peter Becker]

TorNorbye wrote:
> I don't think anyone developing UIs should be writing layout code by
> hand.
>

I tend to disagree. Maybe it is my incompetence with the tools, but I
like the full control in nesting and grouping components into related
elements. Maybe I change things around too much -- any large structural
change always seems a pain in GUI editors. Maybe I'm too much of an
IDE-Dick and don't like the fact of relying on a particular tool. But
while I try GUI builders every now and then, I always end up writing the
code myself in the end. GUI builders still feel too much of a one-way
street to me, nice for prototyping, but nothing for code I'd like to
maintain in the long run.

But it might be just my personal attitude.

Peter

[Christian Catchpole]

I think though the comment was made though that that GUI builders
actually have to work properly, otherwise you end up getting
frustrated and short-circuiting them. I know I have on many
occasions. :)

[Mikael Grev]

Hi All,

I am biased.

The usages for Mattise/GroupLayout and MigLayout are very different
and they should not be compared directly. But, manual coding with
MigLayout and GUI coding using Matisse/GroupLayout (henceforth
Mattise) can.

Before I created MigLayout I did a few GUIs with Matisse. You can for
instance see the result in the iCal demo for MiGCalendar.com .
Unfortunately I didn't like it much. Neither do I like the Sun
provided layout managers, so I created my own (NIH syndrome maybe..).
Matisse has the very common problem of the lacking last 10% (and the
built in LayoutManagers have the more uncommon problem of lacking the
last 90% ;) I am very quality focused and every pixel must be right
where it's supposed to be and I will redo the GUI if I come up with a
better one. These two personal properties (intentional properties-for-
Java plug) is what is making me lean towards manually coded GUIs
rather than using Matisse.

With Matisse you won't get exact control over the layout. If you are
fine with its defaults or don't care exactly what happens if you
resize the GUI you might be OK with this, but I found that the GUIs I
wanted to create wasn't i the best interest of Matisse.. Also, if you
want to move components around Matisse gets crazy. The crazyness is
natural since in Matisse components are constrained to each other
rather than to a grid or layout algorithm. Still, it is very
troublesome if you want to change your GUI a lot, which I do.

MigLayout approach the layout problem from the other side. It makes it
very easy to code GUI by hand, BUT, and this is the difference
compared to the built in ones, if you want total control it gives you
that too. This means that you can get started quickly and can just
slap a few components to the GUI with few extra characters, and later,
when you want to tweak the GUI to get every white space and grow/shink
behaviour just right, you just add the appropriate constraints. No
need to change LayoutManager mid stream. Before MigLayout this meant
that I always ended up using GridBagLayout in the end after starting
out with FlowLayout or something.

Another thing with Matisse is that it locks you into tools that
support Matisse/GroupLayout since it is virtually impossible to code,
or recode, it by hand. If you are sure that all your team members will
always use NetBeans this isn't a problem though.

Cheers,
Mikael Grev

[Dick Wall]

Hi Ernie

This has spawned an interesting thread and I appreciate many of the
arguments, particularly about the fact that this may make you
dependent on netbeans. I would counter that only by saying that if you
use the fancy GUI tools in visual studio for .NET you are going to be
similarly trapped I believe.

I will still say though that for me, someone who knows next to nothing
about GUI creation and with very little interest in the subject,
Matisse is a perfect way to slap something acceptable together
incredibly quickly (I can re-create the jFlubber GUI in under 5
minutes, something I absolutely could not do with any kind of code
based approach). Matisse is obviously a bit of an evolutionary dead-
end now with JavaFX in the picture, but I appreciate environments that
give me this kind of GUI constructor kit (like FlexBuilder for
example) and get me back to the stuff that I am really interested in
writing.

So, all in all, good points, but I totally stick by what I said.
Perhaps Matisse itself is no longer the answer, since the future
appears to be going elsewhere, but right now, if I want to slap
together a simple GUI in java super-quickly, I am still going to use
Matisse until something better (for me) comes along.

Cheers

Dick

On Jul 23, 5:06 pm, Ernie MacNamara <macna...@gmail.com> wrote:

[Mikael Grev]

Dick, I think the NetBeans dependency blurb was my wording, not
Ernie's, so I guess I'll be the one to defend it. :)

> Hi Ernie
>
> This has spawned an interesting thread and I appreciate many of the
> arguments, particularly about the fact that this may make you
> dependent on netbeans. I would counter that only by saying that if you
> use the fancy GUI tools in visual studio for .NET you are going to be
> similarly trapped I believe.

Yes, but if you are referring to Visual Studio it is the standard and
thus it's much less of a problem in .NET than for Java, where there
are several IDEs. Also, VS is not that good, it's just very simple and
pragmatic and

As for the rest of your arguments I agree wholeheartedly, you fall
firmly into the usage category that benefits from Matisse and the
simplicity it brings.

Cheers,
Mikael Grev

[Jess Holle]

Whether or not it is Matisse, I'd expect a similar GUI layout tool for developers for JavaFX.  Corporate intranet application types have complex forms, etc, to layout that they just want to plop together and run -- they don't even have access to Illustrator, Photoshop, etc, etc, much less know how to use them.  Easy, flexible, and maintainable GUI component layout is critical -- whether or not you throw an "FX" at the end of things.

[Fabrizio Giudici]

TorNorbye wrote:
> GroupLayout by itself is extremely hard to use. BUT, it was built with
> toolability in mind - and when used with NetBeans it works well.
>
> I don't think anyone developing UIs should be writing layout code by
> hand.
>

My personal experience is: I had a great enthusiasm when I first faced
with UI design tools, and it was circa 1997/1998 after hearing some
presentation about VisualCafe. After using it for a few months, I
completely gave up with visual designers and stayed with code for
several years. Even JBuilder didn't satisfy me (in spite of being a
great tool for that time in other respects) and every time I tried a new
visual designer I backed off after a few days. I had a big negative bias
when Matisse come out, but I later changed my mind and I'm fine with it.
I think it's mostly subjective, but GUIs are a visual thing and I find
that the most natural way to design them is with a visual tool. I think
that the programmatic approach is still popular because we are
programmers, but as the melting pot with visual designers that is being
created by Flex, JavaFX and Silverlight grews, the visual approach will
get more and more popular.

BTW, I'm pretty fine with creating GUIs with Matisse that resize
themselves when needed. The tool has got sometimes rough edges, but with
a bit of experience you manage them perfectly. I can't see the missing
10% effect with Matisse, and I'd like whether people arguing about it
would elaborate more with some example (it might be that they design
much more complex GUIs than me).

If there's a critic to Matisse is that, if used in brainless mode, it
tends to generate bloated controller code in the same class (e.g. by
generating listeners by double clicking on a button or such). But it's
just a matter of discipline of the programmer - as usual, for having a
good design.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
Fabrizio...@tidalwave.it - mobile: +39 348.150.6941

[Casper Bang]

> I would counter that only by saying that if you
> use the fancy GUI tools in visual studio for .NET you are going to be
> similarly trapped I believe.

The .NET languages are driven by "programmer usability" so you have a
very strong de-facto standard helped along with language features
(i.e. partial classes, as oppose to the locked-lines mess in
NetBeans). From what I've experienced, much of GroupLayout (apart from
the chaining nature of the API and the use of XML files) borrows
heavily from .NET. That's fine of course, we never had a good WYSIWYG
in Java before and most people welcome a good prototyping/RAD tool.

However, in my experiences, GroupLayout fails later in the maintenance
stage, where Matisse is all of a sudden unable to render sufficiently
complex layouts and you have to go behind NetBeans back to be able to
refactor, clean and fix stuff which is not always possible. I don't
know what the current status of JDeveloper is, but for a long while
they where quite mad at Sun for going this non-standard way so it
seems NetBeans is, willingly or not, slowly talking the same path as
Visual Studio in certain aspects.

/Casper

[TorNorbye]

Hi Fabrizio,
I had the same reaction to the code generated by Matisse for event
listeners -- too many innerclasses. But they added an option you can
set on the form itself (select the top-level designed form, and look
at its properties) which lets you control the code generation. You can
choose between the default (one innerclass per interface), having a
single action dispatch class (my preferred approach), and having the
form itself directly implement the listener interfaces (which is what
I used to do, but this has the disadvantage of leaking your
implementation through to others and possibly accidentally overriding
inherited methods. Oh @New, where are you?)

-- Tor

On Jul 24, 10:42 am, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:

> Fabrizio.Giud...@tidalwave.it - mobile: +39 348.150.6941

[Wayne Meissner]

On Jul 25, 2:22 am, Dick Wall <dickw...@gmail.com> wrote:
> incredibly quickly (I can re-create the jFlubber GUI in under 5
> minutes, something I absolutely could not do with any kind of code
> based approach). Matisse is obviously a bit of an evolutionary dead-
> end now with JavaFX in the picture, but I appreciate environments that
> give me this kind of GUI constructor kit (like FlexBuilder for
> example) and get me back to the stuff that I am really interested in
> writing.

The ability to quickly create a simple gui for an app was what sold me
on Netbeans 5.0. One place I was working wanted to create an
application, and wanted a proof-of-concept up and running quickly. It
was probably less than two hours from not having used netbeans before
to having a prototype running with dummy data that had a real gui on
it. Sure, hand coding the UI would have probably produced technically
nicer code, and have been a better gui, but there is no way I could
have done it in the same time frame.

On the other hand, if you are hand-coding your UI, then MigLayout
seems to be the only sane one out there.

[Chas Emerick]

On Jul 24, 12:22 pm, Dick Wall <dickw...@gmail.com> wrote:
> Matisse is obviously a bit of an evolutionary dead-
> end now with JavaFX in the picture, but I appreciate environments that
> give me this kind of GUI constructor kit (like FlexBuilder for
> example) and get me back to the stuff that I am really interested in
> writing.

I suppose I'll be the one to say it -- JavaFX doesn't speak at all to
our requirements or use-cases, while Swing did and does. Given that,
Matisse remains part of our core toolset, and none of the murmurings
around the JavaFX "designer tool" have given me any hope that that
will change anytime soon.

I'm certain I'm not the only one with that perspective, so I'd hope
that we could stay away from stuff like saying Matisse/Swing/et al.
are 'evolutionary dead-ends'. UI is all about getting pixels on the
screen in the way that will achieve the customers' goals -- nothing
more, nothing less -- and given that JavaFX is just another layer on
top of AWT, I think everyone would be better served by not thinking
about the former as some wholly-new revolutionary technology.

Cheers,

- Chas

[Carl]

...but what about the binding?

Admittedly I have not yet read this entire thread but when I see the
code by hand vs. "code" with an IDE and binding is (specifically)
addressed, it's the first thing I wonder about.

We use NetBeans/Matisse as well as binding (JSR-295). We aim to
"write" little UI code letting the IDE do the work for us when
possible. We have found ourselves writing non-visual components to
which we bind using the IDE ending up with less boilerplate code to
read.

The idea of hand writing the GUI and the required binding is not very
appealing to me.

Carl

[Jess Holle]

I think JavaFX could and probably should speak to the requirements and use cases currently addressed by Swing.

I'd agree that it currently doesn't, however -- it does not provide enough components, no layout appropriate for complex forms, nor a GUI layout tool oriented at complex layout of components rather than working with designer assets.

[Mikael Grev]

The only sensible thing they can do for JavaFX is to add:

1) One kick-ass designer that is better than Matisse
2) One kick-ass manual layout manager
3) An easy and predictable way to move back and forth between 1 and 2.

Cheers,
Mikael Grev

[Jess Holle]

Mikael Grev wrote:

The only sensible thing they can do for JavaFX is to add:

1) One kick-ass designer that is better than Matisse
2) One kick-ass manual layout manager
3) An easy and predictable way to move back and forth between 1 and 2.
  

Plus

4) A sufficiently broad component set for business apps (table, tree, combobox, etc)

At that point (and only then) will JavaFX be ready to take over in corporate intranet use cases.

--
Jess Holle

[Joshua Marinacci]

Have you looked into MigLayout? It's pretty sweet.

[TorNorbye]

On Jul 26, 6:59 am, Chas Emerick <cemer...@snowtide.com> wrote:
>  UI is all about getting pixels on the
> screen in the way that will achieve the customers' goals -- nothing
> more, nothing less -- and given that JavaFX is just another layer on
> top of AWT, I think everyone would be better served by not thinking
> about the former as some wholly-new revolutionary technology.

JavaFX isn't just another layer on top of AWT; for example on mobile
there is no AWT in the stack, and I think it's public knowledge that
we are building some alternate graphics stacks below FX.

-- Tor

[Casper Bang]

lol Are you asking Mikael Grev whether he has looked into MigLayout,
or am I just reading this wrong?

[Chas Emerick]

Many apologies. I only keep up with JavaFX happenings from a
distance, so the nuance sometimes gets away from me.

That said, maybe it's more appropriate to say that JavaFX *on the
desktop* is just another layer on AWT? And it probably won't come as
a shock that we're entirely uninterested in mobile platforms.

...but, "building some alternate graphics stacks below FX"? There's
that sinking feeling again, knowing that so much is going into tech
that we'll never have any use for, and that less and less is going
into anything we'll see any benefit from (being users of NB RCP,
Swing, AWT, processing.org, etc).

- Chas

[Chas Emerick]

On Jul 27, 9:05 am, Jess Holle <je...@ptc.com> wrote:
> Mikael Grev wrote:
> > The only sensible thing they can do for JavaFX is to add:
>
> > 1) One kick-ass designer that is better than Matisse
> > 2) One kick-ass manual layout manager
> > 3) An easy and predictable way to move back and forth between 1 and 2.
>
> Plus
>
>     4) A sufficiently broad component set for business apps (table,
>     tree, combobox, etc)
>
> At that point (and only then) will JavaFX be ready to take over in
> corporate intranet use cases.

Plus

5) well-defined APIs accessible from non-Java and non-JavaFX
languages (Clojure's our bag, but JRuby, Jython, Scala, Fan, et al.
should be able to join in), because, really, who's writing in Java-
esque languages anymore? ;-)

- Chas

[Fabrizio Giudici]

Chas Emerick wrote:

> That said, maybe it's more appropriate to say that JavaFX *on the
> desktop* is just another layer on AWT?  And it probably won't come as
>  a shock that we're entirely uninterested in mobile platforms.

I don't think it's appropriate either :-) JavaFX is another layer on Java2D, but all of its components, AFAIK, don't depend either on AWT or Swing.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."

[Joshua Marinacci]

JavaFX provides a new language, a new media stack, and a new scenegraph. While it is built on top of the Java runtime I wouldn't use the word 'just'j any more than I'd say that JRuby is 'just a library' or Eclipse. JavaFX adds quite a lot.  It does currently use Java2D underneath but that is an implementation detail. We have been very careful not to expose Java2D because our long term plan is to offer JavaFX as a unified platform across many OSes and environments, many of which do not have AWT or Java2D.  For example, the version of JavaFX built on top of JavaME's CDC stack does not have Java2D underneath it.

[Chas Emerick]

On Jul 28, 9:07 am, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:

> Chas Emerick wrote:
> > That said, maybe it's more appropriate to say that JavaFX *on the
> > desktop* is just another layer on AWT? And it probably won't come as
> > a shock that we're entirely uninterested in mobile platforms.
>
> I don't think it's appropriate either :-) JavaFX is another layer on
> Java2D, but all of its components, AFAIK, don't depend either on AWT or
> Swing.

It's funny, that's actually what I meant -- I've long since equated
AWT with Java2D, as I've not used an AWT widget directly in many
years. :-)

- Chas