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
