Re: GTK+ 3.24?
On Wed, 2017-05-03 at 18:15 -0400, Matthias Clasen wrote: > On Wed, May 3, 2017 at 2:55 PM, Murray Cumming <murr...@murrayc.com> > wrote: > > Will there absolutely positively never be any GTK+ 3.23/24 > > releases? > > > > After all these years of not adding API, or deprecating API, in > > micro > > releases, I feel very uneasy about doing that in gtkmm 3.22.* just > > because GTK+ seems to be doing it. > > No plans for a 3.24, no. I don't think there is much of a problem > with adding deprecations - they are really a tool to help people > prepare for the jump to the next version. If you want to stick with > 3.22.x, there is no reason to chase deprecations. Yes, deprecations are indeed far less of an issue that API additions. I'd still rather avoid them in a micro release, so it's clearer when the API was deprecated. > As for new API, we have been pretty careful so far, and only allowed > some very minor additions in 3.22.x. Any examples you are thinking of > ? Sorry. Yes, you are right. I was sure we'd found some API additions, but it was just deprecations. > > But if there will never be a GTK+ 3.24, we could have a gtkmm 3.24 > > that > > adds and deprecates API without causing too much confusion in the > > future. > > I'm afraid that a gtkmm 3.24 that is based on gtk+ 3.22 would cause > quite a bit of confusion. We have at least one other API (but not ABI) change (to our Gtk::Box::pack_start() that we'd like to make in a gtkmm 3.24 release, regardless of any GTK+ API additions, to ease porting to gtkmm 4, though we haven't decided that yet. We can't do that in a gtkmm 2.22.x release without upsetting people because of breaking builds. I had hoped that a GTK+ 3.24 might exist to solve that problem for us. Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk4: gtk_box_pack_start()/end() porting
On Wed, 2017-05-03 at 14:22 +0200, Timm Bäder wrote: > > Have some container widgets changed, or lost, some default > > spacing/padding/margins too? For instance, it looks like > > GtkActionBar > > used to have some hard-coded spacing between its child widgets > > (added > > via gtk_action_bar_pack_start()), but not with gtk4. > > Yes, iirc GtkPopover with .menu and GtkFileChooserButton, etc. lost > their > spacing. Since GtkBox supports border-spacing via CSS now, I think > themes should handle that instead, but Adwaita doesn't care yet. So, applications shouldn't generally need to specify any spacing at all between child widgets in containers? For instance - Gtk::Box::spacing - margin of child widgets in a Gtk::ActionBar - Gtk::Grid column-spacing and row-spacing ? GTK 3 and GTK 4 themes are separate, right? -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk4: gtk_box_pack_start()/end() porting
On Fri, 2017-04-28 at 17:50 +0200, Murray Cumming wrote: > On Fri, 2017-04-28 at 17:20 +0200, Timm Bäder wrote: > > I've added notes about the fill and expand child properties to the > > migration guide: > > https://git.gnome.org/browse/gtk+/commit/?id=bb1deaafa42ccb03929d3c > > d5 > > fdab685218bbac29 > > Thanks. I guess it's that last part about hexpand/vexpand affecting > the > parent widgets too that explains what I've seen so far. So there is > really no simple mapping from the old API to the new API. Porting is > going to be rather awkward. Have some container widgets changed, or lost, some default spacing/padding/margins too? For instance, it looks like GtkActionBar used to have some hard-coded spacing between its child widgets (added via gtk_action_bar_pack_start()), but not with gtk4. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk4: gtk_box_pack_start()/end() porting
On Fri, 2017-04-28 at 17:20 +0200, Timm Bäder wrote: > I've added notes about the fill and expand child properties to the > migration guide: > https://git.gnome.org/browse/gtk+/commit/?id=bb1deaafa42ccb03929d3cd5 > fdab685218bbac29 Thanks. I guess it's that last part about hexpand/vexpand affecting the parent widgets too that explains what I've seen so far. So there is really no simple mapping from the old API to the new API. Porting is going to be rather awkward. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk4: gtk_box_pack_start()/end() porting
gtk4's gtk_box_pack_start() and gtk_box_pack_end() now no longer have the expand and fill parameters that are in GTK+3: https://developer.gnome.org/gtk3/stable/GtkBox.html#gtk-box-pack-start these are the commits that removed them: https://git.gnome.org/browse/gtk+/commit/?id=c92b7d4224b9cef1d08373fcc2 8f7fbd96c64e6d https://git.gnome.org/browse/gtk+/commit/?id=5729ea7744c2a41ae8fb833db6 690a6aa5ad7a84 But, based on some experiments, it doesn't seem obvious to me exactly how to replace these by setting halign, valign, hexpand or vexpand. Could someone please add a mapping of the old fill/expand combinations to the new halign/valign/hexpand/vexpand properties to the migrating guide? https://git.gnome.org/browse/gtk+/tree/docs/reference/gtk/migrating-3to 4.xml There are only 4 possible fill/expand combinations, only 3 of which ever made sense, so this should be doable. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Help with modal dialog
On Do, 2016-04-21 at 20:52 -0400, Matthew A. Postiff wrote: > g_signal_connect((gpointer)(syslogdialog->getDialog()), > "close", G_CALLBACK (on_close_system_log_activate), > gpointer(this)); > g_signal_connect((gpointer)(syslogdialog->getDialog()), > "delete-event", G_CALLBACK (on_close_system_log_activate), > gpointer(this)); > syslogdialog->run(); The delete-event signal handler needs to return a gboolean. The C API doesn't do any checking of the signature of the signal handler's function pointer. However, gtkmm does offer this compile-time type safety. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk+3 application Internationalization
On Thu, 2016-04-14 at 16:27 +0100, Emmanuele Bassi wrote: > > I don't know, if I understand it well, that I must translate all > > strings in my application (copy from Stock Items) one more time to > all > > languages just like Gtk if I want to use them ? > > It's hardly going to be an issue. [snip] There are some strings such as Cancel, Close, Quit, File, Edit, Cut, Copy, Paste that really should be the same in each application. The lack of (useful) stock items makes it harder to make them the same in each application. It's a genuine concern. I'm not bothered by the lack of things like OK, Yes, and No, which shouldn't be used anyway. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Announcement of Visual Studio 2015 projects and solutions for Gtkmm and GTK+
On Fri, 2015-11-27 at 09:55 +0100, codekiddy wrote: > Sure, why not, Actually I used these as a starting point, I'll be > glad to contribute! > . > Although instead of working on patches on existing solutions (and > working on multiple versions for each VS), it should be easier to > just push new "reworked" solutions somehow? It's important that improvements can be tracked as distinct commits, so we can see what has actually changed and why. At first, you'd have to submit patches to bugzilla, but you can quickly earn my trust so I just let you push directly. For instance, I'm happy for Chun-wei Fan to just make the changes he thinks are necessary. Hopefully you can work together on this, with others too. > Although I'm not sure how to make them work inside source tree > (because project properties are one folder level outside of source > tree), but it's worth discussing to see what changes can be done to > make them work and incorporate into source tree. > > What say you? Apparently the existing projects work so far at least for some people, so please do try to work with the existing system. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Announcement of Visual Studio 2015 projects and solutions for Gtkmm and GTK+
On Fri, 2015-11-27 at 07:59 +0100, codekiddy wrote: > Hello there! > > I'm glad to be able to announce new release of Visual Studio 2015 > projects and solutions to compile GTK+, Gtkmm, all it's dependencies > solely by using Visual Studio, as well as few other popular "hard to > build" libraries. > > To best illustrate which packages you can build with these projects > and solutions see this image > > Entry repository is available on GitHub Visual Studio gtkmm > > There is also an updated Visual Studio gtkmm wiki to help beginners > building gtkmm from scratch. > > Any possible updates will be pushed to msvc-140 branch, up to next > release of Visual Studio. Well done. We have MS Visual Studio project files in our regular *mm repositories. Could you submit patches to those, if they are not complete, please? For instance: https://git.gnome.org/browse/glibmm/tree/MSVC_Net2013 -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Announcement of Visual Studio 2015 projects and solutions for Gtkmm and GTK+
On Fri, 2015-11-27 at 11:11 +0100, codekiddy wrote: > >It's important that improvements can be tracked as distinct commits, > so > >we can see what has actually changed and why. > > I understand, and thank you for your trust. I'll give my best to take > time when possible. > Can't promise to much since I'm pushing most of free time into my own > project designs. > > What can't be misdone for sure is to add test projects, to existing > solutions, since almost every > source tree has sources for test projects but no actual project files > to perform tests against the > library once build is done. Great. Patches are very welcome. Thanks. > There is nothing wrong with currently present projects in source > tree, and they work fine, assuming > one follows directions mentioned in readme files and additionally > follows Fan's tutorial, of course to > make things easy. > > problem is building dependencies, there is no single place on the > internet where users could > download VS projects for dependencies that will truly work without > build errors. [snip] This will continue to be the case unless the build files are in the upstream dependencies' repositories where people can maintain them together over time. All attempts to do this separately fail. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
gtk+ 4 plan?
Is there still any particular plan to do a gtk+-4.0 parallel-install (like gtk+-3.0) release any time in the next year or so? For gtkmm, we would like to use C++11 features in the gtkmm API, but that would probably need us to break ABI. That would be OK if we had to do it for GTK+ 4 anyway. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problem with 'gio/gwin32appinfo.c'
On Mon, 2015-06-22 at 16:29 +0100, John Emmas wrote: Hi LRN, Just flagging up that after updating today from glibmm master, some of those functions are now coming up as missing symbols (when I try to re-build glibmm with MSVC). It looks like 'glibmm/gio/src/appinfo.hg' might still be trying to wrap some of them - in particular:- g_app_info_get_all_for_type() This is an old function. There's no way it would have been removed from the API (It's still in the header): https://developer.gnome.org/gio/stable/GAppInfo.html#g-app-info-reset-type-associations However, it does indeed look like the win32 implementation was removed: https://git.gnome.org/browse/glib/commit/?id=4d800e4d86db6825dd3c508c83352b9a4cd24350 You might ask about that in the bug report: https://bugzilla.gnome.org/show_bug.cgi?id=666831 g_app_info_reset_type_associations() Just flagging this up in case you need to liaise with the glibmm devs. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Strategy for unit testing GTK+ applications in C
On Sun, 2015-05-17 at 07:04 -0500, Daniel Espinosa wrote: I think your idea of keep processes in a library and create unit tests to it and then link to your GUI app is the better approach. GDA[1] have a processes non-GUI library, a GUI library of widgets and a GUI app. You should check it. Or don't even create a library if you don't need one. Just link your tests to only the sources that the tests need to use. This works out neatly when you can manage to keep some of your source code separate from any UI or use of GTK+. To create unit tests the various parts of your source code need to be loosely coupled anyway. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Replacement for gtk_widget_override_background_color() with GtkTextView
On Sun, 2015-02-15 at 11:40 +0100, Murray Cumming wrote: However, while getting these screenshots I noticed that the change is caused by different GTK+ versions, regardless of what API I use. I'll try to narrow down what caused the change and file a bug. I was wrong again. The problem was in my application's code. While porting from (deprecated) gtk_misc_set_alignment() to gtk_widget_set_halign(), I ended up calling gtk_widget_set_halign() on a GtkTextView that didn't (couldn't) previously have gtk_misc_set_alignment() called on it. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Replacement for gtk_widget_override_background_color() with GtkTextView
On Fri, 2015-02-13 at 14:50 +, Emmanuele Bassi wrote: hi; On 11 February 2015 at 13:08, Murray Cumming murr...@murrayc.com wrote: The gtk_widget_override_*() functions were recently deprecated: https://git.gnome.org/browse/gtk+/commit/?id=63efdca2 (These had themselves replaced gtk_widget_modify_*(): https://git.gnome.org/browse/gtk+/commit/?id=f383e6b0 ) I'd like to improve the deprecation documentation to give more exact clues about what people should do. there are two ways to replace gtk_widget_modify_background_color() — though, obviously, the actual reply would be don't: I too would discourage it in almost all cases but there are legitimate uses in specialist applications. • you can either provide a fragment of CSS to style the widget yourself • you can override the GtkWidget::draw signal, and paint the color yourself using Cairo But I don't know what CSS would replace gtk_widget_override_background_color() for a GtkTextView. If I use background-color: #whatever then only the background of the content's text is colored, not the background of the whole area. what does the whole area mean, in this context? the text view may have some margin, which does not get painted with the background color, as per CSS spec. if you want to paint the area beneath the margin, you'll have to draw on the parent widget, not on the GtkTextView. These screenshots show the difference. Additionally, on the obviously-wrong one, the text wrapping also changes during every mouse over. However, while getting these screenshots I noticed that the change is caused by different GTK+ versions, regardless of what API I use. I'll try to narrow down what caused the change and file a bug. Thanks. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Replacement for gtk_widget_override_background_color() with GtkTextView
The gtk_widget_override_*() functions were recently deprecated: https://git.gnome.org/browse/gtk+/commit/?id=63efdca2 (These had themselves replaced gtk_widget_modify_*(): https://git.gnome.org/browse/gtk+/commit/?id=f383e6b0 ) I'd like to improve the deprecation documentation to give more exact clues about what people should do. But I don't know what CSS would replace gtk_widget_override_background_color() for a GtkTextView. If I use background-color: #whatever then only the background of the content's text is colored, not the background of the whole area. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Plotting Library for Gtkmm-3.0 - PlotMM
On Sun, 2015-02-08 at 09:08 -0800, Jim Charlton wrote: A recent post about charting and plotting software for gtk-3.0 encouraged me to share some modifications I have made to the PlotMM library originally made available by Andy Thaller (http://plotmm.sourceforge.net/). I have made quite extensive modifications to the original library in order to make it compatible with Gtkmm-3.0. Most of the the original functionality remains as described in the link above. The modified library, with a Makefile for Linux/Ubuntu 14.04.1, is included in the package, as are notes on the modification I have made. I have also verified that the code compiles on MAC OS X 10.10 with the gtk/gtkmm osx libraries installed. To obtain the package, go to http://jimc.dyndns.org/Mod-Plotmm. Well done. However, this project would be healthier in the long term if you put it somewhere like github. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: recently-used.xbel
On Fri, 2015-01-23 at 11:55 +, John Emmas wrote: [snip] So what API calls do I need to eventually arrive at a pointer to the RecentManager object? [snip]: If you just call Gtk::RecentManager::get_default() (or gtk_recent_manager_get_default) instead of instantiating it yourself then you can get it anywhere you like. I don't know why gtk_recent_manager_new() even exists. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkWidget:halign and GtkSizeGroup
I'm trying to replace a use of the deprecated GtkMisc:xalign property with the newer GtkWidget:halign property with some labels that are in a GtkSizeGroup. The (GTK_ALIGN_START) alignment doesn't seem to be having any effect, though it does when work using the deprecated xalign property. This screenshot shows the result in Glade with some GtkBoxes and a GtkSizeGroup, and the correct behaviour in a GtkGrid. Should it work with a GtkSizeGroup? I can't just use a GtkGrid because I am actually using a custom container in my application. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 Win32 Bundles : RFC
On Wed, 2014-03-05 at 12:41 +0100, Murray Cumming wrote: On Wed, 2013-12-04 at 07:40 +0100, Tarnyko wrote: Hi folks, Just some news on the Win32 - bundle distribution - side. Main URL : http://win32builder.gnome.org/ The continuous build environment now generates 64-bit bundles. The bundle for GTK+ 3.10.x has been generated. [snip] Many thanks. I found your INSTRUCTIONS.txt file about this system: https://git.gnome.org/browse/gtk3-build-system/tree/GTK +3_build_system-crosslinux/z_Install/INSTRUCTIONS.txt but it mentions some files, such as 1_Prereq.sh that do not exist. Maybe they've been renamed? I wondered what CentOS packages you installed as a prerequisite, so I could try to get this working on Ubuntu. By the way, why is that directory called z_INSTALL? Does it mean something? Would you like to set up a bugs.gnome.org product so you could accept patches more easily? Or maybe we should use the Backend: Win32 component of GTK+ in bugs.gnome.org? This should probably be mentioned in the .doap file. I also noticed that your download/*.sh scripts assume that directories already exist in libs/ before cding to them and git cloning into them. But only some of the directories already exist, because only some of them need to contain patches. So errors like this occur, without a check for the error: ./73_gnome-icon-theme.sh: 2: cd: can't cd to ../../libs/73_gnome-icon-theme Cloning into 'gnome-icon-theme'... which results in some git clones being put where they are probably not expected to be. I would prefer to put these git clones somewhere separate from the associated patches, and I'd guess they can just go right into one directory without the sub-directories with numerical prefixes. So far I guess that jhbuild could do all this more robustly, but I haven't explored everything yet. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 Win32 Bundles : RFC
On Wed, 2013-12-04 at 07:40 +0100, Tarnyko wrote: Hi folks, Just some news on the Win32 - bundle distribution - side. Main URL : http://win32builder.gnome.org/ The continuous build environment now generates 64-bit bundles. The bundle for GTK+ 3.10.x has been generated. [snip] Many thanks. I found your INSTRUCTIONS.txt file about this system: https://git.gnome.org/browse/gtk3-build-system/tree/GTK +3_build_system-crosslinux/z_Install/INSTRUCTIONS.txt but it mentions some files, such as 1_Prereq.sh that do not exist. Maybe they've been renamed? I wondered what CentOS packages you installed as a prerequisite, so I could try to get this working on Ubuntu. By the way, why is that directory called z_INSTALL? Does it mean something? Would you like to set up a bugs.gnome.org product so you could accept patches more easily? Or maybe we should use the Backend: Win32 component of GTK+ in bugs.gnome.org? This should probably be mentioned in the .doap file. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib vs. gdbus-codegen: file collision
On Wed, 2013-11-13 at 06:06 -0800, Grant wrote: The latest glib from git (glib- on Gentoo) wants to install 2 files which are also installed by gdbus-codegen: /usr/share/man/man1/gdbus-codegen.1.bz2 /usr/bin/gdbus-codegen glib- also has a failed patch which might be related: * Failed Patch: glib-2.35.x-external-gdbus-codegen.patch ! * ( /var/lib/layman/gnome-next/dev-libs/glib/files/glib-2.35.x-external-gdbus-codegen.patch ) Does anyone know what's happening with this? Problems with Gentoo packages should be reported to Gentoo, please. -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: tutorial on hiding a widget and showing another in it's place?
On Sun, 2013-10-27 at 09:28 +0100, Murray Cumming wrote: On Sat, 2013-10-26 at 10:33 -0400, Patrick wrote: Hi Everyone I have a table of buttons. On clicking a button I would like a new table of buttons to take the first tables place. I am assuming I do this by hiding the first table, and inserting another in the callback function but I am not quite sure and it would be nice to see the standard way of doing this before i reinvent the wheel. Could someone point me to a good tutorial on this or if you happen to have a bit of code handy, to post it? I am okay with a variety languages if it is not in C. The new GtkSwitch widget is useful for this. I mean GtkStack. Sorry. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: tutorial on hiding a widget and showing another in it's place?
On Sat, 2013-10-26 at 10:33 -0400, Patrick wrote: Hi Everyone I have a table of buttons. On clicking a button I would like a new table of buttons to take the first tables place. I am assuming I do this by hiding the first table, and inserting another in the callback function but I am not quite sure and it would be nice to see the standard way of doing this before i reinvent the wheel. Could someone point me to a good tutorial on this or if you happen to have a bit of code handy, to post it? I am okay with a variety languages if it is not in C. The new GtkSwitch widget is useful for this. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
GtkApplication actions: app and win prefixes/groups
When would someone want to use a GAction action prefix other than app. or win.? I'm creating my own GSimpleActionGroup, with it's own group name (the prefix), as a way to have a set of menu items that's populated at runtime. Is there a downside to not using app or win? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Stock Items Deprecation
On Fri, 2013-07-19 at 12:56 +0200, Krzysztof Kosiński wrote: 2013/7/18 Emmanuele Bassi eba...@gmail.com: support for those features has already been developed and it is going to be added to GAction before we release GLib 2.38 and GTK 3.10, and improved in the future so that it matches with the overall spirit and design of the API. if you want to influence where the API is going, you can start looking at how to port your code, what you think it's missing, and file bugs. dropping on irc.gnome.org, in the #gtk+ channel, is also a good idea. OK, I guess that answers my question. This was about your comment: GAction has no functionality for accelerators, icons, or automatically creating widgets. These are very useful in applications which reuse the same action in more than one place (e.g. in a menu and on a toolbar). How are we supposed to replace it in new code? I've noticed that there is support now in the GtkBuilder GMenu XML (and probably therefore in GMenuModel) for: * accelerators by using, for instance: attribute name='accel'lt;controlgt;F/attribute * icons by using, for instance: attribute name=icon/usr/share/my-app/something.png/attribute This seems to be (wiki) documentation for them: https://wiki.gnome.org/HowDoI/GMenu https://wiki.gnome.org/GApplication/GMenuModel I don't see a way to specify these for the action in general rather than just for the particular use of the action in a menu item or tool button. And I have not found a way to specify a tooltip for a menu item with GMenu/GAction/GtkBuilder, as an equivalent for the tooltip parameter to gtk_action_new(): https://developer.gnome.org/gtk3/unstable/GtkAction.html#gtk-action-new -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
On Wed, 2013-07-17 at 11:47 +0200, Murray Cumming wrote: On Tue, 2013-07-02 at 09:41 -0400, William Jon McCann wrote: Hi, As some of you may have noticed we have recently deprecated Stock Items in master. Some details on this change may be found here: https://docs.google.com/document/d/1KCVPoYQBqMbDP11tHPpjW6uaEHrvLUmcDPqKAppCY8o/pub Please let us know what you think. This deprecated several classes (GtkIconFactory, GtkIconSet, GtkIconSource, GtkImageMenuItem, GtkAction, GtkUIManager). It also deprecated GtkRecentAction, because it deprecated the base GtkAction. So far it has no replacement for use in the world of GAction/GMenu/GtkBuilder instead of GtkAction/GtkMenu/GtkUIManager: https://bugzilla.gnome.org/show_bug.cgi?id=707422 Isn't this reason enough to revert the deprecation of GtkAction and GtkUIManager? Deprecation without replacement makes the deprecation less useful to application code because it makes it impossible for me to achieve zero use of deprecated API. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkBuilder for a popup GMenu: items disabled
I'm trying to convert code from GtkUIManager+GtkMenu to GtkBuilder
+GMenu. Is there anything I'm doing wrong in the attached example? The
menu items are disabled.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
www.openismus.com
#include gtk/gtk.h
const char* ui =
interface
menu id='somemenu'
section
item
attribute name='label' translatable='yes'SomeThing/attribute
attribute name='action'something/attribute
/item
item
attribute name='label' translatable='yes'OtherThing/attribute
attribute name='action'otherthing/attribute
/item
/section
/menu
/interface;
static GtkWidget *menu = NULL;
static void
on_popup_item (GSimpleAction *action, GVariant* parameter, gpointer user_data)
{
g_warning (%s called.\n, G_STRFUNC);
}
static GActionEntry action_entries[] = {
{ something, on_popup_item },
{ otherthing, on_popup_item }
};
static gboolean
on_window_delete_event (GtkWidget *widget,
GdkEvent *event,
gpointer data)
{
return FALSE;
}
static void
on_window_destroy (GtkWidget *widget,
gpointer data )
{
gtk_main_quit ();
}
static gboolean
on_button_press_event (GtkWidget* widget, GdkEventButton* event, gpointer user_data)
{
if( (event-type == GDK_BUTTON_PRESS) (event-button == 3) )
{
gtk_menu_popup (GTK_MENU (menu), NULL, NULL, NULL, NULL,
event-button, event-time);
return TRUE; /* Handled. */
}
return FALSE; /* Not handled. */
}
int
main (int argc, char *argv[])
{
gtk_init (argc, argv);
GtkWidget *window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_widget_show (window);
g_signal_connect (window, delete-event,
G_CALLBACK (on_window_delete_event), NULL);
g_signal_connect (window, destroy,
G_CALLBACK (on_window_destroy), NULL);
GtkBuilder *builder = gtk_builder_new();
GError* error = NULL;
gtk_builder_add_from_string (builder, ui, -1, error);
g_assert_no_error (error);
GMenu* gmenu = G_MENU (gtk_builder_get_object (builder, somemenu));
g_assert (gmenu);
menu = gtk_menu_new_from_model (G_MENU_MODEL (gmenu));
g_assert (menu);
/* This doesn't work, so we must use the SimpleActionGroup to specify a callback instead: */
/*
GMenuItem* menu_item = G_MENU_ITEM (gtk_builder_get_object (builder,
something));
g_assert (menu_item);
*/
GSimpleActionGroup *action_group = g_simple_action_group_new ();
g_action_map_add_action_entries (G_ACTION_MAP (action_group),
action_entries,
G_N_ELEMENTS (action_entries),
NULL);
gtk_widget_insert_action_group(GTK_WIDGET (window), somemenu, G_ACTION_GROUP (action_group));
gtk_menu_attach_to_widget (GTK_MENU (menu), GTK_WIDGET (window), NULL);
g_signal_connect (window, button-press-event,
G_CALLBACK (on_button_press_event), NULL);
gtk_main ();
g_object_unref (G_OBJECT (builder));
g_object_unref (G_OBJECT (action_group));
return 0;
}
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder for a popup GMenu: items disabled
On Tue, 2013-07-23 at 11:08 +0200, Murray Cumming wrote: I'm trying to convert code from GtkUIManager+GtkMenu to GtkBuilder +GMenu. Is there anything I'm doing wrong in the attached example? The menu items are disabled. Ah nevermind. I needed to use 'somemenu.something' rather than 'something' for the items in the 'somemenu' menu. Thanks to Ignacio Casal for helping me with that. I wonder if there could be any runtime warnings about such orphaned menu items. -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
On Tue, 2013-07-02 at 10:56 -0400, William Jon McCann wrote: The problems of consistency between applications is a valid one and may be addressed the way we address other consistency issues, with documentation and clear guidelines . We already have the Stock Items Migration Guide That's a Google Docs document, which is a little odd. and I expect some of this will migrate into the GTK+ documentation Is anybody working on that. It seems to be an essential resource for translators to ensure that we will in future have some consistency, though I suspect that many translators will just not specify any mnemonics at all. I also doubt that most translators will take the time to consider the mnemonics for the whole application to avoid clashes. I guess we would need tools to help them with that. and platform HIG soon. Surely you wouldn't want to duplicate that list. -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
On Tue, 2013-07-02 at 09:41 -0400, William Jon McCann wrote: Hi, As some of you may have noticed we have recently deprecated Stock Items in master. Some details on this change may be found here: https://docs.google.com/document/d/1KCVPoYQBqMbDP11tHPpjW6uaEHrvLUmcDPqKAppCY8o/pub That links to this, which I find a little vague: https://developer.gnome.org/gtk3/stable/checklist-named-icons.html If we can't change the existing IDs such as https://developer.gnome.org/gtk3/unstable/gtk3-Stock-Items.html#GTK-STOCK-DIALOG-ERROR:CAPS to use the standard icon names such as dialog-error, wouldn't it still be useful to have some new macros for the standard icon names, to avoid typos? Otherwise, the compiler can't help us to know if a standard icon name is really a standard icon name. -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Getting a GMenuItem from GtkBuilder
Should the code below work, to get a menu item from a GtkBuilder using
the menu markup? It doesn't seem to. I'm guessing at the XML syntax
based on this:
https://developer.gnome.org/gtk3/unstable/GtkBuilder.html#BUILDER-UI
I would use Glade to show me the correct syntax, but it doesn't use this
menu/section/item syntax yet.
#include gtk/gtk.h
const char* ui =
interface
menu id='somemenu'
section
item
attribute name='label' translatable='yes'Some
Thing/attribute
attribute name='id'something/attribute
/item
item
attribute name='label' translatable='yes'Other
Thing/attribute
attribute name='id'otherthing/attribute
/item
/section
/menu
/interface;
int
main (int argc, char *argv[])
{
GtkBuilder* builder = gtk_builder_new();
GError* error = NULL;
gtk_builder_add_from_string (builder, ui, -1, error);
g_assert_no_error (error);
GMenu* menu = G_MENU (gtk_builder_get_object (builder, somemenu));
g_assert (menu);
GMenuItem* menu_item = G_MENU_ITEM (gtk_builder_get_object (builder,
something));
g_assert (menu_item);
gtk_main ();
g_object_unref (G_OBJECT (builder));
return 0;
}
--
murr...@murrayc.com
www.murrayc.com
www.openismus.com
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Stock Items Deprecation
On Wed, 2013-07-17 at 13:52 -0300, Juan Pablo Ugarte wrote: On Wed, 2013-07-17 at 12:55 +0200, Murray Cumming wrote: On Wed, 2013-07-17 at 11:23 +0100, Emmanuele Bassi wrote: [snip] in general, GtkUIManager should be replaced by GtkBuilder, so that could be added to the long description of the class instead of each public entry point in the API. [snip] Is there some way, as with GtkUIManager, to merge in, and later remove and replace, menu items? I used this with GtkUIManager to dynamically populate a menu with items not known at compile time. No there is not, but as with any dynamic UI you can always fallback to code. IIRC what I did with Glade was to use an action group for all the dynamic content (project's items) so it is easy to distinguish with one are autogenerated and need to be regenerated. You can also use a separator or hidden item as an insertion point. Of course all this needs some custom code and we should have a simple way to do this. Perhaps adding a simple api like this would let you easily know where to start deleting/adding dynamic items gint gtk_menu_shell_get_child_position (GtkMenuShell *menu_shell, GtkWidget *child); I see gtk_builder_add_from_string(), but I don't see how to remove items without destroying the entire GtkBuilder structure. Anyway we need to improve menu building with GtkBuilder, we need to add support for GAction/GMenuModel and all those classes. [snip] What kind of thing is missing? I mean, what kind of code can't be written now? Actually, I noticed that the bloatpad example already uses GtkBuilder and the GMenuModel API to dynamically get a menu from the GtkBuilder and then add menu items via code, so I guess I'll do that. It's actually far nicer than building a new GtkUIManager UI string at runtime and merging it in. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
On Tue, 2013-07-02 at 09:41 -0400, William Jon McCann wrote: Hi, As some of you may have noticed we have recently deprecated Stock Items in master. Some details on this change may be found here: https://docs.google.com/document/d/1KCVPoYQBqMbDP11tHPpjW6uaEHrvLUmcDPqKAppCY8o/pub Please let us know what you think. This deprecated several classes (GtkIconFactory, GtkIconSet, GtkIconSource, GtkImageMenuItem, GtkAction, GtkUIManager). But their overview documentation does not mention that the whole API is deprecated. And the deprecation comments for the individual methods just say that they are deprecated without any further advice. For instance: https://developer.gnome.org/gtk3/unstable/GtkUIManager.html#gtk-ui-manager-new -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
On Wed, 2013-07-17 at 11:23 +0100, Emmanuele Bassi wrote: [snip] in general, GtkUIManager should be replaced by GtkBuilder, so that could be added to the long description of the class instead of each public entry point in the API. [snip] Is there some way, as with GtkUIManager, to merge in, and later remove and replace, menu items? I used this with GtkUIManager to dynamically populate a menu with items not known at compile time. I see gtk_builder_add_from_string(), but I don't see how to remove items without destroying the entire GtkBuilder structure. -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Storage API
On Wed, 2013-05-01 at 16:31 +0200, Bastien Nocera wrote: Heya, I've started writing a simple database-like application in Javascript using GTK+, and I wondered about what to use for storage. gjs currently doesn't have bindings for SQLite, and using intermediate bindings like libgda I found too low-level (provider-specific SQL, libgda's GdaSqlBuilder makes this a bit more pleasant and safer, avoiding most provider-specific stuff. Of course, it doesn't hide SQL entirely. the need to write SQL and highly manual schemas upgrade paths). Dumping serialised Javascript objects to the filesystem isn't really elegant either. I was wondering whether an API based on HTML5's IndexedDB[1] (and maybe a GtkTreeModel to display the database contents/filtered results) would be of interest in GLib. If it's of interest, I'd like to start discussing and designing the API with interested parties. Cheers [1]: http://www.html5rocks.com/en/tutorials/offline/storage/#indexed-db -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Is GTK+ a cross-platform toolkit ?
On Tue, 2013-03-05 at 11:20 +0100, tarn...@tarnyko.net wrote: Hi Andy, I think it would be useful to continue to provide installers [snip] I think that discussion is a distraction. We really really need official binaries, and an official way to recreate them. An installer would be nice to have, but is hardly the major problem. -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: EXTERNAL: Re: win32 installer?
[snip] On Tue, 2012-07-17 at 22:14 +0200, Dieter Verfaillie wrote: That leaves just a folder, which is exactly what the bundle is and always has been (for example: http://ftp.gnome.org/pub/gnome/binaries/win32/gtk+/2.24/) An SDK, in my mind, adds all the tools, sources, patches, scripts, etc used to build that bundle (or to be correct, the packages making up the bundle) and a way for application writers to integrate with that system (so they don't have to reinvent the wheel). Versions of tools would be set in stone for a given branch (let's say gcc 4.6 for whatever packages are considered part of GNOME 3.4 and it's maintenance releases, 4.7 for GNOME 3.6 etc). Not limited to gcc off course, but *everything*. Application writer integrating with this system would be able to generate their own bundle (think glade, gedit, whatever) which can then be used to build real installers (using WiX, NSIS, InnoSetup, whatever). Doing all this is the only way we can guarantee end users (of the SDK) in the distant future will be able to patch say a 3 year old GTK+ branch when nobody is left around to maintain it, provided said user can get at a sufficiently old windows version (let's not pretend current mingw build envs will just work on future windows versions, see what happened when vista got released for example)... I suggest that this is an idea for later, after we have what we had for GTK+ 2. Thanks for your efforts. -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: EXTERNAL: Re: win32 installer?
On Mon, 2012-07-16 at 21:25 +0200, Dieter Verfaillie wrote: Installers are for end user product (GIMP, Gedit, Inkscape, etc) but not for libraries and components used to build such end user products. An installer for some sort of an SDK however would a different matter... Yes, I just want the built libraries and bits, ideally put in the right place automatically. I don't have the time or enthusiasm to build everything on Windows myself. I can just about bear to build my application on Windows if GTK+ is available. I basically just need what we had for GTK+ 2 on Windows. Maybe someday I (or somebody else) will even find the time to get that done ;) Here's hoping. Thanks. -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
win32 installer?
Is anyone any closer to having a Windows installer for GTK+ 3 ready? -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gdk threads ...
On Wed, 2012-04-11 at 11:28 -0400, Paul Davis wrote: On Wed, Apr 11, 2012 at 7:26 AM, Paul Davis p...@linuxaudiosystems.com wrote: Are there any plans for a gtkmm release based on gtk2 that will avoid the endless messages about using deprecated API, some related to thread stuff in gtk 2.24? these, specifically, are the messages i'm referring to: /Users/paul/a3/inst/include/glibmm-2.4/glibmm/thread.h: In function 'void Glib::thread_init(GThreadFunctions*)': /Users/paul/a3/inst/include/glibmm-2.4/glibmm/thread.h:786: warning: 'g_thread_init' is deprecated (declared at /Users/paul/gtk/inst/include/glib-2.0/glib/deprecated/gthread.h:259) /Users/paul/a3/inst/include/glibmm-2.4/glibmm/thread.h:786: warning: 'g_thread_init' is deprecated (declared at /Users/paul/gtk/inst/include/glib-2.0/glib/deprecated/gthread.h:259) /Users/paul/a3/inst/include/glibmm-2.4/glibmm/thread.h: In member function 'T* Glib::StaticPrivateT::get()': /Users/paul/a3/inst/include/glibmm-2.4/glibmm/thread.h:1050: warning: 'g_static_private_get' is deprecated (declared at /Users/paul/gtk/inst/include/glib-2.0/glib/deprecated/gthread.h:245) /Users/paul/a3/inst/include/glibmm-2.4/glibmm/thread.h: In member function 'void Glib::StaticPrivateT::set(T*, void (*)(void*))': /Users/paul/a3/inst/include/glibmm-2.4/glibmm/thread.h:1056: warning: 'g_static_private_set' is deprecated (declared at /Users/paul/gtk/inst/include/glib-2.0/glib/deprecated/gthread.h:250) /Users/paul/a3/inst/include/glibmm-2.4/glibmm/thread.h: In constructor 'Glib::PrivateT::Private(void (*)(void*))': /Users/paul/a3/inst/include/glibmm-2.4/glibmm/thread.h:1072: warning: 'g_private_new' is deprecated (declared at /Users/paul/gtk/inst/include/glib-2.0/glib/deprecated/gthread.h:231) I would prefer to have this discussion on the gtkmm-list or in bugzilla. Anyway, these look like a problem in glibmm, fixed in more recent glibmm versions, rather than in gtkmm. I would consider a patch for gtkmm 2.4, if there is something that helps. -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gdk threads ...
On Mon, 2012-03-05 at 08:07 -0500, Ryan Lortie wrote: hi Michael, On Mon, 2012-03-05 at 12:11 +, Michael Meeks wrote: Does that mean you're removing gdk_threads_enter and leave and the semantics around that ? is there some cunning new scheme proposed to intercept the mainloop and ensure that events / idle / timeout emissions hooked in by the toolkit can have applications add lock/unlock pairs ? We're not removing -- only deprecating. The deprecation does not seem to have happened in GTK+ 3.4: http://developer.gnome.org/gdk3/3.4/gdk3-Threads.html#gdk-threads-enter Is it still planned? The removal will come in GTK4. There will be no replacement functionality -- you will just be expected to do all your interaction with the toolkit from the main thread (ie: dispatching results via idles). -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_menu_popup vs language bindings
On Mon, 2012-03-19 at 05:55 -0400, Matthias Clasen wrote: Hey, a while ago, we changed the annotations for gtk_menu_popup to skip that function and instead rename gtk_menu_popup_for_device to gtk_menu_popup. The reason for this change was that gtk_menu_popup doesn't have a destroy notify for its user_data, which is problematic for language bindings. Now, I am getting urgent requests to undo this and instead expose both functions to bindings as-is. I'd like to get some more opinions on this from language binding authors - will reverting this change cause more harm now, or is it the right thing to do ? I am confused about what change you actually made. Did you change the C API? -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Signal emission changes
I don't know if these compiler warnings are new, and I have not looked at the actual code, but maybe you want to know about them: CC libgobject_2_0_la-gsignal.lo gsignal.c: In function 'g_signal_emit_valist': gsignal.c:3163:7: warning: suggest parentheses around comparison in operand of '' [-Wparentheses] gsignal.c:3171:10: warning: variable 'signal_id' set but not used [-Wunused-but-set-variable] -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Requesting enough size, but not too much
I would like my application window to be: - At least as big as a certain minimum size. - A little bigger if the screen is big enough for that. - Not bigger than the screen. - Not bigger than necessary. I can control the size of my window by calling these functions on the individual widgets: gtk_widget_set_size_request () gtk_entry_set_width_chars() but they only let me set a minimum size. I can also call gtk_window_set_default_size() but I consider that hacky compared to setting child widget sizes, and it has the same problem anyway. Is there no way to specify both a minimum width and natural width (and height) without deriving custom widgets, to override GtkWidget::get_preferred_width() ? I fear that I have to use gtk_window_set_geometry_hints(), but that would need me to hard-code window sizes: http://developer.gnome.org/gdk3/stable/gdk3-Windows.html#GdkGeometry -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: DTDs and other fun
On Thu, 2012-01-26 at 17:30 -0500, Shaun McCance wrote: I mostly agree with that. It certainly means nobody is validating these files at build/install time. I am, but not against any DTD: http://www.murrayc.com/blog/permalink/2010/03/30/testing-glade-files/ though I would like to use a DTD. The question is, should they? I would like to do any testing that I can, particularly if it's easy. People don't usually put that stuff in their Makefiles unless you make it easy for them. It comes down to whether there's a high rate of invalid .ui files being installed. It happens sometimes, and it usually causes crashes. It's nice to avoid it even if it's rare. I kind of suspect no, because they're almost always machine-generated. With menu files written (for now) by hand, that might be different. Glade has been a little funky over the last few years, so hand-editing has often been necessary. Of course, having an invalid DTD in the docs (and another one for GtkUIManager, incidentally) isn't good. If nobody cares about the DTD per se, maybe we should look at less 1980s ways of conveying the grammar. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk-2-24-win32 branch merged into gtk-2-24
On Thu, 2012-01-19 at 12:53 +0100, Dieter Verfaillie wrote: On Thu, 19 Jan 2012 12:44:53 +0100, Murray Cumming wrote: On Mon, 2011-11-07 at 15:19 +0100, Alexander Larsson wrote: The -win32 branch is now in a pretty good state and seems to be the best Gtk 2.x version for win32 so far, so I just merged it into gtk-2-24, and I plan to do a release later this week. [snip] Many thanks for that. What's happening with win32 support in GTK+ 3? Do you have any idea when there will be binaries available, even for testing? I'd like to update Glom's Windows installer. I maintain http://www.optionexplicit.be/projects/gnome-windows/GTK+3/ which is built from ATK, Pango, GLib, GTK+, GObject-Introspection, etc master branches. For some modules with highly experimental patches that have not yet been accepted upstream even. [snip] Thanks, but are people generally working on getting the GTK+ 2 Windows improvements into GTK+ 3? I'd like a general sense of how it is going. I want to use it, but I don't want to spend more time with Windows than necessary if I can avoid it. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk-2-24-win32 branch merged into gtk-2-24
On Mon, 2011-11-07 at 15:19 +0100, Alexander Larsson wrote: The -win32 branch is now in a pretty good state and seems to be the best Gtk 2.x version for win32 so far, so I just merged it into gtk-2-24, and I plan to do a release later this week. [snip] Many thanks for that. What's happening with win32 support in GTK+ 3? Do you have any idea when there will be binaries available, even for testing? I'd like to update Glom's Windows installer. -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GThread struct now hidden
On Thu, 2011-10-13 at 13:26 +0200, Murray Cumming wrote: By the way, I also noticed that g_thread_init() is deprecated, presumably because you must now used g_thread_new(), so you don't need it, but I don't see a deprecation comment on g_thread_init(). There are still no deprecation comments on the deprecate thread API: http://developer.gnome.org/glib/unstable/glib-Deprecated-Thread-APIs.html#g-static-private-get The usual Please use X instead. comment is very useful to people who just see the warning from the compiler about a specific function that is used in their code. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gthread: G_STATIC_MUTEX_INIT: Fix this for the non-win32 case.
On Wed, 2011-10-26 at 15:12 -0400, Ryan Lortie wrote: hi Murray, I reverted this commit for now. Can you please open a bug to discuss this? I don't think your fix is correct since the extra field is never used anymore. OK. It's here: https://bugzilla.gnome.org/show_bug.cgi?id=662797 -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: missing gdaui entrys functions in distribution
On Thu, 2011-10-20 at 20:05 -0200, Renato Merli wrote: Regarding last message... i am using 4.99 version of libgda, newer versions dont compile and are not the ones in use by c++ layer developers gnome-db-l...@gnome.org is the libgda mailing list. 2011/10/20 Renato Merli merli.ren...@gmail.com: Hi, I've found libgda-ui functions for specialized entrys on libgda source code that are not in the reference. The author of C++ wrappers also told that they are not in the package distribution also, but i didnt check it yet. Can anyone fix the configue scripts to install functions on libgda-ui/data-entries folder ? Theres a way to use entries without these functions, but it dont give the possibility to inherit from specialized entrys. It would be nice for libgda-uimm creators if someone could also write some references and a class diagram. Lets make current libgda usable with all its features. Thanks -- Renato Merli -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GThread struct now hidden
This change in glib master does indeed break glibmm: http://git.gnome.org/browse/glib/commit/?id=d904612100120d12126f1a6623a106d8a5b02fa6 Unless it's really really necessary, it would be great if you would not do this, or if you could leave it until a glib ABI break. Glib::Thread has a static (but private) GThread member instance: http://git.gnome.org/browse/glibmm/tree/glib/src/thread.hg#n285 so obviously glibmm no longer builds. We do this so you can cast a Glib::Thread* directly to a GThread*. We probably did this (in 2002?) because we have no way to associate our C++ instance with the C instance, because GThread is not a GObject. I doubt that we can find a way around that, though I have not tried. We also access the struct fields (joinable, priority) directly in simple getter methods, but I don't know if anybody really uses them. We might get away with breaking their functionality if we can't find replacements: http://git.gnome.org/browse/glibmm/tree/glib/src/thread.ccg#n120 http://git.gnome.org/browse/glibmm/tree/glib/src/thread.ccg#n135 At the least, we should probably deprecate those methods. I have no objection to deprecating our entire Glib::Thread API, if we can replace it with a more-correct Glib::Thread2 API, but we'll be in trouble if user applications (built with glibmm = 2.30) start crashing just because the user installed glibmm 2.32. -- Murray Cumming murrayc@murrayc com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GThread struct now hidden
On Thu, 2011-10-13 at 12:48 +0200, Murray Cumming wrote: This change in glib master does indeed break glibmm: http://git.gnome.org/browse/glib/commit/?id=d904612100120d12126f1a6623a106d8a5b02fa6 Unless it's really really necessary, it would be great if you would not do this, or if you could leave it until a glib ABI break. Glib::Thread has a static (but private) GThread member instance: http://git.gnome.org/browse/glibmm/tree/glib/src/thread.hg#n285 so obviously glibmm no longer builds. We do this so you can cast a Glib::Thread* directly to a GThread*. We probably did this (in 2002?) because we have no way to associate our C++ instance with the C instance, because GThread is not a GObject. I doubt that we can find a way around that, though I have not tried. We also access the struct fields (joinable, priority) directly in simple getter methods, but I don't know if anybody really uses them. We might get away with breaking their functionality if we can't find replacements: http://git.gnome.org/browse/glibmm/tree/glib/src/thread.ccg#n120 http://git.gnome.org/browse/glibmm/tree/glib/src/thread.ccg#n135 At the least, we should probably deprecate those methods. I have no objection to deprecating our entire Glib::Thread API, if we can replace it with a more-correct Glib::Thread2 API, but we'll be in trouble if user applications (built with glibmm = 2.30) start crashing just because the user installed glibmm 2.32. By the way, I also noticed that g_thread_init() is deprecated, presumably because you must now used g_thread_new(), so you don't need it, but I don't see a deprecation comment on g_thread_init(). -- Murray Cumming murrayc@murrayc com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GThread struct now hidden
On Thu, 2011-10-13 at 08:58 -0400, Ryan Lortie wrote: hi On Thu, 2011-10-13 at 13:26 +0200, Murray Cumming wrote: By the way, I also noticed that g_thread_init() is deprecated, presumably because you must now used g_thread_new(), so you don't need it, but I don't see a deprecation comment on g_thread_init(). g_thread_init() is deprecated because you simply do not need to call it. g_thread_new() is rather a replacement for g_thread_create(). Yes. My point is just that all those deprecated functions should have deprecation documentation. -- Murray Cumming murrayc@murrayc com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GThread struct now hidden
On Thu, 2011-10-13 at 09:00 -0400, Ryan Lortie wrote: hi Murray, On Thu, 2011-10-13 at 12:48 +0200, Murray Cumming wrote: This change in glib master does indeed break glibmm: http://git.gnome.org/browse/glib/commit/?id=d904612100120d12126f1a6623a106d8a5b02fa6 I had a feeling it might break something or other, and I didn't think about bindings. I'll back it out immediately. Many thanks. Let's add it to the list of reasons to do an ABI break one day, if hiding it would make something useful possible. -- Murray Cumming murrayc@murrayc com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gnome-db] GVariant to replace GValue?
On Tue, 2011-09-06 at 18:51 -0500, Daniel Espinosa wrote: I'm reading about GVariant, still I don't understand all details, but found it equivalent to GValue and may be better on memory usage. Are you considering to replace GValue by GVariant? GVariant values are for constant values. You'll notice that there are no g_variant_set_*() functions here: http://developer.gnome.org/glib/unstable/glib-GVariant.html But libgda is an API that lets you set values in a database as well as read them out. So I don't think GVariant makes sense for libgda, just as it doesn't make sense for GtkTreeView. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gnulib, libegg, foo
On Sun, 2011-08-14 at 22:53 +0200, Andy Wingo wrote: At one point Johan Dahlin, who works with business applications, argued that GTK needed more businessy widgets -- reporting facilities, a spreadsheet-like table, etc. [snip] libgda-ui (in libgda), probably does most of this, or tries to. I don't use it personally, but it's where I'd start if I wanted to spend time on this. http://developer.gnome.org/libgda/unstable/ch22.html -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: libegg: Removing old directories
On Fri, 2011-03-18 at 23:42 +0100, Murray Cumming wrote: libegg has lots of directories that have just a README saying how the code has successfully moved into GTK+. But that's mostly old news now. If there's no objection then I'll remove the directories so it's easier to see at a glance what's still interesting. David King has recently ported some of the code to GTK+ 3, and added an --enable-warnings=error configure option (via gnome-common) so we can avoid some problems in the code in future. However, some stuff still doesn't build, and porting it would be awkward. Should it live? background-monitor / EggBackgroundMonitor: http://git.gnome.org/browse/libegg/tree/libegg/background-monitor I don't know what this was ever meant to do, but it's apparently now hard to port because GTK+3 no longer allows us to paint on the root X window. It might be something to do with transparent windows, maybe a hack that's now unnecessary: http://mail.gnome.org/archives/desktop-devel-list/2002-May/msg00288.html icon-chooser / EggIconChooser: http://git.gnome.org/browse/libegg/tree/libegg/iconchooser Uses a custom GtkFileSystem, though I don't know why yet. smclient / EggSMClient: http://git.gnome.org/browse/libegg/tree/libegg/smclient Uses gdk_x11_set_sm_client_id() and should probably use GDBus instead of libdbus-1. See https://bugzilla.gnome.org/show_bug.cgi?id=79285 treeviewutils: http://git.gnome.org/browse/libegg/tree/libegg/treeviewutils Uses gdk_keyboard_grab and gdk_keyboard_ungrab, which are generally awkward to port to GTK+ 3. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: libegg: Removing old directories
On Fri, 2011-03-18 at 23:42 +0100, Murray Cumming wrote: libegg has lots of directories that have just a README saying how the code has successfully moved into GTK+. But that's mostly old news now. If there's no objection then I'll remove the directories so it's easier to see at a glance what's still interesting. Maybe GDL (used in Anjuta) http://git.gnome.org/browse/gdl is the more up-to-date equivalent for EggDock http://git.gnome.org/browse/libegg/tree/libegg/dock If there's no objection, I'm likely to remove EggDock too. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkApplication and argc/arv
On Fri, 2011-03-25 at 11:48 -0400, Colin Walters wrote: On Mon, Mar 21, 2011 at 6:03 AM, Murray Cumming murr...@murrayc.com wrote: I very much like the re-show-instead-of-reopening idea, and miss it since I stopped using MacOS 7.3. However, I don't understand why this should require a single process. How do you recommend apps implement this then? Via some interprocess communication, via a GtkApplication that makes that easy? Obviously I can't recommend that apps do that now, hence this discussion. Or maybe via some session-wide tracking of open files? I have no idea. I haven't investigated how it's done elsewhere. But my own idle speculation isn't helping me find a justification for the current code. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: libegg: Removing old directories
On Sun, 2011-03-20 at 20:03 -0400, Matthias Clasen wrote: On Fri, Mar 18, 2011 at 6:42 PM, Murray Cumming murr...@murrayc.com wrote: libegg has lots of directories that have just a README saying how the code has successfully moved into GTK+. But that's mostly old news now. If there's no objection then I'll remove the directories so it's easier to see at a glance what's still interesting. Sounds fine to me. Done. I wonder if anyone is using EggSidebar: http://git.gnome.org/browse/libegg/tree/libegg/sidebar The code hasn't been touched for years, and it's rather tedious to port it. I don't know what it's for. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkApplication and argc/arv
On Sat, 2011-03-19 at 09:44 -0400, Colin Walters wrote: Hi Murray, On Sat, Mar 19, 2011 at 9:11 AM, Murray Cumming murr...@murrayc.com wrote: For this and other unrelated reasons, I will remove Gtk::Application from gtkmm 3.0.0. I can't wrap an API that I don't understand It's not that you don't understand it exactly, it's that you don't agree, correct? No. I mean what I said and I'm getting rather tired of saying it. I doubt that others here welcome my persistence either. And really, it's too late for gtkmm 3.0 at this point. I stated reasons above. I disagree that reasons have been stated properly. I guess that answers to these questions might help me: http://mail.gnome.org/archives/gtk-devel-list/2011-March/msg00053.html http://mail.gnome.org/archives/gtk-devel-list/2011-March/msg00043.html I just looked through my entire application list; and have only 2 out of ~50 which I think would obviously be fine as multiprocess (namely file-roller, evince). The rest are games (about 15), system tools (abrt, selinux, ~10), apps like gedit which i know are single process (~10), etc. Why wouldn't gedit be fine as multiprocess? Why wouldn't most document-based applications be fine as multiprocess? Why wouldn't gnome-terminal be fine as multiprocess? I'm repeating myself, and I don't plan to do it much more, but I still see no reason to encourage applications to be multi-process where there is no shared data that is not already handled by multi-process APIs such as GSettings. Obviously - for any app that desires multiple windows (which is actually only ~15 of my apps) you can do both. You can't apparently do both easily with GtkApplication. If both are considered valid by GTK+ then GtkApplication should have some clear warning that it pushes one model only and that it shouldn't be used if that model is not wanted. But again - the point is that single process is more efficient. Efficient in terms of memory? Does it all hinge on that? Also - the single process approach makes it trivial to avoid data loss in the scenario where you open a file twice (i.e. right click on my-notes.txt to open in Abiword from nautilus, later forget you had it open and do it again), which is definitely a very compelling argument to me. If it's not for you, well I don't know what to say. I very much like the re-show-instead-of-reopening idea, and miss it since I stopped using MacOS 7.3. However, I don't understand why this should require a single process. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: libegg: Removing old directories
On Mon, 2011-03-21 at 10:27 +, Bastien Nocera wrote: On Mon, 2011-03-21 at 10:51 +0100, Murray Cumming wrote: On Sun, 2011-03-20 at 20:03 -0400, Matthias Clasen wrote: On Fri, Mar 18, 2011 at 6:42 PM, Murray Cumming murr...@murrayc.com wrote: libegg has lots of directories that have just a README saying how the code has successfully moved into GTK+. But that's mostly old news now. If there's no objection then I'll remove the directories so it's easier to see at a glance what's still interesting. Sounds fine to me. Done. I wonder if anyone is using EggSidebar: http://git.gnome.org/browse/libegg/tree/libegg/sidebar The code hasn't been touched for years, and it's rather tedious to port it. I don't know what it's for. I believe it's a 10-year old Evolution sidebar look-alike that was used in Evolution, Rhythmbox and possibly Muine at different points in time. That'd be the one on the left here: http://www.guidebookgallery.org/pics/gui/applications/internet/mail/gnome220redhat9-1-1.png I think I'll remove it then. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkApplication and argc/arv
On Thu, 2011-03-10 at 20:04 +0100, Murray Cumming wrote: But for applications that actually have some reason to have multiple windows (typically document-based applications) I still know of no reason why we would want to suggest that they should have all windows in one process. For this and other unrelated reasons, I will remove Gtk::Application from gtkmm 3.0.0. I can't wrap an API that I don't understand and I can't tell people to use that API if I can't say why they should. Things are much better now thanks to Matthias' extra documentation, but fundamental questions remain. Hopefully we can figure things out and add it for gtkmm 3.2. This is the gtkmm bug about it: https://bugzilla.gnome.org/show_bug.cgi?id=637445#c17 -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: decrease widget show time
On Fri, 2011-03-18 at 14:13 +0800, czk wrote: hello everyone, I use gtk+-3.0 in a embedded device. If I create a window put 4 buttons , 4 entrys 3 labels in it, from gtk_window_new to the window was showed spend 4 seconds totally. It a long time for me. Most time spend in gtk_widget_show_all. Maybe other things are happening. You can generally make the final show faster by not using gtk_widget_show_all(). I believe you should manually show() or show_all() the child widgets, and then just do one show() of the window itself at the end. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
libegg: Removing old directories
libegg has lots of directories that have just a README saying how the code has successfully moved into GTK+. But that's mostly old news now. If there's no objection then I'll remove the directories so it's easier to see at a glance what's still interesting. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtkmm3?
On Tue, 2011-03-15 at 22:11 -0400, Josh Bialkowski wrote: I was reading the gtkmm book and when I hit the clock example for drawing widgets with cairo, I realized that this was exactly what I was looking for (i.e. wanting to draw widgets with cairo). It was only after I couldn't get the example to compile that I noticed the note that it was for gtkmm3 not gtkmm2 (after all, I guess gtk3 is where all the cairo drawing is at anyway). Yes, you were probably looking at this, for gtkmm-3.0: http://library.gnome.org/devel/gtkmm-tutorial/unstable/sec-drawing-clock-example.html.en But maybe you want to look at this instead, for gtkmm-2.4: http://library.gnome.org/devel/gtkmm-tutorial/stable/sec-drawing-clock-example.html.en Anyway, so my question is, where is gtkmm3? I downloaded gtkmm-2.90.7, 2.91.7, and 2.99.5 guessing that these might be develoment snapshots and gtkmm3 doesn't actually exist yet. These are unstable versions of the gtkmm-3.0 API, yes. They're promising because the configure script seems to require gtk3, but I can't seem to build any of them. Anyway, so is gtkmm3 without a stable branch at this moment? If so, how stable are the unstable branches? Should I be able to build and use them? No, gtkmm 3 is not stable yet. Hopefully it will be soon. Or is the book just ahead of the game? We update the book as the gtkmm API changes. The stable versions still exist. There is a gtkmm-list mailing list, by the way. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GtkApplication and argc/arv
On Thu, 2011-03-10 at 09:59 +, Chris Vine wrote: [snip] The case for having single-instance programs in most cases for programs with a GUI interface seems self-evident to me, since most GUI programs keep some running global state which would be extremely tedious to synchronise between different processes. [snip] What global state, for instance? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkApplication and argc/arv
On Thu, 2011-03-10 at 09:01 -0500, Morten Welinder wrote: What global state, for instance? locale? As a reminder, setlocale is not thread-safe. Sorry, I don't understand. Could you explain in more detail? Why would two separate instances (separate processes) of the same app care if setlocale is not thread safe? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkApplication and argc/arv
On Thu, 2011-03-10 at 14:54 +, Chris Vine wrote: On Thu, 10 Mar 2011 14:48:12 +0100 Murray Cumming murr...@murrayc.com wrote: On Thu, 2011-03-10 at 09:59 +, Chris Vine wrote: [snip] The case for having single-instance programs in most cases for programs with a GUI interface seems self-evident to me, since most GUI programs keep some running global state which would be extremely tedious to synchronise between different processes. [snip] What global state, for instance? Most programs will keep application-related data relevant to all instances running which is not configuration data suitable for dconf nor something for which you want to set up a formal database to deal with change notification and resolution. If it's most programs then surely you can give some example. I don't think that most applications have to deal with caching, bookmarks, and history like Firefox. I accept that _some_ would have some shared data, and they might choose to go single-process to make that easier. But it doesn't seem common enough to recommend it generally. Apart from that, quite frankly it is I think what most users expect for programs having only one main window. Hopefully we don't expect users to have any idea of whether multiple document windows are really in the same process. The Quit menu item leaks this low-level concept so I thought we were generally trying to avoid it. Or do you mean some other sign that users would have that an application is single-process, that they would miss if it was multiple-process? The principal problem at the moment is gtk_window_present(): a user starts a program (she may have forgotten it is already running if it is minimised or on a different desktop) and gets presented with ... some odd blinking thing in the panel if she is attentive enough to spot it at all. Chris -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkApplication and argc/arv
On Thu, 2011-03-10 at 10:54 -0500, Paul Davis wrote: On Thu, Mar 10, 2011 at 10:47 AM, Murray Cumming murr...@murrayc.com wrote: If it's most programs then surely you can give some example. I don't think that most applications have to deal with caching, bookmarks, and history like Firefox. i think that the kind of thing chris is referring to is something like a program setting. suppose you open app FooBar2000 twice. in one instance, you change the preference barffle to yesterday + sin(90). in the other, you change it to jan 1st 1911 + arctan (0.2291). what is the value of the app preference at that point in time? he might be referring to something else entirely, of course. But that's configuration data that is handled by GSettings or GConf, surely? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkApplication and argc/arv
On Thu, 2011-02-24 at 17:55 -0500, Colin Walters wrote: On Thu, Feb 24, 2011 at 5:15 PM, Morten Welinder mort...@gnome.org wrote: What actual problem was solved by all this infrastructure to keep just one instance? Basically for any application which manipulates private files in any form (in Firefox' case, this is the history database), it avoids data corruption with uncontrolled access by multiple processes. This doesn't seem likely to be interesting to most apps. GSettings (or GConf) handles shared access to the configuration data. It also matches the GNOME 3 experience; for any apps that can have multiple windows, it's usually far saner (and more efficient) to implement it with one process. [snip] Maybe I don't understand, but that sounds just like it's saner without telling me why. Or are you talking about windows that are shared between document windows, such as having 2 gimp images open with only one toolbar window? I would very much like some reasoning to point people at when I tell them to use GtkApplication. I will not just hand-wave and say that people say it's good. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkApplication and argc/arv
On Fri, 2011-02-25 at 12:53 +0200, Claudio Saavedra wrote: On Fri, 2011-02-25 at 08:58 +0100, Carlos Garcia Campos wrote: Note that we moved from single process model to multiple process without changing the evince behaviour, it still behaves like a single instance app, opening an already opened document brings it to the front. As far as I understand, you can achieve this with GApplication/GtkApplication by a combination of G_APPLICATION_IS_SERVICE and G_APPLICATION_IS_LAUNCHER in both a service and a launcher process. [snip] Is there any example of this in an application? It seems generally useful. I'd like to use GtkApplication for Glom but I don't want to make all instances be in the same process, because: 1. It will crash. 2. I currently have a global object for application-wide stuff such as a pointer to the main window. Being single-process lets me just use that global instance from various parts of my code rather than passing it up and down all the levels of code as an extra function parameter. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkApplication and argc/arv
On Thu, 2011-02-24 at 23:41 +, Emmanuele Bassi wrote: On 2011-02-21 at 21:57, Murray Cumming wrote: I'll leave the other points, as they've received a reply already. 2. How should we use GOptionContext to parse command line arguments from argc/argv when using GtkApplication. Is this the ideal way, using the command-line signal? http://git.gnome.org/browse/totem/tree/src/totem.c#n187 It seems a little long-winded. Totem's usage is not entirely trivial: it requires argument parsing in the local (i.e. the just executed) and remote (i.e. the currently running) instances. simpler cases are: • you can just parse all arguments in the local instance, which means using g_option_context_parse() prior to creating the G(tk)Application instance; in this case, the command line arguments can be used to parametrize the Application instance, e.g via GObject properties, direct access to instance members, or even GApplication actions (as soon as they get more functionality). • you can defer all command line parsing to the remote instance, by passing the G_APPLICATION_HANDLES_COMMAND_LINE flag to the constructor and by connecting to the ::command-line signal; and example is in the Dictionary: http://git.gnome.org/browse/gnome-utils/tree/gnome-dictionary/src/gdict-app.c#n222 probably the latter case is a more direct map of what you'd have done with libunique or the Bacon copy-and-paste API. in general, and if at all possible, I'd strongly advise to use the first approach (local parsing), and keep an eye out as soon as the GAction API gets more love and functionality. Thanks for the suggestion, but why wouldn't you use the GApplication::local_command_line vfunc for local command-line parsing? http://library.gnome.org/devel/gio/unstable/GApplication.html#GApplicationClass.local-command-line -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkApplication and argc/arv
On Wed, 2011-03-02 at 10:07 +, Emmanuele Bassi wrote: [snip] Thanks for the suggestion, but why wouldn't you use the GApplication::local_command_line vfunc for local command-line parsing? http://library.gnome.org/devel/gio/unstable/GApplication.html#GApplicationClass.local-command-line if I a) don't want to sub-class GApplication and b) want to do local command line parsing, it's pretty trivial to use a GOptionContext and parse the command line prior to creating the GApplication. [snip] That would be nice for us to recommend here, https://bugzilla.gnome.org/show_bug.cgi?id=643650 but wouldn't that require us to call gtk_init() before g_option_context_parse(), to first remove the standard options? Or we could just call gtk_init_with_args(). Then I guess we could pass NULL, NULL to g_application_run() for argc/argv, but this is one of the things that needs to be documented: https://bugzilla.gnome.org/show_bug.cgi?id=643649 -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkApplication and argc/arv
On Thu, 2011-02-24 at 17:51 -0500, Colin Walters wrote: 1. Are we still meant to call gtk_init(argc, argv) when using GtkApplication, which takes argc/argv again via g_application_run(). Or is gtk_init() then superfluous? gtk_init is superfluous, yes; I guess we should mention GtkApplication here then: http://library.gnome.org/devel/gtk3/stable/gtk3-General.html#gtk-init it's handled in the startup phase of GtkApplication. Do you mean, during g_application_run(), or earlier? Mathias mentioned that gtk_init(NULL, NULL) is best anyway, though I don't understand why: http://bugzilla.gnome.org/show_bug.cgi?id=639925#c3 It doesn't really do anything interesting or useful; you can achieve everything with environment variables But don't (bearded) people expect applications to take (GNU?) standard command line options, such as --display=DISPLAY? If we really think people should do this: gtk_init(NULL, NULL), or g_application_run(NULL, NULL), then surely we should say so in the documentation. I don't like the vagueness right now. The documentation currently doesn't even say that NULLs are valid values: http://library.gnome.org/devel/gtk3/stable/gtk3-General.html#gtk-init http://library.gnome.org/devel/gio/unstable/GApplication.html#g-application-run -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkApplication and argc/arv
On Mon, 2011-02-21 at 21:57 +0100, Murray Cumming wrote: I'm trying to wrap GtkApplication for gtkmm but I can't really do that until I understand how it's meant to be used. In general, I find the documentation lacks overview and advice, partly because it's spread between GApplication and GtkApplication and mentions some concepts without explaining them first. So I have some questions. 1. Are we still meant to call gtk_init(argc, argv) when using GtkApplication, which takes argc/argv again via g_application_run(). Or is gtk_init() then superfluous? Mathias mentioned that gtk_init(NULL, NULL) is best anyway, though I don't understand why: http://bugzilla.gnome.org/show_bug.cgi?id=639925#c3 2. How should we use GOptionContext to parse command line arguments from argc/argv when using GtkApplication. Is this the ideal way, using the command-line signal? http://git.gnome.org/browse/totem/tree/src/totem.c#n187 It seems a little long-winded. And more simply: 3. Will we recommend that all GTK+ applications generally use GtkApplication? 4. Do we believe that all (GTK+) applications should be single-instance applications? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkApplication and argc/arv
I'm trying to wrap GtkApplication for gtkmm but I can't really do that until I understand how it's meant to be used. In general, I find the documentation lacks overview and advice, partly because it's spread between GApplication and GtkApplication and mentions some concepts without explaining them first. So I have some questions. 1. Are we still meant to call gtk_init(argc, argv) when using GtkApplication, which takes argc/argv again via g_application_run(). Or is gtk_init() then superfluous? Mathias mentioned that gtk_init(NULL, NULL) is best anyway, though I don't understand why: http://bugzilla.gnome.org/show_bug.cgi?id=639925#c3 2. How should we use GOptionContext to parse command line arguments from argc/argv when using GtkApplication. Is this the ideal way, using the command-line signal? http://git.gnome.org/browse/totem/tree/src/totem.c#n187 It seems a little long-winded. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problem in gtk_combo_box_append_text()
On Thu, 2011-01-20 at 16:37 +0530, Karthikeyan Krishnamurthi wrote: Hi group, I try to append text to combo box using gtk_combo_box_append_text () i got the following error... gtk_combo_box_append_text: assertion `GTK_IS_LIST_STORE (combo_box-priv-model)' failed how to solve this.. I am using anjuta 2.32.0 Maybe you did not create the GtkComboBox with gtk_combo_box_new_text(): http://library.gnome.org/devel/gtk/stable/GtkComboBox.html#gtk-combo-box-append-text (This will be simpler in GTK+ 3.) -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Database view widget
On Mon, 2011-01-10 at 11:40 +0100, Edheldil wrote: Dear listmembers, I am writing an application in Python+libglade (*) which displays a long table of objects and their properties (geocaches, actually. Similar to GSAK or GeoGet). The problem is that with more than 15000 objects the TreeView starts to get rather unresponsive. Is there a better alternative? libgdaui (in libgda) provides widgets to show data from databases, though I don't use it personally yet. There might be python bindings. I guess it's probably possible to display only several pages of objects and handle ScrollBar manually, but that looks inelegant and tedious. Is there a better way? Some better suited widget, capable of displaying icons, simple markup and filtering/sorting? I remember there being some table widget, but it seemed to be limited back when I was looking at it. Regards, Edheldil (*) will port it to Gtk Builder eventually ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ 2.99.0 announced
On Thu, 2011-01-06 at 11:57 -0500, Matthias Clasen wrote: GTK+ 2.99.0 is now available for download at: If it's possible, please, it would be nice to have another release soon. Tristan has just fixed something that was making GtkTreeView completely broken with gtkmm, and probably with any other language bindings that use gtkmm 3: http://git.gnome.org/browse/gtk +/commit/?id=da41937b421fd5bafc4cad309f4c7cf7752d3fb4 This has made the last two releases untestable for our developers. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes of the GTK+ Team Meeting - 2010-12-14
On Wed, 2010-12-15 at 22:53 +0900, Tristan Van Berkom wrote: There's one behavioural change, gtk_tree_view_set_cursor() when specifying start_editing = TRUE will no longer toggle the state of an activatable cell (this used to be the case, we thought it was an undesirable side effect since the api is more about bringing attention to a cell for the user to edit but not implicitly modifying the data). I don't understand. Do you mean that start_editing=TRUE won't start editing? If so, can't we remove that parameter? Or, if not, what state do you mean? How did this change the data before? Other than that is seals the whole GtkTreeViewColumn structure so if people are accessing some members of the column directly they will have to find other means to do this (I dont expect there to be any valid reason for accessing these members directly though, we did expose gtk_tree_view_column_get_button() for the sake of libgail and apps that set tooltips on the column headers). And you've _added_ API, right? So we can now get a GtkCellArea, so we can do slightly more complex layout of cells within a GtkTreeViewColumn. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk-style-context has landed
On Sat, 2010-12-04 at 15:42 +0100, Carlos Garnacho wrote: Hey :), I have just merged the gtk-style-context branch in master, here's the status of things: * The new API is fully functional, well documented, and used underneath GtkStyle, a few widgets are using it directly already. * GtkStyle and GtkRcStyle are deprecated, but more code can be surely removed, the most tricky bit might be GtkRcPropertyParser, which is used in GtkSettings, although we can likely just typedef it to GtkSettingsParser. * Widgets in gtk/ need to use GtkStyleContext directly shortly, during the transition there might be visual glitches as widgets expose further information themeable through CSS, the builtin one will be kept as sane as possible though. * Apps are encouraged to switch, I guess a GNOME goal should be set up to handle this, Javier? :) I guess that the GtkWidget::style-set signal should also be deprecated, removed or changed: /** * GtkWidget::style-set: * @widget: the object on which the signal is emitted * @previous_style: (allow-none): the previous style, or %NULL if the widget * just got its initial style * * The ::style-set signal is emitted when a new style has been set * on a widget. Note that style-modifying functions like * gtk_widget_modify_base() also cause this signal to be emitted. */ widget_signals[STYLE_SET] = g_signal_new (I_(style-set), G_TYPE_FROM_CLASS (gobject_class), G_SIGNAL_RUN_FIRST, G_STRUCT_OFFSET (GtkWidgetClass, style_set), NULL, NULL, _gtk_marshal_VOID__OBJECT, G_TYPE_NONE, 1, GTK_TYPE_STYLE); I notice also that gtk_widget_reset_style() has no documentation. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk-style-context has landed
On Sat, 2010-12-04 at 15:42 +0100, Carlos Garnacho wrote: Hey :), I have just merged the gtk-style-context branch in master, here's the status of things: * The new API is fully functional, well documented, and used underneath GtkStyle, a few widgets are using it directly already. * GtkStyle and GtkRcStyle are deprecated, but more code can be surely removed, the most tricky bit might be GtkRcPropertyParser, which is used in GtkSettings, although we can likely just typedef it to GtkSettingsParser. * Widgets in gtk/ need to use GtkStyleContext directly shortly, during the transition there might be visual glitches as widgets expose further information themeable through CSS, the builtin one will be kept as sane as possible though. I'm wondering how code such as this should be ported (I'm porting a similar gtkmm example): http://git.gnome.org/browse/gtk+/tree/gtk/gtkcellrenderertoggle.c#n325 The old gtk_paint_*(GtkStyle*,) functions took a GtkStateType parameter, which is presumably deprecated in favour of GtkStateFlags, though that's not documented. But the new gtk_render_*(GtkStyleContext*, ) functions don't have a state parameter, because GtkStyleContext has a state instead. But then what happens to the state logic in that code? * Apps are encouraged to switch, I guess a GNOME goal should be set up to handle this, Javier? :) I'll be handling these items during the next days, helping hands are of course welcome. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Incorporating changes from bindings [was: Add GtkRadioGroup?]
On Wed, 2010-11-10 at 17:16 +0100, Philip Chimento wrote: On Sun, Oct 31, 2010 at 11:28, Alexander Larsson al...@redhat.com wrote: By the way, are there any other places where the java or C++ bindings do cleanup changes like this? Some may be interesting to push into the core now that we have the chance. I'd propose adding gtk_builder_get_widget_derived(), based on a method in gtkmm [1]. This would make it much easier to use Glade when subclassing widgets. [1] http://library.gnome.org/devel/gtkmm-tutorial/unstable/sec-builder-using-derived-widgets.html.en Note that I don't like how it demands that the derived class has a certain constructor (that takes a Builder instance as parameter), but there might be a better way: https://bugzilla.gnome.org/show_bug.cgi?id=134161 But that's probably all very C++. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: PyGtk and gtk-3.0 compatibility
On Sat, 2010-07-17 at 12:50 +1200, John Stowers wrote:
On Tue, 2010-07-06 at 01:48 +1200, John Stowers wrote:
Hi,
First of all, PyGI and GObject introspection is the way forward.
Now, that being said, it seems a little silly to spend all this effort
porting C apps in GNOME to gtk-3.0 only to see the first PyGtk app drag
back in the gtk-2.0 libraries with import gtk.
So I spent a little time trying to get PyGtk to build with GSEAL. Turns
out it wasn't that hard [1][2].
This has reached a reasonable state of working, I have run the same
python applications against a GSEALED G_DISABLE_DEPRECATED branch of
2.21 and against master (although for that you will also need this
branch [0])
If you are interested in playing
* Check out the gtk-3.0 branches of PyGObject and PyGtk [1][2]
* Build against a Gtk 2.21.x release with the appropriate GSEAL and
DISABLE_DEPRECATED CFLAGS
The remaining work is
* When needed, fix the override files to not call deprecated functions
* If an object has beer wrapped with the (fields (...)) attribute
then you need to either
1) Add a (getter-funcname foo) or (getter-propname bar)
attribute to he appropriate defs file
2) Remove the field wrapping (or possible override), which
will break compatibility
Behind the scenes, a modified PyGObject codegen is needed because of how
field access on GObjects (ie GtkWidget.window) is now handled. Access is
now delegated to either a getter function (ie gtk_widget_get_window) or
to a GObject property (ie g_object_get(widget, window, window))
depending on whether you added the getter-funcname of getter-propname to
the defs file. To see remaining fields that need to be emulated grep for
FIXME-FIELD in the generated code, or watch for DepreciationError
runtime warnings.
So depending on how many fields can be annotated in this way, and how
the GDK sealing / GDKDevice cleanup goes, I am confident that with a
little luck and some work, that PyGtk apps should be able to run against
gtk-3.0 with no code changes (providing you were not using very old
deprecated stuff, and that fields are now accessible with accessor
functions).
John
[0] http://github.com/nzjrs/pygtk/tree/build-against-gtk-3.0
[1] http://git.gnome.org/browse/pygobject/log/?h=gtk-3.0
[2] http://git.gnome.org/browse/pygtk/log/?h=gtk-3.0
p.s. Branches will likely be rebased in future
Only a few accessors were missing
* GtkWindow.has_user_ref_count
* GtkInvisible.has_user_ref_count
These both are used in the sink funcs, and seem to be a synonym
for checking the object has not been destroyed.
* gtk_menu_get_position_func{,_data}
So, what is the opinion on this? Is it worth me continuing? My idea
would be to make *only one* PyGtk release that builds against gtk-3.0,
it would see no new features.
John
[1] http://github.com/nzjrs/pygtk/commits/gtk-3.0
[2] http://github.com/nzjrs/pygobject/tree/gtk-3.0
What's the status of this now? Is there every likely to be a pygtk
release for GTK+ 3?
--
murr...@murrayc.com
www.murrayc.com
www.openismus.com
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Language Bindings Update for Website
On Mon, 2010-10-25 at 09:36 +0100, Martyn Russell wrote: Hi all, While adding the FreeBASIC language bindings to our language-bindings page¹, I noticed S-Lang and Harbour have not released for a while or have denounced their support for language bindings. This is just to let everyone know I have now removed them. For anyone else wanting to update their language binding support listed on the site, please let me know so we can update them accordingly. ¹ http://www.gtk.org/language-bindings.html That shows vala and Javascript as an Official GNOME Binding, presumably meaning an official GNOME Platform Binding. But they are not: http://live.gnome.org/TwoPointThirtyone/Bindings -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSpreadTable ('spread-table' branch)
On Fri, 2010-10-22 at 09:56 +0100, Emmanuele Bassi wrote: On Fri, 2010-10-22 at 10:48 +0200, David King wrote: On 2010-10-14 11:52, Murray Cumming murr...@murrayc.com wrote: If nobody says they want this soon then I guess we'll just put it in libegg. I am ready to add this to libegg, but it seems to depend on GTK+ 2 only right now, so do we want GTK+ 3 code there? If so, should I update everything to use GTK+ 3, make GTK+ 2/3 support selectable at configure time or simply dump the code in a subdirectory with a separate Makefile (much like wrapbox is currently)? libegg components are meant to be copy and pasted into other projects; adding a dependency on gtk+-3 just for the spread-table is not a problem at all. just add a conditional like the ones currently there for different versions of gtk+-2.0, and recurse into the spread-table directory if gtk+-3.0 is available. Wouldn't it be enough just to branch it and make master use only GTK+ 3? Or is it used by so many projects that try to support both GTK+ 2 and 3 in the same branch (which seems increasingly painful)? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSpreadTable ('spread-table' branch)
On Fri, 2010-10-22 at 12:01 +0100, Emmanuele Bassi wrote: On Fri, 2010-10-22 at 12:53 +0200, Murray Cumming wrote: I am ready to add this to libegg, but it seems to depend on GTK+ 2 only right now, so do we want GTK+ 3 code there? If so, should I update everything to use GTK+ 3, make GTK+ 2/3 support selectable at configure time or simply dump the code in a subdirectory with a separate Makefile (much like wrapbox is currently)? libegg components are meant to be copy and pasted into other projects; adding a dependency on gtk+-3 just for the spread-table is not a problem at all. just add a conditional like the ones currently there for different versions of gtk+-2.0, and recurse into the spread-table directory if gtk+-3.0 is available. Wouldn't it be enough just to branch it and make master use only GTK+ 3? Or is it used by so many projects that try to support both GTK+ 2 and 3 in the same branch (which seems increasingly painful)? I think that the branch already happened - I see a gnome-2-32 branch in libegg; Yes, that was me, not waiting before asking first. Bad me. but it would probably require to port all components to gtk+-3 if we want to make libegg a gtk+-3.0-only copy-and-paste library. Yes, I'm suggesting that David does that. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSpreadTable ('spread-table' branch)
On Thu, 2010-10-07 at 17:18 +0200, Murray Cumming wrote: On Thu, 2010-10-07 at 08:54 -0400, Havoc Pennington wrote: Hi, Oh, I see now it's a WrapBox replacement I guess (reading threads out of order) Well, not quite. This one has a fixed number of columns (or rows, depending on the orientation). That makes its layout quite different than if the number of rows was variable. I think of this one as being like newspaper columns. Here are some screenshots of tests/testspreadtable from the spread-table branch: http://www.flickr.com/photos/murrayc/sets/72157624989723865/detail/ It makes possible (dynamic) arrangements of widgets like this: http://www.glom.org/wiki/index.php?title=File:Small_glom_data_details.png Maybe it's not wanted by many people, but people ask for it every now and then. I want it myself, so I obviously have an incentive to have it maintained inside GTK+. If nobody says they want this soon then I guess we'll just put it in libegg. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSpreadTable ('spread-table' branch)
On Fri, 2010-10-08 at 23:31 +0900, Tristan Van Berkom wrote: For what its worth I finally applied this algorithm to the 'spread-table' branch. In the case that the trailing columns get no widgets, one widget is placed in each of the trailing columns (again, only happens with lots of columns and not enough widgets... and seems to look good this way IMO) I think you have broken the single-line case. No child widgets seem to appear for me now when lines=1. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: possible removal of GtkWrapBox
On Thu, 2010-10-07 at 12:36 +0900, Tristan Van Berkom wrote: Furthermore, the gimp's newer versions is now using GtkToolPalette in place of the older wrap-box (the gimp had been using a similar wrap-box widget to wrap items around in one of it's toolbars). Shouldn't GtkToolPalette (and maybe GtkToolbar) be using GtkWrapBox, or some similar code? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSpreadTable ('spread-table' branch)
On Mon, 2010-10-11 at 19:48 +0900, Tristan Van Berkom wrote: On Mon, 2010-10-11 at 11:04 +0200, Murray Cumming wrote: On Fri, 2010-10-08 at 23:31 +0900, Tristan Van Berkom wrote: For what its worth I finally applied this algorithm to the 'spread-table' branch. In the case that the trailing columns get no widgets, one widget is placed in each of the trailing columns (again, only happens with lots of columns and not enough widgets... and seems to look good this way IMO) I think you have broken the single-line case. No child widgets seem to appear for me now when lines=1. Interesting I'll check that out, the current expected results is that it still lines up children on 2 lines (i.e. thats the current minimum for the lines property, so I would expect a warning message and a behaviour of 2 lines). That seem rather arbitrary. Allowing lines=1 lets me use it more generically and dynamically. Otherwise I need to switch to a GtkBox just for that case. Since having a single-line spread table is desired, I'll go ahead and change that (I suppose 2 lines is still a good default though). Yes. fwiw, there's another unhandled case; currently when there are less widgets in the table than there are lines declared; space is still allocated for the extra missing lines. That sounds OK to me, as long as it's documented. It's giving the coder what he asked for. Otherwise, lines would be max-lines. Is it desirable to: a.) Only request and allocate space for columns we have enough widgets to fill ? or b.) Request and allocate space for a third column if only 2 widgets are in the box (leaving the impression that there is actually a third column that is simply unpopulated) ? I'm pretty sure that 'a' is the reasonable choice but I was not entirely sure. Cheers, -Tristan -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: possible removal of GtkWrapBox
On Mon, 2010-10-11 at 19:54 +0900, Tristan Van Berkom wrote: On Mon, 2010-10-11 at 11:06 +0200, Murray Cumming wrote: On Thu, 2010-10-07 at 12:36 +0900, Tristan Van Berkom wrote: Furthermore, the gimp's newer versions is now using GtkToolPalette in place of the older wrap-box (the gimp had been using a similar wrap-box widget to wrap items around in one of it's toolbars). Shouldn't GtkToolPalette (and maybe GtkToolbar) be using GtkWrapBox, or some similar code? Unfortunately it cant be done that simply (actually; I initially wanted to implement GtkSpreadTable in terms of a GtkBox subclass with 'n-lines' child GtkBoxes lined up in the opposite orientation, i.e. an hbox filled with vboxes... this idea would have presented some problems when it would come to requesting and testing different configurations). The main problem here is that the GtkToolPalette is expected to contain toolitems, and calling gtk_container_get_children on it should generally return the toolitems, anything that invokes the forall vfunc expects toolitems, not a wrapbox (also calling gtk_container_add/remove() on the toolpalette is not expected to add/remove the child wrap-box). Can't some vfunc implementation make it return the indirect children, instead, making GtkWrapBox purely implementation? So I would have to say only the latter is really possible, i.e. the toolpalette should use similar code as the wrapbox. (this case kindof shows one of the advantages that Clutter has in terms of layout managers being separated code from the actual containers). -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSpreadTable ('spread-table' branch)
On Fri, 2010-10-08 at 20:36 +0900, Tristan Van Berkom wrote: On Fri, 2010-10-08 at 12:13 +0200, Murray Cumming wrote: On Thu, 2010-10-07 at 12:37 +0900, Tristan Van Berkom wrote: Hello list again, Now for the introduction of GtkSpreadTable (still open for a better name for this widget). What the spread table container does is takes a linear list of widgets, which can be of variable size and spread/distribute the widgets as evenly as possible according to their size across a fixed number of rows or columns. Thus requiring the smallest size possible while maintaining the fixed number of columns or rows. For instance when oriented vertically, widgets will be listed top-down with the first widget in the top-left corner and the last widget on the bottom right; widgets will be lined up in such a way to require the least height as possible. This widget is the one that actually meets the requirements for Glom[0]. To get a better idea of how this works you can checkout and build the 'spread-table' branch I added to GTK+ yesterday... fire up the ./tests/testspreadlayout demo. Some quick links might be helpful http://git.gnome.org/browse/gtk+/log/?h=spread-table http://git.gnome.org/browse/gtk +/tree/gtk/gtkspreadtable.h?h=spread-table I have already wrapped this in a branch of gtkmm, and even used it in Glom instead of my custom code. It seems to work fine for me. Some small suggestions: 1. I think lines should be lines_count. 2. I'd like a get_widget_line(GtkWidget*) function so I can discover what line (column in my case) the widget is currently in. I'd like to query that whenever the allocation changes, so that I can align some child widgets (children of HBoxes in columns of the GtkSpreadTable) via a GtkSizeGroup. Obviously I only want widgets in a GtkSizeGroup (so they have the same width) that are in the same column. I suppose they could even be read-only child properties, in this way we could cache the current line number and notify the changes when one widget gets placed on an new line (an unallocated widget would always be on line -1). Then you could just watch when the widget jumps from line to line. However I wonder if changing some if the internal widget's size groups may effect the overall requested width of that column... and in the worst case you end up with a situation where: - Allocation happens - Change size groups in consequence - Size group changes widget requests - Widget's get reorganized into different columns as a result of the new size-grouping. Maybe it wont happen so long as you are playing with smaller sizes, but it may be recommendable to just size group widgets in all columns equally (I suppose experimentation will tell). Yeah, I saw the risk of an endless loop, but maybe I can prevent that in my code. Or maybe it will just be one extra relayout. My existing code actually has a hard-coded concept of two horizontally-aligned items in each column, so it knows about that constraint already. But that's very specific behaviour. Alternatively, is there just some way to find a child GtkWidget's position in a GtkContainer? Then I wouldn't need extra API. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSpreadTable ('spread-table' branch)
On Fri, 2010-10-08 at 21:23 +0900, Tristan Van Berkom wrote: On Fri, 2010-10-08 at 14:08 +0200, Murray Cumming wrote: On Fri, 2010-10-08 at 20:36 +0900, Tristan Van Berkom wrote: On Fri, 2010-10-08 at 12:13 +0200, Murray Cumming wrote: On Thu, 2010-10-07 at 12:37 +0900, Tristan Van Berkom wrote: Hello list again, Now for the introduction of GtkSpreadTable (still open for a better name for this widget). What the spread table container does is takes a linear list of widgets, which can be of variable size and spread/distribute the widgets as evenly as possible according to their size across a fixed number of rows or columns. Thus requiring the smallest size possible while maintaining the fixed number of columns or rows. For instance when oriented vertically, widgets will be listed top-down with the first widget in the top-left corner and the last widget on the bottom right; widgets will be lined up in such a way to require the least height as possible. This widget is the one that actually meets the requirements for Glom[0]. To get a better idea of how this works you can checkout and build the 'spread-table' branch I added to GTK+ yesterday... fire up the ./tests/testspreadlayout demo. Some quick links might be helpful http://git.gnome.org/browse/gtk+/log/?h=spread-table http://git.gnome.org/browse/gtk +/tree/gtk/gtkspreadtable.h?h=spread-table I have already wrapped this in a branch of gtkmm, and even used it in Glom instead of my custom code. It seems to work fine for me. Some small suggestions: 1. I think lines should be lines_count. 2. I'd like a get_widget_line(GtkWidget*) function so I can discover what line (column in my case) the widget is currently in. I'd like to query that whenever the allocation changes, so that I can align some child widgets (children of HBoxes in columns of the GtkSpreadTable) via a GtkSizeGroup. Obviously I only want widgets in a GtkSizeGroup (so they have the same width) that are in the same column. I suppose they could even be read-only child properties, in this way we could cache the current line number and notify the changes when one widget gets placed on an new line (an unallocated widget would always be on line -1). Then you could just watch when the widget jumps from line to line. However I wonder if changing some if the internal widget's size groups may effect the overall requested width of that column... and in the worst case you end up with a situation where: - Allocation happens - Change size groups in consequence - Size group changes widget requests - Widget's get reorganized into different columns as a result of the new size-grouping. Maybe it wont happen so long as you are playing with smaller sizes, but it may be recommendable to just size group widgets in all columns equally (I suppose experimentation will tell). Yeah, I saw the risk of an endless loop, but maybe I can prevent that in my code. Or maybe it will just be one extra relayout. My existing code actually has a hard-coded concept of two horizontally-aligned items in each column, so it knows about that constraint already. But that's very specific behaviour. Alternatively, is there just some way to find a child GtkWidget's position in a GtkContainer? Then I wouldn't need extra API. You can use gtk_widget_translate_coordinates() for that... but it will leave you with alot of guessing (observing widget allocation sizes in the child list etc). I think an API will make your code much cleaner, maybe it would help if at least you got to step in /before/ the allocation actually happens. i.e. the same API could be: guint gtk_spread_table_get_child_line (table, child, size); where it would return: the column 'child' would fall into if 'table' were allocated 'size' width. This could potentially give you a chance to shift size groups, run some tests with the above api and then actually allocate the table's size after you know it's safe. So I'd start with the child's currently allocated-size? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSpreadTable ('spread-table' branch)
On Thu, 2010-10-07 at 12:37 +0900, Tristan Van Berkom wrote: Hello list again, Now for the introduction of GtkSpreadTable (still open for a better name for this widget). What the spread table container does is takes a linear list of widgets, which can be of variable size and spread/distribute the widgets as evenly as possible according to their size across a fixed number of rows or columns. Thus requiring the smallest size possible while maintaining the fixed number of columns or rows. For instance when oriented vertically, widgets will be listed top-down with the first widget in the top-left corner and the last widget on the bottom right; widgets will be lined up in such a way to require the least height as possible. This widget is the one that actually meets the requirements for Glom[0]. To get a better idea of how this works you can checkout and build the 'spread-table' branch I added to GTK+ yesterday... fire up the ./tests/testspreadlayout demo. Some quick links might be helpful http://git.gnome.org/browse/gtk+/log/?h=spread-table http://git.gnome.org/browse/gtk +/tree/gtk/gtkspreadtable.h?h=spread-table I have already wrapped this in a branch of gtkmm, and even used it in Glom instead of my custom code. It seems to work fine for me. Some small suggestions: 1. I think lines should be lines_count. 2. I'd like a get_widget_line(GtkWidget*) function so I can discover what line (column in my case) the widget is currently in. I'd like to query that whenever the allocation changes, so that I can align some child widgets (children of HBoxes in columns of the GtkSpreadTable) via a GtkSizeGroup. Obviously I only want widgets in a GtkSizeGroup (so they have the same width) that are in the same column. This is fairly unusual, but this is the first widget that has such dynamic layout so you can't predict at compile time where the widgets will appear in relation to each other. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSpreadTable ('spread-table' branch)
On Thu, 2010-10-07 at 08:54 -0400, Havoc Pennington wrote: Hi, Oh, I see now it's a WrapBox replacement I guess (reading threads out of order) Well, not quite. This one has a fixed number of columns (or rows, depending on the orientation). That makes its layout quite different than if the number of rows was variable. I think of this one as being like newspaper columns. Here are some screenshots of tests/testspreadtable from the spread-table branch: http://www.flickr.com/photos/murrayc/sets/72157624989723865/detail/ It makes possible (dynamic) arrangements of widgets like this: http://www.glom.org/wiki/index.php?title=File:Small_glom_data_details.png Maybe it's not wanted by many people, but people ask for it every now and then. I want it myself, so I obviously have an incentive to have it maintained inside GTK+. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Build and install a new input method?
On Wed, 2010-10-06 at 07:56 +0700, John Matthewman wrote: http://www.openismus.com/misc/multipress-gtk-input-method/source/ Thanks for that - though I was hoping to see a simple makefile so I could make a bit more sense of what's going on. (Not a fan of autotools...) Just watch the output when you do make install then. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkComboBox popup menu wider than the combobox
On Tue, 2010-10-05 at 09:16 +0200, Michael Natterer wrote: On Mon, 2010-10-04 at 20:46 +0200, Murray Cumming wrote: Is there any way to make a GtkComboBox's popup menu wider than the GtkComboBox itself, or to disable ellipsizing so that is possible? No, but the other way around. You initialize the combo with the large cells, and then hack around to set smaller cells once the widget is constructed. In GIMP, we do the hack in style_set() because we need a style property that scales down font size, but I'm sure you can do it in another place too: layout = GTK_CELL_LAYOUT (gtk_bin_get_child (GTK_BIN (combo))); gtk_cell_layout_clear (layout); Then set something small. No a solution, but a hack that has worked for a long time now ;) I'm glad that I'm not the only one who needs this. Would this patch (from Tristan) help you too? https://bugzilla.gnome.org/show_bug.cgi?id=631452#c4 -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
