Re: [Bug 111334] Changed - us-intl keyboard produces c-acute instead of c-cedilla
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@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
--
_
/ \ Leandro Guimarães Faria Corsetti Dutra +41 (21) 648 11 34
\ / http://br.geocities.com./lgcdutra/ +41 (78) 778 11 34
/ \ Answer to the list, not to me directly! +55 (11) 5686 2219
Rate this post if helpful: http://svcs.affero.net/rm.php?r=leandro
Reply to: