Giters

crategus / cl-cffi-gtk

cl-cffi-gtk is a Lisp binding to the GTK+ 3 library.

Home Page:http://www.crategus.com/books/cl-cffi-gtk

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

WRONG: iters should not be allocated in GTK-TEXT-BUFFER and -VIEW functions

stacksmith opened this issue · comments

commented

All gtk-text-buffer functions that return iters are implemented incorrectly, or at least miss the point of how GTK intended to use iterators.
All native GTK functions that use iters as positions do not allocate them, but alter the positions of existing iters. The idea is that you create a few iters up-front, and use these functions to modify them, prior to freeing the iters.
Unfortunately, the lisp functions above the %gtk-... wrappers create new iters which require freeing. This creates a lot of garbage for no good reason.

commented

I'm guessing you're seeing more of an impact of this due to how often these functions are called from your code?

For backwards-compatibility as far as I can see there's only two ways to change this:

  1. Export the %gtk functions.
  2. Add an &optional (iter (make-instance 'gtk-text-iter)) (respectively &key ...) argument.

The return value would stay the same though, but it'd just be returning the passed-in value instead.

The first one is not super nice since the names are supposed to be implementation details. The second one is doable and could then also be supported further with a (with-iter (name) ...) macro and supporting dynamic-extent declaration etc.

commented

Since I've been annoyed by this for years, I wound up just reimplementing iters as simple cstructs, as well as all GtkTextIter, GtkTextBuffer and GtkTextView since these make use of iters extensively. It was a bit of work, but I got to test some neat cffi-related macros. The resultant bindings sit alongside existing ones, in their own packages - gtb, gtv, and gti.
There were many unimplemented functions, an odd mix of gobject-based and function-based accessors, and a few other things that have been annoying me for some time.

I am looking at some other lightweight structures that are boxed-opaque... Rectangles and points are treated with the same lack of respect, I believe. That's next on my list.

commented

God help me. I just noticed that gdk-event structures are boxed... I surely hope they get deallocated somewhere..

commented

Well, I can see why everything is in :gtk package... It extremely painful to deal with foreign structure definitions in different packages.
I made a pull request cffi/cffi#145 in cffi with an improvement to with-foreign-slots macro... It allows different names to be bound to slot accessors, and therefore the ability to rebind names to cstructs in a different package...
I have some better macrology to deal with cstructs, but still testing.