les applications graphiques (tcl/tk, qt, motifi, gtk ... ) pourraient etre dans /usr/X11R6/bin/misc/ par exemple ) ou /usr/bin/X/
----------------------------------------
vient alors un autre principe, et si chaque "application" avait SON repertoire a elle
et dedans son manuel, aide, icone et ressources
on nommerait ce repertoire "trucmuche.app" et ca serait un "bundle" que le gestionnaire de fichier montrerait comme etant une "application" (on clique sur lme trucmuche.app et en fait ca execute trucmuche.app/binaries/x86/trucmuche )
on aurait le modele de Apple dans macosX
l'idée est bonne car l utilisateur peut bouger le "bundle" ou il veut et ca marche toujours
(les libraires sont standards et mises dans un repertoire dédié a ca que l utilisateur n'a pas a trifouiller)
PAR CONTRE :
comme on peut le voir dans macosX ,les 2 systemes existent , la maniere unix (un /usr/bin ) et la maniere macintosh/nextstep (les bundle .app )
parce qu on ne peut decemment pas faire un vi.app ou un httpd.app , ca serait ridicule
probleme donc, 2 logiques existent au sein de macosX . vous me direz l utilisateur lambda n a pas a fouiner le /usr/bin/httpd... et alors ? le jour il veut le faire, bang il doit reapprendre une autre logique de rangement)
sous linux, la meme logique est utilisé que ca soit au niveau de votre super konqueror zoli zoli et sympathique jusqu a l abominable mais fonctionnel vi
neanmoins plus de coherence serait bien
j ai pris l habitude de creer un repertoire /Applications sur mon linux et d y mettre des liens symboliques des binaires de mes applications favorites
quand je dis "applications" je pense programmes avec une interface graphique, genre gnumeric, gqview, scribus etc...
l'idée etant d'avoir un lieu facile a parcourir avec nautilus où je doubleclique, en sachant trés bien que tout ce qui est la a un zoli icone et affiche une fenetre, pas des utilitaires shell
pour rendre linux plus agreable et plus "fluide" a parcourir pour un debutant, il faudrait prendre l habitude de separer les binaires qui sont des applications graphiques des commandes shells.
ne serait ce que pour simplifier le parcours du repertoire des logiciels avec konqueror ou nautilus.
# un premier pas
Posté par - - . En réponse à la dépêche Mosfet : Rage against the File System Standard. Évalué à 3.
(a voir ce qui serait le plus juste)
les libs devraient aller dans /usr/lib/ et separé si ca forme un trop gros ensemble de lib
les includes doivent etre separé
/usr/include/gnome-1.0/.....
par projets
en fait
les binaires (choses les plus utilisé par les utilisateurs) devraient pas etre melangé n importecomment
/usr/bin devrait contenir _que_ des commandes consoles ou systemes
et /usr/bin/gnome devraient avoir tout les applications de gnome
/usr/bin/kde de meme
/usr/bin/gnustep...
cependant
X a son propre sous rep dans /usr/X11R6
les gens de gnustep ont pris la meme habitude /usr/GNUstep
finalement et si on faisait :
/usr/gnome/...
/usr/kde/....
(cela dit , ou met on une application QT ou GTK ne faisant pas partie en tant que tel de kde ou gnome ? hmm ? )
on aurait donc au final :
/usr/X11R6/... (include, lib etc...)
/usr/gnome/.... (include, lib etc... )
/usr/kde/... (include lib etc...)
/usr/bin (binaires console et systeme)
les applications graphiques (tcl/tk, qt, motifi, gtk ... ) pourraient etre dans /usr/X11R6/bin/misc/ par exemple ) ou /usr/bin/X/
----------------------------------------
vient alors un autre principe, et si chaque "application" avait SON repertoire a elle
et dedans son manuel, aide, icone et ressources
on nommerait ce repertoire "trucmuche.app" et ca serait un "bundle" que le gestionnaire de fichier montrerait comme etant une "application" (on clique sur lme trucmuche.app et en fait ca execute trucmuche.app/binaries/x86/trucmuche )
on aurait le modele de Apple dans macosX
l'idée est bonne car l utilisateur peut bouger le "bundle" ou il veut et ca marche toujours
(les libraires sont standards et mises dans un repertoire dédié a ca que l utilisateur n'a pas a trifouiller)
PAR CONTRE :
comme on peut le voir dans macosX ,les 2 systemes existent , la maniere unix (un /usr/bin ) et la maniere macintosh/nextstep (les bundle .app )
parce qu on ne peut decemment pas faire un vi.app ou un httpd.app , ca serait ridicule
probleme donc, 2 logiques existent au sein de macosX . vous me direz l utilisateur lambda n a pas a fouiner le /usr/bin/httpd... et alors ? le jour il veut le faire, bang il doit reapprendre une autre logique de rangement)
sous linux, la meme logique est utilisé que ca soit au niveau de votre super konqueror zoli zoli et sympathique jusqu a l abominable mais fonctionnel vi
neanmoins plus de coherence serait bien
j ai pris l habitude de creer un repertoire /Applications sur mon linux et d y mettre des liens symboliques des binaires de mes applications favorites
quand je dis "applications" je pense programmes avec une interface graphique, genre gnumeric, gqview, scribus etc...
l'idée etant d'avoir un lieu facile a parcourir avec nautilus où je doubleclique, en sachant trés bien que tout ce qui est la a un zoli icone et affiche une fenetre, pas des utilitaires shell
pour rendre linux plus agreable et plus "fluide" a parcourir pour un debutant, il faudrait prendre l habitude de separer les binaires qui sont des applications graphiques des commandes shells.
ne serait ce que pour simplifier le parcours du repertoire des logiciels avec konqueror ou nautilus.