Re: GdkKeymap default for Display problem
Following this up: > Using Gtk 3.22.11 under Debian stable I get a different keymap than > the > one the application was launched with on calling > > gdk_keymap_get_for_display(gdk_display_get_default ()) > > This shows up when there are two keymaps available and I select the > alternative one for a terminal, launch the application and then use > > gdk_keymap_translate_keyboard_state () > > what happens is that it is *not* translated using the keymap that was > used to launch the application (and which shows up in GtkEntry etc > widgets). Instead it is translated using the "default" keymap for the > Desktop. > This lead me to look at the documentation and I see that there is > nothing to suggest you can access the GdkKeymap that the GtkWidgets > are > using - indeed there is nothing to suggest you can create a GdkKeymap > other than getting this "default for display" keymap. > > Is there something I've missed here? > > Richard Shann I've created a minimal example of the problem: //gcc -Wall KeyMap-test.c -o KeyMapTest `pkg-config --cflags --libs gtk+-3.0` //Tested on debian stable and GTK3.22.18 #include static void callback (GtkWidget * widget, GdkEventKey * event) { guint keyval; g_print ("key press event: keyval %d (%s)\n", event->keyval, gdk_keyval_name(event->keyval)); gdk_keymap_translate_keyboard_state (gdk_keymap_get_default (), event->hardware_keycode,0,0, &keyval, NULL, NULL, NULL); g_print ("After keymap translate keyval %d (%s)\n", keyval, gdk_keyval_name(keyval)); } int main(int argc, char **argv) { gtk_init(&argc, &argv); GtkWidget *top_window=gtk_window_new(GTK_WINDOW_TOPLEVEL); g_signal_connect (top_window, "destroy", G_CALLBACK(gtk_main_quit), NULL); g_signal_connect (G_OBJECT(top_window), "key-press-event", G_CALLBACK (callback), NULL); gtk_widget_show_all (top_window); gtk_main(); return 0; } The output on setting a US keyboard in the terminal with a UK keyboard as the desktop default and pressing the key code 51 rshann@debian:~$ ./KeyMapTest key press event: keyval 92 (backslash) After keymap translate keyval 35 (numbersign) The US key map is used for the GtkWindow widget to provide the keyval 92 but then the UK keymap is used for the call to gdk_keymap_translate_keyboard_state() giving the keyval 35 Is this a bug in Gtk 3.22? Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GdkKeymap default for Display problem
Using Gtk 3.22.11 under Debian stable I get a different keymap than the one the application was launched with on calling gdk_keymap_get_for_display(gdk_display_get_default ()) This shows up when there are two keymaps available and I select the alternative one for a terminal, launch the application and then use gdk_keymap_translate_keyboard_state () what happens is that it is *not* translated using the keymap that was used to launch the application (and which shows up in GtkEntry etc widgets). Instead it is translated using the "default" keymap for the Desktop. This lead me to look at the documentation and I see that there is nothing to suggest you can access the GdkKeymap that the GtkWidgets are using - indeed there is nothing to suggest you can create a GdkKeymap other than getting this "default for display" keymap. Is there something I've missed here? Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_log_set_fatal_mask () does not appear to be present
> Date: Sun, 09 Sep 2018 20:21:54 +0100 > From: Richard Shann > To: gtk-app-devel-list@gnome.org > Subject: g_log_set_fatal_mask () does not appear to be present > Message-ID: <1536520914.1394.1.ca...@rshann.plus.com> > Content-Type: text/plain; charset="UTF-8" > > I used to call > g_log_set_fatal_mask () > > via gdb to catch the place where critical errors happen. But now I > get > > (gdb) call g_log_set_fatal_mask ("Gtk", 0x) > No symbol "g_log_set_fatal_mask" in current context. I've been trying to dig deeper into this (guessing that g_log_set_fatal_mask may have become a macro or something) and find that I can call it after gtk_init_check() from within the program without a compile time error, but the program still does not stop on errors. Indeed g_print ("Error level was %x\n", g_log_set_fatal_mask (NULL, -1)); g_print ("Error level now %x\n", g_log_set_fatal_mask (NULL, -1)); prints out 0x5 as the initial setting of the mask and 0xfffd as the setting after setting to -1 but I then can trigger a slew of (denemo:1717): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar errors without the program stopping. Is there something involving threads here? Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
g_log_set_fatal_mask () does not appear to be present
I used to call g_log_set_fatal_mask () via gdb to catch the place where critical errors happen. But now I get (gdb) call g_log_set_fatal_mask ("Gtk", 0x) No symbol "g_log_set_fatal_mask" in current context. any ideas? Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to get a directory from the user
On Mon, 2018-06-04 at 13:24 +0100, Emmanuele Bassi wrote: > > > On 4 June 2018 at 13:06, Richard Shann > wrote: > > Hi, > > > > I have seen GtkFileChooser for getting a file from the user, but > > how to > > get a directory (folder)? > > > > You can use GtkFileChooser with GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER > as the action: Thank you! Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
How to get a directory from the user
Hi, I have seen GtkFileChooser for getting a file from the user, but how to get a directory (folder)? Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_log_set_fatal_mask() not working for me.
On Sun, 2017-12-17 at 17:54 -0500, cecas...@aol.com wrote: > > Hi Richard, > > This sounds similar to the problem Dino Aljević had in "Scrolled > TreeView and size allocation warnings" in this list in September? > > I can get the warning > > "(treeview4:3830): Gtk-WARNING **: Allocating size to GtkWindow > 0x843e188 without calling gtk_widget_get_preferred_width/height(). > How does the code know the size to allocate?" > > with the following code with GTK3.22.26 but I don't see the warning > in GTK3.18.9. To get the warning expand the treeview until the list > extends past the window boundry. I looked on Bugzilla but I didn't > see it listed there. I am not great at finding things on Bugzilla so > that doesn't mean it isn't there. > > Do you have some test code to produce the GtkScrollbar warning you > are seeing? No, indeed, the warnings are appearing during the start up of a very large program and I'm trying to locate the part of the program they are coming from ... > > For the g_log_set_fatal_mask() and a runtime > stop, try starting your code with > > G_DEBUG=fatal-warnings > That's good to know, but it is rather a blunt instrument, calling g_log_set_fatal_mask() from the debugger normally lets you pin down particular warnings. Bizarrely, at present gdb has suddenly got amnesia and declares (gdb) call g_log_set_fatal_mask ("Gtk", 0x) No symbol "g_log_set_fatal_mask" in current context. Where previously it was returning the previous mask as it should. > It is a warning though. Something needs to be fixed but your program > should run fine. Yes, it doesn't seem to cause a problem, but there is worse to come - I have had a couple of crashes coming from Gtk since upgrading to Debian Stable (hence Gtk 3.22) and I can get this: Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar during a gtk_widget_show_all () of a widget that has previously been working. At least I know where this one is happening... Thanks for you helpful reply, Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
g_log_set_fatal_mask() not working for me.
I am getting a warning message: Gtk-WARNING **: Allocating size to GtkScrollbar 0x5647efd0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate? however when I call call g_log_set_fatal_mask ("Gtk", 1<<4) at the start of main the warning is not converted into a fatal error. I've tried call g_log_set_fatal_mask ("Gtk", 0x) as well, to no avail. This is with Gtk version runtime: 3.22.11, compiled against: 3.22.11 Any suggestions to track down the source of the trouble gratefully received... Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to find CSS style syntax changes between Gtk 3.12 and Gtk 3.22
On Wed, 2017-05-10 at 18:34 +0100, Emmanuele Bassi wrote: > On 2017-05-08 at 13:57, Richard Shann wrote: > > On Mon, 2017-05-08 at 12:28 +0100, Emmanuele Bassi wrote: > > > > > But I will have to wait for > > > > Debian to catch up with Gtk 3.20 before I can seriously look at this. > > > > > > And this is why I suggest you use a CSS class, instead; > > > > Is that something different from the GtkWidgetClass that the widget has? > > CSS classes are not related to widget classes. > > https://developer.mozilla.org/en-US/docs/Web/CSS/Class_selectors > > > Are there a gtk_css_class_new() and a gtk_widget_assign_css_class() > > functions to use them? > > You want `GtkStyleContext` and `gtk_style_context_add_class()`: > > https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-get-style-context > https://developer.gnome.org/gtk3/stable/GtkStyleContext.html#gtk-style-context-add-class > > > I'm completely at sea. > > You probably want to read the API reference, then: > > https://developer.gnome.org/gtk3/stable/theming.html Thank you for the references. I had seen that stuff but was lost right at the start, it would seem that a background in HTML would be helpful, and > > Additionally, you may want to read online resources about CSS. some notion about what CSS is. So I will have a lot of reading to do. But, meanwhile, I see that the code I posted (which I didn't originate, just cooked up from someone else's earlier posting) did use `GtkStyleContext` though not 'gtk_style_context_add_class()' but rather 'gtk_style_context_add_provider()' so perhaps it is ok code, if the lookup of the css selector were more robust. I append a copy, in case anyone cares to point out deficiencies. Richard Shann 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8>< void set_background_color(GtkWidget *w, gchar *color) { GtkCssProvider *gcp; GtkStyleContext *gsc; gsc = gtk_widget_get_style_context(w); gchar *type = get_css_selector(w); gchar *str = g_strdup_printf ("%s {background-color: %s;}", type, color); //g_print ("%s", str); gcp= gtk_css_provider_new(); gtk_css_provider_load_from_data(gcp, str, -1, 0); g_free (str); gtk_style_context_add_provider(gsc, GTK_STYLE_PROVIDER(gcp), GTK_STYLE_PROVIDER_PRIORITY_APPLICATION); } 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8>< ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to find CSS style syntax changes between Gtk 3.12 and Gtk 3.22
On Mon, 2017-05-08 at 12:28 +0100, Emmanuele Bassi wrote: > On 8 May 2017 at 12:04, Richard Shann wrote: > > >> But I'd strongly recommend you use CSS classes instead of styling the > >> bare element name. > >> > >> CSS selectors in GTK+ work exactly like the HTML counterpart; you can > >> style "div" or "p" directly, but it's often much more appropriate to > >> create a specific CSS class, like "green-background", and add it to > >> the widget you wish to style. > > > > I didn't find anything describing creating a GtkWidgetClass in the > > gtk3/stable documentation, it seems that there is a field in the > > GtkWidget structure pointing to such a structure accessed via > > > > GTK_WIDGET_GET_CLASS (widget) > > Yes, this is part of basic GObject usage: each instance has a pointer > to its instantiating class structure. > > > so I imagine that using > > > > gtk_widget_class_set_css_name (class, name) > > > > could mean you would get control over the style of that widget and any > > others whose class you assigned that name. > > You don't have *control* over the style. You can *add* to the existing > style — which may include undoing what the existing style does, but > then you need to know what the style does, or essentially reset CSS > properties by using their initial state, see: > https://drafts.csswg.org/css-cascade-3/#initial > > This is how CSS works. The only way for you to control the style of a > GTK+ application I haven't thought about trying to control the style of my application, just do things like creating a label with a certain background color. > is to ship your own theme, and load it in place of > the user theme. > > CSS is a *very* powerful set of rules for rendering content using a > declarative syntax; it's *really* not a bunch of color definitions, > like the style system in GTK+ 2.x. You will need to learn how CSS > works in order to use it. > > > But I will have to wait for > > Debian to catch up with Gtk 3.20 before I can seriously look at this. > > And this is why I suggest you use a CSS class, instead; Is that something different from the GtkWidgetClass that the widget has? Are there a gtk_css_class_new() and a gtk_widget_assign_css_class() functions to use them? I'm completely at sea. Meanwhile for anyone with an application that has to compile with versions of Gtk+ before and after version 3.20 here is the code that is currently working for me to set the background color of a widget: 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8>< static gchar *get_css_selector (GtkWidget *w) { static gchar *ret = NULL; #if ((GTK_MAJOR_VERSION==3) && (GTK_MINOR_VERSION>=20)) g_free (ret); ret = g_ascii_strdown (g_strdup (g_type_name (G_TYPE_FROM_INSTANCE (w))), -1); return ret+3; #else ret = (gchar *)g_type_name (G_TYPE_FROM_INSTANCE (w)); return ret; #endif } void set_background_color(GtkWidget *w, gchar *color) { GtkCssProvider *gcp; GtkStyleContext *gsc; gsc = gtk_widget_get_style_context(w); gchar *type = get_css_selector(w); gchar *str = g_strdup_printf ("%s {background-color: %s;}", type, color); //g_print ("%s", str); gcp= gtk_css_provider_new(); gtk_css_provider_load_from_data(gcp, str, -1, 0); g_free (str); gtk_style_context_add_provider(gsc, GTK_STYLE_PROVIDER(gcp), GTK_STYLE_PROVIDER_PRIORITY_APPLICATION); } 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8>< Thank you for your patience, Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to find CSS style syntax changes between Gtk 3.12 and Gtk 3.22
On Mon, 2017-05-08 at 08:42 +0100, Emmanuele Bassi wrote: > On 7 May 2017 at 20:57, Richard Shann wrote: > > On Sun, 2017-05-07 at 19:52 +, Emmanuele Bassi wrote: > >> > >> On Sun, 7 May 2017 at 19:53, Richard Shann > >> wrote: > >> > >> On Sun, 2017-05-07 at 17:54 +0100, Emmanuele Bassi wrote: > >> > On 7 May 2017 at 16:52, Richard Shann > >> wrote: > >> > > I have a test program that pops up a label with a > >> customized > >> > background > >> > > and foreground color. This works in 3.12 using the syntax > >> > > > >> > > "GtkLabel {background-color: #00;}" > >> > > > >> > > and > >> > > > >> > > "GtkLabel {color: #FF00FF;}" > >> > > > >> > > but fails in 3.22 > >> > > >> > The selector for labels is "label" since GTK+ 3.20. > >> > >> Thank you very much for this. Is there a function to get the > >> selector > >> for a widget? Sort of gchar *gtk_widget_get_css_selector > >> (GtkWidget *w) > >> thing? > >> > >> > >> I'm not sure what would that accomplish. Could you elaborate? > > > > It would enable my program to work. Currently it gets the string > > "GtkLabel" from the type name of the widget, and that works for setting > > the background color of various widgets in the program, replacing > > deprecated calls. > > I'm still puzzled as to why you need programmatic access to the CSS > element name. > > Are you generating CSS fragments from a generic function with only the > widget type as the input? yes > > You can use `gtk_widget_class_get_css_name()`: > > > https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-class-get-css-name > thanks for alerting me to this. My development system is Debian Stable, so I don't have access to this function as it is from 3.20, however it gave me a starting point for looking at what will be possible. > But I'd strongly recommend you use CSS classes instead of styling the > bare element name. > > CSS selectors in GTK+ work exactly like the HTML counterpart; you can > style "div" or "p" directly, but it's often much more appropriate to > create a specific CSS class, like "green-background", and add it to > the widget you wish to style. I didn't find anything describing creating a GtkWidgetClass in the gtk3/stable documentation, it seems that there is a field in the GtkWidget structure pointing to such a structure accessed via GTK_WIDGET_GET_CLASS (widget) so I imagine that using gtk_widget_class_set_css_name (class, name) could mean you would get control over the style of that widget and any others whose class you assigned that name. But I will have to wait for Debian to catch up with Gtk 3.20 before I can seriously look at this. Thanks again for your responses. Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to find CSS style syntax changes between Gtk 3.12 and Gtk 3.22
On Sun, 2017-05-07 at 19:52 +, Emmanuele Bassi wrote: > > On Sun, 7 May 2017 at 19:53, Richard Shann > wrote: > > On Sun, 2017-05-07 at 17:54 +0100, Emmanuele Bassi wrote: > > On 7 May 2017 at 16:52, Richard Shann > wrote: > > > I have a test program that pops up a label with a > customized > > background > > > and foreground color. This works in 3.12 using the syntax > > > > > > "GtkLabel {background-color: #00;}" > > > > > > and > > > > > > "GtkLabel {color: #FF00FF;}" > > > > > > but fails in 3.22 > > > > The selector for labels is "label" since GTK+ 3.20. > > Thank you very much for this. Is there a function to get the > selector > for a widget? Sort of gchar *gtk_widget_get_css_selector > (GtkWidget *w) > thing? > > > I'm not sure what would that accomplish. Could you elaborate? It would enable my program to work. Currently it gets the string "GtkLabel" from the type name of the widget, and that works for setting the background color of various widgets in the program, replacing deprecated calls. > > > Looking through a few widgets it seems the rule is chop off > the > Gtk prefix and lower case what remains ... is that guaranteed? > > > No, it's not. It's part of the API reference for a reason. > > If somebody creates a custom widget, with a custom CSS element name, > then they will have to document it. > yes, but surely there is no harm in you documenting what you do with the widgets that come with Gtk in order to create a selector name? Otherwise a) we have to look it up each time b) we can't create it programmatically for programs like the one I posted. Richard > ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to find CSS style syntax changes between Gtk 3.12 and Gtk 3.22
On Sun, 2017-05-07 at 17:54 +0100, Emmanuele Bassi wrote: > On 7 May 2017 at 16:52, Richard Shann wrote: > > I have a test program that pops up a label with a customized > background > > and foreground color. This works in 3.12 using the syntax > > > > "GtkLabel {background-color: #00;}" > > > > and > > > > "GtkLabel {color: #FF00FF;}" > > > > but fails in 3.22 > > The selector for labels is "label" since GTK+ 3.20. Thank you very much for this. Is there a function to get the selector for a widget? Sort of gchar *gtk_widget_get_css_selector (GtkWidget *w) thing? Looking through a few widgets it seems the rule is chop off the Gtk prefix and lower case what remains ... is that guaranteed? Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
How to find CSS style syntax changes between Gtk 3.12 and Gtk 3.22
I have a test program that pops up a label with a customized background and foreground color. This works in 3.12 using the syntax "GtkLabel {background-color: #00;}" and "GtkLabel {color: #FF00FF;}" but fails in 3.22 How can I track changes needed to CSS syntax from one version to another in the documentation (mostly I struggle to find the correct syntax :( ) Any help appreciated: test code follows. 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8>< //gcc -Wall TestStyleChange.c -o TestStyleChange `pkg-config --cflags --libs gtk+-3.0` #include void set_background_color(GtkWidget *w, gchar *color) { GtkCssProvider *gcp; GtkStyleContext *gsc; gsc = gtk_widget_get_style_context(w); const gchar *type = g_type_name (G_TYPE_FROM_INSTANCE (w)); gchar *str = g_strdup_printf ("%s {background-color: %s;}", type, color); g_print("%s", str); gcp= gtk_css_provider_new(); gtk_css_provider_load_from_data(gcp, str, -1, 0); g_free (str); gtk_style_context_add_provider(gsc, GTK_STYLE_PROVIDER(gcp), GTK_STYLE_PROVIDER_PRIORITY_APPLICATION); } void set_foreground_color(GtkWidget *w, gchar *color) { GtkCssProvider *gcp; GtkStyleContext *gsc; gsc = gtk_widget_get_style_context(w); const gchar *type = g_type_name (G_TYPE_FROM_INSTANCE (w)); gchar *str = g_strdup_printf ("%s {color: %s;}", type, color); g_print("%s", str); gcp= gtk_css_provider_new(); gtk_css_provider_load_from_data(gcp, str, -1, 0); g_free (str); gtk_style_context_add_provider(gsc, GTK_STYLE_PROVIDER(gcp), GTK_STYLE_PROVIDER_PRIORITY_APPLICATION); } int main(int argc, char **argv) { gtk_init(&argc, &argv); GtkWidget *top_window=gtk_window_new(GTK_WINDOW_TOPLEVEL); g_signal_connect (top_window, "destroy", G_CALLBACK(gtk_main_quit), NULL); GtkWidget *eventbox = gtk_event_box_new (); GtkWidget *label=gtk_label_new("Label"); set_background_color (label, "#00"); set_foreground_color (label, "#FF00FF"); gtk_widget_set_size_request(label, 400, 400); gtk_container_add (GTK_CONTAINER (eventbox), label); gtk_container_add (GTK_CONTAINER(top_window), eventbox); gtk_widget_show_all (top_window); gtk_main(); return 0; } 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8>< Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Trouble setting the value of a GtkAdjustment
On Mon, 2017-04-24 at 14:48 -0400, cecas...@aol.com wrote: > > Hi Richard, > > It looks like how you add containers makes a difference in this case. > Also the window placement might have to be adjusted after the window > is shown. Here is a try at it. Thank you very much - it seems you are right, by moving the gtk_container_add() calls until just before the gtk_show_all() the GtkAdjustment widget becomes controllable. The values it has are no longer what were set when it was created however, so I set it with this code after the gtk_show_all() call: gdouble lower, upper, page; lower = gtk_adjustment_get_lower (hadj); upper = gtk_adjustment_get_upper (hadj); page = gtk_adjustment_get_page_size (hadj); //g_print ("Lower ... %f %f %f\n", lower, upper, page); gtk_adjustment_set_value (hadj, (upper-page - lower)/2); which gets the horizontal slider in the middle. The values when printed out are: Lower ... 0.00 1901.00 800.00 where those values come from is a mystery. And, I suppose the way it changes depending on the order of placing the widgets inside each other will have to remain a mystery too. Thanks once again, Richard > > Eric > > > //gcc -Wall adj1.c -o adj1 `pkg-config --cflags --libs gtk+-3.0` > //Tested on Ubuntu16.04 and GTK3.18 > > #include > > int main(int argc, char **argv) > { >gtk_init(&argc, &argv); > >GtkWidget *keyboard_window=gtk_window_new(GTK_WINDOW_TOPLEVEL); >gtk_window_set_title(GTK_WINDOW(keyboard_window), "Keyboard > Window"); >gtk_window_set_default_size(GTK_WINDOW(keyboard_window), 200, 200); >gtk_window_set_position(GTK_WINDOW(keyboard_window), > GTK_WIN_POS_CENTER); >g_signal_connect(keyboard_window, "destroy", > G_CALLBACK(gtk_main_quit), NULL); > >GtkWidget *label=gtk_label_new("Label"); >gtk_widget_set_size_request(label, 400, 400); > >//GtkAdjustment *ADJ = gtk_adjustment_new (1.5, 0.0, 2.0, 0.01, > 0.01, 0.01); >//GtkWidget *sw = gtk_scrolled_window_new (ADJ , gtk_adjustment_new > (1.5, 0.0, 2.0, 0.01, 0.01, 0.01)); >GtkAdjustment *ADJ = gtk_adjustment_new (100.0, 0.0, 400.0, 0.0, > 0.0, 0.0); >GtkWidget *sw = gtk_scrolled_window_new (ADJ , ADJ); > >//gtk_adjustment_set_value (ADJ, 1.2); >g_print ("value %p is %f\n", ADJ, gtk_adjustment_get_value (ADJ)); > >GtkWidget *keyboard=gtk_grid_new(); >gtk_grid_attach(GTK_GRID(keyboard), label, 0, 0, 1, 1); >gtk_container_add(GTK_CONTAINER(sw), keyboard); >gtk_container_add(GTK_CONTAINER(keyboard_window), sw); > >//gtk_container_add(GTK_CONTAINER(keyboard_window), sw); >//GtkWidget *keyboard=gtk_grid_new(); >//gtk_grid_attach(GTK_GRID(keyboard), label, 0, 0, 1, 1); >//gtk_container_add(GTK_CONTAINER(sw), keyboard); > >gtk_widget_show_all(keyboard_window); > >gtk_adjustment_set_value (ADJ, 100.0); > >gtk_main(); > >return 0; > } > > ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Trouble setting the value of a GtkAdjustment
Compiling with Gtk 3.14.5 I can't seem to set the "value" of a GtkAdjustment once I have added a widget to it with gtk_container_add(), it seems to be locked at 0.0 The code looks like this fragment: 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8>< GtkAdjustment *ADJ = gtk_adjustment_new (1.5, 0.0, 2.0, 0.01, 0.01, 0.01); GtkWidget *sw = gtk_scrolled_window_new (ADJ , gtk_adjustment_new (1.5, 0.0, 2.0, 0.01, 0.01, 0.01)); gtk_container_add (GTK_CONTAINER(keyboard_window), sw); gtk_container_add (GTK_CONTAINER(sw), keyboard); gtk_adjustment_set_value (ADJ, 1.2); g_print ("value %p is %f\n", ADJ, gtk_adjustment_get_value (ADJ)); 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8>< where keyboard_window is a toplevel GtkWindow, and keyboard is a GtkGrid. The value printed out is always 0.0 after the widget is added to the scrolled window. Can anyone help? I'm trying to center the scroll-bars on the window. Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk-app-devel-list Digest, Vol 156, Issue 16
> Date: Fri, 21 Apr 2017 09:01:54 + > From: R?ben Rodrigues > To: "gtk-app-devel-list@gnome.org" > Subject: CheckButton background color > Message-ID: > > > > Content-Type: text/plain; charset="utf-8" > > Hi, > > Someone knows how to change gtkcheckbutton background and size in CSS? The GNU Denemo program uses this function that changes the background color of a widget: void set_background_color(GtkWidget *w, gchar *color) { GtkCssProvider *gcp; GtkStyleContext *gsc; gsc = gtk_widget_get_style_context(w); const gchar *type = g_type_name (G_TYPE_FROM_INSTANCE (w)); gchar *str = g_strdup_printf ("%s {background-color: %s;}", type, color); gcp= gtk_css_provider_new(); gtk_css_provider_load_from_data(gcp, str, -1, 0); g_free (str); gtk_style_context_add_provider(gsc, GTK_STYLE_PROVIDER(gcp), GTK_STYLE_PROVIDER_PRIORITY_APPLICATION); } HTH Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to change GTK+3 label color dynamically
From: R?ben Rodrigues > On 16-03-2017 11:20, Tilo Villwock wrote: > > Am Donnerstag, den 16.03.2017, 09:55 + schrieb R?ben Rodrigues: > >> Hi, > >> > >> THanks. This is dynamically? I need in c language if possible :S > > Dynamic version: > > > > ... > > > > static GtkCssProvider* provider = NULL; > > > > static void > > set_label_color(GtkWidget* label, const char* color) > > { > > const char* format = "label { color: %s; }"; > > size_t length = strlen(format) - 2 + 1; > > char style[length]; > > sprintf(style, format, color); > > > > if (provider == NULL) { > > /* only create and add the provider the first time */ > > provider = gtk_css_provider_new(); > > gtk_style_context_add_provider( > > gtk_widget_get_style_context(label), > > GTK_STYLE_PROVIDER(provider), > > GTK_STYLE_PROVIDER_PRIORITY_APPLICATION); > > g_object_unref(provider); > > } > > > > gtk_css_provider_load_from_data(provider, style, -1, NULL); > > } > > > > ... > > > > This might not be ideal in all situations. Just make sure you don't > > create a new provider everytime you set a new color. Hope that helps. > > > > --Tilo > > Hi, > > This is what i have, and don't works... > I have this function (for any widget type): void set_background_color(GtkWidget *w, gchar *color) { GtkCssProvider *gcp; GtkStyleContext *gsc; gsc = gtk_widget_get_style_context(w); const gchar *type = g_type_name (G_TYPE_FROM_INSTANCE (w)); gchar *str = g_strdup_printf ("%s {background-color: %s;}", type, color); gcp= gtk_css_provider_new(); gtk_css_provider_load_from_data(gcp, str, -1, 0); g_free (str); gtk_style_context_add_provider(gsc, GTK_STYLE_PROVIDER(gcp), GTK_STYLE_PROVIDER_PRIORITY_APPLICATION); } I don't know if there is a memory leak here though... HTH Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: caret-color (and caret-width?)
> From: Colomban Wendling > To: gtk-app-devel-list@gnome.org > Subject: Re: caret-color (and caret-width?) > Message-ID: <6524684c-f52e-ec20-0906-b63224766...@herbesfolles.org> > Content-Type: text/plain; charset=windows-1252 > > Hi, > > Le 26/01/2017 ? 16:57, Richard Shann a ?crit : > > I see at > > > > https://developer.gnome.org/gtk3/stable/chap-css-properties.html > > > > that there is a caret-color property. Is it possible to change the > > thickness of the text caret? > > Yes: > https://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget--s-cursor-aspect-ratio, > that is "-GtkWidget-cursor-aspect-ratio". > I see - I did spot that cursor-aspect-ratio style item, but could not guess that I had to prefix it with -GtkWidget- So I have the following code which now works: str = "GtkTextView {-GtkWidget-cursor-aspect-ratio: 0.2;}"; gcp= gtk_css_provider_new(); gtk_css_provider_load_from_data(gcp, str, -1, 0); gtk_style_context_add_provider(gsc, GTK_STYLE_PROVIDER(gcp), GTK_STYLE_PROVIDER_PRIORITY_APPLICATION); > > and, how exactly is caret-color supposed to be set I have: > > > > str = "GtkTextView {caret-color: rgb(255,0,80);}"; > > Which GTK version do you use? this property is new in 3.20, before that > you had to use "-GtkWidget-cursor-color" instead. ah, yes, that was the trouble, well that and not finding anything to suggest that I needed to prefix the style property name with -GtkWidget- thank you very much for this I'm now back on course. Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk_dialog_get_action_area() deprecation
On Sat, 2016-12-31 at 20:11 +, Emmanuele Bassi wrote: > consider using a small > CSS fragment shipped with your own application, if you want to change > the appearance of your UI, instead of hardcoding a space. > > Especially now that the CSS system is documented and extremely > powerful. are you referring to https://developer.gnome.org/gtk3/stable/chap-css-properties.html here? This seems to be just some examples. Looking back through the widget hierarchy I see sometimes "Style Properties" but this example from such an entry (for GtkWidget) GtkWidget:cursor-color has been deprecated since version 3.20 and should not be used in newly-written code. Use the caret-color CSS property indicates that these "Style Properties" are not the CSS properties that can be altered for the widget concerned. So where are they documented, on a widget by widget basis. Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
caret-color (and caret-width?)
I see at https://developer.gnome.org/gtk3/stable/chap-css-properties.html that there is a caret-color property. Is it possible to change the thickness of the text caret? and, how exactly is caret-color supposed to be set I have: str = "GtkTextView {caret-color: rgb(255,0,80);}"; gcp= gtk_css_provider_new(); gtk_css_provider_load_from_data(gcp, str, -1, 0); gtk_style_context_add_provider(gsc, GTK_STYLE_PROVIDER(gcp), GTK_STYLE_PROVIDER_PRIORITY_APPLICATION); but this doesn't seem to work (I have other code such as str = "GtkTextView:selected {background-color: rgb(200,128,0);}"; gcp= gtk_css_provider_new(); gtk_css_provider_load_from_data(gcp, str, -1, 0); gtk_style_context_add_provider(gsc, GTK_STYLE_PROVIDER(gcp), GTK_STYLE_PROVIDER_PRIORITY_APPLICATION); working nicely). Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: pango_scan_string() deprecation
On Thu, 2017-01-05 at 17:02 +0100, infirit wrote: > Op 01/05/2017 om 03:39 PM schreef Richard Shann: > > I see that pango_scan_string() is deprecated since version 1.38 > > but the documentation doesn't indicate what it should be replaced with - > > anyone got any ideas? > > See [1] for the reasoning. Its now deprecated but from the looks of it > there is no intention just yet to remove it. > > And there is no replacement but its fairly simple and self contained so > you could just copy [2] it and include it in your own code. Thank you I've done that. Richard > > ~infirit > > [1] https://bugzilla.gnome.org/show_bug.cgi?id=682840 > [2] https://git.gnome.org/browse/pango/tree/pango/pango-utils.c#n448 > ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
pango_scan_string() deprecation
I see that pango_scan_string() is deprecated since version 1.38 but the documentation doesn't indicate what it should be replaced with - anyone got any ideas? Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk_dialog_get_action_area() deprecation
On Sat, 2016-12-31 at 20:10 +, Emmanuele Bassi wrote: > Hi; > > On 31 December 2016 at 16:03, Richard Shann wrote: > > On Sat, 2016-12-31 at 15:44 +, Emmanuele Bassi wrote: > >> Hi; > >> > >> > >> Deprecations will only impact you if you want to update the code base > >> to the next major API bump. > > > > Yes, it is to be ready for GTK4 that I am working on these. > > > >> Since you don't have or want to commit resources to do so, > > > > I am committing my meagre resources to this. > > I'm sorry to say this, but then you'll likely need more than just > replacing deprecated API. In some cases we do expect changes in how > applications are designed, if they want to keep up with new > environments and human interface guidelines. I haven't thought of trying to do either of those - I'm happy if people with a computer with keyboard, mouse and one (preferably two) large screens can use the program - I'm not sure if touch screens, virtual keyboards etc would be feasible for this sort of work. > > That's also why we generally expect mature, low-maintenance > applications, to bundle a copy of GTK+ if they rely on a specific API. > On Linux, you can look at using Flatpak to build and distribute your > application. Thanks for this pointer - I'm not sure how we create binaries for GNU/Linux at the moment, but I'll flag this up as a possibility. > > > I have just got to this > > one: > > > > gtk_widget_reparent() is deprecated. > > > > Following the suggestion it seems this can be avoided with this: > > > > #define gtk_widget_reparent(w,p) > > (g_object_ref(G_OBJECT(w)),gtk_container_remove(GTK_CONTAINER(gtk_widget_get_parent(w)), > > w),gtk_container_add(GTK_CONTAINER(p), w),g_object_unref(G_OBJECT(w))) > > More or less, yes. > > The reparent() call was a call needed to avoid costly > mapping/unmapping of real X11 resources, back in the day; once we > stopped using real windowing system resources for each widget, > reparent() relied on side effects and widget authors always doing the > right thing, which exposed a bunch of bugs every time somebody wrote a > new widget. So the idea is to always remove and add a widget, instead > of reparenting it. This way, all code paths get consolidated. > > > I think it would make developers of applications feel happier if some > > indication was given as to why something was deprecated so as to guide > > them in re-working the code. > > Please, feel free to file bugs when a deprecation does not have a > suggestion. We usually try to be explicit, but sometimes it's either > complicated or we simply forget. > > > (I'm assuming there's some reason that this > > macro is not simply put into a header). > > Because macros are not bindable anyway, so we generally don't use them > as API. The only exceptions are the type system macros, but we are > kind of replacing them with inlined functions, and those are > implemented by other means in language bindings anyway. > > We also do not provide a "compatibility layer" because now we'd have > to deal with the bugs in two separate layers, and the bad interactions > with applications and toolkit. Ah, a macro wouldn't be a good thing, I see. Though I'm still not so clear why the implementation of the function was not just simplified to the above code when the fancier stuff had become unnecessary. No need to invoke the deprecation machinery. Perhaps it's in the interest of a shorter, "cleaner" API, or is there some (conceivable) type of GtkWidget for which the above code would not work? Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk_dialog_get_action_area() deprecation
On Sat, 2016-12-31 at 15:44 +, Emmanuele Bassi wrote: > Hi; > > > Deprecations will only impact you if you want to update the code base > to the next major API bump. Yes, it is to be ready for GTK4 that I am working on these. > Since you don't have or want to commit resources to do so, I am committing my meagre resources to this. I have just got to this one: gtk_widget_reparent() is deprecated. Following the suggestion it seems this can be avoided with this: #define gtk_widget_reparent(w,p) (g_object_ref(G_OBJECT(w)),gtk_container_remove(GTK_CONTAINER(gtk_widget_get_parent(w)), w),gtk_container_add(GTK_CONTAINER(p), w),g_object_unref(G_OBJECT(w))) I think it would make developers of applications feel happier if some indication was given as to why something was deprecated so as to guide them in re-working the code. (I'm assuming there's some reason that this macro is not simply put into a header). Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk_dialog_get_action_area() deprecation
On Sat, 2016-12-31 at 10:05 +, Gergely Polonkai wrote: > It would be helpful to see your exact use case. If you put only > buttons in your GtkBox, you will be fine with gtk_dialog_add_button(). > If you add other, more complex widgets, there might be a design flaw > in your application. Solutions in between might be OK, but without > knowing what you want to achieve, it's hard to tell. Thank you for you quick reply. I guess the answer to my question was "no". There isn't the manpower to investigate the purpose of this bit of code nor to start re-imagining the design 17 years in to this project, unfortunately. For now, I see that I can get at the action area via action_area = gtk_widget_get_parent (cancelbutton); which will be ok unless the GtkDialog widget gets some new internal implementation. Perhaps this will be useful to other developers hitting this deprecation. Richard > > Best, > Gergely > > > On Sat, Dec 31, 2016, 10:39 Richard Shann > wrote: > > The documentation for gtk_dialog_get_action_area() suggests > using > gtk_dialog_add_button() etc. However, my application is > storing a GtkBox > in that area - is there a way to do this, going forward? > > Richard > > > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtk_dialog_get_action_area() deprecation
The documentation for gtk_dialog_get_action_area() suggests using gtk_dialog_add_button() etc. However, my application is storing a GtkBox in that area - is there a way to do this, going forward? Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtk_key_snooper deprecation
I see gtk_key_snooper is deprecated - it is currently in use to allow the program to intercept key presses made on GtkMenuItems in my application. The suggestion is that the key press event should be intercepted by the widget. The key-press-event documentation says that the GdkWindow associated with the widget has to have the GDK_KEY_PRESS_MASK enabled for the event to be received. But gtk_widget_get_window (menu_item) gives a NULL pointer. All attempts to get g_signal_connect (G_OBJECT (menu_item), "key-press-event", G_CALLBACK(my_key_snooper), NULL); to work are failing. Can anyone suggest a way forward? Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK menus on Ubuntu
> Message: 1 > Date: Thu, 13 Oct 2016 09:49:53 -0400 (EDT) > From: Allin Cottrell > To: Jason Benjamin > Cc: gtk-app-devel-list@gnome.org > Subject: Re: GTK menus on Ubuntu > Message-ID: > > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On Tue, 11 Oct 2016, Jason Benjamin wrote: > > > On Wed, 5 Oct 2016 21:11:41 -0400 (EDT) > > Allin Cottrell wrote: > > > >> I'm wondering if anyone knows the machanism whereby Ubuntu > >> "commandeers" the main menu system of a GTK application and sticks > >> it into the global top-of-screen menu bar, or combines it with the > >> application-window title bar? I'm talking about a "traditional", > >> non-CSD GTK application, where the "natural" location for the main > >> menu system is at the top of the program's window but underneath the > >> window's title bar as added by a WM. > > > > I am familiar with this "distribution", if you could link some > > screenshots with details for the different operating systems that would > > help. That could be difficult, but if you need to use VirtualBox or > > something. I may not be able to give you an answer with the little > > time I have right now, but at least someone else may be able to with a > > more comparable question. > > Thanks, Jason. I think I now have a better handle on what's going on. > It seems that the code responsible for the effect I mentioned is > unity-gtk-module, a "GTK+ module for exporting old-style menus as > GMenuModels". There's a mechanism for "blacklisting" applications so > they're not subject to this treatment, and there's also a relevant > environment variable, UBUNTU_MENUPROXY: I gather that if this is set > to 0 then unity-gtk-module doesn't kick in. > > It seems to me that Ubuntu would have been better to adopt a > "whitelist" approach -- that is, apply this mechanism only to programs > that have been properly tested as working well under it. In the case > of my application the main menus are set up using the GtkUIManager and > GtkAction APIs, and the trouble (or one trouble) with unity-gtk-module > is that calls to gtk_action_set_sensitive() are not getting through to > the "hijacked" menus. It's hard to believe that my app is the only one > to get broken in this way. Indeed not, GNU Denemo was distributed in broken form for some years by Ubuntu, I don't know if it is fixed now... Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re:How to get objecttype
> On Fri, Sep 9, 2016 at 9:14 AM Thomas R?nshof wrote: > > > Hi, > > > > We are converting some OLD COBOL applications to GTK. > > The XML is created dynamically from SCREEN SECTIONS and we then use > > gtk_builder to get the objects into the program. > > > > Is there a way to get the objecttype ? > > If it's a gtk-combo we do this, if it's a gtk-entry we do that in the > > program and so on... In GNU-Denemo I use g_type_name (G_TYPE_FROM_INSTANCE (widget)) Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Workaround for too-fast tooltips
Here are two macros that developers may need when building with GTK versions above 3.10 They replace the tooltip system with a call to a custom display of the tooltip. #define gtk_widget_set_tooltip_text(w, t) {gchar *tip = g_strdup(t);g_object_set_data(G_OBJECT(w), "tooltip", (gpointer)tip);gtk_widget_add_events (w, FAKE_TOOLTIPS_MASK);g_signal_connect_after (w, "destroy", G_CALLBACK(free_tooltip), tip);g_signal_connect (w, FAKE_TOOLTIPS_SIGNAL, G_CALLBACK (show_tooltip), tip);} #define gtk_widget_get_tooltip_text(w) g_object_get_data (G_OBJECT(w), "tooltip") You have to write the functions show_tooltip()and free_tooltip() yourself, of course. The background to this is that if your applications uses tooltips heavily (e.g. on every item of a menu) then recent versions of GTK3 throw them up too quickly, and once they start to appear they are very difficult to throw off; the tooltip time out is no longer controllable. Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtk_image_new_from_file fails on Windows for SVG
For a long time now I have been working around gtk_image_new_from_file () not working on windows trying to load SVG images. Instead I have used pb = rsvg_pixbuf_from_file (filename, &err); and then gtk_image_new_from_pixbuf (pb) and this works for some SVG images. However, even this is failing for the SVG files generated by LilyPond, it generates an image with only the background color. I thought this might be due to the use of the syntax "currentColor" but changing this to "black" did not help. I also noticed that rsvg library has a change log entry for fixing rgb color parsing, so avoided that syntax, but I still can't get the images to load on Windows. The Gtk version being built (and run) against is 3.6.5 Any suggestions what might be causing the trouble in LilyPond's output? Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Which toplevel window is on top?
On Sun, 2015-12-20 at 19:22 +, Emmanuele Bassi wrote: > Hi; > > On 20 December 2015 at 18:01, Richard Shann wrote: > > I would like to know which of the top-level windows in my application is > > on top. Is there a way of doing this? I see that > > You can only see if your window has focus or contains the pointer — > i.e. it's the one that the user is interacting with at this very > moment. That usually implies that the window is at the top of the > stack maintained by the window manager. You could also check if the > "always-on-top" bit is set, but obviously that does not guarantee that > the user is interacting with the window. > > Any other information about the window stack is maintained by the > window manager itself, and you'll have to ask that component, using > window manager and platform specific API, if an API is even exposed. > > > > > GdkEventVisibility has been deprecated since version 3.12 and should not > > be used in newly-written code. > > > > Modern composited windowing systems with pervasive transparency make it > > impossible to track the visibility of a window reliably, so this event > > can not be guaranteed to provide useful information. > > - > > but is there an alternative for my (simpler) question? > > There is, sadly, nothing "simple" about your question. It truly > depends on the platform, and on top of that, it depends on how your > windows are managed. > > For instance, in a tiled window management policy, windows are not > stacked — hence, there is no conventional "on top". Compositing window > managers on X11, such as Mutter or Compiz, may re-arrange the windows > as displayed to the user, even if the user cannot interact with them > outside of the existing stacking order; again, "on top" is not > something that can be conveyed to an API, when your windows are in > "exposé" or laid out on the faces of a 3D solid. Finally, on Wayland, > each surface has no knowledge of anything outside its own coordinate > space; there is no way to access the windows stacking, and for all > intent and purposes, your window manager may put the application's > window on Mars. > > The only reliable way thing you can know is if the user is currently > interacting with a window you're presenting, via pointer, touch, or > keyboard events; either because the pointer or a finger entered the > window, or because the window has key focus. GTK+ provides you with > events to let you know when any of those things happens. Thank you for your clear and comprehensive explanation. I think I will need to provide an option to move all the windows inside a single application window, or two if there are two screens. Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Which toplevel window is on top?
I would like to know which of the top-level windows in my application is on top. Is there a way of doing this? I see that GdkEventVisibility has been deprecated since version 3.12 and should not be used in newly-written code. Modern composited windowing systems with pervasive transparency make it impossible to track the visibility of a window reliably, so this event can not be guaranteed to provide useful information. - but is there an alternative for my (simpler) question? Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [Denemo-devel] Tooltips - what am I doing wrong?
On Sat, 2015-11-28 at 12:00 +, gtk-app-devel-list-requ...@gnome.org wrote: > Date: Fri, 27 Nov 2015 20:42:25 +0100 (CET) > From: Lucas Levrel > To: gtk-app-devel-list@gnome.org > Subject: Re: [Denemo-devel] Tooltips - what am I doing wrong? > Message-ID: > Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed > > Le 27 novembre 2015, John Coppens a ?crit : > > I think those 'tear-offs' are not the same ones as referred to here. > > The 'main menu bar' of GIMP doesn't have tear-offs anymore. I > believe > > the ones you are showing are from right-clicking on the canvas. > > Right. > > > I also suspect that the complexities arise from detaching menus from > > the main menu bar, not from the right-click, which is already a > > pop-up > > Thanks for clarifying. This said, I don't see much difference between > e.g. > the sub-menus of a menu and those of the right-click pop-up. Never > mind. And, indeed, it is particularly in the sub-sub-sub menus where it is very handy to tear-off a menu to be used for a few minutes. I notice that gimp has no tooltips on its menu items - perhaps they were forced to abandon them when the Gtk developers decided to make them pop up uncontrollably fast as you move down a menu... I've worked around this "feature" in Denemo now by allowing people to press the f1 key while hovering on a menu item to bring up the (otherwise disabled) tooltip. Richard > > ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [Denemo-devel] Tooltips - what am I doing wrong?
On Thu, 2015-11-19 at 13:33 +, Richard Shann wrote: > On Thu, 2015-11-19 at 12:01 +, Emmanuele Bassi wrote: > > Hi; > > > > On 19 November 2015 at 09:53, Richard Shann wrote: > > > On Wed, 2015-11-18 at 23:41 +0100, Johan Vromans wrote: > > >> On Wed, 18 Nov 2015 18:49:52 + > > >> Richard Shann wrote: > > >> > > >> > I've pushed a fix that turns off tooltips on menus while leaving them > > >> > on > > >> > everything else (for GTK version >=3.10). > > >> > Can you test if this makes a usable interface? > > >> > > >> It doesn't, and I fail to see why it should... > > >> (I backported the fix to 2.0.0 but I do not think that matters.) > > >> > > >> Not setting a tooltip on the individual menus > > > > > > it is the menu *items* that have the tooltip disabled. I was imagining > > > the problem came when moving the cursor down the menus, that is the > > > browse mode. Experimenting yesterday I saw that if you don't have a > > > tooltip on an widget then the enclosing widget's tooltip fires, so I can > > > imagine there is no escape if tooltip timing is now ordained from above. > > > > > > I have just looked at gimp 2.8.2 and it has the tooltips popping up > > > uncontrollably as you move down menus, the only saving grace is that > > > there aren't quite so many menu items one after the other with tooltips > > > as Denemo has. > > > > If this is happening on Gimp 2.8.2, it means that the issue has > > nothing to do with GTK 3.x, since Gimp 2.8.2 is still very much using > > GTK 2.x > > Actually, what I think it indicates is that the Gtk team have for a long > time had a sense of good default values for tooltip timeout and tooltip > browse timeout which don't suit the more complex programs such as gimp. > (I'm guessing here that gimp is using the default values); indeed as I > move down the menus in gimp unless they are broken up by non-tooltip > items the tooltips once started are difficult to shake off. > > I strongly suspect that is why I looked up the API and gave the user > control in Denemo. All that has happened in Gtk 3.10 is that the user no > longer gets control. Looking at other applications that my (old - > Wheezy) Debian distro provides I see that most do not have tooltips, > Evince in particular is at version 3.4.0 and has no tooltips and > Evolution 3.4.4 has none either. Well, Evolution has none on the menu items, it *does* have them on tool buttons. I notice that the calculator gcalc has them on the buttons but not on menu items as well, and again they are quite difficult to shake off once it has got into browse mode. I suspect most people would find that ideally they would want them to start after a longer delay as well; but programs like this don't get much critical attention, people aren't working with them for hours on end. Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [Denemo-devel] Tooltips - what am I doing wrong?
On Thu, 2015-11-19 at 12:01 +, Emmanuele Bassi wrote: > Hi; > > On 19 November 2015 at 09:53, Richard Shann wrote: > > On Wed, 2015-11-18 at 23:41 +0100, Johan Vromans wrote: > >> On Wed, 18 Nov 2015 18:49:52 + > >> Richard Shann wrote: > >> > >> > I've pushed a fix that turns off tooltips on menus while leaving them on > >> > everything else (for GTK version >=3.10). > >> > Can you test if this makes a usable interface? > >> > >> It doesn't, and I fail to see why it should... > >> (I backported the fix to 2.0.0 but I do not think that matters.) > >> > >> Not setting a tooltip on the individual menus > > > > it is the menu *items* that have the tooltip disabled. I was imagining > > the problem came when moving the cursor down the menus, that is the > > browse mode. Experimenting yesterday I saw that if you don't have a > > tooltip on an widget then the enclosing widget's tooltip fires, so I can > > imagine there is no escape if tooltip timing is now ordained from above. > > > > I have just looked at gimp 2.8.2 and it has the tooltips popping up > > uncontrollably as you move down menus, the only saving grace is that > > there aren't quite so many menu items one after the other with tooltips > > as Denemo has. > > If this is happening on Gimp 2.8.2, it means that the issue has > nothing to do with GTK 3.x, since Gimp 2.8.2 is still very much using > GTK 2.x Actually, what I think it indicates is that the Gtk team have for a long time had a sense of good default values for tooltip timeout and tooltip browse timeout which don't suit the more complex programs such as gimp. (I'm guessing here that gimp is using the default values); indeed as I move down the menus in gimp unless they are broken up by non-tooltip items the tooltips once started are difficult to shake off. I strongly suspect that is why I looked up the API and gave the user control in Denemo. All that has happened in Gtk 3.10 is that the user no longer gets control. Looking at other applications that my (old - Wheezy) Debian distro provides I see that most do not have tooltips, Evince in particular is at version 3.4.0 and has no tooltips and Evolution 3.4.4 has none either. > — unless, obviously, the change predates the branching of GTK > 2.x and 3.x, in which case punting to GTK 3.10 won't do you any good. > > It may be a case of a backported patch; since it's easier to bisect on > the gtk-2-24 branch, would you be able to do so, and identify the > commit in GTK that introduced this behaviour? > > > Emmanuele was only able to help because I copied the email to the > > gtk-app-devel-list, I'll cc this one there too, in case this might be > > taken seriously as a bug in Gtk which they might be glad to get feedback > > on. The version of gimp that I have does seem to be adversely impacted. > > Feel free to open a bug on Bugzilla: > > https://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B Thanks for the link, it is often difficult to track down the place to raise an issue. Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [Denemo-devel] Tooltips - what am I doing wrong?
On Wed, 2015-11-18 at 23:41 +0100, Johan Vromans wrote: > On Wed, 18 Nov 2015 18:49:52 + > Richard Shann wrote: > > > I've pushed a fix that turns off tooltips on menus while leaving them on > > everything else (for GTK version >=3.10). > > Can you test if this makes a usable interface? > > It doesn't, and I fail to see why it should... > (I backported the fix to 2.0.0 but I do not think that matters.) > > Not setting a tooltip on the individual menus it is the menu *items* that have the tooltip disabled. I was imagining the problem came when moving the cursor down the menus, that is the browse mode. Experimenting yesterday I saw that if you don't have a tooltip on an widget then the enclosing widget's tooltip fires, so I can imagine there is no escape if tooltip timing is now ordained from above. I have just looked at gimp 2.8.2 and it has the tooltips popping up uncontrollably as you move down menus, the only saving grace is that there aren't quite so many menu items one after the other with tooltips as Denemo has. > makes little sense if there's > still a tooltip on the menu bar itself. > > Moreover, everything else, all buttons, all areas on the window, still have > tooltips, so there's really no difference with the unfixed version. > > I'm afraid disabling all tooltips for Gtk >= 3.10 is the only option. I've put a fix like that in git now. > > Maybe our Gnome3 friend on the list has a suggestion what mechanism should > be used instead of tooltips? Emmanuele was only able to help because I copied the email to the gtk-app-devel-list, I'll cc this one there too, in case this might be taken seriously as a bug in Gtk which they might be glad to get feedback on. The version of gimp that I have does seem to be adversely impacted. Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [Denemo-devel] Tooltips - what am I doing wrong?
On Wed, 2015-11-18 at 17:15 +, Emmanuele Bassi wrote: > Hi; > > On 18 November 2015 at 16:55, Richard Shann wrote: > > >> > But in the longer term we are coming up to a crunch - the people > >> > developing Gtk are clearly only interested in a narrow group of users. > >> > >> Defining "narrow" as "the group that I'm not in" is not conducive to > >> an honest discussion. > > > > which is why I didn't do anything so idiotic as to define narrow as "not > > my group". But you could very reasonably argue that "wide" equates to > > large numbers of users and narrow to a few. Whereas, what I had in mind > > is wide equating to diverse and complex uses and narrow just to the > > popular simple uses. You can send an email and switch to a calendar and > > lookup a web page with a simple interface comprising a few gestures, but > > you can't do complex technical tasks efficiently that way. > > You still haven't demonstrated that "changing tooltip delay", a complex task can be helped by having tooltips on every thing the user might click on, it turns out that having such a density of tooltips results (I am told at the start of this thread) with popup tooltips happening continuously and, since 3.10 uncontrollably. > having > frame widgets draw a box, a complex task can be helped by dividing the feedback to the user up with frames round the different bits. > or dropping tear-off menus, a complex task can be organized into a hierarchy of menus, which when you arrive at the right one it is convenient to tear off and use as a palette. Denemo now has palettes and a right click on the menu item allows the user to place the menu item as a button in a palette... > equates to > "performing complex tasks" > — unless, obviously, you consider the > current Denemo UI the only way to perform complex tasks, > in which case > I strongly encourage you to look at the wider world of user > interaction and design, including in the proprietary world. No, I don't consider it the only way of doing the job, but re-designing the program is not appealing to me personally, since "it ain't broke" and my interest is mainly in what the program achieves and how easily and musically it achieves it, not whether it works in a similar way to the email program I use. Having said that, Denemo's user interface is evolving - the palettes feature mentioned above will mitigate the lack of tear-off menus. I don't relish reworking the tooltip system, though again, for menu items at least, that is mitigated by the help available by right clicking the item rather than waiting for the tooltip. But really, this last one just seems like a bug - Denemo is not unusual except by using tooltips as much as possible. So if people are finding Gtk>3.10 makes Denemo unusable it would seem to merit a bug report. Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [Denemo-devel] Tooltips - what am I doing wrong?
On Wed, 2015-11-18 at 12:27 +, Emmanuele Bassi wrote: > Hi; > > On 18 November 2015 at 11:16, Richard Shann wrote: > > > I've tracked this down, in the latest manual for gtk3: > > https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-tooltip-browse-timeout > > GtkSettings:gtk-tooltip-browse-timeout has been deprecated since version > > 3.10 and should not be used in newly-written code. > > This setting is ignored. > > > > So, it is a "feature". It appears to be the case that even the regular > > time before a tooltip appears can no longer be controlled, which many > > people will find intolerable (I know of people who set very long times > > on the tooltips, basically because it takes them long enough to read the > > labels on menu items, so that having tooltips pop up while they are > > looking for something is annoying - they would take a long time to read > > a tooltip anyway). > > I think we'll have to disable tooltips for GTK version 3.10 and above. > > Fortunately the tooltip information is still available for commands, > > it's just all the help for playback controls etc etc that will get lost. > > I honestly don't understand why would application developers expose a > tweak to ensure their applications don't behave like any other > application on the system. > > If the people that are not interested in tooltips, and thus change the > timeout to ensure that they are not subject to them, then you can > simply offer a way to disable all tooltips on your controls without > any loss of functionality — after all, these people are not interested > in tooltips in the first place. > > If this is an accessibility issue, like you seem to present it, then > we definitely need a session-wide toggle that changes the delay for a > tooltip to be raised for all applications, not just one. That would be > a great thing to introduce in the session, and I'd be happy to review > a patch to that effect. > > > But in the longer term we are coming up to a crunch - the people > > developing Gtk are clearly only interested in a narrow group of users. > > Defining "narrow" as "the group that I'm not in" is not conducive to > an honest discussion. which is why I didn't do anything so idiotic as to define narrow as "not my group". But you could very reasonably argue that "wide" equates to large numbers of users and narrow to a few. Whereas, what I had in mind is wide equating to diverse and complex uses and narrow just to the popular simple uses. You can send an email and switch to a calendar and lookup a web page with a simple interface comprising a few gestures, but you can't do complex technical tasks efficiently that way. > You already reached your conclusion, and I'm > honestly not interested in convincing you, at that point. > > Personally, I think the amount of users GTK is interested in covers > much, much more than the people tweaking their applications to change > the timeout of the tooltip on a per application basis — but I'm > *personally* interested in getting application developers to stop > considering GTK as a black box, where you just consume an API. > > I've recently run some numbers on the GTK repository[0][1], and it's > clear that while the contributors change over the years, the number of > contributors is mostly stable; this means that new features come at > the expense of deprecations — otherwise there are simply not enough > resources to grow the toolkit while maintaining the old API > indefinitely. > > For better or worse, the world of computing is changing. I think this is the crux of the matter. The "world of computing" has been joined (swamped?) by millions of new users with new devices that can't be used for complex tasks (which those millions would not think of attempting anyway). And the GTK project is adapting to this "big league". So, I think you may have answered my question "Where do we go?": we will have to revert to Gtk2 sooner or later. I guess the problem is that if we continue to offer a Gtk3 version the GNU/Linux distributions will want to build against ever-newer versions of Gtk3 with resultant problems like the one that started this thread. Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [Denemo-devel] Tooltips - what am I doing wrong?
On Wed, 2015-11-18 at 10:35 +0100, Johan Vromans wrote: > On Wed, 18 Nov 2015 07:59:38 + > Richard Shann wrote: > > > One of the time settings available in the preferences sets the browse > > timeout, choosing a value for this (and, possibly, re-starting the > > program) causes a call the gtk to set that value. > > From what you say, none of these calls to set the timings were being > > honored in Gtk 3.10? > > From what I can deduce from experimenting with several programs: > > a. There's an initial delay for a tooltip popup that is approx 1 second. I >haven't found a (system/global) setting that can change the delay time. > > b. If two sensitive areas are more or less adjacent, and one is showing the >tooltip popup, moving to the other area immedeately shows its popup. Only >when the mouse gets some time in between the areas, approx 0.5 seconds, >the popup delay timer is restarted. > > This behaviour seems consistent between all Gtk-based applications I have > tried, both Gtk 2 and Gtk 3 based. > > Apparently, before Gtk 3.10, it was possible to control the popup delay > time, and, also apparently, that disabled (circumvents) the behaviour > described at b. above. > > But this was changed in Gtk 3.10. Now all applications behave consistent > according to a. and b. above. Since Denemo is heavily equipped with > tooltips-sensitive areas, moving the mouse will almost always cause popping > up tooltips all of the time. > > > Are you able to use a bug-fixed version of Gtk? > > Are you saying this has been ackowledged as a bug, and a bug fix exists? > I have no problems building my own Gtk libraries, as long as an officially > fixed version is in the works. I've tracked this down, in the latest manual for gtk3: https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-tooltip-browse-timeout GtkSettings:gtk-tooltip-browse-timeout has been deprecated since version 3.10 and should not be used in newly-written code. This setting is ignored. So, it is a "feature". It appears to be the case that even the regular time before a tooltip appears can no longer be controlled, which many people will find intolerable (I know of people who set very long times on the tooltips, basically because it takes them long enough to read the labels on menu items, so that having tooltips pop up while they are looking for something is annoying - they would take a long time to read a tooltip anyway). I think we'll have to disable tooltips for GTK version 3.10 and above. Fortunately the tooltip information is still available for commands, it's just all the help for playback controls etc etc that will get lost. But in the longer term we are coming up to a crunch - the people developing Gtk are clearly only interested in a narrow group of users. They decide that menus should not be torn off, and that is that, despite the fact that Denemo users do tear off menus if they are going to be using them for a while. They decide that GtkFrames should not have a frame drawn, and so on. Any suggestions as to where we might go? Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkFrame has no frame border drawn?
On Mon, 2015-08-10 at 15:05 +0100, Emmanuele Bassi wrote: > Hi; > > On 10 August 2015 at 14:51, Richard Shann wrote: > > > Having invested effort in this it is exasperating to discover that GTK+ > > chooses a default theme that cripples one of the widgets - by failing to > > draw a frame around the contents the user can no longer see clearly what > > is being grouped by the frame. > > "Crippling" is a strong word, and one that I don't think applies. I'm sorry if the word "cripples" seemed strong to you, I intended it in a purely technical sense of "removes a major part of the functionality". Since the widget in question only has one non-optional feature: "The frame widget is a Bin that surrounds its child with a decorative frame and an optional label", it is clearly the major part of the functionality. I can't think of another English word for this meaning (vitiated? emasculated? these are not so common/have bad connotations). > > Grouping can be achieved by white space, for instance. Or by changing > the background color. Or by changing the typographical appearance. Thank you for these excellent suggestions. I tried gtk_widget_override_background_color (frame, GTK_STATE_FLAG_NORMAL, &color); but could not see the effect (even adding padding or applying it to the child GtkBox of the frame). I did however get colored labels by using gtk_widget_override_color(), but then I read that these calls are deprecated and that a lot more code would be required to do this involving setting up styles. > > Just because you expect a border, Well, I didn't expect a border until I read the documentation: "The frame widget is a Bin that surrounds its child with a decorative frame and an optional label." then I expected a decorative frame surrounding the widget. I guess that a theme could make all widgets invisible if it chose to set the foreground color equal to the background color, but I don't expect theme designers to do that or anything else that essentially negates the documented behavior. > it does not mean your expectations > are correct or are the only possible outcome. > > For instance, using a border around a GtkFrame has been deprecated in > the GNOME HIG since the 2.x era, almost a decade ago: > https://developer.gnome.org/hig-book/2.32/hig-book.html#controls-frames > > The human interface guidelines for MacOS also group controls without a > border: > https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/ControlsView.html#//apple_ref/doc/uid/2957-CH52-SW8 > > In general, you want to use your GtkFrame with GTK_SHADOW_NONE, then that should be the default and the Description should read "The frame widget is a Bin that surrounds its child with a, (by default invisible), decorative frame and an optional label." > and > use spacing. The documentation of GtkShadowType also specifies that > themes may very well not have different types of shadows, and you > should not rely on them: > https://developer.gnome.org/gtk3/stable/gtk3-Standard-Enumerations.html#GtkShadowType a developer will only look up the documentation on the shadow type if they have some reason not to use the default. So they won't see this caveat, which after all would surely apply to most things - a theme could be created to cripple almost any widget I would guess. What would be nice would be to give GtkFrame the features suggested in the GNOME HIG document you cited: gtk_frame_new_with_markup () gtk_frame_set_indent () where the indent would behave nicely under re-sizing. Then the default of GTK_SHADOW_NONE would make sense (else GtkFrame is almost a synonym for GtkBin). Well, I hope that is a constructive suggestion, best wishes Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkFrame has no frame border drawn?
On Mon, 2015-08-10 at 09:05 +0100, Emmanuele Bassi wrote: > Hi; > > the theme is responsible for drawing the frame. The old Windows theme > engine shows a frame; the default GTK+ theme (Adwaita) does not. Thank you for explaining the problem. As a developer of a free software program using GTK+ I consult the documentation to choose suitable widgets to communicate with the users of my program. Having invested effort in this it is exasperating to discover that GTK+ chooses a default theme that cripples one of the widgets - by failing to draw a frame around the contents the user can no longer see clearly what is being grouped by the frame. >From Chris Vine's reply (thank you too, Chris) I gather that this is a bug which has been rectified in more recent versions of the default theme - I am currently summoning up my courage to upgrade to Debian Jessie, and most people I guess will have even more recent versions. So I can treat this as a closed issue. Thank you for help Richard Shann > > Ciao, > Emmanuele. > > > On 9 August 2015 at 17:07, Richard Shann wrote: > > I've recently noticed that the GtkFrames in my application have lost the > > line drawn around the frame - the text is present but not the line. > > I see that in the documentation > > > > file:///usr/share/doc/libgtk-3-doc/gtk3/ch03.html > > > > the widget is illustrated without any line too. I am building and > > running against GTK version 3.4.2 on 64-bit Debian Wheezy. > > > > The same application built for Windows using GTK 3.6.5 *does* show a > > line around frames, albeit rather indistinct... > > > > Is this a known bug? > > > > Richard Shann > > > > > > ___ > > gtk-app-devel-list mailing list > > gtk-app-devel-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > > > ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkFrame has no frame border drawn?
I've recently noticed that the GtkFrames in my application have lost the line drawn around the frame - the text is present but not the line. I see that in the documentation file:///usr/share/doc/libgtk-3-doc/gtk3/ch03.html the widget is illustrated without any line too. I am building and running against GTK version 3.4.2 on 64-bit Debian Wheezy. The same application built for Windows using GTK 3.6.5 *does* show a line around frames, albeit rather indistinct... Is this a known bug? Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A simple choice dialog won't work...
On Thu, 2015-05-07 at 16:21 +0200, Stefan Salewski wrote: > On Thu, 2015-05-07 at 13:02 +0100, Richard Shann wrote: > > From https://developer.gnome.org/gtk3/stable/GtkDialog.html > > GTK_RESPONSE_REJECT Generic response id, not used by GTK+ dialogs > GTK_RESPONSE_ACCEPT Generic response id, not used by GTK+ dialogs > > Maybe try > > GTK_RESPONSE_OK and GTK_RESPONSE_CANCEL Hmm, I wonder what that means - "Generic response id" ... I understood that the idea of the pairs in the trailing arguments of gtk_dialog_new_with_buttons () was that the button with the given text would return the paired response id. I tried the ones you suggested, and also two positive values with the same result. After experimenting with a different bit of code, I think I've found the cause of the problem: doing the widget destroy by responding to the "response" signal seems to be ruining the return value. So, I seem to be back on track - the code that works is below. Thank you for your prompt response! Richard gboolean choose_option (gchar *title, gchar * primary, gchar * secondary) { GtkWidget *dialog; gboolean r; dialog = gtk_dialog_new_with_buttons (title, GTK_WINDOW (Denemo.window), (GtkDialogFlags) (GTK_DIALOG_MODAL | GTK_DIALOG_DESTROY_WITH_PARENT), primary, GTK_RESPONSE_ACCEPT, secondary, GTK_RESPONSE_REJECT, NULL); //g_signal_connect_swapped (dialog, "response", G_CALLBACK (gtk_widget_destroy), dialog); r = (gtk_dialog_run (GTK_DIALOG (dialog)) == GTK_RESPONSE_ACCEPT); gtk_widget_destroy (dialog); return r; } ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
A simple choice dialog won't work...
I wanted to pop up two buttons for the user to choose between two options ("primary" and "secondary"), returning true or false depending which was chosen. I tried this gboolean choose_option (gchar *title, gchar * primary, gchar * secondary) { GtkWidget *dialog; dialog = gtk_dialog_new_with_buttons (title, GTK_WINDOW (Denemo.window), (GtkDialogFlags) (GTK_DIALOG_MODAL | GTK_DIALOG_DESTROY_WITH_PARENT), primary, GTK_RESPONSE_ACCEPT, secondary,GTK_RESPONSE_REJECT, NULL); g_signal_connect_swapped (dialog, "response", G_CALLBACK (gtk_widget_destroy), dialog); return (gtk_dialog_run (GTK_DIALOG (dialog)) == GTK_RESPONSE_ACCEPT); } but it seems to return 0 for both button presses. What am I doing wrong? I'm using GTK3 on a Debian stable installation. Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkTextView background color when not focused
Hi, When a GtkTextView widget does not have the keyboard focus I would like it to be grayed out, so that the user knows his keystrokes are going elsewhere. GdkRGBA color = {0.5, 0.5, 0.5, 1.0}; gtk_widget_override_background_color (staff->currentverse->data, GTK_STATE_FOCUSED, &color); and the like are not doing it, because presumably these would affect the border of the text. I would prefer not to have to insert and remove tags from the text on the focus signal - is there any way to achieve this otherwise? Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Help replacing GtkDrawingArea with GtkLayout
On Tue, 2014-03-11 at 21:43 +0100, Joël Krähemann wrote: [...] > > Please consider the documentation of gtk_widget_set_app_paintable() > > don't believe GtkLayout can do your job. You could try id with a > > GtkDrawingArea with a cairo surface. I do some drawing in C take a look > > at http://sourceforge.net/p/ags/code/HEAD/tree/src/ags/X/ags_editor.c > > > > regards Joël > > > > > > > > ___ > > gtk-app-devel-list mailing list > > gtk-app-devel-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > > > Finally got it you can't read GdkWindow before you didn't show the assigned > widget. I am unsure what you mean by "read GdkWindow", as you can see from the console output when running the minimal example the GdkWindow attached to the GtkLayout does exist and does get its flags set. Those g_print() statements are there to confirm that fact. > > #include > > gboolean > configure_event (GtkWidget *widget, > GdkEventConfigure *configure, > gpointer data) > { > fprintf (stderr, "configure-event\n"); > gtk_main_quit (); > return FALSE; > } > int main(int argc, char *argv[]) > { > GtkWidget *window; > GtkWidget *layout; > GtkWidget *label1; > GdkWindow *win; > > gtk_init (&argc, &argv); > > window = gtk_window_new (GTK_WINDOW_TOPLEVEL); > > layout = gtk_layout_new (NULL, NULL); > g_object_set(G_OBJECT(layout), >"app-paintable", TRUE, >NULL); > > gtk_widget_add_events (layout, GDK_ALL_EVENTS_MASK); > gtk_container_add (GTK_CONTAINER (window), layout); > > label1 = gtk_label_new ("label 1"); > > gtk_layout_put (GTK_LAYOUT (layout), label1, 10, 50); > > > gtk_widget_show_all (window); > > win = gtk_layout_get_bin_window (GTK_LAYOUT(layout)); > g_print("win is %p initial mask 0x%x\n", win, gdk_window_get_events > (win)); > gdk_window_set_events (win, gdk_window_get_events (win) | > GDK_STRUCTURE_MASK); > g_print("After adding GDK_STRUCTURE_MASK mask 0x%x\n", > gdk_window_get_events (win)); > > g_signal_connect (layout, "configure-event", > G_CALLBACK (configure_event), NULL); > > gtk_main (); > > return 0; > } > When I compile the version you have given the code behaves as before, the window pops up (because the configure-event signal has not been received, whose callback would cause an exit). Are you saying it does something different for you? Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Help replacing GtkDrawingArea with GtkLayout
On Tue, 2014-03-11 at 13:18 +0100, Joël Krähemann wrote: > On Tue, 2014-03-11 at 08:12 +0000, Richard Shann wrote: > > On Tue, 2014-03-11 at 04:43 +0100, Joël Krähemann wrote: > > > On Mon, 2014-03-10 at 09:52 +0000, Richard Shann wrote: > > > > On Mon, 2014-03-10 at 09:29 +0100, Joël Krähemann wrote: > > > > > On Mon, 2014-03-10 at 09:26 +0100, Joël Krähemann wrote: > > > > > > On Sun, 2014-03-09 at 14:03 +, Richard Shann wrote: > > > > > > > > From: Jo?l Kr?hemann > > > > > > > > To: gtk-app-devel-list@gnome.org > > > > > > > > Subject: Re: Help replacing GtkDrawingArea with GtkLayout > > > > > > > > Message-ID: <1394327737.3369.3.camel@debian> > > > > > > > > Content-Type: text/plain; charset="us-ascii" > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > Didn't before but may be check the following: > > > > > > > > > > > > > > > > g_object_set(G_OBJECT(layout), > > > > > > > > "app-paintable\0", TRUE, > > > > > > > > NULL); > > > > > > > > > > > > > > Hmm, I hadn't noticed that property. It is presumably set ok > > > > > > > since I can > > > > > > > draw and place widgets on the GtkLayout. It was the configure and > > > > > > > scroll > > > > > > > events that I didn't receive. > > > > > > > BTW why do you have two NULL bytes at the end of the property name > > > > > > > (AFAIK only one is needed)? > > > > > > > > > > > > > > Richard > > > > > > > > > > > > > > > > > > > > > > > > > > Assumed you get annoyed by warnings, you can slightly disable it. > > > > > > It's > > > > > > distribution depend what flags are per default on. For further > > > > > > reading: > > > > > > > > > > > > http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html > > > > > > > > > > > > regards > > > > > > Joël > > > > > > > > > > > > > > > > > > ___ > > > > > > gtk-app-devel-list mailing list > > > > > > gtk-app-devel-list@gnome.org > > > > > > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > > > > > > > > > > You should ask why I forget to add GDK_SCROLL_MASK > > > > > > > > Well, I didn't ask because I already tried it. The GtkLayout didn't > > > > receive that nor the configure signal even with setting > > > > GDK_ALL_EVENTS_MASK. What *did* work is receiving the events on the > > > > parent. > > > > But I am still curious why you have two NULL bytes termination your > > > > signal name strings, the extra one must surely get ignored... > > > > > > > > Richard > > > > > > > > > > > > > > > > > > gtk_widget_set_events (GTK_WIDGET (layout), > > > > > GDK_EXPOSURE_MASK > > > > > | GDK_LEAVE_NOTIFY_MASK > > > > > | GDK_BUTTON_PRESS_MASK > > > > > | GDK_BUTTON_RELEASE_MASK > > > > > | GDK_POINTER_MOTION_MASK > > > > > | GDK_POINTER_MOTION_HINT_MASK > > > > > | GDK_SCROLL_MASK > > > > > ); > > > > > > > > > > then you have to > > > > > > > > > > g_signal_connect(G_OBJECT(layout), "scroll-event\0", > > > > > G_CALLBACK(layout_callback), NULL); > > > > > > > > > > > > > > > gboolean > > > > > layout_callback(GtkWidget *widget, GdkEvent *event, gpointer > > > > > user_data) > > > > > { > > > > > /* do your thing */ > > > > > > > > > > return(FALSE); > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > Is your code somewhere online? Are you using > > > gtk_widget_set_size_request()? > > >
Re: Help replacing GtkDrawingArea with GtkLayout
On Mon, 2014-03-10 at 09:29 +0100, Joël Krähemann wrote: > On Mon, 2014-03-10 at 09:26 +0100, Joël Krähemann wrote: > > On Sun, 2014-03-09 at 14:03 +, Richard Shann wrote: > > > > From: Jo?l Kr?hemann > > > > To: gtk-app-devel-list@gnome.org > > > > Subject: Re: Help replacing GtkDrawingArea with GtkLayout > > > > Message-ID: <1394327737.3369.3.camel@debian> > > > > Content-Type: text/plain; charset="us-ascii" > > > > > > > > Hi, > > > > > > > > Didn't before but may be check the following: > > > > > > > > g_object_set(G_OBJECT(layout), > > > > "app-paintable\0", TRUE, > > > > NULL); > > > > > > Hmm, I hadn't noticed that property. It is presumably set ok since I can > > > draw and place widgets on the GtkLayout. It was the configure and scroll > > > events that I didn't receive. > > > BTW why do you have two NULL bytes at the end of the property name > > > (AFAIK only one is needed)? > > > > > > Richard > > > > > > > > > > Assumed you get annoyed by warnings, you can slightly disable it. It's > > distribution depend what flags are per default on. For further reading: > > > > http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html > > > > regards > > Joël > > > > > > ___ > > gtk-app-devel-list mailing list > > gtk-app-devel-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > > You should ask why I forget to add GDK_SCROLL_MASK Well, I didn't ask because I already tried it. The GtkLayout didn't receive that nor the configure signal even with setting GDK_ALL_EVENTS_MASK. What *did* work is receiving the events on the parent. But I am still curious why you have two NULL bytes termination your signal name strings, the extra one must surely get ignored... Richard > > gtk_widget_set_events (GTK_WIDGET (layout), > GDK_EXPOSURE_MASK > | GDK_LEAVE_NOTIFY_MASK > | GDK_BUTTON_PRESS_MASK > | GDK_BUTTON_RELEASE_MASK > | GDK_POINTER_MOTION_MASK > | GDK_POINTER_MOTION_HINT_MASK > | GDK_SCROLL_MASK > ); > > then you have to > > g_signal_connect(G_OBJECT(layout), "scroll-event\0", > G_CALLBACK(layout_callback), NULL); > > > gboolean > layout_callback(GtkWidget *widget, GdkEvent *event, gpointer user_data) > { > /* do your thing */ > > return(FALSE); > } > > > ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Help replacing GtkDrawingArea with GtkLayout
> From: Jo?l Kr?hemann > To: gtk-app-devel-list@gnome.org > Subject: Re: Help replacing GtkDrawingArea with GtkLayout > Message-ID: <1394327737.3369.3.camel@debian> > Content-Type: text/plain; charset="us-ascii" > > Hi, > > Didn't before but may be check the following: > > g_object_set(G_OBJECT(layout), > "app-paintable\0", TRUE, > NULL); Hmm, I hadn't noticed that property. It is presumably set ok since I can draw and place widgets on the GtkLayout. It was the configure and scroll events that I didn't receive. BTW why do you have two NULL bytes at the end of the property name (AFAIK only one is needed)? Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Re:Help replacing GtkDrawingArea with GtkLayout
On Mon, 2014-03-03 at 16:38 +0001, Bernhard Schuster wrote: > On Mon, Mar 3, 2014 at 5:26 PM, Richard Shann > wrote: > > On Mon, 2014-03-03 at 16:49 +0100, Stefan Salewski wrote: > > On Mon, 2014-03-03 at 15:17 +0000, Richard Shann wrote: > I > > have constructed the following minimal example, Yes indeed, > > > > https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-set-events > > >This function must be called while a widget is unrealized. > > Thank you for giving this some thought. I think it is not the case > > however that the gtk_widget_show_all() call causes the "widget to be > > realized" in gtk-speak, it just sets a flag on the widget to say it > > should be visible (I am guessing). I think I have just made a > > breakthrough with my problem however - setting the configure-event > > signal handler on the parent GtkWindow widget instead of the > > GtkLayout window it contains causes it to fire off. I have tried > > this with the scroll-event too and that works. Why this should be > > different from the case where I use a GtkDrawingArea I have no idea, > > but it looks like I am cooking with gas! > > Either - I strongly recommend to stick to > > > gdk_window_add_events (win, GDK_STRUCTURE_MASK); > > > which does not have any dependency on widget/window realization. (I > found myself in that very same pit some time ago). The docs indicate that this may be set anyway: "The ::configure-event signal will be emitted when the size, position or stacking of the widget's window has changed. To receive this signal, the GdkWindow associated to the widget needs to enable the GDK_STRUCTURE_MASK mask. GDK will enable this mask automatically for all new windows." Once I moved the signal handler attachment upwards in the widget hierarchy it sprang into life without any explicit setting of the GdkWindow mask. Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Re:Help replacing GtkDrawingArea with GtkLayout
On Mon, 2014-03-03 at 16:49 +0100, Stefan Salewski wrote: > On Mon, 2014-03-03 at 15:17 +0000, Richard Shann wrote: > > I have constructed the following minimal example, > > Yes indeed, > > https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-set-events > > >This function must be called while a widget is unrealized. Thank you for giving this some thought. I think it is not the case however that the gtk_widget_show_all() call causes the "widget to be realized" in gtk-speak, it just sets a flag on the widget to say it should be visible (I am guessing). I think I have just made a breakthrough with my problem however - setting the configure-event signal handler on the parent GtkWindow widget instead of the GtkLayout window it contains causes it to fire off. I have tried this with the scroll-event too and that works. Why this should be different from the case where I use a GtkDrawingArea I have no idea, but it looks like I am cooking with gas! Thank you once more Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re:Help replacing GtkDrawingArea with GtkLayout
I have constructed the following minimal example, it creates a GtkLayout with one label inside it, sets the GDK_STRUCTURE_MASK on the GdkWindow of the GtkLayout and connects the configure-event signal to a routine that would just exit the main loop. Instead of exiting, the window is created without the configure-event signal firing. The GdkWindow and its mask are printed out and appear to be set as per the documentation. Please can someone explain what is wrong! #include static gboolean configure_event () { fprintf (stderr, "configure-event\n"); gtk_main_quit (); return FALSE; } int main(int argc, char *argv[]) { GtkWidget *window; GtkWidget *layout; GtkWidget *label1; gtk_init (&argc, &argv); window = gtk_window_new (GTK_WINDOW_TOPLEVEL); layout = gtk_layout_new (NULL, NULL); gtk_container_add (GTK_CONTAINER (window), layout); label1 = gtk_label_new ("label 1"); gtk_layout_put (GTK_LAYOUT (layout), label1, 10, 50); gtk_widget_show_all (window); GdkWindow *win = gtk_widget_get_window(layout); g_print("win is %p initial mask 0x%x\n", win, gdk_window_get_events (win)); gdk_window_set_events (win, gdk_window_get_events (win) | GDK_STRUCTURE_MASK); g_print("After adding GDK_STRUCTURE_MASK mask 0x%x\n", gdk_window_get_events (win)); gtk_widget_add_events (layout, GDK_ALL_EVENTS_MASK); g_signal_connect (layout, "configure-event", G_CALLBACK (configure_event), NULL); gtk_main (); return 0; } Richard Shann > From: Richard Shann > To: gtk-app-devel-list@gnome.org > Subject: Help replacing GtkDrawingArea with GtkLayout > Message-ID: <1393771664.4221.117.ca...@debianbox.loc> > Content-Type: text/plain; charset="UTF-8" > > I want to replace the existing GtkDrawingArea with a GtkLayout in a > large application (GNU Denemo). > When I do this just by substituting gtk_drawing_area_new() with > gtk_layout_new(NULL, NULL) I do not receive the configure_event and > scroll_event signals, although the code gtk_widget_add_events .. > GDK_EXPOSURE_MASK is still in place. > > I suspect this is to do with the cryptic note that drawing has to be > done to the bin_window instead of window, but beyond that I am stumped. > The draw event is being handled fine, and mouse button clicks etc are > all working. > > Any help in migrating from GtkDrawingArea to GtkLayout would be much > appreciated. > > Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Help replacing GtkDrawingArea with GtkLayout
I want to replace the existing GtkDrawingArea with a GtkLayout in a large application (GNU Denemo). When I do this just by substituting gtk_drawing_area_new() with gtk_layout_new(NULL, NULL) I do not receive the configure_event and scroll_event signals, although the code gtk_widget_add_events .. GDK_EXPOSURE_MASK is still in place. I suspect this is to do with the cryptic note that drawing has to be done to the bin_window instead of window, but beyond that I am stumped. The draw event is being handled fine, and mouse button clicks etc are all working. Any help in migrating from GtkDrawingArea to GtkLayout would be much appreciated. Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gdk-pixbuf-query-loaders on Windows does nothing.
Some years ago I was building GNU Denemo on windows and had some help with running gdk-pixbuf-query-loaders. For some years now we have been building the program by cross-compiling on GNU/Linux systems. I don't think we have ever sorted out how to run the gdk-pixbuf-query-loaders automatically on installation, however. As a first step, I have tried to run gdk-pixbuf-query-loaders.exe manually (with elevated permissions). The program executes but does not seem to perform any I/O. It is built without debug symbols unfortunately, but running it under gdb it will break at fopen a couple of times, but otherwise there is no sign of it doing anything. Does anyone have any idea what might be wrong? (I should add that the program runs fine - apart from not loading .svg files for which a loader is present - making extensive use of gtk) Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Location for gspawn_win32_helper.exe in a static build.
> Location for gspawn_win32_helper.exe in a static build. It turns out there are two helper programs, and it was calling the other one gspawn_win32_helper-console.exe which was not installed. Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Location for gspawn_win32_helper.exe in a static build.
Hi, at GNU/Denemo we are currently trying to use mxe to build statically for windows. The gspawn_win32_helper.exe is built but installing it in the path does not seem to work, giving the same error message as when it wasn't available as a static binary: Failed to execute helper program (Invalid argument) Anyone know where it should be/if there are environment variables that can be set to help glib here? As it is we cannot spawn processes. Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Re: DLL Hell on Windows..
On Sun, 2012-08-05 at 12:00 +, gtk-app-devel-list-requ...@gnome.org wrote: > Send gtk-app-devel-list mailing list submissions to > gtk-app-devel-list@gnome.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > or, via email, send a message with subject or body 'help' to > gtk-app-devel-list-requ...@gnome.org > > You can reach the person managing the list at > gtk-app-devel-list-ow...@gnome.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of gtk-app-devel-list digest..." > > > Today's Topics: > >1. Re: DLL Hell on Windows.. (Robin Vossen) > > > -- > > Message: 1 > Date: Sat, 4 Aug 2012 15:07:13 +0200 > From: Robin Vossen > To: gtk-app-devel-list@gnome.org > Subject: Re: DLL Hell on Windows.. > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Hello, > > I have figured out I require 2.4.0 of libatk (by reading headers). > Who can give me libatk 2.4.0 prebuild for Windows (x86)? I don't know if it would help, but the package http://www.denemo.org/downloads/denemo-0.9.5rc5.exe installs the gtk dlls including that one, not sure which version. So you could lift them out of there I guess. I have wondered why we use dlls on windows, we should link statically to the libraries. Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Cursor not visible in GtkTextView
I have a GtkTextView widget which refuses to display the cursor. All the other editing commands seem fine (marking text, switching to overwrite mode and back) but despite calls to gtk_text_view_get_cursor_visible() reporting TRUE, no cursor is visible. This text view widget is packed in a scrolled window in a GtkVbox in a GtkFrame in a GtkNotebook in a GtkWindow. If, instead I put it directly in a top level window the cursor shows. The Gtk version 2.20.1, does anyone have any insights into this problem? Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Signals that do not get emitted
I have the solution, and it is potentially of general interest. It seems that the GtkPrintOperation widget is interacting with the (Unix) SIGUSR1 signal, which our program started using a while ago to do the client thing. Dropping the (unix) signal handler for that signal made the (glib) signals on the GtkPrintOperation widget start to work again. I don't know if that is documented anywhere. Richard Shann On Mon, 2011-11-21 at 12:00 +, gtk-app-devel-list-requ...@gnome.org wrote: > Message: 4 > Date: Sun, 20 Nov 2011 16:13:57 +0000 > From: Richard Shann > To: gtk-app-devel-list@gnome.org > Subject: Signals that do not get emitted > Message-ID: <1321805637.2172.21.camel@debian2.myhost> > Content-Type: text/plain; charset="UTF-8" > > At one time we had the GtkPrintOperation widget working, sending > begin_print and draw_page signals; now it no longer works - the > callback > is never reached - and I wonder if anyone has some idea as to why that > should be. > It is not the specific bit of code that creates/launches the widget, > but > something more generic (like disabling a class of signals, if such a > thing is possible). I say this because I only came across it when I > installed a widget from libevince which uses the GtkPrintOperation and > that fails to get the callbacks. > I have built the evince widget as a standalone program (see below) and > it works. But the same piece of code called from within our (large) > program does not. > > This has been seen in Gtk 2.30.2 and also in Gtk-3 (not sure which > version). > > Any ideas how this can happen? (the project is Denemo, www.denemo.org, > and the file concerned is print.c). ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Signals that do not get emitted
At one time we had the GtkPrintOperation widget working, sending begin_print and draw_page signals; now it no longer works - the callback is never reached - and I wonder if anyone has some idea as to why that should be. It is not the specific bit of code that creates/launches the widget, but something more generic (like disabling a class of signals, if such a thing is possible). I say this because I only came across it when I installed a widget from libevince which uses the GtkPrintOperation and that fails to get the callbacks. I have built the evince widget as a standalone program (see below) and it works. But the same piece of code called from within our (large) program does not. This has been seen in Gtk 2.30.2 and also in Gtk-3 (not sure which version). Any ideas how this can happen? (the project is Denemo, www.denemo.org, and the file concerned is print.c). Below is the Evince widget demo code which I wrote to test out. Richard Shann #include #include #include evince_print() { GError *err = NULL; GFile *file; gchar *filename = "test.pdf"; file = g_file_new_for_commandline_arg (filename); gchar *uri = g_file_get_uri (file); g_object_unref (file); EvDocument *doc = ev_document_factory_get_document (uri, &err); if(err) { g_warning ("Trying to read the pdf file %s gave an error: %s", uri, err->message); if(err) g_error_free (err); err = NULL; } else { EvPrintOperation *printop = ev_print_operation_new (doc); ev_print_operation_run (printop, NULL); } } int main(int argc, char **argv) { GtkWidget *main_vbox, *top; gtk_init(&argc, &argv); ev_init(); GtkWidget *printarea; top = gtk_window_new(GTK_WINDOW_TOPLEVEL); gtk_window_set_title(GTK_WINDOW(top), "Evince Print Test"); printarea = gtk_button_new_with_label("click me to print the file test.pdf"); gtk_container_add (GTK_CONTAINER(top), (GtkWidget*)printarea); g_signal_connect (G_OBJECT (printarea), "clicked", G_CALLBACK (evince_print), NULL); gtk_widget_show_all(top); gtk_main(); return 0; } end of source code To build use something like gcc testevince.c -o test -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -pthread -I/usr/include/gtksourceview-2.0 -I/usr/include/libxml2 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/librsvg-2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/evince/2.30 -levview -levdocument (a lot of that could be omitted I'm sure :) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Custom font for application
I sorted this out yesterday (see denemo-devel mailing list), what you need I suspect is along the lines of this: GtkSettings *settings = gtk_settings_get_default( ); gtk_settings_set_string_property(settings, "gtk-font-name" , "FreeSerif 12", "denemo"); // Note: GTK complains that the font does not have a +ve size unless you mention, one as here. gtk_main(); where "FreeSerif 12" indicates the font you want the application to use, and the last string can be anything. you will also need to call something like: #include void add_font_directory(gchar *fontpath) { #ifdef G_OS_WIN32 AddFontResource(fontpath); #else FcConfigAppFontAddDir(NULL, fontpath); #endif } if the font isn't a system one. Creating a font = fontforge, of course. Richard > On Mon, 2011-07-25 at 12:00 +, gtk-app-devel-list-requ...@gnome.org > wrote: > > > > Does anyone here know how I can create and load a custom font for my > > application from the source code? What method or methods do I need to > > invoke to load the font that I can render? What rendering methods do I > > need to override so that my custom fonts are the ones rendered? Are > > there any examples of source code on how to achieve this? > > The GNU/Denemo music typesetter uses a custom font, called denemo.ttf > You can look at its Makefiles for installation hints and src/utils.c for > setting font load paths. It invokes this font by using gtk's markup > language thus: > > /* markup the passed string to be in the denemo music font > * caller must free the returned string > */ > gchar * music_font(gchar *str) { > return g_strdup_printf("%s", > str); > } > > Where Denemo 12 is asking for denemo.ttf in 12pt. > > I have all this at my fingertips because I want to change it so that I > don't have to switch fonts using markup, but instead use just one font > for both regular text and music symbols. > So I too need to know, how do you tell a gtk application to use a > specific font for all the widget labels and other text which it would > normally render in some default or use preferred font? Richard Shann http://www.denemo.org ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Custom font for application
On Mon, 2011-07-25 at 12:00 +, gtk-app-devel-list-requ...@gnome.org wrote: > > Does anyone here know how I can create and load a custom font for my > application from the source code? What method or methods do I need to > invoke to load the font that I can render? What rendering methods do I > need to override so that my custom fonts are the ones rendered? Are > there any examples of source code on how to achieve this? The GNU/Denemo music typesetter uses a custom font, called denemo.ttf You can look at its Makefiles for installation hints and src/utils.c for setting font load paths. It invokes this font by using gtk's markup language thus: /* markup the passed string to be in the denemo music font * caller must free the returned string */ gchar * music_font(gchar *str) { return g_strdup_printf("%s", str); } Where Denemo 12 is asking for denemo.ttf in 12pt. I have all this at my fingertips because I want to change it so that I don't have to switch fonts using markup, but instead use just one font for both regular text and music symbols. So I too need to know, how do you tell a gtk application to use a specific font for all the widget labels and other text which it would normally render in some default or use preferred font? Richard Shann http://www.denemo.org ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Printing a .png using GtkPrint
I am trying to use GtkPrint* to print a .png file, the code I have tried pops up the print dialog but nothing arrives in the printer queue. The draw page signal is being received when I ok the print dialog. The function I am using for the draw-page signal to try and print is this: static void draw_page (GtkPrintOperation *operation, GtkPrintContext *context, gint page_nr, gpointer user_data) { if(page_nr==0){ g_print("printing page 0"); //gtk_print_operation_set_use_full_page() and gtk_print_operation_set_unit() cairo_t * cr = gtk_print_context_get_cairo_context (context); cairo_surface_t *surface = cairo_image_surface_create_from_png ("denemoprint_.png"); cairo_status_t status = cairo_surface_status(surface); if(status != CAIRO_STATUS_SUCCESS) g_print("An error %d\n", status); cairo_set_source_surface (cr, surface, 0, 0); cairo_paint (cr); cairo_surface_destroy (surface); } else gtk_print_operation_cancel (operation); g_print("returning from draw\n"); } Which has been assembled from the gtk docs and the cairo samples at http://www.cairographics.org/samples/ The draw_page function is being called for page_nr 0 and the png load is ok but as I say, nothing more transpires. The bits of code that I have invented here are the calls to cairo_surface_destroy (surface); and gtk_print_operation_cancel (operation); The first of these can be left out, but the second prevents draw_page being called ad infinitum. Anyone have a working example? I am using Debian Lenny standard standard packages. Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Giving GtkFileChooser different backend functions.
Does anyone know if it would be at all easy to intercept the calls the GtkFileChooser widget makes to get files/directories? I am sure it would take me too long to get to grips with the whole subclassing thing to create a special version of the widget, but if I could just sneak in there when it was wanting the list of files/directories I would be a happy bunny. Preferably some hooks in the backend but even at the cost of having to monitor version changes... can it be done in a few lines of code? Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gio library on Debian Lenny
On Sat, 2009-05-16 at 12:00 +, gtk-app-devel-list-requ...@gnome.org wrote: > To: > Cc: gtk-app-devel-list@gnome.org > Message-ID: <20090516022833.415b5...@resin14.mta.everyone.net> > Content-Type: text/plain; charset="UTF-8" > > Have you try GNet? http://www.gnetlibrary.org/ > it has support for http protocol object (GConnHttp) and also based on > GLib. Thanks for this link - I didn't know about this. If possible I will go with gio as it would seem to be under more active development, though if it is not actually yet working that would be little comfort :-) Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gio library on Debian Lenny
On Fri, 2009-05-15 at 19:12 +0300, Paul Pogonyshev wrote: > Richard Shann wrote: > > Does anyone know if the gio library is working for getting files from > > the internet in the latest Debian Lenny distribution, x86? > > You probably need GVFS package. GIO itself doesn't contain any > implementations for remote access, only interfaces and local access, > AFAIK. Thank you for your quick reply. I have installed the gvfs package and the g_file_read() function now does not return, which is progress of a sort! (I realize there is an asynchronous version, but as the page is fetchable, I presume this ought to be returning). gdb says that it is blocked in __kernel_vsyscall () which sounds reasonable; any thoughts on what to try next? (I guess strace might help ...). Or am I missing something obvious? I didn't start any demon associated with the gvfs package... I just let synaptic install it... Thanks again, Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Gio library on Debian Lenny
Does anyone know if the gio library is working for getting files from the internet in the latest Debian Lenny distribution, x86? I have tried the following code: GError *err = NULL; GFile * file=g_file_new_for_uri ("http://www.rshann.plus.com/denemo.html";); GFileInputStream *stream = g_file_read(file, NULL, &err); if (err != NULL) { g_warning ("The opening of uri gave %s", err->message); if(err) g_error_free (err); err = NULL; } But get "Operation not supported message". It works ok with a local file (file:///home/...) should it be working for http? Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_spawn and files left locked on windows.
Thank you for your observations. On Tue, 2009-04-28 at 07:45 -0700, Ardhan Madras wrote: > As far i know in win32, if a process is opening a new file, then normally > another process couldn't write or remove it. yes that's right. > It's maybe a synchronization method offered by win32 by automatically > locking a file descriptor. Linux doesn't automatically provide such a file > locking mechanism to a file opened by a process. > > So if the file left locked, there are must be a process which still open the > file or a file is still left opened. Win32 maybe doesn't automatically > release such as opened file's resources. The process had finished, and that was why I was puzzled. > In your project or demonstration code: I see you don't fclose() your file > before exit I *do* fclose() the file in the program that creates it (i.e. in the program "doit"). It is also guaranteed to be closed by the main of that program returning, that is as part of the exit. The other program is just finding out if the file is locked by trying to open it, so it doesn't matter what it does with it. The test does, in fact work pefectly on both platforms, so my problem lay elsewhere. Richard > (actually i don't know if this have the 'locking effect'), and you may > interest using a GIOChannel for file operations. > > --- ajhwb > > > --- richard.sh...@virgin.net wrote: > > From: Richard Shann > To: gtk-app-devel-list@gnome.org > Subject: Re: g_spawn and files left locked on windows. > Date: Tue, 28 Apr 2009 08:39:12 +0100 > > On Mon, 2009-04-27 at 12:52 +0300, Tor Lillqvist wrote: > > > My application invokes the lilypond program using the g_spawn... > > > functions. This works fine on linux, but on windows the files created by > > > lilypond are left locked when lilypond has exited. > > > > That sounds very odd and in fact impossible. Are you confusing file > > protection with locking? > Thank you for the quick and helpful reply. Having contstructed the > minimal example, everything worked fine. > For those listening in who need to create a glib standalone minimal > example. I append the code I devised. > Richard > / first program, invoked by the one below */ > #include > > /* > program doit > gcc test.c -o doit.exe > */ > int main(void) { > printf("Opening the test file now\n"); > FILE *fp = fopen("thetestfile","w"); > if(fp==NULL) { > printf("doit could not open the test file"); > return -1; > } > printf("Writing to the test file now\n"); > fprintf(fp, "hello"); > fclose(fp); > return 0; > } > > /** second program, invoking the first */ > > /* > program test > gcc test.c -o test.exe -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > /usr/lib/libglib-2.0.so > */ > #include > #include > static GPid pid = -1; > void finished(void) { > g_spawn_close_pid (pid); > FILE *fp = fopen("thetestfile","rw"); > if(fp==NULL) { > g_print("could not open\n"); > exit(-1); > } > g_print("The file opens ok\n"); > exit(0); > } > > int main(void) { > g_print("Starting the test\n"); > gchar *arguments[] = { > "doit.exe", > NULL > }; > g_spawn_async_with_pipes (NULL, /* dir */ > arguments, NULL,/* env */ > G_SPAWN_SEARCH_PATH | G_SPAWN_DO_NOT_REAP_CHILD, NULL, /* > child setup func */ > NULL, /* user data */ > &pid, > NULL, > NULL, /* stdout */ > NULL, /* stderr */ > NULL); > g_child_watch_add (pid, (GChildWatchFunc)finished, NULL); > g_print("looping for ever, Ctrl-C to kill\n"); > GMainLoop* gm = g_main_loop_new(NULL, 0); > g_main_loop_run(gm); > } > > > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > > > > > _ > Listen to KNAC, Hit the Home page and Tune In Live! ---> http://www.knac.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_spawn and files left locked on windows.
On Mon, 2009-04-27 at 12:52 +0300, Tor Lillqvist wrote: > > My application invokes the lilypond program using the g_spawn... > > functions. This works fine on linux, but on windows the files created by > > lilypond are left locked when lilypond has exited. > > That sounds very odd and in fact impossible. Are you confusing file > protection with locking? Thank you for the quick and helpful reply. Having contstructed the minimal example, everything worked fine. For those listening in who need to create a glib standalone minimal example. I append the code I devised. Richard / first program, invoked by the one below */ #include /* program doit gcc test.c -o doit.exe */ int main(void) { printf("Opening the test file now\n"); FILE *fp = fopen("thetestfile","w"); if(fp==NULL) { printf("doit could not open the test file"); return -1; } printf("Writing to the test file now\n"); fprintf(fp, "hello"); fclose(fp); return 0; } /** second program, invoking the first */ /* program test gcc test.c -o test.exe -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include /usr/lib/libglib-2.0.so */ #include #include static GPid pid = -1; void finished(void) { g_spawn_close_pid (pid); FILE *fp = fopen("thetestfile","rw"); if(fp==NULL) { g_print("could not open\n"); exit(-1); } g_print("The file opens ok\n"); exit(0); } int main(void) { g_print("Starting the test\n"); gchar *arguments[] = { "doit.exe", NULL }; g_spawn_async_with_pipes (NULL, /* dir */ arguments, NULL,/* env */ G_SPAWN_SEARCH_PATH | G_SPAWN_DO_NOT_REAP_CHILD, NULL, /* child setup func */ NULL, /* user data */ &pid, NULL, NULL, /* stdout */ NULL, /* stderr */ NULL); g_child_watch_add (pid, (GChildWatchFunc)finished, NULL); g_print("looping for ever, Ctrl-C to kill\n"); GMainLoop* gm = g_main_loop_new(NULL, 0); g_main_loop_run(gm); } ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
g_spawn and files left locked on windows.
My application invokes the lilypond program using the g_spawn... functions. This works fine on linux, but on windows the files created by lilypond are left locked when lilypond has exited. I can't re-use them on the next invocation, for example. Should I be exploring this as a possible bug in lilypond, or could there be something about the way I invoke it? Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GdkBitmap from black & white .png file
On Thu, 2009-02-05 at 16:20 +, gtk-app-devel-list-requ...@gnome.org wrote: > There are functions to convert a PNG with transparency (alpha component) > to a GdkBitmap according to a threshold. See > gdk_pixbuf_render_threshold_alpha() > http://library.gnome.org/devel/gdk/stable/gdk-Pixbufs.html#gdk-pixbuf-render-threshold-alpha > Thank you for this - I have now taken the this approach - adding an alpha channel to a pixbuf created from the .png and then going to xbm format and finally to the GdkBitmap. Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GdkBitmap from black & white .png file
The Gdk functions to create bitmaps from data require xbm or xpm data. (For example gdk_bitmap_create_from_data ()). Why do I not see anything to create a bitmap from a (b&w) .png image? I've used the pixbuf library before, using gdk_draw_pixbuf() but the program I am working on uses a GdkBitmap * mask to draw in the following fashion: gdk_gc_set_clip_mask (gc, mask); gdk_gc_set_clip_origin (gc, x, y); gdk_draw_rectangle (pixmap, gc, TRUE, x, y, width, height); gdk_gc_set_clip_mask (gc, NULL); /* Removes clip mask */ I don't understand the issues here; I want the application to let the user select a (small) rectangular area in the .png image for use in as the GdkBitmap *mask in the above code. Anyone with a wider view on this stuff? Help would be much appreciated! Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Is there a way to invert gtk_ui_manager_get_path()
The function gtk_ui_manager_get_path() gets the xml path to a widget in your menu hierarchy. Is there a way, given a widget to find this path? Note this is not the path gotten from gtk_widget_path() which is the container hierarchy. I want the menu hierarchy (so as to be able to insert menu items there in some future invocation of the program). Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: svg pixbuf loader on Windows
On Sat, 2008-07-05 at 23:38 +0300, Tor Lillqvist wrote: > > Thanks for this. I think I have the stuff and I think I have poked it in > > the right places, but so far no joy. The gdk-pixbuf.loaders file in the > > directory below c:/program files/Denemo seems to be ignored. > > Ah. I forgot to mention that when installing a new gdk-pixbuf loader, > you indeed need to either 1) run the gdk-pixbuf-query-loaders program > and redirect its output to the corresponding gdk-pixbuf.loaders file > (thus refreshing the list of loaders GTK+ knows about), or 2) edit the > gdk-pixbuf.loaders file manually to add an entry for the new loader. > (If there was an installer for the new loader, the installer should > take care of this.) > Success! Thank you. Just to spell it out (for anyone else listening in) you unpack the gtk-bundle, poke the loader & dependencies in the right places (under lib and bin) and then run gdk-pixbuf-query-loaders. It executes the new loader to find out what parameters it needs. You can only write the gdk-pixbuf.loaders file manually if you know what it needs, guessing won't do. I'm particularly glad that you remembered all the dependencies because windows only tells you about the first one it hasn't got, and since I don't connect to the internet with windows I then have to re-boot into linux to get it :-) The new build of Denemo is going up now. Thanks Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: svg pixbuf loader on Windows
> The Windows binaries for the svg gdk-pixbuf loader are in the > svg-gdk-pixbuf-loader package. The currently latest version is at > http://ftp.gnome.org/pub/GNOME/binaries/win32/librsvg/2.22/svg-gdk-pixbuf-loader-2.22.2.zip. > It requires the librsvg DLL, in the librsvg package in the same > folder. And the librsvg DLL then requires libcroco and libgsf. The > libcroco DLL then again requires the libxml2 DLL, and the libgsf DLL > requires the bzip2 and zlib DLLs. Finding those are left as an > exercise to the reader. They are in hopefully logical locations on the > same site. Note that in particular, binaries for stuff not directly > part of the GNOME and GTK+ stack is in ../../dependencies. Please > follow up if you find that something is missing... Thanks for this. I think I have the stuff and I think I have poked it in the right places, but so far no joy. The gdk-pixbuf.loaders file in the directory below c:/program files/Denemo seems to be ignored. With another program that loads .gif images, if I hide the gdk-pixbuf.loaders file, the program says that it is missing (on the console). But I can hide it in the Denemo tree and I get no complaint. I am not sure that Denemo needs other pixbuf loaders (are the standard gtk icons loaded with one?). In any case the contents of the gdk-pixbuf.loaders file looks suspicious, entries like "c:/devel/target/gtk +-2.8.9/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-xpm.dll" /devel is not (never has been) a path on my windows partition. Finally, (if I am not trying your patience too far) do I need to be worrying about 2.4.0 versus 2.10.0, or will it be happy at runtime with anything it finds below gtk-2.0? I ask because all the earlier pixbuf loaders had a different naming convention (libpixbufloader-gif.dll while the svg one was just svg_loader.dll), but perhaps this is because it doesn't belong in the GTK+ stack. Thanks again for your help Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
svg pixbuf loader on Windows
I have been building the Gnu Denemo program for windows and have adopted the method of bundling all the libraries needed with the intaller. I got the gtk stuff from gtk+-bundle-2.12.10.zip but there does not seem to be anything for creating pixbufs from svg files. I can't figure out why this should be different from loaders for other stuff (jpg, png ...) and where if anywhere the loader can be obtained. Any ideas? Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
insert-at-cursor signal in GtkTextView
The insert-at-cursor signal in GtkTextView doesn't seem to be emitted. There are a few references to a similar problem with GtkEntry, for which using a signal for the GtkEditable ancestor worked around, but I cannot see any suggestions for GtkTextView. Anybody know what is going on? The key-press-event is working fine, but that leaves you with a lot more work since you have to decide whether a character would be inserted... Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk-can-change-accels property absent in gtk 2.8.20?
Well, I've passed in a constant string gtk_settings_set_long_property(settings, "gtk-can-change-accels", TRUE, ".gtkrc:0"); and the code has started working - thank you very much! Richard Shann On Fri, 2008-02-08 at 00:19 +0100, Torsten Reuss wrote: > On Feb 7, 2008 10:28 PM, Richard Shann <[EMAIL PROTECTED]> wrote: > > Hi Torsten, > > Thanks for this - curiously I get > > > > (denemo:16377): Gtk-CRITICAL **: gtk_settings_set_long_property: > > assertion `origin != NULL' failed > > > > with your code. > > Hmm, I couldn't find out what the origin parameter was good for > (documentation is blank there), so I tried NULL and never had any > problems with it. My gtk versions are 2.12.0 (Linux) and 2.10.11 > (windows) though. > > Best regards, > Torsten ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk-can-change-accels property absent in gtk 2.8.20?
Hi Torsten, Thanks for this - curiously I get (denemo:16377): Gtk-CRITICAL **: gtk_settings_set_long_property: assertion `origin != NULL' failed with your code. I'll dig into this. Richard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtk-can-change-accels property absent in gtk 2.8.20?
I tried to putting a line to set the gtk-can-change-accels property thus: g_object_set (gtk_settings_get_for_screen (gdk_screen_get_default ()), "gtk-can-change-accels",TRUE, NULL); I put this in just after gtk_init and got the runtime warning (denemo:10714): GLib-GObject-WARNING **: IA__g_object_set_valist: object class `GtkSettings' has no property named `gtk-can-change-accels' The versions are glib 2.12.4 gtk 2.8.20 and the docs for http://library.gnome.org/devel/gtk/2.8/ say there should be such a property. Any ideas? Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Setting the default values for a class
In the denemo music program it would be useful for the class GtkLabel to default to use_markup TRUE (so that the music font could be freely used). I have tried traversing the widgets setting this value, thus static void use_markup(GtkWidget *widget) { if(GTK_IS_LABEL(widget)) { gtk_label_set_use_markup (GTK_LABEL (widget), TRUE); } else if(GTK_IS_CONTAINER(widget)) { GList *g = gtk_container_get_children (GTK_CONTAINER(widget)); for(;g;g=g->next) use_markup(g->data); if (GTK_IS_MENU_ITEM(widget)) { use_markup(gtk_menu_item_get_submenu(widget)); } } } but this curiously fails for toolitems (the GtkLabel widget in the GtkToolButton changes under some condition, perhaps to do with accelerators). I wondered if there was a call to be made to set the default for the class, but when I looked at the source I became more perplexed: gtklabel.c has a function static void gtk_label_class_init (GtkLabelClass *class) which is not called within the file, even though it is static. Short of some preprocesser magic, I can't see how this could ever get called. Is there a way to set the class defaults? Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list