Il y avait un plug-in pour Koffice à un moment qui faisait cela.
Ca marchait couci-couça mais pour les mises en pages pas trop complexes, ça donnait un résultat satisfaisant.

[ Répondre ]

Lotus Word Pro, dans Smartsuite fait ça depuis environ 10 ans.
Un traitement de texte absolument formidable, ce Word Pro. Bourré d'idées super pratiques qui n'existent toujours pas sous aucun autre traitement de texte libre ou non. Genre les chapitres que l'on met dans des tabs (des sections), que tu réorganises donc en glisser/déplacer avec mise à jour automatique de table des matières et d'index. Que tu peux importer dans d'autres texts indépendamment du reste du document. Les styles appliqué à tout : images, paragraphes, tableaux, cadres.
J'aurai payé pour l'avoir sous Nunux. Si seulement les devs d'outils Linux pouvaient s'inspirer de ce traitement de texte plutôt que de Word....
Ah, si seulement IBM le libérait.... Mais il ne faut pas rêver, j'imagine.

[ Répondre ]

Sans oublier l'effet d'entrainement : plus de sociétés ouvrent leurs specs, plus celles qui ne le font pas feront figures de vilains petits canards.
J'ai des cartes graphiques des deux constructeurs personnellement, mais il est clair qu'à la lumière de cette annonce, je vaid préférer AMD/ATI jusqu'à nouvel ordre.

[ Répondre ]

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.

[ Répondre ]

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.

[ Répondre ]

La qualité de l'échantillon **et** les méthodes d'analyses. Les instituts de sondage appliquent des corrections aux résultats en fonction de paramètres psychologiques évalués dans la durée.
Les deux, échantillon et méthodes, sont totalement absents de ces sondages internet, ce qui les rend totalement inutiles.

[ Répondre ]

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).

[ Répondre ]

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!

[ Répondre ]

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.

[ Répondre ]

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.

[ Répondre ]

Je ne saurais pas dire, ne connaissant pas Pinnacle Studio.
En général, là ou les softs de montage pros se distingue, c'est plus sur les résolutions supportées, sur les garanties de sortie de couleur, sur les possibilités de masques et globalement sur la vitesse et la capacité à gérer de gros projets avec beaucoup, beaucoup de pistes et de rushs.
La différence ne saute pas aux yeux à première vue, mais apparait vite dès que tu montes des films de plusieurs dizaines de minutes avec des centaines de plans.
Je n'ai pas assez utilisé MainActor pour savoir de quel côté il se trouve.

[ Répondre ]

A mon avis, tout n'est pas libérable, à commencer par les codec d'exports qui sont le gagne-pain de MainConcept.
Mais ceux-ci pourraient surement être remplacés par les codec FFMPEG (plus exactement libavcodec/libavformat) qui généralement font plutôt du bon boulot.
Il me semble que dans ses dernières versions, MainActor utilisait Qt, cela permettrait probablement une récupération de tout le code de l'interface assez aisée.
Reste à savoir ce qui est récupérable du framework multimédia utilisé.

[ Répondre ]

Montage linéaire, c'est un montage vidéo en temps réel, donc avec des flux capturé par des caméras que tu montes à la volée. C'est la TV, quoi.
Montage non linéaire, c'est celui que tu fais en ayant des rush, des images, des sons et que tu montes tout cela sur des pistes pour exporter le tout en fichier vidéo.

Concernant la libération du code de MainActor, cela pourrait être une bonne chose. Pour le moment, le seul soft de montage avec les mêmes fonctionnalités (voir meilleures) est Cinerella, mais son interface est vraiment trop mal foutue pour un travail pro. Les autres soft sont assez loin, que ce soit Kino, KDEenlive ou autres. Jahshaka n'est pas du tout dans le même créneau, c'est un logiciel de compositing qui est très prometteur mais trop instable pour le moment.
PErso, un MainActor GPL me plairait bien. Ca ferait une base de travail complète pour des devs afin d'ajouter des fonctionnalités intéressantes. Je serais prêt à donner des sous pour cela.
Et l'intérêt de payer pour celui là plutôt que pour les autres, c'est que cela permettrait d'avoir de facto un soft fini et utilisable et de voir du coup rapidement une communauté de devs se former autour pour l'améliorer, comme cela a fait pour Blender, qui est maintenant loin devant toute alternative libre.

[ Répondre ]

Je ne sais plus, c'était en 2005, la distribe stable de l'époque. Crois-moi ou non, c'est pourtant bien ce qui s'est passé. Le passionné de Debian qui était dans ma boite à l'époque, et qui maintient un des miroirs, avait été un peu vert.
Pour ce qui est de changer de distribution, tant que le principe général de la distribution ne te convient pas, il vaut mieux en changer.
Maintenant, je suis d'accord avec toi : la Slack a quelques soucis de temps en temps, comme toutes les autres, mais je n'en changerai maintenant pour rien au monde.

[ Répondre ]

Ubuntu sort sans KDE. Ca n'a pas l'air de gêner grand monde. Il n'y a pas (plus) Gnome dans la Slack. Bon. Quel est le rapport avec la gestion des packages?

Secondement, certes tu peux compiler des sources sur les autres plateformes mais du coup, tu te retrouves avec certains logiciels gérés par le logiciel de packages, d'autres non, des fichiers de configurations non standards (la plupart des distributions ont des fichiers de conf spécifiques qui ne sont pas pris en compte par les sources), etc.
En général, tu te retrouve assez vite avec un système un peu bordelique, ce qui explique que la plupart des gens attendent des archives correctement packagées pour leur distribution.
Avec la Slack, tu n'as pas ce souci, car de toute façon, Volkerding conserve les méthodes de configuration par défaut des sources, donc les docs des différents projets sont directement applicables, pas besoin de savoir "comment ça se configure sous Debian ou sous Red Hat". En fait, il n'y a strictement rien à faire pour créer un package Slack tout à fait raisonnable que de lancer la compilation des sources, faire une installation avec DESTDIR ou PREFIX, puis lancer le script 'makepkg'.

Enfin, car tu n'a pas l'air de le comprendre, il n'y a pas de gestion automatisée des dépendances sous Slack. Donc, quand tu mets un package à jour, il ne va pas t'en installer d'autres. Et quand tu mets à jour ta Slack, tu peux parfaitement éviter de d'installer un package et si par malchance ton package est remplacé, un simple "updatepkg" avec ton ancien package te ramène à la version que tu apprécies.

En bref, tu contrôles tout, sous la Slack. Evidemment, ça implique des difficultés que tu n'as pas sous les autres distributions, mais aussi une souplesse que tu n'as pas ailleurs non plus. On aime ou on aime pas.

[ Répondre ]

Bon, les autres ont déjà répondu mais j'ai tout de même envie d'insister :

Non, la Slack ne va rien m'obliger du tout. C'est d'ailleurs la caractéristique principale des systèmes ne gérant pas automatiquement les dépendances, s'pas?
Si je me suis mis une version d'un projet, genre PHP, compilée de mes blanches mimines avec mes modifs à moi, et que je mets à jour Apache, cela ne va pas forcer la mise à jour de PHP. Et balancer la nouvelle version de la Slack dessus, en prenant bien soin de ne pas toucher à PHP, va marcher également.
J'ai gardé un version de Glut pendant 3 ou 4 versions de la Slack comme cela, sans jamais la refaire.
Essaye ça avec une Debian, une Red Hat ou une Suse, tu ne pourras que passer par un --nodeps et une fois que tu as commencé à installer des packages de cette manière, la gestion des dépendances devient un peu une farce.

[ Répondre ]

Bon, d'accord, mon exemple était pas terrible.
Ce que je voulais illustrer, c'est que je peux sans souci avoir un transcode 1.1CVS sur une Slack 10.0. Et que mon transcode 1.1CVS compilé sous la Slack 10.0 marchera toujours quand je passerai sous Slack 12.0.
La gestion automatisée des dépendances ne te permet tout simplement pas cette souplesse.

[ Répondre ]

Ben non. Une fois, j'avais tenté d'installer une Debian light, avec uniquement KDE. Et là, pour imprimer, je décide d'installer CUPS. Du coup, apt-get me descend tout Gnome, parce que le petit gaillard qui avait compilé CUPS avait mis comme dépendance gimp-print ou un truc dans le genre. Ce n'est qu'un des nombreux exemples de ce qui m'a toujours gavé avec les gestions de dépendances.

L'intérêt de la Slack, c'est que justement tu n'installes pas tous les softs à la main. Tu as une distribution assez complète et surtout avec la base fondamentale qui te permet de construire ce qui peut te manquer sans souci. En gros, Volkerding t'installe toutes les dépendances les plus courantes, et après tu te débrouilles. Et moi, honnêtement, je ne veux rien d'autre, je trouve toujours que les autres distribes se mettent en travers de ma route.

[ Répondre ]

J'ajouterai à ce que disent les autres que quand tu compiles tes sources, tu n'as pas toujours à mettre à jour les librairies fondamentales.
Il me semble que les systèmes de gestion de dépendance mettent à jour des librairies en fonction de ce qui était présent à la compilation des packages. Il faut donc avoir en général au moins la version de chaque librairie utilisée à la compilation ou plus récente (corrigez-moi si je me trompe). De plus, un système de gestion de packages va t'installer des trucs dont tu pourrais te passer, sous prétexte que le logiciel que tu désires a été compilé avec.
Or, beaucoup de nouvelles versions de projets ne demandent pas spécialement les versions les plus récentes des librairies sous-jacentes. Du coup, tu n'es pas systématiquement obligé de les mettre à jour.
Un exemple : tu installes transcode et tu as une vieille version de libdvdread. Si le transcode a été compilé avec la dernière version de libdvdread, le système de gestion de packages va la mettre à jour, quitte à casser la compatibilité avec d'autres logiciels utilisant cette librairie et déjà installés. Alors que tu peux compiler ton transcode avec ta vieille libdvdread sans souci.
Maintenant, comme disent les autres, il y a des versions minimum à respecter, c'est dans les README et INSTALL. Il est aussi pas toujours inutile de mettre à jour les librairies, évidemment.

Il n'y a donc pas de solutions magiques. Il faut un peu mettre la main à la pâte. Mais avec la Slack, comme toutes les librairies fondamentales sont disponibles, il est rare d'avoir à installer plus de 1 ou 2 dépendances pour n'importe quel projet.

[ Répondre ]

Allez, on décortique, tu sembles avoir besoin de réviser ton anglais, où alors tu as l'analyse sélective :

"GNOME is and always has been a moving target" : non, ce n'est pas une question d'innovation, c'est une question de changements trop réguliers qui empêchent de mettre en place un processus industriel de compilation. C'est ça que cela veut dire. En gros, à chaque nouvelle release, il fallait vérifier tout le processus de compilation et la liste des librairies nécessaires.

"even the "stable" releases usually aren't quite ready yet" : Tiens, tu l'as pas mal évacuée, celle-là. En gros, il y a des problèmes de finition.

"that really does demand a team to keep up on all the changes" : Est-ce si différent de ce que j'ai dit? Est-ce si compliqué de comprendre que l'idée est que Gnome est difficile à maintenir pour une personne seule, alors que KDE l'est moins? Et que c'est cela qui a motivé la décision de Volkerding?

"many of which are not always well documented" : pas facile de maintenir dans ces conditions, hein?

Quant à ton mail plus haut, "configure" ne va pas te chercher les librairies manquantes, il te dit juste lesquelles manquent. Et visiblement, d'après d'autres fils, Gargnome ne marche pas si bien que cela, et résoudre les dépendances dans le bon ordre a l'air d'être assez infernal.
Et quand bien même il fonctionne bien maintenant, cela n'était visiblement pas le cas il y a deux ans. D'autre part, il n'est pas certain que Gargnome puisse te permettre de créer aisément des packages Slack, et si tu dois te le repersonnaliser à chaque nouvelle release de Gnome, cela ne te te facilite pas tellement la tâche et reste un travail important.

Enfin, je ne critique pas Gnome, mais t'as l'air trop bouché à l'émeri pour le comprendre.

[ Répondre ]