Re: [gtk-osx-devel] Bison 3 and WebKit
On Dec 27, 2014, at 9:55 AM, Philip Chimento philip.chime...@gmail.com
wrote:
On Mon, Dec 22, 2014 at 11:28 AM, John Ralls jra...@ceridwen.us
mailto:jra...@ceridwen.us wrote:
On Dec 22, 2014, at 9:11 AM, Philip Chimento philip.chime...@gmail.com
mailto:philip.chime...@gmail.com wrote:
On Mon, Dec 22, 2014 at 9:04 AM, John Ralls jra...@ceridwen.us
mailto:jra...@ceridwen.us wrote:
On Dec 21, 2014, at 9:09 PM, Philip Chimento philip.chime...@gmail.com
mailto:philip.chime...@gmail.com wrote:
On Tue, Dec 16, 2014 at 12:39 PM, John Ralls jra...@ceridwen.us
mailto:jra...@ceridwen.us wrote:
On Dec 16, 2014, at 12:25 AM, Philip Chimento philip.chime...@gmail.com
mailto:philip.chime...@gmail.com wrote:
On Mon, Dec 15, 2014 at 11:01 AM, John Ralls jra...@ceridwen.us
mailto:jra...@ceridwen.us wrote:
On Dec 14, 2014, at 10:14 PM, Philip Chimento
philip.chime...@gmail.com mailto:philip.chime...@gmail.com wrote:
On Mon, Dec 8, 2014 at 8:15 PM, John Ralls jra...@ceridwen.us
mailto:jra...@ceridwen.us wrote:
On Dec 8, 2014, at 3:37 PM, Philip Chimento
philip.chime...@gmail.com mailto:philip.chime...@gmail.com wrote:
On Sun, Dec 7, 2014 at 5:05 PM, John Ralls jra...@ceridwen.us
mailto:jra...@ceridwen.us wrote:
The upgrade of Bison to version 3 which you graciously provided
breaks the WebKit build, which you also graciously provided. ISTR
that you mumbled something about working on building a newer WebKit
version. Are you?
Yes! It's been a bit pre-empted by other stuff, but I am still
working on building WebKit 2.4.7. [...]
[...] should I perhaps keep the old WebKit 1.x module intact, and instead
add a new one for webkitgtk 2.x? I might have to add a new one anyway
since webkitgtk 2.x has discontinued the old WebKit 1 single-process API,
and a lot of apps still depend on it. How about two new modules named
webkit1gtk and webkit2gtk?
Yes, I think that would be wise.
How about just “webkit” and “webkit2” so that app modulesets don’t break
gratuitously?
Actually what I meant was keeping the existing one, and adding two more.
All the APIs and version numbers are confusing but here's everything I'm
proposing in a nutshell:
- WebKit - WebKitGTK 1.x, WebKit 1 API, works with GTK 2.x (could be built
for GTK 3.x but let's not bother)
- webkit1gtk - WebKitGTK 2.4.x, WebKit 1 API, works with GTK 3.x
- webkit2gtk - WebKitGTK 2.6, WebKit 2 API, works with GTK 3.x
I picked webkit2gtk because that's what the pkg-config file calls itself
and webkit1gtk in analogy to that. (Actually webkit1gtk's pkg-config file
is called webkitgtk so that might be better for consistency but a more
confusing name.)
Ah, got it.
Could we use ‘webkit[12]gtk3’ to make it clear that they’re gtk3-only?
That aside, the only way to deal with the confusion is to comment each module
with what it’s for.
Done, pull request here: https://github.com/jralls/gtk-osx-build/pull/32
https://github.com/jralls/gtk-osx-build/pull/32
Yeah, saw that, I’ll make comments on the pull request.
I still get an error building libsoup, only on modulesets-unstable. I worked
around it by adding --disable-introspection to libsoup's autogenargs in my
local configuration file, since I assume it's a temporary problem. I haven't
yet had time to pinpoint where it came from, though. Have you seen this
before at all?
GISCAN Soup-2.4.gir
Traceback (most recent call last):
File /Users/fliep/gtk/inst/bin/g-ir-scanner, line 55, in module
sys.exit(scanner_main(sys.argv))
File
/Users/fliep/gtk/inst/lib/gobject-introspection/giscanner/scannermain.py,
line 517, in scanner_main
ss = create_source_scanner(options, args)
File
/Users/fliep/gtk/inst/lib/gobject-introspection/giscanner/scannermain.py,
line 430, in create_source_scanner
ss.parse_files(filenames)
File
/Users/fliep/gtk/inst/lib/gobject-introspection/giscanner/sourcescanner.py,
line 256, in parse_files
self._parse(headers)
File
/Users/fliep/gtk/inst/lib/gobject-introspection/giscanner/sourcescanner.py,
line 302, in _parse
proc.stdin.write('#ifndef %s\n' % (define, ))
IOError: [Errno 32] Broken pipe
make[3]: *** [Soup-2.4.gir] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
No, but I haven’t tried building libsoup in unstable recently. Looks like a
g-ir-scanner bug, though. Someone changed the format to use only one arg and
screwed up by forgetting to remove the comma in the now-single-member tuple.
Regards,
John Ralls
___
Gtk-osx-devel-list mailing list
Gtk-osx-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
a new combo box
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
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, 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 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
Does it work as depicted with Tiling Window Managers? On Sat, 27 Dec 2014 08:02:44 -0500 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 ___ 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
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 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 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 Sat, Dec 27, 2014 at 12:59 PM, Tristan Van Berkom tris...@upstairslabs.com 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
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 matthias.cla...@gmail.com wrote: On Sat, Dec 27, 2014 at 12:59 PM, Tristan Van Berkom tris...@upstairslabs.com 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 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
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 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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
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 matthias.cla...@gmail.com: 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
On Sat, 2014-12-27 at 16:29 -0500, Matthias Clasen wrote: On Sat, Dec 27, 2014 at 12:59 PM, Tristan Van Berkom tris...@upstairslabs.com 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 between most people who regularly touch GTK+ code (with the
