Layout Managers

[Luc The Perverse]

So I'm reading through the Teach Yourself Java 2 In 21 Days, and it says
that defining dialog items in terms of pixels and locations is highly
deprecated in favor of layout managers.

But . . . then dialog dimensions, graphics etc. everything else is handled
in pixels.

I was wondering what these problems that are going to arise are.

I will probably end up using layout managers anyway, it is convenient how
they work with resized dialogs.

I would like to find a tool which will assist me in making dialogs though.
I had netbeans, and when I try to make even a simple project I get this huge
multidirectory . . .thing.

I would like an app that would help me make my layout and then I could cut
and paste it into my application. If one does not exist, I imagine I could
easily write one. After all, it's not the variables I'm not understanding,
it is how to get them working well together that I have a problem with

 

[Benji]

<snip>

If you're looking for a tool to make nice looking GUIs, netbeans 5.0
(with the matisse layout manager) is the best way to go. However, if
what you really want to do is use the GUI to learn how to use the
layouts, I'm sure that others would work. What I've done is used
netbeans to play around with how stuff gets laid out with certain layout
managers, and then translate that knowledge to writing the code manually.

There aren't really any IDEs that assist in visual development that make
it easy for you to understand the generated code or hand-edit it.

I would recommend downloading the new netbeans beta. It's quite sexy.

 

[Thomas G. Marshall]

Benji coughed up:

If you're looking for a tool to make nice looking GUIs, netbeans 5.0
(with the matisse layout manager) is the best way to go. However, if
what you really want to do is use the GUI to learn how to use the
layouts, I'm sure that others would work. What I've done is used
netbeans to play around with how stuff gets laid out with certain layout
managers, and then translate that knowledge to writing the code manually.

My suggestion to the OP is nearly opposite: Force yourself into writing and
designing the GUI manually, in order to learn and understand the layout
managers. Once you've accomplished that, *then* you are qualified to handle
the crufty looking code that a GUI generator will make.

There aren't really any IDEs that assist in visual development that make
it easy for you to understand the generated code or hand-edit it.

I would recommend downloading the new netbeans beta. It's quite sexy.

Is there anything about it that stands apart from eclipse ($0) or Intelij
IDEA ($mondo) ?

 

[Luc The Perverse]

Benji coughed up:

My suggestion to the OP is nearly opposite: Force yourself into writing
and designing the GUI manually, in order to learn and understand the
layout managers. Once you've accomplished that, *then* you are qualified
to handle the crufty looking code that a GUI generator will make.

I suppose this is kinda where I am coming from. But it is the latency
between writing, compiling, running, viewing and then re-editing that
bothers me.

I believe that if I write, from scratch a tool which allows me to use my
rudimentary knowledge of Java GUIs to design them the way that I like, I
will learn it as well or better than if I had done it "the old fashioned
way".

What I had an issue with was having no idea what NetBeans was doing.

-LTP

 

[Roedy Green]

So I'm reading through the Teach Yourself Java 2 In 21 Days, and it says
that defining dialog items in terms of pixels and locations is highly
deprecated in favor of layout managers.

But . . . then dialog dimensions, graphics etc. everything else is handled
in pixels.

I was wondering what these problems that are going to arise are.

I will probably end up using layout managers anyway, it is convenient how
they work with resized dialogs.

I would like to find a tool which will assist me in making dialogs though.
I had netbeans, and when I try to make even a simple project I get this huge
multidirectory . . .thing.

I would like an app that would help me make my layout and then I could cut
and paste it into my application. If one does not exist, I imagine I could
easily write one. After all, it's not the variables I'm not understanding,
it is how to get them working well together that I have a problem with

Java is in for trouble down the road. For now, layout managers let
you write code without detailed pixels, but they still calculate
everything in pixels.

Recent LCDs use a hardware resolution between 86dpi and 147dpi, only a
few LCDs use a resolution around 204dpi (Toshiba, IBM).

The problem is ordinary Java apps look too small on these high
resolution screens, because Java apps are constructed in pixels, not
points or inches the way PostScript is. A program that draws an icon
32 pixels high looks huge on a low res screen, but shrinks down to a
mite on an ultra highres screen.

Quoting from my resolution essay where I propose doing layouts in a
new unit, the VU.

"VU. Visual Units. This is my personal proposal. One VU is the
vertical distance between two lines of type the user can comfortably
read. It is the leading of the user's preferred body font. What it
corresponds to in cm or pixels depends on many factors including
visual acuity, personal preference and screen resolution. My idea is
you would design in visual units, and the user would configure the
value of a visual unit in pixels using a system wide slider in the
control panel. The definition would then by used by the OS and all
apps. The user could adjust it an any time, causing a system wide
revalidate. The GUI and layouts would still work in pixels at the low
level, but for various higher level methods you could specify
co-ordinates and sizes in terms of a VU grid, or perhaps in terms of
integral MVUs, thousandths of a VU. The notion could be used both for
designing screen layouts and printed output easily readable by the
user."


For more discussion of the issues you are raising see
http://mindprod.com/jgloss/layout.html
http://mindprod.com/jgloss/resolution.html
http://mindprod.com/jgloss/coordinates.html

 

[Thomas G. Marshall]

Luc The Perverse coughed up:

"Thomas G. Marshall"


I suppose this is kinda where I am coming from. But it is the
latency between writing, compiling, running, viewing and then
re-editing that bothers me.

I believe that if I write, from scratch a tool which allows me to use
my rudimentary knowledge of Java GUIs to design them the way that I
like, I will learn it as well or better than if I had done it "the
old fashioned way".

What I had an issue with was having no idea what NetBeans was doing.

This logic bothers me a little. You may have to trust me on this one.
Writing a GUI generation tool is fine in its own right, but in terms of
learning the GUI?

By the time you've understood the GUI to build a tool, you've understood
well the GUI. It seems like the order of things is reversed.

I would suggest building /any other app/ in order to learn the GUI.

 

[Thomas G. Marshall]

Roedy Green coughed up:

....[rip]...

Quoting from my resolution essay where I propose doing layouts in a
new unit, the VU.

"VU. Visual Units. This is my personal proposal. One VU is the
vertical distance between two lines of type the user can comfortably
read. It is the leading of the user's preferred body font. What it
corresponds to in cm or pixels depends on many factors including
visual acuity, personal preference and screen resolution. My idea is
you would design in visual units, and the user would configure the
value of a visual unit in pixels using a system wide slider in the
control panel. The definition would then by used by the OS and all
apps. The user could adjust it an any time, causing a system wide
revalidate. The GUI and layouts would still work in pixels at the low
level, but for various higher level methods you could specify
co-ordinates and sizes in terms of a VU grid, or perhaps in terms of
integral MVUs, thousandths of a VU. The notion could be used both for
designing screen layouts and printed output easily readable by the
user."

It is patently ridiculous that in this day and age we are not specifying
nearly everything in resolution independant formalisms. Points, inches,
centimeters, lightyears or hydrogen atom width.

Display postscript (no and not sun news) was a perfect solution to this: it
drove the NeXT machines perfectly.

The slider you are talking about might as well be a general purpose scale.
Even the thin lines and "individual pixels" of an application (or what the
application thinks are thin lines and individual pixels) can be managed far
better when drawn appropriately in the first place. Far better than any AA
or low end sub sampling or Box resizing.

 

[Thomas G. Marshall]

Benji coughed up:

If you're looking for a tool to make nice looking GUIs, netbeans 5.0
(with the matisse layout manager) is the best way to go. However, if
what you really want to do is use the GUI to learn how to use the
layouts, I'm sure that others would work. What I've done is used
netbeans to play around with how stuff gets laid out with certain
layout managers, and then translate that knowledge to writing the
code manually.

There aren't really any IDEs that assist in visual development that
make it easy for you to understand the generated code or hand-edit it.

I've investigated such things in the past, and unless something's changed in
the last few years, maintenance of GUI code over many cycles of auto-code
generation and tweaking of such code approaches the impossible. It is for
this reason that nearly everyplace I've been, manual construction has been
favored.

 

[Luc The Perverse]

Roedy Green coughed up:

...[rip]...

Quoting from my resolution essay where I propose doing layouts in a
new unit, the VU.

"VU. Visual Units. This is my personal proposal. One VU is the
vertical distance between two lines of type the user can comfortably
read. It is the leading of the user's preferred body font. What it
corresponds to in cm or pixels depends on many factors including
visual acuity, personal preference and screen resolution. My idea is
you would design in visual units, and the user would configure the
value of a visual unit in pixels using a system wide slider in the
control panel. The definition would then by used by the OS and all
apps. The user could adjust it an any time, causing a system wide
revalidate. The GUI and layouts would still work in pixels at the low
level, but for various higher level methods you could specify
co-ordinates and sizes in terms of a VU grid, or perhaps in terms of
integral MVUs, thousandths of a VU. The notion could be used both for
designing screen layouts and printed output easily readable by the
user."

It is patently ridiculous that in this day and age we are not specifying
nearly everything in resolution independant formalisms. Points, inches,
centimeters, lightyears or hydrogen atom width.

Display postscript (no and not sun news) was a perfect solution to this:
it drove the NeXT machines perfectly.

The slider you are talking about might as well be a general purpose scale.
Even the thin lines and "individual pixels" of an application (or what the
application thinks are thin lines and individual pixels) can be managed
far better when drawn appropriately in the first place. Far better than
any AA or low end sub sampling or Box resizing.

I imagine as legacy applications start becoming unrunnable, OS (and possibly
JVM) options will exist that allow pixels to be multiplied by some factor in
an emulation mode, to alleviate the problem

 

[Luc The Perverse]

Luc The Perverse coughed up:

This logic bothers me a little. You may have to trust me on this one.
Writing a GUI generation tool is fine in its own right, but in terms of
learning the GUI?

By the time you've understood the GUI to build a tool, you've understood
well the GUI. It seems like the order of things is reversed.

I would suggest building /any other app/ in order to learn the GUI.

Back in high school I learned chemistry best by writing calculator apps to
do my homework for me. Granted it would take 4 times as long to write the
app as to just do it, but by the time I was done I had concept mastery.

There is nothing about GUI generation which I don't understand in theory, or
could not understand through simple reading. It is the usage and
application that I have an issue with. If there is something which I have
veritable difficulty understanding, then I will require more or less concept
mastery to implement enough to make a dynamic adjustable GUI editor for that
control, something not required in the world of cut and paste for
programming for simple one time usage

So, if the only thing left to learn is how to tweak the corresponding
numbers to make the dialog "look" right, then a tool which handles it for me
transparently without the middle compilation step, then I would find this
tool quite useful.

You said yourself, "By the time you've understood the GUI to build a tool,
you've understood well the GUI." I agree And learning the GUI was all
I ever wanted to accomplish!

Perhaps after I have played around with making even half a dozen GUIs I will
find it generally intuitive, and no longer need the tool, I can write the
code once and have it work great; but I do not believe that this would
invalidate building the application as a learning tool.

Sorry - I guess we're just going to have to disagree on this one

 

[Roedy Green]

It is for
this reason that nearly everyplace I've been, manual construction has been
favored.

I used GUI generated code early on my career as a learning tool, just
create starting point. The problem was , as soon as I hand customised
it even the tiniest bit I could no longer use the gui tools. The code
was uncommented, and somewhat weird, not designed for legibility.

I later used stompers, -- home brew templates written in Java, that
would generate idiomatic code. These are mainly useful for initially
writing the code. One advantage of this technique is you can always
customise it. Further the boss need never know how you wrote the pages
of perfectly consistent code. From his point of view the results are
even more maintainable than if you did them by hand.

 

[Thomas G. Marshall]

Luc The Perverse coughed up:

"Thomas G. Marshall"

Luc The Perverse coughed up:

This logic bothers me a little. You may have to trust me on this one.
Writing a GUI generation tool is fine in its own right, but in terms of
learning the GUI?

By the time you've understood the GUI to build a tool, you've understood
well the GUI. It seems like the order of things is reversed.

I would suggest building /any other app/ in order to learn the GUI.

....[rip]...

There is nothing about GUI generation which I don't understand in theory,
or
could not understand through simple reading. It is the usage and
application that I have an issue with.

You're still way off the mark.

You learn how to build houses by building houses, not by creating the tools
to build the house.

You will need to understand the usage and application of GUI's *BEFORE* you
create an editor for them. True, you could attempt such a tool, without
understanding what direction you're going in, but the part of it that you
teach you GUI mastery would be the part of the application /itself/ that
requires the GUI, not the GUI generation part. The construction of this
"GUI creator's GUI" would be hampered by needs overall of your application
(what a GUI requires), which it appears you know almost nothing about.

In other words, you don't know what you don't know here.

For example, GUI's in java are not thread-safe, and everything must be
altered and/or otherwise mucked with in a single special thread. Further,
GUI's report back information using special call-backs called "listeners",
which are special implemented interfaces. Still further, GUI's require an
understanding of two /simultaneous/ hierarchies: inheritance and container.
And even further than that, GUI's respond to a cascading set of events that
flow between container and component all the way across the container
hierarchy.

You would gain an understanding of all these by creating, say, a newsreader.
But to attempt a GUI generation tool would only slow you down.






....[rip]...

 

[Roedy Green]

I imagine as legacy applications start becoming unrunnable, OS (and possibly
JVM) options will exist that allow pixels to be multiplied by some factor in
an emulation mode, to alleviate the problem

But to properly emulate the Java program, the only scales that would
not have artifacts would be powers of two. Java would have to
internally work with virtual pixels. It would be even less direct than
the DOS character REGEN buffer emulation. Yuchh!

Much better to head the problem off at the pass and start writing
higher level scaleable code.

 

[Roedy Green]

You said yourself, "By the time you've understood the GUI to build a tool,
you've understood well the GUI." I agree And learning the GUI was all
I ever wanted to accomplish!

What I think the next stage in Java evolution will be something
analogous to what CSS did for HTML and L&F did for decoration.

Your code will be concerned with deciding which data should be
displayed and its relative importance. Styles "Sheets" will
intelligently do layouts.

Features I would expect:

Ability to format standard demographic classes, adjusting for country,
including names, phone numbers. email addresses , web addresses ,
zips, countries ,streets, etc.

The LayoutStyle hides not essential information when the screen real
estate is too small.

The LayoutStyle handles labelling components when there is room and
providing tooltip explantions of editing rules, bounds, and field
specifics.

The LayoutStyle can set up scrolling displays, scrolling fields,
smaller fonts and any other trick do deal with trying to display data
in less space than optimal.

The layout will be interactive, so that you can get at other
information there was not enough room to fully display, with any
corresponding application code.

A layout might smoothly revalidate for every new set of data, so as
not to waste whitespace at the end of fields. In some LayoutStyles the
visual experience will be sinuous, as if watching the display on the
body of an octopus.

Eye-direction monitoring will provide clues to the Layout Style just
what on screen you consider important and smoothly enhance or expand
that.

 

[Luc The Perverse]

But to properly emulate the Java program, the only scales that would
not have artifacts would be powers of two. Java would have to
internally work with virtual pixels. It would be even less direct than
the DOS character REGEN buffer emulation. Yuchh!

Much better to head the problem off at the pass and start writing
higher level scaleable code.

I don't think it is going to happen until the problem is manifest.

I still run installer programs who default from a hard coded string (in
windows) to c:\program files\ even though I don't have the letter C assigned
to a partition. Then they complain about their not being enough room.

If the problem is serious enough, video cards will start to be made with
virtual smaller resolution emulation modes, which will handle in hardware
the overhead of stretching the application.

While I agree with you that it should be fixed, Sun will not force something
on programmers which will anger so many of them

 

[Thomas G. Marshall]

Roedy Green coughed up:

But to properly emulate the Java program, the only scales that would
not have artifacts would be powers of two.

No, I think you mean "integer multiples" here. Pixels, for example, could
easily be drawn 3:1. But it's still the wrong solution.

This is the solution already in place when you change monitor resolutions.
Effectively, the output is semi-uniformly scaled (to fit your screen).

The problem with this is multi-fold, but Postscript, for example allows a
line to be widened to whatever width (in real world units) is asked for. A
scaled pixel set as is suggested would only keep the same number of stairs
in a stair-cased line, but make the stairs fatter.

*And*, the artifacts you speak of would only increase like crazy if they
were non-integer multiples in the pixel fattening scheme. That is, an AA
line in postscript will draw better than an AA line made from fattening
pixels 2.5:1.

Java would have to
internally work with virtual pixels.

All apps more or less already do. Images, for example, are objects (virtual
pixels) that only get blitted to the screen by other java objects. Such
objects would "know" what to do. But again, the wrong solution.

....[rip]...

 

[Luc The Perverse]

Luc The Perverse coughed up:

"Thomas G. Marshall"

Luc The Perverse coughed up:
"Thomas G. Marshall"
message Benji coughed up:
Luc The Perverse, while high on whiteboard markers, wrote:
<snip>

If you're looking for a tool to make nice looking GUIs, netbeans 5.0
(with the matisse layout manager) is the best way to go. However,
if what you really want to do is use the GUI to learn how to use the
layouts, I'm sure that others would work. What I've done is used
netbeans to play around with how stuff gets laid out with certain
layout managers, and then translate that knowledge to writing the
code manually.

My suggestion to the OP is nearly opposite: Force yourself into
writing and designing the GUI manually, in order to learn and
understand the layout managers. Once you've accomplished that,
*then* you are qualified to handle the crufty looking code that a
GUI generator will make.

I suppose this is kinda where I am coming from. But it is the
latency between writing, compiling, running, viewing and then
re-editing that bothers me.

I believe that if I write, from scratch a tool which allows me to use
my rudimentary knowledge of Java GUIs to design them the way that I
like, I will learn it as well or better than if I had done it "the
old fashioned way".

What I had an issue with was having no idea what NetBeans was doing.

This logic bothers me a little. You may have to trust me on this one.
Writing a GUI generation tool is fine in its own right, but in terms of
learning the GUI?

By the time you've understood the GUI to build a tool, you've understood
well the GUI. It seems like the order of things is reversed.

I would suggest building /any other app/ in order to learn the GUI.

...[rip]...

There is nothing about GUI generation which I don't understand in theory,
or
could not understand through simple reading. It is the usage and
application that I have an issue with.

You're still way off the mark.

You learn how to build houses by building houses, not by creating the
tools to build the house.

You will need to understand the usage and application of GUI's *BEFORE*
you create an editor for them. True, you could attempt such a tool,
without understanding what direction you're going in, but the part of it
that you teach you GUI mastery would be the part of the application
/itself/ that requires the GUI, not the GUI generation part. The
construction of this "GUI creator's GUI" would be hampered by needs
overall of your application (what a GUI requires), which it appears you
know almost nothing about.

In other words, you don't know what you don't know here.

For example, GUI's in java are not thread-safe, and everything must be
altered and/or otherwise mucked with in a single special thread. Further,
GUI's report back information using special call-backs called "listeners",
which are special implemented interfaces. Still further, GUI's require an
understanding of two /simultaneous/ hierarchies: inheritance and
container. And even further than that, GUI's respond to a cascading set of
events that flow between container and component all the way across the
container hierarchy.

You would gain an understanding of all these by creating, say, a
newsreader. But to attempt a GUI generation tool would only slow you down.

Aha! I have identified the problem as a miscommunication.

Your definition of a GUI generation tool exceeds, by at least an order of
magnitude, that which I had intended, originally, on creating.

Of course now, I am embarassed to try to explain my simplistic
implementation.

 

[Roedy Green]

I don't think it is going to happen until the problem is manifest.

It is beginning to show up with the high end LCD panels.

It shows up when you do printing. Printers vary widely in resolution
and of course they are in a different order of magnitude from screens.

 

[Roedy Green]

No, I think you mean "integer multiples" here. Pixels, for example, could
easily be drawn 3:1. But it's still the wrong solution.

Yes. That applies to shrinking too which is even more problematic.

Shrinking by 1/3 has the added problem you want the image to be a
multiple of 3 wide and tall to start, which is not likely to happen by
accident.

You can't take a finished bit map and stretch it by 5% and expect
something readable, but you can if you did the stretch and rounding to
pixels mathematically as you drew and let the layouts do intelligent
things to preserve regularity.

In PostScript there are operators to do a mathematic transform of a
point then get the snap-to equivalent pixel. Then you make that your
precise new origin.

What bothers me is PostScript was aware of these scaling and
resolution problems even before Java 1.0. Yet Java jumped right in
totally ignoring them.

Maybe they just had too many problems on their plate and felt that by
the time the problem became acute would be so psychologically far in
the future they figured a later generation would deal with it, or
perhaps hardware would do the scaling and rendering and the very
notion of bitmaps would become quaint antiquities.

 

[Chris Uppal]

It is patently ridiculous that in this day and age we are not specifying
nearly everything in resolution independant formalisms. Points, inches,
centimeters, lightyears or hydrogen atom width.

We don't have the display resolution yet. This machine has 125 ppi and that's
nowhere near enough to be able to ignore pixel boundaries. I'd guess that the
old laser printer "standard" resolution of 300 ppi would be enough, but only
just.

Admittedly there are /some/ applications where it's OK to ignore pixel
quantisation, but they tend to be applications where the visible display is
only intended to be an approximation to the underlying "truth" (and tend to
have zoom operations too). That isn't the case for positioning the elements of
a GUI.

But still, I'm looking forward to the day when we stop specifying sizes and
positions in integers.

-- chris