Re: a new combo box
On 27 Dec 2014, at 18:05, Sébastien Wilmet swil...@gnome.org wrote: On Sun, Dec 28, 2014 at 12:50:24AM +0900, Tristan Van Berkom wrote: In any case, I think this misses the point I was trying to make, I think someone had to raise the obvious question: is it justified to bring in a whole new combo API ? Or can we / should we get the most out of the API we have ? Yes, it was more a side note. As a comment says at the top of gtkcombobox.c: /* WELCOME, to THE house of evil code */ I vaguely recall pushing a commit to remove exactly this comment, but I see it never made master. Sorry about that. Anyway, in light of this discussion the comment is interesting. The comment was actually added right from the start of the code and not after years of adding new features. I believe it was born out of frustration (and immaturity). The big problem is that GtkComboBox implements two widgets at once. Back in GTK+ 1.x we had a GtkOptionMenu (menu-based) and a GtkCombo (list-based). High on the wish list in the beginning of the GTK+ 2.x series was a widget that could handle both styles *and* be able to switch between these styles at run-time with the toggle of a style property. This became GtkComboBox and it essentially implemented all event handling logic and child widget rendering logic (for showing the “sample” (the selected item) and the arrow) twice and additionally had code to transform between these two at run-time. We also added the possibility to add another random widget as “sample widget”, not limited to GtkEntry. In retrospect I believe the two-in-one approach was a bad design decision. It would probably have been better to implement the list-based and menu-based variants as specialisations of a base class and somehow implement the logic to switch between these two at run-time. This would also have made it easier to add additional styles such as the one proposed. So in summary, GtkComboBox is highly flexible but only in terms of contents as you have to stick to the default list and menu styles. The proposed design seems to have a new style and limited possibilities for the contents. I believe it will be very hard to map this to GtkComboBox API as it stands now, making replacement pretty much inevitable as Mattias has mentioned. On the other hand, I agree with Tristan’s approach to avoid complete replacements of existing code (widgets). To make this a possibility, I believe you need a framework to allow the existing widgets to evolve: parts have to be deprecated and removed, parts have to be changed (shoving in new base classes), and new parts are added. GTK+ does not have such a framework, because there is no set cycle for the change or removal of code (ABI break), you can never complete the required clean up to be able to implement new functionalities or styles. But I am touching on a controversial topic now, so I will stop right here ;). regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: a new combo box
On Sun, Dec 28, 2014 at 1:27 AM, Alberto Ruiz ar...@gnome.org wrote: My main concern with the design is that users can't make a difference between a normal button and this widget (usually related to an action, perhaps with the exception of iconized menus like the ones we're using in headerbars these days). Is there any design rationale to remove the usual arrow? You should try the actual thing... I had the same question, and added the arrow back ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: a new combo box
This is the third (fourth) incarnation of a combo box and there is still opposition to keeping the API stable? That's just crazy. Matthias' awesomeness aside, why would this be the last time? Seriously, a change in a widget like this means 20+ hours[*] of extra work for me as an application writer. I have a lot of GUI to deal with, but say 10 hours is the average and look at 100 applications. 1000 hours of work that doesn't advance the functionality of the applications. If it took Matthias an extra 500 hours -- something like three months of his time -- it would still be better to use the old api. Or at least some variant for which the changes would be doable by search-and-replace. Morten [*] That's probably a low estimate. It not just finding all uses of the old and replacing with the new. It's debugging the application _and_ the new widget; filing bugs against the widget; writing work-arounds for the 2 years before fixes are made and distributed; it's tracking the API changes that are a consequence because a non-gtk library function that is based on the widget will now have new signals being fired -- no help from the compiler there. On Sun, Dec 28, 2014 at 9:07 AM, Matthias Clasen matthias.cla...@gmail.com wrote: On Sun, Dec 28, 2014 at 1:27 AM, Alberto Ruiz ar...@gnome.org wrote: My main concern with the design is that users can't make a difference between a normal button and this widget (usually related to an action, perhaps with the exception of iconized menus like the ones we're using in headerbars these days). Is there any design rationale to remove the usual arrow? You should try the actual thing... I had the same question, and added the arrow back ___ 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: a new combo box
On 28 December 2014 at 16:32, Morten Welinder mort...@gnome.org wrote: This is the third (fourth) incarnation of a combo box and there is still opposition to keeping the API stable? That's just crazy. on the contrary: with a new class you'd be sure that the GtkComboBox widget API is finally stable — as in no changes, except for bug fixes — which is apparently what you want. Matthias' awesomeness aside, why would this be the last time? it wouldn't. the only way to declare the whole of GTK stable according to your metric of needing to never port anything ever again would be to simply kill off the project, or go in deep maintenance mode, and only do bug fixes that do not require new API. that's the state in which GTK+ 2.24 is, incidentally. as a project, GTK can either add new API and never deprecate anything ever again — thus catering to the people that already have a sizeable code base and don't need to change their UI because of an established user base — but that would be confusing for new developers that come to the API reference and see three different widgets covering 8 overlapping use cases, thus muddling up the developer experience of the whole core platform. or GTK can deprecate older classes when it becomes clear that the maintenance burden they impose is too high, in the face of changing requirements and designs — which imposes maintenance burden on application developers, something that happens basically on every platform anyway. we could introduce delayed or soft deprecations: we simply indicate that a widget should not be used for two cycles (i.e. a year), to let the new widget's API take shape and solidify, and then enable the deprecation warnings. I'm sure we can introduce some pre-processor macro that does this work for us. I honestly don't think never deprecating stuff will ever work. ciao, Emmanuele. -- http://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: a new combo box
So let me ask a very basic question here, since I feel it's at the heart of the dumb internet argument we're having. What is this design trying to solve? What problems with the old ComboBox are we trying to fix? What use cases is it designed for? Is it the usability problems? Are we adding the search field to behave more like Chosen [0] ? Because that's really cool. If that's the main purpose of the redesign, I'd like to keep the old GtkComboBox API so that users benefit by the new usability immediately. Is it a just a visual refresh, making the new widget seem more new GTK+ than the old one? Is it the ability to use widgets instead of cell renderers in ComboBox? OK. Is that worth a new visual refresh and new usability scenario? Could we upgrade both at the same time, and have one API for widgets, and one API for cell renderers? Would that be feasible? My issue, really, is that I haven't really been keeping up with GTK+ development and new widgets over the course of time. I hack on some personal apps in my spare time. If we add GtkCombo as a separate question, I have one simple question: when should I use GtkCombo and when should I use GtkComboBox? Cosimo talks about GtkPopover and GtkMenu, but those just sort of have me stunned. Why should I use one instead of the other? We have GtkMenuButton, GtkMenu, GtkModelMenu, GtkModelButton, GtkPopover, GtkPopoverMenu, and they all sort of do the thing. I have no idea which to use nowadays. (This is not a chance to explain what they do: I have an understanding of what does what after reading the docs. But imagine someone who's never done GTK+ development before. What's the new hot, correct, widget to use if you want a menu button in your app? What's it called? OK. Why are the others there?) [0] http://harvesthq.github.io/chosen/ On Sat, Dec 27, 2014 at 5:02 AM, Matthias Clasen matthias.cla...@gmail.com wrote: Hi, over Christmas, I had some for a little side project, a new combo box. It is based on these mockups: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/theming/widgets/combobox-replacements.png One question I need some feedback on is naming: We currently have GtkComboBox and GtkComboBoxText. I've gone with GtkCombo for now, which has the downside that there is a widget by that name in gtk2. Alternatives might be GtkChoice or GtkComboButton (with a possible avenue for making the list-of-choices available for direct embeeding as GtkComboWidget later). There are some lose ends in the code, like the interaction of grouping and search, but it is complete enough to give it a try and evaluate the design. If you want to try it, the code is in the wip/combo branch, and there is a testnewcombo test app with some examples. I'm off for a few days now - would be great to hear some feedback when I come back. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Jasper ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: a new combo box
on the contrary: with a new class you'd be sure that the GtkComboBox widget API is finally stable — as in no changes, except for bug fixes — which is apparently what you want. There are three types of widgets in the gtk+ world: (1) active and non-deprecated, (2) deprecated, and (3) deprecated and removed. Application writers know that (2) is on the way to (3), even if gtk+ developers like to publicly say that isn't true. It's just that we have never observed anything else. So, no. I don't want the API stability in (3). And the bug fixes part for (2) is by and large PR. In the real world, it doesn't happen and I am regularly reminded of this when 10 year old bug reports get closed wontfix or obsolete. Emmanuele, why are you so cavalier about inflicting pain and work on application writers? Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: a new combo box
hi; On 28 December 2014 at 17:23, Morten Welinder mort...@gnome.org wrote: on the contrary: with a new class you'd be sure that the GtkComboBox widget API is finally stable — as in no changes, except for bug fixes — which is apparently what you want. There are three types of widgets in the gtk+ world: (1) active and non-deprecated, (2) deprecated, and (3) deprecated and removed. (3) is nonsense. deprecated classes are still there, unless you bring me an example of an ABI break in the same major release. if by removed you mean unmaintained then we can somewhat agree. stuff still happens in deprecated widgets, but generally the things that are deemed broken can either be solved by a change in behaviour — which is usually met by a don't do that because otherwise you're breaking my 10 years old application with X users why do you hate us so much — or by adding new API — which usually means that people notice this stuff two years down the line, because long-term support distributions won't add a new release of GTK with that API. So, no. I don't want the API stability in (3). And the bug fixes part for (2) is by and large PR. In the real world, it doesn't happen and I am regularly reminded of this when 10 year old bug reports get closed wontfix or obsolete. stuff gets closed as OBSOLETE/WONTFIX if no patch has materialized in 10 years, or if that requires new API/behavioural changes — see above why. examples where that hasn't happened would be nice. Emmanuele, why are you so cavalier about inflicting pain and work on application writers? why are you so cavalier in imposing even more work on the toolkit maintainers, while simultaneously whinging about every single change in the toolkit that causes you to spend time maintaining your own application? again, if you don't want the toolkit to ever deprecate anything, or to maintain even deprecated classes with the same amount of resources we have, I strongly suggest you start helping out the maintainership of the toolkit itself, instead of filing bugs with fix this like this and waiting for a patch to arrive. ciao, Emmanuele. -- http://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: a new combo box
I am a bit disappointed by the turn this discussion has taken - I was hoping people would try the code I pointed to and let me know what they think and point out problems (thanks to Tim for doing just that). Instead, I get arguments about how much my time is worth compared to Mortens, complaints about 10 year old bugs getting wontfixed, or philosophical questions about whether a toolkit should ever provide more than one tool for a given job... Please, it was fun to write this code, I was hoping you would have some fun trying it out. Anyway, really off now until the new year. Enjoy your new years party, everybody! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: a new combo box
hi Matthias; On 27 December 2014 at 13:02, Matthias Clasen matthias.cla...@gmail.com wrote: over Christmas, I had some for a little side project, a new combo box. It is based on these mockups: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/theming/widgets/combobox-replacements.png There are some lose ends in the code, like the interaction of grouping and search, but it is complete enough to give it a try and evaluate the design. If you want to try it, the code is in the wip/combo branch, and there is a testnewcombo test app with some examples. I'm off for a few days now - would be great to hear some feedback when I come back. just a bunch of comments going through the commits. looking at the API, it seems that every item in the selectable values has: • a string value used for the row id • a string value used for the text • a string value used as the sorting key • a string value used as the grouping key that's a lot of strings; some languages with named and optional arguments (e.g. Python) will be better served by this API, but I'm worried about C developers getting it wrong — like with gtk_box_pack_*. the stringified id is miles better than the numeric one we use in the combobox widget currently, but I'm not entirely sold on the sorting and grouping keys being (nullable) arguments for add_item(). maybe it should be add_item_full(), or a specific set_sort_key(id, sort_key) and/or set_group_key(id, group_key). we're only allowing textual data, but we may want to allow an image selection instead — for instance, to select among a dropdown of known colours, or know background, or known emojis, or whatever. we clearly don't want to have that exposed in the API, but this would require having GtkComboRow as a public class that the user can inherit from. set_placeholder() should probably be set_placeholder_text(), to match the corresponding method in GtkEntry. set_allow_custom() is probably fine, but we probably want a set_allow_custom_text() to customize the text to something other than Custom entry; or maybe have set_allow_custom() take a const char* with NULL being the equivalent of FALSE; being the equivalent of the default string; and a string for a custom label. not the nicest thing, to be honest. the widget design does not seem to allow multiple selection, but the select element in HTML has a multiple option which may turn useful. as for the overall naming: I think combo box does not entirely apply, given that the entry is not only optional, but also part of the drop down, instead of being an entry *with* a drop down. maybe something like GtkDropdown? or GtkDropList? ciao, Emmanuele. -- http://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: a new combo box
On Mon, Dec 29, 2014 at 1:53 AM, Matthias Clasen matthias.cla...@gmail.com wrote: I am a bit disappointed by the turn this discussion has taken - I was hoping people would try the code I pointed to and let me know what they think and point out problems (thanks to Tim for doing just that). Some other comments in addition to what Timm and Emmanuele already said: - gtk_combo_remove_item() and gtk_combo_set_active() should probably return a gboolean for the case the ID is not found. Alternatively (or in addition to that), a gtk_combo_has_item() API could probably be added too - what is the purpose of the inverted property of GtkComboRow? It doesn't seem to be used in the class as far as I can see - it would be nice to share the key press event code with the one in GtkSearchEntry instead of duplicating it - how does gtk_combo_add_group() behave when called on a group ID that already exists? I assume it just sets the new value on the existing group properties, but then the method name is a bit misleading - consider adding a gtk_combo_remove_group() that takes a group ID Finally, I think the widget exacerbates one of the problems with GtkPopovers - the fact that they can't draw outside of the parent window. In testnewcombo this is visible in the With Gropuping example when G 3 is selected; the show more button is drawn half cut with the default window size on my laptop. Cosimo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: a new combo box
On Mon, Dec 29, 2014 at 1:09 AM, Jasper St. Pierre jstpie...@mecheye.net wrote: Cosimo talks about GtkPopover and GtkMenu, but those just sort of have me stunned. Why should I use one instead of the other? I doubt application authors choose which widget to use by reading type names in API references; if you're following a style guide like the HIG, the recommendation will come from there. Other times you will want a widget that looks/works like one you've seen elsewhere, and the visual/behavioral difference will make it obvious why there are two different classes. Cosimo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
