Cette nouvelle version contient des nouveaux widgets et quelques améliorations (performances et widgets) tout en restant compatible source et binaire avec les versions précédentes.
GTK+ est utilisé par GIMP, les environnements graphiques GNOME, XFCE et ROX et un grand nombre d'applications sur diverses plateformes. GNOME Office 1.2 est également annoncé (avec AbiWord 2.2 et Gnumeric 1.4). GTK+ 2.6 sera utilisé par GNOME 2.10 actuellement en développement et prévu pour mars 2005.
Aller plus loin
- GTK+ (3 clics)
- annonce GTK+ 2.6 (0 clic)
- GTK+-2.6 Specific Notes (1 clic)
- GTK-Fr (4 clics)
# Pango 1.8.0 et glib 2.6.0
Posté par itstimetogo . Évalué à 7.
http://mail.gnome.org/archives/gnome-announce-list/2004-December/ms(...)
http://mail.gnome.org/archives/gnome-announce-list/2004-December/ms(...)
# UTF-8 le standard des noms de fichier
Posté par itstimetogo . Évalué à 6.
The assumption of GLib and GTK+ by default is that filenames on the filesystem are encoded in UTF-8 rather than the encoding of the locale; the GTK+ developers consider that having filenames whose interpretation depends on the current locale is fundamentally a bad idea.
Très bien. UTF-8 n'est pas encore assez utilisé par défaut. Ça va "forcer" les autres à utiliser UTF-8.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Pascal Terjan (site web personnel) . Évalué à 10.
If you have filenames encoded in the encoding of your locale, then
you may want to set the G_FILENAME_ENCODING environment variable:
G_FILENAME_ENCODING=@local
export G_FILENAME_ENCODING
(Earlier versions of GLib 2.x required a different environment variable
setting; G_BROKEN_FILENAMES=1 to achieve the same effect; this
is still supported, but G_FILENAME_ENCODING is preferred.)
De ce que je comprend, ils ont donc juste changé le nom de la variable...
[^] # Re: UTF-8 le standard des noms de fichier
Posté par itstimetogo . Évalué à 1.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Pascal Terjan (site web personnel) . Évalué à 9.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par itstimetogo . Évalué à 7.
Tout ça est bien réducteur... et c'est ignorer la démarche de fond qui est très importante et bénéfique à tous. Pour être honnète ce type de réflexion me navre (ou alors je t'ai mal compris).
Red Hat a participé au gros du travail dans la libc.
Red Hat est le mainteneur de gtk+, pango, glib et fait près d'un tier du boulot. Ce n'est pas que essuyer les plâtres mais pour faire avancer au mieux le logiciel libre. Meilleur est le logiciel libre, meilleur est l'offre de Red Hat fasse à ses concurrents.
Red Hat bosse beaucoup sur l'internationalisation car ils ont un gros marché dans les pays asiatiques et sont implantés un peu partout dans le monde.
La démarche n'est pas d'essuyer les plâtres et "débugger sur le tard" avec les utilisateurs mais d'installer des standards.
Une nouvelle technologie ne sort que lorsqu'elle est estimée bonne. Par exemple pour RH8.0 et RH9, il devait y avoir ACL et ACPI (toujours activé dans les versions betas). Et bien les release finales sont sortis sans (ou désactivé par défaut) car il y avait des problèmes. FC2 devait avoir SeLinux par défaut et bien c'est sorti avec SeLinux désactivé par défaut. Les tests sont fait dans rawhide ou les test/beta releases et non avec les releases finales pour justement éviter que les gens "essuient les plâtres". Trouver des bugs durant une phase de test ce n'est pas essuier les plâtres. C'est tout simplement débugger, faire le travail de mise au point. Lorsque la fonctionnalité est au point, elle sort en release finale et cette disponibilité "officielle" est un signal aux développeurs tières et ils savent qu'ils peuvent, voire qu'ils doivent, prendre en compte un nouveau "standard".
Évidement je ne prétend pas qu'une release finale est sans défaut. J'indique (avec insistance) qu'une release finale, même avec une nouvelle fonctionnalité, n'est pas une base pour les tests et le débuggage. Et évidemment aussi, t'as plus de change d'avoir des bugs lorsque tu diffuses des nouvelles technologies (même si tu penses avoir corrigé tous les bugs) que si tu restes conservateur.
Mais si personne n'adopte de nouveaux standards pour éviter "d'essuyer les plâtres" (plus pécisément pour éviter les problèmes de compatibilité) alors il n'y a jamais d'adoption de nouveaux standards qui font avancer les choses.
Ainsi FC2 est sorti avec 4KSTACK (incompatible avec l'ancien 8KSTACK) et ça a forcé (ou invité) nvidia a sortir son driver compatible 4KSTACK et celà a permis de porter et corriger plein de drivers.
Si personne ne sort une distribution avec 4KSTACK pour rester compatible avec l'existant et choyer ses clients/utilisateurs, alors Linux restera à 8KSTACK et les utilisateurs ne profiteront jamais des améliorations de 4KSTACK.
Idem pour NPTL, UTF-8, etc.
La démarche de Red Hat est "courageuse" car elle ajoute des incompatibilités qui gènent les utilisateurs. En effet Red Hat prend le risque de "froisser" des utilisateurs (donc de les perdre) à cause d'incompatibilité avec l'existant et ce dans l'objectif de faire avancer le logiciel libre (ou seulement son propre OS mais ça revient au même puisque c'est du logiciel libre). Ce risque pris par Red Hat profite à tout le monde et pas uniquement à Red Hat. Évidement ce risque est aussi accompagné de l'avantage de proposer une nouvelle caractéristique qui peut séduire du monde. Heureusement jusqu'à maintenant le rapport avantage/risque n'est pas mauvais.
Je ne demande pas que tous le monde fasse ça, mais seulement de respecter cette démarche qui profite au logiciel libre.
Red Hat n'est pas le seul à faire ça, mais dans ce domaine c'est le plus remarquable.
Pascal Terjan ne le prend pas mal, j'ai peut-être tout simplement mal interprété ta phrase.
> que ca marche bien depuis pas mal de temps
Les "problèmes" d'UTF-8 que j'ai rencontré (moi même ou sur des forums) sont à 95 % des gens qui utilisent autre chose que UTF-8 sur un système UTF-8. Par exemple des gens qui importent une base codée en iso8859 dans un SGDB qui tourne en UTF-8. Donc forcément ça merde. C'est comme ouvrir un fichier UTF-8 sur un système qui ne supporte pas UTF-8. C'est principalement un problème d'adoption du standard UTF-8 et non un problème d'UTF-8. De plus la commande iconv pour convertir les fichiers est très peu connue.
Dans le même registre ce sont les gens qui font des tris qui dépendent de la locale. Donc lorsque la locale change (pour UTF-8) ça merde. Ce n'est pas UTF-8 qui fait "merder" c'est le changement de locale. Tu changes vers une locales (non UTF-8) qui ignore les majuscules/minuscules et tu as le même problème.
Pour moi le plus gros problème d'UTF-8 était la lenteur de grep :-)
Ça c'est significativement amélioré.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Vincent Pelletier . Évalué à 8.
Tout a fait d'accord.
> j'ai peut-être tout simplement mal interprété ta phrase
Je pense effectivement qu'il n'y avait rien de péjoratif dans cette expression. Pour moi ça veut juste dire qu'ils ont été les premiers (SuSe n'est pas UTF-8 ? Ou alors elle y serait passé après...) à intégrer UTF-8 dans un système homogène.
> C'est principalement un problème d'adoption du standard UTF-8 et non un problème d'UTF-8
Il y a aussi le problème des programmes qui ne supportent pas UTF-8. Et là je pointe du doigt les terminaux non-graphiques - hormis l'excellent jfbterm, mais peut-on l'apeller non-graphique ?
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Philip Marlowe . Évalué à 7.
Tu as dû mal comprendre. Essuyer les plâtres veut dire endosser les défauts de jeunesse d'un élément présentant un caractère de nouveauté. Ce n'est en rien péjoratif tel que Pascal Terjan l'a exprimé.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Pascal Terjan (site web personnel) . Évalué à 6.
Cela signifie juste que RedHat a été le premier à franchir le pas et a souffert de tous les logiciels qui n'étaient pas prêts et qu'il a fallu corriger. Grace à cela les autres peuvent maintenant franchir le pas avec beaucoup moins de travail.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par gnumdk (site web personnel) . Évalué à 4.
>autres à utiliser UTF-8.
C'est super tout ca mais on fait quoi de l'existant? La suse est par defaut en utf8 et la premiere chose que je fais apres une install, c'est la repasser en iso.
Pkoi?
1) flemme de renommer tous mes fichiers présent sur mes partoches.
2) Probleme de compatiblité avec le reste du monde
La premiere est génante, surtout quand certains logiciels n'arrivent meme plus a parcourir l'arborescence...
la seconde est la plus gavante, tu recois un fichier d'un windowsien et blame tu peux pas le visualiser correctement (note tout de meme, windows sauvegarde les nom de fichier en utf8 mais pas leur contenu).
De plus, si quelqu'un peut m'expliquer l'interet d'enregistrer ses noms de fichier en utf8, je n'y vois aucun interet, a part le fait de se la peter en soirée : "Quoi? t'utilises pas utf8? T'es hasbeen toi!"
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Eric P. . Évalué à 6.
Je ne connais pas particulièrement Windows, mais on est justement en train de parler des noms de fichiers !
L'enregistrement des fichiers, ce n'est pas Windows qui le fait le programme qui crée ce fichier. D'ailleurs, il me semble que même le Notepad (bloc-note) de Windows sait enregistrer le contenu d'un fichier texte en UTF-8.
L'intérêt, c'est justement d'être compatible avec le reste du monde...
L'UTF-8 te permet d'avoir un nom de fichier lisible depuis n'importe quel système dans le monde.
Alors que si tu encodes ton nom de fichier dans une page de code locale française, les accents par exemples seront mal interprêtés par le type qui essayera de lire ton fichier.
Tu vas me dire: oui mais j'ai pas de copains en Asie, donc je m'en fous.
Ca peut être vrai mais il faut quand même penser que d'une part il y a pas que les asiatiques qui utilisent des pages de code différentes, il y a aussi plein de pays d'Europe, et d'autre part si fais du libre tu seras amener à mettre tes sources sur Internet et celui qui lira tes fichiers pourra très bien être chinois ou japonais.
Excusez l'absence d'accents dans mes commentaires, j'habite en Australie et n'ai pas de clavier francais sous la main.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par gnumdk (site web personnel) . Évalué à 1.
>enregistrer le contenu d'un fichier texte en UTF-8.
Ben vas y, vas leur expliquer que c'est mieux de passer par utf8...
Mais bon, il n'y pas que ca, passer tout son systeme en utf8, c'est aussi se retrouver avec tous les tags de ses ogg en vrac, ... Désolé, mais j'ai autre chose à faire qu'a perdre du temps avec ca.
>Tu vas me dire: oui mais j'ai pas de copains en Asie, donc je m'en fous.
Mwai, je veux pas dire, mais ca va m'apporter quoi de pouvoir afficher le dernier spam venu d'asie correctement grace à utf8? Je ne lis pas le chinois ou autre, donc aucun interet. Pour les deux langues que je connais(anglais et francais), latin9 fait l'affaire. Donc, non, utf8 ne m'apporte rien à part des emmerdes.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par itstimetogo . Évalué à 6.
C'est une déformation de dire ça.
Avoir 50 codages apporte des emmerdes. En avoir qu'un n'apporte pas d'emmerde.
Tu préfères être emmerdé à jamais que de t'emmerder maintenant "une fois pour toute" en passant à utf-8.
Libre à toi.
Néanmoins, je pense qu'il manque de documentation pour faire un passage sans douleur vers utf-8 (migration des données, convertion des noms de fichier, ...).
[^] # Re: UTF-8 le standard des noms de fichier
Posté par gnumdk (site web personnel) . Évalué à -2.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
[^] # -- Coupure Pub --
Posté par calandoa . Évalué à 10.
- Ah ben oui, dites donc! j'ai tous mes é qui font des é.
- Il faut utiliser Utrac, qui reconnaitra automatiquement le charset de vos fichiers même à 60° et effectuera la bonne conversion, tout en respectant l'environnement (et ses variables).
http://utrac.sourceforge.net(...) (existe aussi en bibliothèque)
[^] # Re: UTF-8 le standard des noms de fichier
Posté par imalip . Évalué à 10.
Et hop, un coup de doc Vorbis :
http://www.xiph.org/ogg/vorbis/doc/Vorbis_I_spec.html#id4744873(...)
The comment vectors are structured similarly to a UNIX environment variable. That is, comment fields consist of a field name and a corresponding value and look like:
comment[0]="ARTIST=me";
comment[1]="TITLE=the sound of Vorbis";
The field name is case-insensitive and may consist of ASCII 0x20 through 0x7D, 0x3D ('=') excluded. ASCII 0x41 through 0x5A inclusive (characters A-Z) is to be considered equivalent to ASCII 0x61 through 0x7A inclusive (characters a-z).
The field name is immediately followed by ASCII 0x3D ('='); this equals sign is used to terminate the field name.
0x3D is followed by 8 bit clean UTF-8 encoded value of the field contents to the end of the field.
Les tags vorbis sont en principe stoques nativement en UTF8. A priori, si tu les as autrement, soit ta lib est hackee, soit tu utilises des tags ID3.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par nicolassanchez . Évalué à 4.
L'UTF-8 te permet d'avoir un nom de fichier lisible depuis n'importe quel système dans le monde.
Et l'UTF-16, ça sert à quoi ?
[^] # Re: UTF-8 le standard des noms de fichier
Posté par nicolassanchez . Évalué à 4.
En voyant UTF-8, je me suis dit qu'il doit y avoir d'autres UTF...
Et effectivement, il y a au moins UTF-7, UTF-16 et UTF-32.
Mais à quoi servent-ils si UTF-8 permet effectivement d'encoder n'importe quel texte ?
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Romain Vinot . Évalué à 10.
UTF-8 est un codage à longueur variable. Les 7 premiers bits du premier octet sont les caractères ASCII-7bits standards. Donc tous les caractères alphanumériques de base s'écrivent de la même façon en UTF-8 et en ASCII (et donc LATIN-*). Le 8ème bit permet d'indiquer si le caractère est codé sur 1 ou plusieurs octets. Les lettres accentués sont codés en UTF-8 sur 2 octets. Et on continue, s'il y a besoin de plus de deux octets, le dernier bit sert à indiquer qu'on passe au troisième octet...
Du coup, pour les langues asiatiques, on a besoin de beaucoup d'octets pour chaque lettre. Du coup, on a :
UTF-16 : tous les caractères sont codés sur 2 octets. Comme ça les caractères asiatiques sont toujours codés sur 2 caractères plutôt que sur 4 caractères en UTF-8, ce qui divise la taille des fichiers par 2. Et on s'est rendu compte que 65000 caractères, c'était peut-être pas suffisant du coup :
UTF-32...
Conclusion, tout le monde ne jure que par l'UTF-8 parce que c'est le plus pratique pour les américains (leurs caractères ASCII-7 bits resent inchangés !), c'est presque aussi pratique pour les européens (quelques caractèrse à mettre sur 2 octets seulement). Pour les asiatiques, ce n'est pas encore la panacée puisque leurs documents prennent plus de place qu'ils ne pourraient en prendre avec de l'UTF-16.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Vivi (site web personnel) . Évalué à 7.
C'est surtout parce que ça reste compatible avec les API en char* : le byte 0 n'intervient qu'en fin de chaîne avec UTF-8 alors qu'il peut apparaître en plein milieu avec UTF-16 ou UTF-32.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Éric (site web personnel) . Évalué à 5.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Croconux . Évalué à 6.
L'UTF-8 présente malgré tout un problème de taille : Le fait qu'un caractère n'ait pas une longueur variable, justement. Avec des caractères sur 8, 16, ou 32 bits les manipulations de chaines sont très faciles : nombre de caracactère = taille de la chaine / taille d'un caractère. Avec de l'UTF-8 on est obligé d'aller voir le contenu de la chaîne en détail pour faire des manipulations élémentaires comme des copies de sous chaînes, etc. On gagne en place (on n'utilise que ce qui est nécessaire pour représenter un caractère) mais au niveau perf ça épile pas un caribout.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Il faut aussi distinguer l'encodage (UTF-8) du charset (UCS). L'encoage, c'est la façon de représenter une suite de nombres, et le charset, c'est l'association nombre -> caractère. UTF-8 n'est pas completement universel (preuve en est l'existance d'UTF-16 par exemple), mais UCS, par contre, devrait tenir un moment en satisfaisant au mieux les besoins de tout le monde.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Vivi (site web personnel) . Évalué à 3.
UTF-8, UTF-16 et UTF-32 ne sont que des codages pour le même charset, UCS. Ils sont tous les 3 capables de représenter n'importe quel élément d'UCS.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Pablo Saratxaga (site web personnel) . Évalué à 4.
Et puis, avec l'extension de l'espace d'unicode à plusieurs plans, l'UTF-16, qui était sensé être justemment un encodage à longuer fixe d'octets, ne l'est plus, et UTF-16 présente tous les inconvenients de UTF-8 sans en presenter les avantages.
De plus, il est impossible de travailler sur des chaînes de texte unicode caractère par caractère en ignorant le contexte; parcequ'il y a des caractères combinatoires, et des écritures où la forme depends du contexte; donc même en UTF-32 (qui, tout comme UTF-16, est incompatible avec lui même en clair, car il y a des petits et des grands boutistes; alors que UTF-8 est le même partout, encore un avantage de UTF-8), même avec 4 octets par caractère, on ne pourrait pas faire des manipulations aveugles et avoir un programme correct.
UTF-8 est le meilleur encodage à utiliser sur un système de type Unix, vu ces avantages, sa philosophie (c'est en fait une sorte de continuation de EUC (Extended Unix Coding), et, tout simplement, le fait que c'est ce qui est utilisé presque partout (note qu'en interne des boîtes noires que sont pour l'utilisateur les bibliothèques de fonctions, un autre encodage peut être utilisé; ainsi la libc utilise un encodage fixe sur 32 bits il me semble).
[^] # Re: UTF-8 le standard des noms de fichier
Posté par TImaniac (site web personnel) . Évalué à 2.
http://fr.wikipedia.org/wiki/UTF-8(...)
Je pense que l'intérêt de l'UTF-8 par rapport aux suivant (16/32) et la compatibilité avec l'ASCII.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Olivier Jeannet . Évalué à 0.
Ca permet d'économiser de l'espace par rapport à UTF-16 ou UTF-32 quand la majorité des caractères tient sur 7 bits, ce qui est le cas en français par exemple (les accents ne sont pas majoritaires). En plus les caractères de l'ASCII-US (7 bits) sont inchangés en UTF-8, aucun problème de compatibilité.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Zanton . Évalué à -1.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par ookaze . Évalué à 1.
Donc plus universel que l'ISO (tout le monde utiliserait la même chose), donc mieux.
Au niveau du navigateur, c'est bien de faire des pages en UTF-8, mais encore faut-il configurer ton serveur Web, afin que celui-ci prévienne qu'il envoie de l'UTF-8. Parce que par défaut, les serveurs Web doivent envoyer de l'ISO-8859-1. Donc si tu lui dit rien à ton serveur, il croît que ta page est en ISO-8859-1, alors avec de l'UTF-8 ça peut pas fonctionner.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Zanton . Évalué à 0.
D'ailleurs, si un serveur est en UTF-8, est ce qu'il pourra quand meme bien "rendre" les pages en ISO-8859 ?
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Emmanuel Seyman . Évalué à 4.
Oui (en tout cas pour Apache).
Tout depend de la config d'Apache (la valeur de la directive AddDefaultCharset de ton httpd.conf) et du charset précisé dans les entêtes de tes pages HTML.
Cela dit, je pense qu'il vaut mieux que les deux valeurs coincident.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par itstimetogo . Évalué à 3.
Rien à voir. Un serveur donne un contenu et le contenu peut-être n'importe quoi dont du binaire. Tu connais le charmap utilisé par le binaire ?
Tous les serveurs web sont compatibles UTF-8.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Marc Perron (site web personnel) . Évalué à 3.
<meta content="text/html;charset=utf-8" http-equiv="content-type">
Donc on indique que la page utilise le UTF-8?
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Vincent Danjean . Évalué à 1.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par dinomasque . Évalué à 2.
BeOS le faisait il y a 20 ans !
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Vincent Danjean . Évalué à 1.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par itstimetogo . Évalué à 7.
C'est valable pour utf-8 et tous les autres codages !
> Alors que si j'utilise ISO-8859-15, là je n'ai aucun souci.
Car tu n'indiques pas le codage de la page et ton navigateur est configuré en iso-8859.
Fais un fichier utf-8 comme tu le fais maintenant (c-à-d sans indiquer le codage) et visualise dans Mozilla configurer pour utiliser utf-8 par défaut. Ça passe bien de la même façon.
Mozilla supporte utf-8.
> Si UTF-8 demande à tous les développeurs de logiciels de passer à cette norme, je ne sais pas s'ils vont être d'accord...
Et bien ils sont tous d'accord à 95 % minimum. Il n'y a presque plus de programmes qui ne supportent pas UTF-8.
Et il n'y a qu'une minorité qui veut continuer à se faire chier avec 50 codages différents.
Ce n'est pas UTF-8 vs iso-8895 mais UTF-8 vs ANSI_X3.110-1983 ANSI_X3.4-1968 ARMSCII-8 ASMO_449 BIG5 BIG5-HKSCS BS_4730 BS_VIEWDATA CP10007 CP1125 CP1250 CP1251 CP1252 CP1253 CP1254 CP1255 CP1256 CP1257 CP1258 CP737 CP775 CP949 CSA_Z243.4-1985-1 CSA_Z243.4-1985-2 CSA_Z243.4-1985-GR CSN_369103 CWI DEC-MCS DIN_66003 DS_2089 EBCDIC-AT-DE EBCDIC-AT-DE-A EBCDIC-CA-FR EBCDIC-DK-NO EBCDIC-DK-NO-A EBCDIC-ES EBCDIC-ES-A EBCDIC-ES-S EBCDIC-FI-SE EBCDIC-FI-SE-A EBCDIC-FR EBCDIC-IS-FRISS EBCDIC-IT EBCDIC-PT EBCDIC-UK EBCDIC-US ECMA-CYRILLIC ES ES2 EUC-JISX0213 EUC-JP EUC-JP-MS EUC-KR EUC-TW GB18030 GB2312 GBK GB_1988-80 GEORGIAN-ACADEMY GEORGIAN-PS GOST_19768-74 GREEK-CCITT GREEK7 GREEK7-OLD HP-ROMAN8 IBM037 IBM038 IBM1004 IBM1026 IBM1047 IBM1124 IBM1129 IBM1132 IBM1133 IBM1160 IBM1161 IBM1162 IBM1163 IBM1164 IBM256 IBM273 IBM274 IBM275 IBM277 IBM278 IBM280 IBM281 IBM284 IBM285 IBM290 IBM297 IBM420 IBM423 IBM424 IBM437 IBM500 IBM850 IBM851 IBM852 IBM855 IBM856 IBM857 IBM860 IBM861 IBM862 IBM863 IBM864 IBM865 IBM866 IBM866NAV IBM868 IBM869 IBM870 IBM871 IBM874 IBM875 IBM880 IBM891 IBM903 IBM904 IBM905 IBM918 IBM922 IEC_P27-1 INIS INIS-8 INIS-CYRILLIC INVARIANT ISIRI-3342 ISO-8859-1 ISO-8859-10 ISO-8859-11 ISO-8859-13 ISO-8859-14 ISO-8859-15 ISO-8859-16 ISO-8859-2 ISO-8859-3 ISO-8859-4 ISO-8859-5 ISO-8859-6 ISO-8859-7 ISO-8859-8 ISO-8859-9 ISO-IR-197 ISO-IR-209 ISO-IR-90 ISO_10367-BOX ISO_10646 ISO_2033-1983 ISO_5427 ISO_5427-EXT ISO_5428 ISO_646.BASIC ISO_646.IRV ISO_6937 ISO_6937-2-25 ISO_6937-2-ADD ISO_8859-1,GL ISO_8859-SUPP IT JIS_C6220-1969-JP JIS_C6220-1969-RO JIS_C6229-1984-A JIS_C6229-1984-B JIS_C6229-1984-B-ADD JIS_C6229-1984-HAND JIS_C6229-1984-HAND-ADD JIS_C6229-1984-KANA JIS_X0201 JOHAB JUS_I.B1.002 JUS_I.B1.003-MAC JUS_I.B1.003-SERB KOI-8 KOI8-R KOI8-T KOI8-U KSC5636 LATIN-GREEK LATIN-GREEK-1 MAC-CYRILLIC MAC-IS MAC-SAMI MAC-UK MACINTOSH MSZ_7795.3 NATS-DANO NATS-DANO-ADD NATS-SEFI NATS-SEFI-ADD NC_NC00-10 NEXTSTEP NF_Z_62-010 NF_Z_62-010_(1973) NF_Z_62-010_1973 NS_4551-1 NS_4551-2 PT PT154 PT2 RK1048 SAMI SAMI-WS2 SEN_850200_B SEN_850200_C SHIFT_JIS SHIFT_JISX0213 T.101-G2 T.61-7BIT T.61-8BIT TCVN5712-1 TIS-620 TSCII UTF-8 VIDEOTEX-SUPPL VISCII WIN-SAMI-2 WINDOWS-31J.
Tu vois le problème ?
[^] # Re: UTF-8 le standard des noms de fichier
Posté par pas_moi . Évalué à 9.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par itstimetogo . Évalué à 4.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Philippe F (site web personnel) . Évalué à 2.
Je ne connais pas bien les histoires d'unicode, mais je sais que Qt stocke ses chaines de caracteres en UCS2 et gtk en UTF8, ce qui oblige des conversions permanentes losrque tu essayes d'utiliser les deux en meme temps.
Est-ce que l'utf8 est plus adapte pour les noms de fichiers ? J'imagine que l'encodage du nom du fichier n'est pas precise a priori, et que donc chaque programme le lit comme il l'entend. En fait, ce qu'il faudrait, c'est des metadata pour preciser l'encodage du nom...
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Emmanuel Seyman . Évalué à 5.
UCS-2 == UTF16
[^] # Re: UTF-8 le standard des noms de fichier
Posté par itstimetogo . Évalué à 1.
Juste. Le noyau n'a aucune contrainte sauf une. Le nom du fichier doit se terminer par (char)'0' (doit être un "char *"). Pas un (int)0 ou (int16)0. D'où l'utilisation de utf8 qui respecte ça. utf8, ucs, utf16, utf32 c'est le même charset, c'est unicode. Mais c'est différente façon de représenter unicode. utf8 est compact et compatible "char *".
> En fait, ce qu'il faudrait, c'est des metadata pour preciser l'encodage du nom...
Ce qui est une erreur.
Premièrement, le noyau ne ferait rien de ça.
Deuxièmement les applis ne ferait rien de ça aussi. Sauf lors de l'affichage.
Troisièmement, tar/cpio/etc se stockent pas les attributs étendus. iso9660 n'a pas d'attribut étendu, etc.
Et pourquoi pas ajouter le codage du document aussi ?
Et pourquoi pas ajouter le type mime ?
Bref, c'est une erreur de faire ça.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par dinomasque . Évalué à 3.
Ca offrait une puissance folle au système. Login: avait même publié un article en quelques pages qui expliquait comment construire un client mail en quelques clics à base de live queries à intégrer au menu Be.
C'est vrai que c'était agaçant de "perdre" les attributs étendus dans des fichiers qui n'étaient pas protégés dans des archives ZIP avant d'être transférés sur Internet ou un CD-ROM cela dit.
Par contre tu m'étonnes en disant que tar ne conserve pas les attributs étendus. Il me semble bien que les attributs des applications BeOS distribués dans des tarballs étaient conservés (je me trome peut-être).
BeOS le faisait il y a 20 ans !
[^] # Re: UTF-8 le standard des noms de fichier
Posté par itstimetogo . Évalué à 1.
Star le fait (du moins pour ACL).
Pour moi les attributs étendus peuvent être utilisés lorsque "ça regarde le noyau". Par exemple pour ACL ou SeLinux. Pour le reste il faut le faire un userland. Sinon tu te retrouves a mettre les propriétés des fenêtres nautilus dans les attributs étendus et quand tu sauvegardes ou copies tu copies aussi les paramètres nautilus. Ce qui n'est pas très cool.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par ookaze . Évalué à 1.
Les attributs dont le grand-parent parle, ça ressemble plus aux attributs sous Windows (aïe pas taper !), ça fait partie intégrante de la description du fichier au niveau du fs.
Il me semble que tar ne supporte toujours pas ces attributs sous Linux, et il me semble aussi que cette intégration est en cours.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Emmanuel Seyman . Évalué à 6.
Mais, faut pas faire ça à la main, malheureux !
Newsforge avait fait un article sympa sur la conversion en Unicode (avec des scripts et tout): http://www.newsforge.com/article.pl?sid=04/10/27/1631244(...)
Puis, on peut aussi utiliser des scripts du style conmv (http://freshmeat.net/projects/convmv/(...)).
Sachant que UTF-8 est compatible avec l'ASCII, la conversion sera restriente a ton home.
> 2) Probleme de compatiblité avec le reste du monde
Ben non, justement.
Le gros intéret de UTF-8, c'est justement de reunir tout le monde avec un charset unique pour améliorer la compatibilité.
# Xfce et Gnome, quels liens ?
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 3.
Je sais que ce genre de question est du style 'flou' et que les prévisions en informatique (5*640k) impossibles, mais dans certains contextes, il faut voir à long terme, d'ou mes interrogations...
[^] # Re: Xfce et Gnome, quels liens ?
Posté par cosmocat . Évalué à 6.
Après, y'en a un qui se veux plus minimaliste que l'autre....
[^] # Re: Xfce et Gnome, quels liens ?
Posté par ookaze . Évalué à 0.
Par exemple, rien que pour intégrer les thèmes de Gnome, il faut une bonne partie des modules Gnome.
[^] # Re: Xfce et Gnome, quels liens ?
Posté par Biscotte . Évalué à 4.
Pour appuyer, je cite xfce.org : http://xfce.org/index.php?page=documentation&lang=fr(...)
"La compilation des modules de Xfce 4 dépend de :
* pkconfig
* GTK+ >= 2.2
* libxml2
* libdbh (et encore celle la c'est pour le gestionnaire de fichiers de xfce4 : xffm)
Dépendances optionnelles :
* librsvg >= 2.2.x
* libstartup-notification >= 0.5"
Donc non Xfce4 n'utilise pas une grosse partie des infrastructures de Gnome.
Par contre ils essaient de respecter les normes de Freedesktop.
Aprés forcément si tu veux utiliser nautilus ou une autre appli Gnome, là t'auras besoin des bibliothèques Gnome ...
[^] # Re: Xfce et Gnome, quels liens ?
Posté par Thierry . Évalué à 0.
Merci, ça me semble bien répondre à mes interrogations...
[^] # Re: Xfce et Gnome, quels liens ?
Posté par ookaze . Évalué à 0.
Bon alors c'est optionnel OK.
Parce que j'installe aussi le xfce-gtk-engine ou un truc comme ça, et pour installer ça, j'ai toujours eu besoin d'un tas de modules gnome (je remonte jusqu'au libgnomeui, en passant par gnome-vfs).
Du coup, mon XFCE peut utiliser les thèmes Gnome. Je suppose donc que ce sont des plus, et pas qqch d'obligatoire.
[^] # Re: Xfce et Gnome, quels liens ?
Posté par Prosper . Évalué à 1.
justement oui.
[^] # Re: Xfce et Gnome, quels liens ?
Posté par Jean-François Wauthy . Évalué à 3.
jf@palpatine:~$ ldd `which xfwm4`
linux-gate.so.1 => (0xffffe000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb7fb6000)
libxfce4mcs-client.so.2 => /usr/lib/libxfce4mcs-client.so.2 (0xb7fb0000)
libxfcegui4.so.3 => /usr/lib/libxfcegui4.so.3 (0xb7f63000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb7c6f000)
libxfce4util.so.1 => /usr/lib/libxfce4util.so.1 (0xb7c57000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb7bd8000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x4bc6a000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb7bc0000)
libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0xb7bb9000)
libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0xb7bad000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb7b71000)
libm.so.6 => /lib/libm.so.6 (0xb7b4e000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7b13000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7b0e000)
libdl.so.2 => /lib/libdl.so.2 (0xb7b0a000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7a84000)
libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0xb7a75000)
libstartup-notification-1.so.0 => /usr/lib/libstartup-notification-1.so.0 (0x4c17f000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0xb7a6d000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0xb7a55000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb798b000)
libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0xb7987000)
libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0xb797f000)
libc.so.6 => /lib/libc.so.6 (0xb7867000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0xb785e000)
libXinerama.so.1 => /usr/X11R6/lib/libXinerama.so.1 (0xb785b000)
libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0xb7849000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb77c8000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x4c135000)
libXcursor.so.1 => /usr/X11R6/lib/libXcursor.so.1 (0xb77bf000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb7790000)
/lib/ld-linux.so.2 (0xb7feb000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x4c0fd000)
libz.so.1 => /lib/libz.so.1 (0xb777c000)
Pour répondre à Thierry je ne pense pas que Xfce ne dérive vers un outil geek; en témoignent les nouveaux outils tels que xfce4-appfinder, xfce4-menueditor, l'éditeur de raccourcis clavier, la gestion des queues d'imprimantes, le support du mode Kiosk...
[^] # Re: Xfce et Gnome, quels liens ?
Posté par durandal . Évalué à 2.
[^] # Re: Xfce et Gnome, quels liens ?
Posté par Philip Marlowe . Évalué à 2.
[^] # Re: Xfce et Gnome, quels liens ?
Posté par Jean-François Wauthy . Évalué à 2.
[^] # Re: Xfce et Gnome, quels liens ?
Posté par Couderc Romain . Évalué à 1.
Utilise les scripts de udev pour lancer le filemanager sur le point de montage de ton peripherique amovible.
Tu devrais pouvoir faire cela en creant dans /etc/dev.d/block/ (sur debian sid c'est ici...) un script comme b-mount.dev par exemple.
Dedans tu as droit à des variables d'env comme ACTION(add|remove) et DEVNAME. Tu fais le test en fonction de ACTION, tu lance un:
su ${toi} /usr/bin/pmount $DEVNAME
puis tu cree une variable PETITDEVNAME=`echo $DEVNAME | cut -c6-`
et tu invoques ton filemanager pour qu'il s'ouvre dans /media/$PETITDEVNAME. (faut que tu exportes le bon display)
Comme cela quand tu plug ton device, tu devrais avoir une fenetre de ton filemanager qui souvre sur ton device.
Tu peux meme prevoir un truc en gerant l'action REMOVE pour pas te taper un umount. Le pmount se lance avec nocache je crois, si c'est le cas tu repere tout les process qui utilises ton point de montage (avec lsof | grep /media/PETITDEVNAME ) et tu les tue violement (un kill -9 carrement). puis tu lance un pumount.
Cela te fait l'economie de gnome-vfs.
[^] # Re: Xfce et Gnome, quels liens ?
Posté par Couderc Romain . Évalué à 1.
:)
# Logo
Posté par samds . Évalué à 6.
Mais ce qui me tracasse un peu, c'est le logo (et donc la section) qui a été choisi par l'auteur ou par le(s) modérateur(s) : Gnome.
Même si Gnome est basé sur Gtk+, à l'origine Gtk+ signifie The GIMP Toolkit. J'ai remarqué qu'il en était de même pour les news sur Qt, qui se retrouvent dans la section Kde.
Ne serait-il pas préférable de séparer ces news de celles sur Gnome/Kde ? Soit en les mettant ensemble dans une section 'Bibliothèques graphiques' par exemple, ou alors en créant une section Gtk+ (http://gtk.org/images/gtk-logo-rgb.gif(...)) et une section Qt (http://www.trolltech.com/images/logos/qt.png(...)) (attention le logo Qt est la propriété exclusive de Trolltech, cf http://www.trolltech.com/company/copyright.html(...)).
Voilà, c'était l'idée du matin.
Bonne journée,
- Sam
[^] # Re: Logo
Posté par samds . Évalué à 2.
s/affecion ados/aficionados/
[-] Ca m'apprendra à pas me relire.
[^] # Re: Logo
Posté par crevette . Évalué à 3.
[^] # Re: Logo
Posté par Patrix (site web personnel) . Évalué à -2.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Logo
Posté par Yusei (Mastodon) . Évalué à 4.
D'ailleurs, chose amusante, Gimp 2.2 vient de sortir avec une fonctionnalité amusante: on peut le compiler en mode texte, pour ne plus avoir de dépendance sur GTK. Bon, je ne sais pas à quoi ça peut servir, c'est destiné aux développeurs plus qu'aux utilisateurs, mais j'ai trouvé ça rigolo et un peu paradoxal.
(Une première étape pour avoir un gimp permettant de faire des manipulations uniquement en ligne de commande ?)
[^] # Re: Logo
Posté par david odin . Évalué à 9.
Ben non, justement, c'est la dernière étape. Le Gimp est utilisable depuis un bon moment en ligne de commande, ce qui permet par exemple de faire un site web qui crée automatiquement des Logos, en utilisant des scripts du Gimp.
Mais jusqu'à maintenant, même pour cela, il fallait compiler un Gimp complet, avec toutes les libs graphiques (d'où un temps de lancement trop important). Avec un Gimp sans support graphique, le chargement est quasi instantanné.
[^] # Re: Logo
Posté par - - . Évalué à 6.
GTK intègre de plus en plus des widgets de "gnome" et gnome planifie de plus en plus ses progrès en fonction du développement de GTK
fondamentalement, gnome va finir par être GTK + Gnome-vfs et les services gnome.
libgnome et libgnomeui allant peut être disparaitre pour se fondre dans un futur GTK (mais y à le temps, ça cassera la compatibilité binaire, donc ce n'est pas avant un gnome 3.0)
enfin bref : quand même Gimp 2.2 utilise les recommandations d'interface graphiques de Gnome, quand gaim est amélioré pour être intégré naturellement à gnome etc, on sent bien que GTK c'est en réalité la fondation de GNOME
et que XFCE est un sous-ensemble de gnome/freedesktop
alors après je veux bien que les puristes disent que GTK c pas Gnome, etc etc, que gnome c'est la grossse soupe et que gtk c la toolkit, que XFCE ce n'est pas gnome, etc etc etc , et parlons de rox et autres blablabla. mais bon hein, dans le concret, dés qu'on parle à autre chose qu'un geek puriste, vla ce qu'il en est :
GTK, pour la personne qui s'y connait juste un peu mais qui n'est pas Historien, c'est "ho ben c'est la fondation de Gnome".
ces développements et communautés s'interpénètrent, ce n'est PAS grave si on les mélange. au contraire, cela SIMPLIFIE la communication auprès des non experts ! boudié.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Logo
Posté par itstimetogo . Évalué à -2.
Non.
> gnome planifie de plus en plus ses progrès en fonction du développement de GTK
Oui.
> libgnome et libgnomeui allant peut être disparaitre pour se fondre dans un futur GTK
Non.
Gtk+ a une fonction. Être un toolkit graphique. libgnome et libgnomeui ne font pas que du graphique et utilisent bonobo, gnome-vfs, etc.
> mais y à le temps, ça cassera la compatibilité binaire
Non. C'est un ajout d'API donc ça ne casse pas la compatibilité. Mais ce n'est pas intelligent à faire.
[^] # Re: Logo
Posté par Vivi (site web personnel) . Évalué à 8.
Non.
Ben si. La plupart des nouveaux widgets dans 2.4 et 2.6 viennent en remplacement de widgets de libgnomeui.
> libgnome et libgnomeui allant peut être disparaitre pour se fondre dans un futur GTK
Non.
Ben si, cf:
http://people.imendio.com/andersca/archives/2004/11/handling_deskto(...)
http://people.imendio.com/andersca/archives/2004/11/answers_to_some(...)
[^] # Re: Logo
Posté par itstimetogo . Évalué à 1.
Tu parlais de libgnome et libgnomeui. libgnome ne va pas disparaitre et je doute que libgnomeui disparaisse aussi. Ou alors libgnomeui a atteint un haut niveau de consensus.
Par contre que des widget de libgnomeui passent dans gtk+ est normal. Pourquoi gtk+ referait ce que Gnome a déjà fait ? Mais libgnomeui ne sera pas intégré à gtk+. Sinon ça veut dire qu'il y aura des fonctions gnome_.... dans gtk+. Donc gtk+ va récupérer des widget gnome qui sont utiles à toutes applis (et pas seulement à Gnome) et les mettres à sa sauce. Si ces widgets sont supprimés de libgnomeui alors il y a incompatibilité.
Examples : Gnome peut avoir un sélecteur de fichier qui passe par gnome-vfs et gtk+ n'aura pas ce widget. libgnomeui fournira des menus avec des petit icone qui font bien pour Gnome mais que Xfce ne veut peut-être pas. Donc il faut toujours libgnomeui pour ce qui est spécifique à Gnome et ne conserne pas les autres.
[^] # Re: Logo
Posté par Vivi (site web personnel) . Évalué à 4.
libgnome ne va pas disparaitre et je doute que libgnomeui disparaisse aussi.
Une chose est claire : la compatibilité binaire sera maintenue dans tout le branche 2.x. C'est-à-dire que libgnome et libgnomeui resteront au moins jusqu'à l'arrivée de GNOME 3 (qui n'est pas sur le radar). Maintenant pleins de morceaux de libgnome et libgnomeui sont indiqués comme deprecated, c-à-d à ne pas utiliser pour du nouveau code car qqche de mieux le remplace.
Dans libgnome, il ne reste d'utile quasiment plus que GnomeProgram qui a tout un tas de problèmes comme l'explique andersca. Dans libgnomeui, il y a GnomeClient et divers widgets qui vont petit à petit dans GTK+.
Par contre que des widget de libgnomeui passent dans gtk+ est normal. Pourquoi gtk+ referait ce que Gnome a déjà fait ? Mais libgnomeui ne sera pas intégré à gtk+.
effectivement, il ne s'agit pas de déplacer les fichiers. Les widgets sont ré-écrits pour GTK+.
Gnome peut avoir un sélecteur de fichier qui passe par gnome-vfs et gtk+ n'aura pas ce widget.
Ouais enfin c'est plus compliqué que ça parce que la fonctionnalité gnome-vfs est implémentée dans un module chargé dynamiquement. L'appli ne fait que des appels à gtk_file_chooser_* mais si gnome-vfs est installé sur le système, il est utilisé pour les petites icones.
[^] # Re: Logo
Posté par itstimetogo . Évalué à 2.
Effectivement, c'est possible. Je n'avais pas envisagé un file_chooser dynamique.
C'est intéressant et ça change beaucoup la façon de voir les choses. gtk+ n'est plus seulement un toolkit graphique mais aussi "noyau" extensible dynamiquement.
Tu sais depuis quand c'est fait comme ça ?
C'est spécifique au file_chooser ou ça va être fait à d'autres domaines de gtk+ ?
Mais il y aura toujours ce type de "problème" spécificité Gnome ( http://people.imendio.com/andersca/archives/2004/11/handling_deskto(...) ) :
Also, in GTK+ 2.6 there are more hooks that need to be filled by someone, for example
gtk_about_dialog_set_url_hook
which lets you set a callback function that will be called when an URL is clicked in the new GTK+ about dialog. In GNOME, this would open your default web browser with that link. Remember that GTK+ shouldn't enforce policy about what desktop the user is running. Since we're getting more high-level widgets in GTK+, expect more hooks of this type.
Il faut bien que Gnome renseigne gtk_about_dialog_set_url_book par une valeur par défaut. Ça ne peut être fait que par libgnome ou libgnomeui et ce n'est pas à gtk+ de le faire. Sinon il doit avoir du code pour savoir s'il tourne sous Gnome ou KDE ou Xfce et fixer la valeurs par défaut. Dans le cas de Gnome il doit aussi utiliser gconf.
Certe on peut trouver une solution avec les modules. Gtk charge les modules "desktop" qu'il trouve (KDE, Gnome, ...) et demande à chacun dans quel environnement il tourne et s'il tourne sous Gnome par exemple il demande au même module la valeur de gtk_about_dialog_set_url_hook.
Tout est possible mais ça fait presque peur :-)
[^] # Re: Logo
Posté par Vivi (site web personnel) . Évalué à 2.
Sinon à propos des hooks pour gérer les URL et tout ça, effectivement c'est du domaine de GNOME (il faut consulter GConf pour récupérer les préférences globales de l'utilisateur). C'est en gros ce que GnomeProgram est censé faire : un appel à gnome_program_init() charge des modules, consulte GConf et règle des trucs GTK+.
# sélecteur de fichier
Posté par mickabouille . Évalué à 2.
* The new GtkFileChooser widget emphasizes simplicity unusability and thus does not provide a navigation entry by default when opening files.
Experienced command line users will likely want to make heavy use of
the location dialog brought up by the Control-L key shortcut.
Alors que dans "Annonce GTK 2.6", je vois :
Changes in the file chooser widget
The new GtkFileChooser widget which was introduced in 2.4 has
been improved in many ways. It is possible to enter paths in
the location dialog now, the file list has typeahead search
and loading large directories has been made faster.
Est-ce que cela veut dire que l'affreux bug introduit dans GTK 2.4 et qui rendait le sélecteur de fichier d'un nombre incroyable d'applications inutilisables serait corrigé? Je vois pourtant toujours le bug dans le bugzilla de gnome.
Alors?
[^] # Re: sélecteur de fichier
Posté par Christophe Fergeau . Évalué à 6.
Je vois pas vraiment de quoi tu parles... Sauf si tu parles par là du fait que la boîte d'ouverture de fichier ne comporte pas de zone de texte où tu peux taper un chemin à la main. Mais j'appelle pas ça un bug affreux qui rend des applis inutilisables, mais un changement de comportement/d'interface du sélecteur de fichier discutable et qui ne te convient peut être pas.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.