L'article vaut ce qu'il vaut, le testeur est sous Suse, mais quelques arguments semblent faire pencher son choix pour Ximian...
Personnellement, des environnements comme Afterstep, GNUStep, Fluxbox, fvwm, larswm ;) me semblent encore plus légers... A vous de juger...
Aller plus loin
- Le "duel" Ximian/KDE (4 clics)
- Une liste de gestionnaires de fenêtres sur Freshmeat (4 clics)
# bingo
Posté par Anonyme . Évalué à 10.
On notera qu'il s'agit d'un parti pris de naxale, l'article original parlant de Ximian GNOME.
Mais au fait, cet article « Ximian GNOME on a low-resources machine », n'est-ce pas celui passé il y'a quelques jours sur linuxfr ?
[^] # bingo pouf !
Posté par TSelek . Évalué à -2.
Je ne trollai pas, merci.
[^] # Re: bingo pouf !
Posté par Philippe F (site web personnel) . Évalué à 10.
Certes, il y a beaucoup d'allemands dans KDE, mais il y a aussi des francais, des belges, des neerlandais (beaucoup), des anglais, des americains. L'expression "rigueur germanique" ne me plait pas. Rigueur tout court oui. Ou bien rigueur europeenne et marketing a l'americaine pour Gnome et Ximian Gnome, la ce me va tres bien :-))
pour info:
http://worldwide.kde.org/map/index.phtml?large=normal(...)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: bingo pouf !
Posté par TSelek . Évalué à -7.
Je comprends très bien, j'adore être bordélique mais c'est autre chose que de se le faire remarquer...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: bingo pouf ! de Schneider à LiNuCe
Posté par Schneider Dark . Évalué à -3.
Mais un troll que j'aimes ;P
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: bingo pouf !
Posté par kalahann . Évalué à 2.
c'est pas staroffice sur lequel tout le monde a gueulé une fois le code source rendu publique, parce que c'était devenu une usine à gaz non maintenable, commentée au hasard des fois en allemand des fois en anglais?
Je veux bien qu'on parle de rigueur allemande... mais pas pour staroffice.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # d'experience...
Posté par TSelek . Évalué à 10.
Aujourd'hui encore je peux comparer deux produits, un french, un allemand. le premier a une doc execrable, le second une doc nickel.
Ce n'est pas toujours vrai, c'est juste une tendance. Ce n'est pas majeur, mais inutile d'affirmer que nous tous européens nous sortons tous du même moule.
Mais quand on parle de "french touch" là y'a pas un français qui tique !
[^] # Re: d'experience...
Posté par Veggie . Évalué à -5.
Un jour, il sortait d'un repas avec les directeurs des centres de recherche de son entreprise. Il était le français, il y avait un Américain, un Allemand, et un gars d'une autre nationalité, je me rappelle plus. A là sortie du restaurant donc, l'américain et l'autre gars traversentle passage clouté alors que le feu était rouge. Mon père les suis, ils se retournent, et l'Allemand était resté sur le trottoir d'en face. Ils l'ont appellé mais il a attendu que le feu passe au vert pour traverser. Il a fallu que mon père explique aux autres cette fameuse rigueur allemande.
En ce qui me concerne, j'ai fait l'expérience de la nouvelle génération de mon âge (16-17 ans) qui est elle beaucoup plus laxiste. Mais on m'a dit aussi que le lycée ou j'étais tombé était légèrement baba-cool sur le retour donc je ne sais pas trop quoi penser. Faudra vérifier...
[^] # German gfx
Posté par Moby-Dik . Évalué à -5.
Perso l'expression "french touch" me fait autant chier que la "rigueur germanique", surtout que la dite touche est souvent invoquée comme alibi commercial à saveur folklo lorsqu'il s'agit d'exporter des daubes industrielles (type Amélie Boulet). Ce genre de raccourci foireux fait partie de l'arsenal marketing des multinationales, qui ont besoin de dessiner une catégorisation simplifiée à l'extrême afin de présenter un catalogue compréhensible par n'importe quel être humain sur Terre.
Ceci dit il y a des tendances qui statistiquement ne sont pas fausses. Par exemple, quand je codais sur un ordinateur 8 bits dont la marque commence par A, on parlait de "German graphix" pour désigner les graphiques les plus laids. C'étaient effectivement les Allemands qui systématiquement
utilisaient des palettes mélangeant allègrement le mauve, le vert et l'orange vif, le tout sans la moindre notion d'élégance du trait et de sobriété de la composition. Quand je vois KDE, je me dis que cette expression est toujours valable.
D'un autre côté, PHPNuke, qui est d'une inélégance achevée, est d'origine brésilienne....
# wm ultra leger
Posté par - neuro (site web personnel) . Évalué à 10.
Ion est un wm ultra light, ultra parametrable; il a une particularite qui le rends tres agreable a utiliser: aucune fenetre ne doit en chevaucher une autre. L'ecran est splitte en frames, et jusqu'a 10 espaces de travail sont acessibles. De plus, les frames sont superposables... enfin, c'est un vrai bonheur quoi.
Il est dispo sur http://projects.freshmeat.net/ion(...)
[^] # Re: wm ultra leger
Posté par Gentoo][Gravis . Évalué à 10.
[^] # Re: wm ultra leger
Posté par GCN (site web personnel) . Évalué à -5.
Sans commentaires ;) et [-1] bien entendu ;)
[^] # comparer ce qui est comparable !!!
Posté par Jean-Marc Chapuzot . Évalué à 10.
On peut cependant regretter l'abscence dans ce comparatifs de WindowMaker ou Icewm mais ion quoiqu'interessant n'offre de loin s'en faut les fonctionalites des deux gros.
D'autre part KDE et gnome sont les seuls environements qui offrent un login graphique complet permettant non seulement le login mais aussi d'arreter la machine sans passer par la console.
Wdm base sur les libs de windowsmaker n'est pas trop mal mais necessite le mot de passe de root pour arreter la machine ce qui le disqualifie quelque peu.
[^] # wdm...
Posté par vazco . Évalué à 5.
Simplement ce n'est pas la configuration par défaut.
$less /etc/X11/wdm/wdm-config
[...]
DisplayManager*wdmVerify: false
DisplayManager*wdmRoot: false
[...]
[-1 parce que c'est un tantinet hors-sujet]
[^] # Re: comparer ce qui est comparable !!!
Posté par Pierre Jarillon (site web personnel) . Évalué à 7.
XFCE http://www.xfce.org/(...) a été écrit par Olivier Fourdan.
Il a l'avantage d'être léger ainsi que de permettre aux Unixiens de passer à Linux sans même s'en apercevoir !
Il pèse à peu près le même poids que IceWM et Fvm2.
[^] # Re: wm ultra leger
Posté par kasi . Évalué à 4.
qui est peut connu mais vraiment sympa
http://rox.sourceforge.net/(...)
[^] # Re: wm ultra leger
Posté par jojolapin . Évalué à 1.
Quand on voit ça, on se demande encore plus comment konqueror/nautilus font pour être aussi lents.
Rox, ça roxor :-)
(pas pu m'empêcher)
[^] # Re: wm ultra leger
Posté par kalahann . Évalué à 1.
Par contre, pas réussi à faire du drag'n'drop avec wmaker, alors qu'ils sont tous les 2 censés utiliser le protocole XDND... bizarre.
[^] # Re: wm ultra leger
Posté par kasi . Évalué à -3.
ça marche pas mal pourtant .....
[^] # Re: wm ultra leger
Posté par kalahann . Évalué à -2.
Faudra que je fouille un peu... mais la flemme :)
# Et IceWM ?
Posté par domi . Évalué à 10.
Avec Dillo comme navigateur, je ne tape même pas de 100 Ko dans le swap !
Et je ne parle pas du temps de chargement : c'est nettement plus rapide que KDE2 sur mon XP1700+ :-)
# Confusion gestionaire de fenêtres - environements
Posté par Yann Hirou . Évalué à 10.
> Fluxbox, fvwm, larswm ;) me semblent encore plus légers...
> A vous de juger...
NON, ce ne sont pas des environements, mais simplement des gestionaires de fenêtres.
Ximian GNOME et KDE sont des environements, gérant la communication entre applications, alors que enlightenment, Afterstep, GNUStep, fvwm, etc... ne sont que des gestionaires de fenêtres.
Ce sont deux choses distinctes, et il est parfaitement possible d'utiliser KDE ou GNOME avec un autre gestionnaire de fenêtres que celui proposé par défaut !
Le test parle donc bien d'un environnement, que j'appelle un "bureau actif", et non du gestionnaire de fenêtres qui vient par dessus; les deux seuls bureaux actifs disponibles aujourd'hui étant GNOME et KDE, le test est complet... ensuite le test aurait pu envisager plusieurs gestionaires de fenêtre pour prendre le plus léger, mais c'est un autre point.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Anonyme . Évalué à 10.
Contrairement à ce que tu écris, fvwm, Afterstep et Gnustep sont des gestionnaires de fenêtre mais aussi des environnement.
En fait, le terme environnement peu être vu selon une perspective restreinte (là il ne s'agit que de GNOME, KDE et GNUSTEP qui apportent un tableau de bord mais aussi des lecteurs de courriel etc..) ou selon une perspective large (on peut considerer comme environnement le gestionnaire de fenêtre et le tableau de bord, comme fvwm2, icewm, blackbox, considérant le reste comme des applications et non des éléments de l'environnement - car ni GNOME ni KDE ne sont nécessaires).
J'avoue ne pas trop saisir ce que tu appelles « bureau actif » mais je n'utilise ni GNOME ni KDE et je n'ai pas l'impression de ne pas avoir d'environnement. Mon environnement c'est wmaker et gtk+.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Thomas Cataldo (site web personnel) . Évalué à 10.
o un toolkit graphique _complet_ (gtk et qt)
o un modèle orienté composant (bonobo et kparts)
o Communication interproc
o des API d'accessibilité
o des thèmes complets (wm + sons + toolkit + fontes)
o API pour les prefs façon base de registre :-)
Au niveau utilisation, un environnement donne un niveau d'intégration qu'il est impossible d'obtenir avec un assemblage fait maison de logiciels : changement des raccourcis clavier de toutes les applis dans un endroit unique, barres d'outils avec ou sans texte, etc...
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Anonyme . Évalué à -5.
- un toolkit graphique _complet_ (gtk et qt) : ne sont pas fournis par KDE ni GNOME, ce sont des prérequis.
- un modèle orienté composant (bonobo et kparts) : je ne connais pas dans le détail mais à ce que j'en ai compris, c'est plus un moins.
- Communication interproc : je ne sais pas ce que c'est
- des API d'accessibilité : capital ?
- des thèmes complets (wm + sons + toolkit + fontes) : il y'a des themes complets pour d'autres environnement, les sons ça c'est pas un problème mais ça ne me semble pas vital, le « toolkit » t'en a déjà parlé plus haut et je n'ai aucune polices fournie par KDE ni GNOME sur ma machine mais par XFree...
- API pour les prefs façon base de registre :-) : comme pour l'histoire de composant, je ne suis pas persuadé que réinventer regedit soit un truc vital mais je suis assez persuadé que l'on ne peut pas considérer cela comme un critère discriminant concernant le débat qui nous préoccupe.
Pour ma part, je ne prend pas parti pour une acception du terme environnement plutôt qu'une autre. J'entends bien tes arguments (ceux qui ne passent pas à la trappe selon moi), GNOME et KDE sont plus complets globalement. Néanmoins si on me demande ce que j'utilise, j'aurai du mal à définir wmaker + aterm + les dockappps comme un simple gestionnaire de fenetres.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par #3588 . Évalué à -2.
De toutes façons ça a l'air d'être présent dans GTK2 et les libs (non-Gnome) qui vont avec... donc pas une exclusivité Gnome/KDE.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par pasBill pasGates . Évalué à 4.
Pourquoi est-ce que ce serait un moins ? J'ai vraiment du mal a voir quel desavantage ca peut apporter.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Anonyme . Évalué à -3.
Clarté et simplicité ?
Toujours est-il que ça ne me semble pas etre un discriminant valable pour définir ce qu'est un environnement.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Guillaume Laurent (site web personnel) . Évalué à 7.
Et si tu veux appeler ton wm un environnement, bof, pourquoi pas. On va pas faire un thread à sodomiser les drosophiles sur la question, quand même.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par tanguy_k (site web personnel) . Évalué à 4.
Par exemple dans KOffice si tu veux mettre un tableau, un graphique, une image etc... dans un long rapport fait avec KWord, cela se fera très facilement grâce à kpart qui appelera de facon transparente pour l'utilisateur les autres programmes de KOffice.
Du coté du programmeur il y a beaucoup moins à programmer puisqu'il utilise les programmes d'autres personnes
Evidemment c'est un mécanisme qui prend quelques cycles cpu en plus mais la puissance et la ré-utilisabilité est à ce prix.
Quelques fois l'interet est moindre, par exemple avec un PDF qui s'affiche directement dans le navigateur au lieu de s'ouvrir dans une fenetre séparé.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par #3588 . Évalué à 10.
Bien qu'en général, ça n'en soit pas l'unique manière non plus...
Quelques fois l'interet est moindre, par exemple avec un PDF qui s'affiche directement dans le navigateur au lieu de s'ouvrir dans une fenetre séparé.
Voilà exactement le genre de truc que je trouve insupportable. Alors, que ça existe, très bien, mais j'espère que ceux qui font ça ont la présence d'esprit de placer des options permettant de lancer un viewer externe, de son choix.
Unix a toujours fonctionné sur le principe une appli par travail à effectuer, et c'est plutot efficace. Quand j'écris un mail avec mutt, ça se fait avec l'éditeur de mon choix. Ça tombe bien, un éditeur c'est fait pour éditer du texte, et ça le fait plutot bien (du moins mon éditeur favori le fait à ma convenance). Avec la plupart des clients mail graphiques, on n'a pas ce choix, il faut se contenter de l'éditeur intégré qui bien sûr est plutot pauvre, n'a pas les mêmes raccourcis claviers, etc. C'est ce que permettent les composants s'il y a un éditeur prêt à intégrer. Seulement si c'est facile à programmer, j'imagine que quand mutt demande l'exécution de l'éditeur par défaut c'est pas compliqué non plus. Et si les composants sont intéressants quand il y a vraiment interaction, assez souvent il n'y en a pas, et donc aucune raison de supprimer l'autre méthode, celle du programme externe.
Je ne parle en aucun cas de remplacer l'une par l'autre, mais de leur coexistence, quand la méthode des composants n'est pas indispensable. Je n'ai pas l'impression que les logiciels vont dans le sens de cette coexistence en ce moment, c'est bien dommage.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par tanguy_k (site web personnel) . Évalué à 4.
http://www.freehackers.org/kvim/screenshots.html(...)
un vim avec une interface kpart qui peut s'intégrer partout.
Pour le moment, kpart existe depuis kde2 donc c'est récent, koffice qui est le principale programme qui l'utilise n'est pas encore mature.
Le meilleur reste à venir, la technologie est là et fonctionne bien, maintenant il reste à créer encore une bonne partie des applications autour. Il faut bien évidemment l'utiliser de manière intelligente et ne pas en foutre partout sans réfléchir.
Mais nul doute que c'est beaucoup plus puissant et que ca a beaucoup plus d'avenir qu'un simple system("vim");
Il faut voir le potentiel de cette technologie et son évolution possible, pas uniquement ce que cela nous apporte à l'instant même.
Analogie : quand les gens on vu la première voiture ils devaient surement bien rigoler car ca ne devait pas avancer plus vite que leurs vélos et avec beaucoup de contraintes supplémentaires.
Et pourtant aujourd'hui tout le monde utilise des voitures (c'est pas pour autant que l'on a abandonné le vélo).
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Guillaume Laurent (site web personnel) . Évalué à -1.
Et alors ? Ça ne veut pas dire qu'on a pas trouvé mieux depuis. Les composants sont précisément une amélioration de ce principe.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par #3588 . Évalué à 1.
Faudrait lire un petit peu au-delà de la première phrase, j'ai bien dit que les composants
- étaient une amélioration,
- qu'ils pouvaient être indispensables,
mais que dans les cas où ils ne le sont pas il est dommage d'imposer une solution quand
- une autre solution aussi simple existe
- l'utilisateur peut préférer cette autre solution (gout personnel, légereté de la solution, etc.)
- les deux solutions peuvent coexister
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Plus simple, vraiment ? Il faut
- trouver où se trouve le programme (si il est installé, ce qui n'est pas forcément garanti)
- connaitre les options qu'il accepte en ligne de commande (qui ne sont pas forcément les mêmes selon les versions)
- savoir comment lui passer les données (fichier temporaire, stdin...) et sous quel format
- savoir quoi faire en cas d'erreur du programme (crash, etc...), et comment detecter ces erreurs
et chacun de ses paramètres est complètement différent d'un programme à l'autre. Un framework de composant unifie tout ça.
l'utilisateur peut préférer cette autre solution
Trouve-moi un utilisateur "normal" (ie pas un geek) qui se préoccupe de se genre de détail, et on en reparle.
Oui, les deux solutions peuvent co-exister, il reste bien quelques fois où un simple fork() fait l'affaire, mais bon... au final pas tant que ça.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par #3588 . Évalué à -1.
J'ai parlé des cas simples, qui existent, là tu cherches déja à compliquer. Pour un mail (je reprends l'exemple de mutt) il va certainement chercher $EDITOR, et ajoute le nom de son fichier temporaire. Pas compliqué.
S'il y a besoin de plus compliqué (on commence à sortir de ce dont je parlais) eh bien tu n'as qu'à considérer que l'utilisateur est trop exigeant et que ce sera à lui de fournir ces infos, dans un fichier de conf, dans un tab de conf, n'importe où, peu importe.
Regarde par exemple les front-ends aux logiciels de gravure où il faut tout spécifier. Le front-end n'a rien à supposer. Ca peut sembler compliqué à l'utilisateur, mais vu que la solution par défaut sera d'utiliser les composants, il n'y touchera que s'il y tient.
Le framework unifie mais restreint. C'est une solution.
Trouve-moi un utilisateur "normal" (ie pas un geek) qui se préoccupe de se genre de détail, et on en reparle.
C'est du même niveau que quand les pro-Windows expliquent qu'un utilisateur normal n'a pas à choisir son wm. Dans la mesure où on peut toujours lui en mettre un par défaut, un qui soit user-friendly, il n'y a aucune raison de critiquer l'existence des autres, chacun a la possibilité de choisir. Si les logiciels libres s'étaient basés sur ton utilisateur dit "normal", le bureau serait un clone de celui de Windows, il n'y aurait aucune variété, aucune adaptation possible à l'utilisateur.
Oui, les deux solutions peuvent co-exister, il reste bien quelques fois où un simple fork() fait l'affaire, mais bon... au final pas tant que ça.
Mais il n'y a que sur ces cas là que je regrette l'inexistence de l'alternative... C'est très peu comparé à l'ensemble des utilisations des composants, oui, je l'ai dit, mais ça peut aussi être très pratique...
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Qu'est-ce que tu fais si $EDITOR pointe vers un truc inexistant ? Si il se plante ? Et regarde le cas "simple" d'Emacs qui a un mode par type de fichier. Pour faire du mail, idéalement tu veux indented-text, auto-fill, et filladapt (et j'oublie font-lock). vi lui est complètement différent. Comment tu fais pour lui dire de passer au bon mode ? Et si l'utilisateur décide de ne pas envoyer le mail, et quitte brutalement l'éditeur, comme tu fais pour reconnaitre ça ?
et que ce sera à lui de fournir ces infos, dans un fichier de conf, dans un tab de conf, n'importe où, peu importe.
Sauf que tu dois te frapper le codage du parsing de la config, plus l'éditeur de préférences parce que de nos jours éditer des fichiers de conf à la main c'est un peu passé de mode.
Le framework unifie mais restreint. C'est une solution.
Oui, et elle recouvre 99% des besoins des utilisateurs normaux.
C'est du même niveau que quand les pro-Windows expliquent qu'un utilisateur normal n'a pas à choisir son wm.
Et ils ont tout à fait raison. Enfin non, c'est pas qu'il n'a pas à le faire, c'est qu'il s'en fout complètement.
Si les logiciels libres s'étaient basés sur ton utilisateur dit "normal", le bureau serait un clone de celui de Windows, il n'y aurait aucune variété, aucune adaptation possible à l'utilisateur.
Et peut-être qu'on aurait un peu plus d'applis correctes.
Par ailleurs, Windows est tout à fait customisable, c'est comme Linux faut juste savoir comment faire. J'ai des copains qui connaissent bien Windows et ce qu'ils me montrent est tout aussi "impressionnant" que ce qu'ont voit sous Linux.
Mais il n'y a que sur ces cas là que je regrette l'inexistence de l'alternative
Ben ça existe toujours, et quelques fois même on s'en sert.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par #3588 . Évalué à 3.
Tu retournes au défaut que tu as proposé évidemment.
Et regarde le cas "simple" d'Emacs qui a un mode par type de fichier. Pour faire du mail, idéalement tu veux indented-text, auto-fill, et filladapt (et j'oublie font-lock). vi lui est complètement différent. Comment tu fais pour lui dire de passer au bon mode ?
Si ça t'amuse de le faire tu peux essayer, mais sinon laisse l'utilisateur définir sa ligne de commande, ce sera bien suffisant. C'est un programme externe, évidemment qu'on ne va pas chercher à la contrôler avec le même niveau que des composants. On lance, on récupère éventuellement un fichier temporaire. Pour les viewers on lance, on ne fait rien d'autre, l'utilisateur a défini la ligne de commande.
Sauf que tu dois te frapper le codage du parsing de la config, plus l'éditeur de préférences parce que de nos jours éditer des fichiers de conf à la main c'est un peu passé de mode.
N'importe quoi ça fait maximum une ligne, si tu as une config ça s'ajoute comme n'importe quelle autre élément de config. De plus les fichiers de mode c'est passé de mode ? Tiens donc, suivant que ça t'arrange, l'utilisateur est tantot geek tantot neuneu. Eh bien puisque tu considérais que c'était forcément un geek, il saura bien faire avec un fichier de conf, pas la peine d'en proposer plus.
Oui, et elle recouvre 99% des besoins des utilisateurs normaux.
L'utilisateur normal étant défini parce qu'il utilise, ce qui n'est jamais que ce qui lui est proposé, ce 99% ne veut d'une part rien dire, et ne serait d'autre part pas une bonne raison pour oublier 1% restant quand l'implémentation n'est pas un problème. Enfin les développeurs font ce qu'ils veulent, je dis juste que c'est dommage.
Et ils ont tout à fait raison. Enfin non, c'est pas qu'il n'a pas à le faire, c'est qu'il s'en fout complètement.
Comme je l'ai dit, celui qui s'en fout prendra celui qui est proposé par défaut. Pour les autres ce n'est certainement pas toi qui a à leur imposer ce qu'ils veulent utiliser. Dès qu'on a des critères c'est normal de vouloir choisir un wm plutot qu'un autre.
Et peut-être qu'on aurait un peu plus d'applis correctes.
Rien ne permet de l'affirmer, par contre ce serait beaucoup de choses en moins. Mais vas-y, fais ton OS+Framework+Logiciels avec une norme stricte. C'est satisfaisant pour le développeur, pas trop pour l'utilisateur.
Ben ça existe toujours, et quelques fois même on s'en sert.
Très bien dans ces cas là, mais ça a tendance à disparaître dès qu'une solution composants est écrite.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
Et un p'tit message d'erreur, non, jamais ?
Si ça t'amuse de le faire tu peux essayer, mais sinon laisse l'utilisateur définir sa ligne de commande, ce sera bien suffisant.
Oh ben oui, c'est top user-friendly ça. Et avec un peu de chance il faudra quand même coder l'expansion de quelques token genre '%F' pour placer le nom du fichier dans certains cas, et prier pour que ça n'ouvre pas quelques trous de sécurité (y a pas mal d'exploits qui partent de ce genre de trucs).
N'importe quoi ça fait maximum une ligne, si tu as une config ça s'ajoute comme n'importe quelle autre élément de config.
Plus la ligne qui dit "l'utilisateur veut ça plutôt qu'un composant".
Et tu oublies toujours la détéction et récupération en cas de crash du truc, le cancel quand il s'agit d'un éditeur, etc...
De plus les fichiers de mode c'est passé de mode ? Tiens donc, suivant que ça t'arrange, l'utilisateur est tantot geek tantot neuneu.
Attends, on parle bien d'une appli utilisant des composants, donc un truc un tantinet moderne tout de même, sur laquelle tu voudrais absolument ajouter la possibilité pour l'utilisateur de lancer le programme de son choix à la place du composant standard. Donc soit tu es cohérent, et tu fais la config propre, soit tu es goret et tu ajoute deux options dans le fichier de conf, "spécial geek" a bricoler à la main. Pourquoi pas. :-)
L'utilisateur normal étant défini parce qu'il utilise
Non, il est défini par ce qu'il veut faire. C'est à dire pas bricoler des fichiers de confs et s'emmerder avec des considérations "fork()+exec() c'est mieux qu'un composant" auquel il ne comprend rien de toute façon.
Dès qu'on a des critères c'est normal de vouloir choisir un wm plutot qu'un autre.
Non, ça n'est pas "normal" de vouloir choisir son WM. C'est comme si tu me disais qu'il est "normal" de vouloir bricoler sa voiture ou sa chaine Hi-Fi. 99% des gens s'en foutent complètement, ils veulent juste conduire ou écouter de la musique.
Rien ne permet de l'affirmer
Ça fait plus de 10 ans que je fréquente Unix, et je crois que je peux tout à fait t'affirmer que la profusion de toolkits graphiques, de window managers, et au final la non-spécification de l'environnement (aussi bien l'API système, avant POSIX, que l'API graphique "haut niveau") est très largement responsable de l'echec d'Unix (et maintenant de Linux) sur le desktop.
C'est satisfaisant pour le développeur, pas trop pour l'utilisateur.
Windows satisfait beaucoup plus d'utilisateurs que Linux, pour le cas où tu ne l'aurais pas remarqué.
A moins que tu ne crois sérieusement qu'ils sont tous victimes de la propagande du grand méchant Microsoft, auquel cas autant arrêter là la discussion.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par #3588 . Évalué à 0.
Non, jamais. Dans le cas du viewer pas de problème. Dans le cas d'un éditeur si tu y tiens, soit le fichier temporaire est toujours vide, soit il a changé. Quelqu'en soient les raisons, c'est pas ton problème, l'utilisateur peut rééditer s'il le souhaite. Tu t'obstines à détourner les propos en présentant un cas qui n'est pas celui dont je parle.
Oh ben oui, c'est top user-friendly ça.
Tous tes arguments sont contradictoires les uns avec les autres. C'est une fonctionnalité en plus, pour les quelques uns qui préfèrent puisque tu prétends qu'il sont peu. L'aspect user-friendly est un faux prétexte, sans valeur, comme tout le reste de tes posts.
Et avec un peu de chance il faudra quand même coder l'expansion de quelques token genre '%F' pour placer le nom du fichier dans certains cas, et prier pour que ça n'ouvre pas quelques trous de sécurité (y a pas mal d'exploits qui partent de ce genre de trucs).
De plus en plus ridicule. Alors comme ça on utilise une bibliothèque de composants, mais on refuse d'utiliser une gestion de haut niveau des chaines de caractères. Et pourquoi pas les traiter dans du code assembleur ? Une concaténation, sans %F (c'est pas user-friendly de toutes facons le %F), ça suffit.
Plus la ligne qui dit "l'utilisateur veut ça plutôt qu'un composant".
Non. Sa présence suffit évidemment.
Et tu oublies toujours la détéction et récupération en cas de crash du truc, le cancel quand il s'agit d'un éditeur, etc...
Non. Déja dit, depuis le début. Tu es dans ton délire qui consiste à faire le boulot d'un composant sans composant. On n'es pas dans ce cadre là et tu le sais, mais ça doit t'amuser.
Attends, on parle bien d'une appli utilisant des composants, donc un truc un tantinet moderne tout de même, sur laquelle tu voudrais absolument ajouter la possibilité pour l'utilisateur de lancer le programme de son choix à la place du composant standard.
Ca n'a rien de moderne, c'est juste une manière de faire, comme une autre. (cas dont je parle, depuis le début).
Donc soit tu es cohérent, et tu fais la config propre, soit tu es goret et tu ajoute deux options dans le fichier de conf, "spécial geek" a bricoler à la main. Pourquoi pas. :-)
C'est toi qui affirme que cette appli est propre, moderne, sous prétexte qu'elle utilise des composants, et c'est faux. Fournir un viewer pourri alors qu'il en existe des bons sur le système, voilà le truc de goret. Et si ton appli est si propre, ajoute l'option dans les préférences, si c'est bien fait ça ne posera pas de problèmes. Ah mais je vois la suite, soudain comme par magie ce truc là aura été fait comme un porc, et ce sera compliqué puisque ça t'arrange ?
(...)
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par #3588 . Évalué à 0.
Non, il est défini par ce qu'il veut faire. C'est à dire pas bricoler des fichiers de confs et s'emmerder avec des considérations "fork()+exec() c'est mieux qu'un composant" auquel il ne comprend rien de toute façon.
Ridicule suite, détournement de propos. Jamais l'utilisateur, dans aucun cas, n'aura à s'emmerder avec des considérations exec/composant. C'est comme si je disais que pour utiliser des composants dans un logiciel, l'utilisateur devait savoir ce que sont les composants. C'est d'une betise affligeante.
Non, ça n'est pas "normal" de vouloir choisir son WM. C'est comme si tu me disais qu'il est "normal" de vouloir bricoler sa voiture ou sa chaine Hi-Fi. 99% des gens s'en foutent complètement, ils veulent juste conduire ou écouter de la musique.
Si, c'est normal. Pour le wm, la voiture ou la hi-fi, 99% des gens prendront ce qu'ont leur donne, et tous ceux qui souhaiteront bricoler quelque chose eux-meme le feront. De plus 99% seulement des gens ne sera jamais une justification. Que tu le veuilles ou non, choisir certains composants en tant qu'application externe, c'est une fonctionnalité en plus. Et pour le wm, il suffit de constater que quand le choix existe, ceux qui le veulent font ce choix, et qu'ils trouvent le wm qui leur convient et qu'ils ne souhaitent pas en changer. Tout ce que tu veux faire, c'est réduire les possibilités des utilisateurs sous prétexte de facilité à programmer.
Ça fait plus de 10 ans que je fréquente Unix, et je crois que je peux tout à fait t'affirmer
On l'avait pas entendu depuis longtemps celui-là, mais encore une fois cet argument-choc auto-suffisant est sans valeur dans ce contexte.
que la profusion de toolkits graphiques, de window managers, et au final la non-spécification de l'environnement (aussi bien l'API système, avant POSIX, que l'API graphique "haut niveau") est très largement responsable de l'echec d'Unix (et maintenant de Linux) sur le desktop.
Très fort comme réflexion basique et limitée. Tu as raison sur les conséquences de la diversité non organisée (le manque de norme), et c'est bien ça la cause du retard (ce que tu appelles l'échec, et qui n'en est pas un) d'Unix sur le desktop. Ton choix c'est la manière autoritaire, la Solution Unique, orientée monopole, avec un seul type de logiciel par catégorie, surtout pas de choix. On peut difficilement trouver plus basique, c'est du meme niveau que ceux qui défendent le monopole de MS comme étant quelque chose de pratique pour l'uniformité. La bonne solution c'est évidemment un travail sur des normes, permettant d'avoir des dizaines de toolkits sans que ça gene personne.
Windows satisfait beaucoup plus d'utilisateurs que Linux, pour le cas où tu ne l'aurais pas remarqué.
T'as remarqué qu'ils étaient plus nombreux et qu'ils n'avaient jamais rien connu d'autre ? Et qu'ils n'étaient souvent pas si satisfaits que ça ? La satisfaction des utilisateurs de Windows, on ne peut pas la quantifier, les conditions ne le permettent pas. Et même si c'est vrai pour la majorité, faudra mesurer la contribution des composants. Ce qu'on peut mesurer, c'est la satisfaction des utilisateurs de Linux, parce qu'ils viennent souvent de Windows et qu'ils pourraient y retourner. Or la diversité est une des principales raisons de satisfaction. Le normes manquent, c'est un fait, c'est pas une raison pour vouloir faire un truc hyper restreint comme Windows capable seulement de faire des logiciels moyens pour convenir à une hypothétique moyenne, et non à chacun.
A moins que tu ne crois sérieusement qu'ils sont tous victimes de la propagande du grand méchant Microsoft, auquel cas autant arrêter là la discussion.
Si ça t'amuses d'encore détourner les propos, continue, on a l'habitude maintenant. Microsoft a un discours commercial vantant ses produits, même pour des qualités qu'ils n'ont pas, c'est normal pour une entreprise, tout le monde le fait. Ca n'a aucun lien avec cette histoire de propagande, le fait est que quand on ne connait qu'un produit, on ne peut pas le comparer à autre chose. Si tu n'as utilisé qu'une voiture dans ta vie, tu vois qu'elle t'a rendu bien des services, mais tu n'es certainement pas capable de la comparer à d'autres que tu n'as pas conduites. L'uniformité chez MS elle a quelques avantages mais aussi beaucoup de défauts, par exemple celui de ne pas réussir à évoluer, résultat ils n'ont pas d'uniformité dans l'interface graphique (composants Win3.1 mélangés à des Win9x, etc.). Pas de quoi s'extasier.
Enfin bon, la discussion est terminée, oui, vu que j'avais explicité tout ce qui était nécessaire dès le début, que tu n'en as tenu aucun compte par mauvaise foi, que tu n'as rien apporté et que tout ce que tu as fait c'est en gros de minables détournements de propos et changements de contextes.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Maintenant pour achever de démontrer ce que tu avances, je te suggère d'ajouter à Konqueror la possibilité de visualiser les .txt dans l'éditeur que l'on veut. C'est assez simple comme cas, ça ? En plus KDE fourni tout ce qu'il faut comme classes pour wrapper le lancement de process. Et une fois que tu l'aura fait, ce qui je suis sur ne te prendra que quelques heures puisque c'est si simple, propose le patch sur kfm-devel et kde-devel. Je suis sur qu'il y aura plein de personnes interessées.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Sebastien . Évalué à 4.
- Communication interproc : je ne sais pas ce que c'est
Ta deuxième phrase repond à la première ! Si tu ne sais pas ce qu'est une communication entre processus alors forcemment tu ne peux comprendre l'interet d'un modèle orienté composant.
Dans toute architecture, à un certain niveau de complexité, la communication entre tes composants devient importante. Si tu ne fais rien, ça fini en point à point et c'est le bordel. D'ou le besoin de définir des bus objets ou d'utiliser des middleware orienté messages pour établir des comm avec des interfaces claires et définies.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Anonyme . Évalué à -3.
Que je sache, on a un système qui tourne très bien sans, non ? De là à s'agiter le poireau entre jargoneux, il n'y a pas tant d'évidences que ça.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Vivi (site web personnel) . Évalué à 3.
arf, le bon vieil argument anti-progessiste :)
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par #3588 . Évalué à 2.
> arf, le bon vieil argument anti-progessiste :)
Tu vas bien vite en affirmant qu'il s'agit de progrès. Le progrès c'est des choses possibles en plus, pas en moins.
Si je reprends l'exemple de l'affichage de PDF, que quelqu'un a donné, je ne trouve pas ça un progrès qu'un logiciel décide à ma place quel moteur d'affichage va être utilisé.
C'est comme l'apport du graphique : ça facilite peut-être énormément, et il y a beaucoup d'applications où c'est même indispensable et plus ergonomique, mais ce n'est pas une raison pour abandonner la commande en ligne quand celle-ci peut exister. Dans ce cas, rien de tel pour utiliser le logiciel en automatique, dans un script, si on n'a pas X, ou même si on préfère. Qu'un logiciel propose la CLI et la GUI quand il n'y a pas de raison de n'avoir que la seconde, ça c'est un progrès. Qu'il supprime la première sans raison, c'est plus discutable.
Les composants devraient faire la même chose : s'ils sont vraiment indispensable parce qu'il faut de la communication entre composants, très bien, les utiliser, c'est l'évidence même ; mais si c'est juste pour afficher une pauvre aide html ou un pdf, je ne trouve pas ça un progrès que d'imposer cette méthode à l'utilisateur, alors que d'autres existent et sont même a priori plus simples à implémenter...
Evidemment ce n'est pas un problème des composants en eux-même, c'est celui de leur utilisation systématique et exclusive.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Non, justement.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par #3588 . Évalué à 1.
> Non, justement.
Si. C'est le cas de tout ce qui concerne de l'affichage sans avoir besoin d'un retour. Lancer un navigateur avec une doc html, un viewer pdf, etc. Même récupérer un texte créé par un autre programme n'est pas si compliqué pourvu qu'on ait bien sur aucune exigence d'interaction lors de l'édition.
C'est peut-etre des cas limités par rapport à l'étendue des possibilité des composants, mais ils existent, et l'implémentation est extrêmement simple. Proposer les deux solutions ne coûterait rien. En imposant une solution, l'aspect modulaire des composants apparait peut-etre pour le développeur, mais certainement pas pour l'utilisateur qui se retrouve avec quelque chose de bien moins configurable.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
Et même si ça l'était, avoir 2 solutions complètement différentes, une pour un problème général et l'autre pour un cas particulier du même problème, complique inutilement les choses.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par #3588 . Évalué à 0.
Pour dire qu'on préfère son propre viewer html (ne nécessitant pas de retour) plutot que le composant, il suffit d'un fork comme tu l'as dit, et d'une variable dans un fichier de conf ou dans l'environnement. Je parle des cas où ceci suffit. Ca reste plutot simple.
Et même si ça l'était, avoir 2 solutions complètement différentes, une pour un problème général et l'autre pour un cas particulier du même problème, complique inutilement les choses.
2 solutions différentes apportent avant tout du choix. Ensuite si leur coexistence est impossible, faut faire des choix, par exemple en faveur des composants si le modèle est compliqué.
En tous cas il ne s'agit pas vraiment du même problème, puisque celui des composants concerne la communication et l'interaction entre ces composants. Pour un viewer html c'est juste du lancement d'application externe...
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
Et donc juste pour faire plaisir à quelques geeks, il faudrait coder 2 façons de visualiser de l'html, plus toute la config qui va avec, etc... ? Et tu penses vraiment que c'est "simple" ? Et quel va être le bénéfice, ça ne va même pas être plus rapide, fork()+exec() est plus lent d'un simple dlopen(). C'est vraiment du bloat totalement gratuit.
Par ailleurs, les composants n'empèchent pas le choix, il peut y avoir plusieurs composants disponible pour une même fonction, et que l'environnement te laisse choisir celui que tu veux utiliser par défaut.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par #3588 . Évalué à 1.
C'est toi qui le dit.
il faudrait coder 2 façons de visualiser de l'html
L'une d'entre elles étant triviale.
plus toute la config qui va avec, etc... ?
Idem pour la config, dans le cas du programme externe.
Et tu penses vraiment que c'est "simple" ?
Evidemment, si certains le programmes le font c'est bien pour se décharger de tout une tâche. Il faut bien sûr qu'il n'y ait pas de besoins d'interactions ou autres choses de ce style. C'est pour ça qu'une simple doc html me parait un bon exemple.
Et quel va être le bénéfice, ça ne va même pas être plus rapide, fork()+exec() est plus lent d'un simple dlopen(). C'est vraiment du bloat totalement gratuit.
Une doc qui s'ouvre dans un navigateur déja ouvert, non pas trop, c'est pas violent. Pour le bénéfice, c'est simplement celui du choix. Est-ce qu'il est choquant de s'installer Mozilla sous Windows alors qu'IE est installé ? Non. C'est exactement la même chose, une simple question de choix, que le développeur ne devrait pas présumer.
Par ailleurs, les composants n'empèchent pas le choix, il peut y avoir plusieurs composants disponible pour une même fonction, et que l'environnement te laisse choisir celui que tu veux utiliser par défaut.
C'est très bien ça, ça va dans le sens du choix. Encore faut-il que l'élément qu'on souhaite soit un composant, ce qui n'est pas forcément le cas, d'où le besoin de gérer un programme externe quand ils conviennent très bien. Evidemment, si tout existait sous forme de composants, on ne ferait que du composant, et ce serait très bien.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Guillaume Laurent (site web personnel) . Évalué à 0.
Tu l'as codé souvent, pour pouvoir dire ça ?
Evidemment, si certains le programmes le font c'est bien pour se décharger de tout une tâche.
Ah, c'est sur, fork()+exec() ça reste plus simple que re-coder un éditeur de texte ou autre :-).
Pour le bénéfice, c'est simplement celui du choix.
Encore une fois : trouve moi un utilisateur non-geek qui se préoccupe de forker un programme externe plutôt que d'utiliser un composant. Trouve m'en un qui sache ce que c'est que forker un programme, et ce qu'est un composant, déjà.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par #3588 . Évalué à -1.
Oui, mais c'est toi qui parle des cas compliqués, alors que j'ai précisé dès le début que je ne parlais pas de ceux-là.
Encore une fois : trouve moi un utilisateur non-geek qui se préoccupe de forker un programme externe plutôt que d'utiliser un composant. Trouve m'en un qui sache ce que c'est que forker un programme, et ce qu'est un composant, déjà.
Tu éviteras de demander quelque chose de débile la prochaine fois : ainsi tu veux un utilisateur faisant la différence entre exec et composant ? Strictement, aucun intéret, l'utilisateur n'a pas besoin de connaitre ça. L'utilisateur c'est les SOLUTIONS qu'il peut comparer, et a priori ça l'intéresse de choisir celle qui lui convient. Toi tout ce que tu proposes c'est une solution unique, pour ma part j'ai regretté l'absence d'une coexistence des deux méthodes, le lancement de programme externe pouvait avoir des avantages. Tu peux continuer à expliquer que le progrès c'est de réduire les possibilités de l'utilisateur, c'est pas vraiment crédible.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Guillaume Laurent (site web personnel) . Évalué à 8.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par #3588 . Évalué à -3.
On a un système qui tourne très bien sans, comme dit Yeupou, et l'intérêt pour l'utilisateur n'est pas si flagrant que ça (réel, mais pas si grand, et ça dépend encore de l'utilisation qu'on en fait). Pour le programmeur, oui, pour certaines choses. De là à dire que c'est nécessaire à un environnemnt...
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Si, le desktop qu'il décrit c'est grosso-modo celui que j'avais il y a 3 ou 4 ans, et qui existe depuis 90 (au nom du WM près).
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par #3588 . Évalué à -1.
Par contre avec ou sans composants, aucune différence de son coté, c'est du coté du développement de l'application qu'ils apportent beaucoup.
La meme appli peut être réalisée avec ou sans composants, ce sera seulement beaucoup plus simple de la réaliser avec des composants. Coté utilisateur ça ne change rien (à part la disponibilité, puisque c'est plus simple à développer), mais ces avantages (certains) ne sont en aucun cas comparables aux exemples sans X11 que tu donnes.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Va faire du couper/coller entre un tableur et un traitement de texte sans composants, pour voir.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par #3588 . Évalué à -2.
Tu n'as pas l'air de lire, et comme par hasard tu ne cites pas les passages contenant les réponses...
J'ai parlé de la même appli (ou ensemble d'applications). La même chose donc pour l'utilisateur, par définition.
A programmer, évidemment qu'on va vouloir le faire avec des composants (dans le cas d'applications graphiques) si jamais on a un tel besoin de couper/coller. Je n'ai jamais remis en cause leur utilité. Je ne parle ici, que de tes exemples, qui sont de mauvaises comparaisons.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Par "ensemble d'applications" tu veux dire une suite office, avec un tableur et un traitement de texte par exemple ? :-)
Je ne comprend pas ton argument. Tu dis que pour l'utilisateur, "fork()+exec()" ou des composants c'est pareil. C'est faux, pour la bonne raison que les composants permettent plus de choses que fork()+exec().
Si tout ce que tu dis c'est que dans les cas ou fork()+exec() marche, alors utiliser des composants est identique du point de vue de l'utilisateur, c'est faux aussi. Tu as une interface beaucoup plus cohérente avec des composants, et c'est plus rapide.
Il reste encore pleins de cas ou un fork()+exec() est utile, ou même nécéssaire (le front-end au graveur de CD par ex.), mais globalement un framework de composants comme KPart apporte un énorme plus.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par #3588 . Évalué à -1.
Je n'ai dit ça nulle part. Je crois qu'il y a confusion. Dans ce thread-ci, j'ai juste dit que tes exemples consistant à comparer l'apport des composants à celui du graphique sur la console n'étaient pas pertinents. Rien de plus. Et dans les autres threads je ne parle que de cas à interactions nulles.
Pour le reste de ce post je suis tout à fait d'accord sur les avantages des composants, et que la plupart du temps un fork/exec ne pourra pas les remplacer.
Précision néanmoins sur :
Si tout ce que tu dis c'est que dans les cas ou fork()+exec() marche, alors utiliser des composants est identique du point de vue de l'utilisateur, c'est faux aussi. Tu as une interface beaucoup plus cohérente avec des composants, et c'est plus rapide.
Si, c'est équivalent pour l'utilisateur si c'est ce qu'il veut. Ca peut paraitre moins cohérent, et alors, si l'utilisateur l'a demandé ? Et pour la vitesse, idem, c'est son problème. Si on veut utiliser un éditeur pour des raisons d'ergonomie, on s'en fout du coté "cohérent", c'est l'éditeur qu'on utilise toute la journée, et on peut etre prêt à sacrifier un peu sur la vitesse si on tient à l'avoir. Mais ça c'est juste une question de choix, de préférence.
Maintenant, si tu veux que la solution par défaut soit celle des composants, plus "cohérente", plus rapide, ça me parait aussi naturel de la proposer par défaut, oui.
[^] # TEMPS MORT !
Posté par homoanonymus . Évalué à -2.
Bon les gars, au bout de 27 posts il est peut-etre temps que vous vous retrouviez devant une ptite bière tous les deux en amoureux !
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Thomas Cataldo (site web personnel) . Évalué à 9.
Et le modèle objet t'aide à garantir la pérénité de tes interfaces de programmation. Chaque logiciel expose un idl public, et tout le monde peut l'utiliser. A mon avis, pouvoir utiliser gnumeric pour faire un tableau dans abiword est une fonctionnalité nécessaire.
Pour les prefs, une fois que tu as défini l'addresse de ton proxy et celle de ton serveur smtp dans 15 logiciels differents, tu en voit vite l'intêret. La "base de registre" gérée par un démon utilisateur permet aux applications d'être informés des changements de prefs sans redémarrer.
A mon avis, les environnements graphiques sous unix/linux seront au point quand je n'aurai plus besoin d'un terminal.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par mickabouille . Évalué à 3.
Non, vraiment, impossible de se passer de ligne de commande.
D'ailleurs, je me demande si la ligne de commande n'est pas le mode de commande le plus évolué : c'est tout simplement l'extension de notre fonction la plus évoluée, le language. Impossible d'être plus expressif que notre mode de communication naturel.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par #3588 . Évalué à 10.
GNUStep n'est pas un gestionnaire de fenêtres, mais bien un environnement de développement.
[^] # Re: GNUStep, non ça n'est pas ...
Posté par Timbert Benoît . Évalué à 0.
Par contre souvent quand on parle de GNUStep, on parle en fait de GNUstep Workspace, qui est un environement graphique issu de GNUStep, et non un environnement de développement...
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par Jak . Évalué à -2.
Alors évidemment, sur petite machine, IceWM ou FluxBox tournera mieux que Gnome ou KDE, mais dans ce cas, autant ne pas mettre X, ça fera gagner de la place.
Récemment, j'ai du installer un modem sur un vieux PC portable (Pentium 133, 32 Mo de RAM), et comme il m'a été impossible de le faire fonctionner sous Windows 98 (problème certainement résolvable en réinstallant, mais ça, je ne fais pas), j'ai pris 500 Mo du disque et installé une Slackware 7.1 (noyau 2.2.16, XFree 3.3.6, Gnome 1.2), car il est certainement beaucoup plus simple de lâcher quelqu'un sous Gnome 1.2 que sous IceWM.
Donc à tous ceux qui la ramènent avec leur IceWM/FluxBox/WindowMaker : bande de l4m3rZ, repassez en console !
Non, mais c'est vrai, à la fin.
[^] # Trop fort
Posté par Jak . Évalué à -4.
# Petite machine?
Posté par Grégory SCHMITT . Évalué à 10.
Mais qui tourne encore bien sous xfree 3.3.6 avec twm, emacs et latex...
A propos, quel est le plus léger? X 3.3.6 ou 4.2 (sachant que je peux décharger le max de modules) ?
[^] # Re: Petite machine?
Posté par Serge2 . Évalué à 0.
J'utilise Blackbox, nickel.
[^] # Re: Petite machine?
Posté par kesako . Évalué à 4.
Ne me dit pas que tu utilise lynx...
[^] # Re: Petite machine?
Posté par Serge2 . Évalué à 6.
Sinon, j'ai Netscape 4.08 mais c'est quand même un peu lourd.
[^] # Re: Petite machine?
Posté par domi . Évalué à 4.
Dillo ne gère pas les frames, ni le javascript, mais c'est du graphique et c'est donc plus "confortable" que links ou lynx. En effet, malheureusement de plus en plus de sites mettent des infos directement dans les images :-(
D'autre part, Dillo est assez vivant, et des évolutions sont en cours. Du moment, qu'il reste léger, je le conserve.
[^] # Re: Petite machine?
Posté par franck villaume (site web personnel) . Évalué à 3.
je conseille la version en cvs car les cookies sont gérés. C'est bien pratique pour se logger sur pas mal de sites dont dlfp.
Par contre, je conseille de se munir d'un outil tel que gtm ou d4x pour les téléchargements. Car avec Dillo, il est actuellement possible de télécharger mais cela reste assez obscure.
Voilà.
--
C01N C01N will save your soul !!!
[^] # Re: Petite machine?
Posté par kesako . Évalué à 3.
oui oui on aimerai bien savoir...
car je pense que le pb n'est pas gnome ou kde mais Xfree qui prend vraiment beaucoup de ram pour simplement afficher un xterm...
[^] # Re: Petite machine?
Posté par Anonyme . Évalué à 9.
Quand à XFree qui prend de la RAM pour afficher un xterm, il en prend autant pour 1 que 10 xterm...
[^] # Re: Petite machine?
Posté par Alberto . Évalué à 10.
En 800x600 256 couleurs (800x600x1), XFree ne prend que 1 ou 2mo si mes souvenirs sont bons. Maintenant en 1280x1024-16m, l'image est 10fois plus grande en memoire (1280x1024x4), c'est aussi simple que ca.
[^] # Re: Petite machine?
Posté par Thomas Cataldo (site web personnel) . Évalué à 2.
[^] # Re: Petite machine?
Posté par Jak . Évalué à 3.
[^] # Re: Petite machine?
Posté par domi . Évalué à 10.
Moi j'ai l'exemple d'une machine avec une vieille Matrox. On avait des plantages assez fréquents en mode graphique, avec diverses applications : écran figé.
On a cherché un peu, et rien trouvé qui puisse justifier ces plantages. On est repassé en Xfree 3.3.6 et là ça marche sans aucun problème.
Je ne pense pas qu'ils testent les cartes vraiment anciennes pour les nouveaux Xfree. Il est normal qu'ils portent leur effort sur les cartes les plus récentes.
[^] # Re: Petite machine?
Posté par Jak . Évalué à 3.
Et je n'ai aucun plantage sous XFree 4, il me dit juste qu'il n'a pas assez de mémoire et il affiche en 320x200, mais ça marche.
Donc pour moi, c'est bien que XFree 4 prend plus de mémoire que XFree 3. Mais je dois admettre ne pas avoir essayé d'alléger le XFree 4 en supprimant les modules (vu que j'ai toujours pas trouvé de doc explicite sur le sujet).
[^] # Re: Petite machine?
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 6.
c qu'il n'a pas reussi a determiner la quantite
de memoire disponible sur ta carte graphique. En
aucun cas la memoire du pc est necessaire a ce momment la.
Ton pb c que tu n'as pas donnee as XFree4 la taille
de la memoire de ta carte et comme elle est 'unsupported' il ne peut pas faire un probe.
Recherche qque chose comme 'VideoRam' dans la page de man
[^] # Re: Petite machine?
Posté par mickabouille . Évalué à 0.
# Economise tes ressources, DuC...
Posté par jigso . Évalué à 10.
Je ne conteste pas que KDE/GNOME ne soient pas adaptes a des petites conf, mais il doit etre possible de les 'tuner' pour gagner quelques precieux cycles cpu - on vire les gadgets, les effets, les font d'ecrans qui bouge, les background par desktop, etc...
Et quand on veut faire des comparatifs, le minimum est de donner un etat de la memoire, pour voir ce qui prend reellement de la place, pas de se contenter de simples impressions.
Honnetement je pense qu'il merite de revoir ca copie.
Le troll sous-jacent n'est pas KDE/GNOME, mais bon-sens/idiotie.
[^] # Re: Economise tes ressources, DuC...
Posté par Prosper . Évalué à 10.
Gmc a bien des qualités mais il est loin d egaler konqueror et ses kioslaves.
# Autre liste
Posté par Jean . Évalué à 10.
Mes 2¢...
# [Troll] ça m'énerve !
Posté par Timbert Benoît . Évalué à -1.
[^] # Re: [Troll] ça m'énerve !
Posté par poil oq . Évalué à 6.
L'important c'est que chacun configure son écran comme il l'entend. Et c'est pas les possibilités qui manquent ;o)
[^] # Moi aussi ...
Posté par Jak . Évalué à 7.
En effet, il n'y a rien d'autre d'aussi abouti.
Allez voir les abrutis qu'on peut trouver sur HFR : ce sont eux qui promeuvent Windows XP version WAreZ auprès de l'utilisateur lambda.
Gnome et KDE sont les 2 seuls environnements que l'on peut présenter à un utilisateur lambda qui ne connaît que Windows, il faudrait voir à ne pas l'oublier. Si tu peux t'en passer, tant mieux, moi, je peux même me passer de X si je veux.
[^] # Re: Moi aussi ...
Posté par mickabouille . Évalué à -1.
# Juste une remarque !
Posté par Samuel Pajilewski . Évalué à -4.
Bon, juste pour faire taire certains detracteurs
[^] # Re: Juste une réponse
Posté par Anonyme . Évalué à 4.
Et ?
A priori, ce qui est possible sur une distrib GNU/Linux est possible sur une autre, tant que tout est libre.
Personne ne dit que la SuSE est une distribution qui n'a aucun mérite technique. Tout comme personne ne dit que les produits microsoft n'ont aucun mérites technique.
On dit que ce n'est pas intégralement libre - pas du tout dans le second cas - et que ça, ça nous défrise, au point qu'on refuse de recommander ceci.
Dans le premier cas, parce que l'on trouve intolérable qu'une entreprise qui n'existe que grace aux logiciels libres (car si on retire ce qu'il y'a de libre dans une SuSE, je doute qu'elle soit commercialisable) ne joue pas le jeu des logiciels libres. Dans le second cas, on pense que les limitations de nature font que c'est un environnement fermé, où l'on ne peut que faire ce que la firme microsoft veut bien que l'on fasse, et certains pensent qu'il n'est pas acceptable de contribuer à la fracture sociale et économique mondiale.
[^] # Re: Juste une remarque !
Posté par Étienne . Évalué à 4.
Et en plus ca marche sur la Debian (je viens d'essayer), et je suis sûr que ca marche sur la RedHat, la Mandrake, la Slackware, une LFS et tout ce que vous voulez.
Bon, juste pour faire taire certains detracteurs ;)
Etienne
[^] # Hibernation
Posté par aThom . Évalué à -1.
Y a une commande spéciale pour gérer la chose parceque c'est bien pratique sous Windows, démarrage ultra rapide et ca mériterait d'être plus accessible.
Merci
[^] # Re: Hibernation
Posté par bad sheep (site web personnel) . Évalué à -4.
[^] # Re: Hibernation
Posté par aThom . Évalué à -2.
Je suis pas sûr que ce soit forcément au bios de faire le travail.
Je sais pas si la Suse le fait de manière automatique sur les portables mais ce serait de retrouver cette fonction sur les autres distros et sur les PC de bureau.
# Aucun interet ! la meme sur un pentium 90 ...
Posté par Code34 (site web personnel) . Évalué à -4.
finalement kde marche , ça swap, mais ça marche ... Quant à ximian ... il ne faut peut etre pas pousser :))) !
@+
Code34
[^] # Re: Aucun interet ! la meme sur un pentium 90 ...
Posté par mickabouille . Évalué à 2.
Si,si,si... ça marche. Et même plutôt bien (et même avec seulement 24Mo de ram). Par contre, ça ne doit pas être la toute dernière série de paquets. Et puis, faut pas abuser : pas Mozilla (galeon est limite), pas évolution, ... (même si en ce qui me concerne, le problème est plutôt l'espace disque).
[^] # Re: Aucun interet ! la meme sur un pentium 90 ...
Posté par Mes Zigues . Évalué à 0.
J'ai installé une mandrake 8.1 sur un P75/40MoRAM/850MoDD et cela fonctionne aussi bien que W95 et même mieux pour le traitement d'images (GIMP).
<don't feed the troll please/>
# une petite configuration machine ?
Posté par BOB BOB . Évalué à -2.
Le nouvelle acheteur d'ordinateur n'ira pas en magasin et s'acheter une machine qui vas a de telle vitesse et ayant une telle puissance.
La plus part des machine abordable de nos jours et disponible en magasin commence au alentour de 800 Mhz et la plus par ont 1 GHZ de CPU pour une machine complete ( facon de parler ) valant au alentour de 700$. ( 503.980 EURO ).
Et si vous dite mais c'est un portable il y a beaucoup de portable pas cher en vente sur Ebay ou autre dans ses prix ... qui sont 6 fois plus puissant.
Donc ce test bien qu'intéressant ne vaut pas grand chose aujourdhui car il n'aide pas a savoir ce qui a a être améliorer car cette technologie est déja tres tres dépasser et n'est même plus produite ...
Et les nouveau modele ne fonctionne pas comme les anciens ...
Je pense qu'aujourdhui Linux mérite sa place sur les ordinateur que monsieur et madame tout le monde vas aller acheter en magasin et non au puces ou dans une foires ou de son oncle qui s'en est payer un meilleur et nous vend/cede l'ancien a rabais.
Il serait bien que pour la respectabilité de Linux aujourdhui on commence a regarder de vrai test et non des test qui ne prouve et sert a rien en bout de ligne.
[^] # Re: une petite configuration machine ?
Posté par Serge2 . Évalué à 5.
Quand aux technologies "dépassées", je fais pratiquement la même chose avec mon 486sx portable sous Rh6.2 et mon Celeron 500 sous Mdk8.1. C'est vrai que c'est plus "zoli" Kde2 que Blackbox mais pour lire ses mails, faire du Perl et écrire 2 textes par an les deux se valent. Je ne remet pas en cause les nouveautés, au contraire mais je trouve important que l'on puisse adapter le système à sa machine et pas de changer de machine tous les 6 mois parcequ'elle est soit disant obsolète.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.