Re: [platform-swt-dev] GTK2 Tree: build, patch, and one smoking shot

[snickell@xxxxxxxxxxxx]

"Agreed 100%.  The existing documentation is *miserable*, and I believe
this is *the* worst problem with SWT today."

If you'd like, I'm happy to document the general "non-code" issues that
I am aware of wrt to SWT, though I may still be ignorant of some.

<snip discussion of natives/wrappering>

I'll switch to the SWT Way[TM]. I don't agree with it, but I don't have
to maintain the code that results, so no skin off my back.

"Now the piece of Tree that really bothers me:  the pixmaps.  I know all
of what you are telling me, and I totally agree:  pixmap *is* very bad.
 But the problem is that I don't see how to do without it
I keep re-reading your mail and I still don't understand what it is that
you are proposing to do.  Right, pixbufs are on the X client - then how
will we getGC, and then drawString and all that stuff in Drawable.java?"

I agree with your assesment of these problems, but I don't see how to do
with Pixmap either, and it will only become increasingly problematic in
the future. The problem seems to be that the SWT interfaces deal with a
"platform" that only has one type of image (sensible enough), but GTK
has two types of image (pixbufs, and pixmaps, both of which are
appropriate in different circumstances and not in others). However,
while the SWT API presents a single Image, there do appear to be two
distinct use cases we can optimize for.

Looking through API usage.... Most stuff either:

a) Loads an image from disk, and then assigns it to a control (Drawable
aspects not used, and you almost always want to use the Image as a
pixbuf here since all the controls accept pixbufs)

or

b) Creates a custom image programmatically, e.g. the gradients in the
cooltabs (Drawable aspects used, and you almost always want to use teh
Image as a pixmap here)

So an option would be to provide the option of getting the pixbuf OR the
pixmap, but rather than directly referencing them provide methods such
as getPixmap() and getPixbuf() that either return the structure (if its
up to date) or lazily render it from the other (if its not). In the
normal (a) and (b) cases this would mean that no conversions would be
done (since we would naturally create pixbufs when loading from a file,
but pixmaps if starting from scratch).

In the cases where an Image is, say, drawn to (which would use pixmap)
and then set to a control (which would use pixbuf) it would be drawn to
as a pixmap, and the pixbuf version marked as "dirty", and then
re-rendered as a pixbuf when getPixbuf was called. Similarly if you load
a file (which would use a pixbuf), and then do getPixmap. Looking at the
current code I don't think this ever happens, but of course its a case
that would have to work (even if rare).

> "This seems sketchy given that we actually *allocate* the model. The
> model is not grabbed as a pointer......"
 
> Oh, I meant in a much lighter sense!!! :-)))
> Of course we have to manage the store as a totally independent entity
> by itself, but *in SWT*, the TreeView is always tied to it so once we
> have the view and it has grabbed onto the store, we can always figure 
> out what the store is.  All the essential code is the same, we are
> just talking about modelHandle() vs modelHandle.

I guess is just my old-sk00l C programmer tendencies, but I'm
uncomfortable being ultimately responsible for the management of memory
I don't hold a pointer to (and I don't really understand the cost of
holding pointers to objects that are intended to belong on the client
side; I do understand how its dangerous to hold references to objects
that aren't "ours"). Its fine I guess, it just makes me itchy ;-)
 
> Macro conversions vs. casts:  I agree here.  We chose casts 
> "arbitrarily" in the sense that we didn't put specific thought into 
> the problem; but it should be the macros.  The only thing why I 
> started on this was, everywhere else it's casts, and in the team we 
> have a saying: "there is no 'better' and 'worse'; there is 'same 
> everywhere' and 'different', and different is the Bad Thing."  So I 
> will change it to macros in one shot - doing it here today and there 
> a month later is not our practice.

Sounds fine, I'll switch to casts...

-Seth