Logiciel : GNOME fête ses dix ans de logiciel libre
Posté par j (page perso, ). Modéré le 25 août 2007.
Les semaines prochaines vont être l'occasion de quelques surprises pour fêter l'évènement via la mise en ligne de nouveaux sites web concernant GNOME ainsi que la sortie en septembre de GNOME 2.20.
En guise de cadeau supplémentaire, DesktopLinux.com vient de publier les résultats de son sondage annuel (38500 votants cette année) et GNOME est en tête de liste des environnements graphiques plébiscités par les utilisateurs participants.
![[en]](../images/en.png)
GNOME (766 hits)-
GNOME Community Celebrates 10 Years of Software Freedom... (416 hits)
-
Message du 15 août 1997 (393 hits)
-
GNOME 2.20 sur le plan de route (1013 hits)
![[fr]](../images/fr.png)
GNOME Fr (1585 hits)-
DesktopLinux.com (1044 hits)
> Lire la dépêche (141 commentaires, moyenne: 3,7).
Vous avez demandé le commentaire #861152.
Run by 
Cette page a été générée par Templeet en 0.1842s (dont 0.0162 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cycle de release
Ce qui me gene dans Gnome, c'est son cycle de release : tous les 6 mois. Ca donne l'impression qu'on a vraiment jamais une version pleinement opérationnelle. Pourtant j'aime bien gnome, mais on se demande parfois pourquoi ils n'ont pas mis les nouveautés dans le version N et ne les ont ajoutées que dans la version N+1...
Je comprends qu'au début des développements cette démarche pouvait se comprendre, pour maintenir éveillée la communauté tant des utilisateurs que des dévs, mais est ce que c'est encore justifié aujourd'hui ?
[^]Re: Cycle de release
Oui je pense qu'un cycle de release fixe est une bonne chose (et 6 mois me semble pas mal pour pas attendre les nouveautés trop longtemps).
Sinon, on serait toujours en train d'attendre qu'un des softs ait fini de coder une fonctionnalité et ca ne sortirait jamais. La on sait à quoi s'attendre et tout le monde si adapate, si un dev ne pense pas pouvoir finir quelque chose à temps pour la prochaine release, il sait qu'il doit viser celle d'après et planifie son travail en consequence.
Et puis savoir qu'on n'a plus qu'un mois pour finir un truc ca motive pour s'y remettre si on n'avançait plus trop :)
[^]Re: Cycle de release
Et puis savoir qu'on n'a plus qu'un mois pour finir un truc ca motive pour s'y remettre si on n'avançait plus trop :)
C'est marrant, ça ressemble au reproche qui est fait aux logiciels priprios de sortir non pas quand c'est prêt mais en fonction d'une date...
[^]Re: Cycle de release
Tu ne parles quand-même pas de Windows Vista, là par exemple ?
[^]Re: Cycle de release
Il y a trois manières de sortir un software :
a) en fonction d'une date
b) en fonction d'une liste de fonctionnalités/corrections définies (généralement sur un bts)
c) quand le responsable estime que c'est prêt.
Pour un projet jeune, c) est généralement utilisé. Cependant, il doit très vite être abandonné car on n'estime jamais que c'est réellement prêt une fois que le programme a de l'envergure. On est toujours déçu, on veut un peu fignoler, on repousse. Et le soft ne sort jamais ou sort trop tard. L'attente s'essoufle : le soft ne peut que décevoir. Exemple : E17, Dotclear 2, (j'ajouterais même KDE4)
La méthode b) semble parfaite si ce n'est que, bien souvent, des fonctionnalités à priori simple se révèlent plus complexe, il faut tout réécrire, etc. Y'a également une forte tendance du responsable à ajouter des nouveaux bugs/fonctionnalités en cours de route. En pratique, b) se ramène donc souvent à c)
Ce qu'on repproche souvent aux logiciels proprios (comme Vista), c'est d'annoncer une date alors qu'ils suivent la méthode b). Du coup, les dates ne sont bien entendu jamais tenue et les fonctionnalités à moitié abandonnées, pas finies. Le pire des deux mondes. Exemple : Vista.
En pratique, b) et c) sont des méthodes pour les programmeurs. Pour eux c'est important que la version X possède tel truc.
La méthode a) elle, est centrée sur l'utilisateur. L'utilisateur veut avoir des améliorations régulières et des corrections. Que la super fonctionnalité qui n'est pas dans la 0.1 soit dans la 0.2 sortie 16 mois après ou quelle soit dans la 0.4 sortie 18 mois après, ça ne change rien. Sauf que les petites améliorations des 0.2 et 0.3 auront apporté des petits avantages, auront permis une migration progressive.
L'informatique pour les utilisateurs, ce n'est plus une grosse mise à jour/migration "quand c'est prêt" ! Ce sont des mises à jour régulières, progressives, qui améliorent le système par petite touche plutôt que de tout changer à chaque fois, solutionnant des problèmes mais surtout en apportant des nouveaux.
Le cycle de release par date est le cycle qui se concentre sur réellement l'utilisateur. Dans l'informatique moderne à destination du grand public, j'estime qu'un gros projet ne peut plus se concevoir sans une approche de release par date.
Le cycle de release par date est également un outil merveilleux pour la coopération entre projets (exemple : Ubuntu et Gnome) ainsi que pour l'utilisation professionnelle (migrations et mises à jour parfaitement planifiables et quantifiables en terme de coût).
Il avait un moment été question de passer le dev d'OpenOffice sous cette formule : http://ploum.frimouvy.org/?95-ploumterview-n2-slowness-of-op(...)
e suis déçu de ne plus en entendre parler.
[^]Re: Cycle de release
Je confirme par un exemple.
J'ai été dév chez SourceMage pendant deux ans (2004-2006). A mon arrivée la version 1.0 était imminente : il fallait juste que le nombre de bugs critiques soit inférieurs à 50 (je crois) et que quelques fonctionnalités soient terminées (solution c) donc). Une question de semaines.
Mais en fait cela faisait déjà deux ans que la version 1.0 était imminente. Alors on a sorti la 0.9.3, 0.9.4, 0.9.5, 0.9.6 et puis finalement le nombre de bugs continuait à augmenter (faute de dévs), on rajoutait des features sur la liste... Deux ans plus tard quand je suis parti elle n'était toujours pas sortie (ça faisait donc 4 ans !)
D'un point de vue utilisateur, je pense que ça pénalise le projet, car on a toujours l'impression qu'il s'agit d'une distro qui ne sort que des ISO de développement. Ca en rebute plus d'un à mon avis.
Et pourtant, pas mal de gens l'utilisaient tous les jours sans souci, c'était relativement stable ! Aujourd'hui je crois que l'idée d'une 1.0 a fini par être abandonnée, car finalement, il était considérée que la 1.0 devait être "parfaite". Si d'autres distros en avait fait autant, on aurait jamais eu de Mandriva 10.0 par exemple (pas taper !!!).
Donc moi aussi je vote pour le cycle de release par date. Et comme l'a dit quelqu'un plus haut, ça peut motiver pour bosser plus rapidement.
[^]Re: Cycle de release
D'ailleurs, on l'a pas eu la Mandriva 10.0, puisque c'était encore une Mandrake ;)
xmpp:ofaurax@jabber.fr
[^]Re: Cycle de release
C'est pas faux. ^^
[^]Re: Cycle de release
C'est Mandrake, que t'as pas compris ?
La seule chose qui arrive à la cheville de Chuck Norris... c'est sa chaussette.
[+] [^]Re: Cycle de release
Tu es démasqué Perceval!
ebaobab.net - Partagez avec vos amis tout en conservant votre vie privée !
[^]Re: Cycle de release
Le truc c'est qu'en logiciel proprio, ça sortira même si c'est pas prêt. Là la seule conséquence, c'est que la nouvelle version sortira 6 mois plus tard... Bon, hum, des fois ça sort aussi même si c'est pas prêt, hein...
[^]Re: Cycle de release
Le mieux, quand même, ça reste les boîtes qui publient leurs correctifs de sécurité à date fixe ! :-)
[+] [^]Re: Cycle de release
C'est pour ne pas perturber la grand-mère du développeur ;o)
"I wonder where I'll go now. The net is vast and infinite."
[^]Re: Cycle de release
Gnome a adopté une démarche progressiste. Si une feature n'arrive pas à être intégrée dans l'interval, elle est retardée pour la version suivante. C'est comme un développement normal, sauf que les utilisateurs peuvent obtenir les progrès obtenus entre temps dans une version stable, plutôt que de faire des semi-révolutions en changeant toutes les API du software en un seul trait, comme KDE4.
C'est aussi la démarche du noyau linux. De nouvelles versions sortent régulièrement avec des changements importants et selon Linus Torvalds il n'y a pas de raison de préparer un Linux 3.0 en chantier.
[^]Re: Cycle de release
Sauf qu'un grand changement peut être inévitable.
Pour KDE 4 il l'est : améliorations importantes de l'API, suppression de tout ce qui était devenu inutile au fil du temps (arts par exemple)... Alors certes, c'est un grand changement d'un coup, certes ça prend du temps, mais des changements incrémentaux ne peuvent pas marcher tout le temps si tu as dans tes objectifs la compatibilité d'API et d'ABI.
[^]Re: Cycle de release
Solid, plasma, kross, le développement des widgets oxygen, phonon, strigi et tout un tas d'autres trucs, ils n'étaient pas obligés de le faire tout en même temps.
Ils auraient pu commencer par ne faire que porter les API de KDE à QT4. Puis implémenter plasma et toute la clique de façon incrémentale.
Je dis pas que la façon de faire de Gnome est forcément la mieux et la plus parfaite, juste que c'est loin d'être un passage obligatoire de tout réécrire d'un bloc.
[^]Re: Cycle de release
C'est pas non plus comme si le développement de KDE4 avait arrêté celui de la branche 3.
[^]Re: Cycle de release
Justement, on a des dev qui travaillent sur la branche 3, d'autres sur la 4. Finalement la 4 est retardée indéfiniment, rien ne presse, on a la 3. Puis quand la 4 sort, les utilisateurs veulent pas migrer, on doit continuer à faire des backports pour la 3, tel programme ne fonctionne que pour la version 3, tel autre que pour la version 4.
Bon, en même temps la majorité ne sont pas payés donc ils font ce qu'ils veulent, c'est leur choix.
[^]Re: Cycle de release
les utilisateurs veulent pas migrer, on doit continuer à faire des backports pour la 3
pourquoi "on doit" ? et qui ça, "on" ? qui sont ces "utilisateurs" ?
en général les utilisateurs sont les distributions, ce sont elles qui décident quelle version elles vont livrer avec leur bazar. c'est rarement les utilisateurs des distributions qui vont choisir d'autres versions en les recompilant sans aucune assistance (Gentoo et compagnie c'est toujours la distribution qui fait le sale boulot)
alors oui ils migrent mais ils ont un cycle assez lent, et en plus ils sont une douzaine et pas synchro entre eux \o/
Bon, en même temps la majorité ne sont pas payés donc ils font ce qu'ils veulent, c'est leur choix.
tu veux sans doute dire que les employés payés, eux, ont un manager ou autre décideur pressé qui vient les remettre dans le droit chemin, enfin, leur piétiner l'aorte pour qu'ils se concentrent sur la toute toute toute dernière dernière version même pas encore en alpha mais déjà annoncée partout sur la planète. ouais mais c'est un raccourci trop rapide
et puis il y a des softs commerciaux utilisant KDE 3 (ou plutot les KDElibs associées) et dont les développeurs (enfin, les vendeurs, le support) ont tout intêret à aider à réparer et maintenir ces librairies de KDE 3 - même des branches sans avenir à moyen terme - plutot que patcher leur produits comme des porcs en testant les numéros de versions de KDE pour contourner des erreurs
Windows has no users. It has hostages.
[^]Re: Cycle de release
Gné ?
Le tout début de KDE4 a été le portage vers Qt4 des libs de base, ce qui n'a mobilisé qu'une partie des développeurs. Les autres n'allaient pas porter les applis sur des libs pas finies. Donc ça n'a pas eu d'impact.
Où as-tu vu que KDE4 est retardé indéfiniment ? Le planning n'a pas été fixé au début parce que ça n'aurait eu aucun sens ; puisque la 'vision' n'était pas bien définie. Chaque équipe a commencé à développer son projet, puis quand la vue d'ensemble a émergé, là un planning a été possible : http://dot.kde.org/1174481326/
Il y a déjà eu 2 alpha et la beta 1 est sortie le 6 août. Tu devrais suivre le planet...
o_0 Il n'a jamais été prévu de faire des backports dans la branche 3. Si des utilisateurs ne veulent pas migrer, c'est eux que ça regarde. Je ne vois pas pourquoi il faudrait faire des backports... Si KDE3 leur convenait, pourquoi ne leur conviendrait-il plus ?
Après pour le problème de compatibilité, le changement de version majeur chez KDE indique une incompatibilité binaire, donc c'est un peu normal... Tous les programmes Gnome 1 marchent sous Gnome 2 ?
[^]Re: Cycle de release
Solid, plasma, kross, le développement des widgets oxygen, phonon, strigi et tout un tas d'autres trucs, ils n'étaient pas obligés de le faire tout en même temps.
Ils auraient pu commencer par ne faire que porter les API de KDE à QT4. Puis implémenter plasma et toute la clique de façon incrémentale.
Non. Parce que en portant l'API uniquement, ils auraient gardé des choses inutiles genre arts, et lors de l'introduction de phonon par exemple ils se seraient retrouvés avec un "conflit" entre phonon et arts.
Pour oxygen, ça a été fait principalement par des artistes, et le thème ne commence à être développé que maintenant en fait.
Pour solid par contre, c'était pas indispensable certes, mais autant en profiter vu que ça va aider des applications diverses et réduire l'effort de portage pour les applis (certaines disparaissant purement d'ailleurs).
Pour strigi, c'est pas une nouveauté de KDE4, c'est plutôt nepomuk la nouveauté. Bon, là par contre je suis d'accord, lui il irait bien dans KDE 4.1 de mon point de vue, mais c'est trop tard.
Pour kross, même problème : laisser les gens utiliser directement KJS dans KDE4.0 puis les faire passer à Kross après au petit bonheur la chance ?
On parle plus de fonctionnalités là, on parle d'API. Ça n'a rien à voir au niveau des contraintes.
[+] [^]Re: Cycle de release
Ce qui est bien c'est que si arts était devenu inutile au cours du temps, phonon lui ne l'est pas du tout hein !
/o\
[^]Re: Cycle de release
Phonon est utile. Parce que gstreamer ne garantit en rien la compatibilité d'API et la compatibilité binaire. De plus, les librairies de KDE4 ont vocation à fonctionner sur des plateformes où gstreamer est inutile (Windows => DirectSound je crois ; OS X => Quicktime).
Les mecs de KDE en ont assez chié à cause du choix d'arts, ils ont décidé de plus reprendre ce risque.
(Pareil pour xine par exemple)
[+] [^]Re: Cycle de release
Mais sous Linux, on avait déjà Gstreamer...
Qu'est-ce qui peut garantir les compatibilité API et binaire ? Tout refaire soi-même, c'est ça ? Gstreamer est utilisé par Gnome mais il n'est pas non plus spécifique que je sache.
[^]Re: Cycle de release
Tout le monde n'utilise pas Gstreamer pour le moment et cela n'est pas portable sous Win ou MacOS. L'un des avantages de QT4 est qu'il existe en GPL sous Win et que donc, il va être possible de porter les librairies et les applis KDE sous cette plateforme, comme sur Mac.
Phonon permet alors aux applis multimédia KDE de fonctionner de façon transparente sur ces plateformes, car il sert de couche d'abstraction entre elles et le framework multimédia de la plateforme (comme on l'a dit au dessus, DirectX sous Win et Quicktime sous Mac). On pourra donc avoir Amarok sous Win, sous Mac ou sous Nunux avec Gstreamer ou xine, selon ce que tu préfères.
Et sans que cela demande quoi que ce soit aux développeurs de l'appli.
Si ça c'est pas top moumoutte.......
Bon ceci étant dit, je vois pas trop l'intérêt de ramener tout cela sur une news Gnome.
[^]Re: Cycle de release
Et cela dit aussi, bon anniversaire à Gnome.
Je n'aime pas, je n'utilise pas, mais c'est du logiciel libre, nom d'un caniche!
Ca a droit à mon respect!
[^]Re: Cycle de release
Ah ? Je pensais, en lisant Pinaraf, que KDE4 allait (devait) s'adapter à ce qu'offrait le système d'exploitation visé :
- DirectSound pour Windows ;
- Quicktime pour Mac OS ;
- et donc GStreamer pour Linux.
Si Phonon est encore une couche d'abstraction au-dessus de cette mêlée, ça explique tout. J'imagine qu'il en aurait été autrement si GStreamer était porté sous Windows et/ou Mac OS.
Il est amusant de constater que les projets cherchant à être très portables ont tous tendance à avoir des cycles de versions très long.
[^]Re: Cycle de release
Non, car GStreamer ne permet pas d'implémenter toutes les fonctionnalités de Phonon. Par exemple GStreamer ne comprend pas de couche réseau comme NMM (http://www.networkmultimedia.org/).
[^]Re: Cycle de release
2 choses :
1) le lien est en 404
2) gstreamer posséde des éléments comme udpsink et udpsrc ( et en tcp aussi ), ce qui permet une certaine transparence réseau.
Et il suffit de voir ce qui est possible de faire avec flumotion pour voir que la transparence réseau n'est pas interdite par gstreamer, au contraire.
[^]Re: Cycle de release
1) http://www.networkmultimedia.org/
[ Répondre ] Ce commentaire est-il impertinent ou utile ?
[^]Re: Cycle de release
Arf, merde, c'etait pourtant simple à voir :/
[^]Re: Cycle de release
Oui, Phonon c'est en gros
- Une couche d'abstraction pour différent backend multimédia et leurs différents effets
- Une UI (des boites de dialogue) pour choisir sa carte son, contrôler le volume, ....
Le tout en utilisant les guidelines de KDE (tant au niveau API que UI)
Donc ce n'est pas la même chose que gstreamer.
:-D !!!NOUVEAU!!!
[+] [^]Re: Cycle de release
Mon dieu ! KDE aurait des guidelines au niveau UI ? Ah mais bien sûr, suis-je bête : "Tout espace vide est une occasion rêvée pour ajouter un boutton".
[^]Re: Cycle de release
Ca devient pénible...
[^]Re: Cycle de release
C'est mieux que "Tout bouton est une occasion rêvée pour mettre un espace vide"...
[ Répondre ] Ce commentaire est-il impertinent ou utile ?
[^]Re: Cycle de release
Je ne vois pas pourquoi le message parent est en négatif, il montre une incompréhension mais n'est pas inutilement péjoratif comme ceux de ploum concernant l'UI de KDE. Enfin bref...
Pour te répondre, oui Phonon est une couche d'abstraction au dessus des framework multimedia. Sous Linux, il permet d'utiliser xine, Gstreamer ou prochainement NMM, voir jack comme serveur multimedia, ce qui permet donc à chacun de choisir celui qui lui convient. Et permet une portabilité plus aisée sur les autres plateformes car la "seule chose à faire" est d'écrire l'interface entre Phonon et le framework usuel de la plateforme. Pour l'appli, c'est en gros transparent (je dis en gros car je suppose que selon la plateforme, il y aura des fonctionnalités plus ou moins bien supportées qui doivent être désactivées quand elles ne sont pas dispos).
[^]Re: Cycle de release
Tout le monde n'utilise pas Gstreamer pour le moment et cela n'est pas portable sous Win ou MacOS. L'un des avantages de QT4 est qu'il existe en GPL sous Win et que donc, il va être possible de porter les librairies et les applis KDE sous cette plateforme, comme sur Mac.
Je sais que ce n'est de toute façon pas la vraie raison pour laquelle KDE n'adopte pas directement Gstreamer mais, il est en cours de portage pour mac et windows.
http://blogs.gnome.org/uraeus/2007/05/30/growing-fast/
Thanks to our collaboration with the guys at Songbird, GStreamer is today fully functional for playback also on Windows and MacOSX. It feels great to finally be able to say that GStreamer is not only portable in theory, but it is actually ported. The number of people testing and providing feedback on Windows and Mac is also very good, and due to our agreement with the Songbird developers we can promise even more goodies to come in the future.
[^]Re: Cycle de release
C'était pas le cas quand la décision de créer Phonon a été prise, c'est ça qui est important.
Et comme je l'ai dit, tout le monde n'utilise pas Gstreamer, j'utilise xine personnellement, et beaucoup de monde utilise Mplayer ou VLC qui ne l'utilisent pas non plus.
Pour finir, le plugin xine pour Phonon a été crée en une semaine par un gars tout seul, alors que celui pour Gstreamer semble encore douteux. A croire que créer des applis qui utilisent Gstreamer n'est pas encore aussi simple que pour xine, soit parce que l'API est changeante, soit parce qu'elle est beaucoup plus complexe.
Il n'est donc pas du tout étonnant que les devs de KDE se soient orientés vers une couche d'abstraction de ce type, plutôt que de parier il y a un an sur Gstreamer partout.
Il est tout à fait possible qu'à terme, Gstreamer soit LA solution, mais au moment où les décisions ont été prises pour l'infrastructure de KDE4 et même maintenant, ce n'est pas un environnement qui s'impose de façon évidente par rapport aux autres.
[^]Re: Cycle de release
C'est un peu normal que l'API de Gstreamer soit plus complexe que celle de Xine, Gstreamer n'est pas qu'un moteur de lecture, c'est aussi un moteur d'encodage, et bien plus. Par exemple, on n'a pas d'appli de montage vidéo basé sur Xine ou Mplayer, alors que pour Gstreamer, on a Pitivi. C'est sûr que Pitivi est très loin d'être fini, mais ça montre les possibilités de Gstreamer.
La seule chose qui arrive à la cheville de Chuck Norris... c'est sa chaussette.
[^]Re: Cycle de release
Oh la belle excuse toute pourrie... Ce n'est pas parce qu'on propose plus que ce qu'on fourni doit être plus complexe.
Pour des choses simples, une API simple.
Pour des choses plus complexes, un API "étendue", et voila.
C'est une excuse de mauvais programmeur.
[^]Re: Cycle de release
Comme c'est la facon de concevoir les API Win32 (couteau suisse donc complexe) on en deduit que les defendeurs de Win32 sont des mauvais programmeurs .
Bravo pour ce message !
[^]Re: Cycle de release
Faudrait lire l'API Microsoft avant de dire des bêtises.
Chez Microsoft, en général c'est :
- NonDeLaFonction pour les trucs de base (avec des paramètres à NULL ou 0 pour les trucs que tu ne te sers pas vont très bien)
- NomDeLaFonctionEx pour les trucs complexes (callbacks etc...) (c'est du C, donc pas de surcharge possible)
Toujours aussi lourd les gens qui crachent sur une entreprise en prenant les a priori entendus à droit à gauche.
[^]Re: Cycle de release
Pourtant, il y a beaucoup plus d'application basé sur gstreamer que sur xine.
Et je pense que de nombreux éléments font penchés la balance en faveur de gstreamer :
Il y a des éléments haut niveau de gstreamer qui permettent de faire facilement un lecteur multimedia ( genre, decodebin ), et une architecture bien pensé ( ie, des composants qu'on enchaine )
Il y a des bindings en python, en perl, en ruby et en mono ( alors que xine n'a que python, je pense, et ça me semble pas trés maintenu ). Ça permet d'avoir le choix du language, et cela réduit d'autant la courbe d'apprentissage.
Et il y a une documentation assez exhaustive, comme http://gstreamer.freedesktop.org/documentation/ ou http://pygstdocs.berlios.de/, et des tutorials comme http://www.jonobacon.org/?p=750 et http://www.jonobacon.org/?p=810
[^]Re: Cycle de release
pour le 2ème lien c'est [http://pygstdocs.berlios.de/] (l'habitude d'ajouter des crochets est pratique pour éviter les soucis de parenthèse et de ponctuation, mais bon même certains relectomodérateur l'oublient aussi comme quoi tout le monde se fait prendre).
[^]Re: Cycle de release
Au passage, arts et phonon c'est pas du tout la même chose.
Arts est un serveur de son. Phonon est un framework multimedia.
[^]Re: Cycle de release
À propos de arts par exemple, sous gnome l'équivalent, c'est esound. Petit à petit gnome a fait des progrès au point de ne plus être vraiment dépendant de ce bousin et Fedora 8 va sortir en employant PulseAudio à la place.
http://fedoraproject.org/wiki/Releases/FeaturePulseaudio
https://www.redhat.com/archives/fedora-devel-list/2007-Augus(...)
Ca pourrait même casser la compatibilité avec flash.
On a pas eu besoin d'un Gnome 3.0 pour faire ce genre de progrès incrémental.
Que se serait-il produit si Phonon n'avait commencé à être développé que pour KDE4.1 ou 4.2 ? on aurait conservé le support pour arts pendant quelques versions mineures, puis quand les développeurs se seraient mis d'accord et auraient porté leurs apps, mettre arts en deprecated. Pareil pour Kross et tout le reste.
[^]Re: Cycle de release
Dans ce cas arts serait "deprecated" mais les developpeurs seront quand même obligé de le supporter pendant toute la durée de vie de KDE4.
[^]Re: Cycle de release
Je voulais aussi ajouter que arts est l'équivalent de esound+gstreamer.
[^]Re: Cycle de release
Il ne t'es pas venu à l'esprit que le passage à QT4 demandait de toute façon une réécriture des applis et que tant qu'à faire, il pouvait être intéressant de remettre tout à plat pour simplifier les choses?
En l'occurence, un truc comme Phonon rend la création d'applis multimédia plus simple. Et il en est ainsi pour toute l'infrastructure qui est mise en place pour KDE4. Quitte à porter les applis vers de nouvelles API, autant que celles-ci soient le plus définitive possible. Par ailleurs, le projet KDE est ainsi fait que les applis faites pour KDE 3.0 sont censées continuer à tourner sous KDE 3.5.7. Il en sera de même pour KDE 4.X, il falait donc que toute l'infra soit là, car après elle ne changera pas jusqu'à KDE5.
Parfois ce genre de remise à plat peut être très bénéfique sur le moyen et long terme. Ce qui est fait actuellement sur KDE 4.0 est très prometteur.
Si un jour GEGLE (si c'est bien comme cela que cela s'écrit) remplace GTK avec toutes les améliorations qu'il est censé apporter, alors Gnome devra en passer par là aussi. La seule raison qui permet à Gnome d'évoluer de façon incrémentielle, c'est surtout que sa librairie fondamentale n'évolue pas de façon radicale.
[+] [^]Re: Cycle de release
"Quitte à porter les applis vers de nouvelles API, autant que celles-ci soient le plus définitive possible."
En fait, c'est ça l'erreur de perception des projets qui ne sont pas basé sur des time-release. Ils sont persuadé de faire, cette fois, un truc définitif, un truc qui correspond aux besoins et voilà.
Seulement l'histoire a montré que tout évolue, que tout change tout le temps, qu'il faut s'adapter et que la majorité des trucs qui perdurent réellement n'était pas fait pour durer au départ.
À partir d'un certain de degré de maturité, un projet doit acquérir cette vision et c'est exactement ce que Linux et Gnome ont fait.
[^]Re: Cycle de release
Grossière erreur, en effet, l'API et l'ABI de KDE 3.0 ont seulement été conservées 5 ans. C'est si court. Une demi-vie de gnome, seulement.
[ Répondre ] Ce commentaire est-il impertinent ou utile ?
[^]Re: Cycle de release
Le noyau Linux sait pertinemment l'importance de conserver des interfaces stables sur la durée, pour ne pas casser la compatibilité avec les applis.
Gnome, comme KDE, aura besoin à un moment ou à un autre de mettre à jour tout son fonctionnement fondamental ne serait-ce que pour garder le même niveau de fonctionnalités.
Et ce n'est pas qu'une question de cosmétiques, c'est une question d'intégration. Les fonctionnalités apportées par le cadre de KDE4 seront accessibles à toutes les applications, ce qui veut dire que je pourrai utiliser une recherche utilisant Strigi à partir de KOffice ou d'Amarok, pour utiliser des les méta-données du fichier aussi bien que son nom. Je pourrai faire des recherches sur des accès SSH ou SMB sans montage à partir de n'importe quelle applis, pas seulement le gestionnaire de fichiers. Le carnet d'adresses sera accessibles de toutes les applis, etc.
Si Gnome veut pouvoir fournir un degré d'intégration proche, il devra à terme suivre le chemin de la refonte fondamentale.
[^]Re: Cycle de release
Oui, tout évolue, KDE aussi. Entre la 3.0.0 et la 3.5.7, il y en a eu du boulot... (KDE3 est à peine plus agé que Gnome2)
[^]Re: Cycle de release
Quitte à porter les applis vers de nouvelles API, autant que celles-ci soient le plus définitive possible. Par ailleurs, le projet KDE est ainsi fait que les applis faites pour KDE 3.0 sont censées continuer à tourner sous KDE 3.5.7. Il en sera de même pour KDE 4.X, il falait donc que toute l'infra soit là, car après elle ne changera pas jusqu'à KDE5.
Ca me rappelle le développement du noyau linux avant la sortie du 2.6. Il n'existe pas d'API parfaite. C'est dommage pour vous d'avoir un développement complètement figé dès qu'on sort une version à nombre majeur.
Quant à GEGL ça n'a rien à voir avec un remplacement de GTK. C'est une lib de traitement d'image qui permettrait entre autres de dépoussiérer les limitations de The GIMP.
Il n'y a pas d'évolution radicale de GTK car il n'y a pas de besoin qui se présente et n'oubliez pas que GTK n'est que la boite à widgets. QT est un ensemble "toute la maison, cuisine comprise". L'équivalent de QT pour gnome, c'est GTK+Glib+Pango+Cairo+LibXML.
[^]Re: Cycle de release
Mmmm en même temps, KDE4 constitue une véritable rupture avec KDE3, avant tout parce que Qt4 n'est pas qu'une simple évolution de Qt3. Je peux comprendre que, ayant dû remettre en chantier l'adoption d'un nouveau Qt très différent par KDE, les "ptits gars" se soient dit qu'il serait plus judicieux de repenser l'architecture à la même occasion.
Et puis comme le disait un autre intervenant, KDE3 a évolué (certes, assez peu) entre temps.
En bref, Qt4 et KDE4 sont assez atypiques dans l'évolution des versions majeures, je serais assez surpris qu'il en soit de même pour Qt5 ou KDE5.
[^]Re: Cycle de release
J'ai l'impression en tout cas que la branche Qt4 va évoluer plus longtemps que Qt3. Pour preuve, on en est déjà à la 4.3 et la 4.4 se profile alors que la branche 3 s'est arrêté à la 3.3.8...
[^]Re: Cycle de release
Un truc intéressant c'est que Qt4 est séparé en modules : QtCore, QtGui, QtNetwork, QtXml, QtSql...
Ça permet d'augmenter le nombre de fonctionnalités de Qt sans augmenter la consommation mémoire ou la taille des librairies nécessaires pour des applications qui n'en ont pas besoin. Par exemple QtScript est dans sa propre librairie, dans Qt 4.4 on verra QtWebkit...
[^]Re: Cycle de release
Le développement n'est pas "complètement figé" dès qu'une version majeure sort. Des ajouts sont toujours possibles dans l'API (et il y en a eu de nombreux dans la branche 3.x). Seulement il n'est plus possible de supprimer ou modifier des fonctions de l'API de base.
C'est une contrainte forte, mais je trouve quand même intéressant qu'un logiciel développé pour la X.0 ait l'assurance de continuer à fonctionner jusqu'à la dernière évolution de la branche X ; même si le développement est abandonné. Ça lui donne plus de 'chances' d'être utilisé et repris.
[^]Re: Cycle de release
"Ils auraient pu commencer par ne faire que porter les API de KDE à QT4. Puis implémenter plasma et toute la clique de façon incrémentale."
C'est un peu ce qui se passe, les API et ABI de Plasma se sont pas encore figées, c'est seulement à partir de KDE 4.1 de les API/ABI de Plasma auront une compatibilité ascendante.
Il me semble aussi que le portage KDE-PIM/Akonadi vers KDE 4 ne sera pas prêt pour KDE 4.0.
[^]Re: Cycle de release
KDE est environnement de bureau qui vise la meilleure intégration possible. Si c'est pour se retrouver avec la moitié des applis qui ont été portées pour phonon et solid et l'autre moitié non, ça ne fait pas très propre...
D'autre part, la compatibilité binaire doit être assurée pour toute la durée de KDE4 (comme ça a été le cas pour les 2.x et 3.x). Une appli 3.0 fonctionne toujours avec le dernier 3.5.7... Donc passer à la 4.0 en gardant arts (par exemple) ne permet plus de le virer après...
KDE combine des évolutions 'douces' dans une branche (la 3.x aura duré plus de 5,5 ans quand même ; à peu près autant que Gnome 2.0) et des évolutions plus 'brutales' afin de permettre des sauts évolutifs plus importants.
[^]Re: Cycle de release
pense à Sarge...
ebaobab.net - Partagez avec vos amis tout en conservant votre vie privée !