Re: How does the dialog's default button respond enter key
I think you should connect the enter signal to the window instead of the button. I think what you mean is, you wanna destroy the dialog whenever the user press enter key, right? On Wed, Oct 7, 2009 at 10:35 AM, wjh jh_wang2...@163.com wrote: Hi all: I have a question, in Gtk+ dialog,there is a GtkListStore Widget, when user select the list's entry and then press the enter key, I want programe make the dialog's default OK button responds the entre key signal and destory the dialog immediately. But the list widget intercept the signal, default button does not! how can i? thanks! ___ 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: Resizing
2009/10/7 John Coppens j...@jcoppens.com: - I have a (top-level) window, with a vbox, then a vpanel, a frame, an 'alignment' and a table (listed in the order of nesting). When I change something in the table, which makes it wider, the table gets wider, wider than the frame, which doesn't resize, and neither does the rest upwards in the hierarchy. I understand that normally the size allocation starts from the window down. How do I resize from de table up? You need to put stuff inside something which can get larger. I'd put a scrolledwindow inside the vpane, then the frame and the table inside that. This will mean if the table gets bigger than the vpane, it'll get scrollbars. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How does the dialog's default button respond enter key
2009/10/7 Simon Chan simon...@gmail.com: I think you should connect the enter signal to the window instead of the button. I think what you mean is, you wanna destroy the dialog whenever the user press enter key, right? Actually I think this is better. Closing a dialog using the default button is named using the default response. There are several steps to achieve this: First you need to set the default response for your dialog with gtk_dialog_set_default_response Then, you need to set your GtkEntry to activate the default response when they are activated with: gtk_entry_set_activates_default Unfortunately, there seems to be no way to do the same on GtkTreeView. You will have to connect to the row-activated signal and manually return a response in the handler with gtk_dialog_response. Pierre-Luc Beaudoin ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Resizing
On Wed, 7 Oct 2009 10:23:00 +0100 jcup...@gmail.com wrote: You need to put stuff inside something which can get larger. I'd put a scrolledwindow inside the vpane, then the frame and the table inside that. This will mean if the table gets bigger than the vpane, it'll get scrollbars. Thanks, John. That solves part of the problem. Now the table remains inside the frame when it grows... I have a more fundamental problem though: Recalling the structure: Window VBox Top: Menu Btm: HPaned Left: VPaned (works fine) Right: Frame with table (with ScrollWdw, ok) But, if I enlarge the outer window, the Vbox doesn't grow: the menu stays the same width, as does the HPaned. I've checked the properties of all of the elements, and, as far as I can see, all the resizing/etc flags which could influence, are set. I have done several programs which use this structure - never had any problem with resizing the menu! John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GLib 2.22.2 released
GLib 2.22.2 is now available for download at: ftp://ftp.gtk.org/pub/glib/2.22/ http://download.gnome.org/sources/glib/2.22/ md5 sums: 846a86c74b74d5b16826aa5508940f9b glib-2.22.2.tar.bz2 00eb873975e2ef9361b8177131c7c943 glib-2.22.2.tar.gz sha1 sums: bdd9c4b930e81203ea69fe83876cb6c82bdc5a38 glib-2.22.2.tar.bz2 6984909bdc8e3e6be3ddf07a837408206cb25b12 glib-2.22.2.tar.gz This is the second bug fix release in the stable 2.22 series. 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.22.1 to GLib 2.22.2 === * GIO: - Support case-sensitive globs in the shared mime database, including support for the newer cache format that allows these. Case-sensitive globs have been introduced in shared-mime-info version 0.70 * GObject: - Speed up creation of simple objects * Bugs fixed: 597194 Typo in _G_TYPE_CVH macro * Updated translations: Russian Thanks to Alexander Larsson and Edward Hervey for the changes in this release October 7, 2009 Matthias Clasen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 2.90 branch
Am Tue, 29 Sep 2009 18:47:48 +0200 schrieb Christian Dywan christ...@lanedo.com: Am Tue, 29 Sep 2009 13:04:54 +0200 schrieb Javier Jardón javierjc1...@gmail.com: Hello, I've read here [1] about the creation of a GTK+ branch for GTK+ 2.90/3.0 development after 2.14 has been released. GTK+ 2.18 has been released and I think that no branch was created, is there any plans to create that branch soon? Best Regards [1] http://live.gnome.org/GTK%2B/3.0/Tasks#Q0 Hey Javier, I actually started to look into doing that this week. I think we have resolved all but a handful of sealing/ accessor issues at this point, and at least some of the GTK+ hackers seem to share the sentiment. So I think it's a good time. So I guess I should try to organize this a bit, and see if I can attract some bears to the honey. I started a local branch gtk-2.90, where I began to remove deprecated classes and functions which basically is #Q1. Question: do others agree, and can I push the branch to git.gnome.org so everybody can join the effort? For the record, I pushed the gtk-2.90 branch now, it almost compiles, that is I need to fix GtkInputDialog which uses deprecated functions and a few tests also still use old API. Anybody is welcome to help out, preferrably poke here or poke me in #gtk+ (kalikiana) before so we don't end up duplicating work. I rebased the branch once so far, Emanuelle offered to do that in the future. There's also http://live.gnome.org/GTK+/3.0/Tasks in the wiki. What I did so far is #Q0, creating the branch, and #Q1, removing deprecated code. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
