On Thu, 2015-10-08 at 10:30 +0200, Pierre Wieser wrote: > Oop's. Sorry ! I've clicked on the bad button !!
Yes, it is sad that this trivial task is so hard, and that no one can really help. I was hoping that it could be possible to simple block input when buffer has a maximum length, but I got that not working. But deleting works at least. https://developer.gnome.org/gtk3/stable/GtkTextBuffer.html#GtkTextBuffer -insert-text >Note that if your handler runs before the default handler it must not >invalidate the location iter (or has to revalidate it). So our callback have to reset the iter! I did some test in Nim, a change to test my bindings and become some more comfortable with that language. There we have discard g_signal_connect_after(buffer, "insert-text", g_callback(clip), nil) proc clip*(buffer: TextBuffer, iter: TextIter; text: cstring; len: gint; data: gpointer) {.cdecl.} = const max = 8 var i, j: TextIterObj var cc = buffer.char_count if cc > max: buffer.get_iter_at_offset(i, cc) j = i # copy iter object discard j.backward_chars(cc - max) buffer.delete(j, i) buffer.get_iter_at_offset(iter[], max) # set iter to valid value again, value seems to be arbitray So the trick is just the last line, reset the iter callback parameter to a valid value after deletion. It is strange, I have the feeling that the callback is executed after the new text was already inserted, but in spite of that gtk complains about invalid iter. Strange. I guess you can understand the idea of that Nim code. I connected to "insert-text" signal, so no danger of recursion. I used g_signal_connect_after here, seems to make more sense when we delete last char. g_signal_connect works similar, but we seem to get one char more? Maybe Emmanuele Bassi can comment on this later... _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
