Re: [gtk-list] Drawing interface in Gtk--

[John Utz <utz serv net>]

hi Michael;

i think the gint is there as a porting aid. i think i read it in the
tutorial somewhere. gint is guaranteed to be the same length on all gtk
supported platforms.

i know the MS has published a document about writing code for Win64, and i
seem to recall that they were going to make their Win64 int 64bits....i
suspect other system vendors will as well. Wont be ANSI, but youll still
get stuck with it :-(

On Fri, 11 Sep 1998, Michael Babcock wrote:

> 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
> 
> -- 
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
> 
>