Re: GtkBuilder bugs
On 4 September 2011 12:32, Tristan Van Berkom wrote: > Its a bug that needs to be fixed in Glade. > > You can remove the line that says n-rows safely fwiw I don't think that an extra property would break the widget, the warning should be harmless. > > On Sun, Sep 4, 2011 at 1:41 AM, Bernhard Schuster > wrote: >> I am using a gtk-builder file for my application, which uses a Grid >> widget for layouting. When I run the application, I read this: >> >> Gtk-WARNING **: Unknown property: GtkGrid.n-rows >> >> and the grid is not shown (nor its contents) Are you by any chance using glade 3.10? That won't work. HTH Michal ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkBuilder bugs
On Mon, Sep 5, 2011 at 10:49 AM, Michal Suchanek wrote: > On 4 September 2011 12:32, Tristan Van Berkom wrote: >> Its a bug that needs to be fixed in Glade. >> >> You can remove the line that says n-rows safely fwiw > > I don't think that an extra property would break the widget, the > warning should be harmless. > Anything that GtkBuilder encounters that is unrecognized (unrecognized xml tags, properties and even unknown/inexistant GObject properties) cause GtkBuilder to either abort or fail to parse. >> >> On Sun, Sep 4, 2011 at 1:41 AM, Bernhard Schuster >> wrote: >>> I am using a gtk-builder file for my application, which uses a Grid >>> widget for layouting. When I run the application, I read this: >>> >>> Gtk-WARNING **: Unknown property: GtkGrid.n-rows >>> >>> and the grid is not shown (nor its contents) > > Are you by any chance using glade 3.10? > > That won't work. > No Glade earlier than 3.10 allows you to edit a GtkGrid, however the Grid implementation is based on the old GtkTable implementation. To remove the erronously serialized n-rows/n-columns properties from GtkGrid in Glade we first need to add some code to the GtkGrid deserialization routine to "guess" the span in row/columns based on the span of all children and number/position of added placeholders. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkBuilder bugs
On 5 September 2011 11:29, Tristan Van Berkom wrote: > On Mon, Sep 5, 2011 at 10:49 AM, Michal Suchanek wrote: >> On 4 September 2011 12:32, Tristan Van Berkom wrote: >>> Its a bug that needs to be fixed in Glade. >>> >>> You can remove the line that says n-rows safely fwiw >> >> I don't think that an extra property would break the widget, the >> warning should be harmless. >> > > Anything that GtkBuilder encounters that is unrecognized (unrecognized > xml tags, properties and even unknown/inexistant GObject properties) cause > GtkBuilder to either abort or fail to parse. For me unknown properties are just ignored, at least in gtk 2. > >>> >>> On Sun, Sep 4, 2011 at 1:41 AM, Bernhard Schuster >>> wrote: I am using a gtk-builder file for my application, which uses a Grid widget for layouting. When I run the application, I read this: Gtk-WARNING **: Unknown property: GtkGrid.n-rows and the grid is not shown (nor its contents) >> >> Are you by any chance using glade 3.10? >> >> That won't work. >> With Gtk 2 which does not know about Grid. > > No Glade earlier than 3.10 allows you to edit a GtkGrid, however > the Grid implementation is based on the old GtkTable implementation. > > To remove the erronously serialized n-rows/n-columns properties from > GtkGrid in Glade we first need to add some code to the GtkGrid deserialization > routine to "guess" the span in row/columns based on the span of all children > and number/position of added placeholders. If gtk3 cannot display the glade files made for it with glade 3.10 that's quite odd. I can see them in glade-previewer just fine but that's the only gtk3 app which I use with these. Thanks Michal ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkBuilder bugs
On Mon, Sep 5, 2011 at 12:43 PM, Michal Suchanek wrote: > On 5 September 2011 11:29, Tristan Van Berkom wrote: >> On Mon, Sep 5, 2011 at 10:49 AM, Michal Suchanek wrote: >>> On 4 September 2011 12:32, Tristan Van Berkom wrote: Its a bug that needs to be fixed in Glade. You can remove the line that says n-rows safely fwiw >>> >>> I don't think that an extra property would break the widget, the >>> warning should be harmless. >>> >> >> Anything that GtkBuilder encounters that is unrecognized (unrecognized >> xml tags, properties and even unknown/inexistant GObject properties) cause >> GtkBuilder to either abort or fail to parse. > > For me unknown properties are just ignored, at least in gtk 2. Ah my bad, indeed only a warning is issued for a misplaced property (the warnings which the Bernhard originally mentioned). > >> On Sun, Sep 4, 2011 at 1:41 AM, Bernhard Schuster wrote: > I am using a gtk-builder file for my application, which uses a Grid > widget for layouting. When I run the application, I read this: > > Gtk-WARNING **: Unknown property: GtkGrid.n-rows > > and the grid is not shown (nor its contents) >>> >>> Are you by any chance using glade 3.10? >>> >>> That won't work. >>> > > With Gtk 2 which does not know about Grid. > >> >> No Glade earlier than 3.10 allows you to edit a GtkGrid, however >> the Grid implementation is based on the old GtkTable implementation. >> >> To remove the erronously serialized n-rows/n-columns properties from >> GtkGrid in Glade we first need to add some code to the GtkGrid >> deserialization >> routine to "guess" the span in row/columns based on the span of all children >> and number/position of added placeholders. > > If gtk3 cannot display the glade files made for it with glade 3.10 > that's quite odd. Agreed, however while Glade is usually behind GTK+ in terms of features so often times Glade chokes out on hand crafted GtkBuilder xml which might contain tags that Glade does not yet recognize. But the opposite should usually never be a problem, unless we introduce features with some severe bugs then files created by Glade should always be readable by GtkBuilder (in this case we introduced GtkGrid with a bug that at least only causes a warning... unless there is more to this GtkGrid story...). > > I can see them in glade-previewer just fine but that's the only gtk3 > app which I use with these. Indeed, I'm not sure what is the story with GtkGrid not showing the content when loaded in a preview or an application (and the preview quite litteraly does what an application would do). Bernhard, can you perhaps attach the Glade file in question which does not show the contents of the GtkGrid ? Regards, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkBuilder bugs
2011/9/5 Tristan Van Berkom : > On Mon, Sep 5, 2011 at 12:43 PM, Michal Suchanek wrote: >> On 5 September 2011 11:29, Tristan Van Berkom wrote: >>> On Mon, Sep 5, 2011 at 10:49 AM, Michal Suchanek >>> wrote: On 4 September 2011 12:32, Tristan Van Berkom wrote: > Its a bug that needs to be fixed in Glade. > > You can remove the line that says n-rows safely fwiw I don't think that an extra property would break the widget, the warning should be harmless. >>> >>> Anything that GtkBuilder encounters that is unrecognized (unrecognized >>> xml tags, properties and even unknown/inexistant GObject properties) cause >>> GtkBuilder to either abort or fail to parse. >> >> For me unknown properties are just ignored, at least in gtk 2. > > Ah my bad, indeed only a warning is issued for a misplaced > property (the warnings which the Bernhard originally mentioned). Only a warning, not an error. Just curious because my widgets did not show up, but that was caused by GtkBin not drawing _anything_. In gtk2 it did, and the gtk3 docs do not mention it that there is no drawing method implemented. Removing the mentioned lines indeed fixed the warning. The glade version I spawned my .ui xml file from is the following: $ glade --version glade 3.10.0 Thanks for the quick response Regards Bernhard ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
How to detect when user scrolls
Im writing some code which will call a function (userActive) when the user does something, for mouse moves, clicks and keyboard presses this is working fine: g_signal_connect(G_OBJECT(mainwindow),"motion-notify-event",G_CALLBACK(userActive),NULL); //will be called when a mouse move occurs g_signal_connect(G_OBJECT(mainwindow),"button-press-event",G_CALLBACK(userActive),NULL); //will be called when a mouse click occurs g_signal_connect(G_OBJECT(mainwindow),"key-press-event",G_CALLBACK(userActive),NULL); //will be called when a key press occurs However in the mainwindow is a GtkScrolledWindow, and although its detecting mouse movement over the display area, if the user is just moving the scrollbarsandnot doing anything else, as they would if reading through some text, it doesnt detect it. I've tried the following, on both the GtkScrolledWindow (browserscrolledview) and the mainwindow (GtkWindow) but to no avail: g_signal_connect(G_OBJECT(browserscrolledview),"scroll-event",G_CALLBACK(userActive),NULL); //will be called when user scrolls in display area How do I detect when the scrollbars move? Thanks ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Alt-key mnemonics in menus
I've noticed that in my GTK app Alt-key mnemonics work like this: pressing Alt-F, for example, opens the _File menu, but once you're in the menu pressing Alt-N does not activate _New, although pressing plain N does so. In various other GTK apps both Alt-N and plain N work in this sort of context. Any idea on what might account for the difference? I'm wondering if I've inadvertantly done something that disables Alt-key within menus but I don't know what that could be. -- Allin Cottrell Department of Economics Wake Forest University, NC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Alt-key mnemonics in menus
On Mon, 5 Sep 2011, Allin Cottrell wrote: I've noticed that in my GTK app Alt-key mnemonics work like this: pressing Alt-F, for example, opens the _File menu, but once you're in the menu pressing Alt-N does not activate _New, although pressing plain N does so. In various other GTK apps both Alt-N and plain N work in this sort of context. Any idea on what might account for the difference? I'm wondering if I've inadvertantly done something that disables Alt-key within menus but I don't know what that could be. I should probably add: My menus are built in 'actions' mode, using an array of GtkActionEntry, a GtkUIManager and an XML UI definition. -- Allin Cottrell Department of Economics Wake Forest University, NC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to detect when user scrolls
On Mon, Sep 05, 2011 at 02:37:32PM +0100, Andrew Wood wrote: > However in the mainwindow is a GtkScrolledWindow, and although its > detecting mouse movement over the display area, if the user is just > moving the scrollbarsandnot doing anything else, as they would if > reading through some text, it doesnt detect it. > > I've tried the following, on both the GtkScrolledWindow > (browserscrolledview) and the mainwindow (GtkWindow) but to no avail: > > g_signal_connect(G_OBJECT(browserscrolledview),"scroll-event",G_CALLBACK(userActive),NULL); > > //will be called when user scrolls in display area > > How do I detect when the scrollbars move? Connect to "value-changed" signal of the GtkScrolledWindow's adjustments. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to detect when user scrolls
Excellent. Thank you On 05/09/11 15:37, David Nečas wrote: On Mon, Sep 05, 2011 at 02:37:32PM +0100, Andrew Wood wrote: However in the mainwindow is a GtkScrolledWindow, and although its detecting mouse movement over the display area, if the user is just moving the scrollbarsandnot doing anything else, as they would if reading through some text, it doesnt detect it. I've tried the following, on both the GtkScrolledWindow (browserscrolledview) and the mainwindow (GtkWindow) but to no avail: g_signal_connect(G_OBJECT(browserscrolledview),"scroll-event",G_CALLBACK(userActive),NULL); //will be called when user scrolls in display area How do I detect when the scrollbars move? Connect to "value-changed" signal of the GtkScrolledWindow's adjustments. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK+ 3.1.18
GTK+ 3.1.18 is now available for download at: ftp://ftp.gtk.org/pub/gtk/3.1/ http://download.gnome.org/sources/gtk+/3.1/ 22197439092404b43184d6121d047610f6c4573891309feca36ac8eedeaf6ab4 gtk +-3.1.18.tar.xz e6f1afcdf87932cb3fb78f65b9459b3e5bae44481d8c9f0ca3be9c388c0ad975 gtk +-3.1.18.tar.bz2 Another release in the 3.1 development cycle. I haven't gotten around to writing announcements for 3.1.14 and 3.1.16, so this announcement will be a little longer than usual. GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Overview of Changes in GTK+ 3.1.14, 16 and 18 = * GtkTreeView: - The GtkTreeModelFilter and GtkTreeModelSort implementations have been improved and a comprehensive test suite has been added * GtkFileChooser: - The selected file(s) can now be copied to the clipboard - It is now possible to go to the containing folder of a selected file in recent files or search results * Bugs fixed: 656851 Allow use of GVariant in GtkListStore 344858 gtk_menu_item_new_with_label() created widget with refcount 2 349502 option to copy full path in "Save AS"/"Open file" dialogs 621076 GtkTreeModelFilter does not emit all signals in some situations 634136 GtkTable::children accessor 649588 crash when sending a notification: "Gdk-CRITICAL **: gdk_vis... 650762 gtk_misc_set_alignment replacement with the new API functions 651827 Crash in check_application() 656986 GtkSwitch is unusable when added to primary toolbar. 657146 Missing files in POTFILEs.in 657260 Gtk should use AtkWindow and remove that hack on GailUtil 657359 Crash when specifying data length in gtk_css_provider_load_... 657384 missing accessors for GdkEvent structures 656223 GtkToolShell: Move vfunc default results to default impl... 530253 typo ifaces under gtk_tree_view_set_reorderable 566202 GTK_SELECTION_MULTIPLE description unclear 581435 gtk_tree_view_set_drag_dest_row() needs more documentation 655631 Description of x and y parameters in gtk_render_arrow is in... 657793 Support NULL sibling in gtk_grid_attach_next_to 657882 gtk_css_provider_propagate_error's signature not updated... 657963 themingengine: remove xthickness FIXME from gtk_render_line() 657985 reeview: add GTK_STYLE_CLASS_SEPARATOR for tree view separators 658008 Centered text alignment in GtkAssistant is wrong 658077 Add theming support to GtkPathBar 658111 gtk_label_set_pattern() is reset by a call to gtk_box_pack_... 658168 Gtk-Message: Failed to load module "gail" 658200 gtk_toolbar_finalize() does stuff it shouldn't Fix colord support in the print dialog * Distchecking works again, and errors that crept in due to lack of a working distcheck have been eliminated * Translation updates: Belarusian Brazilian Portuguese Esperanto Galician German Gujarati Indonesian Korean Lithuanian Norwegian bokmål Persian Russian Serbian Spanish Swedish Traditional Chinese Uighur Thanks to all contributors: Chun-wei Fan David Zeuthen Cosimo Cecchi Kristian Rietveld Xavier Claessens Arx Cruz Ryan Lortie Colin Walters Benjamin Otte Michael Terry Tristan Van Berkom Federico Mena Quintero Vincent Bernat Diego Celix Alejandro Piñeiro Murray Cumming Javier Jardón Richard Hughes Eitan Isaacson Sep 5, 2011 Matthias Clasen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Can g_file_monitor_file () report events from before it was created?
Hi, I'm working on some code to monitor for file changes in our application, and ran into a bit of a problem today with the Save-As case. The order of operations is something like: 1. File monitor exists on the document file which was loaded last 2. User hits File->Save as.. (and enters a filename) 3. Core of app saves file into the new file name 4. File monitor does not fire, as the saved file is not the one being monitored 5. Core of app notifies the GUI (with the file monitor) that the document we should be watching is now in the new filename. 6. g_object_unref() the old file monitor 7. Create new file monitor on the new file. After this happens, I actually get a change event fire from the new file monitor - despite the changes having been saved by the app's core (fopen / fclose directly to the file in question), before I even created the file monitor. Is it possible that Glib / GIO is caching some state incorrectly, and spotting on-disk changes from _before_ I created the file monitor, or is it more likely that the file doesn't "hit the disk" until some time after I fclose() it - and that it spots the change at this point in time? Any ideas what I might be doing wrong here? (PS. I got the feeling GLib / GIO is using polling, not anything clever like inotify to spot changes - is this correct?) Best regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Alt-key mnemonics in menus
Just for the record, in case anyone else wonders about this, here's what I have found (history below): Suppose you have a menubar with a top-level menu _File (with underscore-mnemonic F). How do you open the File menu via the keyboard? Easy: using Alt-F. Now for the question I was asking: suppose that under File you have a menu item _Baz (with underscore-mnemonic B). With the File menu open, how do you select Baz via the keyboard? (a) By pressing B; xor (b) by pressing Alt-B; xor (c) by doing either of the above, both work. I said that for my GTK app the answer was (a) but for some GTK-based apps the answer was (c). (I'm not aware of any for which the answer is (b).) And I wondered if something in my code was disabling (c). Having built a minimal test program, showing a plain GTK window with a menu, I can confirm that the GTK default is (a). And I find this to be the case with all the gnome apps that I've tested. I infer that apps that support (c) -- e.g., Firefox, Thunderbird and LibreOffice -- must be making some special effort to achieve that effect. Maybe for compatibility with MS Windows? On Mon, 5 Sep 2011, Allin Cottrell wrote: I've noticed that in my GTK app Alt-key mnemonics work like this: pressing Alt-F, for example, opens the _File menu, but once you're in the menu pressing Alt-N does not activate _New, although pressing plain N does so. In various other GTK apps both Alt-N and plain N work in this sort of context. Any idea on what might account for the difference? I'm wondering if I've inadvertantly done something that disables Alt-key within menus but I don't know what that could be. -- Allin Cottrell Department of Economics Wake Forest University ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Alt-key mnemonics in menus
On 2011-09-05 at 21:35, Allin Cottrell wrote: > Having built a minimal test program, showing a plain GTK window with > a menu, I can confirm that the GTK default is (a). And I find this > to be the case with all the gnome apps that I've tested. I infer > that apps that support (c) -- e.g., Firefox, Thunderbird and > LibreOffice -- must be making some special effort to achieve that > effect. Maybe for compatibility with MS Windows? Firefox, Thunderbird and LibreOffice are not really gtk applications. in the case of Firefox and Thunderbird, at least, the chrome of the browser is written usign XUL — and only looks like gtk. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list