wismerhill a écrit 2603 commentaires

N'importe quel distribution linux peu tourner sans moteur html, et même sans serveur graphique, et continuer de fournir un système opérationnel avec des milliers d'applications et leur documentation (man) respective, le tout pouvant être mis à jour en une commande.
'
et honnetement, a par pour de l'embarque on s'en branle....

Ben moi, pour tous les serveurs que j'ai installé j'en suis bien content!

Moi je pleure quand desinstaller un logiciel par defaut sur kde et gnome m'enleve tout kde ou gnome, alors que ce logiciel par defaut et un jeu ou un logiciel de mail, qui sont quand meme moins utile qu'un navigateur web.

Faut utiliser une distribution qui faire ses paquets correctement.

Non, le gestionnaire de fenêtres gère les ... fenêtres.
Il ne s'occupe pas (et ne saurais pas s'occuper) des composants dans les fenêtres, c'est le domaine du programme et c'est lui qui détermine comment ces composants doivent se comporter au-delà du fonctionnement par défaut du toolkit.
Alors peut-être que le toolkit de macOS pourrait par défaut permettre de passer sur tous les composants, mais si le programmeur ne se soucie pas du tout de cet aspect, tu passera sur les composants dans l'ordre où ils auront été ajoutés (ou dans l'ordre où le toolkit les aura trié) ce qui risque de ne pas être pratique.

Ou pour pouvoir inclure des images?
Une capture d'écran ou un petit schéma c'est souvent utile dans une documentation, et ni man ni texinfo n'est prévu pour.

Bridés par rapport à quoi?

Ça t'avancerait à quoi d'avoir tes extension adblock ou youtube (pour prendre des exemples connus) pour visualiser de la documentation?

C'est vrai que certains petits trucs peuvent être utiles, comme pouvoir adapter la taille des polices, mais la majorité des fonctionnalités d'un navigateur web ne sert à rien pour de l'affichage de documentation.

Autre cas d'utilisation: un système d'assistant (wizard). Il est tout à fait intéressant d'avoir, dans les fenêtres successives, des explications mises en forme, avec images mais sans interactivité (éventuellement des liens pour renvoyer vers une doc plus complète). Ça a tout à fait du sens d'intégrer un moteur de rendu HTML dans ces fenêtre plutôt que de se prendre la tête par programmation de gérer des composants graphiques pour faire une mise en forme bancale (et ne parlons même pas des traductions).

Tu donnes des cas ou effectivement, le logiciel travaille sur un canvas HTML pour en modifier de manière interactive le DOM. Dans ces cas là, la liaison sur un moteur est normale.

C'est nullement le cas des programmes d'aide.


Manipuler le DOM, peut-être pas.
Par contre s'interfacer avec les ouvertures d'URL pour pouvoir générer dynamiquement des pages et coupler le tout avec un moteur d'indexation c'est exactement ce dont un navigateur d'aide à besoin, et qui ne serait pas faisable en ouvrant simplement un navigateur web.

Ce qui n'est pas normal, c'est que plein de programmes différents y aillent de leur implémentation d'un navigateur d'aide. Les programmes KDE (avec le khelpcenter) et Gnome (avec yelp) ont justement leurs navigateurs d'aides communs qu'ils peuvent lancer dans un programme à part.

Quand au problème du fichier temporaire, c'est un faux problème, un navigateur devrait ouvrir un page en lisant l'entrée standard. Quand on sais ce que met un navigateur dans son cache, cela me semble aussi un exemple mal choisis...

Je ne suis pas d'accord, je trouve justement que les programmes actuels utilisent beaucoup trop le disque dur, d'ailleurs mon konqueror est configuré avec la cache désactivée pour limiter la quantité d'IO du système.
Donc éviter de lancer un gros navigateur plein de fonctionnalités dans tous les sens juste pour afficher un peu d'HTML me semble une bonne chose (en terme d'IO et en terme de consommation mémoire).

Ce n'est pas aussi simple.
Si le but est juste de lancer un autre programme (dont tu espère) qui va affiche de l'HTML il suffit effectivement d'avoir son nom dans une variable d'environnement.

Si tu veux intégrer un rendu HTML dans ton programme (par exemple client mail ou afficheur d'aide) il vaut déjà mieux avoir une API (éventuellement minimaliste) pour le faire facilement, parce que l'intégration d'une fenêtre X dans une autre n'est pas une technique triviale et donne des résultats peu satisfaisants pour des trucs plus complexes qu'une vidéo.
Pareil si tu as ton HTML à afficher en mémoire (par exemple parce que tu l'as généré toi-même) et que tu veux éviter de devoir l'enregistrer dans un endroit temporaire pour qu'un autre programme puisse le lire (et si on ferme le programme d'origine avant le browser, doit-il supprimer le fichier peut-être encore utilisé, ou le laisser traîner?).

Il y a enfin le cas, plus particulier, des programmes qui ont besoin de s'intégrer intimement avec le moteur de rendu et le DOM de celui-ci. Typiquement les programme d'édition HTML, pas si rares que ça car beaucoup de clients mails proposent l'édition de mails en HTML.

Ça arrive avec l'intégration de policykit dans KDE 4.3.

Les développeurs de KDE ont décidé de ne pas faire une solution bancale à la va-vite et d'attendre une intégration correcte de policykit pour gérer les permissions plus proprement.

Ça c'est uniquement pour que le groupe soit hérité, ça n'impose pas les permissions des nouveaux fichiers.

En python, les parenthèses ont priorité sur l'indentation, il est donc tout à fait possible de choisir son indentation au sein d'un appel de fonction, de l'écriture d'une chaine, de tests etc.

Ah, ça je ne savais pas, merci.
(mon expérience de python date déjà de plusieurs années, je me suis concentré sur java pour raison professionnelle)

Je comprend que ce ne soit pas évident, comme tu dis, en java on a plutôt tendance à en rajouter pour que ce soit plus clair. On a besoin d'un commentaire pour dire que là, attention, on va ouvrir un fichier...

Ça ce sont les programmeurs qui appliquent sans réfléchir les consignes qu'ils ont eu a l'école, et pas que pour les commentaires!
On en a eu un comme ça pendant un moment, c'est toujours un petit éclat de rire, suivit d'un long soupir, de devoir reprendre (réécrire) son code.

Je précise que la cible est *python 2.3* , et je développe sous python 2.5. (Non, on peux pas upgrader... Le code doit être compatible avec les 2 versions).


Si ton code doit tourner sur python 2.3 alors il faut développer avec un 2.3!
C'est normal que les API évolue et il ne faut pas t'attendre à ce que tout ce que tu développe avec un 2.5 fonctionne sur un 2.3.

On a parfois le problème au boulot, avec java, on a forcément une version un peu récente par défaut sur nos machines avec d'autres versions à côté pour les développements qui doivent rester compatibles 1.4, mais parfois un des développeurs oublie sur quel JDK il est et on constate plus tard qu'on a des fonctions du 1.5 qui sont utilisées.
Heureusement maintenant on est passé à retrotranslator qui nous permet quand même d'utiliser les améliorations les plus fondamentales de l'API java 1.5.

Justement, tu fais des proportions qui n'ont pas lieu d'être.
L'enrobage syntaxique à la C++ de java fait que des très petits programmes vont faire beaucoup de ligne pour pas grand chose (mais contrairement à python on peut tout mettre sur une seule ligne ;-) )

De plus, je préfère écrire quelques lignes de plus et que le code soit plus lisible plutôt que d'avoir un truc super compact qu'il faut relire cinq fois pour comprendre ce qu'il fait. Mais là je pense plutôt à perl.
Et python, qui impose syntaxiquement l'indentation m'empêche certaine mise en forme du code qui en améliore la lisibilité (séparer un long appel de fonction sur plusieurs lignes avec indentation variable pour bien identifier des groupes de paramètres par exemple)

Et si tu pense qu'on peut faire un projet de taille raisonnable en quick and dirty, je plains ceux qui devront reprendre ton code.

* créer un objet URL et un objet "BufferedInputStream". En python, je gère un seul objet, "session HTTP". "Buffer" ? "Stream" ? Concepts beaucoup trop bas niveau pour ce que je veux faire, morbleu !
* De même, pour l’écriture, tu es obligé de créer un FileOutputStream ET un BufferedOutputStream par dessus. Pour la concision, on repassera.


Non, tu n'es pas obligé, tu peux te contenter de l'InputStream de l'URL et du FileOutputStream, mais c'est plus efficace de bufferiser les IO.

Idem pour la clareté et la simplicité. Pour écrire dans un fichier, c’est trois classes donc: OutputStream, BufferedOutputStream et FileOutputStream. Même si c’était aussi concis que python au niveau du nombre de caractères, ça ne l’est pas au niveau de la doc à consulter.

L'OutputStream c'est juste parce que c'est la classe de base et que j'ai l'habitude ne ne pas utiliser les sous-classes quand je peux me contenter de la classe parente, tu peux écrire directement BufferedOutputStream si ça te dérange tant que ça d'avoir des noms de classe différents.

* Obligé de te taper une boucle pour faire le transfert. Effectivement, tu fais ça en une seule ligne, mais bon…

Dans la méthode python cette boucle est sous-entendue. Au boulot dans un projet de relativement grosse taille on a une méthode utilitaire qui fait ça, on lui passe un InputStream et un OutputStream (ou directement des fichiers ou URLs, y a plusieurs variantes) et elle boucle pour copier l'un dans l'autre.

Ça semble négligeable, dit comme ça. Mais supposons que je veuille en fait remplacer tous les "spam" par des "egg" dans mon texte (oui, supposons que ce soit pas un pdf). En Python, je remplace response.read() par response.read().replace("spam", "egg"). En Java ? Je dois alors m’amuser avec les StreamReader, les convertions byte[]/String… Ajoute une expression régulière, et la différence python/java devient évidente.

Mais donc dans ton exemple tu va charger tout le contenu de ton URL dans une chaîne de caractères pour pouvoir ensuite faire un remplace dessus et puis la réenregistrer, tu va utiliser beaucoup plus de mémoire que nécessaire par rapport à un fonctionnement en streaming.

Mais on en revient à ma remarque précédente que java est plutôt fait pour des projets d'une certaine taille et pas pour du quick and dirty.

> > mes try{}finally{} le rendent plus robuste
> d'accord avec ça le problème que ça me pose c'est que tu es obligé de les mettre...

Bien sur qu'on est obligé de les mettre, l'interpréteur/compilateur ne peut pas trouver de lui-même quelle est la façon intelligente de le faire. (Dans les cas simple comme ici ce serait possible, mais pas en général)

En effet, je me contentais de donner un exemple de code équivalent au code python (enfin, pas tout à fait équivalent, les try{}finally{} le rendent plus robuste en garantissant la fermeture propre des flux).
Mais je considère effectivement que java est plus adapté à des programmes de taille moyenne à grande bien architecturés, pas pour des petits programmes quick and dirty. Pour ce genre de cas je préfère le shell mariné de grep sed awk et autres commandes facilement scriptables ;-)


- des catchs parce que le finally seul ne semble pas plaire à mon compilo java C'est d'ailleurs très bien que Java force la gestion des erreurs mais c'est précisemment ce que j'aime éviter de faire quand je prototype


Non, soit tu intercepte les exceptions (et tu en fait quelque chose), soit tu déclare que ta méthode peut les lancer, en l'occurrence ton main.

Ou même GNU/Hurd!

Allez, le vendredi se rapproche...

En java tu peux faire:


java.io.InputStream is=new java.io.BufferedInputStream(new java.net.URL("http://download.savannah.gnu.org/releases-noredirect/tsp/dte(...)
try{
java.io.OutputStream os=new java.io.BufferedOutputStream(new java.io.FileOutputStream("what_is_dtest.pdf"));
try{
int c;
while(c=is.read()>=0){os.write(c);}
os.flush();
}finally{fos.close();}
}finally{is.close();}


SUN essaie de relancer l'intérêt de java (la plateforme, pas le langage) pour les contenus web et comme concurrent de flash avec son javaFX:
http://www.javafx.com/

Pour le moment il faut encore programmer pour animer les trucs, mais ils prévoient à court terme (quelques mois) un éditeur visuel.
Le langage javaFX en lui-même est assez différent de java, mais peut utiliser toute la bibliothèque standard java s'il le souhaite. javaFX a ses propres composants graphiques et peut aussi intégrer des composants swing (le contraire n'est pas encore possible, mais devrait arriver car c'est très demandé).

Vu ce que tu décrit, il me semble que tu tente de réécrire en javascript tout ce que fait le navigateur (y compris le head de la page!) quand on clique sur un lien et qu'il charge la page.
Mieux vaut le laisser faire, il le fera bien mieux.
Si tu veux absolument que ce soit fait par javascript t'as qu'à lui demander de charger une nouvelle adresse.

C'est là que la transparence réseau de X tombe à point, j'ai installé un oracle sur un serveur sans interface graphique via une connexion ssh qui déportait l'affichage sur ma machine.
Sinon, dans le même ordre d'idée un serveur VNC sur le serveur peut faire l'affaire, ça évite de devoir se déplacer jusqu'au serveur.

J'ai jamais testé la version entreprise, mais dans la mandriva normale le centre de contrôle mandriva (drakconf) fonctionne aussi en mode texte, on n'a pas toutes les fonctions (pas les wizard), mais l'essentiel pour faire fonctionner la machine est là (en particulier pour reconfigurer l'interface graphique et le réseau).

Firefox 3.5 n'est pas encore en version finale, la dernière en date (d'après le site de mozilla) est la rc3 (as-tu bien cette version et pas une plus ancienne?), ce qui veut dire qu'on est très proche d'une version finale, mais il est peut-être encore temps de rapporter ces problèmes (ou d'apporter ta contribution a des rapports de bugs probablement déjà existant) sur
https://bugzilla.mozilla.org/

Pour les CSS c'est normal, c'est le principe de base tel qu'il était déjà du temps du HTML pur: les navigateurs supportent ce qu'il peuvent/veulent et ça donne un rendu plus où moins dégradé. (Bon, après que les navigateurs interprètent de façon différente les même propriétés c'est un autre problème, mais il y y a des cas où la recommandation est foule et laisse la place à l'interprétation)

Par contre, pour le javascript, c'est très gênant que l'API de base soit implémentée suivant le bon vouloir des navigateurs (et en particulier le DOM qui est une vraie galère si tu veux faire un truc portable).

C'est simple, il faut juste les mettre (avec les autres) dans le répertoire d'installation d'eclipse.
$ECLIPSE_HOME/plugins et $ECLIPSE_HOME/features (suivant le niveau de fonctionnalité fourni par le plugin)

Moi je ne fais que comme ça, je n'aime pas les programmes qui font des installations de modules à leur façon je ne sais où et qui outrepassent le système de packaging de ma distribution.

Si tu arrive à faire fonctionner gcj sous windows il y a moyen.

Alors tu devrais plutôt essayer d'avoir des noms de domaines différents de l'extérieurs pour tes différents serverus internes.
Par exemple 1.apache qui renverrait vers serveur_1 et 2.apache qui renverrait vers serveur_2 (avec des VirtualHost différents)

Tu peux aussi faire des virtual host sur des ports différents, mais ça risque de ne pas être très partique d'être sur des ports non standards.