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.

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."

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

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:
> > 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. :}

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

-- 
Lew