GTK clipboard fails after 3+ hours from wxGTK app
I'm trying to sort out why the clipboard copy/paste functionality of my wxGTK (wxWidgets on top of GTK) app fails on Debian/Ubuntu after a few hours of use. The app (through wxGTK) relies on gtk clipboard API: gtk_selection_data_set, gtk_selection_data_set_text, gtk_selection_owner_set, gtk_selection_add_target and gtk_selection_convert. It handles these GTK signals: "selection_received", "selection_clear_event" and "selection_get". The symptoms are as follows: - On app startup, copying in my app and pasting in an X-Term window works fine (X-Term requests UTF8 text format). The text is copied from "clipboard" (not "primary selection). - After some hours of use, copying text from our app to X-Term stops working. Looking at what goes on in a debugger reveals: -- The X-Term window is no longer requesting UTF8 plain text. Instead it seems to ask for a filename. -- Our app have not registered a filename as available in the clipboard, so pasting fails. -- I've checked in the debugger that our app goes through the identical clipboard format registration loop at this time (compared to when the program started). It does offer UTF8 plain text. Now I wonder what goes wrong at this point: - Is there some resource allocation failure (exhausting some pool of memory)? - It seems that registering UTF8 text for the text simply fails in some way after N+ hours of use. - What else could go wrong after having run the app for this time? Copying the other way around works fine (external app to ours). It seems to me wxGTK is using the clipboard in a slightly wrong way and this shows up when running the app for long time. Any help/hints at GTK level appreciated. Regards Arne Steinarson -- View this message in context: http://www.nabble.com/GTK-clipboard-fails-after-3%2B-hours-from-wxGTK-app-tp23508674p23508674.html Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: tree model
On Tue, 2009-05-12 at 14:05 +0300, Claudio Saavedra wrote: > totem-pl-parser is using GtkTreeModel as well. IIRC, tracker uses > totem-pl-parser to parse playlists, but I guess they are not interested > on GtkTreeView. It uses a GtkTreeModel, not a GtkTreeView, and only for the saving bits. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Review of gnio, round 1
On Tue, May 12, 2009 at 09:41:53AM -0400, Dan Winship wrote: > On 05/12/2009 05:22 AM, Paul LeoNerd Evans wrote: > > Speaking of GResolver, in the API (which I'm currently staring at here: > > > > http://git.gnome.org/cgit/glib/diff/gio/gresolver.h?h=gresolver&id=05507dce1f540581028e8be0e220e68c44fade2f > > > > ) I don't see any attempt at the gai()-style "hostname + servicename" > > resolver. Where's the ability to connect to, say, "www.google.com:http"? > > > > Half the point of gai+gni was to unify the separate operations of > > hostname->IP and servicename->port, so they're in one combined place. > > gai() can therefore support things like SRV records, which the previous > > pair of gethostbyname+getservbyname cannot. > > You're mixing up two very different things. getaddrinfo *does not* use > SRV records. When you pass a (non-numeric) string to getaddrinfo for > "service", it just looks that string up in /etc/services to translate it > to a port number, and returns that port number (regardless of whether or > not that service is really running on the host). Ah; I wasn't quite clear enough in my statement. I didn't mean that e.g. GNU libc's _implementation_ of getaddrinfo() currently today actually does a SRV lookup, merely the RFC 2553 _interface_ which defines getaddrinfo() has to hand all the information that such a lookup would require, so an implementation can, in theory, do it. > GResolver intentionally does not support doing the servicename->port > mapping thing that getaddrinfo/getsrvbyname does though, because it's a > bad API; you can't know for sure what's going to be in /etc/services on > any given machine, and in particular, if you're using some very new > protocol, it's very likely that some people are going to try to run your > application on machines that don't have that protocol listed in > /etc/services. So it's always better to just provide your own #define > FOOBAR_PORT with the right port number, and then use that, rather than > crossing your fingers and hoping that GResolver will be able to map > "foobar" to the right number for you. Hmm.. I guess that's fair enough then I suppose; though surely that's not a reason not to provide the _ability_ to do so, simply a discouragement for applications developers to try to actually make use of it, in this manner..? -- Paul "LeoNerd" Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: tree model
Matthias Clasen wrote: On Tue, May 12, 2009 at 9:50 AM, Ryan Lortie wrote: Since GtkTreeModel also has no reason to depend on (the rest of) GTK, it seems logical to move it into glib. It is not that GtkTreeModel depends on the rest of GTK+, it is more that GtkTreeModel is designed for being the model part of GtkTreeModel, not as a generic tree container. You could make the same argument about GtkBuilder, I suppose. I'm of the mind that that should also have been a generic GObject thing: GBuilder. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: tree model
On Tue, May 12, 2009 at 9:50 AM, Ryan Lortie wrote: > Since GtkTreeModel also has no > reason to depend on (the rest of) GTK, it seems logical to move it into > glib. It is not that GtkTreeModel depends on the rest of GTK+, it is more that GtkTreeModel is designed for being the model part of GtkTreeModel, not as a generic tree container. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: tree model
Thomas Wood wrote: I think the Clutter project has it's own model implementation only because there isn't one in glib. There isn't actually a consumer in Clutter for ClutterModel, but other libraries built on top of Clutter use it. Yes. It's exactly about libraries. I have a similar situation with GSettings -- I want to allow people to place GSettingsList objects inside of GtkTreeView if they want, but GSettings itself has no other reason to depend on GTK. Since GtkTreeModel also has no reason to depend on (the rest of) GTK, it seems logical to move it into glib. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Review of gnio, round 1
On 05/12/2009 05:22 AM, Paul LeoNerd Evans wrote: > Speaking of GResolver, in the API (which I'm currently staring at here: > > http://git.gnome.org/cgit/glib/diff/gio/gresolver.h?h=gresolver&id=05507dce1f540581028e8be0e220e68c44fade2f > > ) I don't see any attempt at the gai()-style "hostname + servicename" > resolver. Where's the ability to connect to, say, "www.google.com:http"? > > Half the point of gai+gni was to unify the separate operations of > hostname->IP and servicename->port, so they're in one combined place. > gai() can therefore support things like SRV records, which the previous > pair of gethostbyname+getservbyname cannot. You're mixing up two very different things. getaddrinfo *does not* use SRV records. When you pass a (non-numeric) string to getaddrinfo for "service", it just looks that string up in /etc/services to translate it to a port number, and returns that port number (regardless of whether or not that service is really running on the host). libresolv doesn't provide any dedicated SRV-lookup API. (You have to do it by hand with res_query.) But GResolver supports SRV lookup via g_resolver_lookup_service() and g_resolver_lookup_service_async(). (And at a higher level via GNetworkService.) GResolver intentionally does not support doing the servicename->port mapping thing that getaddrinfo/getsrvbyname does though, because it's a bad API; you can't know for sure what's going to be in /etc/services on any given machine, and in particular, if you're using some very new protocol, it's very likely that some people are going to try to run your application on machines that don't have that protocol listed in /etc/services. So it's always better to just provide your own #define FOOBAR_PORT with the right port number, and then use that, rather than crossing your fingers and hoping that GResolver will be able to map "foobar" to the right number for you. -- Dan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: tree model
On Tue, 2009-05-12 at 12:50 +0200, Alexander Larsson wrote: > On Tue, 2009-05-12 at 10:47 +0200, Christian Dywan wrote: > > Am Tue, 12 May 2009 08:10:11 +0200 > > schrieb Mikkel Kamstrup Erlandsen : > > > > > 2009/5/12 Matthias Clasen : > > > >> > > > >> I should have been slightly more clear: I am interested in being > > > >> able to provide a GtkTreeModel for those people who wish to use it > > > >> without having to link to libgtk myself. > > > >> > > > >> So the problem with using GNode: GtkTreeView doesn't use it. > > > > > > > > I don't see why this is something we should be eager to support. > > > > Since tree models are only useful with GTK+ widgets, it doesn't > > > > seem like a big burden to link against gtk when you are providing > > > > tree models. The consumer of your model will already link against > > > > gtk anyway. > > > > > > I recall having issues with this... But my memory serves me badly... > > > > > > Is it that gtk_init() requires a connection to X? That way if I am > > > writing mydaemon based on mylib.so then mydaemon will require X to > > > run. Maybe gtk_init_check() can work around this, or maybe the library > > > does not need gtk_init_* in the first place... I am hoping that I can > > > use the same data model in the daemon and in the GUI app so that I > > > don't have to wrap it in a GtkTreeModel when using it in the GUI app. > > > > > > Anyway, I just want to back Ryan up on this one. I've been wanting a > > > GTreeModel for the exact same purpose as Ryan on more than one > > > occasion. > > > > Hey, > > > > if the main issue is, as you describe, not having to run X11, then > > gtk_init_check is all you need. There is no practical problem using a > > GtkTreeModel without a display. It's simply that gtk_init errors out if > > there is no display, which is reasonable default behaviour. See the API > > reference for details :) > > The issue comes up when you have an object in a non-gui library that you > would like to use as a source for a GtkTreeView, for instance, in ryans > case I believe its about some object that would end up in libgio. > totem-pl-parser is using GtkTreeModel as well. IIRC, tracker uses totem-pl-parser to parse playlists, but I guess they are not interested on GtkTreeView. Claudio ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: tree model
On Tue, 2009-05-12 at 10:47 +0200, Christian Dywan wrote: > Am Tue, 12 May 2009 08:10:11 +0200 > schrieb Mikkel Kamstrup Erlandsen : > > > 2009/5/12 Matthias Clasen : > > >> > > >> I should have been slightly more clear: I am interested in being > > >> able to provide a GtkTreeModel for those people who wish to use it > > >> without having to link to libgtk myself. > > >> > > >> So the problem with using GNode: GtkTreeView doesn't use it. > > > > > > I don't see why this is something we should be eager to support. > > > Since tree models are only useful with GTK+ widgets, it doesn't > > > seem like a big burden to link against gtk when you are providing > > > tree models. The consumer of your model will already link against > > > gtk anyway. > > > > I recall having issues with this... But my memory serves me badly... > > > > Is it that gtk_init() requires a connection to X? That way if I am > > writing mydaemon based on mylib.so then mydaemon will require X to > > run. Maybe gtk_init_check() can work around this, or maybe the library > > does not need gtk_init_* in the first place... I am hoping that I can > > use the same data model in the daemon and in the GUI app so that I > > don't have to wrap it in a GtkTreeModel when using it in the GUI app. > > > > Anyway, I just want to back Ryan up on this one. I've been wanting a > > GTreeModel for the exact same purpose as Ryan on more than one > > occasion. > > Hey, > > if the main issue is, as you describe, not having to run X11, then > gtk_init_check is all you need. There is no practical problem using a > GtkTreeModel without a display. It's simply that gtk_init errors out if > there is no display, which is reasonable default behaviour. See the API > reference for details :) The issue comes up when you have an object in a non-gui library that you would like to use as a source for a GtkTreeView, for instance, in ryans case I believe its about some object that would end up in libgio. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: tree model
On Mon, 2009-05-11 at 21:10 -0400, Matthias Clasen wrote: > > > > I should have been slightly more clear: I am interested in being able to > > provide a GtkTreeModel for those people who wish to use it without having to > > link to libgtk myself. > > > > So the problem with using GNode: GtkTreeView doesn't use it. > > I don't see why this is something we should be eager to support. Since > tree models are only useful with GTK+ widgets, it doesn't seem like a > big burden to link against gtk when you are providing tree models. The > consumer of your model will already link against gtk anyway. I think the Clutter project has it's own model implementation only because there isn't one in glib. There isn't actually a consumer in Clutter for ClutterModel, but other libraries built on top of Clutter use it. Regards, Thomas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Review of gnio, round 1
On Sun, 10 May 2009 17:29:48 +0300 Stefan Kost wrote: > Alexander Larsson schrieb: > > With gnome 2.26 out and the GResolver branch landed it is time to start > > look at merging the gnio network code into gio. I'm posting this here, > > plus CC:ing the involved people instead of on bugzilla in order to get > > feedback from others who may be interested but unaware of this work. > > Its a bit late - Is there an object called GResolver? If so could that be > named > GNameResolver or something simillar - or would it be GNIOResolver?. I feel > GResolver sounds too generic. Speaking of GResolver, in the API (which I'm currently staring at here: http://git.gnome.org/cgit/glib/diff/gio/gresolver.h?h=gresolver&id=05507dce1f540581028e8be0e220e68c44fade2f ) I don't see any attempt at the gai()-style "hostname + servicename" resolver. Where's the ability to connect to, say, "www.google.com:http"? Half the point of gai+gni was to unify the separate operations of hostname->IP and servicename->port, so they're in one combined place. gai() can therefore support things like SRV records, which the previous pair of gethostbyname+getservbyname cannot. Unless perhaps I'm looking at the wrong part, or there's a more up-to-date version somewhere? -- Paul "LeoNerd" Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: tree model
Am Tue, 12 May 2009 08:10:11 +0200 schrieb Mikkel Kamstrup Erlandsen : > 2009/5/12 Matthias Clasen : > >> > >> I should have been slightly more clear: I am interested in being > >> able to provide a GtkTreeModel for those people who wish to use it > >> without having to link to libgtk myself. > >> > >> So the problem with using GNode: GtkTreeView doesn't use it. > > > > I don't see why this is something we should be eager to support. > > Since tree models are only useful with GTK+ widgets, it doesn't > > seem like a big burden to link against gtk when you are providing > > tree models. The consumer of your model will already link against > > gtk anyway. > > I recall having issues with this... But my memory serves me badly... > > Is it that gtk_init() requires a connection to X? That way if I am > writing mydaemon based on mylib.so then mydaemon will require X to > run. Maybe gtk_init_check() can work around this, or maybe the library > does not need gtk_init_* in the first place... I am hoping that I can > use the same data model in the daemon and in the GUI app so that I > don't have to wrap it in a GtkTreeModel when using it in the GUI app. > > Anyway, I just want to back Ryan up on this one. I've been wanting a > GTreeModel for the exact same purpose as Ryan on more than one > occasion. Hey, if the main issue is, as you describe, not having to run X11, then gtk_init_check is all you need. There is no practical problem using a GtkTreeModel without a display. It's simply that gtk_init errors out if there is no display, which is reasonable default behaviour. See the API reference for details :) Yours, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
