[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GdkGraphics extending Graphics2D?

From: S. Meslin-Weber
Subject: GdkGraphics extending Graphics2D?
Date: Fri, 4 Mar 2005 14:12:37 +0000
User-agent: Mutt/1.5.6+20040907i

Hi Everyone,

Following a very brief discussion on irc with Michael we thought that
broader input would help resolve:

Namely, should GdkGraphics extend Graphics (as it does now) or

The argument against (corrections please) is that Graphics2D implies
more functionality than is currently available either in our AWT/Swing
or in the underlying native layer.

The argument for is Sun's (and IBM's) doing unfortunately. Since 1.2(?)
JComponent.paint() gets passed a Graphics2D object in the majority of
cases[1] and people are writing production code such as the following
example habitually.

  public void paint(Graphics g) {
    Graphics2D g2 = (Graphics2D) g;
    g2.draw(new Rectangle());

Worse is that publications teaching usage of Swing encourage this usage.

I propose that GdkGraphics be made to extend Graphics2D with dreaded
stub methods to make it behave like a standard Graphics instance.

I realise that subbed classes hide incomplete implementations at
compilation time[2] (heaven knows this has been discussed heavily in the
past) but what concerns me now is making this work at runtime.

Comments welcome! :)

Best regards


[1] The degenerate case in this instance is the use of DebugGraphics
[2] Stubbed methods can be caught reasonably easily by static analysis
either by an IDE or other command line tools.

Stephane Meslin-Weber         Email: address@hidden
Software Engineer             Web:

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]