Re: [Quartz] Gtk Selection
On Jun 8, 2010, at 5:42 PM, John Ralls wrote: > It's too early for requirements. First we need to figure out what to > abstract, and whether each abstraction really belongs in Gdk or should be > moved "up" to Gtk (like clipboards) or "down" to Glib (like string > conversions). Wikis are like whiteboards: They're a useful aid to a > discussion but not a vehicle for the discussion itself. > > So if you want to start a wiki page, maybe you start a list of what Gdk > abstracts, and we can discuss here where (i.e., GLib, Gdk, Gtk, or somewhere > else, including Cairo and Pango) each of those abstractions belong. We could > also consider whether there are abstractions in other libraries which would > fit more naturally into Gdk. This is actually more or less what I meant. Listing what GDK abstracts and start drafting how this may be improved. I think "requirements" was the wrong choice of words on my side :) regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GApplication and GtkApplication oddness
With GApplication we have:
application = g_application_new_and_register
("org.gnome.ColorManager.Prefs", argc, argv);
and with GtkApplication we have:
application = gtk_application_new (argc, argv,
"org.gnome.ColorManager.Prefs");
It does seem slightly odd that the former has the appid first, and the
latter has it last. I'm not sure it matters much, but I figured
feedback might be useful.
Richard.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Is it a bug in Gio::FileMonitor?
On Wed, 2010-06-02 at 04:26 +0300, Владимир wrote: > > On Tue, Jun 1, 2010 at 12:57 PM, Alexander Larsson > wrote: > On Mon, 2010-05-31 at 17:36 +0300, Владимир wrote: > > > There is nothing "server" about change notification > coalesceing. If any > app downloads or copies a file you'll get a change event for > every call > to write() (if you read all events). This can easily be in the > hundreds > a second for the entire duration of the download/copy. So, any > UI that > tries to handle every change will more or less lock up. > > > You're talking about gio, I wanted to see what inotify would do in > same circumstances: > > > I started inotify to listen to all the events on my desktop folder, > then I took a large zip file (about 500MB) and started copying it to > the desktop folder. There was no "hundreds a second" events, just 4 > (four) events: IN_CREATE, then IN_OPEN, then IN_CLOSE_WRITE and > finally (as the copy finished) IN_ATTRIB. > > So inotify doesn't suffer from the Armageddon you describe, also it's > fast. How come gio would be doomed/overworked in such a scenario and > it's slow at reporting even 1 file change quickly. Yes, because you didn't select for file change events, only creation and close-write. This means you won't get any updates to a file that changes but is not closed. For instance a log file or just a long download. > Sorry I don't mean to be harsh but after these conversations I'm > really starting to like inotify a lot more and disliking gio. I don't think gio is perfect, the inotify backend in particular is kinda crufty and ugly. If a hard dependency on inotify works for you, by all means go for it! -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an underprivileged alcoholic dwarf with a winning smile and a way with the ladies. She's a sarcastic junkie pearl diver on the trail of a serial killer. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Print dialog hangs for several seconds before activating
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: 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: Is it a bug in Gio::FileMonitor?
I said I listened to "all the events", not just some, in particular IN_ATTRIB stands for "File's metadata (inode or xattr) was changed.". That is, I used IN_ALL_EVENTS which stands for "Bitwise OR of all events.". I also think it's sad that instead of a reaction like "hey, he's got a point, this issue does make apps feel sluggish so we should investigate into it, after all even Java (7) which is also cross-platform doesn't suffer from this", there's instead quite the opposite reaction to not improve, like "if we do this, a bad side effect will happen (and if you prove we're wrong about it we'll find another noble excuse) or just say nothing is perfect". And thanks, I already went for inotify because clients/users want quality, not noble excuses. On Wed, Jun 2, 2010 at 2:26 PM, Alexander Larsson wrote: > On Wed, 2010-06-02 at 04:26 +0300, Владимир wrote: > > > > On Tue, Jun 1, 2010 at 12:57 PM, Alexander Larsson > > wrote: > > On Mon, 2010-05-31 at 17:36 +0300, Владимир wrote: > > > > > > There is nothing "server" about change notification > > coalesceing. If any > > app downloads or copies a file you'll get a change event for > > every call > > to write() (if you read all events). This can easily be in the > > hundreds > > a second for the entire duration of the download/copy. So, any > > UI that > > tries to handle every change will more or less lock up. > > > > > > You're talking about gio, I wanted to see what inotify would do in > > same circumstances: > > > > > > I started inotify to listen to all the events on my desktop folder, > > then I took a large zip file (about 500MB) and started copying it to > > the desktop folder. There was no "hundreds a second" events, just 4 > > (four) events: IN_CREATE, then IN_OPEN, then IN_CLOSE_WRITE and > > finally (as the copy finished) IN_ATTRIB. > > > > So inotify doesn't suffer from the Armageddon you describe, also it's > > fast. How come gio would be doomed/overworked in such a scenario and > > it's slow at reporting even 1 file change quickly. > > Yes, because you didn't select for file change events, only creation and > close-write. This means you won't get any updates to a file that changes > but is not closed. For instance a log file or just a long download. > > > Sorry I don't mean to be harsh but after these conversations I'm > > really starting to like inotify a lot more and disliking gio. > > I don't think gio is perfect, the inotify backend in particular is kinda > crufty and ugly. If a hard dependency on inotify works for you, by all > means go for it! > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander LarssonRed Hat, Inc > al...@redhat.comalexander.lars...@gmail.com > He's an underprivileged alcoholic dwarf with a winning smile and a way with > the ladies. She's a sarcastic junkie pearl diver on the trail of a serial > killer. They fight crime! > > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
