dimanche 04 janvier

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Développeur

Liens connexes

La proposition (1877 hits)
Vu dans les Gnome Weekly news (566 hits)
GV (611 hits)
Open File dans GV (image) (1145 hits)

Dépêche modérée par

Amaury

Développeur : Crise dans la gestion de fichier

Posté par zero heure (Jabber id, page perso, ). Modéré le 06 octobre 2002.

Menheere, un développeur Gnome, est en train de mettre fin à ce qui faisait la joie de tous : les (très) austères boites de dialogues Ouvrir fichier et Enregistrer de Gnome.

Bon c'est pas qu'une news pour délirer.

L'auteur a fait pas mal d'essais (cf le site), réfléchi aux problèmes... Allez jeter un oeil, le résultat est assez joli.
Mais le résultat est-il plus utilisable ?

C'est confus: il y a beaucoup d'options; c'est beau mais sans doute plus lourd qu'avant; je sens que ça va prendre du temps d'ouvrir ou sauver un fichier...

Bref, c'est un sujet qui me tarabuste depuis un moment: avons-nous des bonnes boites de dialogue de gestion de fichiers sous Linux ? Celui qui m'a toujours impressionné (combinaison de facilité / efficacité / élégance / "power", etc.) c'est celui de GV (GhostView revu par Johannes Plass).

La proposition (1877 hits)
Vu dans les Gnome Weekly news (566 hits)
GV (611 hits)
Open File dans GV (image) (1145 hits)

> Lire les commentaires (22 commentaires, moyenne: 5,2).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

gv ?

Posté par Infernal Quack (Jabber id, page perso, ) le 07/10/2002 à 00:14. (lien). Évalué à 23.

Je la trouve horrible la boite de dialogue de GV

- il y a aucune complétion,
- c'est laid (AMA),
- ça reste basique dnas les fonctionnalités,
- ...

Je préfère encore mille fois une fenêtre de dialogue de gtk1 :(

mouches

Posté par Moby-Dik () le 07/10/2002 à 00:18. (lien). Évalué à 13.

Celui qui m'a toujours impressionné (combinaison de facilité / efficacité / élégance / "power", etc.) c'est celui de GV (GhostView revu par Johannes Plass).

Heu... je pense que si tu montres ça à un utilisateur moyen il va se sentir complètement perdu. Il n'y a même pas de label sur les différents widget pour indiquer de quoi il s'agit. D'autre part le placement relatif des widgets n'est pas logique (la liste de sélection en bas, la boîte contenant le nom de fichier en haut, le filtre entre les deux... ??). C'est une GUI unixienne typique, qui demande un temps d'adaptation assez long pour un résultat pas meilleur qu'avec des interfaces plus accessibles.
J'appellerais donc plutôt ça une grosse daube bien énervante ;)

Concernant la proposition Gnome, c'est vrai qu'elle est un peu chargée... L'emblème n'a rien à faire dans la boîte par défaut, et la navigation fait fouillis. Malheureusement KDE n'est pas mieux de ce point de vue (ces types-là réussissent à caser une myriade d'icones inutiles dans une fenêtre de sélection de fichier... n'importe quoi).

[^]Re: mouches

Posté par Kasp () le 07/10/2002 à 00:54. (lien). Évalué à 27.
Bah, moi celles de kde me vont bien, surtout la séparation dossiers/fichiers (sans l'arborescence lourde) et la possibilité de rajouter des icones dans la barre de racourcis de gauche pour l'application en cours uniquement ou pour toutes.
A ca, ajouté le support fish (ssh), webdav etc... intégré, c mortel, dans kvim, kate, quanta etc... un clic dans la boite de dialogue et hop je suis en ssh sur une box, en webdav sur une autre.

Pour ce qui est de la présentation, la version proposée pour gnome me parait sympa, mais il me manquerai le coup des raccourcis de ouf

--
asadmin-maven-plugin
jaroverlay-maven-plugin

[^]xaw3d

Posté par Emmanuel Blindauer (page perso, ) le 07/10/2002 à 06:25. (lien). Évalué à 2.
Je pense que:
* D'un coté, la boite de dialogue est comme écrit au dessus très non-intuitive pour les gens qui debutent.
* D'un autre coté le toolkit utilisé est très joli et intéréssant. Il fut une époque où un projet de desktop a été lancé avec xaw3d, mais il semblait être un peu trop buggé.

Lourd ?

Posté par LupusMic (page perso, ) le 07/10/2002 à 01:13. (lien). Évalué à 4.

Peut-être que les quelques icônes prendront un peu de place mémoire, mais en tout cas, cela ne semble pas lourd.

En plus, c'est simple, précis et concis. C'est étonnant venant du projet GNOME ! Quand aux autres boites de dialogues, celle de l'API native de BeOS était un modèle de simplicité, et d'ergonomie !

[+] [^]rions un peu avec trollorak

Posté par Le_Maudit Aime () le 07/10/2002 à 05:58. (lien). Évalué à -2.
c'est pas parce qu'on y connait rien qu'il faut fermer sa gueule.
<troll>
comme tout est corba dans gnome, il n'y a qu'à demander à ORbit d'appeler nautilus et puis c'est tout.
Ce sera simple, léger et très bien pour ceux qui ont de la mémoire et des cycles en trop.
</troll>
et puis -1 aussi
- [^]Re: rions un peu avec trollorak
  
  Posté par LupusMic (page perso, ) le 07/10/2002 à 08:50. (lien). Évalué à 0.
  c'est pas parce qu'on y connait rien qu'il faut fermer sa gueule.
  Parles pour toi ! ;p
  
  Bien sûr que l'architecture de GNOME est lourde et souvent inutile, mais ce n'est pas une raison pour systématiquement dénigrer tout le travail accompli !

Navigateur Rapide du menu KDE

Posté par Nÿco (Jabber id, page perso, ) le 07/10/2002 à 10:20. (lien). Évalué à 8.

Putain, j'ai jamais compris q'un truc aussi génial n'aie pas été intégré partout ! C'est un peu comme les "pie-menus" de Mozilla, ainsi que les "mouse gestures" que j'ai rencontré la première fois sur les outils Mentor Graphics en 1995 (CAO électronique).

Dans les boites de dialogues "ouvrir...", "Sauver..." et "Sauver sous..." il nous faut impérativement un navigateur rapide à la KDE !

Ce sera alors une "killer feature" !

--
Jabber ID : xmpp:Nyco@jabber.fr

le dessus de l'iceberg !

Posté par bobert () le 07/10/2002 à 12:18. (lien). Évalué à 15.

Je ne vois rien d'original dans la proposition de Menheere: la boite de dialogue nous montre toujours la hierarchie du systeme de fichiers et le contenu d'un endroit de la hierarchie...

Mais je comprends tres bien qu'on puisse se sentir frustre par ces boites de dialogue d'ouverture et d'enregistrement... et comment !!

En fait, il ne s'agit que du dessus de l'iceberg... je vais vous aider a mettre le doigt sur ce qui nous gene tous reellement:

On a tous (disons les linuxfr-iens) a gerer des tartinees d'informations:

par mail

sous forme d'URL

sous forme de fichiers

sous forme de notes

etc.

Alors, comme on est patient et bien organise (hein ? vous faites ca une fois tous les 10 ans ?), on se cree:

des sous-repertoires ou des fichiers mbox supplementaires via son client mail favori pour trier les infos qui nous arrivent sous forme de mails

un fichier de bookmarks aux p'tits oignons, avec des categories juste comme on les aime, pour classer les infos sous forme d'URL, en essayant d'oublier que galeon/moz/konqueror/lynx sont incappables de se mettre tous d'accord pour lire ce p'tit fichier (aaaargh !!!)

une belle hierarchie de repertoires et sous-repertoires pour classer ses fichiers

un truc que chacun fait a sa sauce mais qui sert a la meme chose, trier ses notes

Bon, cool. Maintenant, vous avez besoin d'une info...
Euh, c'etait pas untel qui m'avait envoye ca par mail, des fois ?
Non, je dois avoir garde le fichier chez moi, ou au boulot...
ah merde, non, je l'ai pas, mais j'ai surement ca dans mes bookmarks de moz ??
rhaa, #$@# !!!!! je vais lancer konqueror, j'ai peut-etre colle un lien en vitesse la-dessus...

Vous avez surement compris ce qui nous fait tous ch... au quotidien (desole mais c'est un cri du coeur):

l'information, ou les donnees, appelez ca comme vous voulez, a la meme gueule, qu'elle se presente par mail ou sous forme de document pdf. un mail ou un fichier renferment des informations de meme nature.

Stocker des informations dans des hierarchies differentes suivant la facon dont elle nous est parvenue ou le type de fichier, ca n'a aucun sens !! Le mode actuel de stockage des informations est un lourd heritage du passe.

Vous vous imaginez garder une hierarchie de repertoires differente pour stocker des documents pdf et des documents postscript ? Notre facon actuelle de stocker nos informations est aussi insensee, ni plus, ni moins. Et les applications qu'on utilise ne font rien pour nous aider a changer ca.

Alors, vieux, tu l'as, la solution miracle ?
Faut voir... j'ait les idees, mais pas le temps de les implementer (je suis sense faire de pa physique, pas de l'informatique). Encore que, si je trouvais des gens aussi motives que moi...

En tout cas, j'ai les convictions suivantes:

il faut absolument dissocier les informations des meta-informations (les informations sur les informations). En gros, mettre a la queue-leu-leu tout ce qu'on veut stocker comme des patates dans un sac a patates. Mais attacher a chaque patate des informations sur elles (type de document, qui c'est qui l'a ecrit, etc.). Ces meta-informations incluent des infos sur la nature des informations contenues dans la patate (en gros, l'endroit ou on stockerait notre patate dans notre hierarchie-d'a-nous-perso qu'on connait bien: langages, langages/java, langages/perl, etc)

On n'en est encore qu'a la prehistoire de l'informatique. L'age moderne, ca sera quand on pourra stocker nos informations dans une seule hierarchie. Mais vu que les applications actuelles continuent joyeusement de s'ignorer mutuellement (allez, chipotez pas, c'est quasiment vrai), ca pourrait prendre du temps d'en arriver la. Alors en attendant, disons un moyen-age possible, ce serait de laisser les clients mails gerer leurs mails, les systemes de fichiers gerer leurs fichiers, etc, mais de centraliser les meta-informations au sein d'un "truc" qui proposerait d'acceder aux informations en parcourant une hierarchie unique.

Ouala mes 2 centimes. J'aimerais bien que d'autres continuent le debat. Et peut-etre, si des volontaires sont partants pour cracher du code, ben en reunissant nos 2 centimes on pourrait arriver a quelque chose ?
Contactez-moi si vous etes partants !

eul'Bob

References utiles:

Il y a eu un debat la-dessus sur freshmeat, beaucoup d'idees etaient deja la: http://freshmeat.net/articles/view/286/(...)

Un outil qui pourrait aider a sortir de la prehistoire, libferris: http://witme.sourceforge.net/libferris.web/(...)

Le systeme de fichiers de BeOS etait tres novateur puisqu'il permettait de dissocier fichiers et meta-informations sur ces fichiers. Je crois que ce concept est a la mode du cote des systemes de fichiers journalises, mais je ne suis pas au gout du jour a ce niveau-la. En tout cas, cette differenciation peut tres bien se faire a un niveau plus eleve que celui du systeme de fichiers

[^]Re: le dessus de l'iceberg !

Posté par Infernal Quack (Jabber id, page perso, ) le 07/10/2002 à 15:16. (lien). Évalué à 3.
1) il faut absolument dissocier les informations des meta-informations

Cf KDE3.1 et l'arrivée des metas-informations dans les previews avec à termes une possibilité de recherche sur celle-ci.
Pour Gnome je sais pas mais ça doit arriver.

2) Mais vu que les applications actuelles continuent joyeusement de s'ignorer mutuellement

C'est pour ça qu'il y a des standards : mbox pour les mails, xbel pour les bookmarks,... (Ce ne sont que des exemples)
Le tout est que le meilleur reste et qu'il soit utilisé parce que l'import/export de bookmarks entre galeon et konqui c'est chiant. Il faudrait presque qu'ils puissent gérer un format quelconque de base (export/import à la volée) de façon à pouvoir utiliser le même fichier pour tous les navigateurs
- [^]Re: le dessus de l'iceberg !
  
  Posté par Olivier Jeannet () le 07/10/2002 à 15:59. (lien). Évalué à 1.
  l'import/export de bookmarks entre galeon et konqui c'est chiant. Il faudrait presque qu'ils puissent gérer un format quelconque de base (export/import à la volée) de façon à pouvoir utiliser le même fichier pour tous les navigateurs
  
  En principe pour les carnets d'adresses (address book) il existe un format standard, le LDIF (Lightweight Directory Interchange File je crois, rapport au LDAP), que Netscape 4 gérait déjà. Je sauve mes adresses comme ça depuis Netscape.
  
  KMail est censé importer du LDIF mais j'ai été très déçu par le KMail qui est dans KDE 3, il n'importe presque rien. En plus, l'application dédiée (KAddressBook, séparée de KMail) est plutôt bugguée ne serait-ce que graphiquement (largeur des colonnes qui change n'importe comment par ex). Du coup je suis resté à Mozilla (1.1) pour mon courriel.
  
  Pour les signets (bookmarks), Netscape les sauve au format HTML; je n'ai pas regardé ce que faisait Konqueror, mais c'est plutôt simple et facile à implémenter comme format il me semble.
  - [^]Re: le dessus de l'iceberg !
    
    Posté par Infernal Quack (Jabber id, page perso, ) le 07/10/2002 à 16:15. (lien). Évalué à 2.
    le KMail qui est dans KDE 3, il n'importe presque rien
    
    Il faut passer par une application d'import qui est à part je crois. Pour les colonnes bugguées je confirme :(
    
    ), Netscape les sauve au format HTML; je n'ai pas regardé ce que faisait Konqueror, mais c'est plutôt simple et facile à implémenter comme format il me semble.
    
    HTML n'est pas fait pour. C'est un langage qui sert à faire de la présentation pas du stockage. Xbel est BEAUCOUP mieux et est utilisé par konqueror et tous les trucs de signets de KDE. Galeon les importent aussi. C'est du XML qui a l'avantage de pouvoir être parsé en Sax ou Dom et c'est ce que j'utilise pour mon site (Mais il reste à commenter les liens ;)
- [^]Re: le dessus de l'iceberg !
  
  Posté par imr () le 07/10/2002 à 16:02. (lien). Évalué à 0.
  KDE3.1 et l'arrivée des metas-informations
  Il y a eu beaucoup de discussions à ce sujet entre Havoc Pennington et les développeurs kde sur les mailling lists à ce sujet, je crois.
  Quelqu'un peut confirmer? et dire si quelque chose de concrét en ait sorti ?
  On peut réver de plus d'interropérabilité?

[^]Re: le dessus de l'iceberg !

Posté par Gaël Le Mignot (page perso, ) le 08/10/2002 à 10:08. (lien). Évalué à 1.
un mail ou un fichier renferment des informations de meme nature.

C'est ce que j'ai toujours dit: vive mboxfs ( http://people.type-z.org/ludo/hurd/README-mboxfs(...) , http://people.type-z.org/ludo/hurd/(...) ) ! :)

File dialogs : 3 "volets"

Posté par Nÿco (Jabber id, page perso, ) le 07/10/2002 à 13:39. (lien). Évalué à 2.

Je pense en fait qu'il devrait y avoir trois "parties" dans les "file dialogs" (ou "boites de dialogues de fichiers") :

- navigation répertoires/dossiers (dont navigateur rapide et signets locaux paramétrables par l'utilisateur)
- fichiers (la liste des fichiers présents dans le rep sélectionné)
- types de fichiers (filtre pour lecture, export pour sauvegarde)

Ces trois "éléments" de base doivent à mon sens clairement être affichées, donc trois parties à peu près égales visuellement.

1 )
Une liste déroulante pour la navigation ce n'est clairement pas suffisant, et très handicapant pour la rapidité d'exécution. Une liste d'emplacements remarquables (root, cdrom, floppy, etc) n'est que partiellement éccelérateur du processus de sélection de l'emplacement des fichiers. La solution MS recopiée par KDE est une horreur digne de l'interface hall of shame : pourquoi des boutons aussi gros et aussi colorés prennent-ils autant de place pour si peu ?

2 )
La partie fichier (liste et nommage) est celle qui est le plus naturellement "développée", car toute l'attention est portée sur celle-ci.

3 )
Un simple menu déroulant pour la sélection du type est encore une fois insuffisant à mourir ! Une succession de boites pour paramétrer le type de ficher est trop lourde. Tout cet enchainement doit figurer dans la boite de dialogue fichiers.

Avec ces trois volets, on s'approche d'une manière chronologique de pensée : où, puis quoi, et enfin comment. (on peut aussi éventuellement faire différent : "comment"-type puis "où"-emplacement puis "quoi"-nom du fichier)

Nÿco

--
Jabber ID : xmpp:Nyco@jabber.fr

[^]Re: File dialogs : 3 "volets"

Posté par Mickaël L () le 07/10/2002 à 14:48. (lien). Évalué à 2.
J'ai un doute concernant le type de fichier. Ca sert à quoi au juste? A ajouter une "extension" au nom du fichier? Le genre de chose qui fait que j'ai des noms de fichier du genre DSno4.lyx.lyx ?
1. Si j'ai besoin d'un extension de fichier, je ne peux pas la mettre?
2. Pourquoi un fichier aurait-il un type? Les types mime c'est bien, mais ça peut être génant parfois.
3. Est-ce qu'il existe un moyen de stocker un type dans le FS?
- [^]Re: File dialogs : 3 "volets"
  
  Posté par Infernal Quack (Jabber id, page perso, ) le 07/10/2002 à 15:30. (lien). Évalué à 6.
  Ca sert que quand tu veux ouvrir un document Word avec OpenOffice tu as pas besoin d'avoir tous les types supportés dans ta partie "fichiers"
  
  1. Si mais si tu utilises un programme pour la première fois tu la connais l'extension ? Quiz : Types de bases de sketch, blender, kword ?
  
  2. Pour pouvoir l'associer à l'ouverture automatique par un programme/une librairie. Imagine dès que tu arrives sur http://linuxfr.org(...) qu'on te demandes avec quoi on ouvre "logo.png" ? "libgif, libpng, libflash, libhtml,..." ? T'aurais l'air fin :)
  
  3. A quoi ça sert ? C'est immonde. Externaliser du fichier une de ses propriétés intinsèque :(
  Ce qu'il faudrait surtout c'est une normalisation des fichiers pour que le type apparaisse dans le fichier (En première ligne ?) pour éviter de se fier aux extensions trompeuses et limitantes. Mais bon ça c'est mal barré. Le fichier "magic" a encore du chemin à faire.
  
  My 2 euros
  - [^]Re: File dialogs : 3 "volets"
    
    Posté par yugz () le 07/10/2002 à 16:13. (lien). Évalué à 1.
    A quoi ça sert ? C'est immonde. Externaliser du fichier une de ses propriétés intinsèque :(
    
    un fichier en tant que tel n'est qu'un récipient de données, il n'est rien sans quelques informations que le FS conserve : nom, taille, etc. Que l'info identifiant le type du contenu soit également dans le FS me semble être ce qu'il faut pour pouvoir gérer efficacement les données.
    - [^]Re: File dialogs : 3 "volets"
      
      Posté par Infernal Quack (Jabber id, page perso, ) le 07/10/2002 à 16:32. (lien). Évalué à 3.
      Et dès que tu déplaces un fichier sur un FS qui le gère pas tu perds cette info ? :(
      
      En réfléchissant c'est pas con mais ça demande une cohabitation avec l'existant.
      - [^]Re: File dialogs : 3 "volets"
        
        Posté par yugz () le 07/10/2002 à 16:49. (lien). Évalué à 2.
        Je n'aimerais pas voir dans un fichier trop d'informations le concernant, d'autant plus qu'on en fait ce qu'on veut : un fichier est ce que tu en fais, pas ce qu'il décide d'être. Sinon, tu peux mettre l'info dans le nom du fichier, généralement sous forme de suffixe séparé du nom par un '.'. Ca revient au même que de mettre l'info du type dans le FS, mais ça s'écarte de l'esprit UNIX et c'est pas super pratique si tu changes le type du fichier car ça t'oblige à faire un changement de nom (ce qu'on ne devrait jamais avoir à faire).
        
        Quand on déplace un fichier sur un FS qui ne gère pas ça, on perd l'info, comme beaucoup d'autres. Quid des permissions sur un FS ne les gérant pas ? Quid de la casse du nom sur un FS ne différençiant pas les majuscules des minuscules ?
        
        Ce problème a toujours existé.
        
        [^]Re: File dialogs : 3 "volets"
        
        Posté par Infernal Quack (Jabber id, page perso, ) le 07/10/2002 à 20:30. (lien). Évalué à 1.
        Euh oui mais là c'est très grave si on perds le type de fichier :)
        
        Perso moi je préfèrerais que le fichier stocke ce qu'il est en interne. Comme-ça on peut le renommer, le déplacer,.. sans perdre l'info. Bref que le fichier saches ce qu'il est. C'est pas pour rien que j'aime la programmation objet :))
        Et puis ajouter une ligne avec le mime-type ("image/png", "audio/wav",...) ça coûte pas grand chose mais ça peut rapporter gros
        
        Mais bon vu que ce que je dis ne fera pas chager les choses j'arrêtes là ;)

Mocheté ????

Posté par Benjamin G. ( Prae ) (page perso, ) le 07/10/2002 à 23:31. (lien). Évalué à 1.

Certains dans le message disent que c'est moche...
On doit pas voir la même image alors...
C'est bien celle-là : http://home.wanadoo.nl/sbm/Pictures/result/gtk-savefile5b.gif(...) ?
et celle-là : http://home.wanadoo.nl/sbm/Pictures/result/gtk-openfile5.gif(...) ?
Je trouve les boites plutot jolie, c'est clair, ca va au plus simple et en plus ca prendra surement moins de mémoire si c'est écrit dans une function avec un paramètre entre le 'save' ou le 'open'.

Que demande le peuple ? :)

Revenir en haut de page

Articles précédents : Développeur

Liens connexes

Dépêche modérée par

Développeur : Crise dans la gestion de fichier

gv ?

mouches

[^]Re: mouches

[^]xaw3d

Lourd ?

[+] [^]rions un peu avec trollorak

[^]Re: rions un peu avec trollorak

Navigateur Rapide du menu KDE

le dessus de l'iceberg !

[^]Re: le dessus de l'iceberg !

[^]Re: le dessus de l'iceberg !

[^]Re: le dessus de l'iceberg !

[^]Re: le dessus de l'iceberg !

[^]Re: le dessus de l'iceberg !

File dialogs : 3 "volets"

[^]Re: File dialogs : 3 "volets"

[^]Re: File dialogs : 3 "volets"

[^]Re: File dialogs : 3 "volets"

[^]Re: File dialogs : 3 "volets"

[^]Re: File dialogs : 3 "volets"

[^]Re: File dialogs : 3 "volets"

Mocheté ????