Re: A GIterator type, but not as a simple type -> as a GTypeInterface (GIterIface)

[Philip Van Hoof <spam pvanhoof be>]

On Tue, 2006-02-07 at 21:18 -0500, Owen Taylor wrote:

Hey Owen, 

I've been cutting in your reply. Else this discussion would get
needlessly long and difficult to read ;-).

If others are reading this: please make sure to read the stuff came
before this e-mail.

> It definitely bothers me that it's hard to write GtkTreeModel
> implementations in a high-level language. That's something I wish we
> could have done better.

I'm happy it bothers you. For me this means that in the end, we have the
same goal ;-). And somehow share the same opinion on the core idea of
why I proposed a type like GIterIface.

> But I don't know how, and I'm not entirely sure it was possible ...

If it's not possible, we can make it possible. And about 'difficult':
IMHO, 'difficult' is fun.

> the memory management paradigms we use for GTK+ work well for big
> objects, they don't work well for tiny objects.

Agreed.

Wouldn't it be a good idea to create a new style of object creating,
like gobject, that is more suitable for tiny objects?

In a demo I also used a very tiny interface and a very very very tiny
object: the proxy for each of those three million rows in the treeview.

The full demo:
https://svn.cronos.be/svn/custom-treemodel-demo/trunk/src/

An iterator-type that is as small as that msgheader-proxy type, isn't
going to have a significant impact on memory usage and isn't going have
a significant impact on performance.

I do believe you when you say memory management will be more difficult
than, let's say, a Java developer will encounter. 

But let's face it, C developers know that memory and it's management are
difficult while using their programming environment.

The implementations:

a) The small proxy type (I create three million of these in a continuous
allocation in a few seconds on modern hardware, using a single malloc):

https://svn.cronos.be/svn/custom-treemodel-demo/trunk/src/msg-header-proxy.c

b) The small interface it implements:

https://svn.cronos.be/svn/custom-treemodel-demo/trunk/src/imsg-header.c
https://svn.cronos.be/svn/custom-treemodel-demo/trunk/src/imsg-header.h

I know it's not using GObject. I wanted to keep it blazing fast. It's
just the minimal things, some function pointers and that's it. Very fast
to create them, very small in memory (A few bytes each depending on
things like data alignment).

> I almost wonder whether the right way to attack things is to provide
> only two things:
> 
>  - A view that is *much* more of a shell than our current view -
>    it just has callbacks for drawing.
>  - An interface spec for what the final result should look like
>    with example mappings to various languages.
> 
> And then force language binding authors to do most of the heavy lifting
> on their side. That's painful, but you can get some pretty big wins
> in this area by being pure Java or pure CLR.

Actually, this doesn't sound like a bad idea. 

My own idea was to build an adaptor that makes building a simple custom
tree model more easy. And perhaps a custom tree model implementation
that's more easy to inherit in a programming language that uses a 'a by
a language binding generated' binding or wrapper.

Perhaps also an adaptor for GtkTreeView.

> Then again, most people don't really need to do a custom model at all;
> it's almost always a mistake.

I disagree here. I can give you many cases for which I needed a custom
model and where it was the best solution for my problem.

I can also give many cases where it should have been used. And I can
give many cases where it has been used successfully. I can also  this
for a lot Gtk+ applications.

And I can show you how people solved a specific such problem very
cleanly in a higher programming language, whereas others solved it
extremely ugly partly because they used GtkList -and TreeStore.

Custom models aren't something specific to gtk+. In fact is every type I
develop a potential model for a potential view. And every list of such a
type a potential list model. 

In .NET I can bind any IList (an array of a specific type or a col-
lection are such IList implementations) to a DataGrid type. I very
frequently use this.   It works.

I want "that" in Gtk+ :-). Perhaps only in java-gtk or gtk-sharp or
whatever, but "in" gtk+.

Today, that is very difficult. System.Windows.Forms (the worst UI
toolkit I can think of) can do it. This is because Microsoft told its
developers: "No, it's not impossible. It's just difficult. Difficult is
fun".

> > Above I explained how doing the iterator type as an interface can solve
> > this.
> 
> I was discussing a particular proposal, that was GLib level
> not GObject level. If you do iterators as a GObject thing that returns
> GValues, you've made things even more unpleasant for C programmers, but
> yes, you'll solve this problem.

My proposal is, indeed, GObject. Not C nor GLib. I'm more interested in
making it more easy to use it in a higher language. If pure C developers
burn and kill me, fine.

A lot pure C developers already hate everything about glib for trying to
reinvent everything.  :-)

> > >  - Lack of robustness like a foreach() function; if iterators
> > >    contain pointers to internal data, they won't be 
> > >    robust against structural changes.
> > 
> > Oh? Can you give an example?
> 
> Your iterator contains a pointer to a GList node. While your 
> iterator is kept around, the GList node is freed...

Ah, right. But not all list-types aren't gobjects that can't do
reference counting. I agree most are. So, good point :-)

> > I'd say implement a library on top of GObject that makes it possible to
> > start using a type like GIterIface. But not yet use it in gtk+. Perhaps
> > refactoring the GtkTreeView so that letting it use a real iterator in
> > stead of GtkTreeIter. I would in stead of putting a new
> > GtkTreeModelIface in gtk+, put it in that library on top of GObject. For
> > example with a name like GListModelIface and GTreeModelIface.
> 
> I think we've just about got people over the GtkCList => GtkTreeView
> hump now... not particularly looking forward to another switch.

At the begin of my e-mail I wrote that gtk+ shouldn't be modified. I'm
not advocating a new switch.

One of the few problems I have with Gtk+ is that GtkTreeIter thingy. It
could have been better. Other than that is gtk+ very usable for most
high-level programming techniques already.

Also note that the previous switch was also about learning people the
MVC paradigm (and made gtk+ usable for these techniques). I can imagine
this wasn't easy. It was a huge step. I don't think this means 'all'
switches would be as huge.

I also don't think any such changes should go into what we today call
gtk+-2.0. This would be gtk+-3.0 or maybe gtk+-4.0, and gobject-x.y or
not even gobject-x.y but a gobject-extra-1.0.

In a few years, I think high-level programming environments will be even
more important than today. Sure today we want to get gtk+ "just work".
But what about tomorrow? s/gtk/xul/g ?


-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be