Drawing interface in Gtk--

[Michael Babcock <mbabcock la creatureshop henson com>]

Things move too fast in the Free Software world! I still haven't had
time to implement my own Viewport widget (which would seem to entail
writing a C++ drawing interface and giving all widgets a new way to draw
themselves in order to allow them to be used inside a viewport) and now
I see talk of integrating an existing drawing interface into Gtk-- as
well as talk of a 1.0 release. So I guess I better speak now or forever
hold my peace.

The problem I ran into was that implementing a proper Viewport widget
would not allow use of the existing "draw" slot because that is defined
to take dimensions of short int. I wrote about this a couple months ago
and posted it to the gtk-mozilla newsgroup. I guess it was the wrong
place or just a dumb message because I didn't get much response. I've
included the message below. I apologize for recycling old email but time
is short. My question is whether this gtkmmdraw deals with encapsulating
drawables/gcs so that you don't have this problem. Another thing drawing
should be able to handle is printing. I believe the scheme I vaguely
outline below would also solve the lack of transparent printing support
in Gtk, since another "Graphics" subclass would just generate
Postscript. Of course a few addition APIs would also be needed to deal
with printer specific stuff like paper sizes and page breaks.

Comments?

This is the message I sent a couple months ago:

Elliot Lee wrote:
> 
> On 9 Apr 1998, Vidar Hokstad wrote:
> 
> > It's should be easy to do, but if ScrolledWindow really is so messed up it
> > can't support more than 32768x32768, then that's what needs to be fixed...
> 
> It has nothing to do with GtkScrolledWindow - it's a limitation of X11
> itself. I'm pretty sure that getting reasonable performance in a space
> bigger than that means implementing a specific solution for each use case.

No No No! It's definitely a limitation of GtkScrolledWindow (and in fact
the Gtk design itself). And providing a good ScrolledWindow widget that
can handle nearly infinite sized child widgets is certainly desirable,
and attainable. Unfortunately I think it requires some redesigning of
Gtk widgets themselves, not just a new version of GtkScrolledWindow.

The problem stems from the fact that that unlike Gtk, Gdk is not object
oriented. Widgets are sent a draw signal with the clipping argument,
which is unfortunately tied much to closely to the underlying X
implementation. The clipping rectangle is given in short ints! Even if
this was fixed, it's still not enough, as the widgets are expected to
muddle through as best they can with the gdk_* procedures to do their
drawing. The draw signal's parameter should be some sort of object,
something like a Drawable, a GC, or a combination of the two (obviously
I haven't really thought this through very well). All drawing should use
this "Graphics/Drawable context" object. An abstract class could provide
the interface to the object, but the implementations could vary. A
ScrolledWindow class would pass an object of a type that was a derived
class of this Context class that would implement the drawing functions
simply by translating the coords by the current scroll position and then
calling the default drawing implementation. Other widgets could pass
children objects that transparently allowed such things as scaling and
rotation in addition to translation. The child widgets wouldn't have to
know anything about this, they would just work.

I'm new to Gtk; I'm not worthy to be talking about its design like this.
I was hoping to finish my own implementation of some of these ideas and
use them in my own Gtk project to get a better understanding of the
issues, before submitting my ideas to the Gtk people. However when I saw
this GtkScrolledWindow issue come up, I figured I better say something
even if I sound like a fool. I'm hoping someone who knows Gtk better
than I do can take the ball and run with it. Also, all my (limited)
experience is with Gtk-- in C++, I'm not sure how well this applies to
Gtk itself.

But that offensive phrase "implementing a specific solution for each use
case", which should cause unease in any programmer's heart, inspired me
to action! ;-)

Okay, while I'm ranting about this, I might as well throw in a couple of
other observations about Gtk. I'm suspicious of the thin (to the point
of uselessness?) wrapping techniques seen in some of Gtk. The Gdk is a
good example of this. It really looks an awful lot like Xlib. There's
nothing wrong with Xlib, but the documentation doesn't make it clear if
there's any additional functionality or not. Abstraction should be used
for a reason, not just to rename functions to have the nice looking
letter "g" in front! For portability, say to Windows, it seems it would
be just as easy to port Xlib (which has probably already been done) in
order to port Gtk as any other method. If Gdk is really Xlib, why not
use XLib? At least it is already well defined, tested, and documented.

Likewise, I'm curious if anyone can define precisely what a "gint" is.
If the definition is something different than that of a C "int", I think
the name should be more descriptive than "gint". On the other hand, if
the definition is that of a C "int" we should say what we mean and call
it an "int". Unless all code is written from scratch and uses this
"gint" throughout, there are going to ints in the code mixed with gints.
Confusion ensues. (Okay, this is a bit pedantic.)

In any case I want to make it clear that I'm a fan of Gtk. It seems to
be gaining momentum, which is great. I'm not trying to put it down, I'm
trying to help make it as good as possible. I only criticize because I
care:-)

--
Michael Babcock
mbabcock@la.creatureshop.henson.com