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 > 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
GTK+ 3.24?
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. 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. -- 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 15:45 +0200, Timm Bäder wrote: [snip] > [1]Even though spacing *should* probably be handled by the theme, so > the > theme can decide whether UIs are more spacey or more narrow, nobody > has > come up with a proper way for applications to specify that. Yes, I've never liked how applications have all these magic values sprinkled through their code. Thanks for the explanation. -- 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: Problem with 'gio/gwin32appinfo.c'
On Thu, 2015-07-02 at 13:02 +0300, LRN wrote: > Truth is, i dislike having noop dummies in glib on one hand, and have > no > motivation/time/ideas to implement them on the other hand. Which is > why i'm > reluctant to act all by myself. ABI-breaking commits should be reverted or corrected in subsequent commits. It is not nice to break ABI. -- Murray Cumming murr...@murrayc.com www.murrayc.com signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-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-15 at 20:34 +0300, LRN wrote: > Previously g_app_info_reset_type_associations() > was a dummy, now it's just missing. Surely that's a regression then. -- Murray Cumming murr...@murrayc.com www.murrayc.com signature.asc Description: This is a digitally signed message part ___ 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: 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: Stock Items Deprecation
On Fri, 2013-07-19 at 12:56 +0200, Krzysztof Kosiński wrote: > 2013/7/18 Emmanuele Bassi : > > 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: <control>F> * icons by using, for instance: /usr/share/my-app/something.png 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-09-11 at 12:10 +0100, Emmanuele Bassi wrote: > hi; > > On 11 September 2013 11:39, Murray Cumming wrote: > > >> This deprecated several classes (GtkIconFactory, GtkIconSet, > >> GtkIconSource, GtkImageMenuItem, GtkAction, GtkUIManager). > > > > It also deprecated GtkRecentAction, because it deprecated the base > > GtkAction. > > as the author of GtkRecentAction, I'm honestly not concerned. > GtkRecentAction was a stop-gap that covered users of the old > EggRecent* API, and was never really useful; in a sense, it was a > class used to paper over a deprecation. shoving a bunch of recently > used files with only the name and a 16 px MIME type icon as a > differentiating feature in a menu (or in a toolbar menu button) always > seemed to me like a very bad UI. the file selection widget has a > better list of recently used files, these days. OK. That sounds reasonable. Can we make that decision and state it in the gtk-doc deprecation comments, please? > > 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. > > I'm not entirely sure that "zero use of deprecated API" is a worthy > goal to achieve immediately after a single release cycle - especially > when it comes to timed releases like the 3.x series has been for the > past 3 years. yes, in the end we obviously want the deprecated API > usage in applications to tend to zero, but "being able to port an > application in the month and a half between API freeze and GTK > release" has never been a requirement for deprecating API. [snip] I don't need to do it immediately after the stable release. I'd like to do it as soon as possible, idally before the next set of deprecations come along, but that gives me 6 months or so, which seems like a worthwhile goal for me. We want deprecations to be useful and would like people to follow their advice. They are more useful when people can temporarily turn on warnings as errors and make sure there are no deprecation warnings left. A warning that can't be solved would make that harder. -- 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
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 s in the 'somemenu' . 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
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
const char* ui =
""
" "
""
" "
"SomeThing"
"something"
" "
" "
"OtherThing"
"otherthing"
" "
""
" "
"";
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: 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
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 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 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: 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: 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 > 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::StaticPrivate::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::StaticPrivate::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::Private::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: gtk-2-24-win32 branch merged into gtk-2-24
On Tue, 2012-01-31 at 10:37 +0100, Dieter Verfaillie wrote: > On Sun, 29 Jan 2012 21:48:51 +0100, Murray Cumming wrote: > > On Thu, 2012-01-19 at 12:53 +0100, Dieter Verfaillie wrote: > >> 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. > > Yes. Alex' work was done on both gtk-2.24 and master branches, but due > to differences between the two lines of development happened at a > different > time IIUC. > > For the (smaller) bugfixes I've been doing, I make sure all of them > written > for the gtk-2-24 branch are ported -if still applicable- to master and > vice versa *before* pushing the patches, just so we don't get bug > reports > on GTK+3 for something already solved in 2.24 :) So when is something for GTK+ 3 on Windows likely to show up here: http://www.gtk.org/download/win32.php or even just here: http://ftp.gnome.org/pub/gnome/binaries/win32/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: 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: 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 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 22:18 +0200, Murray Cumming wrote: > 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 Sorry. I didn't really mean to post this to the list. Most people can ignore this. It's boring. -- 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 : > > 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
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: 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 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
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: moderation discussion
On Fri, 2011-09-09 at 17:26 +0200, Michal Suchanek wrote: > I am subscribed to quite a few mailing list and this is the first time > I saw such heavy-handed approach but it's your list and you are free > to manage it as you see fit. I'd like to see more of this kind of moderation and I trust Olav to do 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: 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 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 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 > > > 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 Sat, 2011-03-19 at 09:44 -0400, Colin Walters wrote: > Hi Murray, > > On Sat, Mar 19, 2011 at 9:11 AM, Murray Cumming 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 Sun, 2011-03-20 at 20:03 -0400, Matthias Clasen wrote: > On Fri, Mar 18, 2011 at 6:42 PM, 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. > > > > 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 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
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: 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
Re: GtkApplication and argc/arv
On Thu, 2011-03-10 at 18:41 +, Chris Vine wrote: > On Thu, 10 Mar 2011 16:47:59 +0100 > Murray Cumming 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 didn't realise you wanted examples, but most programs that have a > shared resource would fall into this category. For example, my mail > reader (claws), and most other mail readers for that matter apart from > yours, evolution, which I think is server/database based, are single > instance programs (as it happens I have seen complaints that, for any > one user, evolution should be single instance). The messaging > applications I am running, empathy and pidgin, are single instance > programs. (Skype is an example of a poorly designed one which does > start another instance but then complains about it and interferes with > itself: it would have done better to get it right by itself.) [snip] Yes, these are applications that should be single instance because that's what is obviously best for the user and it's about useless extra windows showing the same thing rather than about any user awareness of processes. 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. -- 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 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-03-10 at 14:54 +, Chris Vine wrote: > On Thu, 10 Mar 2011 14:48:12 +0100 > Murray Cumming 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 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 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-02-24 at 17:55 -0500, Colin Walters wrote: > On Thu, Feb 24, 2011 at 5:15 PM, Morten Welinder 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 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 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 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: 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. 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: 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: 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 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 Tue, 2010-10-26 at 00:28 +0200, Javier Jardón wrote: > Hello all, > > 2010/10/25 Martyn Russell : > > On 25/10/10 19:45, Murray Cumming wrote: > >> > >> On Mon, 2010-10-25 at 09:36 +0100, Martyn Russell wrote: > > >> 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 > > > > I will change the "officially gnome" part on the site unless there are any > > objections? > > > > I do not know how is the situation with the moduleset reorganization, > but I think JavaScript is a official binding as seed is already part > of the bindings moduleset [1] and gjs was accepted in the last cycle > [2] Ah, yes, Javascript (seed) was added in GNOME 2.28. Sorry. > About Vala is already a external dependency [3], but I'm not very sure > if It's enough. No, it's obviously not enough. > Regards > > [1] http://live.gnome.org/TwoPointThirtyone/Bindings > [2] http://live.gnome.org/TwoPointThirtyone/Desktop > [3] http://live.gnome.org/TwoPointNinetyone/ExternalDependencies > -- 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 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 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 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 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: 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 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 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 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: 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 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 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 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: GtkObject is gone (was GTK3 breakage)
On Tue, 2010-09-28 at 10:11 -0400, Owen Taylor wrote: > On Tue, 2010-09-28 at 09:55 +0200, Murray Cumming wrote: > > > We could just unref the underlying object, but once the wrapping C++ > > object has been destroyed, the vfuncs (and default signal handlers) will > > fall back to default C implementations, if any, and this could even > > cause different UI behaviour. > > > > If I must, then I'll force Gtk::CellRenderer and Gtk::TreeViewColumn to > > be used only via RefPtr<>, like other reference-counted objects, but > > this will probably just annoy C++ programmers. They feel like widgets, > > so it seems odd for them to not have similar memory management. > > g_object_run_dispose() is very similar to gtk_widget_destroy() in terms > of memory management semantics. Yes, after talking on irc we came to the same conclusion. > The main difference is that there's no ::destroy signal emitted. For some reason we use a qdata destroy callback to detect GObject destruction anyway, instead of the "destroy" signal. -- 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
GtkObject is gone (was GTK3 breakage)
On Sun, 2010-09-26 at 16:08 +0200, Benjamin Otte wrote: > - GtkObject is gone > With the existance of GObject, GtkObject became unnecessary. The > functions it provided are now either part of GObject or GtkWidget. For gtkmm, I welcome this for the little GtkAdjustment, GtkFileFilter and GtkRecentFilter objects. Now they are simple reference-counted objects. But for some other more commonly-used objects (GtkWidgets, GtkCellRenderer, GtkTreeViewColumn), I'd like to avoid changing our memory management too much. Is there no way now to force an object to be destroyed? Right now, we let our GtkWidgets be destroyed when their C++ wrappers go out of scope automatically. For instance, when a C++ class's destructor automatically destroys its member instances, like so: http://library.gnome.org/devel/gtkmm-tutorial/unstable/sec-helloworld.html.en Our GtkWidget classes should be OK, because we can use gtk_widget_destroy() instead of gtk_object_destroy. But I wonder what to do with GtkCellRenderer and GtkTreeViewColumn. We could just unref the underlying object, but once the wrapping C++ object has been destroyed, the vfuncs (and default signal handlers) will fall back to default C implementations, if any, and this could even cause different UI behaviour. If I must, then I'll force Gtk::CellRenderer and Gtk::TreeViewColumn to be used only via RefPtr<>, like other reference-counted objects, but this will probably just annoy C++ programmers. They feel like widgets, so it seems odd for them to not have similar memory management. -- 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: padding cleanup
I haven't followed this in detail, but I see the new GtkWidget align and margin-* properties and functions: http://git.gnome.org/browse/gtk +/commit/?id=474f80442a6f3cf72a3c3b9efc5a846e7664d758 So will things like gtk_alignment_set() be deprecated soon? http://library.gnome.org/devel/gtk/unstable/GtkAlignment.html#gtk-alignment-set -- 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: Wrapping Box Container
On Mon, 2010-08-30 at 18:20 -0400, Behdad Esfahbod wrote: > On 08/24/10 13:42, Tristan Van Berkom wrote: > > Is this a kind of widget that we are interested in adding to GTK+ ? > > What are the usecases for such a container? The selection of features looks a > bit arbitrary to me. I wanted it for Glom, which has vertical columns of widgets, flowing the widgets into the next column, like text in newspaper columns: http://www.glom.org/wiki/index.php?title=File:Small_glom_data_details.png Glom currently uses an awful buggy hacky C++ widget that I wrote, but GtkWrapBox should work properly. Gimp apparently has something similar, maybe for its tool pallete or tool preference windows: http://developer.gimp.org/api/2.0/app/GtkWrapBox.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
What replaces gdk_bitmap_create_from_data() ?
I'm trying to fix the gtkmm 3 build against gtk+ 3 from git master. gdk_bitmap_create_from_data() has been removed but it's not yet deprecated in the gtk-2-22 branch, so I can't read about what replaces it. I see no other simple way to create a GdkBitmap. Is GdkBitmap meant to be removed completely? There are still functions in git master that take it as a 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: Minutes of the gtk+ team IRC meeting - 2010-05-25
On Mon, 2010-05-31 at 12:08 +0200, Kristian Rietveld wrote: > > - GtkRuler (used by dia, claws, possibly xsane; gimp has a fork) > > Is this really only used by dia and claws, or also some more > applications? In contrast to GtkHSV, GtkGamma, etc., I can actually > imagine that GtkRuler has some proper use cases in a variety of > applications ;) I use it in Glom, in UI for designing print layouts. I would rather not maintain a fork of the 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: Scrollable interface for 3.0?
On Mon, 2010-05-17 at 15:07 -0500, Shaun McCance wrote: > http://library.gnome.org/devel/gtk/stable/GtkScrolledWindow.html#ftn.id1043260 > > The scrolled window installs GtkAdjustment objects in the child > window's slots using the set_scroll_adjustments_signal, found > in GtkWidgetClass. (Conceptually, these widgets implement a > "Scrollable" interface; because GTK+ 1.2 lacked interface support > in the object system, this interface is hackily implemented as a > signal in GtkWidgetClass. The GTK+ 2.0 object system would allow > a clean implementation, but it wasn't worth breaking the API.) > > Is this worth breaking API for in 3.0? Jan Arne Petersen's old patch here is probably helpful if it is wanted: https://bugzilla.gnome.org/show_bug.cgi?id=468689 -- 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+ IRC team meeting - 2010-05-04
On Tue, 2010-05-04 at 23:19 +0100, Emmanuele Bassi wrote: > • gtk-2-90 branch and gtk+ 2.90 release > - merge gtk-2-90 into master as soon as: > a) we have stable branches > b) gtk-2-90 works > - we have a), and close on b) I am confused. Will there be a GTK+ 2.22? If so, what git branch is aiming for that? Is GTK+ 2.90 meant to become GTK+ 3.0? -- 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: Extended Layout
On Thu, 2010-04-15 at 15:18 -0400, Owen Taylor wrote: > I meant that 'height-for-width' is useful, and > 'width-for-height' is a bit of gravy on top. > > That is, "the behavior of text" is useful, the opposite behavior less > useful. Tristan, so can you make things easier by cutting out that feature, while still fixing the UI bugs that we think need extended-layout? -- 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: When deprecating, always say what the replacement is.
On Thu, 2010-02-25 at 16:52 +0100, Christian Dywan wrote: > > But "Do not use it" does not even make that clear. The reader has no > > idea whether it is something that should never have been used (and > why > > not) or something that has a replacement. It shouldn't take much > > empathy to realize that, or to realize that documentation _must_ > have > > a problem if someone says it's unclear. We can do better. > > The few "Don't use it" comments in GTK+ usually indicate that it is > questionable why someone would try to use a function in the first > place. > > In this case I don't know what someone would use flags for. If you > need > to test a value such as visibility or sensitivity, you normally use > the > specific macros. As far as I'm aware at least. > > Can you give an example? Then I'd say pointing that out certainly > can't > hurt. I don't use this API. I have no idea. I'm not asking why this API is deprecated. I'm asking for it to be properly documented because it should be properly documented. And I want this to stop happening. I see deprecations while updating gtkmm even when I have no great interest in the particular function. I don't want to carry over this obviously bad documentation to gtkmm. If it should never have been used then say so. Try to give some idea about why it should never have been used. Don't make people guess. But I'm repeating myself. -- 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: When deprecating, always say what the replacement is.
On Tue, 2010-02-23 at 22:36 +0100, Michael Natterer wrote: > On Tue, 2010-02-23 at 19:59 +0100, Murray Cumming wrote: > > No, "Deprecated: 2.20: Do not use it." is not good enough. > > As a matter of fact, it is. There is not supposed to be any > replacement for the stuff that says "Do not use it". Everything > that has a replacement is however documented. But "Do not use it" does not even make that clear. The reader has no idea whether it is something that should never have been used (and why not) or something that has a replacement. It shouldn't take much empathy to realize that, or to realize that documentation _must_ have a problem if someone says it's unclear. We can do better. -- 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
