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