Re: runtime accel changes

[Tristan Van Berkom <tvb gnome org>]

On Sun, Sep 16, 2012 at 8:05 AM, Benjamin Otte <otte gnome org> wrote:
> Michael Natterer <mitch <at> gimp.org> writes:
>
>> I think my actual point here is: There are so many usecases
>> and levels of complexity in peoples' workflows, and
>> in the applications that can be written in GTK+, we should
>> not disable useful things because they are either not in
>> fashion any longer according to whoever defines "fashion",
>> or are out of scope for some refactoring. Instead, rather
>> adjust the scope of the refactoring.
>>
> I think this is not a very good argument. GTK is still severely understaffed and
> has such a huge complexity already that it is necessary to cut. And to cut
> heavily. In particular because people expect GTK to grow even more features
> (mostly in the graphics and touch departments).
>
> Also, there is a lot of places where developers don't really understand the code
> they are touching and the code does things in a "weird" way (read: It was
> written 10+ years ago when we were all writing code differently). And when
> someone actually does dare to touch these codepaths again, he'll have to make
> choices - and oftentimes the choice is not 100% backwards compatibility, but
> implementing desired new functionality. And I personally prefer people reducing
> the amount of unmaintained code, even if the cost to that is features. And if it
> turns out those features were great, hopefully someone will volunteer to add
> them back later.

I do agree and do disagree, in this particular case I think that we have code
in place that does do runtime accelerator changing properly, even if I would
personally like to privatise that accelmap/accelgroup stuff into some basement,
we do have a good GtkAction[Group] api that at least should take care of all
of this stuff automatically. There's no sensible reason to just throw that away.

Some examples in contrast; for instance when we ditched code generation
feature from Glade, *so many people complained* really they did, but we
did it on the grounds that the feature was crap and the feature itself had more
negative impact than positive.

On the other hand, ... oh how I would have loved to throw GtkSizeGroup in
the garbage when implementing height-for-width... based on the same arguments
perhaps I should have... but it's a useful feature that already worked (read: I
had not considered them properly and so I had to expand the scope of my
refactoring, that was my own fault and my own responsibility) it probably cost
me an extra week (maybe more) of hair pulling to get h4w apis to play well
with size groups.

And dont even get me started about GtkUIManager and that silly "merge ui"
feature... if it wasnt for that feature and our lazyness in porting that feature
into GtkBuilder proper then we would have ditched that double standard
of UI building years ago.

> I'm pointing this out because I don't like the way of reasoning here. I have no
> real opinion on editability of keybindings.

<drumroll/>...

I would think that anyone who has played starcraft... would have an opinion
about the usefulness of configuring keybindings without restarting the
application ;-)
(couldnt resist).

Cheers,
          -Tristan