Re: a new combo box
This is a quick note to say that I updated the mockups a little while ago: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/theming/widgets/combobox-replacements-2.png These are intended to be a bit simpler than the previous iteration (found at [1]). I would personally prefer not to use horizontal movement (as seen in the handling of groups), but that is somewhat dependent on bug 741155 [2]. Allan [1] https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/theming/widgets/combobox-replacements.png [2] https://bugzilla.gnome.org/show_bug.cgi?id=741155 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: a new combo box
Jasper St. Pierre wrote: > 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? ... I've added some additional material to the design page [1] today. I hope that it answers some of your questions. ... > 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? That's a good question. One thing I've been thinking about is linking to (or referencing) widgets from the design patterns in the HIG. That would help to communicate what's recommended. It would also help to communicate the differences between the widgets. For example, the page on lists refers to list boxes and tree views (not by name, currently), and gives advice on when to use one rather than the other. Allan [1] https://wiki.gnome.org/Design/OS/DropDowns ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: a new combo box
Alberto Ruiz 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? Well that's embarrassing. The omission of the arrow was an oversight on my part - corrected now. Allan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: a new combo box
Timm Bäder wrote: ... > Seems like these mockups (and the new combo box) should be kept in sync > with general popover menus, especially wrt. the grouping behavior (i.e. > separate pages in a GtkStack VS. expanding the new group downwards). I > know Allan favored the latter (and there's a bug about it), but making > that work for all the cases in comboboxes would be even harder. Indeed. It would be good to have a resolution on bug 741155 [1] before taking this forward. The design patterns for add/remove lists are also relevant, particularly the section on additional actions [2]. Allan [1] https://bugzilla.gnome.org/show_bug.cgi?id=741155 [2] https://wiki.gnome.org/Design/OS/AddRemoveLists#Additional_Row_Actions ___ 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 27/12/14 13:02, Matthias Clasen 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 It looks nice! I've had a look at gtkoptionlist.c and had a play with the test application. On the api front I would echo Cosimo's comments about removing groups, adding an existing group and being able to check if an entry exists. Having a string id is nice but there are times when it would be handy to associate some data with a entry. I'm thinking about existing comboboxes such as the preferences in sound-juicer where there's a GstEncodingProfile associated with it's description, in BraseroMediumSelection where a BraseroMedium is associated with a label or ripping a CD in rhythmbox where the album selector associates an album object with a label. In such cases it's a pain to create arbitrary id's and write a mapping function to get the data from the id, it would be much more convenient if GtkOptionList handled this for the application. As Emmanuele mentioned it would be good to be able display a general widget in the option list. At the moment GtkOptionList and GtkOptionListRow are opaque so it's not possible to create a derived widget to do this. Also there would need to be some api to add and remove GtkOptionListRows to and from the GtkOptionList. This would make it possible to recreate something like BraseroMediumSelection which displays an icon next to the drive name. The test app is really useful for giving a good feel for how things work. I really like the search, it makes selecting from a long list so much easier. It's great that it's matching substrings rather than prefixes. It would be nice if the popover closed when the user pressed enter, it always feels wrong to me to have to press escape to close something which I don't want to cancel. I find this is a general problem with popovers rather than this widget specifically. Of course it's not straight forward for multiple selections, I'd be happy for space to toggle the selection and enter to toggle the current item and close the popover but can see that that could be confusing for users at first. When searching, if there's only one match then it would be nice if enter selected it and closed the popover. When dealing with groups it would be nice if pressing the left arrow or backspace went back to the main list. When adding a custom item the resizing is a little clumsy as the stack animation runs and then the popover resizes rather than there being a smooth transition. Also the resizing causes other widgets to move up and down when the GtkOptionList is embedded in the dialog which is distracting. > 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). I think calling it GtkChoice risks confusion with the various GtkChoosers which are (mostly?) dialogs. Another possibility for the name is something based on selector or selection - GtkSelectButton and GtkSelector or GtkSelectionButton and GtkSelectionList maybe. One last thing the documentation mentions #GtkOptionListBox I think this must be a victim of search and replace when it was renamed from GtkCombo. I hope you find these comments helpful, I think this is a nice alternative to GtkComboBox. Best Wishes Phillip ___ 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 7:42 PM, Emmanuele Bassi wrote: > just a bunch of comments going through the commits. Thanks for this! [...] > 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"? I've spent some more time on the branch and ended up reworking things a bit more. I've incorporated most of your suggestions. Wrt names, I've renamed things to GtkOptionList (for the list widget) and GtkOptionButton for the button with the popover. Still not great. The test app is now called testoptionlist, and shows a more stuff: multi-selection, and various alternative uses of the list widget without a button. ___ 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 Tue, Dec 30, 2014 at 2:26 AM, Philip Chimento wrote: > Assuming that questions on Stack Overflow are an approximate poll of what > application authors do - many application authors go to the documentation > and do exactly that. (And often don't bother to read any further - I've > often enough seen questions about a deprecated widget such as GtkList which > was selected purely based on its name.) > We are getting a bit off the topic of the thread, but this is an interesting observation. Can you link to some examples of this? I would be curious why that is the case - i.e. which medium was used to consult the documentation, because on the website deprecated classes are quite clearly marked in a separate section at the bottom of the reference ( https://developer.gnome.org/gtk3/unstable/). 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 Sun, Dec 28, 2014 at 9:24 PM, Cosimo Cecchi wrote: > On Mon, Dec 29, 2014 at 1:09 AM, Jasper St. Pierre > 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; > Assuming that questions on Stack Overflow are an approximate poll of what application authors do - many application authors go to the documentation and do exactly that. (And often don't bother to read any further - I've often enough seen questions about a deprecated widget such as GtkList which was selected purely based on its name.) > 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. > This also happens, though - people will post a screenshot and say "What is this widget?" We could make the Widget Gallery page more discoverable in the documentation in order to encourage this. -- Philip ___ 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, 2014-12-28 at 12:53 -0500, Matthias Clasen 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). > 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... > I'm sorry to see this thread spiral out of control and for my part in that. My intention was really to start a rational conversation around this topic and raise a concern that I think is justified, whichever direction this takes, it will be nice to know that the decisions made were carefully considered. We have a long history on this list of careful consideration of the benefits and collateral damage of the new APIs we adopt, and in doing so, make a certain commitment to maintain. This is what makes GTK+ a safe place to contribute and a viable choice for application developers. This said, I think Jasper has raised the right course of discussion, all emotions aside I hope that we can follow his lead by simply sticking to facts and having some rational discussion. Best wishes for the new year, -Tristan > 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 ___ 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 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
Re: a new combo box
On Mon, Dec 29, 2014 at 1:53 AM, Matthias Clasen 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
hi Matthias; On 27 December 2014 at 13:02, Matthias Clasen 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 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
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; On 28 December 2014 at 17:23, Morten Welinder 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
> 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
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 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 28 December 2014 at 16:32, Morten Welinder 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
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 wrote: > On Sun, Dec 28, 2014 at 1:27 AM, Alberto Ruiz 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 Sun, Dec 28, 2014 at 1:27 AM, Alberto Ruiz 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
> On 27 Dec 2014, at 18:05, Sébastien Wilmet 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 Sat, 2014-12-27 at 16:29 -0500, Matthias Clasen wrote: > On Sat, Dec 27, 2014 at 12:59 PM, Tristan Van Berkom > wrote: > > > > > It's really not that bad, combobox is currently < 6k lines of code which > > is really not much for all that it does, sure we could afford to do a > > bit less (like dropping the crazy tabular menus). > > Tbh, thats only true after your shoved off 2000+ lines to gtktreemenu.c. > > > Honestly I would have rather proposed to just switch the whole internals > > of combobox to do the more modern looking thing using cell areas, which > > strikes me as the obvious way forward, bringing a new look to the combo > > without dropping any of the value of combobox, and every app using > > combobox automatically benefits - only that it would probably result in > > breaking API. > > > > Frankly I don't appreciate this let's rewrite everything from scratch > > attitude, it doesnt show a whole lot of respect to the users of our API, > > who would, I think have a justifiable expectation that their usage of > > combobox would not be labeled as obsolete at least until GTK+ 4. > > > > Sure, exceptions can be made within reason for dropping huge important > > parts of GTK+, but let's stick within reason right ? Has this been > > discussed ? Has it been concluded that there is no way forward with > > the existing API ? Where is that discussion ? What is the rationale ? > > Thats one of the hardest questions, isn't it ? > > Deciding when a codebase that you've invested a lot of time and effort > into has grown too old and complex, and it is better to start from > scratch ? I'm often struggling with this, and stick to fixing things > up to 'preserve existing investment' far too long. Of course, starting > over is not a panacea: you may end up repeating old mistakes, and do a > lot of work just to end up in the same place you started from. On the > flip side, its a chance to revisit old assumptions that are deeply > embedded in the old code, add modern features without having to > force-retrofit them into ancient code (and cause collateral damage in > the process). The collateral damage really hurts, though. It's really hard to digest that application developers who have developed an application with GTK+ 3.4 or 3.6 have to continually play 'catch up' and rewrite their code to keep up with the latest release, or to benefit from new features in GTK+. A simple example that comes to mind, we have the 'fresh kids' writing cool new apps that use the bright and shiny GtkRevealer, and we have the old and suffering apps which have just not been brought up to speed, still using GtkExpander - are app developpers to blame for still using an expander ? Or should we do better to maintain the widgets that are already part of the API ? The combo box duplication will just be another instance of this, and the result is a growing disparity between applications which already exist and applications which happen to be being written this year. > That being said, I think the case for GtkComboBox is pretty clear-cut. > It was doomed from the beginning by the mistake to force two pretty > distinct user experiences (option menus and combo boxes) into a single > widget. You've made a valiant attempt to clean this up with the > introduction of GtkTreeMenu, but it is still a mess. Another mistake > was to expose a data-driven API (with models and cell renderers) for a > widget that most of the time is used in non-data-driven scenarios. Most of the time being the key word here. While perhaps 90% or more use cases of GtkComboBox want to only display a single text label which is a controlled (albiet translatable) phrase, it's the 5% - 10% of outlying cases you encounter as an application developer that you thank your lucky stars for having chosen GTK+ and have the tools handy to accomplish something which strayed just a little beyond the most basic of use cases. > We've later tried to patch up that mistake by adding the simplified > GtkComboBoxText. But since it is a subclass, it inherits all of the > api problems of GtkComboBox. Lastly, there's a number of ill-advised > APIs in GtkComboBox that make it very hard to do any new > implementation of the same api: tabular menus, spanning columns, etc. > Almost as if to prove the last point, your last major refactoring of > GtkComboBox already broke a bunch of those APIs (e.g. col-span-column > is not working anymore). > > You'll be happy to learn that the "buildable API" of GtkCombo is > pretty close to compatible with GtkComboBoxText (I should probably > rename the active property to active-id to get even closer), so for > most users, switching from GtkComboBoxText to GtkCombo should be as > simple as s/GtkComboBoxText/GtkCombo/ in their ui files. > > Since you are asking about discussions and conclusion, I'll state that > in my opinion, combo boxes should not use (even less expose in the > api) cell renderers and tree models. I believe that is pretty much > agreed upon
Re: a new combo box
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? 2014-12-27 13:02 GMT+00:00 Matthias Clasen : > 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 > -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: a new combo box
Thanks, Matthias for working on this, it looks great! It's pretty clear to me that this widget is different enough from the current combobox that using the old API and pushing the new design on every current client is not a good idea - in the same way that GtkPopover was made a different widget than GtkMenu. I especially welcome the departure from cell renderers, finally! What to do with the current GtkComboBox widget moving forward is a different conversation in my opinion; are there any important use cases that are not covered by the new widget? Deprecating the old API in GTK3 and removing it in GTK4 would be the way similar things have been done in the past. Cosimo On Sat, Dec 27, 2014 at 9:02 PM, Matthias Clasen 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 > ___ 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 12/27/2014 01:44 PM, Morten Welinder wrote: > Can we keep the api -- function names, etc.? > > I.e., could we, for once, do such an upgrade without inflicting > pain on the users? Even at the cost of some pain for > developers. On the other hand, this is the type of thing where people also complain that we break "ABI" because it doesn't work/look the same as before. So my vote is opposite. Don't make it compatible unless it is functionally the same. -- Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: a new combo box
Can we keep the api -- function names, etc.? I.e., could we, for once, do such an upgrade without inflicting pain on the users? Even at the cost of some pain for developers. Morten On Sat, Dec 27, 2014 at 4:29 PM, Matthias Clasen wrote: > On Sat, Dec 27, 2014 at 12:59 PM, Tristan Van Berkom > wrote: > >> >> It's really not that bad, combobox is currently < 6k lines of code which >> is really not much for all that it does, sure we could afford to do a >> bit less (like dropping the crazy tabular menus). > > Tbh, thats only true after your shoved off 2000+ lines to gtktreemenu.c. > >> Honestly I would have rather proposed to just switch the whole internals >> of combobox to do the more modern looking thing using cell areas, which >> strikes me as the obvious way forward, bringing a new look to the combo >> without dropping any of the value of combobox, and every app using >> combobox automatically benefits - only that it would probably result in >> breaking API. >> >> Frankly I don't appreciate this let's rewrite everything from scratch >> attitude, it doesnt show a whole lot of respect to the users of our API, >> who would, I think have a justifiable expectation that their usage of >> combobox would not be labeled as obsolete at least until GTK+ 4. >> >> Sure, exceptions can be made within reason for dropping huge important >> parts of GTK+, but let's stick within reason right ? Has this been >> discussed ? Has it been concluded that there is no way forward with >> the existing API ? Where is that discussion ? What is the rationale ? > > Thats one of the hardest questions, isn't it ? > > Deciding when a codebase that you've invested a lot of time and effort > into has grown too old and complex, and it is better to start from > scratch ? I'm often struggling with this, and stick to fixing things > up to 'preserve existing investment' far too long. Of course, starting > over is not a panacea: you may end up repeating old mistakes, and do a > lot of work just to end up in the same place you started from. On the > flip side, its a chance to revisit old assumptions that are deeply > embedded in the old code, add modern features without having to > force-retrofit them into ancient code (and cause collateral damage in > the process). > > That being said, I think the case for GtkComboBox is pretty clear-cut. > It was doomed from the beginning by the mistake to force two pretty > distinct user experiences (option menus and combo boxes) into a single > widget. You've made a valiant attempt to clean this up with the > introduction of GtkTreeMenu, but it is still a mess. Another mistake > was to expose a data-driven API (with models and cell renderers) for a > widget that most of the time is used in non-data-driven scenarios. > We've later tried to patch up that mistake by adding the simplified > GtkComboBoxText. But since it is a subclass, it inherits all of the > api problems of GtkComboBox. Lastly, there's a number of ill-advised > APIs in GtkComboBox that make it very hard to do any new > implementation of the same api: tabular menus, spanning columns, etc. > Almost as if to prove the last point, your last major refactoring of > GtkComboBox already broke a bunch of those APIs (e.g. col-span-column > is not working anymore). > > You'll be happy to learn that the "buildable API" of GtkCombo is > pretty close to compatible with GtkComboBoxText (I should probably > rename the active property to active-id to get even closer), so for > most users, switching from GtkComboBoxText to GtkCombo should be as > simple as s/GtkComboBoxText/GtkCombo/ in their ui files. > > Since you are asking about discussions and conclusion, I'll state that > in my opinion, combo boxes should not use (even less expose in the > api) cell renderers and tree models. I believe that is pretty much > agreed upon between most people who regularly touch GTK+ code (with > the exception of you, possibly). Speak up if you disagree. > ___ > 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 Sat, Dec 27, 2014 at 12:59 PM, Tristan Van Berkom wrote: > > It's really not that bad, combobox is currently < 6k lines of code which > is really not much for all that it does, sure we could afford to do a > bit less (like dropping the crazy tabular menus). Tbh, thats only true after your shoved off 2000+ lines to gtktreemenu.c. > Honestly I would have rather proposed to just switch the whole internals > of combobox to do the more modern looking thing using cell areas, which > strikes me as the obvious way forward, bringing a new look to the combo > without dropping any of the value of combobox, and every app using > combobox automatically benefits - only that it would probably result in > breaking API. > > Frankly I don't appreciate this let's rewrite everything from scratch > attitude, it doesnt show a whole lot of respect to the users of our API, > who would, I think have a justifiable expectation that their usage of > combobox would not be labeled as obsolete at least until GTK+ 4. > > Sure, exceptions can be made within reason for dropping huge important > parts of GTK+, but let's stick within reason right ? Has this been > discussed ? Has it been concluded that there is no way forward with > the existing API ? Where is that discussion ? What is the rationale ? Thats one of the hardest questions, isn't it ? Deciding when a codebase that you've invested a lot of time and effort into has grown too old and complex, and it is better to start from scratch ? I'm often struggling with this, and stick to fixing things up to 'preserve existing investment' far too long. Of course, starting over is not a panacea: you may end up repeating old mistakes, and do a lot of work just to end up in the same place you started from. On the flip side, its a chance to revisit old assumptions that are deeply embedded in the old code, add modern features without having to force-retrofit them into ancient code (and cause collateral damage in the process). That being said, I think the case for GtkComboBox is pretty clear-cut. It was doomed from the beginning by the mistake to force two pretty distinct user experiences (option menus and combo boxes) into a single widget. You've made a valiant attempt to clean this up with the introduction of GtkTreeMenu, but it is still a mess. Another mistake was to expose a data-driven API (with models and cell renderers) for a widget that most of the time is used in non-data-driven scenarios. We've later tried to patch up that mistake by adding the simplified GtkComboBoxText. But since it is a subclass, it inherits all of the api problems of GtkComboBox. Lastly, there's a number of ill-advised APIs in GtkComboBox that make it very hard to do any new implementation of the same api: tabular menus, spanning columns, etc. Almost as if to prove the last point, your last major refactoring of GtkComboBox already broke a bunch of those APIs (e.g. col-span-column is not working anymore). You'll be happy to learn that the "buildable API" of GtkCombo is pretty close to compatible with GtkComboBoxText (I should probably rename the active property to active-id to get even closer), so for most users, switching from GtkComboBoxText to GtkCombo should be as simple as s/GtkComboBoxText/GtkCombo/ in their ui files. Since you are asking about discussions and conclusion, I'll state that in my opinion, combo boxes should not use (even less expose in the api) cell renderers and tree models. I believe that is pretty much agreed upon between most people who regularly touch GTK+ code (with the exception of you, possibly). Speak up if you disagree. ___ 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 Sat, 2014-12-27 at 11:44 -0800, Christian Hergert wrote: > On 12/27/2014 07:50 AM, 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 ? > > Can I style combobox items with CSS? I'm not sure how relevant that is in this discussion, if you can't style a cell renderer that would be a bug (I do recall Carlos reassuring me that CSS would work with cell renderers when he was originally authoring the CSS machinery). A very quick look tells me that yes you certainly can, as the renderers pick up the style context from the widget they are rendered onto, you would have to be theming a GtkCellView, which is what displays an item in a combo. Cheers, -Tristan ___ 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 12/27/2014 07:50 AM, 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 ? Can I style combobox items with CSS? ___ 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 Sat, 2014-12-27 at 18:05 +0100, Sébastien Wilmet 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 */ > Sorry for not having removed that comment after spending significant time cleaning that up myself. > If it's the reason why new APIs are created instead of cleaning > internally the code, then the risk is to repeat the history every 10 > years, deprecating endlessly APIs. Every code base evolves. At the > beginning a new class is (almost) always clean, but years after years > when more features are added the code becomes harder to understand, and > the risk is that it becomes "evil code" that nobody wants to modify, if > no refactorings is done regularly. It's really not that bad, combobox is currently < 6k lines of code which is really not much for all that it does, sure we could afford to do a bit less (like dropping the crazy tabular menus). Honestly I would have rather proposed to just switch the whole internals of combobox to do the more modern looking thing using cell areas, which strikes me as the obvious way forward, bringing a new look to the combo without dropping any of the value of combobox, and every app using combobox automatically benefits - only that it would probably result in breaking API. Frankly I don't appreciate this let's rewrite everything from scratch attitude, it doesnt show a whole lot of respect to the users of our API, who would, I think have a justifiable expectation that their usage of combobox would not be labeled as obsolete at least until GTK+ 4. Sure, exceptions can be made within reason for dropping huge important parts of GTK+, but let's stick within reason right ? Has this been discussed ? Has it been concluded that there is no way forward with the existing API ? Where is that discussion ? What is the rationale ? Cheers, -Tristan ___ 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 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 */ If it's the reason why new APIs are created instead of cleaning internally the code, then the risk is to repeat the history every 10 years, deprecating endlessly APIs. Every code base evolves. At the beginning a new class is (almost) always clean, but years after years when more features are added the code becomes harder to understand, and the risk is that it becomes "evil code" that nobody wants to modify, if no refactorings is done regularly. Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: a new combo box
Does it work as depicted with Tiling Window Managers? On Sat, 27 Dec 2014 08:02:44 -0500 Matthias Clasen 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 ___ 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 Sat, Dec 27, 2014 at 08:02:44AM -0500, Matthias Clasen 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 > > ... > > I'm off for a few days now - would be great to hear some feedback when > I come back. Judging from the mockups, it eats precious vertical screen space and goes against Fitt's law by making it necessary to move the pointer far in order to select even an adjacent value (which, if the values are sanely organised, is a more likely change than selecting a distant value). Regards, Yeti ___ 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 Sat, 2014-12-27 at 16:21 +0100, Sébastien Wilmet wrote: > On Sat, Dec 27, 2014 at 10:52:27PM +0900, Tristan Van Berkom wrote: > > From a quick look at gtkcombobox.h, the only really problematic part > > is the tabular menu nonsense (set_wrap_width(), set_row_span_column(), > > set_column_span_column()). Is there any way we could get around that ? > > perhaps just an additional GtkComboBox subclass which explicitly does > > not support those tabular menu things and thus would not be an API > > break ? > > Overriding a function with a NOP is generally not a good idea, it breaks > the logic of inheritance. A derived type should be a specialization of > its base class. The derived type *is* also (a kind of) the base class. > If the base class supports operations A and B but a derived class > doesn't, then the derived class is *not* a kind of the base class, > logically. The inheritance hierarchy should be reversed in that case, so > that only the derived class supports operations A and B. Or create a > common base class or interface with two subclasses. Sure, it was suggested as a practical 'cheat' to get away with not implementing some of the more odd-ball features from combobox which I have doubts that anyone is actually using. The reverse approach would IMO be worse, since any additional features which the new beast might bring to the table would be expected functionality in the older combo, while explicitly implementing some vfuncs with g_warnings() on a few APIs, possibly deprecating those tabular menu APIs in the parent GtkComboBox API), is not really a bad side effect. 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 ? Cheers, -Tristan ___ 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 Sat, Dec 27, 2014 at 10:52:27PM +0900, Tristan Van Berkom wrote: > From a quick look at gtkcombobox.h, the only really problematic part > is the tabular menu nonsense (set_wrap_width(), set_row_span_column(), > set_column_span_column()). Is there any way we could get around that ? > perhaps just an additional GtkComboBox subclass which explicitly does > not support those tabular menu things and thus would not be an API > break ? Overriding a function with a NOP is generally not a good idea, it breaks the logic of inheritance. A derived type should be a specialization of its base class. The derived type *is* also (a kind of) the base class. If the base class supports operations A and B but a derived class doesn't, then the derived class is *not* a kind of the base class, logically. The inheritance hierarchy should be reversed in that case, so that only the derived class supports operations A and B. Or create a common base class or interface with two subclasses. Sébastien ___ 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 27.12, Matthias Clasen 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 Seems like these mockups (and the new combo box) should be kept in sync with general popover menus, especially wrt. the grouping behavior (i.e. separate pages in a GtkStack VS. expanding the new group downwards). I know Allan favored the latter (and there's a bug about it), but making that work for all the cases in comboboxes would be even harder. Other than that, the current behavior of popovers when changing their size isn't really what I'd like to see (i.e. changing the position when changing the size, that's really disturbing). And of course, animating the size change would be great here too. A few things I found in a quick test: - http://i.imgur.com/QAQddSD.png There are 2 problems here: on the very top of the list, there's a GtkSeparator visible and of course the undershoot (or overshoot?) indicator at the bottom while no scrolling is possible. - It seems to me like some rows (e.g. those with text fields and/or buttons in them) should not be focusable? - The "Remove active" button crashes testnewcombo here Other than that, I think it looks really cool and is a step in the right direction. Regards, Timm ___ 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 Sat, 2014-12-27 at 08:02 -0500, Matthias Clasen 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 Looks very modern and nice :) > > 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). I guess one obvious question is, how much of this really calls for a whole new API as a hard requirement ? Afaics, most of this new look for a GtkComboBox can be accomplished from the confines of the current GtkComboBox API - filtering the option tree can also probably be simplified with some GtkTreeModelFiltering and leveraging of the existing GtkEntryCompletion code... and the group switching instead of showing recursive menus looks like a nice refreshing change from the current GtkTreeMenu. I'm sure the same look can be accomplished with GtkCellViews in the items, also allowing for flexible customization of the items look and feel, leveraging the cellview code without adding any additional API. >From a quick look at gtkcombobox.h, the only really problematic part is the tabular menu nonsense (set_wrap_width(), set_row_span_column(), set_column_span_column()). Is there any way we could get around that ? perhaps just an additional GtkComboBox subclass which explicitly does not support those tabular menu things and thus would not be an API break ? It would be really great if one could just simply change a class name in their existing code and suddenly benefit from a whole new look and feel of GtkComboBox... Best, -Tristan > 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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
