Re: swing comments from an ex-C++ motif programmer
- From: Hunter Gratzner <a24900@xxxxxxxxxxxxxx>
- Date: Fri, 31 Aug 2007 12:25:30 -0700
On Aug 31, 10:40 am, ap...@xxxxxxxxxxxxxxxxxx wrote:
However with Motif at least it was possible to get the result you
wanted
What? Later you complain about JTable. Motif doesn't even have a
table.
and the result always looked nice.
What? Motif looks even uglier than Windows 95. Look at this junk
http://www.opengroup.org/graphics/desktop/m-mwm.gif
I remember what happened with C++/Motif. A number
of competing toolkits were developed, some proprietary, some open
source. A number of them, mainly the open source ones, survived to the
present day.
The root of the X11 toolkit proliferation is not Motif. The root is
X11's architecture which was right from the beginning designed to be
independent of toolkits, and LAFs. And early X11 already shipped with
several toolkits, like Xt and Andrew.
What I am after is a toolkit that is built on swing that makes things
easier to code,
Swing is a toolkit.
Bling fan use SwingX for fancy effects https://swingx.dev.java.net/
possibly with a GUI builder (e.g like GTK has glade).
Hand-coding GUIs works better. If you really want a GUI builder look
at the one in NetBeans.
Whilst some toolkits do seem to be evolving in java they seem to be
concentrating on the LAF rather than making coding easier. Maybe this
is because swing components do not look nice by default.
It is completely up to the PLAF how a Swing component looks. Don't
like the look? Switch the PLAF.
As a relative latercomer to java I am shocked at the state of play
when it comes to GUI programming. I wonder why that is. Perhaps it is
because GUIs are moving over to being web based?
No, there are two main reasons:
Sun does not care about Java on the desktop. They spend most of the
development effort on enterprise stuff and ME, because that's where
the big bucks can be made.
The other issue is that it is really difficult to develop a non-
trivial cross-platform toolkit.
In particular I find it very awkward to implement a non-trivial JTable
component.
Well, here programming hasn't degenerated to copy-pasting stuff from
MSDN or clicking around in some fancy GUI. Sometimes a programmer has
to write code.
I want my table to be non-editable by the end-user
Use a TableModel with an isCellEditable() method that always returns
false. A trivial line of code.
programmatically updated (rows added/deleted/changed) upon the
asynchronous arrival of events from a third-party API.
Let the TableModel fire the necessary events to the JTable. This is
the general Swing architecture. The model informs the component about
updates. Nothing special when it comes to JTables.
See the implementation of the fire methods in AbstractTableModel for
examples on how the events should be fired, or even subclass
AbstractTableModel for your model and just use the methods. Make sure
you call the fire methods from the EDT, so use invokeLAter().
I want to be
able to set the color of cells depending on data that arrives via this
API. I have found a crude way to do it by extending
DefaultTableCellRenderer but I want something better.
Extend a JLabel and implement TableCellRenderer. Implement a
TableModel which keeps data type information, too. Let the
CellRenderer query the model for the type of a particular cell. Let
the renderer translate the type into a set of colors (e.g. from some
color schema). Let the renderer set the superclass (JLabel) colors.
.
- References:
- swing comments from an ex-C++ motif programmer
- From: apm35
- swing comments from an ex-C++ motif programmer
- Prev by Date: Re: Newbie - JAR question
- Next by Date: Re: IO: creating dirs/files...
- Previous by thread: Re: swing comments from an ex-C++ motif programmer
- Next by thread: When to log? (best practices and localization)
- Index(es):
Relevant Pages
|
