search

crategus / cl-cffi-gtk

cl-cffi-gtk is a Lisp binding to the GTK+ 3 library.
http://www.crategus.com/books/cl-cffi-gtk
146 stars 33 forks source link

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

Open stacksmith opened 5 years ago

stacksmith commented 5 years ago

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.

Ferada commented 5 years ago

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.

stacksmith commented 5 years ago

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.

stacksmith commented 5 years ago

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

stacksmith commented 5 years ago

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 https://github.com/cffi/cffi/pull/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.