GLib 2.21.1 released
GLib 2.21.1 is now available for download at: ftp://ftp.gtk.org/pub/glib/2.21/ http://download.gnome.org/sources/glib/2.21/ md5 sums: eaf8f40c743effe26dab18c81b10a89e glib-2.21.1.tar.bz2 9db0e937a4f420502fb659137e30d220 glib-2.21.1.tar.gz sha1 sums: 135aa72a9f8a5fda077635101003859afc23b9b2 glib-2.21.1.tar.bz2 e5c380517ae6ce30ea7c8b787395e75c04cd8cd2 glib-2.21.1.tar.gz This is the a development release leading up to GLib 2.22. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.20. If you have problems, you'll need to reinstall GLib 2.20. * GLib 2.22 will be source and binary compatible with the GLib 2.20 series; however, the new API additions in GLib 2.21 are not yet finalized, so there may be incompatibilities between this release and the final 2.22 release. * Bugs should be reported to http://bugzilla.gnome.org. About GLib == GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.21.0 to GLib 2.21.1 === * GIO: - Support for network IO has been added, including a low-level socket API and a high-level API for network connections and services. - Support for read-write access with GIOStream and its subclasses. - GMount gained a pre-unmount signal. * Bug fixes: 576104Implement GMount::pre-unmount 578769 implement GWinHttpFileInputStream::close_fn 582856 gsocket.c doesn't compile on Solaris 569375 g[u]intptr undocumented 573246 [FIX] g_desktop_app_info_dup() can access NULL pointer 575013 g_cancellable_push_current() does not allow NULL 577884 live-g-file.c:461: error: format ‘%d’ expects type ... 578499 g_output_stream_splice and stream closing with gnio strea... 579558 Application employing gvfs crashes with only libgvfscommo... 583001 SIGPIPE (grr!) 583061 Please add convenience function to connect to machines by... 583198 typo in error message 583206 use g_set_error_literal where appropriate 583229 void function g_async_initable_init_async returns value 583324 locking problem in g_main_context_iterate() 583408 void function g_socket_control_message_serialize returns ... 578786 wrong and confusing error message 583205 g_inet_address_to_bytes has no length outparam 583196 mem leak in keyfile test 583663 GSocketType enum ends with a comma 569024 Make g_error_new_valist public 569376 missing G_G[U]INTPTR_FORMAT 580347 off-by-1 bug in GWinHttpFile * Updated translations: Oriya Spanish Valencian-Catalan Thanks to all contributors Carlos Garnacho Paul Pogonyshev Alexander Larsson Tor Lillqvist Dan Winship Sjoerd Simons Stefan Kost Christian Persch Jonathon Jongsma Robert Bragg Hans Breuer Shixin Zeng May 29, 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:Closing a window.
Hi, You should read the comment first.For example, /* If you return FALSE in the "delete_event" signal handler, * GTK will emit the "destroy" signal. Returning TRUE means * you don't want the window to be destroyed. * This is useful for popping up 'are you sure you want to quit?' * type dialogs. */ so,just replace "TRUE" with "FALSE",then the "destroy" signal will be emit,and the "destroy" callback function will be called to destroy the window. 在2009-05-29，"Sunburned Surveyor" 写道： >I'm a Java developer that is brand new to GTK and not the world's >greatest C programmer. (I'm acutally working with GTK in an effort to >become more familiar with C.) > >I've been working through the online GTK 2 tutorial. I modified the >"hello world" example to just show a window (with no button). > >I have a callback function defined for the delete_event and the >destroy event. These are connected to the GtkWindow using the >gtk_signal_connect function as shown in the "hello world" example. > >However, I can't close the window with the "X" button on the window >title bar. The minimize and maximize buttons work just find. For some >reason, my code isn't catching the event that comes from the close >button on the title bar. > >Can you guys give me some things to check in my code that might lead >me to the cause of the problem? Perhaps I'm messing something up with >the signal connection. > >Thank you for the help. > >Landon > >P.S. - I'm running the example on Windows XP using the Code::Blocks IDE. >___ >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: Stop alt-spacebar window menu
Actually I believe it is here: http://library.gnome.org/devel/gdk/stable/gdk-General.html#gdk-keyboard-grab ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Stop alt-spacebar window menu
Brian J. Tarricone wrote: > Well, you have a couple choices: Actually there is a third option. You can grab the focus like VMWare or DosEMU does and prevent any keystrokes from going to the WM. Of course you'll have to provide a way to release the grab. I believe the API is in GdkDisplay area[1]. Look for calls involving keyboard_grab. [1] http://library.gnome.org/devel/gdk/stable/GdkDisplay.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Closing a window.
Original Message Subject: Closing a window. From: Sunburned Surveyor To: gtk-app-devel-list@gnome.org Date: 05/28/2009 03:27 PM I'm a Java developer that is brand new to GTK and not the world's greatest C programmer. (I'm acutally working with GTK in an effort to become more familiar with C.) I'll help you, if it rids the world of a Java programmer. :) Can you guys give me some things to check in my code that might lead me to the cause of the problem? Perhaps I'm messing something up with the signal connection. If you copied the "Hello World" app 1:1 then there's your problem. The delete_event callback is not set to close the window for you. The comments for the app should point you in the right direction. In particular, the comment on line 15 and onward. ;) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Closing a window.
I'm a Java developer that is brand new to GTK and not the world's greatest C programmer. (I'm acutally working with GTK in an effort to become more familiar with C.) I've been working through the online GTK 2 tutorial. I modified the "hello world" example to just show a window (with no button). I have a callback function defined for the delete_event and the destroy event. These are connected to the GtkWindow using the gtk_signal_connect function as shown in the "hello world" example. However, I can't close the window with the "X" button on the window title bar. The minimize and maximize buttons work just find. For some reason, my code isn't catching the event that comes from the close button on the title bar. Can you guys give me some things to check in my code that might lead me to the cause of the problem? Perhaps I'm messing something up with the signal connection. Thank you for the help. Landon P.S. - I'm running the example on Windows XP using the Code::Blocks IDE. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Stop alt-spacebar window menu
Looks like it's a show stopper, which is a shame because I've already got a nice layout, and got the keyboard interaction going. The problem is that the emulation has to bear some resemblance to the real instrument, and be playable, so even if I don't use the alt key, users are likely to hit it by accident when playing. This had already happened to users of the windows version until I figured out how to stop it. Brian J. Tarricone wrote: On 05/28/2009 11:51 AM, Bill Farmer wrote: The reason for wanting to capture the alt-spacebar combination is because the keyboard is being played as a musical instrument using the function keys on one side, and the control, alt, and spacebar on the other side. So, every time the user presses alt-spacebar, the app main window loses the keyboard focus, he has to put the keyboard down, and use the mouse to dismiss the menu, as the escape key doesn't return the focus to the app main window. See http://melodeon.googlecode.com. Well, you have a couple choices: 1. Come up with a better virtual keyboard layout that isn't likely to conflict with existing shortcuts. (Or make the things likely to conflict configurable in your app.) 2. Suggest that users disable conflicting key bindings or, if that's not possible, use a different WM that doesn't have a conflicting key binding (or is configurable). Basically #1 is your only viable option. #2 is going to make the majority of your potential users either say "huh, what's a window manager? how do I change that?" and be completely confused, or say "no thanks, I can live without your app." I've looked at the keybindings, but can't work out how to remove this one. It's possible that it's in Gnome, I haven't got that far. Also I only want to change it for this application. You can't. The WM doesn't care what app is focused. It'll eat the key regardless. And besides, even if you do find a solution for GNOME, what about people who run KDE? Xfce? LXDE? *box? Ratpoison? .. -brian ___ 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: Stop alt-spacebar window menu
On 05/28/2009 11:51 AM, Bill Farmer wrote: The reason for wanting to capture the alt-spacebar combination is because the keyboard is being played as a musical instrument using the function keys on one side, and the control, alt, and spacebar on the other side. So, every time the user presses alt-spacebar, the app main window loses the keyboard focus, he has to put the keyboard down, and use the mouse to dismiss the menu, as the escape key doesn't return the focus to the app main window. See http://melodeon.googlecode.com. Well, you have a couple choices: 1. Come up with a better virtual keyboard layout that isn't likely to conflict with existing shortcuts. (Or make the things likely to conflict configurable in your app.) 2. Suggest that users disable conflicting key bindings or, if that's not possible, use a different WM that doesn't have a conflicting key binding (or is configurable). Basically #1 is your only viable option. #2 is going to make the majority of your potential users either say "huh, what's a window manager? how do I change that?" and be completely confused, or say "no thanks, I can live without your app." I've looked at the keybindings, but can't work out how to remove this one. It's possible that it's in Gnome, I haven't got that far. Also I only want to change it for this application. You can't. The WM doesn't care what app is focused. It'll eat the key regardless. And besides, even if you do find a solution for GNOME, what about people who run KDE? Xfce? LXDE? *box? Ratpoison? .. -brian ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Stop alt-spacebar window menu
The reason for wanting to capture the alt-spacebar combination is because the keyboard is being played as a musical instrument using the function keys on one side, and the control, alt, and spacebar on the other side. So, every time the user presses alt-spacebar, the app main window loses the keyboard focus, he has to put the keyboard down, and use the mouse to dismiss the menu, as the escape key doesn't return the focus to the app main window. See http://melodeon.googlecode.com. I've looked at the keybindings, but can't work out how to remove this one. It's possible that it's in Gnome, I haven't got that far. Also I only want to change it for this application. Andrew W. Nosenko wrote: On Wed, May 27, 2009 at 8:11 PM, Bill Farmer wrote: I am porting a native windows application to linux gtk. I want to stop the alt-spacebar key combination popping up the application window menu. This can be done in windows by capturing the WM_SYSCHAR message. After searching though the gtk documentation and sources, the only way I can see to do this is by copying a file from the gdk sources, modifying it, and compiling it with the application. This is complicated by the latest gtk source tarball not including gdk. Is this because gdk hasn't changed since the last version that contained it? Am I missing something? Sorry, but I don't understand your wish completely! First at all, why do you want to limit user's ability to access window menu? Second, it is unclear, whether you targeting "window menu" indeed, or there just conflict between wanted-by-you keybinding and default WM's keybinding. In first case (targeting window menu especially), I would to recommend think twice before frustrating user. In second, just reconsider your keybindings, which would be far better. But again and anyway, I can be absolutelly wrong because don't understand your reasons and needs... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkCombo events
Hi, I search, but not find the answer of my question.. What event is going on when the string selected of a GtkCombo is chenged? -- Abraço, Frederico Schardong, SOLIS - O lado livre da tecnologia www.solis.coop.br ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
