tgl a écrit 1743 commentaires

> le truc, c est que c est effectivement l'avenir

Ouais, je suis d'accord, mais c'est pas à une appli de t'imposer le moment ou tu bascules. Quand les applis seront toutes compatibles, personne ne rechignera plus à franchir le pas, mais en attendant, ça sert à rien de pousser. C'est pas la mort d'ajouter, au fur et à mesure du code, un appel à une fonction de conversion de la glib avant chaque accès au fs, comme dans les tutoriaux, et comme partout ailleurs dans les codes gtk2... Bon, maintenant, ok, c'est pas moi qui ait codé, etc.

> Plus sérieusement au niveau des gestionnaire de paquetage -rpm, portage, deb...-
> cela rend caduc les bases des gestionnaire non???

Pas vraiment, mais ça leur enlève (enfin, simplifie à l'extrême) une partie du boulot: la gestion des fichiers. Quand à la gestion des dépendances, elle est absente des AppRun, et donc le gestionnaire de packages est utile. Mais on pourrait imaginer, sur une distrib 100% ROX, et en enrichissant un peu les AppRuns, fusionner totalement ces deux aspects de la gestion de paquets. (Quand à l'aspect "gestion de la compilation", c'est évident que un .ebuild qui fait principalement "AppRun --compile" fait double emploi, et donc sur ce plan là aussi, là fusion est largement envisageable. Mais bon, je trip là.)

> qu'en est il si on met à travers ce principe une application qui apporte ses include,
> et qu'on lance un configure pour compilation d'un programme tiers ayant besoin de
> ces sources, ainsi que d'autre, il faut tout se taper à la main les
> --with-app-include=/// pour toutes les sources requise, ecla fait bc de manip non?

Généralement, c'est pour utiliser des librairies, pas des bouts de sources, qu'on inclut des headers externes à l'application (sauf bidouille à la "utilisation des filtres de mplayer dans transcode", mais là c'est déjà manuel). Et bien rassure toi, c'est déjà tout prévu, et largement aussi (plus) pratique que ce que tu connais actuellement.

Dans Rox, tout ce qu'il faut pour utiliser la librairie Toto est dans le répertoire Toto qui est un sous répertoire d'un des répertoires référencé par ton LIBDIRPATH. Quand une appli à besoin de Toto pour être compilée, ce path est parcouru lors du "AppRun --compile", jusqu'à trouver Toto. Or Toto contient les headers, les .so, etc., et un script permettant de générer les flags gcc qu'il faut pour l'utiliser.

Donc pas de problème, un répertoire à coller dans un endroit bien connu, c'est tout ce qu'il faut pour qu'une librairie soit totallement accessible et utilisable. Le seul hic c'est si tu veux utiliser une librairie Rox pour un programme non-Rox à compiler avec les habituels autotools, alors là ça va pas, c'est pas fait pour, et faut donner les paths à la main, mais je trouve pas ça critique. Bref, le système est différent, mais dispose d'outils qui lui sont propre et sont très pratiques. Et puis y'a des petits bonus, genre si t'as juste dumpé les sources de ta librairie, elle sera compilée la première fois que ce sera nécéssaire. Et même potentiellement, si elle est compilée Linux-x86 mais que tu en as besoin depuis une compile Hurd-ppc (oui, je sais, pas de si tôt) sur une autre machine du réseau, cette nouvelle archi sera compilée aussi dans un autre sous répertoire de Toto.

Sur la Redhat, c'est un peu ce que j'avais compris en lisant à droite à gauche des commentaires disant en substance que c'était bien gentil de passer en UTF-8, mais qu'il faudrait tester autre chose que en_EN après... Pour l'instant, moi j'ai vraiment la flemme de me cogner la transition sur ma Gentoo, je sais trop que ce sera chiant, qu'il faudra que je me cogne plein de petits wrappers shell qui remettent les locales en iso-8859 pour toutes les applis qui merdouillent, galère quoi. Plus tard.

Du coup, ce que j'ai fait pour utiliser ROX quand même lors de mon gros rangement de fichiers ogg (qui sont à peu près mes seul fichiers nommés avec des caractères non-ASCII), c'est un tout petit patch crado qui fait quelques unes des conversions manquantes avant d'écrire sur le disque. Il est tout nul parceque je suis incapable de faire du C pour de vrai (c'est là que j'ai réalisé que même le peu que je savais à l'école je l'avais presque oublié), et ça affiche quand même mes vilains noms accentués en rouge, mais bon, ça marchouille pour les déplacement, copies et renommages, et c'est ce dont j'avais besoin...

Les petites choses importantes que j'ai évidemment oubliées :
- ROX-Filer fait aussi punaiseur et panel (cf. "rox --help"). Si vous voulez les utiliser pour mettre des icônes de lancement d'applications, vous devrez vous creer des wrappers à la sauce ROX (des AppDir quoi, cf. la doc). Le plus simple est de les générer à partir de .desktop de Gnome ou KDE grâce à "Desktop2App", ou encore de les faire avec "AppBuilder" (tous ces softs sont référencés sur le site ROX)
- un des gros changements qui a accompagné le passage à GTK2 est l'utilisation exclusive de UTF-8 pour les noms de fichiers. Perso, je pense que c'est une connerie et qu'il aurait mieux valu faire des conversions UTF-8<-->locales lors des accès au système de fichiers, comme le font les applis Gnome2/GTK2 habituelles. Mais les dévellopeurs ont fait ce choix, +/- parceque "c'est l'avenir" à ce que j'ai compris...

Bon bah celle d'aujourd'hui sur les brevets logiciels était très bien j'ai trouvé (bon rapport information/temps, vulgarisation sans simplification outrancière, ils sont forts parfois ces journalistes...). Le texte est en ligne: http://www.radiofrance.fr/chaines/france-inter01/information/chroni(...)

Et celle de demain devrait être consacrée à la sécurité informatique.

Merci à Martin Winckler à France Inter.

Dans mldonkey c'est la "recherche étendue". À utiliser avec modération ceci dit, c'est beaucoup plus gourmant pour le réseau que la recherche locale sur quelques serveurs. (Et c'est entre autre pour ça que la connection à plusieurs serveurs n'est une mauvaise chose en soit).

Mldonkey: un port configurable en TCP (4662 par défaut), un autre en UDP (celui de tcp + 4, soit 4666 par défaut). Plus peut-être autre chose pour les serveurs ou les recherches, je sais plus trop, mais j'ai une url:
Overnet: un port configurable (3548 par défaut je crois), à ouvrir en UDP et TCP.
FastTrack: un port (1214 par défaut, je ne sais pas ce que ça donne si on le change), à ouvrir en TCP (quelqu'un peut confirmer ?).
Bittorrent: un port (par défaut 6882, je ne sais pas ce que ça donne si on le change), à ouvrir en TCP, plus éventuellement les suivants à concurrence de 10 (j'en ai ouvert 4, ne me demandez pas pourquoi).

> mlDonkey c'est mal.

Bon, là je ne demande pas d'explications. Il y a déjà eu ici, et c'est pas si vieux, un troll sur le dénigrement fallacieux de mlDonkey par les suppôts des clients officiels (tm) et autres muletiers alter-monopolistes.

> Le multi-réseaux, c'est pire.

Là par contre, je veux bien que tu m'expliques, ce troll me semble être nouveau.

Oh bah moi je suis toujours sous mlDonkey, et je vois pas trop de raison de passer à [E|L|X]mule. D'autant que maintenant que j'ai éssayé, les supports de FastTrack et Bittorrent me manqueraient un peu.

Ouais, d'ailleurs, c'est pas évident de troller politique en anglais... Je regrette presque que la mayo soit pas plus montée ici, ça aurait été reposant de faire ça en français.

Non, j'aurais honte de faire douiller le contribuable pour un de mes fantasmes de geek. (par contre, si jamais il veut remplacer ma sun...)

Ah bah je viens de voir sur la page de l'importateur que y'a un adaptateur XGA pour le SL-C700. Bon bah je veux juste des sous alors.

avec sortie vidéo pour la TV
Moi j'en voudrais un avec sortie VGA pour brancher sur videoprojecteur, pour trimballer des slides en pdf. Et puis avec une toute petite télécommande avant/arrière. Oui, bon, c'est un peu loin du concept des PDAs en fait...

s/"je me suis mis à préferré Armageddon. Faut le confondre avec Worms 2"/"je me suis mis à préferrer Armageddon. Faut pas le confondre avec Worms 2"/

Mais pourquoi diable suis-je repassé voir ce post, ça m'a l'air catastrophique. J'arrête là.

J'ai pensé ça pendant un temps aussi, et puis à l'usage répeté, je me suis mis à préferré Armageddon. Faut le confondre avec Worms 2, il a vraiment corrigé les défaut. (Argh, je soutiens une position impopulaire, ça craint...) - sur la précision des armes : c'est vrai que l'éspèce de flame qui sort de l'arme donne l'impression d'être plus grossièrement graduée que la barre de worms(+). Mais en fait, au fur et à mesure que tu tires, tu prends vraiment conscience de la vitesse à laquelle la barre avance, et c'est plus un problème de faire des demi graduation, etc. Je crois que de toutes façon, notre cerveau anticipe cette progression plutôt que d'attendre de constater visuellement qu'on est arrivé à la bonne force. Donc c'est pas vraiment moins bien, question d'habitude quoi. - sur les graphismes : franchement, j'apprécie de pouvoir jouer en 1024, le côté cartoon je le trouve sympa, etc. Mais là, c'est vraiment une question de goût, dur d'argumenter. - sur les aspects tactique, gameplay : Worms(+) était très bien dosé, très intérressant au niveau tactique, mais y'a vraiment moyen d'arriver au même bon dosage dans Armageddon. Mais surtout, imiter Worms(+) dans Armageddon n'est vraiment qu'un des très nombreux jeux possibles, et en bidouillant d'autres ensembles d'options, on arrive à des trucs très sympa (je conseille l'utilisation de petits programmes externes pour bidouiller les options, c'est plus pratique et ça donne accès à des possibilités cachés). Par exemple, un mode que j'aime beaucoup que je me suis fait consiste à avoir des worms immortels mais handicapés. On ne peut les tuer que en les noyant, par contre ils ne peuvent pas bouger, sauf avec des cordes. Mais ils n'ont pas de cordes. Mais il n'y a presque que ça dans les caisses. Mais ils ne peuvent pas aller les chercher à pied, évidemment. Mais ils ont des moutons volants, qui peuvent ramasser des cordes pour eux, et leur donner alors un avantage décisif sur leurs adversaires. Je vous laisse imaginer à quoi peut ressembler une partie, mais franchement, essayez, c'est sympa. Par contre c'est vrai que ça n'a plus rien à voir avec Worms(+)... mais c'est bien non plusieurs jeux en un ? - jeux en réseau : mon petit frère a un "world party" qui ressemble furieusement à Armageddon, sauf que ça marche sur internet. Bon, ça franchement, je vois pas l'intérêt. Le fait d'être sur le même clavier que ses adversaires est vraiment partie intégrante du jeux, surtout à plus de deux. La guerre psychologique est au moins aussi importante que le jeux lui même.

"rhhaaa la bonne vieille banana bomb" Sans oublier la "Mole Bomb", accessible seulement après patchage de deux octets dans le binaire, et qui déchirait pas mal aussi :)

Ça craint, va falloir rechercher la licence du premier "Hello world".

Plus depuis le xfree-4.3.0-r2 je crois. C'est maintenant bien dans /usr/share/cursors/xfree.

Allez, en vrac:
* l'installation de curseurs peut se faire dans /usr/blablabla, mais aussi au niveau utilisateur dans ~/.icons
* le choix d'un thème au niveau utilisateur peut se faire soit:
- par une variable d'environnment: XCURSOR_THEME="nom-du-theme"
- par une ressource X: dans ~/.Xdefaults ou ~/.Xresources : "Xcursor.theme: nom-du-theme"
* on peut aussi changer la taille du curseur:
- soit par un variable d'environnement: XCURSOR_SIZE="16"
- soit par un ressource: "Xcursor.size: 16"
* le plus joli thème que j'ai trouvé pour l'instant est celui du bien connu Jimmac:
http://jimmac.musichall.cz/i.php3?ikony=71(...)
http://jimmac.musichall.cz/download.php3?id=33(...)
* Y'a pas mal d'autres thèmes là:
http://www.kde-look.org/index.php?xcontentmode=mouse(...)
(beaucoup de ces thèmes sont en fait convertis depuis des thèmes Windows XP, grâce à ça: http://www.bwbohh.net/?section=Software&subdir=Free/SD2XC(...) )

Tu nous as fait un assez bon condensé des trolls habituels, avec des conclusions chaque fois pro-Emacs mais qui sont je pense justifiées, parceque les arguments des détracteurs que tu cites sont en effet plutôt infondés. Soit.

Mais je n'ai moi rien reproché à Emacs justement, j'ai juste dit que j'étais pas "fan". J'apprécie justement son côté généraliste mais spécialisable, j'adore le lisp en plus, et c'est bien pour ça que j'en parlais. Ceci dit, j'arrache pas non plus mon teeshirt à chaque utilisation, c'est tout. Pas "fan" quoi. Et je comprends que certains préferrent, pour des tâches particulières, des éditeurs spécialisés qui collent plus à leurs autres applications, par exemple Gnome ou KDE (je ne connaissais pas la version KDE de Emacs. Y'a ça pour Gnome aussi ?).

Maintenant, puisque tu tiens à ce qu'on en parle, reconnaissons qu'Emacs n'est pas la panacée non plus : Les modes d'Emacs ne permettent pas de faire de l'affichage formaté, parceque le moteur d'affichage n'est pas prévu pour. On est pas prêt de faire un mode équivalent à LyX pour le LaTeX. (X)Emacs ne permet pas de faire des modes qui modifient vraiment l'interface, à part des ajouts dans les menus. Pourtant, il y a d'autres composants dans les UI modernes qui sont bien pratiques, et qui sont abondament utilisés, avec raison, dans les éditeurs spécialisés à la Kdevelop ou Kile. Bref, Emacs est certes généraliste, mais il ne permet pas pour autant de faire certaines des choses que permettent les éditeurs spécialisés récents.

D'où l'idée que j'envisageais d'un éditeur généraliste qui oserai reprendre les bons principes d'emacs tout en offrant des composants d'interfaces modernes. Comme je l'ai dit après, c'est probablement Eclipse que j'avais en fait en tête sans l'avoir nommé, mais il est un peu tôt pour en juger. Et si il pouvait y avoir un équivalent orienté Gnome, et un KDE, ce serait parfais. Et alors, plutôt que de coder une appli par langage à éditer, les gens pourraient se contenter de faire des plugins à ces grands éditeurs.

Laisse tomber, c'était juste une petite vanne à ces deux collègues, qui ne mérite qu'un petit [-] sans question :)

Bah ça fait longtemps que j'ai pas essayé, mais autant que je me souvienne c'est kwrite avec ce qu'il faut autour pour faire du code Qt/C++ (browser de classes, patrons de classes, builder...), non ? Pour les autres langages, c'était juste, comme d'habitude, la coloration et rien d'autre... bref, pas vraiment intérressant. Il me semble que y'avait ceci dit un vague système de plugin,mais je sais pas trop ce qu'ils étaient censé avoir le droit de faire, et je n'en ai jamais vu.

Maintenant, comme je disais, c'était y'a déjà qlqs temps, donc je peux me tromper. Si il existe un plugin pour par exemple travailler efficacement en Latex ou HTML, je le testerai volontier.

Par contre, on pourra peut-être m'objecter aussi Eclipse, et là j'ai rien à dire. Vivement que y'ait + de plugins, c'est tout.

Non il n'est pas aussi démonstratif, par contre il était fier d'avoir posté aussi vite :-)

Je te trouve bien renseigné... Je soupçonne de plus en plus olivp d'être ton multi à troll, qui te sert à clamer ce que ta position de modéro t'oblige à taire. D'ailleurs, vous postez tous les deux depuis des machines aux IP étrangement corrélables ;-)

Je trouve ça un peu dommage quand même tous ces efforts sur des éditeurs spécifiques. Un pour le HTML, un pour le C++, un pour le LaTeX... J'en ai même vu un l'autre jour pour le PHP ! Je dis pas que ça fait des logiciels inutiles, mais je pense que y'a vraiment des efforts de code qui seraient factorisables. Or, que ce soit côté Gnome ou KDE, on nous pond:
- des éditeurs génériques dont le graal est la coloration syntaxique
- des éditeurs spécifiques bien fichus certes, mais vraiment... spécifiques.

Que les gens n'aime pas Emacs je veux bien, je suis pas fan non plus, mais pourquoi personne ne se lance dans un vrai éditeur qui en reprendrait qlqs bonnes idées ? Quelque chose qui serait sauce KDE ou Gnome, mais avec des modes faisant plus que du simple barbouillage de mot clefs. Des modes qui agirait sur les éléments d'interface, les commandes de compil, l'affichage mis en forme, etc. C'est vraiment si has been que ça le concept de soft puissant avec un langage de script derrière ?

LaTeX était LE format préféré il y a quelques années. En tant que scientifique, je peux le dire avec regret, maintenant, il y a autant d'acceptation de Word que de LaTeX.

Ça dépend vraiment des disciplines, voir des branches des différentes disciplines. Latex est quasi omniprésent dans les revues de mon domaine (analyse statique et vérification de programmes), même pour les papiers signés MS Research, alors que y'a pas mal de Word dans certaines autres branches de l'informatique. Je pense qu'il y a des habitudes suivant les communautés, même si en théorie les deux sont souvents acceptés par les éditeurs. Mais là où c'est le pire, c'est dans les sciences humaines, où Latex est presque inconnu au bataillon. Ils ne savent pas ce qu'ils ratent nos confrères du côté mou :)