Bug#170037: This bug should be fixed!

Loïc Minier Loïc Minier , 170037-quiet@bugs.debian.org
Mon, 22 Nov 2004 16:17:20 +0100


Martin Samuelsson <debianbts@cos.user.lysator.liu.se> - Mon, Nov 22, 2004:

> I did read them and I read them well. So I did not miss such a trivial
> thing.
> No offense, but I think it is you who are missing the point.

 heh actually it seems we're both missing the point.  I had a talk with
 a firefox maintainer (Mike Hommey) and he explained that firefox
 brought its *own* emacs-like keybindings in the past, and that theyjust
 removed the kludge.

 Finally, we concluded for the firefox part that a note was necessary to
 explain it was possible to get the old behavior of firefox with a
 simple gtk configuration.  This is #282321.

 We also discussed the matter of #170037, which is related but somehow
 different, the end rensult was that we disagreed globally but concluded
 the discussion was not clearly defined.
   Here are what I believe to be the main points in the discussion:
 - gtk1 -> gtk2 is an important transition, and you need to adapt
   software for it to use gtk2 instead of gtk1, gtk1 is still more or
   less supported (of course less now than back in 2002), hence
   transitionning from gtk1 to gtk2 is not exactly the same as switching
   from qt to gtk orgtk to wxwindows, but still an important upgrade or
   technical switch,
 - applications did not switch instantly or in a short period of time
   from gtk1 to gtk2, this happened over years (and still happens at a
   slower pace, but ~500 packages are still depending on gtk1!), hence
   reconfiguring gtk2 or not in 2002 could still mean behavioral changes
   in 2005, when an application switches from gtk1 to gtk2,
 - still, users are *supposed* to upgrade from distro to distro, hence
   from woody to sarge, so a global dist-upgrade question would be less
   pain than 100 apps specific questions when they make the transition
   from gtk1 to gtk2,
 - sarge is going to be released with gtk1 and gtk2 apps, so the next
   release upgrade (from sarge to etch) will bring the question of the
   default gtk2 behavior again and again.

 What *I* want from firefox and other apps making technical changes that
 are non-isofunctional or "transparently compatible", such as removing
 emacs-like keybindings emulaiton, is to print a note -- most probably
 in NEWS.Debian -- explaining a change was made.  If the change is too
 important, or a major regression, users can complain via the BTS that a
 compatible version should be made, but since this is often a lot of
 work to do and to maintain, chances are low that it will be done.
   Something more that can be done in such updates is to suggest a way
 of reverting t othe old behavior (say via configuration, or aliases, or
 whatever).

 *I* don't believe anything must be one in gtk2, but I would find it
 acceptable to add a note explaining gtk2 doesn't ship with the same
 behavior as gtk1, and that one can configure gtk2 to act similarly to
 gtk1 or to emacs.
   Still, my point of view is that gtk2 is different software from gtk1,
 and just doesn't follow the "upgrade" path.  There is no "global
 transition from gtk1 to gtk2", or at least it isn't atomic.

> What matters is the topic of #170037, that the default keybindings are
> highly unexpected by at the very least as many users as there are bug
> reports.

 In the case of mozilla-firefox, this isn't related to a gtk2 switch but
 purely the consequence of the removal of a kludge.  Still, I wish the
 firefox update would advertize the important change, but that's about
 anything that can be done.

> I am tempted to say most, but can settle for that very many users of
> unix like systems expect their software to have emacs like key bindings
> if nothing else is stated. Because that is the way things have been
> for several decades and this also justifies to call these bindings
> traditional unix key bindings.

 I don't see how traditional unix key bindings must be mapped in a
 graphical text input field where you can type chinese characters or
 from right to left, select text, or simply paste text.  This is simply
 a different input method, and it's true some keys such as ^A and ^E can
 be mapped to a similar behavior, but not all "unix key bindings" such
 has ^Z, ^C, ^S, and ^Q.  ^Q is quite a good example of something you
 can't borrow to the unix tradition.

> With an increasing amount of debian users coming from other environment=
s
> the default keybindings of gtk2 are far from unnecessary, of course.

 It's also other people using gtk2 somewhere else.  It is simply not
 acceptable to ship defaults that differ completely in behavior from
 other systems, for example Redhat or Mandrake.

> Different users clearly have different needs and desires and the featur=
e
> of remapable key maps that gtk2 provides is heaps good! No question
> about that!

 Ok, we're in sync on this subject.

> However what was requested (and even offered to be done) by the origina=
l
> bug reporter was that a debconf question should be asked upon gtk2 pack=
age
> installation informing the user that gtk2 provides different key maps
> and let the system administrator choose which one to have as a system
> default.

 #170037 mentions technical issues with the implementation of such a
 choice, and I am personnally disturbed by system administrator changing
 the default behavior for their own confort disregarding my multi-system
 use of application.

> I would say though that problem is only hypothetical. About 100% of the
> debian systems out there are unaffected, i.e. single user systems with
> gtk2 or multiuser systems without gtk2. For the probably less than 1% o=
f
> debian systems that are multi users systems with gtk2 I would say we
> could guess their administators are competent enough not messing up and
> answering debconf questions wrong. Don't you think?

 That's a good point, but don't you think it would be fairly enough to
 print a note regarding configuration of keybindings in gtk2 instead?

> Traditional unix key bindings were the default with gtk1 and there's no
> other natural way to inform the user about key bindings than debconf so
> I think that libgtk2 should start asking before sarge becomes
> debian/stable.

 Debconf is for the administrator, not the user.  User will be victims
 of the change, one way or the other.

> Please reread #170037 with traditional unix users perspective in mind
> and tell us after that if that doesn't change your mind.

 I'm damn used to unix/shell shortcuts, and I'm typing in a Mutt window
 in vim right now where I often use ^U to delete a line, but guess what:
 ^A doesn't behave like in the shell, it's a vim specific binding.  I
 could be suprized by that, but I accept the fact that vim differs from
 the shell in behavior.
   Of course we're talking about upgrades here, but my position is that
 gtk2 is different from gtk1, as much as vim 6 can be different from vim
 5, and I would certainly accept vim to map ^U to a new function in vim
 7, I would probably search, as an user, to remap the key for a while,
 or live with the new one.

> Clearly *users perspective* are the key words here.

 Yeah, users perspective.  You suggest an administrator intervention for
 a change from the view point of the user.  I suggest a note to the
 admin.

> Do you really think that I should reopen the firefox bug report and
> start filing against all other packages that use gtk2? Isn't it better
> to solve the problem at it's root? Regardless if the problem is an
> actual bug or only an need for action to simplify for users?

 As I said, I don't think a programmatic intervention makes sense, but I
 have nothing against a debconf note suggesting how users /
 administrators can reconfigure gtk2 after its installation to behave
 somehow like gtk1.

 Regarding firefox, it's a slightly different problem, you don't need to
 file a bug, I did it already.

   Regards,

-- 
Loïc Minier <lool@dooz.org>