[GUFSC] caso do ``c'' acentuado no GNOME 2

[Ricardo Grützmacher]

Aqui está a cópia de um email interessante da lista de desenvolvimento 
do Debian sobre o problema de acentuacão no GNOME 2.

Talvez nos arquivos tenham ainda outros melhores.

http://lists.debian.org/debian-devel-portuguese/2003/debian-devel-portuguese-200307/msg00029.html


     * To: debian-devel-portuguese em lists.debian.org
     * Subject: Re: [Bug 111334] Changed - us-intl keyboard produces 
c-acute instead of c-cedilla
     * From: Leandro Guimarães Faria Corsetti Dutra <lgcdutra em terra.com.br>
     * Date: Sun, 13 Jul 2003 09:41:35 +0200
     * Message-id: <pan.2003.07.13.07.41.32.948283 em terra.com.br>
     * Old-return-path: <glddp-debian-devel-portuguese em m.gmane.org>
     * Organization: Família Dutra
     * Sender: news <news em main.gmane.org>
     * User-agent: Pan/0.14.0 (I'm Being Nibbled to Death by Cats!)

	Há muito tempo reclamei do comportamento do teclado US Int'l
no Gtk+ 2.  Há alguns dias o Taylor finalmente deu uma resposta
completa, que me autorizou a publicar aqui.  Antes de ler, vale
lembrar que o estado atual é que é impossível digitar cê-cedilha no
us-intl em programas Gtk+ 2 a menos que se tenha LOCALE=pt_BR ou
LC_TYPE=pt_BR; nem pt_BR.UTF-8 funciona.

	Como estou sem tempo, procurando emprego, agradeceria
voluntários.


On Mon, 2003-07-07 at 15:43, Leandro Guimarães Faria Corcete Dutra
wrote:
 > Em Seg, 2003-07-07 Ã s 20:49, Owen Taylor escreveu:
 > > On Mon, 2003-07-07 at 14:17, Leandro Guimarães Faria Corcete Dutra
 > > wrote:
 > > > > +export GTK_IM_MODULE=xim is that option...
 > > > > +
 > > > > +(And no I'm *not* changing the severity of this to critical,
 > > > > +the current behavior of GTK+ is correct, just inconvienient
 > > > > +for Brazilian users. And a workaround is available.)
 > > >
 > > >   You should.  The workaround doesn't work on the Macintosh at all,
 > > > especially in the portables that lack AltGr.
 > >
 > > I understand the difficulty that not having an easy way of producing
 > > c_cedilla for typing Portuguese with a us_intl keyboard, but in
 > > the end, it's not something I'm going to drop everything for
 > > and rush out a new GTK+ release for.
 >
 >       We don't ask Gtk+ 3 just for this.  All we ask is (1) 
acknowledgement
 > this is a bug, instead of a thousand excuses, and (2) a reasonable fix
 > timeframe, given it is brokenness in previously working, production,
 > stable software.

(1) things which aren't bugs get closed in bugzilla *very* quickly.
     If I left it open, I thought it was something needing fixing.

(2) if someone sends me a patch that will speed up the time for
     a fix.

 > > dead_acute + c gives LATIN SMALL LETTER C WITH ACUTE. Clearly
 > > a critical bug!
 >
 >       Yes, it is, when you have loads of users relying on the old, 
perfectly
 > reasonable behaviour which has been changed for no other reason than
 > æsthetical nitpicking.

And they say that people in the US are parochial...

Perhaps it isn't clear ... compose sequences have nothing to do with
keyboard maps ... while the 'us_intl' keyboard map is basically used
only Brazil, if I changed the default GTK+ compose sequence, it would
affect *everybody* with a dead_acute key on their keyboard.

Prior to the introduction of UTF-8, there was a nice easy solution:

  - Western European users used compose sequence tables for ISO-8859-1
    which has c_cedilla and not c_acute

  - Eastern European users used compose sequence tables for ISO-8859-2
    which has c_acute and not c_cedilla

These days, we don't have that solution available, so we have to go
with something more sophisticated that takes the locale into
account, not just encoding.

 > > C with acute is a real letter used in various eastern European
 > > languages.
 >
 >       So what?  None of these various Eastern European languages has 
loads of
 > users expecting to get ć from '+c in an us_intl keymap.

How do I know? They wouldn't be sending me mail currently, would they?

 > > A) GTK_IM_MODULE=xim gives you 100% exactly the same key combinations
 > >    that every other X app has.
 > >
 > >    Of course, if your locale has LC_CTYPE=en_US.UTF-8, that will
 > >    give you the same "problem" as GTK+. Xlib can't guess that
 > >    you really are typing portuguese and don't give a damn
 > >    about eastern european languages any better than GTK+
 > >    can.
 >
 >       Actually I have all my locale pt_BR.UTF-8 and 
GTK_IM_MODULE=xim, yet it
 > doesn't work.  I assume it is something to do with the Mac keyboard:
 >
 > debora em limao:~$ locale
 > LANG=pt_BR.UTF-8
 > LC_CTYPE="pt_BR.UTF-8"
 > LC_NUMERIC="pt_BR.UTF-8"
 > LC_TIME="pt_BR.UTF-8"
 > LC_COLLATE="pt_BR.UTF-8"
 > LC_MONETARY="pt_BR.UTF-8"
 > LC_MESSAGES="pt_BR.UTF-8"
 > LC_PAPER="pt_BR.UTF-8"
 > LC_NAME="pt_BR.UTF-8"
 > LC_ADDRESS="pt_BR.UTF-8"
 > LC_TELEPHONE="pt_BR.UTF-8"
 > LC_MEASUREMENT="pt_BR.UTF-8"
 > LC_IDENTIFICATION="pt_BR.UTF-8"
 > LC_ALL=

No, this has nothign to do with the Mac keyboard. It simply is
a result of the fact that the pt_BR compose sequences are the same
for pt_BR.UTF-8 and en_US.UTF-8, identical to those that GTK+
uses in all locales by default.

I'm sure that XFree86 would be happy to get a contribution of
a /usr/X11R6/lib/X11/locale/pt_BR.UTF-8/Compose. If you look at
/usr/X11R6/lib/X11/locale/compose.dir, you'll find:

en_US.UTF-8/Compose:            pt_BR.UTF-8

 > > B) Creating an input method module that is exactly like
 > >    gtkimcontextsimple but that overrides dead_acute + c is
 > >    a pretty trivial excercise. There are various examples
 > >    in the GTK+ source code, in modules/input or you can look at:
 > >
 > >     http://gtk-im-extra.sourceforge.net/
 > >
 > >    to see how to do it without having to modify GTK+.
 > >
 > >    You can then force GTK+ to use it without having to
 > >    touch your locale variables at all by setting GTK_IM_MODULE=im_pt_br
 > >    (or whatever you call it.)
 >
 >       Why is it so hard to unbreak software you have to torture 
*users* like
 > that?  It is not like we are following the kernel mailing lists...
 >
 >       To tell you the truth, Gnome and Gtk+ seem to me to be in a kinda
 > schizophrenic mode.  On one hand you remove loadsa options lotsa people
 > relied on to make it simpler; on the other you break previously working
 > software, suggest a workaround instead of unbreaking it, and when told
 > the workaround doesn't always work suggest users fix it themselves!  So
 > what, are Gnome users supposed to be totally dumb or complete geniuses?

No, I don't expect *all* users to be hackers, but I am a little suprised
that *no* user from Brazil has sent me a patch. Brazil
has certainly produced plenty of smart hackers in other areas of
free software.

 > >    I'd love to see some convenient resolution to this issue
 > >    in GTK+, and I've suggested how to do this to various people
 > >    multiple times, but someone affected by it is going to have
 > >    to take the initiative.
 >
 >       Please suggest to me, and if it in my ability (severily limited 
when it
 > comes to coding) I will try.  Serious.

What needs to be done is:

  A) copy gtk+/modules/input/imcyrillic-translit.c to impt-br.c.
     (or imcedilla.c, perhaps)
  B)  Change all the references to 'cyrillic_translit' to 'cedilla'
  C) Remove the current compose sequences, replace them with
     the 6 ones you want to override.
     (dead_acute + C/c / Compose + apostrophe + C/c /
      Compose C/c apostrophe). grep for C_WITH_ACUTE in
     gtk+/gtk/gtkimcontextsimple.c to find the necessary
     lines, you'll find a small bug there ... one of the
     sequences with the Compose key is missing.
  D) Change the line
      ""                               /* Languages for which this module
is the default */
     to have "pt" rather than "". (The list is : separated if you
     want more than one language)
  E) Adjust the modules/input/Makefile.am
  F) Fix gtk+/gtk/gtkimmulticontext.c to always use LC_CTYPE, rather
     than to use LC_MESSAGES when available. (Search for LC_MESSAGES
     in that file)

Regards,
                                                 Owen