Re: Print dialog hangs for several seconds before activating
I've run into this issue (and have been poking at it recently). The core problem appears to be that, although GTK+ is using CUPS and setting things like httpBlocking off, the CUPS "non-blocking" API isn't. See conversations with CUPS developers at [1,2,3]. It appears that the only sane way to interact with CUPS in a GUI application is to use separate threads. If folks do not object the change, I'll try my hand at them. David [1] http://www.cups.org/newsgroups.php?s3708+gcups.development+v3713+T0 [2] http://www.cups.org/newsgroups.php?s3708+gcups.development+v3714+T0 [3] http://www.cups.org/newsgroups.php?s3708+gcups.development+v3716+T0 On Wed, 9 Jun 2010, Shawn Bakhtiar wrote: For some reason the Print dialog hangs for several seconds before fully activating. During this period I am unable to push any buttons and on my OS X 10.6.3, I get the little color wheel. After a few seconds, The dialog pops bigger, with several added tabs show up at the top (printer info). jhbuild info Name: gtk-i386 Module Set: gtk-osx-universal Type: autogen Install-date: not installed URL: http://ftp.gnome.org/gtk+/2.16/gtk+-2.18.2.tar.bz2 Version: 2.18.2 Tree-ID: 2.18.2-d41d8cd98f00b204e9800998ecf8427e Required-by: meta-gtk-universal Name: glib Module Set: gtk-osx Type: autogen Install-date: 2010-03-22 16:31:17 URL: http://ftp.gnome.org/pub/GNOME/sources/glib/2.22/glib-2.22.2.tar.bz2 Version: 2.22.2 Tree-ID: 2.22.2-d41d8cd98f00b204e9800998ecf8427e Required-by: glibmm, gnome-mime-data, pango, enchant, shared-mime-info, libsoup, atk After: meta-gtk-osx-bootstrap, gtk-doc Before: loudmouth, gstreamer . According to google, there seems to be a bug everyone is working arround, I have as of yet to implement correctly on my machine. https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/475845 https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/475845/comments/29 https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/359975 http://serverfault.com/questions/104935/authinforequired-cups-overwrites Has anyone run into this problem, and is there a fix I am not aware of? Thanks in advance, Shawn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSpreadTable ('spread-table' branch)
On Thu, 7 Oct 2010, Tristan Van Berkom wrote: Some technical caveats: - When there are over ~12 columns the whole thing slows down significantly. The reason for this being, the algorithm in place starts by lining up all the widgets in the first column and then evening them out column by column... by the time we hit the 3rd column; columns 1 & 2 need to be recalculated for every widget we pull into the 3rd column, and so on as the columns grow. By the time we hit 12 columns things are getting exponentially heavier to calculate (I've tried simpler algorithms that were much further from perfect results than this one though). So, am I understanding your setup and code correctly? You have a number of columns of equal width that you wish to arrange some widgets into. The first few widgets get laid out vertically into the first column, the next into the next column, etc. And your goal is to minimize the height of the tallest column, computed as the sum of the heights of each widget (plus some padding between them). Is this correct? In that case, just binary search for the optimum height; bounds are the average and the total of the boxes. For a given candidate height, a greedy algorithm is sufficient to determine whether or not the height is viable. Just go through column-by-column and stuff widgets into the next column until you can't fit the next widget and move on to the next column. If you manage to fit them all, you have a valid height and valid assignment; try going smaller if you can. If you go through all the columns with widgets to spare, your height was too big; go larger. Running time is O(num_widgets * log(total_height)) with a very nice constant. In fact, I think this should work for variable-width columns, although you won't be able to cache the heights. (You can also do a DP, but I've only been able to get that down to O(num_widgets * num_columns * log(num_widgets)) thus far.) I can give the implementation a go sometime this weekend if no one else beats me to it. :-) David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkApplication and argc/arv
On Thu, 24 Feb 2011, Tristan Van Berkom wrote: On Thu, 2011-02-24 at 13:11 +0800, Wen-Yen Chuang wrote: c.) For stability Crash of one process will not affect other processes. Eh, ok... I don't really agree but the fact is you might sell that to a manager somewhere who wants to ship his unstable software early and say "it doesnt crash" at least most of the time, or "when it crashes" only one window crashes "so its ok to sell it to users". It's also worth noting that even Chromium/Chrome, which is not entirely unknown for splitting things into separate processes like this, is still a single-instance app, though not using GtkApplication. It manages many separate renderer processes, but the primary controlling browser process is single-instance. David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
