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 ?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]