Re: Stock Items Deprecation
To answer myself; Gtk+3.10 and above cannot have icons and buttons in menus unless opted in explicitly by the app author. it seems this removal was noticed by someone else https://lists.ubuntu.com/archives/ubuntu-desktop/2013-October/004311.html https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1228886 Ubuntu LTS will stay with Gtk+ 3.8 Make of that what you will. John On Thu, Jul 18, 2013 at 12:17 PM, John Stowers john.stowers.li...@gmail.com wrote: Hi, How does this intersect with the (also deprecated AIUI) GtkSettings variables gtk-button-images and gtk-menu-images? Will those settings be honored through the Gtk+-3 series? John 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. Thanks, Jon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ 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 eba...@gmail.com: support for those features has already been developed and it is going to be added to GAction before we release GLib 2.38 and GTK 3.10, and improved in the future so that it matches with the overall spirit and design of the API. if you want to influence where the API is going, you can start looking at how to port your code, what you think it's missing, and file bugs. dropping on irc.gnome.org, in the #gtk+ channel, is also a good idea. OK, I guess that answers my question. This was about your comment: GAction has no functionality for accelerators, icons, or automatically creating widgets. These are very useful in applications which reuse the same action in more than one place (e.g. in a menu and on a toolbar). How are we supposed to replace it in new code? I've noticed that there is support now in the GtkBuilder GMenu XML (and probably therefore in GMenuModel) for: * accelerators by using, for instance: attribute name='accel'lt;controlgt;F/attribute * icons by using, for instance: attribute name=icon/usr/share/my-app/something.png/attribute This seems to be (wiki) documentation for them: https://wiki.gnome.org/HowDoI/GMenu https://wiki.gnome.org/GApplication/GMenuModel I don't see a way to specify these for the action in general rather than just for the particular use of the action in a menu item or tool button. And I have not found a way to specify a tooltip for a menu item with GMenu/GAction/GtkBuilder, as an equivalent for the tooltip parameter to gtk_action_new(): https://developer.gnome.org/gtk3/unstable/GtkAction.html#gtk-action-new -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
hi; On 13 September 2013 03:10, Matthew Brush mbr...@codebrainz.ca wrote: 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. Do you mind if I simply ask why are you asking for feeback? can't really talk for Jon, but I think it's obvious why: you can only get feedback once you do something, and find issues when people start porting their code, not before. as a rule, people don't port their code until it's strictly necessary, so doing thought experiments and getting feedback prior to actually deprecating API yields either skewed, or no results. luckily, we have GTK under revision control, so if we need to do so, we can revert commits — which is something that happened multiple times in the past (even in this cycle). it's also obvious that somebody's mind has been made: that's how things get started, developed, and committed. it doesn't mean that opinions can't change, though; it's still possible to convince to revert, or to defer to a later cycle. we can even undeprecate in another cycle. it helps if you don't automatically assume that people working on GTK are stubborn or simply don't care. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
On 13-09-13 02:29 AM, Emmanuele Bassi wrote: hi; On 13 September 2013 03:10, Matthew Brush mbr...@codebrainz.ca wrote: 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. Do you mind if I simply ask why are you asking for feeback? can't really talk for Jon, but I think it's obvious why: you can only get feedback once you do something, and find issues when people start porting their code, not before. as a rule, people don't port their code until it's strictly necessary, so doing thought experiments and getting feedback prior to actually deprecating API yields either skewed, or no results. luckily, we have GTK under revision control, so if we need to do so, we can revert commits — which is something that happened multiple times in the past (even in this cycle). it's also obvious that somebody's mind has been made: that's how things get started, developed, and committed. it doesn't mean that opinions can't change, though; it's still possible to convince to revert, or to defer to a later cycle. we can even undeprecate in another cycle. it helps if you don't automatically assume that people working on GTK are stubborn or simply don't care. I certainly don't assume that automatically, but when massive deprecations are made presumably without any prior discussion (at least on any public GTK+ channels), and then feedback is asked for and a number of important issues are raised and nothing is done about it, or even responding to some of the issues, just ignoring the thread for 2 months now ... what can be assumed? It's just frustrating trying to contribute to GTK+, or even to just code apps against it, when this stuff happens. Cheers, Matthew Brush ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
hi; On 13 September 2013 11:33, Matthew Brush mbr...@codebrainz.ca wrote: I certainly don't assume that automatically, but when massive deprecations are made presumably without any prior discussion (at least on any public GTK+ channels) discussions these days tend to happen on high bandwidth channels (hackfest, conferences, public IRC channels), because mailing lists have proven, time and again, to be poor venues of communication, especially when it comes to time-sensitive development. all invested parties should really consider joining the #gtk+ IRC channel, if you're not there already. and then feedback is asked for and a number of important issues are raised and nothing is done about it, or even responding to some of the issues, just ignoring the thread for 2 months now ... what can be assumed? the thread is not ignored — it just happened to be between GUADEC and a bunch of people going on holiday. it's still routinely discussed on IRC, for instance. Murray has been very good at filing bugs. if there are *concrete* issues in porting code from the stock system to the named icons, or from GtkAction/GtkUIManager to GAction/GtkBuilder, then filing bugs with *actionable items* is the quickest way to get feedback. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
On 13-07-02 06:41 AM, 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. Do you mind if I simply ask why are you asking for feeback? Since you did a whole pile ( 25) deprecations before you asked, and have obviously made up your mind before discussing on IRC or on the mailing list here, where normal people could find the conversation, I'm simply asking what is the purpose of you asking this question? Will it change the mass-deprecations? Cheers, Matthew Brush ___ 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: Stock Items Deprecation
hi; On 11 September 2013 11:39, Murray Cumming murr...@murrayc.com 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. 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. also, the fact that GTK never really adhered to the API freeze in the first place, and that depending on the latest stable GTK release puts you at the whims of the distribution channel, kinda makes this target highly problematic. covering all major use cases of a deprecated API before actually deprecating it is a good guideline, but it should not be an absolute requirement. the deprecated API is still there, and porting can happen at different stages. as a relevant example: GtkRecentAction was introduced in a later cycle than the rest of the GtkRecent* API, and yet the EggRecent* API was deprecated long before that happened. please, note that I'm neither advocating to keep the deprecation of GtkUIManager/GtkAction, nor to revert it — I don't have any horse in this race. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
2013/9/11 Emmanuele Bassi eba...@gmail.com: 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. The recently used files thing in the open dialog is utterly confusing. It looks exactly like a directory listing, but the shown files and directories are not actually in a single directory. The first few times I encountered it, I thought there was some filesystem disaster that mixed all my files together. Maybe if the display was changed so that it did not resemble a directory listing so much, it would be less confusing; but for now I find this feature unusable. Regards, Krzysztof ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
On 07/17/13 12:21, Emmanuele Bassi wrote: hi; On 17 July 2013 11:01, Jean Brefort jean.bref...@normalesup.org wrote: Le mercredi 17 juillet 2013 à 11:47 +0200, Murray Cumming a écrit : 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). for GtkUIManager we already have a replacement that covers about 95% of the use cases: GtkBuilder. GAction replaces GtkAction; images on menus have been discouraged for years, and the whole menu system has been replaced by GMenu XML descriptions that can be exported on the session bus. named icons have been replacing stock items for years; API is available both in GTK (GtkIconTheme) and in GIO (GIcon, GThemedIcon, etc.). So since this started I've been looking at not using stock items anymore, and have been using GtkIconTheme instead[1]. However, one thing stock items also did that seems to be missing now (unless I'm missing something, which is possible), is handle different sort of rendering based on widget states, e.g. when disabled/not sensitive, the icon would reflect that automatically. How should this be handled now? If one doesn't use stock items, but wants to use icons in a menu (or button), and have the icon shown as disabled when the widget isn't sensitive, what's the recommended way to do it ? Thanks. [1] Specifically, using gtk_icon_theme_load_icon() to get a GdkPixbuf. All these? And what replace them? you should have read the thread and the document linked at the start of it. Should I just stop using gtk+ for development? I have not so much available time and rewriting code using deprecated classes should not use it all. I clearly prefer spend time on new code, or fixing bugs. you can still use deprecated classes until we break GTK for 4.0. deprecation does not mean removal, it just means that the deprecated API should not (should not, not must not) be used in newly written code. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ 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, Aug 20, 2013 at 03:01:25PM +0100, Patrick Welche wrote: On Tue, Jul 02, 2013 at 10:44:13AM -0400, Matthias Clasen wrote: On Tue, Jul 2, 2013 at 10:29 AM, Tristan Van Berkom t...@gnome.org wrote: Besides what Bastian already points out, I have another concern if we are to consider moving away from stock items completely. The document above points to this list of icon names: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html#names What guarantees do we have that referring to an icon name in the icon naming spec will actually produce an icon ? GTK+ ships with a built-in icon theme that covers the named icons used by the stock system (not all listed in the naming spec). Since gcalctool moved away from stock icons (f962134f66), I can't tell the difference between undo and clear - both appear as the icon not found icon, which causes a problem with usability. If there is an automatic fallback mechanism, I don't see how it is working, and 1. Provided a guaranteed, consistent, and high quality set of icons for use in applications. seems to have evaporated. From http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html Implementations are required to look in the hicolor theme if an icon was not found in the current theme. Which suggests that there should be a fallback mechanism, but given the gcalctool example, it doesn't seem to be implemented? Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
Hi all. I agree with Matthew Brush and others. I developed some GTK+ applications and I used a lot of stock items, practically for all buttons. I can't realize why to change this. Maybe I miss something good reasons or argumentation. Regards, José Paulo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
On 8/21/13, Jose Paulo pa...@sistemasolar.com.br wrote: I agree with Matthew Brush and others. I developed some GTK+ applications and I used a lot of stock items, practically for all buttons. I can't realize why to change this. Maybe I miss something good reasons or argumentation. This sounds like classic Factory pattern. Perhaps a static factory fn could be created, which provides for an easier transition (ie an easy way to sed the old code to use a standard factory function)? I'd say the movement towards standardization across desktops is a good thing. Factory methods for standard stock items are common in Java (from memory). Just my 2c. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
I believe that this is exactly what GtkIconFactory is there for, it allows you to define named icons for various widget states including RTL/LTR. Thankfully GtkIconFactory != stock icons... but unfortunately it looks as though a deprecation of GtkIconFactory snuck in with the stock icon deprecation (presumably under the guise that the two are somehow related). Ok, sorry for venting my frustration, but is there really any justification for this additional deprecation of a useful feature ? It's also frustrating that GtkIconFactory is silently removed, after not even receiving any reply on the topic, which was discussed only a month or two ago: https://mail.gnome.org/archives/gtk-devel-list/2013-May/msg00063.html Is it too late to reverse this deprecation for 3.10 ? Cheers, -Tristan On Thu, Jul 25, 2013 at 11:37 AM, phil p...@philandanna.no-ip.org wrote: On 02/07/13 14:41, 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. The document doesn't mention anything about stock icons with rtl variants. I just changed some code from using the stock-id property of a GtkCellRendererPixbuf to icon-name and I only see the ltr versions of the media-playback-start icon on a rtl locale. Is it now the applications responsibility to take care of this by changing the icon name or is it just a bug? If it is now up to the application then I think that is (a) not a good idea as people will forget to do it and (b) it also needs a prominent mention in the migration guide. As others have mentioned it is unfortunate eliminating the #defines for stock items also eliminates all compile-time checks for valid icon names makes errors in common menu items more likely. One other thing, I'm wondering why the migration guide and rationale are on goggle docs which tracks who is viewing what and which links they click on in the documents. It seems a bit incongruous as GNOME is currently fund raising for privacy enhancements and has it's own wiki. Best Wishes Phillip Wood ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ 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, Jul 02, 2013 at 10:44:13AM -0400, Matthias Clasen wrote: On Tue, Jul 2, 2013 at 10:29 AM, Tristan Van Berkom t...@gnome.org wrote: Besides what Bastian already points out, I have another concern if we are to consider moving away from stock items completely. The document above points to this list of icon names: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html#names What guarantees do we have that referring to an icon name in the icon naming spec will actually produce an icon ? GTK+ ships with a built-in icon theme that covers the named icons used by the stock system (not all listed in the naming spec). Since gcalctool moved away from stock icons (f962134f66), I can't tell the difference between undo and clear - both appear as the icon not found icon, which causes a problem with usability. If there is an automatic fallback mechanism, I don't see how it is working, and 1. Provided a guaranteed, consistent, and high quality set of icons for use in applications. seems to have evaporated. Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
On 13-07-02 06:41 AM, 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. Hi, I try not to pipe-up here too often, but since you asked :) This seems like a whole lot of disruption to many existing GTK+ applications, the only decent GUI designer, and a highly used part of GTK+ in applications in the wild (that seems to work quite nice IME) for very little, if any, gain. I work on several GTK+ projects who's code is *littered* with stock icon usage - because their so easy to use and understand, and it would suck having to go through all the busy work of updating[1] all their uses for what seems to be little/no gain. Also pointed out already in this thread has several problems in practice. Also, in the linked Word file, it says Since GTK+ 3.0 we have recommended against using Stock Items and gives the reference to the migration checklist, where it doesn't say that at all, it just says use named icons, which to me reads as rather than using your own hard-coded/provided icons, not don't use stock icons, although maybe I misunderstood it - it's not very detailed. Also in the terse migration checklist page linked, it talks about automatically adapt to theme changes and much more integrated experience but - if it is comparing against stock icons and not other hard-coded non-stock icons as mentioned above - I've always found stock icons to make apps *very* consistent and they've always not only used my chosen icon theme but also update themselves correctly at runtime when I change my icon theme (and on platforms where I don't have/use icon themes they always seems to just work). Lastly, in the Word file linked, the only rational in So what's the benefit? is that no matter what, stock icons will be deprecated (paraphrasing) ... which if true, makes me wonder what is the purpose of this thread asking for people's opinions about the deprecation? It almost sounds like circular reasoning. P.S. Sorry if I missed some huge master plan document and/or detailed rational about stock icons are bad, I'm just going on the context given in this thread and linked document. Cheers, Matthew Brush [1] Yes, I'm aware deprecation doesn't mean removal, but it means eventual removal in the next major version, and having your build give tons of compiler errors/warnings about deprecated uses if you enable deprecation checking in order to find other deprecated stuff. And even without that, it's just good style not to use deprecated stuff, IMO. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
On 13-08-20 06:59 PM, Matthew Brush wrote: On 13-07-02 06:41 AM, 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. Hi, I try not to pipe-up here too often, but since you asked :) And here I am again, sorry for noise. [TLDR;...] Actually I should sum up my last email more constructively as: Having a constant to a stock item is quite useful, despite the reasons outlined in your document, because stock items provide a compiler-checked name/identifier to a consistent, internationalized, mnemonic-ized label and (ideally) semantic icon from GTK+ rather than pushing that magic (ie. work) into the individual applications. Even like: ... #define GTK_STDITEM_SAVE ? ... GtkButton *b = gtk_button_new_from_stditem(GTK_STDITEM_SAVE); ... Not all GTK+-using applications prescribe strictly to GNOME's human interface guidelines but most applications share semantics like Open and Save and Close and so on. IMO, the general idea behind stock items/icons is still a good one. Sorry again for noise and less-than-constructive previous email :) Cheers, Matthew Brush ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
On Thu, Jul 18, 2013 at 12:17 PM, John Stowers john.stowers.li...@gmail.com wrote: Hi, How does this intersect with the (also deprecated AIUI) GtkSettings variables gtk-button-images and gtk-menu-images? Will those settings be honored through the Gtk+-3 series? Hi, So this wasn't really answered, and now I am wondering what to do with the switch that controls this gsetting in gnome-tweak-tool. John John 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. Thanks, Jon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
Dear, I have a question about this sentence : The guidance since before GTK+ 3.0 was for buttons to be text labels only or icon images only. I always design my applications based on the GNOME Human Interface Guidelines and I never read something like this. Plus, in this guide, all screenshoots show button with text label and icon. Do this guide needs an update ? If I replace all gtk_button_new_from_stock by gtk_button_new_with_mnemonic then by default every button will not have an icon. So does the gnome-tweak-tool's option Buttons Have Icons will disappear and the answer will always be no ? Thanks, Vincent LE GARREC 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. Thanks, Jon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
hi; On 13 August 2013 08:14, LE GARREC Vincent legarrec.vinc...@gmail.com wrote: I have a question about this sentence : The guidance since before GTK+ 3.0 was for buttons to be text labels only or icon images only. I always design my applications based on the GNOME Human Interface Guidelines and I never read something like this. Plus, in this guide, all screenshoots show button with text label and icon. Do this guide needs an update ? yes, it does need to be updated. the next revision of the HIG is a work in progress, and it's currently being tracked on the wiki: https://wiki.gnome.org/Design/HIG in general, even during the last release cycles of the 2.x series, the default for both icons in menus and icons in buttons has been off by default. If I replace all gtk_button_new_from_stock by gtk_button_new_with_mnemonic then by default every button will not have an icon. So does the gnome-tweak-tool's option Buttons Have Icons will disappear and the answer will always be no ? a general turn on icons for buttons and menus toggle is already moderately nonsensical: unless everybody packs an icon in every button/menu items, and accepts that icons can appear and disappear at random, then there is no actual way to implement such toggle. whether or not to add an icon in buttons and menu items is left to the application developer's responsibility or to the application designer's guidelines. for GNOME applications, buttons should have text describing the action taken when pressing them (similarly to what the HIG for GNOME 2.0 already specified), and menus should only have icons for nouns, not for verbs. ciao, Emmanuele. 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. Thanks, Jon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
Thanks for the advice. I'll take a good look at the given URL and modify my apps accordingly. 2013/8/13 Emmanuele Bassi eba...@gmail.com hi; On 13 August 2013 08:14, LE GARREC Vincent legarrec.vinc...@gmail.com wrote: I have a question about this sentence : The guidance since before GTK+ 3.0 was for buttons to be text labels only or icon images only. I always design my applications based on the GNOME Human Interface Guidelines and I never read something like this. Plus, in this guide, all screenshoots show button with text label and icon. Do this guide needs an update ? yes, it does need to be updated. the next revision of the HIG is a work in progress, and it's currently being tracked on the wiki: https://wiki.gnome.org/Design/HIG in general, even during the last release cycles of the 2.x series, the default for both icons in menus and icons in buttons has been off by default. If I replace all gtk_button_new_from_stock by gtk_button_new_with_mnemonic then by default every button will not have an icon. So does the gnome-tweak-tool's option Buttons Have Icons will disappear and the answer will always be no ? a general turn on icons for buttons and menus toggle is already moderately nonsensical: unless everybody packs an icon in every button/menu items, and accepts that icons can appear and disappear at random, then there is no actual way to implement such toggle. whether or not to add an icon in buttons and menu items is left to the application developer's responsibility or to the application designer's guidelines. for GNOME applications, buttons should have text describing the action taken when pressing them (similarly to what the HIG for GNOME 2.0 already specified), and menus should only have icons for nouns, not for verbs. ciao, Emmanuele. 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. Thanks, Jon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
On 02/07/13 14:41, 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. The document doesn't mention anything about stock icons with rtl variants. I just changed some code from using the stock-id property of a GtkCellRendererPixbuf to icon-name and I only see the ltr versions of the media-playback-start icon on a rtl locale. Is it now the applications responsibility to take care of this by changing the icon name or is it just a bug? If it is now up to the application then I think that is (a) not a good idea as people will forget to do it and (b) it also needs a prominent mention in the migration guide. As others have mentioned it is unfortunate eliminating the #defines for stock items also eliminates all compile-time checks for valid icon names makes errors in common menu items more likely. One other thing, I'm wondering why the migration guide and rationale are on goggle docs which tracks who is viewing what and which links they click on in the documents. It seems a bit incongruous as GNOME is currently fund raising for privacy enhancements and has it's own wiki. Best Wishes Phillip Wood ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
hi; On 25 July 2013 10:37, phil p...@philandanna.no-ip.org wrote: One other thing, I'm wondering why the migration guide and rationale are on goggle docs which tracks who is viewing what and which links they click on in the documents. It seems a bit incongruous as GNOME is currently fund raising for privacy enhancements and has it's own wiki. pretty sure Jon used google docs because it was convenient for him; no need to ascribe ulterior motives to him, gtk developers, or GNOME as a whole. the documentation is in the process of being moved inside the GTK+ API reference. as a side note: wikis are not great for collaborative editing, and setting up the ACLs are pretty awful. we do have etherpad on gnome.org, but I'd have to check the ACLs there as well. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
On 25/07/13 11:08, Emmanuele Bassi wrote: Hi Emmanuele On 25 July 2013 10:37, phil p...@philandanna.no-ip.org wrote: One other thing, I'm wondering why the migration guide and rationale are on goggle docs which tracks who is viewing what and which links they click on in the documents. It seems a bit incongruous as GNOME is currently fund raising for privacy enhancements and has it's own wiki. pretty sure Jon used google docs because it was convenient for him; no need to ascribe ulterior motives to him, gtk developers, or GNOME as a whole. I wasn't trying to ascribe ulterior motives I'm sorry if it came across that way. I just wanted to highlight the contradiction in the hope that in future people would consider using solutions more in line with GNOME's goals and values (where they exist). It's sad that there is not a convenient alternative that preserves people's privacy and software freedom :-( the documentation is in the process of being moved inside the GTK+ API reference. That's great, leaving aside privacy and freedom. it's good to have a permanent record of these things. as a side note: wikis are not great for collaborative editing, and setting up the ACLs are pretty awful. we do have etherpad on gnome.org, but I'd have to check the ACLs there as well. I didn't realise it was such a pain to use the wiki when you want to restrict who can edit the page. Sorry if I offended anyone, I'm a fan of what GNOME stands for so would definitely not want to do that. Best Wishes Phil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
On Tue, 2013-07-02 at 10:56 -0400, William Jon McCann wrote: The problems of consistency between applications is a valid one and may be addressed the way we address other consistency issues, with documentation and clear guidelines . We already have the Stock Items Migration Guide That's a Google Docs document, which is a little odd. and I expect some of this will migrate into the GTK+ documentation Is anybody working on that. It seems to be an essential resource for translators to ensure that we will in future have some consistency, though I suspect that many translators will just not specify any mnemonics at all. I also doubt that most translators will take the time to consider the mnemonics for the whole application to avoid clashes. I guess we would need tools to help them with that. and platform HIG soon. Surely you wouldn't want to duplicate that list. -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
On Tue, 2013-07-02 at 09:41 -0400, William Jon McCann wrote: Hi, As some of you may have noticed we have recently deprecated Stock Items in master. Some details on this change may be found here: https://docs.google.com/document/d/1KCVPoYQBqMbDP11tHPpjW6uaEHrvLUmcDPqKAppCY8o/pub That links to this, which I find a little vague: https://developer.gnome.org/gtk3/stable/checklist-named-icons.html If we can't change the existing IDs such as https://developer.gnome.org/gtk3/unstable/gtk3-Stock-Items.html#GTK-STOCK-DIALOG-ERROR:CAPS to use the standard icon names such as dialog-error, wouldn't it still be useful to have some new macros for the standard icon names, to avoid typos? Otherwise, the compiler can't help us to know if a standard icon name is really a standard icon name. -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
2013/7/18 Emmanuele Bassi eba...@gmail.com: support for those features has already been developed and it is going to be added to GAction before we release GLib 2.38 and GTK 3.10, and improved in the future so that it matches with the overall spirit and design of the API. if you want to influence where the API is going, you can start looking at how to port your code, what you think it's missing, and file bugs. dropping on irc.gnome.org, in the #gtk+ channel, is also a good idea. OK, I guess that answers my question. you should *really* read the document linked in Jon's email; it answers the questions about when and where icons should be used inside menus. it's not a blanket removal (and it's not something done to emulate OSX; please, refrain from making snap judgements in the future). I read the document before posting, and it did mention that icons are OK for noun menu items. However, in your initial post you said GAction replaces GtkAction; images on menus have been discouraged for years...', and I was not aware that a replacement for the presentation-related functionality of GtkAction will be added to GAction - so this sounded like the ability to add icons to menu items would be removed completely. Regards, Krzysztof ___ 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
hi; On 18 July 2013 04:59, Matthew Brush mbr...@codebrainz.ca wrote: Should I just stop using gtk+ for development? I have not so much available time and rewriting code using deprecated classes should not use it all. I clearly prefer spend time on new code, or fixing bugs. you can still use deprecated classes until we break GTK for 4.0. deprecation does not mean removal, it just means that the deprecated API should not (should not, not must not) be used in newly written code. To be fair, it may not mean immediate removal but it does mean slated for removal, which to a developer effectively means you need to re-write all your code using it (sooner or later), which is I think pretty much what Jean was griping about. it's the griping that I don't understand. it's not like the deprecation policy of gtk is new: it's been the same for the past 15 years. it's the same policy used *everywhere*. removal can *only* happen when we bump major version, which will require porting anyway and it's not something that will happen any time soon; and even if it does, the older API series won't be magically removed from the Git repository. people are still using gtk2 even if we released gtk 3.0 almost 3 years ago. I've seen people on gtk-list ask about issues with gtk 1.x. nobody was using gtk 0.x except GIMP, hence why nobody is asking about that. seriously: API deprecated in the 3.x API series will continue to work for the duration of the 3.x API series. that's why we *deprecate* instead of removing and bumping the API. deprecations are informative, not normative; we *cannot* force anybody to migrate to the new API. we can hint that the deprecated code is not going to be touched any more except for bug fixing, and that if you want new features, then you should ask them for the new API. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
hi; On 18 July 2013 03:55, Krzysztof Kosiński tweenk...@gmail.com wrote: 2013/7/17 Emmanuele Bassi eba...@gmail.com: GAction replaces GtkAction; images on menus have been discouraged for years, and the whole menu system has been replaced by GMenu XML descriptions that can be exported on the session bus. 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? 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. Removing icons from menus seems like a pointless attempt to emulate OS X. There are places where menu icons do make sense. you should *really* read the document linked in Jon's email; it answers the questions about when and where icons should be used inside menus. it's not a blanket removal (and it's not something done to emulate OSX; please, refrain from making snap judgements in the future). ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
Hi, How does this intersect with the (also deprecated AIUI) GtkSettings variables gtk-button-images and gtk-menu-images? Will those settings be honored through the Gtk+-3 series? John 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. Thanks, Jon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
On Tue, 2013-07-02 at 09:41 -0400, William Jon McCann wrote: Hi, As some of you may have noticed we have recently deprecated Stock Items in master. Some details on this change may be found here: https://docs.google.com/document/d/1KCVPoYQBqMbDP11tHPpjW6uaEHrvLUmcDPqKAppCY8o/pub Please let us know what you think. This deprecated several classes (GtkIconFactory, GtkIconSet, GtkIconSource, GtkImageMenuItem, GtkAction, GtkUIManager). But their overview documentation does not mention that the whole API is deprecated. And the deprecation comments for the individual methods just say that they are deprecated without any further advice. For instance: https://developer.gnome.org/gtk3/unstable/GtkUIManager.html#gtk-ui-manager-new -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
Le mercredi 17 juillet 2013 à 11:47 +0200, Murray Cumming a écrit : 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). All these? And what replace them? Should I just stop using gtk+ for development? I have not so much available time and rewriting code using deprecated classes should not use it all. I clearly prefer spend time on new code, or fixing bugs. Regards, Jean 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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
hi; On 17 July 2013 11:01, Jean Brefort jean.bref...@normalesup.org wrote: Le mercredi 17 juillet 2013 à 11:47 +0200, Murray Cumming a écrit : 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). for GtkUIManager we already have a replacement that covers about 95% of the use cases: GtkBuilder. GAction replaces GtkAction; images on menus have been discouraged for years, and the whole menu system has been replaced by GMenu XML descriptions that can be exported on the session bus. named icons have been replacing stock items for years; API is available both in GTK (GtkIconTheme) and in GIO (GIcon, GThemedIcon, etc.). All these? And what replace them? you should have read the thread and the document linked at the start of it. Should I just stop using gtk+ for development? I have not so much available time and rewriting code using deprecated classes should not use it all. I clearly prefer spend time on new code, or fixing bugs. you can still use deprecated classes until we break GTK for 4.0. deprecation does not mean removal, it just means that the deprecated API should not (should not, not must not) be used in newly written code. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
hi Murray; On 17 July 2013 10:47, Murray Cumming murr...@murrayc.com wrote: On Tue, 2013-07-02 at 09:41 -0400, William Jon McCann wrote: 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 I'm sure documentation patches are welcome; I'll gladly review them. 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. for GtkIcon* API, the replacement has been named theme icons, and has been so for a while. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ 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
Hi On 2013-07-17 11:23, Emmanuele Bassi eba...@gmail.com wrote: I'm sure documentation patches are welcome; I'll gladly review them. I filed a bug about the GtkAction deprecation notices, with a patch: https://bugzilla.gnome.org/show_bug.cgi?id=704392 It probably needs someone who is more intimately involved with GAction and the associated machinery than I am to review it. It would also be good to copy some information to: https://wiki.gnome.org/HowDoI/GAction Does there need to be a migration guide, like the GTK+ 2 to 3 guide that is in the API reference, or should that go on the wiki too? -- http://amigadave.com/ signature.asc Description: Digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
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. Specifically, how does one create menus like Firefox's History and Bookmarks menus which have dynamic contents? Or gedit's Documents menu? Morten ___ 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 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. The problem I see with this is that some of those classes (GSimpleActionGroup for example) will have to implement GtkBuildable which can not be done because its on another library. So maybe it is time to move GtkBuilder to GLib I guess we could rename GtkBuilder to GBuilder and move it to glib. I am not sure if we can maintain ABI by making a new GtkBuilder class derive from GBuilder. In any case we would also deprecate GtkBuilder. so its a lot of work, and that is why Glade still does not support GAction :( cheers JP ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Stock Items Deprecation
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. Thanks, Jon ___ 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. The biggest loss is the need to re-translate, usually with consistency about the mnemonic used, things such as _About, _Save, etc. Cheers ___ 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, Jul 2, 2013 at 10:41 PM, William Jon McCann william.jon.mcc...@gmail.com 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. Besides what Bastian already points out, I have another concern if we are to consider moving away from stock items completely. The document above points to this list of icon names: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html#names What guarantees do we have that referring to an icon name in the icon naming spec will actually produce an icon ? Will GTK+ have a dependency on an installed icon theme which conforms to the basic spec ? (can GTK+'s configure script verify that there is a *complete* set of icons installed and bail out if it's not the case ?). When you refer to a stock icon, you know that if you installed GTK+ on a given system, the icon will be there, period, if it's not overridden by an icon theme, there is always a default icon. Having constant definitions of available stock items is also a nice thing to have i.e. referring to GTK_STOCK_BUMBLEBEE produces a compiler error, refering to gtk-stock-bumblebee will happily compile and leave you wondering if: a.) Did I misspell bumblebee ? b.) Is bumblebee really an icon name ? c.) Did I use the wrong Icon Theme, which failed to install a bumblebee icon ? d.) Was I so ignorant to use an icon name which was only supported by the Icon Theme that existed in my GNOME desktop environment ? Should I have known better that bumblebee would not exist in other environments, like the embedded device I just setup ? I'm not really against moving away from the stock items, but I think that it's important to be able to guarantee which icon names will be provided for *any* installation of GTK+, even if this is a small list of guaranteed icons. Cheers, -Tristan Thanks, Jon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ 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, Jul 2, 2013 at 10:29 AM, Tristan Van Berkom t...@gnome.org wrote: Besides what Bastian already points out, I have another concern if we are to consider moving away from stock items completely. The document above points to this list of icon names: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html#names What guarantees do we have that referring to an icon name in the icon naming spec will actually produce an icon ? GTK+ ships with a built-in icon theme that covers the named icons used by the stock system (not all listed in the naming spec). ___ 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:44 -0400, Matthias Clasen wrote: On Tue, Jul 2, 2013 at 10:29 AM, Tristan Van Berkom t...@gnome.org wrote: Besides what Bastian already points out, I have another concern if we are to consider moving away from stock items completely. The document above points to this list of icon names: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html#names What guarantees do we have that referring to an icon name in the icon naming spec will actually produce an icon ? GTK+ ships with a built-in icon theme that covers the named icons used by the stock system (not all listed in the naming spec). Will we keep those: https://developer.gnome.org/gtk3/3.4/gtk3-Stock-Items.html somehow listed in the documentation (even if the declarations are deprecated)? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
Hi Bastien, Thanks for the feedback. I've added the following section about this to the document. One objection that has been raised is that now application authors will need to include and translate label strings (such as “_Save”) application-side. This means application authors will need to decide which characters to use for mnemonics. This is actually a good thing. A problem we’ve always had with standardized label strings hardcoded in the toolkit is that inevitably the mnemonics clash. We’ve never had a solution for this and there is even a FIXME in the codehttps://git.gnome.org/browse/gtk+/tree/gtk/gtkstock.c#n339for it. To do it correctly you really need to know what ones you've already used and what items are important enough to have them. While it may be possible to invent some kind of mechanism to pick mnemonics automatically, we don’t currently have one. And it will likely be complicated to do reliably considering translations. Instead of relying on internal magic it is better to trust the application author to get it right. 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 Guidehttps://docs.google.com/spreadsheet/pub?key=0AsPAM3pPwxagdGF4THNMMUpjUW5xMXZfdUNzMXhEa2coutput=htmland I expect some of this will migrate into the GTK+ documentation and platform HIG soon. On Tue, Jul 2, 2013 at 9:53 AM, Bastien Nocera had...@hadess.net 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. The biggest loss is the need to re-translate, usually with consistency about the mnemonic used, things such as _About, _Save, etc. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
Hi Tristan, On Tue, Jul 2, 2013 at 10:29 AM, Tristan Van Berkom t...@gnome.org wrote: The document above points to this list of icon names: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html#names What guarantees do we have that referring to an icon name in the icon naming spec will actually produce an icon ? Will GTK+ have a dependency on an installed icon theme which conforms to the basic spec ? (can GTK+'s configure script verify that there is a *complete* set of icons installed and bail out if it's not the case ?). Yeah that was advantage 1. A guaranteed, consistent, and high quality set of icons I listed. Essentially GTK+ 3 has implicitly had a runtime dependency on an implementation of the icon naming spec for some time. This isn't a new change. In fact we optionally also depend on an implementation of symbolic icons too. Even though I think not having one should fallback in some fashion. As for the best way to express this? I don't know offhand. Suggestions welcome. Jon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
