> Il peut y avoir plein d'explication. Une des explications qui fut donnée dans le message du départ de la discussion, c'est la disponibilité en libre totalement de KDE.
Très fort. Depuis des années Gnome perd des développeurs et KDE en gagne.
Ben il faut annoncer la mort proche de Gnome alors (si Gnome n'est pas déjà mort). Je dis ça, c'est juste pour être un peu cohérent.
> Les choix de GNOME furent ceux de Ximian.
Gnagna...
Quand evolution a été en standard dans Gnome STP ?
> gnome.org incitait à télécharger GNOME par Ximian
Faut arrêter la fumette.
> Raconter que GNOME et Ximian ont des destins qui ne sont pas lié, c'est oublié que Ximian fut HelixCode, une boite fondée explicitement dans l'idée d'embaucher les contributeurs majeurs à GNOME et distribuer GNOME.
Gnagna et patati et patata.
Ximian n'a pas tout fait. Désolé les cocos et c'est très loin d'être le cas.
Ils sont déjà bien occupé avec evolution, red carpet, les patchs OpenOffice et mono. Donc je vois pas comment il peuvent tout faire.
> Ce fut le porte parole de GNOME pendant trop longtemps pour que ce que fait MDI soit sans importance.
D'accord, j'ai compris. Je me prépare pour voir encore cet argument dans 2 ans.
Ça fait depuis 3 ans que MDI ne fait rien pour Gnome !
C'est claire.
Mais si c'est pas Xiniam, c'est Red Hat, si c'est pas Red Hat c'est Sun, et si c'est pas Sun c'est donc ton frère (ou une logique dans ce goût).
> Est-il est encore à la GNOME foundation, au fait ?
Oui. Sur 366 membres. Et sa voie compte pour 1 et pas pour 200 !
37 Sun.
22 Ximian.
7 Redhat.
Mon dieu, c'est grave, grave, grave !
Puis RedHat la joue petit bras. Selon mes infos ils sont 30 developpeurs sur Gnome et 7 nouvelles embauches pour bosser sur Gnome. Vas-y, je te laisse fantasmer sur tes nouveaux arguments sur une cohalition Sun/Red Hat pour avoir la main mise sur Gnome.
Tu sais qui est l'enfoiré qui a fait le mode spatial ?
C'est Red Hat !
L'enculé qui a fait Gtk+ 2 pour torpiller Gnome en performance ?
C'est Red Hat !
Cette putain de philosophie qui nous vires tous nos options qui nous permettaient avant d'avoir un bureau aux petits oignons.
Ce sont ces enculés d'Havoc et d'Owen. Des suppo de Red Hat.
Et pourquoi ?
Pour que ça coûte moins cher en hotline pour Red Hat. La philosophie du libre sur la customisation ils s'en torchent l'arrière train.
Tu vois, moi aussi je peux dire des conneries et en argumentant.
> L"idée que GNOME puisse utiliser Mono est au coeur de ses dernières déclarations ou je me trompe ?
Et encore une couche.
Pas fatigué ?
Ce que dit MDI n'engage que MDI. C'est compliqué à comprendre ?
Actuellement pratiquement personne veux de mono "dans" Gnome. Un binding c'est OK, mais pratiquement personne veut de mono comme "brique" de base.
C'est enregistré ?
> mais que cela explique le mécontentement de certains.
Un pointeur SVP.
> Abiword, Gnumeric (et son son bidule Guppi), ils sont presque tués du fait d'OpenOffice, non ?
Non.
OpenOffice sera plus utilisé mais les autres seront encore là et pour un bon moment (comme balsa).
> Tu es tristement deterministe. Vision étroite quand tu nous tiens...
Si tu veux. Mais on ne dit pas un truc sans vouloir assumer les conséquences du "truc" annoncé. Si beaucoup de développeurs Gnome se barrent, la question est :
- Où sont-ils ?
Lorsque question est :
- Comment fait Gnome avec son hémoragie de développeurs depuis plusieurs années ?
Et je n'ai toujours pas de réponse satisfaisante.
Quand ça ne va pas avec gcc, ça fork (egcs). Quand ça ne va pas avec XFree86, ça fork (X.org). Quand ça ne va pas avec xmule, ça fork (amule). etc, etc. Et avec Gnome, vous affirmez que ça ne va pas depuis plusieurs années et rien ne se passe (sauf un patch de 9ko).
J'attend toujours une explication.
> Moi ce qui m'amuse, c'est que tu sembles persuadé que ce sont les mêmes personnes qui donnent le même avis depuis 4 ans...
Moi ça me navre.
Être aussi assidu à faire les poubelles, ça me navre beaucoup.
> d'autres donnent un point de vue à distance.
Très loin le point de vue. Tellement loin que le repère est MDI qui n'a rien fait pour Gnome depuis 3 ans...
Reculé encore un peu et vous arriverez à articuler tout l'historique de Gnome sur Microsoft (ou apple).
J'ai pas d'argument massu, mais c'est aussi mon impression (pour les développeurs).
En gros les développeurs se concentrent sur vim/emacs/mozilla et préfèrent oublier leur bureau.
La mailing devel de Fedora (pro gnome, il faut bien le reconnaitre) que je lis, est assez significative. En gros, tout le monde s'en fous. Lorsqu'il y a un screenshot pour montrer un bug, c'est toujours le thème par défaut, le fond d'écran par défaut et gnome-terminal dans un coin.
C'est la flemme de changer les trucs par défaut qui l'emporte...
Vrai fausse nouvelle.
C'était déjà le cas depuis un bon moment.
L'upstream fait le travail de fond et les distributeurs corrigent les petits bobo qui restent. Corrections qui sont reportés à la version suivante de Linux.
Ça fait déjà depuis longtemps qu'une nouvelle version de Linux n'est pas sortie uniquement pour corriger un trou de sécurité ou un bug. Ce sont les distributeurs qui font ça.
Je trouve ça normal. Puis qui compile depuis les sources ?
A part quelques "rebelles".
Par contre, les fantasmes de fork par distribution, restent ...
des fantasmes.
> Je pense que le probleme de Gnome, c'est de ne pas avoir garde un message directeur et une vision d'ensemble coherente depuis ses debuts.
???
A part le virage Gnome 1 Gnome 2 il y a quoi ?
La vision est claire et cohérente depuis Gnome 2.0 et n'a pratiquement pas bougée Oui , Non ?
Oui. Définitivement.
Deux ans que Gnome 2.0 est sorti... et j'oublie sa longue période de gestation.
Biensûr, tu vas sauté sur le passage à spatial de Nautilus. Et alors ?
Le projet ne peut pas évoluer. Ce n'est pas bien ?
FC2 sort avec le mode spatial par défaut. Slackware fait la même chose. Les autres distributeurs vont probablement faire la même chose aussi (sauf quelqu'un qui y trouveront un niche).
Actuellement il y a une réflexion autour du framework (et pas forcément sur le language de programmation !).
Faut-il faire un framework qui supporte les nouvelles technos "ala .net" ou pas ?
Faut-il se rapprocher de Mozilla ?
Mais j'ai vu nul part que libgnome ou gconf ou ... allait être réécrit en C++ ou java ou C#, que les api allaient être cassées etc...
Il y a compatibilité ascendante depuis Gnome 2.0 ! Et Gnome 2.8 sera toujours compatible Gnome 2.0. Mais bien évidement il y a aussi de nouvelles api (la terre n'arrete pas tourner).
Tu connais les plans pour Gnome 2.10 ou 3.0 ?
Moi non. La discussion est en cours et est public ! Ce n'est pas le "méchant" MDI qui va imposer sa dictature dans un coin grace au bras armé de Sun et autres conneries que tu nous ponds.
> Aujourd'hui, ces differents groupes sont decus parce que Gnome n'est pas ce qu'on leur avait promis a l'epoque d'ou cette accumulation de mauvaise humeur et cette envie de retourner au temps de Gnome 1.0
Qui sont ces groupes ?
S'ils sont si nombreux, pourquoi il n'y a pas un "vrai" fork ?
J'aimerai que tu me donnes une explication.
> Ceux-la (et RMS en fait partie) sont decu par les dernieres orientations de MDI vers Mono sous licence Mit
N'en déplaise aux détracteurs de Gnome, MDI ce n'est pas (ou ce n'est plus) Gnome !
MDI est concentré sur Mono depuis plusieurs années et je ne vois pas une trace de Mono dans Gnome 2.8 à venir.
> [fondation de Gnome] Qt, ca pue c'est du C++
Jamais été dit par Gnome. Que des "fanatiques" de Gnome l'aient dit, je te crois. Mais pas la fondation Gnome. Gtkmm et Gnomemm font parti de Gnome et les binding pour tous les languages (dont le C++) ont toujours été pris en compte. Gnome est l'un des projets les plus ouverts vers les autres languages. Mais pour ça il faut utiliser le C pour les librairies de bas niveau.
Même si Qt/KDE a des bindings ils ne sont pas du niveau de Gtk/Gnome et pas aussi utilisés.
> Ceux-la sont particulierement mal a l'aise avec le soutien fort de MDI a Mono.
MDI qui ne fait plus rien pour Gnome. C'est un rappel.
> De fait, le gtk en C n'est pas en phase niveau facilite d'utilisation avec les langages et lib modernes (java, C#, Qt/C++, python, ...)
Ce qui est stupide comme réflexion.
Gtk# utilise Gtk+.
Oui , Non ?
Oui biensûr. Personne ne réécrit Gtk en C# ou java ou je_sais_pas_quoi. Il y a des bindings. Gnome a toujours reconnu l'importance de pouvoir développer des applis dans d'autres languages.
> [epoque de la liberation d'openoffice] OpenOffice, c'est genial, en 3 mois, on aura des composants Gnome : il s'est mis a mal les developpeurs d'abiword et de Gnumeric a qui il avait dit que ces deux logiciels seraient la suite office de Gnome. Surtout, ce n'etait qu'un effet d'annonce puisque 3 ans plus tard, on a pas plus qu'un vernis Gnome sur OpenOffice.
Et alors ?
Il faut ignorer OpenOffice ? Mozilla aussi ?
Tu fais la sourde oreille et fonce tête baissée ?
OpenOffice est important et avoir qu'un "vernis" Gnome est mieux que rien.
btw, OpenOffice n'a pas été fait pour Gnome. Je dis ça si tu ne l'as pas remarqué.
btw2, je me demande si tu ne mélanges pas tout et si MDI s'occupait encore de Gnome à l'époque de passage en libre d'Openoffice... J'ai un doute. Car ça fait depuis Gnome 2.0 (et un peu avant (sortie Gnome 1.4?)) que MDI ne s'occupe plus de Gnome.
> bonobo pour le rendre vaguement utilisable en C, on est en train de le faire lentement passer a la trappe parce que trop complique a utiliser et trop lourd.
Ou tu as vu ça ?
Regarde les programmes qui utilisent bonobo :
- evolution
- abiword
- guppi
- gnumeric
J'en oublie encore un paquet.
> Gnome se retrouve donc a pousser discretement le nouveau DBUS
DBUS ne remplace pas, ne remplacera JAMAIS bonobo. C'est claire !
Ou alors trouve moi un pointeur sur la mailing Gnome qui annonce plus ou moins ça.
> Et il y en a eu d'autres des derapages de MDI jetant la confusion sur la ligne directrice de Gnome. Pour formaliser le soutien de Sun, MDI a cree la Gnome Foundation mais la aussi, la base hackers qui n'aime pas les entreprises commerciales n'a pas forcement aime le principe de la Gnome Foundation comme le signale le post plus haut.
Psssss
T'es gerbant. Le complot mondial et patati et patata...
> Le focus sur l'amelioration de l'ergonomie oblige a changer un certain nombre d'habitudes, ce qui n'a pas plus du tout a la fois dans le principe et dans la facon dont cela a ete fait a aliene une partie de la base des developpeurs qui aimaient mieux l'ancienne facon.
Mais où sont tous ces hackers ?
Où ?
Ils bossent sur KDE, sur XFCE ? Ils sont où ?
C'est la seconde énorme hémoragie de hackers selon toi mais on ne sait toujours pas ce qu'ils font. C'est "bizarre".
S'il y a autant de hackers mécontents, ce fork (ou un autre) va cartonner alors !
Prenons date et voyons ce qu'il va arriver à ce fork (ou un autre) massivement supporté par des tonnes de développeurs déçus par Gnome (selon ton troll).
Franchement, les trolleurs KDE, vous n'en avez pas marre ?
Ça fait maintenant plusieurs années que vous nous tomber des trolls sur la merde qu'est Gnome et Gnome est toujours là et solidement installé (la preuve, ce fork fait sourire la majorité des gens).
Vous n'en avez pas marre ?
Moi, ce qui m'impressionne, c'est que ton troll a un score de 20 !
C'est dingue.
Dans deux ans tu nous feras encore une merde dans ce style pour nous dire que Gnome perd des développeurs, des utilisateurs, que c'est la débandade de chez la débandade et Gnome sera encore là et tu auras encore plein d'XP. Dans deux ans de plus tu vas encore en remettre une couche et tout le monde vas te trouver génial.
C'est délirant.
> Prenons l'exemple de la libesd, on ne peut s'y soustraire, on ne peut la remplacer.
Tu parles d'un système type "plugin". Ben effectivement Gnome n'est pas comme ça. Remarquons que le "tout plugin" est assez vite lourd à développer.
S'il n'y a pas gconf que doit faire l'appli ? Puis il faut coder l'utilisation du son même si esd n'est pas installé, etc...
Dans certain cas les plugin c'est bien (gnome-vfs a des plugin) dans d'autre c'est un peut plus douteux comme intérêt.
> Moi ce qui m'intrigue, et c'est surtout ça le problème, en prenant ton exemple c'est que dans debian :
> mon gnome terminal depend directement de libgnome, bonobo, gnomevfs, orbit ...
C'est normal.
Si dpkg marche grosso-modo comme rpm, tu remarqueras que gnome-terminal dépend aussi de la libc :-)
Les dépendances pour un executable sont faite avec ldd (pour faire simple) pour connaitre les librairies nécessaire.
Ça a un autre avantage. Si tu as un paquet qui fourni libgnome, bonobo, gnomevfs en même temps, ça ne dérange pas apt. T'es indépendant du paquetage des fonctionnalités. Tout ce qu'il faut pour apt, c'est trouver les fonctionnalités (quelles soient dans 50 paquets différents ou dans un paquet).
yeupou (qui vient encore de changer de pseudo...) est toujours en train d'inventer des trucs pour casser du sucre sur gtk+. C'est fatiguant.
> Richard et sa femme (post juste au dessus du tien)
Mais ça ne doit pas être gtk+ (et son nouveau modèle objet depuis la version 2 qui est effectivment plus lent que gtk+ 1). C'est peut-être gdk (qui n'utilise pas gtk ! C'est gtk qui utilise gdk) ou gimp (pour l'affichage des dessins et l'édition, gimp doit sûrement utiliser directement gdk).
Son post est effectivement plus interressant. C'est de l'utilisation "réelle" et pas une impression de lenteur car tel ou tel truc s'affiche avec 4 centièmes de seconde en trop. Fonctionnellement c'est embêtant. Malheureusement, je n'ai pas d'aide à fournir :-(
> Premièrement, ça reste à voir, à moins que tu ne sois "les développeurs" :-)
Non.
Mais si tu lis les mailing Gnome ou KDE, les développeurs sont surtout utilisateur de GNU/Linux et très occasionnellement de Windows ou Mac.
> Deuxièmement, je n'ai jamais dit le contraire, mais on dirait qu'une comparaison avec Windows, c'est digne d'un point Godwin, par ici.
Ben j'ai mal compris.
Comparer Gnome à Windows (par exemple) n'est pas un problème. Par contre les :
- "Gnome fait comme Windows NT avec le mode spatial donc c'est mal"
ou
- "KDE veut copier Windows donc c'est mal"
m'énervent beaucoup.
Où tu veux en venir ?
Que le menu pourrais s'afficher en 0,01 seconde au-lieu de 0,05 ?
Ça pourrait être 5 fois plus rapide. Mais pour être honnète, là je m'en fous complètement.
gqview est rapide avec les répertoires plein d'images et c'est ce qui compte. Puis il a aussi l'intéligence de s'occuper des thumbnails visibles en priorité et de faire l'affichage de l'image en parallèle. C'est beaucoup plus important que les 0,04 secondes perdu durant l'affichage du menu.
Konqueror s'affiche plus vite que nautilus mais pour les répertoires remplis d'image il devrait s'impirer de nautilus pour que l'utilisateur qui veut voir les dernière images d'un répertoire n'est pas a attendre durant 1000 x 0,04 secondes.
Lorsque je teste une applis, je m'amuse pas à redimensionner doucement la taille de la fenêtre ou fais trainer à la vitesse tout petit v une boite de dialogue pour voir si ça lague ou pas.
Ces trucs que m'en contre fous et on doit être très très nombreux dans ce cas.
> J'espere pour ceux qui utilisent GNOME que la copie à été revue sur ce point.
T'as pas espérer pour moi. Je me fous de ces petites optimisations.
Il y a des initiatives dans ce sens. Le but n'est pas de tout rassembler mais d'indiquer que lorsqu'on parle du framework gnome 2.6 on parle de :
- gtk+2.4
- Pango 1.4
- libxml etc...
Mais le but n'est vraiment pas de fusionner les bibliothèques !
C'est du côté de freedesktop qu'on pense à ça.
> On a l'impression que ça peut être modulaire, mais en fait non
C'est modulaire ! Arrêtes de dire n'importe quoi.
libgnome utilise bonobo, gnomevfs, Orbit etc...
Bref, il y a une organisation, une hierarchie.
Rien ne t'interdit de ne pas utiliser gnomelib pour utiliser seulement Orbit.
Modulaire ce n'est pas :
- chaque lib dépend seulement de la libc et je peux les ajouter et enlever indépendament.
Si tu veux remplacer ton gtk+ "standard" par un optimisé pour framebuffer tu peux.
Sinon demandes aussi la "fusion" de "sed/tar/bash/find/etc" pour faire un gros paquet "ligne de commande Unix".
Ça te gène pas cette tripoté de paquet pour la ligne de commande ?
Puis Mandrake pourrait faire un urpmi avec rpm déjà dedans. Red hat devrait arrêter de séparer librpm de rpm. Tant qu'on y est Red Hat devrait fournir rpm avec librpm, rpmpython, up2date, yum etc... Puis si Mandrake n'utilise pas rpmpython car il utilise perl avec urpmi, ben tant pis eux...
Puis après on pourait faire un gros paquet bien baveux pour gcc avec make, m4, autoconf, automake, gdb, lint, ld, etc dedans.
Désolé, mais je ne veux pas de ça. Ça frise le cauchemard. En tant qu'utilisateur final ça ne m'apporte rien (yum s'occupe de ça très bien) et en tant que développeur : beurk !
Puis à chaque correction de bug ou trou de sécurité s'il faut download 300 Mo toute les semaines, je dis :
- non non non non non non !
> le même modèle que celui de Microsoft, Gnome essaye de s'en éloigner.
Le but de Gnome n'est pas de s'éloigner de Windows.
Parfois Gnome s'éloigne, parfois il se rapproche mais c'est le hazard.
Idem pour KDE.
Le but est de faire un bon desktop. Qu'il ressemble ou non à Windows est le dernier des soucis des développeurs.
Perso, j'utilise pratiquement jamais Windows ou Mac et lorsque j'ai découvre une nouvelle version de Gnome, je ne la juge pas en terme :
- plus proche de Windows
- moins proche de Windows
Ce critère je m'en fous, comme vous ne pouvez pas l'imaginer...
> Mais voilà, pour moi soit tout est intégré, et ça n'a pas de sens de faire 36000 paquets séparés
Le problème de séparation en plusieurs bibliothèques est un problème de développeurs (maintenance/communication/réutilisation) et pas d'utilisateurs finals (y a apt/yum/etc pour régler ça pour eux).
Il y a (résumé très grossier) :
glib
gdk
pango
gtk+
gnomelib
Tu veux tout ça dans la même lib ? Quel intérêt ?
libxml étant un composant parmis d'autres, KDE peut l'utiliser. glib peut-être utilisé par arts. Je bosse sur un petit projet et j'utilise glib (mais pas gtk+) et libxml. XFCE qui fait un """petit""" bureau utilise """seulement""" gtk+ (je te conseille sérieusement de regarder du côté de XFCE, c'est peut-être le bon bureau pour toi). Tu crois que si glib/gdk/pango/gtk+/libxml/gnomelib/etc était dans la même bibliothèque se serait mieux pour la diversité ? Que l'ensemble des développeurs (pas seulement Gnome) serait content ?
Même si c'est parfois "casse couille", je préfère avoir beaucoup de bibliothèques qu'un truc monolithique.
Je vais te donner un exemple de ma "sincérité" sur le fait que la lenteur n'est pas critique pour moi.
Néanmoins, je suis comme tout le monde, je constate que lancer gnome-terminal alors qu'il n'est pas en cache, ça prend du temps.
Mais il faut relativer.
J'ai 3 disques dures (hde et hdg : deux très vieux disques) :
/dev/hde : débit hdparm : 8 Mo
/dev/hdg : débit hdparm : 8 Mo
/dev/hda : débit hdparm : 50 Mo
/dev/md0 : raid0 strippé de hde et hdg : débit hdparm : 15 Mo.
Ben j'utilise mon système avec /dev/md0 alors que j'ai une copie identique sur /dev/hda (pour backup ou en cas de "grosse merde" (je peux à tous moment booter dessus)).
Je réserve le gros débit de hda pour mes videos (enregistrement/lecture). Et pourtant si je boote avec /dev/hda c'est nettement plus rapide. Par exemple avec md0 je boote en 48 secondes et avec hda en 32...
> > Le configuration est lu une fois au début et c'est tout.
> Non.
le "une fois au début et c'est tout" c'est par application.
Sous Gnome, si une autre applie fait une modifcation les autres applis consernées sont informées par Gconf et il n'y a pas relecture (au pire tout est en cache).
> Bref, c'est loin d'etre aussi simpliste qu'on pourrait le penser initialement.
Oui, tout à fait.
Mais c'est pas LE problème des bureaux. Le matin je lance evolution/mozilla/etc... et c'est fini.
Si la lecture de la conf était deux fois plus lente, je le remarquerai même pas...
Le plus gros problème actuellement (tel que je le perçois) c'est que les informations sont "dispersées" un peu partout. Le réveille d'un programme qui dormait dans le swap peut être assez laborieux...
L'exemple typique, c'est le bouton "démarrer" du panel. Si tu n'y touche pas longtemps et fais plein de truc à côté, il faut dans les 3 secondes pour qu'il s'affiche c'est pas un problème de place mémoire ou de temps pour parser les fichiers. C'est le temps de déplacement de la tête de lecture du disque dure pour récupérer toutes les informations dispersées qui pose problème. Là il y a effectivement du travaille à faire. Notes que pour le menu du panel, gconf n'est pas utilisé et que si tout est en cache c'est très rapide (presque instantané).
gnome-session-properties, vires nautilus, sauves la session.
ou
"killall nautilus", lance un autre vm, puis sauve la session.
> c'est tellement entrelacé qu'au final on est obligé de tout avoir, et à ce moment là autant faire une seule lib mais c'est un avis personnel.
Pssssssss
Gnome-terminal utilise plein de truc, donc il y a plein de dépendances. Voilà, c'est tout. Si tu mets tout dans une librairie, ça change rien (apt sera moins "verbeux" et c'est tout).
Puis si tu veux n'utiliser que glib, libxml et Orbit tu peux. T'es pas obligé d'installer gtk+, gnomelib, bonobo...
En ce sans c'est modulaire. C'est pas modulaire dans le sens :
- les programmes du bureau Gnome doivent utiliser le moins de fonctionnalité Gnome.
> à grands coups de grep et de find, on se rend compte que c'est éparpillé dans plusieurs fichiers dont les noms sont du genre 12343523423.934531.
Tu as raison :-)
Mais il y a gconf-editor et gconftool.
C'est comme si tu disais que les bases de données sql te gonffre car grep et find retournent n'importe quoi.
Pas moi. Je veux dire pas dans le projet Gnome. Ça peut-être un projet séparé qui utilise Gnome ou (comme c'est actuellement le cas) un projet de la distribution.
Un "control center" c'est normalement pour les admis pas pour les desktop-user (évidemment, quand il n'y a pas d'admin....).
> j'avais jamais vu que "fichier" était remplacé par "document"
Je l'ai vu dans KDE 3.2.3.
Ça a même créé une incompréhension car j'ai dit à quelqu'un qu'il y avait le menu "envoyer ce lien" dans le menu "fichier" alors que c'était le menu "document".
Ceci dit, "Fichier" ou "Document" je m'en fous un peu...
> Il se trouve que dans le cas d'un desktop, ce temps _est_ genant pour de nombreuses raison que j'ai la flemme d'expliciter ici. Rien qu'en occupation cpu, parser du xml pose plus de problemes que lire un fichier texte.
N'importe quoi. Tu lances une application toutes les secondes ?
Le configuration est lu une fois au début et c'est tout.
Y a 20 ans il y avait peut-être apple II en ligne de commande uniquement...
Les premiers mac n'ont jamais été spatial. Ça ne consernait que les dossiers sur le bureau.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 0.
Je pensais que tu aurais proposé koffice.
Les programmes que tu n'aimes pas tu les proposes aux autres.
T'es un rigolo ?
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 0.
Très fort. Depuis des années Gnome perd des développeurs et KDE en gagne.
Ben il faut annoncer la mort proche de Gnome alors (si Gnome n'est pas déjà mort). Je dis ça, c'est juste pour être un peu cohérent.
> Les choix de GNOME furent ceux de Ximian.
Gnagna...
Quand evolution a été en standard dans Gnome STP ?
> gnome.org incitait à télécharger GNOME par Ximian
Faut arrêter la fumette.
> Raconter que GNOME et Ximian ont des destins qui ne sont pas lié, c'est oublié que Ximian fut HelixCode, une boite fondée explicitement dans l'idée d'embaucher les contributeurs majeurs à GNOME et distribuer GNOME.
Gnagna et patati et patata.
Ximian n'a pas tout fait. Désolé les cocos et c'est très loin d'être le cas.
Ils sont déjà bien occupé avec evolution, red carpet, les patchs OpenOffice et mono. Donc je vois pas comment il peuvent tout faire.
> Ce fut le porte parole de GNOME pendant trop longtemps pour que ce que fait MDI soit sans importance.
D'accord, j'ai compris. Je me prépare pour voir encore cet argument dans 2 ans.
Ça fait depuis 3 ans que MDI ne fait rien pour Gnome !
C'est claire.
Mais si c'est pas Xiniam, c'est Red Hat, si c'est pas Red Hat c'est Sun, et si c'est pas Sun c'est donc ton frère (ou une logique dans ce goût).
> Est-il est encore à la GNOME foundation, au fait ?
Oui. Sur 366 membres. Et sa voie compte pour 1 et pas pour 200 !
37 Sun.
22 Ximian.
7 Redhat.
Mon dieu, c'est grave, grave, grave !
Puis RedHat la joue petit bras. Selon mes infos ils sont 30 developpeurs sur Gnome et 7 nouvelles embauches pour bosser sur Gnome. Vas-y, je te laisse fantasmer sur tes nouveaux arguments sur une cohalition Sun/Red Hat pour avoir la main mise sur Gnome.
Tu sais qui est l'enfoiré qui a fait le mode spatial ?
C'est Red Hat !
L'enculé qui a fait Gtk+ 2 pour torpiller Gnome en performance ?
C'est Red Hat !
Cette putain de philosophie qui nous vires tous nos options qui nous permettaient avant d'avoir un bureau aux petits oignons.
Ce sont ces enculés d'Havoc et d'Owen. Des suppo de Red Hat.
Et pourquoi ?
Pour que ça coûte moins cher en hotline pour Red Hat. La philosophie du libre sur la customisation ils s'en torchent l'arrière train.
Tu vois, moi aussi je peux dire des conneries et en argumentant.
> L"idée que GNOME puisse utiliser Mono est au coeur de ses dernières déclarations ou je me trompe ?
Et encore une couche.
Pas fatigué ?
Ce que dit MDI n'engage que MDI. C'est compliqué à comprendre ?
Actuellement pratiquement personne veux de mono "dans" Gnome. Un binding c'est OK, mais pratiquement personne veut de mono comme "brique" de base.
C'est enregistré ?
> mais que cela explique le mécontentement de certains.
Un pointeur SVP.
> Abiword, Gnumeric (et son son bidule Guppi), ils sont presque tués du fait d'OpenOffice, non ?
Non.
OpenOffice sera plus utilisé mais les autres seront encore là et pour un bon moment (comme balsa).
> Tu es tristement deterministe. Vision étroite quand tu nous tiens...
Si tu veux. Mais on ne dit pas un truc sans vouloir assumer les conséquences du "truc" annoncé. Si beaucoup de développeurs Gnome se barrent, la question est :
- Où sont-ils ?
Lorsque question est :
- Comment fait Gnome avec son hémoragie de développeurs depuis plusieurs années ?
Et je n'ai toujours pas de réponse satisfaisante.
Quand ça ne va pas avec gcc, ça fork (egcs). Quand ça ne va pas avec XFree86, ça fork (X.org). Quand ça ne va pas avec xmule, ça fork (amule). etc, etc. Et avec Gnome, vous affirmez que ça ne va pas depuis plusieurs années et rien ne se passe (sauf un patch de 9ko).
J'attend toujours une explication.
> Moi ce qui m'amuse, c'est que tu sembles persuadé que ce sont les mêmes personnes qui donnent le même avis depuis 4 ans...
Moi ça me navre.
Être aussi assidu à faire les poubelles, ça me navre beaucoup.
> d'autres donnent un point de vue à distance.
Très loin le point de vue. Tellement loin que le repère est MDI qui n'a rien fait pour Gnome depuis 3 ans...
Reculé encore un peu et vous arriverez à articuler tout l'historique de Gnome sur Microsoft (ou apple).
Allez ! courage !
[^] # Re: Un fork pour un gnome d'expert
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 0.
J'ai pas d'argument massu, mais c'est aussi mon impression (pour les développeurs).
En gros les développeurs se concentrent sur vim/emacs/mozilla et préfèrent oublier leur bureau.
La mailing devel de Fedora (pro gnome, il faut bien le reconnaitre) que je lis, est assez significative. En gros, tout le monde s'en fous. Lorsqu'il y a un screenshot pour montrer un bug, c'est toujours le thème par défaut, le fond d'écran par défaut et gnome-terminal dans un coin.
C'est la flemme de changer les trucs par défaut qui l'emporte...
[^] # Re: hummm
Posté par 007 . En réponse au message Remplacer APM par ACPI. Évalué à 0.
Pour arrêter de suite :
service apmd stop
# Re:
Posté par 007 . En réponse au journal Le noyau linux change de mode de développement. Évalué à 0.
C'était déjà le cas depuis un bon moment.
L'upstream fait le travail de fond et les distributeurs corrigent les petits bobo qui restent. Corrections qui sont reportés à la version suivante de Linux.
Ça fait déjà depuis longtemps qu'une nouvelle version de Linux n'est pas sortie uniquement pour corriger un trou de sécurité ou un bug. Ce sont les distributeurs qui font ça.
Je trouve ça normal. Puis qui compile depuis les sources ?
A part quelques "rebelles".
Par contre, les fantasmes de fork par distribution, restent ...
des fantasmes.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à -2.
> Je pense que le probleme de Gnome, c'est de ne pas avoir garde un message directeur et une vision d'ensemble coherente depuis ses debuts.
???
A part le virage Gnome 1 Gnome 2 il y a quoi ?
La vision est claire et cohérente depuis Gnome 2.0 et n'a pratiquement pas bougée Oui , Non ?
Oui. Définitivement.
Deux ans que Gnome 2.0 est sorti... et j'oublie sa longue période de gestation.
Biensûr, tu vas sauté sur le passage à spatial de Nautilus. Et alors ?
Le projet ne peut pas évoluer. Ce n'est pas bien ?
FC2 sort avec le mode spatial par défaut. Slackware fait la même chose. Les autres distributeurs vont probablement faire la même chose aussi (sauf quelqu'un qui y trouveront un niche).
Actuellement il y a une réflexion autour du framework (et pas forcément sur le language de programmation !).
Faut-il faire un framework qui supporte les nouvelles technos "ala .net" ou pas ?
Faut-il se rapprocher de Mozilla ?
Mais j'ai vu nul part que libgnome ou gconf ou ... allait être réécrit en C++ ou java ou C#, que les api allaient être cassées etc...
Il y a compatibilité ascendante depuis Gnome 2.0 ! Et Gnome 2.8 sera toujours compatible Gnome 2.0. Mais bien évidement il y a aussi de nouvelles api (la terre n'arrete pas tourner).
Tu connais les plans pour Gnome 2.10 ou 3.0 ?
Moi non. La discussion est en cours et est public ! Ce n'est pas le "méchant" MDI qui va imposer sa dictature dans un coin grace au bras armé de Sun et autres conneries que tu nous ponds.
> Aujourd'hui, ces differents groupes sont decus parce que Gnome n'est pas ce qu'on leur avait promis a l'epoque d'ou cette accumulation de mauvaise humeur et cette envie de retourner au temps de Gnome 1.0
Qui sont ces groupes ?
S'ils sont si nombreux, pourquoi il n'y a pas un "vrai" fork ?
J'aimerai que tu me donnes une explication.
> Ceux-la (et RMS en fait partie) sont decu par les dernieres orientations de MDI vers Mono sous licence Mit
N'en déplaise aux détracteurs de Gnome, MDI ce n'est pas (ou ce n'est plus) Gnome !
MDI est concentré sur Mono depuis plusieurs années et je ne vois pas une trace de Mono dans Gnome 2.8 à venir.
> [fondation de Gnome] Qt, ca pue c'est du C++
Jamais été dit par Gnome. Que des "fanatiques" de Gnome l'aient dit, je te crois. Mais pas la fondation Gnome. Gtkmm et Gnomemm font parti de Gnome et les binding pour tous les languages (dont le C++) ont toujours été pris en compte. Gnome est l'un des projets les plus ouverts vers les autres languages. Mais pour ça il faut utiliser le C pour les librairies de bas niveau.
Même si Qt/KDE a des bindings ils ne sont pas du niveau de Gtk/Gnome et pas aussi utilisés.
> Ceux-la sont particulierement mal a l'aise avec le soutien fort de MDI a Mono.
MDI qui ne fait plus rien pour Gnome. C'est un rappel.
> De fait, le gtk en C n'est pas en phase niveau facilite d'utilisation avec les langages et lib modernes (java, C#, Qt/C++, python, ...)
Ce qui est stupide comme réflexion.
Gtk# utilise Gtk+.
Oui , Non ?
Oui biensûr. Personne ne réécrit Gtk en C# ou java ou je_sais_pas_quoi. Il y a des bindings. Gnome a toujours reconnu l'importance de pouvoir développer des applis dans d'autres languages.
> [epoque de la liberation d'openoffice] OpenOffice, c'est genial, en 3 mois, on aura des composants Gnome : il s'est mis a mal les developpeurs d'abiword et de Gnumeric a qui il avait dit que ces deux logiciels seraient la suite office de Gnome. Surtout, ce n'etait qu'un effet d'annonce puisque 3 ans plus tard, on a pas plus qu'un vernis Gnome sur OpenOffice.
Et alors ?
Il faut ignorer OpenOffice ? Mozilla aussi ?
Tu fais la sourde oreille et fonce tête baissée ?
OpenOffice est important et avoir qu'un "vernis" Gnome est mieux que rien.
btw, OpenOffice n'a pas été fait pour Gnome. Je dis ça si tu ne l'as pas remarqué.
btw2, je me demande si tu ne mélanges pas tout et si MDI s'occupait encore de Gnome à l'époque de passage en libre d'Openoffice... J'ai un doute. Car ça fait depuis Gnome 2.0 (et un peu avant (sortie Gnome 1.4?)) que MDI ne s'occupe plus de Gnome.
> bonobo pour le rendre vaguement utilisable en C, on est en train de le faire lentement passer a la trappe parce que trop complique a utiliser et trop lourd.
Ou tu as vu ça ?
Regarde les programmes qui utilisent bonobo :
- evolution
- abiword
- guppi
- gnumeric
J'en oublie encore un paquet.
> Gnome se retrouve donc a pousser discretement le nouveau DBUS
DBUS ne remplace pas, ne remplacera JAMAIS bonobo. C'est claire !
Ou alors trouve moi un pointeur sur la mailing Gnome qui annonce plus ou moins ça.
> Et il y en a eu d'autres des derapages de MDI jetant la confusion sur la ligne directrice de Gnome. Pour formaliser le soutien de Sun, MDI a cree la Gnome Foundation mais la aussi, la base hackers qui n'aime pas les entreprises commerciales n'a pas forcement aime le principe de la Gnome Foundation comme le signale le post plus haut.
Psssss
T'es gerbant. Le complot mondial et patati et patata...
> Le focus sur l'amelioration de l'ergonomie oblige a changer un certain nombre d'habitudes, ce qui n'a pas plus du tout a la fois dans le principe et dans la facon dont cela a ete fait a aliene une partie de la base des developpeurs qui aimaient mieux l'ancienne facon.
Mais où sont tous ces hackers ?
Où ?
Ils bossent sur KDE, sur XFCE ? Ils sont où ?
C'est la seconde énorme hémoragie de hackers selon toi mais on ne sait toujours pas ce qu'ils font. C'est "bizarre".
S'il y a autant de hackers mécontents, ce fork (ou un autre) va cartonner alors !
Prenons date et voyons ce qu'il va arriver à ce fork (ou un autre) massivement supporté par des tonnes de développeurs déçus par Gnome (selon ton troll).
Franchement, les trolleurs KDE, vous n'en avez pas marre ?
Ça fait maintenant plusieurs années que vous nous tomber des trolls sur la merde qu'est Gnome et Gnome est toujours là et solidement installé (la preuve, ce fork fait sourire la majorité des gens).
Vous n'en avez pas marre ?
Moi, ce qui m'impressionne, c'est que ton troll a un score de 20 !
C'est dingue.
Dans deux ans tu nous feras encore une merde dans ce style pour nous dire que Gnome perd des développeurs, des utilisateurs, que c'est la débandade de chez la débandade et Gnome sera encore là et tu auras encore plein d'XP. Dans deux ans de plus tu vas encore en remettre une couche et tout le monde vas te trouver génial.
C'est délirant.
[^] # Re: une discrimination intolérable !
Posté par 007 . En réponse à la dépêche Poudre Verte vs NaDa. Évalué à 1.
Et dans la pratique aussi. Quand je suis stressé et/ou que quelque chose passe mal, je prend toujours mes dragées FUSCHIA (*).
(*) : en vente en pharmacie.
[^] # Re: ho sigh, windows...
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 1.
Tu parles d'un système type "plugin". Ben effectivement Gnome n'est pas comme ça. Remarquons que le "tout plugin" est assez vite lourd à développer.
S'il n'y a pas gconf que doit faire l'appli ? Puis il faut coder l'utilisation du son même si esd n'est pas installé, etc...
Dans certain cas les plugin c'est bien (gnome-vfs a des plugin) dans d'autre c'est un peut plus douteux comme intérêt.
> Moi ce qui m'intrigue, et c'est surtout ça le problème, en prenant ton exemple c'est que dans debian :
> mon gnome terminal depend directement de libgnome, bonobo, gnomevfs, orbit ...
C'est normal.
Si dpkg marche grosso-modo comme rpm, tu remarqueras que gnome-terminal dépend aussi de la libc :-)
Les dépendances pour un executable sont faite avec ldd (pour faire simple) pour connaitre les librairies nécessaire.
Ça a un autre avantage. Si tu as un paquet qui fourni libgnome, bonobo, gnomevfs en même temps, ça ne dérange pas apt. T'es indépendant du paquetage des fonctionnalités. Tout ce qu'il faut pour apt, c'est trouver les fonctionnalités (quelles soient dans 50 paquets différents ou dans un paquet).
[^] # Re: Gnome Leger?
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 1.
> Richard et sa femme (post juste au dessus du tien)
Mais ça ne doit pas être gtk+ (et son nouveau modèle objet depuis la version 2 qui est effectivment plus lent que gtk+ 1). C'est peut-être gdk (qui n'utilise pas gtk ! C'est gtk qui utilise gdk) ou gimp (pour l'affichage des dessins et l'édition, gimp doit sûrement utiliser directement gdk).
Son post est effectivement plus interressant. C'est de l'utilisation "réelle" et pas une impression de lenteur car tel ou tel truc s'affiche avec 4 centièmes de seconde en trop. Fonctionnellement c'est embêtant. Malheureusement, je n'ai pas d'aide à fournir :-(
[^] # Re: ho sigh, windows...
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 0.
Non.
Mais si tu lis les mailing Gnome ou KDE, les développeurs sont surtout utilisateur de GNU/Linux et très occasionnellement de Windows ou Mac.
> Deuxièmement, je n'ai jamais dit le contraire, mais on dirait qu'une comparaison avec Windows, c'est digne d'un point Godwin, par ici.
Ben j'ai mal compris.
Comparer Gnome à Windows (par exemple) n'est pas un problème. Par contre les :
- "Gnome fait comme Windows NT avec le mode spatial donc c'est mal"
ou
- "KDE veut copier Windows donc c'est mal"
m'énervent beaucoup.
[^] # Re: Gnome Leger?
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 0.
Où tu veux en venir ?
Que le menu pourrais s'afficher en 0,01 seconde au-lieu de 0,05 ?
Ça pourrait être 5 fois plus rapide. Mais pour être honnète, là je m'en fous complètement.
gqview est rapide avec les répertoires plein d'images et c'est ce qui compte. Puis il a aussi l'intéligence de s'occuper des thumbnails visibles en priorité et de faire l'affichage de l'image en parallèle. C'est beaucoup plus important que les 0,04 secondes perdu durant l'affichage du menu.
Konqueror s'affiche plus vite que nautilus mais pour les répertoires remplis d'image il devrait s'impirer de nautilus pour que l'utilisateur qui veut voir les dernière images d'un répertoire n'est pas a attendre durant 1000 x 0,04 secondes.
Lorsque je teste une applis, je m'amuse pas à redimensionner doucement la taille de la fenêtre ou fais trainer à la vitesse tout petit v une boite de dialogue pour voir si ça lague ou pas.
Ces trucs que m'en contre fous et on doit être très très nombreux dans ce cas.
> J'espere pour ceux qui utilisent GNOME que la copie à été revue sur ce point.
T'as pas espérer pour moi. Je me fous de ces petites optimisations.
[^] # Re: ho sigh, windows...
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 0.
Il y a des initiatives dans ce sens. Le but n'est pas de tout rassembler mais d'indiquer que lorsqu'on parle du framework gnome 2.6 on parle de :
- gtk+2.4
- Pango 1.4
- libxml etc...
Mais le but n'est vraiment pas de fusionner les bibliothèques !
C'est du côté de freedesktop qu'on pense à ça.
> On a l'impression que ça peut être modulaire, mais en fait non
C'est modulaire ! Arrêtes de dire n'importe quoi.
libgnome utilise bonobo, gnomevfs, Orbit etc...
Bref, il y a une organisation, une hierarchie.
Rien ne t'interdit de ne pas utiliser gnomelib pour utiliser seulement Orbit.
Modulaire ce n'est pas :
- chaque lib dépend seulement de la libc et je peux les ajouter et enlever indépendament.
Si tu veux remplacer ton gtk+ "standard" par un optimisé pour framebuffer tu peux.
Sinon demandes aussi la "fusion" de "sed/tar/bash/find/etc" pour faire un gros paquet "ligne de commande Unix".
Ça te gène pas cette tripoté de paquet pour la ligne de commande ?
Puis Mandrake pourrait faire un urpmi avec rpm déjà dedans. Red hat devrait arrêter de séparer librpm de rpm. Tant qu'on y est Red Hat devrait fournir rpm avec librpm, rpmpython, up2date, yum etc... Puis si Mandrake n'utilise pas rpmpython car il utilise perl avec urpmi, ben tant pis eux...
Puis après on pourait faire un gros paquet bien baveux pour gcc avec make, m4, autoconf, automake, gdb, lint, ld, etc dedans.
Désolé, mais je ne veux pas de ça. Ça frise le cauchemard. En tant qu'utilisateur final ça ne m'apporte rien (yum s'occupe de ça très bien) et en tant que développeur : beurk !
Puis à chaque correction de bug ou trou de sécurité s'il faut download 300 Mo toute les semaines, je dis :
- non non non non non non !
[^] # Re: ho sigh, windows...
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 2.
Le but de Gnome n'est pas de s'éloigner de Windows.
Parfois Gnome s'éloigne, parfois il se rapproche mais c'est le hazard.
Idem pour KDE.
Le but est de faire un bon desktop. Qu'il ressemble ou non à Windows est le dernier des soucis des développeurs.
Perso, j'utilise pratiquement jamais Windows ou Mac et lorsque j'ai découvre une nouvelle version de Gnome, je ne la juge pas en terme :
- plus proche de Windows
- moins proche de Windows
Ce critère je m'en fous, comme vous ne pouvez pas l'imaginer...
[^] # Re: Un fork pour un gnome d'expert
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 1.
Sûrement car tu as oublié de sauvegarder la session (par exemple lorsque tu te déconnectes de Gnome).
[^] # Re: ho sigh, windows...
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 1.
Le problème de séparation en plusieurs bibliothèques est un problème de développeurs (maintenance/communication/réutilisation) et pas d'utilisateurs finals (y a apt/yum/etc pour régler ça pour eux).
Il y a (résumé très grossier) :
glib
gdk
pango
gtk+
gnomelib
Tu veux tout ça dans la même lib ? Quel intérêt ?
libxml étant un composant parmis d'autres, KDE peut l'utiliser. glib peut-être utilisé par arts. Je bosse sur un petit projet et j'utilise glib (mais pas gtk+) et libxml. XFCE qui fait un """petit""" bureau utilise """seulement""" gtk+ (je te conseille sérieusement de regarder du côté de XFCE, c'est peut-être le bon bureau pour toi). Tu crois que si glib/gdk/pango/gtk+/libxml/gnomelib/etc était dans la même bibliothèque se serait mieux pour la diversité ? Que l'ensemble des développeurs (pas seulement Gnome) serait content ?
Même si c'est parfois "casse couille", je préfère avoir beaucoup de bibliothèques qu'un truc monolithique.
[^] # Re: Un fork pour un gnome d'expert
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à -1.
Je vais te donner un exemple de ma "sincérité" sur le fait que la lenteur n'est pas critique pour moi.
Néanmoins, je suis comme tout le monde, je constate que lancer gnome-terminal alors qu'il n'est pas en cache, ça prend du temps.
Mais il faut relativer.
J'ai 3 disques dures (hde et hdg : deux très vieux disques) :
/dev/hde : débit hdparm : 8 Mo
/dev/hdg : débit hdparm : 8 Mo
/dev/hda : débit hdparm : 50 Mo
/dev/md0 : raid0 strippé de hde et hdg : débit hdparm : 15 Mo.
Ben j'utilise mon système avec /dev/md0 alors que j'ai une copie identique sur /dev/hda (pour backup ou en cas de "grosse merde" (je peux à tous moment booter dessus)).
Je réserve le gros débit de hda pour mes videos (enregistrement/lecture). Et pourtant si je boote avec /dev/hda c'est nettement plus rapide. Par exemple avec md0 je boote en 48 secondes et avec hda en 32...
[^] # Re: Un fork pour un gnome d'expert
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 0.
> Non.
le "une fois au début et c'est tout" c'est par application.
Sous Gnome, si une autre applie fait une modifcation les autres applis consernées sont informées par Gconf et il n'y a pas relecture (au pire tout est en cache).
> Bref, c'est loin d'etre aussi simpliste qu'on pourrait le penser initialement.
Oui, tout à fait.
Mais c'est pas LE problème des bureaux. Le matin je lance evolution/mozilla/etc... et c'est fini.
Si la lecture de la conf était deux fois plus lente, je le remarquerai même pas...
Le plus gros problème actuellement (tel que je le perçois) c'est que les informations sont "dispersées" un peu partout. Le réveille d'un programme qui dormait dans le swap peut être assez laborieux...
L'exemple typique, c'est le bouton "démarrer" du panel. Si tu n'y touche pas longtemps et fais plein de truc à côté, il faut dans les 3 secondes pour qu'il s'affiche c'est pas un problème de place mémoire ou de temps pour parser les fichiers. C'est le temps de déplacement de la tête de lecture du disque dure pour récupérer toutes les informations dispersées qui pose problème. Là il y a effectivement du travaille à faire. Notes que pour le menu du panel, gconf n'est pas utilisé et que si tout est en cache c'est très rapide (presque instantané).
[^] # Re: Un fork pour un gnome d'expert
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 0.
Tu as raison :-)
Je croyais que c'était 86. Ce qui est un peu bête car apple fesait une pub relative à 1984.
[^] # Re: Un fork pour un gnome d'expert
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à -2.
Il y a 20 ans ?
Et en plus avec le mode spatial ?
Putain, j'ai bousillé toute ma jeunesse.
[^] # Re: ho sigh, windows...
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 0.
gnome-session-properties, vires nautilus, sauves la session.
ou
"killall nautilus", lance un autre vm, puis sauve la session.
> c'est tellement entrelacé qu'au final on est obligé de tout avoir, et à ce moment là autant faire une seule lib mais c'est un avis personnel.
Pssssssss
Gnome-terminal utilise plein de truc, donc il y a plein de dépendances. Voilà, c'est tout. Si tu mets tout dans une librairie, ça change rien (apt sera moins "verbeux" et c'est tout).
Puis si tu veux n'utiliser que glib, libxml et Orbit tu peux. T'es pas obligé d'installer gtk+, gnomelib, bonobo...
En ce sans c'est modulaire. C'est pas modulaire dans le sens :
- les programmes du bureau Gnome doivent utiliser le moins de fonctionnalité Gnome.
Evidemment.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à -1.
Tu as raison :-)
Mais il y a gconf-editor et gconftool.
C'est comme si tu disais que les bases de données sql te gonffre car grep et find retournent n'importe quoi.
[^] # Re: ho sigh, windows...
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 0.
Pas moi. Je veux dire pas dans le projet Gnome. Ça peut-être un projet séparé qui utilise Gnome ou (comme c'est actuellement le cas) un projet de la distribution.
Un "control center" c'est normalement pour les admis pas pour les desktop-user (évidemment, quand il n'y a pas d'admin....).
[^] # Re: PORTNAWAK
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 0.
Je l'ai vu dans KDE 3.2.3.
Ça a même créé une incompréhension car j'ai dit à quelqu'un qu'il y avait le menu "envoyer ce lien" dans le menu "fichier" alors que c'était le menu "document".
Ceci dit, "Fichier" ou "Document" je m'en fous un peu...
[^] # Re: Un fork pour un gnome d'expert
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 1.
N'importe quoi. Tu lances une application toutes les secondes ?
Le configuration est lu une fois au début et c'est tout.
[^] # Re: Un fork pour un gnome d'expert
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à -1.
Y a 20 ans il y avait peut-être apple II en ligne de commande uniquement...
Les premiers mac n'ont jamais été spatial. Ça ne consernait que les dossiers sur le bureau.