[Linux-Biella] input di tastiera no more working correctly

Pierpaolo Martinello pier.martinello a alice.it
Lun 29 Giu 2009 17:58:23 CEST


Paul TT ha scritto:
> find -iname *encodin*
> find -iname *key*
> danno risultati certamente estranei (sia in home che in etc)
> postpongo che non sembrerebbe un problema di localizzazzione allora.
> non mi fungono solo i caratteri che andrebbero scritti come 
> ISO_Level3_Shift (AltGr)+qualcosaltro
> sempreche' iso_coso sia corretto come altgr (lo imposto con xmodmap su 
> un tasto 'morto'), ma direi di si', gia' che altrove funziona come ci si 
> attende :(
> parrebbe quasi che le gtkappakose mi beffino ignorando il modificatore 
> suddetto
>   
>> hai un problema strano :)
>>   
>>     
> eh lo so, non so manco cosa poter cercare su gugol, azzzzz
>   
>> non riesci a vedere che file di configurazione ti ha toccato l'ultimo update
>>     
> potrei tentare un find per data, si', boh, mah... :D
>
>   
Non so quanto possa essere utile, ma credo possa avere attinenza con il 
tuo problema.
E' in portoghese, ma Ptt non ha sicuramente problemi a tradurre



Não tenho nenhuma objeção quanto à usar uma 'flag' para controlar a
conversão de/para UTF-8. Acho até bastante interessante este recurso.

Apenas gostaria de exclarecer uma dúvida que me ocorreu:

Temos usado o termo 'locale' nas discussões sobre este assunto, mas 'locale'
me parece estar relacionado com o idioma (inglês, espanhol, português,
russo, etc...) e não com o conjunto de caracteres.

A GTK+ adota como padrão o idioma do sistema operacional. No Windows, eu
posso alterar isto usando um comando como o abaixo:

set LANG=ru

No exemplo acima, eu altero o idioma para russo e as mensagens da GTK+
passam a ser neste idioma, mesmo o Windows sendo PT-BR. Veja imagem anexa.

Já UTF-8, eu vejo como um formato de representação de caracteres (charset).
O idioma (locale) poderia ser qualquer um.

Na função xhgtk_set, creio que deveríamos usar outro termo no lugar de
locale. Exemplo:

#define XHGTK_SET_UTF8  1

Local pAboutDialog := gtk_about_dialog_new()

XHGTK_Set( XHGTK_SET_UTF8, .F. ) // nao faz conversao
gtk_about_dialog_set_name( pAboutDialog, "óúç" ) // óúç em uf8

XHGTK_Set( XHGTK_SET_UTF8, .T. ) // faz conversao
gtk_about_dialog_set_version( pAboutDialog, "á é ó ú" )

Penso que assim ficaria mais clara a real utilidade da 'flag'.


Subject: [xhgtk-br] Locales de novo

Pessoal,

Nos ultimos dias fiz muitos testes e algumas conclusoes. Algumas das
mudanças que venho propondo no código core da xhgtk na conversao
automatica de locales usando g_locale_to_utf8 ou g_locale_from_utf8,
pode trazer mais benefícios do que problemas em mudança no código.

Bom como havia conversao na lista dos desenvolvedores, as versoes mais
recentes do gerenciadores de janelas X para linux, já usam por padrão
UTF8. Já o windows não.

Pois bem, se na aplicacao final, programarmos apenas em linux, usando
acentos ou nao, nao vamos ter problemas e talvez precisaríamos usar
g_locale..., mas não é o caso, a maioria vai programar em windows e o
code page do windows nao é aceito pela gtk, tendo que usarmos as
funcoes de conversao.

Porém se programarmos a aplicacao final em windows e formos compilar
em linux, tambem não funciona, pelo mesmo motivo, a codificacao é outra.

Ou seja, ou se programa em linux apenas e use pra compilar o mesmo
codigo fonte ou usa apenas windows e usamos a conversao tanto pra
linux como windows.

Complicado né, eu também achei.

exemplos:

gtk_about_dialog_set_name( pAboutDialog, "óúç" ) // óúç (UTF8)

este é um pedaço do código em linux, este código funciona em linux (no
linux ve-se como acentos normalmente) e windows sem precisar de
conversao, porem não é viável em windows apenas. Agora, se vc misturar
UTF8 com acentos, descobri um bug na gtk windows, gera GPF.

Enfim, estou propondo duas novas funcoes:
xhgtk_locale_to_utf8/xhgtk_locale_from_utf8

Internamente seria mais ou menos isso:

gchar * xhgtk_locale_to_utf8( gchar *szLocale )
{
  gchar *szText;

  if (nSetLocale == 1)
    szText = g_locale_to_utf8(szLocale, -1, NULL, NULL, NULL);
  else
    szText = g_strdup( szLocale );

  return szText;
}

e seria usado assim:

HB_FUNC( GTK_ABOUT_DIALOG_SET_NAME )
{
  gchar *szText = xhgtk_locale_to_utf8(hb_parcx(2));
  gtk_about_dialog_set_name( (GtkAboutDialog*) hb_parptr(1), szText );
  g_free(szText);
}

e uma nova funcao XHGTK_SET()

HB_FUNC( XHGTK_SET )
{
switch (hb_parni(1))
        {
         case XHGTK_SET_LOCALE :
nSetLocale = hb_parl(2);
break;
}
}

Com isso a gente abre uma nova possiblidade de um conjunto de SET's.

Voltando..., com isso, este código resolveria o problema, podendo
programar o codigo em windows/linux, vice versa, usando acentos em
unicode ou nao

exemplo:

#define XHGTK_SET_LOCALE   1

Local pAboutDialog := gtk_about_dialog_new()

XHGTK_Set( XHGTK_SET_LOCALE, .F. ) // nao faz conversao
gtk_about_dialog_set_name( pAboutDialog, "óúç" ) // óúç em uf8

XHGTK_Set( XHGTK_SET_LOCALE, .T. ) // faz conversao
gtk_about_dialog_set_version( pAboutDialog, "á é ó ú" )


Buona Fortuna

-- 
Pierpaolo Martinello
IW1CUY Ham Radio From Biella Italy
Linux User 177880 




Maggiori informazioni sulla lista Linux