Re: a new combo box

[Tristan Van Berkom <tristan upstairslabs com>]

On Sat, 2014-12-27 at 16:29 -0500, Matthias Clasen wrote:
> On Sat, Dec 27, 2014 at 12:59 PM, Tristan Van Berkom
> <tristan 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 exception of you, possibly).  Speak up if you disagree.

I agree that GtkComboBox has a lot of baggage which we could do away
with, I do not agree that the implementation should be dumbed down
and restrictive in terms of what data can be displayed in a combobox
item, I'm not sure that you have a plan to restrict combobox items
in terms of what can be displayed in them, but that would IMO be a
very great loss were it to happen.

If you can bear with me, let me describe just one of the particular
outlying cases I'm dealing with currently, I could imagine other
similar cases but this one is fresh on my mind.

Right now I've been working on a data driven resource management
application, one case of data driven combo box usage is where we
define equipment - our users manage large work forces and need to keep
an inventory of a wide range of equipment (cement trucks, flat beds,
cranes, snow removal and street cleaning devices, trackers, front
loaders, etc etc), types of equipment which the user can create/define
on demand and cannot be hard coded into our application.

To allow the user to more easily recognize equipment types (and also to
bring life to the application, make it feel good to use, which is also
really important), we allow them to assign an avatar from a predefined
set of avatar icons for their equipment types - equipment types have a
numeric code (part of the client's data set), a name, and sometimes a
description blurb. The combo box comes into play when defining a new
item in their inventory, which must have an equipment type.

This use case is not all that far fetched, and creating an additional
modal dialog / treeview to select a type of equipment is not a good UI
solution to everything, as you quickly have multiple dialogs displayed
one on top of the other.

The data to display is both:

 a.) Data Driven

    The user defines equipment types, we cannot always be in control of
    the text, or the length of the text which might appear as a combo
    box item.

 b.) Tabular in Nature

    To display the relevant data and be visually pleasing, we have a
    layout which includes:

    1.) A fixed size equipment type avatar icon on the left

    2.) Bold, right aligned text for the equipment type's numeric code,
        which can range from 3 to 6 digits in length, the numeric code
        should of course be aligned with the codes displayed in items
        above and below.

    3.) The equipment type's name, which must ellipsize should it
        exceed the maximum possible width of the combo box.


The second point is specifically relevant to the choice of having used
cell renderers to display combo box items, because you simply cannot
achieve the same with widgets.

Displaying tabular data with widgets sort of works in a GtkGrid, but as
your combo box items will undoubtedly be separate widgets for each and
every row, you lose the ability to leverage GtkGrid's geometry
management, unless perhaps you allow in the new combo API for the user 
to define widgets for each column of a combo item, but then the API
quickly blows up when you start to desire header rows or any widgets
which span multiple columns.

One can resort to using GtkSizeGroups in boxes at this point, but this
is already limiting in the tabular layouts you can achieve, not to
mention that size groups are rather a computational nightmare - while
the cell area and cell rendering code was written for exactly this type
of display of tabular data and get the job done much more elegantly
(with room for improvement of course, regrettably there is still no
GtkCellAreaGrid).

Yes, I have many times found myself cursing about the complexity of
treeviews and treemodels, and my wrists are particularly thankful
for convenience APIs such as GtkComboBoxText - we all have our issues
with the particulars of the treemodel API which is hard to implement,
but on the other hand - treeview has functionality I simply cannot
get with other widgets and find myself time after time choosing to use
a treeview, especially for display of any hierarchical dataset where
you really don't want or need the degraded UX commonly referred to as
'pagination'.

I understand that some of you have a desire to drop treeviews, cell
renderers and tree models, but realistically speaking, unless someone
starts seriously working on an alternative data model API right now,
which is really a lot of work, treeview is not something we'll be able
to just drop in GTK+4, not without severe degradation in functionality.

Sorry for the length of the email.

Best,
    -Tristan