Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] GTK2 Tree: build, patch, and one smoking shot

Seth,
 
I looked through the patch, and it certainly makes a lot
of sense :-) I didn't actually *run* it yet, so I didn't
verify what happens with the signals (which is the trickiest
part), but there are several comments I have based on what
I saw in the source.
 
The only *essential* thing I don't understand in your
approach is the replacement of pixmaps with pixbufs.  In
SWT, Images are drawables.  When we made the decision
to stick with pixmaps, we couldn't find a way to obtain
a GC on a pixbuf; my understanding is that, this is not
possible.  Did we miss the elephant?
 
Looking at how your code gets the pixbuf from the pixmap,
I realize we were dumb and the "preparatory code" in
Image.getImageData() (that is, the six lines before the
gdk_pixbuf_get_from_drawable()) is not needed - right?
 
There are several minor things I would modify in your
implementation - they are mainly deviations from the coding
conventions we follow in SWT.
 
The rule of *No Custom Natives* is strict, and in many places
we sacrifice simplicity/straightforwardness to be able to
keep it.  There are a few places in your Tree where the rule
causes problems, and it feels completely natural to break it.
Most obvious: gtk_tree_model_get_value_boolean().  This one is really
evil because the name looks like an actual gtk function, and it's
impossible to tell by just looking at the java code that there are
in fact several OS calls going on in that native.
 
I understand this convention leaves one wondering, what to do
with "polymorphic" methods like gtk_tree_store_set().  Answer:
define polymorphic methods in OS.java, and use the "full signature"
form for the function name in swt.c.  Look at the various forms of
OS.memmove(...) and you'll see what I mean.
 
The other thing you certainly are wondering about, is the allocation
of GtkIter (OS.allocateGtkTreeIter).  Whatever is done, should be
done in Java, not in a custom native.  On the other hand, the normal
SWT way of having a struct and using memmoves, sort of makes no sense
here, because GtkIter is 100%-opaque, and all we need is the address.
In the new Table, I simply call malloc(), but we don't know the real
answer yet.
 
Another convention: SWT should not use java.util.*
 
Also:
Some VMs try to resolve all natives at class load time - in the case
of OS, this means native declarations on the java side must correspond
exactly to swt.c, even if a method is never touched.  In other words:
make_gtk_warnings_stop_in_c_debugger() will cause Eclipse to not
come up on *some* installations (although it is *usually* not the case).
This is really minor cleanup, but it is needed before code can go
into CVS.
 
Yet another convention: keep as much state in the OS, not in the
object.  This means, for example, that treeModel should not be an
instance variable in Tree; it is already kept in the OS.
 
An open question still pending careful consideration is when to
do macro conversions vs. casts:
 
jint tree_columns;
GTK_TREE_VIEW_COLUMN(tree_column)
vs.
(GtkTreeViewColumn*)tree_column
 
This is minor and non-essential, but it caught my attention because
we (arbitrarily) follow the latter convention everywhere, and your
use of the macro stands out as "different".
 
I'll actually apply the patch and see how the thing runs tomorrow,
this will certainly lead to more observations.
 
Boris

-----platform-swt-dev-admin@xxxxxxxxxxx wrote: -----

To: platform-swt-dev@xxxxxxxxxxx
From: Seth Nickell <snickell@xxxxxxxxxxxx>
Sent by: platform-swt-dev-admin@xxxxxxxxxxx
Date: 09/05/2002 08:27PM
Subject: [platform-swt-dev] GTK2 Tree: build, patch, and one smoking shot

Well after a holiday and a "summer BBQ" later I actually fixed the last
few nigglies in the Tree. I also went ahead and did the necessary fixes
to Image to make it support Pixbufs[1] rather than converting on the
fly.

Shot of the GTK2 tree in action[2]:
http://www.stanford.edu/~snickell/tree/tree-shot.png

Built version you can drop in your plugins directory[3]:
http://www.stanford.edu/~snickell/tree/swt-with-gtk2-tree.zip

Patch to SWT (CVS HEAD):
http://www.stanford.edu/~snickell/tree/swt-tree-v1.patch

Currently I am unaware of any bugs / problems /
doesn't-do-the-swt-thing-issues, though I'm sure they are present. I.e.
pretty much everything should be supported[5]. Feedback appreciated :-)

see posters and print ads for details[6],

-Seth


1) Pixbufs are now used by most GTK APIs rather than Pixmaps. The
GtkTreeView, as a new widget, doesn't include any support for Pixmaps in
its APIs. Most places we currently use Pixmaps should be converted to
use Pixbufs. I didn't have the time to do this, so currently it stores
both the Pixbuf and the Pixmap (but this is preferable to recreating the
Pixbuf on the fly which, courtesy of the no custom C code policy, is
relatively expensive)

2) Of course the coolest part is the animation *wink*

3) The tree has weird problems on one system here (using the same VM,
eclipse drop, etc as the others and a clean workspace). The only cause I
can surmise is that its using a somewhat older version of GTK2. Perhaps
there's a bug in that version of GTK in the tree, or perhaps its caused
by linking on a newer GTK (shouldn't be, but who knows?). I'd appreciate
help tracking this down.

4) Hacking around JFace phantom node behavior by forcing an expand after
the event is sent to JFace (see previous message for details). This
works fine, except that in the cases where the behavior is triggered
(e.g., expanding a folder before it is cached) the expand animation
looks jerky.

5) Actually, not quite true. I don't support setting the background of
cells, which the old one didn't either, but *could* be done with the new
tree view (whereas it couldn't really with GtkCTree).

6) With any luck the footnotes will be longer than the actual message.


_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev

Back to the top