Laurent J a écrit 2948 commentaires

euh... moi j'appelle ça un succès dans la mesure où elle a volé, ce qui n'était pas le cas de leur précédent essai, et elle a volé pendant un temps non négligeable. Et ils ont récupéré l'essentiel selon moi, la capsule où est censé se trouver plus tard un gars (bon ok, elle est peut être descendu un peu vite :-)).

Sans compter que ce n’était pas forcément les conditions idéales pour un lancement (avec une plateforme qui bouge autant...)

Pour un budget de 37000$, moi je dis bravo. Ce serait la NASA, avoir un tel résultat avec les moyens qu'ils ont, ce serait navrant, voir comique, mais là tout de même...

Et puis appeler ça de la propagande... Regarde dans le dico la définition exacte de ce mot... C'est pas une organisation gouvernementale, mais une simple association de quelques personnes.

parce que GTK == Gnome ?

Il y aura une supère intégration avec QT quand des développeurs connaissant QT voudront bien aider... Mozilla Corp a beau avoir plusieurs dizaines de dev à temps plein, il n'en reste pas moins que les journées ne font que 24h, et qu'il y a des choses tout aussi importantes, voir plus, à faire que le support de QT.

En attendant, il y a un support minimal de QT fait (et maintenu?) par Nokia. Et tu peux essayer de voir ce que ça donne dans kde en compilant avec le flag qt.

Tout est déjà expliqué dans les commentaires :
- https://linuxfr.org/nodes/86050/comments/1234118
- https://linuxfr.org/nodes/86050/comments/1234361

Bluegriffon n'est basé sur aucun des logiciels que tu sites (ni nvu, ni Mozilla Composer, ni Netscape Composer, ni Kompozer)

C'était sûrement propre au début. Mais à force de faire évoluer le soft, en rajoutant des fonctionnalités, l'architecture du code devenait de moins en moins adapté.

Ce sont des choses qui arrive très souvent dans les projets qui vivent longtemps. Celui qui a commencé il y a 10 ans, ne peut prévoir ce qu'il faudra implémenter 2 ans, 5 ans, 10 ans après.

De plus un logiciel comme Composer ou autre se base sur un framework (celui de Mozilla), qui évolue lui aussi et propose des nouveaux composants, des nouvelles Apis. Et si le logiciel ne fait pas évoluer son code en même temps pour profiter de ces nouveautés, on se retrouve au bout d'un moment avec du vieux code tout moche, nécessitant de la refactorisation qui peut être très compliqué.

Et il arrive donc un moment où c'est plus rapide et mieux de tout jeter et recommencer, que de vouloir faire évoluer le code.

Pour éviter ça, il faudrait maintenir et faire évoluer le code dans le bon sens, mais ça demande du temps, des contributeurs etc... (Mozilla Composer étant le parent pauvre en la matière, dans le projet Mozilla).

à te lire, on comprend que c'est bluegriffon qui produit du code moche pas standard. À priori, j'ai mal compris, et alors tu te trompes en disant que c'est pas standard. Si c'est dans la spec, c'est que c'est "standard" (ou "pre-standard" vu que la spec est encore un brouillon).

Bref, ton message n'est alors pas clair.

PS: par curiosité, tu es vraiment membre du HTML5-WG, ta boite est membre du W3C, a payé sa cotisation, tu vas aux meetings, participent aux confcalls ? ou tu es juste inscrit à la mailing-list ? Parce que bon, "participer" à un WG, ça veut tout dire et rien dire à la fois... Surtout pour le HTML5-WG, la ML ouverte à tous, même à des pseudos experts, ce qui fait que bon, il y avait, au moins à une époque, beaucoup de brouahah pour rien.

tu remarqueras que ça date de plus d'un an, et que à priori, ça n'a pas beaucoup avancé.

le support ftp est devenue une extension (gratuite). Voir sur http://www.bluegriffon.com/

En terme d'évolutions de fonctionnalité, en terme de code, c'est un projet mort. Tout juste est-il maintenu pour qu'il continue à fonctionner sur les versions successives de gecko. Il n'y a personne qui le fait évoluer.

Il y a eu un rapprochement entre l'auteur de Kompozer et l'équipe de Seamonkey, pour mutualiser les efforts (importer les évolutions de Kompozer dans Composer entre autre), mais je ne sais pas ce qu'il en ai ressorti depuis. (Pas de release de Kompozer issue de cette fusion prévue)

Kompozer est en partie obsolète, d'autant plus qu'il est basé encore sur un noyau Gecko 1.8

je parle bien sûr des dernières versions "officielles" (0.8 beta)...

PS: je ne cherche pas à spécialement mousser Daniel ou Kaze, juste à rétablir la vérité. Ce sont deux personnes que je connais très bien et que j'estime.

disclaimer : j'ai bossé avec Daniel pendant 4 ans et demi (mais pas sur Nvu).

Un jour, en 2005, il a décidé que Nvu ne le satisfaisait plus

Totalement faux. Un jour, en 2005, Linspire, qui avait commandé à Daniel le développement de Nvu, a décidé de ne pas poursuivre au delà de la version 1.0, pour les raisons qu'on sait par la suite : difficulté financière et cie, qui aboutit à la disparition de Linspire.

Et Linspire a décidé aussi qu'ils ne "libéreraient" jamais la marque Nvu (propriété en fait du fondateur de Linspire). Impossible pour Daniel donc de poursuivre le développement de Nvu sous le nom de Nvu donc, ni même mettre à jour le site web et cie, malgré de long mois de tractations.

À cela faut ajouter de long mois occupés sur d'autres projets (bah ouai, fallait bien manger), donc pas le temps de bosser sur un "fork" pendant pas mal de temps.

Quand il décida de se relancer sur le projet (concrètement en 2008), il y a plusieurs raisons qui ont fait que BlueGriffon a été fait from scratch :

• nvu était basé sur le gecko de l'époque: 1.7, qui était alors totalement obsolète en 2008 (gecko 1.9). À ceci il faut ajouter qu'il y avait pas mal de patch sur Gecko pour faire fonctionner Nvu. Patchs qui n'étaient plus trop nécessaires sur gecko 1.9. Mais c'est un travail assez titanesque pour migrer de Gecko 1.7 à 1.9, vous pouvez demander à Kaze, celui qui a maintenu Nvu (sous le nom de Kompozer) et qui a migré vers 1.8.
• Le code des couches hautes de Nvu (interface, API générales et cie), était hérité de feu Mozilla Composer (dont Daniel était aussi l'un des auteurs principaux). API qui devint vieille, obsolète, moche, difficilement évolutive, maintenable etc...

Bref, nécessité de tout refaire from scratch, pour gagner en temps, en maintenance, en performance etc..

Pour l'utilisateur, Kompozer n'est pas forcément Obsolète (Coucou Kaze !), et même si Kaze a fait pas mal de boulot pour refondre certaines parties de l'interface et des api générales, il reste encore pas mal d'héritages de Mozilla Composer. Donc oui, d'un point de vue code, Kompozer est en partie obsolète, d'autant plus qu'il est basé encore sur un noyau Gecko 1.8, ce qui, en terme de support de CSS et HTML5, est très très loin derrière Gecko 2.0, utilisé par BlueGriffon.

C'est quand même dommage d'avoir besoin d'installer une application, alos que les technos web auraient permis de faire cela directement dans le browser. Non ?

Non. Les technos web sont loin de permettre de tout faire. (et heureusement, sinon les browsers seraient des vrais gruyères en matières de sécurité).

Clairement, il y a besoin d'utiliser des apis internes de Gecko pour manipuler le composant éditeur de Gecko. Toutes les APIS ne sont pas exposées dans les pages web.

Ne serait-ce que pour charger ou sauver le contenu html de l'éditeur dans un fichier sur le poste utilisateur, il n'y a rien pour ça en HTML. Fort heureusement d'ailleurs... Et il y a plein d'autres fonctionnalités qui ne sont pas possibles dans un contexte non-privilégié d'une page web.

Il produit du HTML5 sérialisé xml, càd du code pas standard

Tu devrais lire la spec HTML5, pour éviter de dire de telles bétises.

surtout de pas mettre de doctype réel

Tu devrais lire la spec HTML5, pour éviter de dire de telles bétises (bis)

(Rappel: même si il peut y avoir des bugs, l'auteur du logiciel s'y connait un tout petit peu au niveau HTML. Il fut co-auteur de HTML4, et il est co-chairman du working group CSS au W3C)

Pour le reste, je t'invite à ouvrir des tickets ici : http://bugzilla.bluegriffon.org/

Nvu fut déclaré successeur de Composer, mais n'avait déjà, tout comme BlueGriffon, aucun lien avec Mozilla (à part la techno). Nvu était un logiciel commandé par feu Linspire, à la société disruptive innovations, pour avoir un vrai éditeur HTML wysiwyg sous linux.

c'est pour montrer que linux fonctionne aussi sur le matériel de la pomme. non ?

tu veux dire que tu es jaloux de l'interface kikoolol de skype sous windows ? :-)

Personnellement, je préfère la "sobriété" de leur client linux.

Le truc qui me fait peur, c'est quid de l'avenir de la version linux. Parce que pour moi, sous linux, je n'ai pas trouvé d'équivalent qui me permettent de converser avec des user windows, mac sans problèmes (à moins que l'offre open source ait évoluée ces derniers mois).

(non, ceci n'est pas un troll)

donc effectivement, le ministère propose de désactiver des sécurités. génial.

bah si j'ai bien compris, c'est le site du ministère qui utilise une version du protocol SSL toute moisie, vulnérable...

Mais que font les admin sys de ces sites ? :-)

QML +CSS, du js, avec des composants en C++...

Aller, encore quelques petits efforts et on fera du XUL-like. Finalement, la plateforme Mozilla et XUL a de l'avenir malgré ses 12 ans d'age.. :-)

Et sinon, embarquer V8 n'est apparemment pas une super idée pour le moment (c'est le gars de Nginx qui le dit). Alors que SpiderMonkey est quasi aussi performant, et propose du javascript plus évolué (iterateur, generateur, array comprehension etc). Ceci dit, le choix de V8 est assez naturel puisque webkit est utilisé..

le souci de tmpfs en ram, c'est qu'il faut recopier toutes les sources (plusieurs megas) dans ce système de fichier, ce qui est plutôt long à faire. Et quand on y fait des modifs, faut faire une sauvegarde à chaque modif (si la machine venait à s'éteindre...).

Ou on peut y mettre le résultat de la compil, mais là le problème c'est qu'à chaque fois que tu rallumes la machine, c'est la compil tout entière qu'il faut te retaper (25min à 2h selon les machines).

bref, pas l'idéal le tmpfs je pense. (ou alors laisser allumer la machine 24/24)

et ton frigo, il fait comment pour aller commander tout seul ce qui manque ? hein ? (sauf si il est wifi)

:-)

Pendant qu'on y est, que pensez-vous de l'usage d'un SSD dans un contexte où il y a beaucoup de lecture écriture ? J'ai souvent besoin de compiler des gros trucs (genre Firefox).

C'est bien gérer maintenant les histoires de gestion d'allocations des mémoires dans le SSD, pour éviter que ce soit toujours la même partie du SSD qui soit utilisé ? ou est-ce que maintenant les composants sont suffisamment "costaud" pour durer longtemps avec des cycles lecture/écriture soutenu ?

Une idée, pour éviter d'avoir une config trop chère : c'est de prendre un SSD avec une capacité juste suffisante pour le système et les logiciels (40 ou 60 Go suffisent la plupart du temps), histoire de booster ton système, et un bon vieux DD grosse capacité pour ton home.

J'ai pas testé mais ça pourrait le faire je pense (pour les desktops)

c'est plus accessible dans le sens où :

• il n'y a pas besoin de fournir un alt.
• ça prend 2 à 4 octets, là où pour l'image + code html, ça en prend des dizaines (oui, le volume d'un fichier, ça fait parti de l'accessibilité)
• il n'y a pas que le HTML dans la vie, tout les formats de documents n'acceptent pas forcément l'incrustation d'images. Cela peut donc être utile "d'illustrer" des formats de fichiers purement textuel par exemple.