classpath
[Top][All Lists]
Advanced

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

Re: GdkGraphics extending Graphics2D?


From: Michael Koch
Subject: Re: GdkGraphics extending Graphics2D?
Date: Fri, 4 Mar 2005 15:56:49 +0100
User-agent: mutt-ng 1.5.8i (Debian)

On Fri, Mar 04, 2005 at 02:12:37PM +0000, S. Meslin-Weber wrote:
> Hi Everyone,
> 
> Following a very brief discussion on irc with Michael we thought that
> broader input would help resolve:
> 
> https://savannah.gnu.org/bugs/?func=detailitem&item_id=12211
> 
> Namely, should GdkGraphics extend Graphics (as it does now) or
> Graphics2D?
> 
> 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! :)

At first thought when I saw bug report I thought its invalid. Now I'm
not sure anymore. When its reached as "good practice" for Swing
developers we should allow it too. As we would probably break a majority
of Swing applications otherwise.

I know at least JEdit depends on a working Graphics2D implementation.
There this workaround wouldnt help. For other apps it might be enough to
derived GdkGraphics from Graphics2D and stubb the new methods. Another
possibility is to switch to the real Graphics2D implementation using
Cairo now. The problem with this is that the Cairo API still changes
much from release to release and we always need to depend on the special
version of it (as we do now already).

What do others think about this ?


Michael
-- 
Java Trap: http://www.gnu.org/philosophy/java-trap.html




reply via email to

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