Re: Auto-resize on table headings
Hi, On Wed, Sep 30, 2009 at 6:52 AM, Diogo Baeder diogobae...@gmail.com wrote: I was using my Ubuntu Jaunty, here, and noticed something that could be usefull, that Windows (argh!) GUI already has: auto-resize on table headings. In a Windows XP system, when a user double-clicks at the table column separators, the column to the left resizes to fit the largest content of the rows. Wouldn't it be a usefull feature? Let me know your opinions on it... This has already been implemented in GtkTreeView (I think since 2.0). regards, -kris. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Error in gthread.h?
Hello people. After a month of switching to 64 bits, I'm still recompiling old software. Most of this goes really very smoothly, but today I hit a snag for which I can't seem to find a solution. I get this error during compilation of my program: /usr/include/glib-2.0/glib/gthread.h: In function ‘g_once_init_enter’: /usr/include/glib-2.0/glib/gthread.h:344: warning: cast to pointer from integer of different size The offending line is: if (G_LIKELY ((gpointer) g_atomic_pointer_get (value_location) != NULL)) return FALSE; else return g_once_init_enter_impl (value_location); Though the (gpointer) cast seems unnecessary (The definition I found already declares g_atomic_pointer_get as gpointer), I can't really find any other problem (removing the cast doesn't change anything). I've looked around the 'net, but can't find any reference to this problem. Please, suggestions! John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK+ 2.18.1
GTK+ 2.18.1 is now available for download at: ftp://ftp.gtk.org/pub/gtk/2.18/ http://download.gnome.org/sources/gtk+/2.18/ md5 sums: d6e0f982a84d393cd11e2ea90a9e3775 gtk+-2.18.1.tar.bz2 c98802383822742bfee88c8d0fad409e gtk+-2.18.1.tar.gz sha1 sums: c4874c76173eb9b6591cce1f4c94e40290f13732 gtk+-2.18.1.tar.bz2 9420ed1f4495325f1b1199b9210b2891e664593f gtk+-2.18.1.tar.gz This is the first bug fix release in the stable 2.18 series. GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Contributing GTK+ is a large project and relies on voluntary contributions. We are actively searching for new contributors in various areas and invite everyone to help project development. If you are willing to participate, please subscribe to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GtkTasks Overview of Changes from GTK+ 2.18.0 to 2.18.1 == * Client-side Windows: - Fix a problem with the F-Spot screensaver - Request native events that are necessary for grab emulation - Fixes for input device and extended input event handling - Allow up to 255 buttons in extended input events * OS X: - Improve handling of multi-monitor setups - Basic DND works - Other improvements * Filechooser: - Support Tracker 0.7 in the search code * Bugs fixed: 596423 Landscape pages are the wrong way around 588449 DnD doesn't work on GDK/Quartz 596080 Mention gtk-tooltip in gtk_widget_set_tooltip_window 596580 Blank rows in entry autocompletion 588649 extended input events sent to widgets that didn't... 596081 Update tracker support for version 0.7 596345 clicking empty space in backgrounds... 596494 New property cursor in 2.18's GdkWindow with wrong... 596012 popup menu position is horribly off on gdk quartz... 596250 Gdkcursor-quartz.c doesn't implement GDK_BLANK_CURSOR 586207 Printing dialog with a CUPS printer connected... * Translation updates: Assamese British English Czech Estonian French Galician German Hungarian Slovenian Spanish Swedish Thanks to all contributors: Marek Kasik Alexander Larsson Kristian Rietveld John Ralls Cody Russell Thomas Jaeger Xan Lopez Jürg Billeter Christian Dywan Adrian Johnson September 30, 2009 Matthias Clasen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Error in gthread.h?
On Wed, 30 Sep 2009 16:12:50 -0700 Brian J. Tarricone br...@tarricone.org wrote: if (G_LIKELY ((gpointer) g_atomic_pointer_get (value_location) != NULL)) return FALSE; else return g_once_init_enter_impl (value_location); It's just a warning. In this case, it's harmless. Might want to report it as a bug, though. I think you've hit a semi-bug in gatomic.h -- if G_ATOMIC_OP_MEMORY_BARRIER_NEEDED isn't defined, g_atomic_pointer_get just expands to a dereference of the argument, cast to gpointer. Since the argument passed is a gsize, they don't match -- though they should, because gsize should be a typedef for unsigned long on x86_64, which is a 64bit quantity... so maybe this is a problem, though something more about your installation of glib than an actual bug. Hard to say. Mmmm... I hadn't realized that this might have something to do with the compatibility libraries I installed a week ago. They installed well, and I have googleearth running, but they may have broken compilation in 64 bit mode. I also received the following: /usr/include/glib-2.0/gio/gioenums.h:561: error: ‘GLIB_SYSDEF_AF_INET’ undeclared here (not in a function) /usr/include/glib-2.0/gio/gioenums.h:562: error: ‘GLIB_SYSDEF_AF_INET6’ undeclared here (not in a function) And I can't seem to find a definition of those macros anywhere (not even in the glib source tree). I have no clue as to where to start looking for either issue. Or where best to search for help :( John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Error in gthread.h?
On Wed, 30 Sep 2009 16:38:10 -0700 Brian J. Tarricone bj...@cornell.edu wrote: That's odd. Are you sure you don't have mixed versions of glib installed somehow? I was convinced that I hadn't, because I installed both from Slackware 13.0 (32 and 64bit). But now I remember compiling Inkscape SVN, and that needed a more recent version of glib (and I had to use SVN because of problems with poppler). So, I'm supposing the install of the compat libraries overwrote the includes of the 64 bit version. If I re-install the (newer) 64 bit version of glib, will the 32 bit version remain functional, or do I have to make a 32 version too? John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Error in gthread.h?
On 09/30/2009 04:57 PM, John Coppens wrote: On Wed, 30 Sep 2009 16:38:10 -0700 Brian J. Tarricone bj...@cornell.edu wrote: That's odd. Are you sure you don't have mixed versions of glib installed somehow? I was convinced that I hadn't, because I installed both from Slackware 13.0 (32 and 64bit). But now I remember compiling Inkscape SVN, and that needed a more recent version of glib (and I had to use SVN because of problems with poppler). So, I'm supposing the install of the compat libraries overwrote the includes of the 64 bit version. If I re-install the (newer) 64 bit version of glib, will the 32 bit version remain functional, or do I have to make a 32 version too? Probably safest to do both... Stuff linked to the old version should continue to work as is, but you might encounter compilation/linker problems later on if you try to build a 32bit app against the newer headers that don't match the 32bit binaries. -brian ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Error in gthread.h?
On Wed, 30 Sep 2009 17:11:19 -0700 Brian J. Tarricone bj...@cornell.edu wrote: So, I'm supposing the install of the compat libraries overwrote the includes of the 64 bit version. If I re-install the (newer) 64 bit version of glib, will the 32 bit version remain functional, or do I have to make a 32 version too? Probably safest to do both... Stuff linked to the old version should continue to work as is, but you might encounter compilation/linker problems later on if you try to build a 32bit app against the newer headers that don't match the 32bit binaries. Mystery solved, it appears. Slackware64 had the wrong environment variables set for pkg-config (/usr/lib and /usr/local/lib instead of the 64 bit versions). Thanks for the hints, Brian! John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: 2.90 branch
2009/9/30 Emmanuele Bassi eba...@gmail.com: sure. I asked around on #gtk+ after GUADEC for the best day/time to maximize attendance - the default being on Tuesday at 20:00 UTC. if anyone has issues with the day/time then feel free to contact me either on gtk-devel-list, in private or on IRC. otherwise, we can have a IRC meeting next Tuesday (October 6th); this should give people enough time to schedule stuff around. :-) +1 ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On Tue, 2009-09-29 at 22:59 +0200, Mark wrote: hehe that was the idea indeed ^_^ and i will continue with that. I will test the large factors tomorrow. For now i'm happy with 100% cpu usage on all my cores (4). with the code posted in my previous message i only had 70% cpu usage so there was a bottleneck and it wasn't the HDD nor the CPU. Now that's fixed with giving each thread more then one (5 actually) images of it's own before locking and refilling the queue of 5 so now there is 100% cpu usage in the multi threaded benchmark. http://codepad.org/PKnp69qW Ok, i tested this a bit, and my results are not the same as yours. I tested on a directory with 1348 jpeg files, each aroung 5 megapixels, totalling 3.1 gig of data. Before each test I ran (as root): sync; echo 3 /proc/sys/vm/drop_caches This flushes the caches, for two reasons: make the tests comparable (i.e. same cache status), and to make the test realistic (nobody thumbnails 3 gig of files that are all in the cache). You test is scaling to size 200, which is not the thumbnail size (128), but lets ignore that for now. // GLib Thumbnailing Benchmark There is a bug in the benchmark, where it saves the original pixbuf rather than the thumbnailed one, making this very very slow. When I fixed this i get this timing: real3m40.876s user3m19.667s sys 0m2.542s Same test but, using gnome_desktop_thumbnail_scale_down_pixbuf(): real3m34.784s user3m13.926s sys 0m2.479s So, for me gnome_desktop_thumbnail_scale_down_pixbuf() is ~3% faster (which makes some sense, as its using a simpler algorithm). Did you compile your benchmark app with full optimization? (since you have an in-line copy of the scale_down_pixbuf function this is required) (The rest of the tests are all run with gdk_pixbuf_scale_simple for easy comparison. // Glib more rapid thumbnailing benchmark real1m56.650s user1m24.030s sys 0m2.622s Here we can see that the jpeg loading trick really helps us. //Glib threaded thumbnailing My machine has 2 cores, not 4 as yours. With the default 4 threads: real2m2.194s user1m25.437s sys 0m2.982s Changed to use two threads: real1m53.783s user1m25.948s sys 0m2.966s If we use the same number of threads as cpus we go slightly faster (approximately 2.6% less time). However, if we use more things are actually slower. I've got 4 gigs of memory, so not everything will fit in the cache, but the caches would probably help a bit, to verify this i ran the same two-thread example without blowing the caches first: real1m36.681s user1m21.610s sys 0m2.501s So, slighly better, and we can see that the real time is getting nearer to the user time, which means that less time were spent waiting on disk. However, i'm not sure how interesting a cached benchmark is. Nobody will thumbnail the same files twice. Now, what does this mean for Nautilus Well, nautilus loads the files using gdk-pixbuf io-based resizing, which is essentially what Glib more rapid does. I.E. it uses the jpeg loading trick and scales using gdk_pixbuf_scale_simple. It calls gnome_desktop_thumbnail_scale_down_pixbuf() only when an external thumbnailer returns an oversize result (i.e. very seldom). Given the above result this is not ideal. The ideal would be to use the jpeg loader trick but then downscale with gnome_desktop_thumbnail_scale_down_pixbuf(), although that is hard to implement given the pixbuf APIs. Nautilus uses only one thread for thumbnailing, and upping this to the number of cpus of the machine could gain us a slight advantage, at the risk of starving the rest of nautilus by the increase in i/o traffic. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On Wed, Sep 30, 2009 at 11:46 AM, Alexander Larsson al...@redhat.com wrote: On Tue, 2009-09-29 at 22:59 +0200, Mark wrote: hehe that was the idea indeed ^_^ and i will continue with that. I will test the large factors tomorrow. For now i'm happy with 100% cpu usage on all my cores (4). with the code posted in my previous message i only had 70% cpu usage so there was a bottleneck and it wasn't the HDD nor the CPU. Now that's fixed with giving each thread more then one (5 actually) images of it's own before locking and refilling the queue of 5 so now there is 100% cpu usage in the multi threaded benchmark. http://codepad.org/PKnp69qW Ok, i tested this a bit, and my results are not the same as yours. I tested on a directory with 1348 jpeg files, each aroung 5 megapixels, totalling 3.1 gig of data. Before each test I ran (as root): sync; echo 3 /proc/sys/vm/drop_caches This flushes the caches, for two reasons: make the tests comparable (i.e. same cache status), and to make the test realistic (nobody thumbnails 3 gig of files that are all in the cache). You test is scaling to size 200, which is not the thumbnail size (128), but lets ignore that for now. // GLib Thumbnailing Benchmark There is a bug in the benchmark, where it saves the original pixbuf rather than the thumbnailed one, making this very very slow. When I fixed this i get this timing: real 3m40.876s user 3m19.667s sys 0m2.542s Same test but, using gnome_desktop_thumbnail_scale_down_pixbuf(): real 3m34.784s user 3m13.926s sys 0m2.479s So, for me gnome_desktop_thumbnail_scale_down_pixbuf() is ~3% faster (which makes some sense, as its using a simpler algorithm). Did you compile your benchmark app with full optimization? (since you have an in-line copy of the scale_down_pixbuf function this is required) (The rest of the tests are all run with gdk_pixbuf_scale_simple for easy comparison. // Glib more rapid thumbnailing benchmark real 1m56.650s user 1m24.030s sys 0m2.622s Here we can see that the jpeg loading trick really helps us. //Glib threaded thumbnailing My machine has 2 cores, not 4 as yours. With the default 4 threads: real 2m2.194s user 1m25.437s sys 0m2.982s Changed to use two threads: real 1m53.783s user 1m25.948s sys 0m2.966s If we use the same number of threads as cpus we go slightly faster (approximately 2.6% less time). However, if we use more things are actually slower. I've got 4 gigs of memory, so not everything will fit in the cache, but the caches would probably help a bit, to verify this i ran the same two-thread example without blowing the caches first: real 1m36.681s user 1m21.610s sys 0m2.501s So, slighly better, and we can see that the real time is getting nearer to the user time, which means that less time were spent waiting on disk. However, i'm not sure how interesting a cached benchmark is. Nobody will thumbnail the same files twice. Now, what does this mean for Nautilus Well, nautilus loads the files using gdk-pixbuf io-based resizing, which is essentially what Glib more rapid does. I.E. it uses the jpeg loading trick and scales using gdk_pixbuf_scale_simple. It calls gnome_desktop_thumbnail_scale_down_pixbuf() only when an external thumbnailer returns an oversize result (i.e. very seldom). Given the above result this is not ideal. The ideal would be to use the jpeg loader trick but then downscale with gnome_desktop_thumbnail_scale_down_pixbuf(), although that is hard to implement given the pixbuf APIs. Nautilus uses only one thread for thumbnailing, and upping this to the number of cpus of the machine could gain us a slight advantage, at the risk of starving the rest of nautilus by the increase in i/o traffic. Hi Alex, nice benching. i will fix that little issue in // GLib Thumbnailing Benchmark to save the thumbnail pixbuff. Then i hope the gnome_desktop_thumbnail_scale_down_pixbuf is really faster like it states. And if that's the case perhaps it's time to make a gdk_pixbuf_new_from_file_at_scale that uses gnome_desktop_thumbnail_scale_down_pixbuf. note that the scaling performance is just a minor part of the complete picture. If the loading/saving of files could be made faster in any way that would give the most speed boosts. As for full optimization to make it worse.. all my benchmarks where ren in debug compile mode. So not representative if did for one test but i did that for all tests so that probably makes it fair again..? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On Wed, 2009-09-30 at 12:36 +0200, Mark wrote: On Wed, Sep 30, 2009 at 11:46 AM, Alexander Larsson al...@redhat.com wrote: On Tue, 2009-09-29 at 22:59 +0200, Mark wrote: hehe that was the idea indeed ^_^ and i will continue with that. I will test the large factors tomorrow. For now i'm happy with 100% cpu usage on all my cores (4). with the code posted in my previous message i only had 70% cpu usage so there was a bottleneck and it wasn't the HDD nor the CPU. Now that's fixed with giving each thread more then one (5 actually) images of it's own before locking and refilling the queue of 5 so now there is 100% cpu usage in the multi threaded benchmark. http://codepad.org/PKnp69qW Ok, i tested this a bit, and my results are not the same as yours. I tested on a directory with 1348 jpeg files, each aroung 5 megapixels, totalling 3.1 gig of data. Before each test I ran (as root): sync; echo 3 /proc/sys/vm/drop_caches This flushes the caches, for two reasons: make the tests comparable (i.e. same cache status), and to make the test realistic (nobody thumbnails 3 gig of files that are all in the cache). You test is scaling to size 200, which is not the thumbnail size (128), but lets ignore that for now. // GLib Thumbnailing Benchmark There is a bug in the benchmark, where it saves the original pixbuf rather than the thumbnailed one, making this very very slow. When I fixed this i get this timing: real3m40.876s user3m19.667s sys 0m2.542s Same test but, using gnome_desktop_thumbnail_scale_down_pixbuf(): real3m34.784s user3m13.926s sys 0m2.479s So, for me gnome_desktop_thumbnail_scale_down_pixbuf() is ~3% faster (which makes some sense, as its using a simpler algorithm). Did you compile your benchmark app with full optimization? (since you have an in-line copy of the scale_down_pixbuf function this is required) (The rest of the tests are all run with gdk_pixbuf_scale_simple for easy comparison. // Glib more rapid thumbnailing benchmark real1m56.650s user1m24.030s sys 0m2.622s Here we can see that the jpeg loading trick really helps us. //Glib threaded thumbnailing My machine has 2 cores, not 4 as yours. With the default 4 threads: real2m2.194s user1m25.437s sys 0m2.982s Changed to use two threads: real1m53.783s user1m25.948s sys 0m2.966s If we use the same number of threads as cpus we go slightly faster (approximately 2.6% less time). However, if we use more things are actually slower. I've got 4 gigs of memory, so not everything will fit in the cache, but the caches would probably help a bit, to verify this i ran the same two-thread example without blowing the caches first: real1m36.681s user1m21.610s sys 0m2.501s So, slighly better, and we can see that the real time is getting nearer to the user time, which means that less time were spent waiting on disk. However, i'm not sure how interesting a cached benchmark is. Nobody will thumbnail the same files twice. Now, what does this mean for Nautilus Well, nautilus loads the files using gdk-pixbuf io-based resizing, which is essentially what Glib more rapid does. I.E. it uses the jpeg loading trick and scales using gdk_pixbuf_scale_simple. It calls gnome_desktop_thumbnail_scale_down_pixbuf() only when an external thumbnailer returns an oversize result (i.e. very seldom). Given the above result this is not ideal. The ideal would be to use the jpeg loader trick but then downscale with gnome_desktop_thumbnail_scale_down_pixbuf(), although that is hard to implement given the pixbuf APIs. Nautilus uses only one thread for thumbnailing, and upping this to the number of cpus of the machine could gain us a slight advantage, at the risk of starving the rest of nautilus by the increase in i/o traffic. Hi Alex, nice benching. i will fix that little issue in // GLib Thumbnailing Benchmark to save the thumbnail pixbuff. Then i hope the gnome_desktop_thumbnail_scale_down_pixbuf is really faster like it states. And if that's the case perhaps it's time to make a gdk_pixbuf_new_from_file_at_scale that uses gnome_desktop_thumbnail_scale_down_pixbuf. Its faster because it uses a simpler algorithm, so its not generally useful, however it might be nice to allow it optionally, like adding a new filter type and let you pass in a filter to the scaling loader. note that the scaling performance is just a minor part of the complete picture. If the loading/saving of files could be made faster in any way that would give the most speed boosts. Yes indeed. File load speed is very important here, but there really isn't that much you can do on the app side. As for full optimization to make it worse.. all my benchmarks where ren in debug compile mode. So not representative if did for
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On Wed, 2009-09-30 at 12:58 +0200, Mark wrote: Its faster because it uses a simpler algorithm, so its not generally useful, however it might be nice to allow it optionally, like adding a new filter type and let you pass in a filter to the scaling loader. the filter structure in glib seems... extremely complex. Lets first just make this FAST before we (or i) start try to make this as a new filter type. Also i think the bilinear filter type is just fine for me since it's just that only faster. glib, you mean gdk-pixbuf? And what do you mean by FAST? The gdk-pixbuf implementation is a bilinear filter, which inherently is more expensive than the simple filter in scale_down_pixbuf. scale_down_pixbuf() is really a pretty bad filter for most usecases, but it doesn't matter much for the thumbnailing case. note that the scaling performance is just a minor part of the complete picture. If the loading/saving of files could be made faster in any way that would give the most speed boosts. Yes indeed. File load speed is very important here, but there really isn't that much you can do on the app side. And is there anything possible in glib? The thing i noticed in earlier posts (from late last month in this thread) is that there is a big usage of gpointers... so perhaps it's possible to optimize something there? gpointers? Not sure what you are talking about. The problem is inherent in the fact that it needs to do i/o reading bits from rotating media. As for full optimization to make it worse.. all my benchmarks where ren in debug compile mode. So not representative if did for one test but i did that for all tests so that probably makes it fair again..? Only if you compiled your gdk-pixbuf library with debug mode, and even then its not certain because it has assembler versions of the scaler i think. It would be fair if you used the optimized version of gnome_desktop_thumbnail_scale_down_pixbuf() from libgnomedesktop though. That is this one right: http://git.gnome.org/cgit/gnome-desktop/tree/libgnome-desktop/gnome-thumbnail-pixbuf-utils.c ? that is the one i included in the benchmark. If that isn't the one you mean then which one is it? (link please) Yes, that is the source code, but if you use the copy in libgnomedesktop it will be built with optimization, if you use the copy in your code it will be built with no optimization. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
Hi, On Wed, 2009-09-30 at 11:46 +0200, Alexander Larsson wrote: On Tue, 2009-09-29 at 22:59 +0200, Mark wrote: hehe that was the idea indeed ^_^ and i will continue with that. I will test the large factors tomorrow. For now i'm happy with 100% cpu usage on all my cores (4). with the code posted in my previous message i only had 70% cpu usage so there was a bottleneck and it wasn't the HDD nor the CPU. Now that's fixed with giving each thread more then one (5 actually) images of it's own before locking and refilling the queue of 5 so now there is 100% cpu usage in the multi threaded benchmark. http://codepad.org/PKnp69qW Ok, i tested this a bit, and my results are not the same as yours. I tested on a directory with 1348 jpeg files, each aroung 5 megapixels, totalling 3.1 gig of data. did you try testing with an already thumbnailed directory ? I find Nautilus quite slow in this case (sorry, I'm not at home right now do I can't test), although if I understand correctly there's not much work to do. Xav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On Wed, 2009-09-30 at 14:53 +0200, Xavier Bestel wrote: Hi, On Wed, 2009-09-30 at 11:46 +0200, Alexander Larsson wrote: On Tue, 2009-09-29 at 22:59 +0200, Mark wrote: hehe that was the idea indeed ^_^ and i will continue with that. I will test the large factors tomorrow. For now i'm happy with 100% cpu usage on all my cores (4). with the code posted in my previous message i only had 70% cpu usage so there was a bottleneck and it wasn't the HDD nor the CPU. Now that's fixed with giving each thread more then one (5 actually) images of it's own before locking and refilling the queue of 5 so now there is 100% cpu usage in the multi threaded benchmark. http://codepad.org/PKnp69qW Ok, i tested this a bit, and my results are not the same as yours. I tested on a directory with 1348 jpeg files, each aroung 5 megapixels, totalling 3.1 gig of data. did you try testing with an already thumbnailed directory ? I find Nautilus quite slow in this case (sorry, I'm not at home right now do I can't test), although if I understand correctly there's not much work to do. This benchmark was not nautilus, but a separate test app. Nautilus being slow loading existing thumbnails is another thing. Partly it is due to the way the thumbnail spec stores things (see the xdg list for ways of making it better) and partly just loading lots of small files being slow on rotating media. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gobject-performance
On Thu, 2009-09-24 at 15:37 +0200, Benjamin Otte wrote: Hi, I'd like to move the work done on the gobject-performance branch to master now that 2.22.0 is out. It contains tremendous improvements for threaded applications and even noticably speeds up non-threaded performance. The patches on the branch have been developed, reviewed and tested by at least Alex Larsson, Edward Hevery and me, so it should be sufficiently reviewed. I'd have liked to get Tim to review it, but he seems to be quite busy now and IMO we threw enough eyes and CPU time at the issue to be sure there is no regressions. (From the tests we added, I'd even say it's more stable than master). I'd also like to get it merged while we're far away from the next release, so it gets enough testing, as these changes are quite deep down the stack and we want to find remaining issues with them before we release the next stable. So can we merge the branch or is there anything that we should take care of before? Man, this situation with such low maintainer activity in gobject is getting out of hand. We really need a way to get important fixes like this into gobject in finite amount of time. After all gobject is the core of the whole gtk and gnome platform, if we can't get fixes into it then we're in a very bad shape. I realize that GObject is a very complex and important piece of software and that timj knows it much better than anyone else. However, we just cannot totally stop work on it when timj is busy with other things. Now, some stuff in the gobject-performance branch is pretty trivial, but some of it is extremely complex (lock free stuff, atomic refcounting etc), so I don't really like to just wait a bit and then commit without timj approval. However, I'd like to have *some* way of getting things in, while still having a decent chance of finding problems before they land in glib. What about introducing some sort of ack rules. If you can get, say, three detailed reviews with acks from well known developers (core people, maintainers, etc) then we can commit stuff during to the unstable branch. Opinions? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gobject-performance
On Wed, 2009-09-30 at 15:06 +0200, Alexander Larsson wrote: [CUT] On Thu, 2009-09-24 at 15:37 +0200, Benjamin Otte wrote: What about introducing some sort of ack rules. If you can get, say, three detailed reviews with acks from well known developers (core people, maintainers, etc) then we can commit stuff during to the unstable branch. I'm not petitioning to become such a reviewer, as I don't think I'd be a very good one. But I like this idea very much. I propose to ask Jürg Billeter to help review gobject patches. With his work on Vala Jürg seems to have an in-depth knowledge of gobject. Opinions? Thanks a lot for trying to get things moving here, Alex. Appreciated. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On Fri, 2009-08-28 at 22:11 +0200, Mark wrote: Now for the results: Glib -- 1927 images thumbnailed in 2.29 minutes. That is roughly 0.07 seconds per thumbnail GraphicsMagick -- 1927 images thumbnailed in 3.08 minutes. That is roughly 0.09 seconds per thumbnail FreeImage -- 1927 images thumbnailed in 5.45 minutes. That is roughly 0.17 seconds per thumbnail You want to override GdkPixbuf's support for Jpeg and thumbnail all JPEG images using EPeg. It'll beat GdkPixbuf by 5 times or something. That's because afaik does EPeg use libjpeg in a way that it skips rows and columns, and that way performs better on both I/O (having to read less of the original), memory (same reason) and CPU (having to decompress less, having to scale less or nothing). We are already using EPeg for this on the Maemo Fremantle platform, by the way. Scaling truly large JPEG images goes magically fast with it. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On 09/30/2009 09:27 AM, Philip Van Hoof wrote: You want to override GdkPixbuf's support for Jpeg and thumbnail all JPEG images using EPeg. It'll beat GdkPixbuf by 5 times or something. That's because afaik does EPeg use libjpeg in a way that it skips rows and columns, and that way performs better on both I/O (having to read less of the original), memory (same reason) and CPU (having to decompress less, having to scale less or nothing). Is there any reason not to use epeg in the gdk-pixbuf jpeg loader itself? - Mike ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GIOChannel missing ftell() equivalent
I'm converting a program from C standard library to glib and stumbled on the fact that there is no equivalent for ftell() on GIOChannels. Could you please implement that? Or is there a deep reason why this doesn't exist? -- Gerhard ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On Wed, Sep 30, 2009 at 3:27 PM, Philip Van Hoof s...@pvanhoof.be wrote: On Fri, 2009-08-28 at 22:11 +0200, Mark wrote: Now for the results: Glib -- 1927 images thumbnailed in 2.29 minutes. That is roughly 0.07 seconds per thumbnail GraphicsMagick -- 1927 images thumbnailed in 3.08 minutes. That is roughly 0.09 seconds per thumbnail FreeImage -- 1927 images thumbnailed in 5.45 minutes. That is roughly 0.17 seconds per thumbnail You want to override GdkPixbuf's support for Jpeg and thumbnail all JPEG images using EPeg. It'll beat GdkPixbuf by 5 times or something. That's because afaik does EPeg use libjpeg in a way that it skips rows and columns, and that way performs better on both I/O (having to read less of the original), memory (same reason) and CPU (having to decompress less, having to scale less or nothing). We are already using EPeg for this on the Maemo Fremantle platform, by the way. Scaling truly large JPEG images goes magically fast with it. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be sounds interesting. A few questions for that lib: - Where can it be downloaded (i only found the documentation of it) - Can it be used on it's own without a need of including other dependencies other then libjpeg? - Are there any benchmarks existing? preferably compared to GdkPixbuff and beating it by 5 times is unlikely. My threaded test took ~30 seconds that would mean with epeg it can take just 6 seconds.. i just doubt that's possible for my 1927 image test. Thanx, Mark ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On Wed, 2009-09-30 at 15:27 +0200, Philip Van Hoof wrote: On Fri, 2009-08-28 at 22:11 +0200, Mark wrote: Now for the results: Glib -- 1927 images thumbnailed in 2.29 minutes. That is roughly 0.07 seconds per thumbnail GraphicsMagick -- 1927 images thumbnailed in 3.08 minutes. That is roughly 0.09 seconds per thumbnail FreeImage -- 1927 images thumbnailed in 5.45 minutes. That is roughly 0.17 seconds per thumbnail You want to override GdkPixbuf's support for Jpeg and thumbnail all JPEG images using EPeg. It'll beat GdkPixbuf by 5 times or something. That's because afaik does EPeg use libjpeg in a way that it skips rows and columns, and that way performs better on both I/O (having to read less of the original), memory (same reason) and CPU (having to decompress less, having to scale less or nothing). We are already using EPeg for this on the Maemo Fremantle platform, by the way. Scaling truly large JPEG images goes magically fast with it. I'm not sure EPeg is really that magic. For instance, this: http://www.freshports.org/graphics/epeg says: It makes use of libjpeg features of being able to load an image by only decoding the DCT coefficients needed to reconstruct an image of the size desired. This gives a massive speedup. If you do not try and access the pixels in a format other than YUV (or GRAY8 if the source is grascale) then it also avoids colorspace conversions as well. The first part (DCT stuff) we already do in the jpeg loader (its the jpeg loader trick talked about above). The second we could easily do ourself in the jpeg loader for scaled image loads by scaling in YUV/GRAY8 space before converting. I'd love if someone would like to work on this in gdk-pixbuf. Another thumbnailing performance trick is to use thumbnails in EXIF data, which many cameras add, if availible. This is slightly more dubious to do in gdk-pixbuf as the thumbnail is not 100% reliable (i.e. it may be out of date due to file modifications or whatnot). So, something like this really has to be done in the gnome-desktop thumbnailer code. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On Wed, 2009-09-30 at 16:07 +0200, Alexander Larsson wrote: The first part (DCT stuff) we already do in the jpeg loader (its the jpeg loader trick talked about above). The second we could easily do ourself in the jpeg loader for scaled image loads by scaling in YUV/GRAY8 space before converting. Of course, most jpegs are in the RGB colorspace, so this is not perhaps so important in practice. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On Wed, 2009-09-30 at 16:05 +0200, Mark wrote: On Wed, Sep 30, 2009 at 3:27 PM, Philip Van Hoof s...@pvanhoof.be wrote: sounds interesting. A few questions for that lib: - Where can it be downloaded (i only found the documentation of it) The websites Alexander pointed to in his reply have pointers to source code. I don't think it has an upstream repository anymore, just source packages of distributions. - Can it be used on it's own without a need of including other dependencies other then libjpeg? Yes - Are there any benchmarks existing? preferably compared to GdkPixbuff Problem with the benchmarks that I used is that they are proprietary. But you get most difference with large JPEG images. So take any large JPEG image and test it. The code to write an EPeg based thumbnailer is about 12 lines. The hildon-thumbnailer code got a bit messy and we have started redoing this together with the XFCE people as the Tumbler project, but you can find Fremantle's EPeg based thumbnailer plugin here: http://gitorious.org/maemo-af/hildon-thumbnail/blobs/master/daemon/plugins/epeg-plugin.c and beating it by 5 times is unlikely. My threaded test took ~30 seconds that would mean with epeg it can take just 6 seconds.. i just doubt that's possible for my 1927 image test. Nod, that's the kind of differences that we measured ;) Which is also why we didn't hesitate to just switch to using it. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On Wed, Sep 30, 2009 at 4:58 PM, Alexander Larsson al...@redhat.com wrote: On Wed, 2009-09-30 at 16:07 +0200, Alexander Larsson wrote: On Wed, 2009-09-30 at 15:27 +0200, Philip Van Hoof wrote: On Fri, 2009-08-28 at 22:11 +0200, Mark wrote: Now for the results: Glib -- 1927 images thumbnailed in 2.29 minutes. That is roughly 0.07 seconds per thumbnail GraphicsMagick -- 1927 images thumbnailed in 3.08 minutes. That is roughly 0.09 seconds per thumbnail FreeImage -- 1927 images thumbnailed in 5.45 minutes. That is roughly 0.17 seconds per thumbnail You want to override GdkPixbuf's support for Jpeg and thumbnail all JPEG images using EPeg. It'll beat GdkPixbuf by 5 times or something. That's because afaik does EPeg use libjpeg in a way that it skips rows and columns, and that way performs better on both I/O (having to read less of the original), memory (same reason) and CPU (having to decompress less, having to scale less or nothing). We are already using EPeg for this on the Maemo Fremantle platform, by the way. Scaling truly large JPEG images goes magically fast with it. I'm not sure EPeg is really that magic. For instance, this: http://www.freshports.org/graphics/epeg says: It makes use of libjpeg features of being able to load an image by only decoding the DCT coefficients needed to reconstruct an image of the size desired. This gives a massive speedup. If you do not try and access the pixels in a format other than YUV (or GRAY8 if the source is grascale) then it also avoids colorspace conversions as well. The first part (DCT stuff) we already do in the jpeg loader (its the jpeg loader trick talked about above). The second we could easily do ourself in the jpeg loader for scaled image loads by scaling in YUV/GRAY8 space before converting. I took a look at the epeg code, and in addition to both these it also sets dct_method to JDCT_IFAST (whereas gdk-pixbuf leaves this at the default slower but better one). Additionally it also uses NEAREST as a scaling algorithm, causing horrible looking thumbnails. Look at the attached images for comparison. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list Oh, that does look horrible and is even bigger in size... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On Wed, 2009-09-30 at 16:57 +0200, Philip Van Hoof wrote: I don't think it has an upstream repository anymore, just source packages of distributions. I do find that using software which lacks a maintainer and canonical repository is far preferable than software with a repository but no maintainer or -- dare I say it -- maintained software. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On Wed, 2009-09-30 at 16:07 +0200, Alexander Larsson wrote: Another thumbnailing performance trick is to use thumbnails in EXIF data, which many cameras add, if availible. FWIW, we do this in the gphoto2:// GVfs backend. Browsing through a USB connected camera in Nautilus is really fast these days; the thumbnails are 20ish KB (vs. several MB for common consumer cameras). So this matters _a lot_ when reading from a camera where you only get throughput of a couple of MB/s at best. (Btw, this infrastructure is not specific to the gphoto2:// GVfs backend; any GVfs backend can use it - say, a Flickr backend). This is slightly more dubious to do in gdk-pixbuf as the thumbnail is not 100% reliable (i.e. it may be out of date due to file modifications or whatnot). Another problem is that the embedded thumbnail may not be properly rotated (on some cameras). This is not a huge problem, just an annoyance and for gphoto2:// connected devices this tradeoff of quirky behavior vs performance is justified. For browsing local filesystems it may or may not be justified. David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On Wed, 2009-09-30 at 12:32 -0400, David Zeuthen wrote: (Btw, this infrastructure is not specific to the gphoto2:// GVfs backend; any GVfs backend can use it - say, a Flickr backend). Bad example, downloading the original file (no seeking in HTTP) just to extract the thumbnail would be pretty silly considering that Flickr allows direct access to thumbnails (and other sizes) through its API. :) Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On Wed, 2009-09-30 at 17:51 +0100, Ross Burton wrote: On Wed, 2009-09-30 at 12:32 -0400, David Zeuthen wrote: (Btw, this infrastructure is not specific to the gphoto2:// GVfs backend; any GVfs backend can use it - say, a Flickr backend). Bad example, downloading the original file (no seeking in HTTP) just to extract the thumbnail would be pretty silly considering that Flickr allows direct access to thumbnails (and other sizes) through its API. :) Got that wrong. David was talking about out-of-band thumbnails (gphoto2 can export that data as an attribute of the file, without downloading the whole file). So you are in agreement... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On Wed, 2009-09-30 at 17:51 +0100, Ross Burton wrote: On Wed, 2009-09-30 at 12:32 -0400, David Zeuthen wrote: (Btw, this infrastructure is not specific to the gphoto2:// GVfs backend; any GVfs backend can use it - say, a Flickr backend). Bad example, downloading the original file (no seeking in HTTP) just to extract the thumbnail would be pretty silly considering that Flickr allows direct access to thumbnails (and other sizes) through its API. :) No, it's actually a great example. The way it works is that a GVfs backend can set the preview::icon file attribute (which is a GIcon) [1] to whatever it wants. In GVfs we have a class, GVfsIcon, that implements GLoadableIcon and GIcon. When clients read preview::icon, then the loading of the returned icon is directed back to the backend via the open_icon_for_read() VFunc on the GVfsBackend class. The backend can then use any API it wants to get/create the thumbnail. It is completely unrelated to the file in question. David [1] : http://library.gnome.org/devel/gio/unstable/GFileInfo.html#G-FILE-ATTRIBUTE-PREVIEW-ICON--CAPS ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On Wed, 2009-09-30 at 18:01 +0100, Bastien Nocera wrote: On Wed, 2009-09-30 at 17:51 +0100, Ross Burton wrote: On Wed, 2009-09-30 at 12:32 -0400, David Zeuthen wrote: (Btw, this infrastructure is not specific to the gphoto2:// GVfs backend; any GVfs backend can use it - say, a Flickr backend). Bad example, downloading the original file (no seeking in HTTP) just to extract the thumbnail would be pretty silly considering that Flickr allows direct access to thumbnails (and other sizes) through its API. :) Got that wrong. David was talking about out-of-band thumbnails (gphoto2 can export that data as an attribute of the file, without downloading the whole file). So you are in agreement... Ah, right, gotcha. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On Wed, 2009-09-30 at 13:06 -0400, David Zeuthen wrote: No, it's actually a great example. The way it works is that a GVfs backend can set the preview::icon file attribute (which is a GIcon) [1] to whatever it wants. In GVfs we have a class, GVfsIcon, that implements GLoadableIcon and GIcon. When clients read preview::icon, then the loading of the returned icon is directed back to the backend via the open_icon_for_read() VFunc on the GVfsBackend class. The backend can then use any API it wants to get/create the thumbnail. It is completely unrelated to the file in question. I take it back, that is neat. :) Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ 2.18.1
GTK+ 2.18.1 is now available for download at: ftp://ftp.gtk.org/pub/gtk/2.18/ http://download.gnome.org/sources/gtk+/2.18/ md5 sums: d6e0f982a84d393cd11e2ea90a9e3775 gtk+-2.18.1.tar.bz2 c98802383822742bfee88c8d0fad409e gtk+-2.18.1.tar.gz sha1 sums: c4874c76173eb9b6591cce1f4c94e40290f13732 gtk+-2.18.1.tar.bz2 9420ed1f4495325f1b1199b9210b2891e664593f gtk+-2.18.1.tar.gz This is the first bug fix release in the stable 2.18 series. GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Contributing GTK+ is a large project and relies on voluntary contributions. We are actively searching for new contributors in various areas and invite everyone to help project development. If you are willing to participate, please subscribe to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GtkTasks Overview of Changes from GTK+ 2.18.0 to 2.18.1 == * Client-side Windows: - Fix a problem with the F-Spot screensaver - Request native events that are necessary for grab emulation - Fixes for input device and extended input event handling - Allow up to 255 buttons in extended input events * OS X: - Improve handling of multi-monitor setups - Basic DND works - Other improvements * Filechooser: - Support Tracker 0.7 in the search code * Bugs fixed: 596423 Landscape pages are the wrong way around 588449 DnD doesn't work on GDK/Quartz 596080 Mention gtk-tooltip in gtk_widget_set_tooltip_window 596580 Blank rows in entry autocompletion 588649 extended input events sent to widgets that didn't... 596081 Update tracker support for version 0.7 596345 clicking empty space in backgrounds... 596494 New property cursor in 2.18's GdkWindow with wrong... 596012 popup menu position is horribly off on gdk quartz... 596250 Gdkcursor-quartz.c doesn't implement GDK_BLANK_CURSOR 586207 Printing dialog with a CUPS printer connected... * Translation updates: Assamese British English Czech Estonian French Galician German Hungarian Slovenian Spanish Swedish Thanks to all contributors: Marek Kasik Alexander Larsson Kristian Rietveld John Ralls Cody Russell Thomas Jaeger Xan Lopez Jürg Billeter Christian Dywan Adrian Johnson September 30, 2009 Matthias Clasen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
filesystemmodel branch - initial testing
Humans from Earth, I'm finally testing Company's filesystemmodel branch. IT IS SO FAST! Really, it makes the file chooser much snappier. And the code is a pleasure to read. I haven't had crashes yet, although I haven't tested all the features in the file chooser. I guess I'll keep testing it for a week or so. Matthias mentioned that he's interested in merging this to master before the .2 release. I'm extremely happy with Company's work - he deserves a lot of beer and pats on the back. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: filesystemmodel branch - initial testing
On Wed, 2009-09-30 at 19:45 -0500, Federico Mena Quintero wrote: Humans from Earth, I'm finally testing Company's filesystemmodel branch. IT IS SO FAST! Really, it makes the file chooser much snappier. And the code is a pleasure to read. I haven't had crashes yet, although I haven't tested all the features in the file chooser. I guess I'll keep testing it for a week or so. Matthias mentioned that he's interested in merging this to master before the .2 release. I'm extremely happy with Company's work - he deserves a lot of beer and pats on the back. Not having looked at the code since the original patches, have all the concerns about the possible regressions and incremental changes been addressed? Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: filesystemmodel branch - initial testing
On Thu, Oct 1, 2009 at 3:45 AM, Federico Mena Quintero feder...@novell.com wrote: Humans from Earth, I'm finally testing Company's filesystemmodel branch. IT IS SO FAST! Really, it makes the file chooser much snappier. And the code is a pleasure to read. I haven't had crashes yet, although I haven't tested all the features in the file chooser. I guess I'll keep testing it for a week or so. Matthias mentioned that he's interested in merging this to master before the .2 release. From that I take that the plan is to release this in 2.18.2? Wouldn't it be a much better idea to only go for it in the unstable 2.19.x series? At least this is not the kind of change I'd expect to receive in a minor incremental bugfix release of the stable series. I'm extremely happy with Company's work - he deserves a lot of beer and pats on the back. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ 2.18.1
GTK+ 2.18.1 is now available for download at: ftp://ftp.gtk.org/pub/gtk/2.18/ http://download.gnome.org/sources/gtk+/2.18/ md5 sums: d6e0f982a84d393cd11e2ea90a9e3775 gtk+-2.18.1.tar.bz2 c98802383822742bfee88c8d0fad409e gtk+-2.18.1.tar.gz sha1 sums: c4874c76173eb9b6591cce1f4c94e40290f13732 gtk+-2.18.1.tar.bz2 9420ed1f4495325f1b1199b9210b2891e664593f gtk+-2.18.1.tar.gz This is the first bug fix release in the stable 2.18 series. GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Contributing GTK+ is a large project and relies on voluntary contributions. We are actively searching for new contributors in various areas and invite everyone to help project development. If you are willing to participate, please subscribe to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GtkTasks Overview of Changes from GTK+ 2.18.0 to 2.18.1 == * Client-side Windows: - Fix a problem with the F-Spot screensaver - Request native events that are necessary for grab emulation - Fixes for input device and extended input event handling - Allow up to 255 buttons in extended input events * OS X: - Improve handling of multi-monitor setups - Basic DND works - Other improvements * Filechooser: - Support Tracker 0.7 in the search code * Bugs fixed: 596423 Landscape pages are the wrong way around 588449 DnD doesn't work on GDK/Quartz 596080 Mention gtk-tooltip in gtk_widget_set_tooltip_window 596580 Blank rows in entry autocompletion 588649 extended input events sent to widgets that didn't... 596081 Update tracker support for version 0.7 596345 clicking empty space in backgrounds... 596494 New property cursor in 2.18's GdkWindow with wrong... 596012 popup menu position is horribly off on gdk quartz... 596250 Gdkcursor-quartz.c doesn't implement GDK_BLANK_CURSOR 586207 Printing dialog with a CUPS printer connected... * Translation updates: Assamese British English Czech Estonian French Galician German Hungarian Slovenian Spanish Swedish Thanks to all contributors: Marek Kasik Alexander Larsson Kristian Rietveld John Ralls Cody Russell Thomas Jaeger Xan Lopez Jürg Billeter Christian Dywan Adrian Johnson September 30, 2009 Matthias Clasen ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Manipulating a GtkComboBox like a GtkTreeView.
I've got a GtkListStore as the model for a GtkComboBox. I'd like to be able to call gtk_tree_view_set_show_lines() and gtk_tree_view_expand_all(), but obviously a GtkComboBox is not a GtkTreeView... Is it possible to do this with a GtkComboBox? If not... is there at least a way to expand certain rows? ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
State of Gtk+-2.18 On Windows
Hi All, As I am currenlty unable to test, could someone please advise me on the state of Gtk+-2.18 on windows? Has it been ported to support the new client side windows work? Regards John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: State of Gtk+-2.18 On Windows
As I am currenlty unable to test, could someone please advise me on the state of Gtk+-2.18 on windows? Try it, there are binaries in http://ftp.gnome.org/pub/GNOME/binaries/win32/gtk+/2.18/ . You will need up-to-date dependencies too, in hopefully self-evident locations near to that. Has it been ported to support the new client side windows work? I don't know if ported is the right term here. As I understand it, client side windows code was from the start written for the Windows backend, too. How well it works is another question. I have heard that some complex applications behave wildly erratically with GTK+. gtk-demo seems to work fine, though. The ms-windows theme engine doesn't work nicely in GTK+ 2.18, so I don't include it in the binaries above. This is unfortunate. This is a problem in the ms-windows theme engine code, it needs to be modified to work with client-side windows. Also, using the GDK_NATIVE_WINDOWS environment variable to fall back to non-client-side-windows code causes erratic behaviour and crashes, just in gtk-demo even. But otherwise it seems to work... --tml ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
