Overriding JComponent or implementing ComponentUI?

Hello Swing programmers.

I'm going to try to make a few custom components. Specifically histogram
and heat maps. Heat maps meaning histograms over time plots.

I know there are probably existing libraries which do this, and I will
investigate using them too, but for my use-case I may need more
flexibility then they afford. In any case, I also enjoy implementing
these kinds of things as a learning exercise.

So, in the past I've always implement custom views by extends JComponent
and overriding the paintComponent method. That works fairly well, but
then I noticed that there is the ComponentUI classes and subclasses.

Does anyone have any experience with implementing ComponentUI classes?
It seems to be part of the PLAF architecture, and since this isn't
really a look-and-feel configurable component, it seems like that may be
overkill.

Actually, I think I've answered my own question, but I'll post this
anyway to encourage discussions :-)

Feedback and suggestions on libraries to use instead is welcome. Thanks.


Thanks,
Daniel.

In article <kN1Ir.59786$GJ4.56436@newsfe16.iad>,
Daniel Pitts <newsgroup.nospam@virtualinfinity.net> wrote:

> I'm going to try to make a few custom components. Specifically
> histogram and heat maps. Heat maps meaning histograms over time
> plots.

<http://www.jfree.org/jfreechart/> should be on your short list. I'd
look at XYBarRenderer and XYBlockRenderer; both are pictured in the
API and featured in the JWS demo.

> I know there are probably existing libraries which do this, and I
> will investigate using them too, but for my use-case I may need more
> flexibility then they afford. In any case, I also enjoy implementing
> these kinds of things as a learning exercise.

As a simple example, implementing the Icon interface will allow you to
leverage the text positioning feature(s) of JLabel:

<https://sites.google.com/site/drjohnbmatthews/kineticmodel/code#Histogram>

> So, in the past I've always implement custom views by extends
> JComponent and overriding the paintComponent method. That works
> fairly well, but then I noticed that there is the ComponentUI classes
> and subclasses.
>
> Does anyone have any experience with implementing ComponentUI
> classes? It seems to be part of the PLAF architecture, and since this
> isn't really a look-and-feel configurable component, it seems like
> that may be overkill.

I've followed this outline to get the UI plumbing right, but there's
little value unless you can realistically anticipate anyone ever
wanting more that one UI delegate.

<http://today.java.net/pub/a/today/2007/02/22/how-to-write-custom-swing-component.html>

As a particular example, org.jfree.chart.JFreeChart itself extends
Object, not JComponent. Typically, a JFreeChart is added to a
ChartPanel, which extends JPanel and listens for chart related events.
The container then adopts the chosen PLAF, while the chart has a
ChartTheme. You can leverage the chosen PLAF by having your
implementation of ChartTheme use the PLAF defaults.

> Actually, I think I've answered my own question, but I'll post this
> anyway to encourage discussions :-)
>
> Feedback and suggestions on libraries to use instead is welcome.
> Thanks.

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Daniel Pitts <newsgroup.nospam@virtualinfinity.net> writes:
>Does anyone have any experience with implementing ComponentUI classes?
>It seems to be part of the PLAF architecture, and since this isn't
>really a look-and-feel configurable component, it seems like that may be
>overkill.

To address one detail: When doing custom painting, the
component should fit into the LAF appearance. So, for
example, when painting the thumb of a custom scrollbar,
one would use the color obtained as follows:

final java.awt.Color thumbColor =
javax.swing.UIManager.getColor( "ScrollBar.thumb" );

. Why does nobody use »getColor«?

It might be related to the fact that these color names, such
as »ScrollBar.thumb« are not defined statically. So one can
never be sure whether the current environment »supports« a
given color name. This seems to render them useless for
using them in source code.

What should be done is to define a subset of color names
statically (such as »Foreground« and »Background«) that
is guaranteed to always be available.

On Sun, 01 Jul 2012 12:45:19 -0700, Daniel Pitts
<newsgroup.nospam@virtualinfinity.net> wrote, quoted or indirectly
quoted someone who said :

>It seems to be part of the PLAF architecture, and since this isn't
>really a look-and-feel configurable component, it seems like that may be
>overkill.

The first thing I do in such a situation is think about which Oracle
Component is closest to what I want to do, then study its source in
src.zip JavaDoc is fine for the details, but it does not tell you
what something is for, i.e. its intended use. I am quite sure you are
familiar with the technique, but you asked to stimulate a general
discussion.
--
Roedy Green Canadian Mind Products
http://mindprod.com
Why do so many operating systems refuse to define a standard
temporary file marking mechanism? It could be a reserved lead character
such as the ~ or a reserved extension such as .tmp.
It could be a file attribute bit. Because they refuse, there is no
fool-proof way to scan a disk for orphaned temporary files and delete them.
Further, you can't tell where the orhaned files ame from.
This means the hard disks gradually fill up with garbage.

In article <Swing-color-names-20120703132124@ram.dialup.fu-berlin.de>,
ram@zedat.fu-berlin.de (Stefan Ram) wrote:

> Daniel Pitts <newsgroup.nospam@virtualinfinity.net> writes:
> >Does anyone have any experience with implementing ComponentUI classes?
> >It seems to be part of the PLAF architecture, and since this isn't
> >really a look-and-feel configurable component, it seems like that may be
> >overkill.
>
> To address one detail: When doing custom painting, the
> component should fit into the LAF appearance. So, for
> example, when painting the thumb of a custom scrollbar,
> one would use the color obtained as follows:
>
> final java.awt.Color thumbColor =
> javax.swing.UIManager.getColor( "ScrollBar.thumb" );
>
> . Why does nobody use »getColor«?
>
> It might be related to the fact that these color names, such
> as »ScrollBar.thumb« are not defined statically. So one can
> never be sure whether the current environment »supports« a
> given color name. This seems to render them useless for
> using them in source code.
>
> What should be done is to define a subset of color names
> statically (such as »Foreground« and »Background«) that
> is guaranteed to always be available.

Daniel: Stefan Ram' point is well taken. You may be able to find a
subset of named defaults in the intersection of L&Fs you plan to
support. To ensure that your component can respond to a dynamic change
in L&F, (re-) apply your changes in updateUI(), as shown in this example
that conditions a JToggleButton to resemble a JTable header:

<http://stackoverflow.com/a/7137801/230513>

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

In article <9l9bv7hn0giftqhmai9lbothbcuhvltcvt@4ax.com>,
Roedy Green <see_website@mindprod.com.invalid> wrote:

> On Sun, 01 Jul 2012 12:45:19 -0700, Daniel Pitts
> <newsgroup.nospam@virtualinfinity.net> wrote, quoted or indirectly
> quoted someone who said :
>
> >It seems to be part of the PLAF architecture, and since this isn't
> >really a look-and-feel configurable component, it seems like that
> >may be overkill.
>
> The first thing I do in such a situation is think about which Oracle
> Component is closest to what I want to do, then study its source in
> src.zip JavaDoc is fine for the details, but it does not tell you
> what something is for, i.e. its intended use. I am quite sure you
> are familiar with the technique, but you asked to stimulate a
> general discussion.

One valuable consequence of such an approach is an opportunity to
critically evaluate of the need to change the component or its
appearance at all.

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

On 01/07/2012 21:45, Daniel Pitts allegedly wrote:
> Hello Swing programmers.
>
> I'm going to try to make a few custom components. Specifically histogram
> and heat maps. Heat maps meaning histograms over time plots.
>
> I know there are probably existing libraries which do this, and I will
> investigate using them too, but for my use-case I may need more
> flexibility then they afford. In any case, I also enjoy implementing
> these kinds of things as a learning exercise.
>
> So, in the past I've always implement custom views by extends JComponent
> and overriding the paintComponent method. That works fairly well, but
> then I noticed that there is the ComponentUI classes and subclasses.
>
> Does anyone have any experience with implementing ComponentUI classes?
> It seems to be part of the PLAF architecture, and since this isn't
> really a look-and-feel configurable component, it seems like that may be
> overkill.
>
> Actually, I think I've answered my own question, but I'll post this
> anyway to encourage discussions :-)
>
> Feedback and suggestions on libraries to use instead is welcome. Thanks.
>
>
> Thanks,
> Daniel.

FWIW (as it's been a while I've done GUI code), the more complex and
specialised custom components I wrote, the further I lent towards
ComponentUIs. Unfortunately, I don't remember any exact benefit. Perhaps
a matter of cleanness and encapsulation (as it feels "more right" to put
that code in a dedicated place, rather than overriding stuff in the
component). There's also the issue of shared resources, although those
can be dealt with similarly in JComponent.

I realise that was a terribly useless post. Sorry about that.

--
DF.

On 10/07/2012 08:30, Lew allegedly wrote:
> Daniele Futtorovic wrote:
>> FWIW (as it's been a while I've done GUI code), the more complex and
>> specialised custom components I wrote, the further I lent towards
>> ComponentUIs. Unfortunately, I don't remember any exact benefit. Perhaps
>> a matter of cleanness and encapsulation (as it feels "more right" to put
>> that code in a dedicated place, rather than overriding stuff in the
>> component). There's also the issue of shared resources, although those
>> can be dealt with similarly in JComponent.
>>
>> I realise that was a terribly useless post. Sorry about that.
>
> Honestly, I thought it was going to be useless for a second, but it
> turned out to be rather thought-provoking and best-practice oriented.
>
> Assuming I understood your remarks correctly.
>
> Josh Bloch says, "Prefer composition to inheritance."
>
> In GUI terms this translates to, "Usually you have a JFrame as a member
> rather than as a supertype."
>

Indeed the good man does, and indeed the good man is right. But I would
have liked to be able to find in my experience a pratical illustration
of that bit of wisdom. For, while trust may be fine, knowledge is good. :}

--
DF.

Daniele Futtorovic wrote:
> Lew allegedly wrote:
> &gt; Daniele Futtorovic wrote:
> &gt;&gt; FWIW (as it's been a while I've done GUI code), the more complex and
> &gt;&gt; specialised custom components I wrote, the further I lent towards
> &gt;&gt; ComponentUIs. Unfortunately, I don't remember any exact benefit. Perhaps
> &gt;&gt; a matter of cleanness and encapsulation (as it feels &quot;more right&quot; to put
> &gt;&gt; that code in a dedicated place, rather than overriding stuff in the
> &gt;&gt; component). There's also the issue of shared resources, although those
> &gt;&gt; can be dealt with similarly in JComponent.
> &gt;&gt;
> &gt;&gt; I realise that was a terribly useless post. Sorry about that.
> &gt;
> &gt; Honestly, I thought it was going to be useless for a second, but it
> &gt; turned out to be rather thought-provoking and best-practice oriented.
> &gt;
> &gt; Assuming I understood your remarks correctly.
> &gt;
> &gt; Josh Bloch says, &quot;Prefer composition to inheritance.&quot;
> &gt;
> &gt; In GUI terms this translates to, &quot;Usually you have a JFrame as a member
> &gt; rather than as a supertype.&quot;
> &gt;
>
> Indeed the good man does, and indeed the good man is right. But I would
> have liked to be able to find in my experience a pratical illustration
> of that bit of wisdom. For, while trust may be fine, knowledge is good. :}

Well, the bit about making a JFrame a member rather than supertype is a
practical illustration.

--
Lew