Pinaraf a écrit 3682 commentaires

on n'en est qu'aux versions alpha
Perdu, la bêta 2 est sortie cette semaine.

Au passage, autre raison que l'on peut évoquer :
-- je vous l'avais bien dit, .... que des branleurs ces utilisateurs de logiciels libres qui ne veulent pas tester les bêtas et donc on en rajoute pour avoir plus de retours...

PDF pour la norme OpenDocument 1.1, page 316 (paragraphe 9.3.4).
En fait, il est possible d'insérer une applet Java dans un fichier OpenDocument. Une implémentation de 100% de la norme devrait donc dépendre plus ou moins directement (par un plugin de préférence quoi) de Java.

Ha bon ?
Qui développe la norme ? Le comité OASIS...
La version 1.2 est en brouillon actuellement, elle passera devant OASIS sans problème vu que c'est le comité OASIS qui la développe en se basant sur les retours par les différentes implémentations (OpenOffice, KOffice, Google Apps...)

Pour Mac OS X, c'est beaucoup beaucoup de travail. C'est pas un port, c'est plus proche d'une réécriture. Comme, à l'époque, IE sur Mac... C'était un moteur différent (plus proche des standards d'ailleurs)

Et ne dit pas que techniquement c'est difficile à réaliser, etc...
Il y a Firefox, Oracle, OOo, etc pour Windows, Unix, Mac, etc...
Je vais me dévouer, je vais défendre microsoft...
C'est difficile à réaliser.
Prenons un logiciel comme KWord. Le port sur Windows et Mac OS X est ultra facile : une recompilation, à la rigueur une ou deux bidouilles, et ça roule. En plus, c'est automatiquement adapté à la plateforme.
Mais c'est pas facile pour autant. En fait, tout le boulot est fait par Qt (et les kdelibs).
Or, quand microsoft développe Office or SQL server, ils utilisent Qt ou une autre librairie multi plateformes qui "s'intercale" entre l'OS et l'application ? Probablement non, ils utilisent directement l'API windows, les MFC et tout ce qu'ils veulent (ils doivent avoir de quoi en stock...)
Donc réaliser une version OS X ou Linux d'Office, c'est le même combat : beaucoup beaucoup de temps (et donc d'argent) nécessaire. Pour OS X, c'est en cours de réalisation pour la version 2008. Tu vas dire : "pourquoi ils adaptent pas dans la foulée à Linux ?" Ben parce que tout simplement ça demande la réalisation d'une abstraction à la plateforme dans ce cas, et c'est juste pas dans leurs plans.
Pareil pour SQL Server.

Donc non, c'est pas facile à réaliser. Par contre, c'est faisable pour eux, vu leurs moyens, si ils ont simplement la volonté de le faire. Mais ils ne l'ont pas.

T'iras dire ca a KOffice et sa gestion d'ODF
Pas de problème.
Y'a deux mois, il y avait 1 développeur pour KWord. Maintenant on est 3, j'ai passé pas mal de temps pour avoir un meilleur support de l'ODF dans KOffice. Mais c'est clairement un manque de temps. Pour implémenter seul l'OOXML, il faudrait des années. Pour l'ODF ça prend déjà beaucoup de temps, mais bon c'est faisable.
Donc si t'as des points précis qui ne marchent pas, n'hésite pas à rapporter des bugs.

Et dans ton commentaire tu viens de pourrir encore un peu plus la news avec 2 occurences pour le bureau au pied, et 5 pour le bureau au K.
Cf aussi les réponses à ton précédent commentaire (à ta place, je lirais un peu les réponses au lieu de repolluer la news avec plein d'occurences du Vilain (je suppose que tu lui donnes ce genre de surnom))

Sinon de manière générale, d'où vient cette """pollution""" :
- Un lien vers le dot à propos du sondage desktoplinux
- Une discussion sur les cycles de sortie
- Une discussion qui a parlé de Gnome 3.0 et KDE 4.0 (je maintiens l'équilibre)

C'est vachement des fanatiques de KDE qui ont lancé des trolls comme :
Oui mais non. Quand un gars de KDE demande des nouveautés, ça veut dire qu'il faut rajouter au moins une dizaine de boutons, de la transparence dans les menu, une preférence pour régler le degré de la transparence, etc...
Ha oui, mais bien sûr, on est sur une dépêche à propos de gnome, tous les fanatiques de gnome peuvent lancer des trolls mais les défenseurs de l'autre bureau doivent fermer leur gueule ?

Au final, vous avez réussi à pourrir vous même "votre" dépêche.


P.S : ce commentaire à un taux garanti à 50% de gnome et 50% de KDE.

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

Plus exactement, c'est au choix OpenGL ou XRender je crois...

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.

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)

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.

C'est ta machine, sur mon konqueror je vois très bien les captures d'écran.

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.

Et tous les geeks de KDE sont occupés à bosser, alors que les geeks de Gnome ça fait une paire d'année qu'on attend qu'ils bossent plus que 2 heures par version de Gnome...

Houlala tu te fatigues beaucoup toi...
Tu supprimes tes cookies et ça suffit pour revoter.

Citons OSNews (ainsi que de nombreux experts) :
Hence, these reports are not proper measurements of security - they are just that, a tally of fixed vulnerabilities. Any conclusions like "x is more secure than y" cannot be drawn from this data set.
Traduction (à peu près) :
Ainsi, ces rapports ne sont pas des mesures valables de la sécurité - ils comptent simplement les vulnérabilités corrigées. On ne peut pas tirer de ces données une conclusion comme "X est plus sécurisé que Y".


Alors bravo pour le lancer de trolls, mais sache que pour un bon lancer de troll, il ne faut pas mettre de sources (même sans liens).

La gestion de certains trucs graphiques dans le noyau ça peut déjà aider à retourner dans un état potable sans X, puis relancer X derrière sans soucis.
Sinon, pour GLX et XVideo, ça m'étonnerait que ça soit faisable. Il faudrait au minimum faire une sauvegarde de la mémoire vidéo utilisée par un programme, la restaurer de la bonne façon, s'occuper des shaders et de toutes les joyeusetés disponibles... Bref, truc bien lourd.

Ce qui c'est passé avec Novell et Xgl/Compiz, c'est que Novell a décidé d'embaucher le développeur de Xgl et de faire bosser sur un dépôt interne jusqu'à ce que le produit soit présentable, et le présenter avec autant de force marketing que possible.
Novell n'est pas à l'origine de Xgl et Compiz.
Sinon, pour les plantages, y'a des trucs qui rendent ça impossible ou presque :
1- les applis utilisant GLX ou XVideo (ou tout ce qui fait du rendu direct) : à mon avis Xmove marche pas pour ça et marcherait pas pour ça avant un bout de temps...
2- l'absence de gestion des modes de l'écran dans le noyau pour lui permettre de remettre la carte graphique dans un état potable avant de relancer X.

(Le deuxième problème est en cours de résolution, mais ça va prendre un certain temps...)

Les tests de Konqueror et Safari sont incomplets pour l'instant :/

* Upstart (gros morceau ça)
Mouais, il serait temps qu'ils tiennent leurs promesses à ce sujet. Ils avaient promis de réécrire tous les scripts d'init pour profiter pleinement d'upstart, c'est loin d'être le cas.

* Implémentation du sudo par defaut
Est-ce une bonne innovation ? J'en doute fortement. Personnellement ça m'emmerde plus qu'autre chose quand j'administre la kUbuntu "familiale" : je suis obligé de me logger sur mon compte utilisateur puis de faire sudo pour administrer (donc 2 commandes : su + sudo, alors qu'une suffit sur toutes les autres distribs).

Non, je n'ai pas dit qu'il ne me plaisait pas.
J'ai dit :
Et pourquoi ne pas contribuer à qemu ? Parce que son code ne plaît pas, parce que sa structure ne plaît pas, parce que certains choix techniques peuvent être à l'origine de désaccords...

On le refait en version bien diluée pour aider à la compréhension :
Et pour quelles raisons une personne pourrait décider de ne pas contribuer à Qemu ? Parce que le code de Qemu peut ne pas plaire à cette personne, parce que la structure de Qemu peut ne pas plaire à cette personne, parce que certains choix techniques effectués dans Qemu peuvent être à l'origine de désaccords avec d'éventuels contributeurs...

Peut être que sur notre vieux continent on n'a pas l'esprit "Microsoft c'est une entreprise américaine, faut la défendre", on a pas une allergie au communisme (les préjugés Linux = communisme ont la vie dure, je crains que ce ne soit facile de trouver des gens qui y croient et continueront à y croire pendant encore longtemps), on n'a pas eu dans la gueule des belles campagnes Get the facts (je l'ai vue que sur des sites US, pas sur des sites français par exemple)...

C'est pas parce que ton site est compatible Firefox qu'il respecte les standards.
Firefox a, comme tous les navigateurs, un "quirk mode" pour interpréter du code pourri.
De plus, si tu fais un site avec une identification du navigateur pour balancer du code HTML ignoble pour IE ou du XUL pour Firefox, ton site sera pas plus respectueux des standards.

Enfin, un autre "détail" : ce qui compte de plus en plus, c'est le Javascript, et là c'est bien pire que le HTML...

Hum, pas si sûr que ça.
De plus tu sépares comment la fonction test du reste de l'outil ?
Sans oublier que Sax et drakxtools ont déjà la fonction test depuis longtemps.