Re: Handle "Enter" pressing at GtkEntry
On Wed, Oct 3, 2012 at 7:42 AM, Yury Alyaev wrote: > What is the right way to catch "Enter" pressing at the end of the text input > to GtkEntry gtk_entry_set_activates_default() is probably what you want. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkFileChooserButton::file-set
On Thu, Oct 04, 2012 at 12:33:24AM +0200, Nicola Fontana wrote: > Il Wed, 3 Oct 2012 23:28:23 +0200 Rafał Mużyło > scrisse: > > > but the change on cancel was > > recently fixed in bug . in regard of gtk 3.4 and 3.6 (unfortunately, not in > > 2.24 though, even if it seems to be only a matter of a cherry-pick). > > What I mean is pressing ESC or clicking cancel unset the file name > and I didn't find a way to catch it: this is not the same issue. > > I'm using gtk 3.4.4 but I don't think it is relevant. > It's in fact not only the *very same* problem, but also while it *was* fixed on 3.4 branch, there was no release there yet containing this commit from this branch - it's post 3.4.4. PS: there's no need to CC me explictly - this is one of a few lists I'm subscribed to, that I didn't turn the delivery off. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkFileChooserButton::file-set
Il Wed, 3 Oct 2012 23:28:23 +0200 Rafał Mużyło
scrisse:
> On Wed, Oct 03, 2012 at 10:23:12PM +0200, Nicola Fontana wrote:
> > I need to catch when the file has changed in a
> > GtkFileChooserButton. I thought connecting to "file-set" was
> > enough but this signal is not emitted when the user cancels
> > (although bug 555351 does not agree [1]). Here is the proof:
> >
> >
> > #include
> >
> > int main(int argc, char **argv)
> > {
> > GtkWidget *window, *chooser;
> >
> > gtk_init(&argc, &argv);
> >
> > window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
> > chooser = gtk_file_chooser_button_new(NULL,
> > GTK_FILE_CHOOSER_ACTION_OPEN);
> > gtk_container_add(GTK_CONTAINER(window), chooser);
> >
> > g_signal_connect_swapped(chooser, "file-set",
> > G_CALLBACK(g_print), "file-set\n");
> >
> > gtk_widget_show_all(window);
> > gtk_main();
> >
> > return 0;
> > }
> >
> >
> > What am I supposed to do? I can provide my custom dialog to
> > GtkFileChooserButton but checking when the file has changed in a
> > file chooser seems a too natural request for requiring such
> > effort.
> >
> Well, I'm not 100% sure what you mean (and that "callback" of yours
> looks like it's only working by chance)
No, this is valid GTK+ code.
> but the change on cancel was
> recently fixed in bug . in regard of gtk 3.4 and 3.6 (unfortunately, not in
> 2.24 though, even if it seems to be only a matter of a cherry-pick).
What I mean is pressing ESC or clicking cancel unset the file name
and I didn't find a way to catch it: this is not the same issue.
I'm using gtk 3.4.4 but I don't think it is relevant.
Ciao.
--
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkFileChooserButton::file-set
On Wed, Oct 03, 2012 at 10:23:12PM +0200, Nicola Fontana wrote:
> I need to catch when the file has changed in a
> GtkFileChooserButton. I thought connecting to "file-set" was
> enough but this signal is not emitted when the user cancels
> (although bug 555351 does not agree [1]). Here is the proof:
>
>
> #include
>
> int main(int argc, char **argv)
> {
> GtkWidget *window, *chooser;
>
> gtk_init(&argc, &argv);
>
> window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
> chooser = gtk_file_chooser_button_new(NULL,
> GTK_FILE_CHOOSER_ACTION_OPEN);
> gtk_container_add(GTK_CONTAINER(window), chooser);
>
> g_signal_connect_swapped(chooser, "file-set",
> G_CALLBACK(g_print), "file-set\n");
>
> gtk_widget_show_all(window);
> gtk_main();
>
> return 0;
> }
>
>
> What am I supposed to do? I can provide my custom dialog to
> GtkFileChooserButton but checking when the file has changed in a
> file chooser seems a too natural request for requiring such
> effort.
>
Well, I'm not 100% sure what you mean (and that "callback" of yours
looks like it's only working by chance), but the change on cancel was
recently fixed in bug 645065 in regard of gtk 3.4 and 3.6 (unfortunately, not
in 2.24 though, even if it seems to be only a matter of a cherry-pick).
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Handle "Enter" pressing at GtkEntry
On Wed, 2012-10-03 at 20:18 +0200, David Nečas wrote: > On Wed, Oct 03, 2012 at 09:42:24AM -0500, Yury Alyaev wrote: > > What is the right way to catch "Enter" pressing at the end of the > > text input to GtkEntry. The obvious way is conecting the callback to > > the "activate" signal, but for some reason documentation says > > "Applications should not connect to it". > > My Gtk+ documentation says the opposite: > > ...it is also commonly used by applications to intercept activation > of entries. > > and I've been using it for a long time without problems. > > Yeti I asked a similar question some time ago https://mail.gnome.org/archives/gtk-list/2012-March/msg00033.html Seems that the irritating statement "Applications should not connect to it, but may emit it..." http://developer.gnome.org/gtk/stable/GtkEntry.html#GtkEntry-activate is removed for current GTK3. Thanks. http://developer.gnome.org/gtk3/stable/GtkEntry.html#GtkEntry-activate ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkFileChooserButton::file-set
I need to catch when the file has changed in a
GtkFileChooserButton. I thought connecting to "file-set" was
enough but this signal is not emitted when the user cancels
(although bug 555351 does not agree [1]). Here is the proof:
#include
int main(int argc, char **argv)
{
GtkWidget *window, *chooser;
gtk_init(&argc, &argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
chooser = gtk_file_chooser_button_new(NULL,
GTK_FILE_CHOOSER_ACTION_OPEN);
gtk_container_add(GTK_CONTAINER(window), chooser);
g_signal_connect_swapped(chooser, "file-set",
G_CALLBACK(g_print), "file-set\n");
gtk_widget_show_all(window);
gtk_main();
return 0;
}
What am I supposed to do? I can provide my custom dialog to
GtkFileChooserButton but checking when the file has changed in a
file chooser seems a too natural request for requiring such
effort.
Ciao.
--
Nicola
[1] https://bugzilla.gnome.org/show_bug.cgi?id=555351
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Handle "Enter" pressing at GtkEntry
On Wed, Oct 03, 2012 at 09:42:24AM -0500, Yury Alyaev wrote: > What is the right way to catch "Enter" pressing at the end of the > text input to GtkEntry. The obvious way is conecting the callback to > the "activate" signal, but for some reason documentation says > "Applications should not connect to it". My Gtk+ documentation says the opposite: ...it is also commonly used by applications to intercept activation of entries. and I've been using it for a long time without problems. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Handle "Enter" pressing at GtkEntry
Hello all, What is the right way to catch "Enter" pressing at the end of the text input to GtkEntry. The obvious way is conecting the callback to the "activate" signal, but for some reason documentation says "Applications should not connect to it". The alternative method is just to catch key press event and check if the "Enter" key is pressed, but this looks less convenient comparing with catching the "activate" signal. Why is caonnecting user callback to "activate" signal bad? Regards, Yury. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
