Re: gtk_text_iter_forward_search() comparison
On Sat, Jan 28, 2017 at 07:16:04PM -0500, Eric Cashon via gtk-devel-list wrote: > I have been working on a little search experimentation. Gave writing a > case in-sensitive gtk_text_iter_forward_search() a try. The code is > shorter than what is in gtktextiter.c and it works a little faster. If > a word is searched that isn't very frequent the time is about the > same. If you just look for single chars or words that are frequent it > looks to be quicker. Is the performance of gtk_text_iter_forward_search() a problem for your application? Or you just wanted to play a little with the code? (Side note: GtkSourceView has a higher-level API for the search and replace, with regex support. If you're working on the search and replace for an application, this is worth a look.) > Not sure if this a suitable method though. I know > little of the textbuffer internals. UTF-8 gives me some trouble also. This doesn't give us confidence in your code. Bug-free code is more important than better performance at the cost of UTF-8-related bugs. -- Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Versioning and long term stability promise in GTK+
On Sat, Sep 03, 2016 at 02:09:04PM +0100, Emmanuele Bassi wrote: > https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/ In the above announcement, you've written: More details about these plans, including specifics for library developers and distribution packagers, will follow in subsequent blog posts. Those subsequent blog posts have not yet been posted. If you've written that, it probably means that you wanted to explain more things. For a higher-level library based on GTK+, a GTK+ API break can force an API break in the higher-level library. So during the GTK+ 3.9x versions, the higher-level library cannot really guarantee API stability. Normally, each time there is an API break, the Libtool version must be bumped (increment CURRENT, set REVISION to 0 and set AGE to 0). Is that all there is to know about handling API instability in higher-level libraries? Maybe you have other things in mind. Thanks, Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_text_iter_forward_search() comparison
Hi Sebastien, I assume that you did not even look at the code before commenting. If code is more concise and runs faster... there is no interest? It uses UTF-8 functions but I don't have experience with other languages outside of English. I don't know how to test with other languages. Admittedly, I don't have all things figured out. Maybe there is a bug in the code. If there is no interest, that is OK with me. Not many people even look at search algorithms. I find it interesting. Eric -Original Message- From: Sébastien Wilmet To: cecashon Cc: gtk-devel-list Sent: Sun, Jan 29, 2017 1:35 am Subject: Re: gtk_text_iter_forward_search() comparison On Sat, Jan 28, 2017 at 07:16:04PM -0500, Eric Cashon via gtk-devel-list wrote: > I have been working on a little search experimentation. Gave writing a > case in-sensitive gtk_text_iter_forward_search() a try. The code is > shorter than what is in gtktextiter.c and it works a little faster. If > a word is searched that isn't very frequent the time is about the > same. If you just look for single chars or words that are frequent it > looks to be quicker. Is the performance of gtk_text_iter_forward_search() a problem for your application? Or you just wanted to play a little with the code? (Side note: GtkSourceView has a higher-level API for the search and replace, with regex support. If you're working on the search and replace for an application, this is worth a look.) > Not sure if this a suitable method though. I know > little of the textbuffer internals. UTF-8 gives me some trouble also. This doesn't give us confidence in your code. Bug-free code is more important than better performance at the cost of UTF-8-related bugs. -- Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
