Re: runtime accel changes

Michael Natterer <mitch <at>> 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'm pointing this out because I don't like the way of reasoning here. I have no
real opinion on editability of keybindings.


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