double click
Can anyone help with some tips on constructing XEvents to signal a mouse double-click? Down-Up-Down-Up (4 XEvents) without a MouseMove? TIA, Chuck Crisler ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Pass more widgets as gpointer.
Hello All. I'm quite new to C, but have done some gtk programming in perl. I've been looking for answers on the web, and in various tutorials, without any luck. My question is how to pass more widgets as a gpointer, to a callback function. (in C ) For instance if a OK button, has to read the state of three other widgets... In perl I would make an array of the widgets, and then pass the ref as the data argument to the callback. I cannot grasp how to do something like that in C. An example snippet would be really helpfull. Thx Jens ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Pass more widgets as gpointer.
Hello. The common solution to this problem is to create a structure containing all of the widgets you may need in callbacks and than pass pointer to it around. Some sample code can be found here: http://gtkforums.com/viewtopic.php?t=2913#8098 Hope this helps a bit. Bye 2009/4/20 Jens Hansen jensh...@gmail.com: Hello All. I'm quite new to C, but have done some gtk programming in perl. I've been looking for answers on the web, and in various tutorials, without any luck. My question is how to pass more widgets as a gpointer, to a callback function. (in C ) For instance if a OK button, has to read the state of three other widgets... In perl I would make an array of the widgets, and then pass the ref as the data argument to the callback. I cannot grasp how to do something like that in C. An example snippet would be really helpfull. Thx Jens ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Tadej Borovšak tadeb...@gmail.com tadej.borov...@gmail.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Pass more widgets as gpointer.
Hello, Jens The other way is to make your widgets global. Especially, me? I use GOjects, and always pass self object. For example, I inherit main window object from GtkWindow and later in widgets definition pass itself to callback. Also, you can use g_object_set_data for storing some useful pointers. Good luck 2009/4/20 Jens Hansen jensh...@gmail.com: Hello All. I'm quite new to C, but have done some gtk programming in perl. I've been looking for answers on the web, and in various tutorials, without any luck. My question is how to pass more widgets as a gpointer, to a callback function. (in C ) For instance if a OK button, has to read the state of three other widgets... In perl I would make an array of the widgets, and then pass the ref as the data argument to the callback. I cannot grasp how to do something like that in C. An example snippet would be really helpfull. Thx Jens ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: glib dbus bindings notes
On Tue, 2009-03-03 at 13:19 -0500, David Zeuthen wrote: Regarding your other comments, I largely agree with them and this mail would be too long if I replied to all of them. So, to sum up, the main suggestions you are making are - Rework low-level bits of EggDBus so it's like dbus-hippo-helper - Don't try to hide libdbus in the low-level bits (but do hide it from the high-level bits) - make sure the all gunk needed for the C/GObject binding is separate from the low-level stuff (a separate library even?) Just as a follow up, I've started working on this, see http://bugzilla.gnome.org/show_bug.cgi?id=579571 for details and am hoping the low-level bits (i.e. not the object mapping) can land in the next GLib release. Once the low-level details are on master, I will start doing the C/GObject object mapping - this is probably going to take longer to bake so maybe it won't make the next GLib release, maybe it will, depends. David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Sun, 19 Apr 2009, David Zeuthen wrote: On Sun, 2009-04-19 at 20:05 -0400, Allin Cottrell wrote: I've recently been trying to purge my GTK app of deprecated stuff, and I tried replacing gnome_url_show() with gtk_show_uri(). No go; on invoking gtk_show_uri() I get operation not supported. After some googling, it appears that one must have gvfs installed. OK, I download, build and install gvfs. But it doesn't help. Gvfs as built on my system (without configure or compilation errors) apparently can't handle URIs... This sort of thing is new, and IMO thoroughly obnoxious: up till now, one could depend on GTK functions working provided one had successfully installed the known stack of dependencies, which were checked at compile time for GTK and friends. Now we have GTK functions that may or may not work depending on unspecified dependencies... This is _supposed_ to work, there's already an unpleasant amount of work in GIO to ensure that things work when things like GVfs (which requires a modern flavor of Linux or UNIX) is not available. Now, GIO may not work as well as when GVfs installed (e.g. automounting storage devices won't work unless the OS actively assists with playing games like modifying /etc/fstab) but basics like launching a program for URIs _should_ work - e.g. http, mailto, file:///path/to/some.jpg file or other well-known URIs schemes. I could be wrong, but just briefly looking at the code it looks like there is no default implementation of GDesktopAppInfoLookup in GIO, there's only one in GVfs (that looks up stuff in GConf under in /desktop/gnome/url-handlers/scheme) so it's no surprise things don't work if GVfs is not installed. Yes, that's right. As it's currently coded gtk_show_uri is bound to fail if GVfs is not present. But more than that: it'll fail even if GVfs _is_ present (as it is now on my system), if GVfs does not in turn incorporate GConf support. I thought I'd read that GConf was supposed to be deprecated, or on the way there? I think it would be reasonable if GIO at least handled file:// and maybe also http:// and mailto:// (the former by using the MIME, the latter two by include a search path of well-known applications like epiphany firefox, evolution and thunderbird) and also the URI schemes used to launch Yelp. Agreed. You should probably file a bug about this. OK, will do. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Mon, 2009-04-20 at 10:43 -0400, Allin Cottrell wrote: On Sun, 19 Apr 2009, David Zeuthen wrote: I could be wrong, but just briefly looking at the code it looks like there is no default implementation of GDesktopAppInfoLookup in GIO, there's only one in GVfs (that looks up stuff in GConf under in /desktop/gnome/url-handlers/scheme) so it's no surprise things don't work if GVfs is not installed. Yes, that's right. As it's currently coded gtk_show_uri is bound to fail if GVfs is not present. But more than that: it'll fail even if GVfs _is_ present (as it is now on my system), if GVfs does not in turn incorporate GConf support. I thought I'd read that GConf was supposed to be deprecated, or on the way there? I don't understand what you propose? There is no in-use non-gconf setting for mapping default handlers for entire uri scheme. So, we lookup none which mean we then fall back to the per-mime default. Its entierly unreasonable to have a file:// uri handler, as that would open *all* types of local files, overriding your per-mime specs. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Am Mon, 20 Apr 2009 17:00:41 +0200 schrieb Alexander Larsson al...@redhat.com: On Mon, 2009-04-20 at 10:43 -0400, Allin Cottrell wrote: On Sun, 19 Apr 2009, David Zeuthen wrote: I could be wrong, but just briefly looking at the code it looks like there is no default implementation of GDesktopAppInfoLookup in GIO, there's only one in GVfs (that looks up stuff in GConf under in /desktop/gnome/url-handlers/scheme) so it's no surprise things don't work if GVfs is not installed. Yes, that's right. As it's currently coded gtk_show_uri is bound to fail if GVfs is not present. But more than that: it'll fail even if GVfs _is_ present (as it is now on my system), if GVfs does not in turn incorporate GConf support. I thought I'd read that GConf was supposed to be deprecated, or on the way there? I don't understand what you propose? There is no in-use non-gconf setting for mapping default handlers for entire uri scheme. So, we lookup none which mean we then fall back to the per-mime default. Its entierly unreasonable to have a file:// uri handler, as that would open *all* types of local files, overriding your per-mime specs. What about using xdg-open if GVfs is not available OR if gconf is not available? That's a tiny script that can be easily installed anywhere, even on less modern boxes. Just my 2 pfennig, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Mon, 2009-04-20 at 18:31 +0200, Christian Dywan wrote: What about using xdg-open if GVfs is not available OR if gconf is not available? That's a tiny script that can be easily installed anywhere, even on less modern boxes. That would give you a nice circular dependency if xdg-open(1) is ever ported to use GIO [1] which is not at all unlikely... David [1] : under GNOME, xdg-open(1) uses gnome-open(1) which AFAICT uses gnome-vfs2... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Mon, 2009-04-20 at 12:45 -0400, David Zeuthen wrote: That would give you a nice circular dependency if xdg-open(1) is ever ported to use GIO [1] which is not at all unlikely... David [1] : under GNOME, xdg-open(1) uses gnome-open(1) which AFAICT uses gnome-vfs2... gnome-open already uses GIO since 2.24 [1] so yes, we would have that loop already. OTOH, as libgnome depends on GConf, if you have gnome-open available, you're likely to also have GConf already installed. [1] http://svn.gnome.org/viewvc/libgnome/trunk/libgnome/gnome-open.c?view=markup Ciao, Cosimo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Mon, 2009-04-20 at 12:29 -0400, Allin Cottrell wrote: On Mon, 20 Apr 2009, Alexander Larsson wrote: On Mon, 2009-04-20 at 10:43 -0400, Allin Cottrell wrote: As it's currently coded gtk_show_uri is bound to fail if GVfs is not present. But more than that: it'll fail even if GVfs _is_ present (as it is now on my system), if GVfs does not in turn incorporate GConf support. I thought I'd read that GConf was supposed to be deprecated, or on the way there? I don't understand what you propose? There is no in-use non-gconf setting for mapping default handlers for entire uri scheme. So, we lookup none which mean we then fall back to the per-mime default. The uri I'm testing with gtk_show_uri is a simple http reference. So far as I can tell the attempt to handle it grinds to a halt in g_file_query_info with iface-query_info = NULL. gnome_url_show has no problem getting firefox to open it. Well, if you don't have gvfs installed then you will not be able to either look up the uri handler for the http uri scheme in gconf, nor will you be able to query_info for the mime type of the file on the http server. It should not grind to a halt though, can you explain in more detail what happens? For the gnome_url_show() case this calls the old gnome_vfs_url_show() which reads the http scheme default from gconf. This is the same behaviour as gtk_show_url would have if you had gvfs installed with gconf support. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Mon, 20 Apr 2009, Alexander Larsson wrote: On Mon, 2009-04-20 at 12:29 -0400, Allin Cottrell wrote: On Mon, 20 Apr 2009, Alexander Larsson wrote: On Mon, 2009-04-20 at 10:43 -0400, Allin Cottrell wrote: As it's currently coded gtk_show_uri is bound to fail if GVfs is not present. But more than that: it'll fail even if GVfs _is_ present (as it is now on my system), if GVfs does not in turn incorporate GConf support. I thought I'd read that GConf was supposed to be deprecated, or on the way there? I don't understand what you propose? There is no in-use non-gconf setting for mapping default handlers for entire uri scheme. So, we lookup none which mean we then fall back to the per-mime default. The uri I'm testing with gtk_show_uri is a simple http reference. So far as I can tell the attempt to handle it grinds to a halt in g_file_query_info with iface-query_info = NULL. gnome_url_show has no problem getting firefox to open it. Well, if you don't have gvfs installed then you will not be able to either look up the uri handler for the http uri scheme in gconf, nor will you be able to query_info for the mime type of the file on the http server. It should not grind to a halt though, can you explain in more detail what happens? I put some debugging statements into some of the gio files, and here's what I'm getting when I try to open the http reference: g_io_module_load_module: loaded '/opt/gtk2/lib/gio/modules/libgvfsdbus.so' g_io_module_load_module: loaded '/opt/gtk2/lib/gio/modules/libgiofam.so' g_io_extension_point_lookup: 'gio-local-file-monitor' - gio-local-file-monitor g_io_extension_point_lookup: 'gio-local-directory-monitor' - gio-local-directory-monitor g_io_module_load_module: loaded '/opt/gtk2/lib/gio/modules/libgioremote-volume-monitor.so' g_io_extension_point_lookup: 'gio-local-directory-monitor' - gio-local-directory-monitor g_io_extension_point_lookup: 'gio-local-file-monitor' - gio-local-file-monitor g_io_extension_point_lookup: 'gio-native-volume-monitor' - gio-native-volume-monitor g_io_extension_point_lookup: 'gio-vfs' - gio-vfs g_io_extension_point_lookup: 'gio-vfs' - gio-vfs g_io_extension_point_lookup: 'gio-desktop-app-info-lookup' - gio-desktop-app-info-lookup g_io_extension_point_lookup: ep = 0x9e92e18 g_file_query_info: iface-query_info = NULL g_file_query_default_handler gave NULL for 'http://gretl.sourceforge.net' And an error message Operation not supported. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Mon, 2009-04-20 at 14:36 -0400, Allin Cottrell wrote: On Mon, 20 Apr 2009, Alexander Larsson wrote: On Mon, 2009-04-20 at 12:29 -0400, Allin Cottrell wrote: On Mon, 20 Apr 2009, Alexander Larsson wrote: On Mon, 2009-04-20 at 10:43 -0400, Allin Cottrell wrote: As it's currently coded gtk_show_uri is bound to fail if GVfs is not present. But more than that: it'll fail even if GVfs _is_ present (as it is now on my system), if GVfs does not in turn incorporate GConf support. I thought I'd read that GConf was supposed to be deprecated, or on the way there? I don't understand what you propose? There is no in-use non-gconf setting for mapping default handlers for entire uri scheme. So, we lookup none which mean we then fall back to the per-mime default. The uri I'm testing with gtk_show_uri is a simple http reference. So far as I can tell the attempt to handle it grinds to a halt in g_file_query_info with iface-query_info = NULL. gnome_url_show has no problem getting firefox to open it. Well, if you don't have gvfs installed then you will not be able to either look up the uri handler for the http uri scheme in gconf, nor will you be able to query_info for the mime type of the file on the http server. It should not grind to a halt though, can you explain in more detail what happens? I put some debugging statements into some of the gio files, and here's what I'm getting when I try to open the http reference: And an error message Operation not supported. Thats not grind to halt really, but ok. What do you have built? It seems to load a libgvfsdbus.so, so gvfs seems to be there, but with no gconf module? Do you have a session dbus running? If you have gvfs installed but not with gconf what should happen is that the query_info on the uri should sniff the mimetype and launch app depending on that. Does gvfs stuff work at all in your installation? For instance, what does gvfs-info http://gretl.sourceforge.net; print? for me it does: gvfs-info http://gretl.sourceforge.net display name: / edit name: / type: unknown size: 14276 attributes: etag::value: 37c4-467d4ae02f640 standard::display-name: / standard::edit-name: / standard::content-type: text/html standard::size: 14276 id::filesystem: type=http,uri=http%3A%2F%2Fgretl.sourceforge.net,__mount_prefix=%2F time::modified: 1240063057 time::modified-usec: 0 which should lanuch whatever app is registered for text/html. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Mon, 20 Apr 2009, Alexander Larsson wrote: 00, Allin Cottrell wrote: On Mon, 20 Apr 2009, Alexander Larsson wrote: On Mon, 2009-04-20 at 12:29 -0400, Allin Cottrell wrote: On Mon, 20 Apr 2009, Alexander Larsson wrote: On Mon, 2009-04-20 at 10:43 -0400, Allin Cottrell wrote: As it's currently coded gtk_show_uri is bound to fail if GVfs is not present. But more than that: it'll fail even if GVfs _is_ present (as it is now on my system), if GVfs does not in turn incorporate GConf support. I thought I'd read that GConf was supposed to be deprecated, or on the way there? I don't understand what you propose? There is no in-use non-gconf setting for mapping default handlers for entire uri scheme. So, we lookup none which mean we then fall back to the per-mime default. The uri I'm testing with gtk_show_uri is a simple http reference. So far as I can tell the attempt to handle it grinds to a halt in g_file_query_info with iface-query_info = NULL. gnome_url_show has no problem getting firefox to open it. Well, if you don't have gvfs installed then you will not be able to either look up the uri handler for the http uri scheme in gconf, nor will you be able to query_info for the mime type of the file on the http server. It should not grind to a halt though, can you explain in more detail what happens? I put some debugging statements into some of the gio files, and here's what I'm getting when I try to open the http reference: And an error message Operation not supported. Thats not grind to halt really, but ok. What do you have built? It seems to load a libgvfsdbus.so, so gvfs seems to be there, but with no gconf module? Do you have a session dbus running? That's right; no gconf module in gvfs but dbus-daemon --system is running. If you have gvfs installed but not with gconf what should happen is that the query_info on the uri should sniff the mimetype and launch app depending on that. Does gvfs stuff work at all in your installation? For instance, what does gvfs-info http://gretl.sourceforge.net; print? It prints the same messages as I gave earlier, culminating in g_file_query_info: iface-query_info = NULL Error getting info: Operation not supported But, e.g., gvfs-info /usr/local/bin/mplayer works fine. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Mon, 20 Apr 2009, Alexander Larsson wrote: gvfs needs a session bus, not a system bus, so you're falling back to a non-gvfs system. Thus no http support. OK, I suppose I can get this working on my own system, but my main point is: why does GTK include a function such as gtk_show_uri which depends on a big stack of unspecified stuff? At least this should be mentioned in the documentation. As I said before, up till very recently one has been able to rely on GTK functions just working so long as the compile-time dependencies are satisfied. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Sun, 19 Apr 2009, Havoc Pennington wrote: I think my arguments are compelling. If someone else thinks differently, they can say so, and explain their reasoning... The bottom line is that dbus has an MIT/X11-equivalent license, with the addition of a *weaker* patent clause than LGPL/GPL already have. The license was written by a lawyer and is perfectly sane. Sane and written by a lawyer are surely orthogonal to desirability from the point of view of free software. Havoc wrote in his blog: I believe if you distributed D-Bus under GPL or LGPL, you would be making a patent grant of any patents affecting D-Bus. The AFL patent clause does not require you to make a patent grant; it still allows you to sue. You just have to stop distributing D-Bus while you do it. With the GPL or LGPL, you can never distribute in the first place, without giving up the right to sue at all. Unless I'm missing something, there's no way the AFL patent clause can be a problem unless LGPL or GPL would be a problem in the same context. IANAL, but... Hypothesis: Monster Corp distributes D-BUS under AFL, while believing that DB in fact violates patents held by Monster Corp. MC then sues users of DB. MC can no longer distribute DB under AFL, but they don't care! They have succeeded in causing trouble. But as Havoc says, if Monster Corp had distributed DB under *GPL they would have effectively made a patent grant and given up the right to sue, making this scenario impossible. OK, maybe there's no Monster Corp associated with D-BUS right now, but we know there _are_ such monsters around. This seems to me a _major_ reason to see *GPL as superior to AFL from the p.o.v. of free software. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Hi, On Mon, Apr 20, 2009 at 10:31 PM, Allin Cottrell cottr...@wfu.edu wrote: On Sun, 19 Apr 2009, Havoc Pennington wrote: The license was written by a lawyer and is perfectly sane. Sane and written by a lawyer are surely orthogonal to desirability from the point of view of free software. The contrast is with things like the Artistic 1.0 license, which is a legal mess written by a non-lawyer. That is not desirable because the license ends up vague (from a legal perspective) and difficult to enforce in court. AFL was written by an open source advocate (and lawyer) with input from a lot of other open source people. The point is, it's not some off-the-wall license made up over beers. It was written by someone competent to do so and vetted by quite a few others. It is an approved license on opensource.org. IANAL, but... Hypothesis: Monster Corp distributes D-BUS under AFL, while believing that DB in fact violates patents held by Monster Corp. MC then sues users of DB. MC can no longer distribute DB under AFL, but they don't care! They have succeeded in causing trouble. But as Havoc says, if Monster Corp had distributed DB under *GPL they would have effectively made a patent grant and given up the right to sue, making this scenario impossible. Yes, you're right that the AFL imposes fewer restrictions than GPL, just as any other MIT/X11 type of license imposes less restrictions than GPL. OK, maybe there's no Monster Corp associated with D-BUS right now, but we know there _are_ such monsters around. This seems to me a _major_ reason to see *GPL as superior to AFL from the p.o.v. of free software. The discussion is not about whether AFL (or MIT/X11 type licenses in general) are superior to GPL-type licenses philosophically. The discussion is about whether there's a licensing problem with libdbus that keeps GLib and GTK+ from relying on it. Last I checked, GTK+ at least linked to quite a bit of code under MIT/X11 sort of licenses, such as libX11. You aren't saying anything here that doesn't also apply to libX11. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
