Moonz a écrit 3657 commentaires

Bon, je vais tenter une Gentoo alors ;)
Par contre tu me fais un peu peur là:
> gnome-base/gnome-desktop-2.2
Pourquoi 2.2 ?
Et gnome-desktop, c'est pas un métapackage qui installe gnome-panel, gnome-control-center et autres paquets ? (parce que sous ma debian, c'est le cas...)

En tous cas, merci à tous pour vos réponses :)

> D'après ce que tu décris, ça ressemble fort à Gentoo
Tu es sûr ? Il me semblait qu'avec Gentoo, on peut bien mettre --disable-plop, mais que les dépendances sont "statiques", et qu'il installe quand même libplop :) (sauf si je modifie le paquet à la main et toussa, mais là c'est... lourd)

> mais Gentoo n'est pas binaire
C'est pas parce que je suis sous Debian que je suis réfractaire à toute distribution source :)


> Sinon, je ne comprends pas vraiment ton problème. est tu vraiment à cours d'espace disque pour ne pas pouvoir installer cette petite dépendance de quelque Mo ?
Ben quelques mégas en plus sur mon disque dur, ça fait rien. Mais je suis en 56K, et 1mo en moins par mise à jour, ça m'intéresse :). De plus, comme tu le fais remarquer, une telle distribution est forcément une distribution source. Et les sources, c'est plus léger que binaires+libdevel la plupart du temps... Je comptais donc de toutes façon passer à une distribution source...

> Ou bien c'est juste de l'extrémisme ?
Un peu, aussi ;)

>Je ne compte plus le nombre de fois ou je n'ai pas vu une popup apparaitre.

Heu si t'as besoin d' effets d'ombrages pour ça, c'est ton opticien que tu devrais aller voir là, et vite :)

> Dommage pour gaim dont j'ai été fan très longtemps, mais quand on a touché à mercury ou kopete, on peut pas revenir à gaim.
Ben moi, j'ai testé Kopete, et je suis retourné à Gaim :)
Quant à Mercury, je vois pas comment on pourrait faire pire: un client MSN en Java, désolé, mais même si je suis pas un intaigriste barbu, ça me ferait mal de l'utiliser :p

> Si pour le Head Dev de GAIM une version 2.0 c'est un smooth scroll et un panel de plugin remanié (mais qui fait la meme chose) alors je crois qu'il vont droit au mur...
C'est quoi cette fixette sur le numéro de version ? Je vois pas la différence entre:
0.9 0.10 .11 0.12 0.13 ... 0.87
et:
1.0 1.1 1.2 1.3 1.4... 2.0
C'est qu'une question de position de la virgule. SI t'es pas content, tu fais mentalement une petite division par 10, et ça devient Gaim 0.20, et tout va bien dans le meilleur des mondes...

P.S.: je te vise pas personnelement hein, mais les commentaires "les devs de Gaim sont des gros cons, leur nouveau système de numérotation des versions ne représente pas l'avancement", ça va bien deux minutes (en fait non, ça ne va même pas deux minutes)...

Ben ça reste portable partout où g++ tourne, et c'est pas mal...

Opposer dcop et la ligne de commande, c'est pas très malin...
Perso, certains de mes scripts shell font appel à dcop (et parfois c'est dcop konsole-xxxx ;)). De plus avec dcop tu ne peux pas faire des choses simples comme assignation de variable, boucles... Je vois mal comment tu peux faire un truc comme for f in *.wmv; do mencoder $f -o `echo $f | sed s/.wma/.avi/` -oac faac -ovc x264; done avec JUSTE dcop... Et je vois mal comment controler kwm avec la ligne de commande sans dcop. Pour moi, les deux sont complémentaires...

Bon , au cas où quelqu'un d'autre se pose la question, ça marche très bien pour moi (mis à part que contrairement à ce que dis la fnac, c'est un SPD3000CC :)). La plus grosse difficulté a été de trouver le port USB 2 du PC :)

> Konqueror se lance avant qu'on clique tellement c'est rapide
Tu travailles sur un supercalculateur ? Chez moi konqueror mets plusieurs secondes à se lancer... (2-3, montre en main. Mais j'ai toujours l'impression que c'est beaucoup plus... commequoi, 3 secondes, ça peut être très long ;))

> Comme Internet Explorer, il fait tout
Quelle référence :)
Blague à part, mettre ensemble client ftp et gestionnaire de fichiers, je dis bravo. Y mettre un navigateur internet dedans, ppasse encore, mais c'est déjà limite. Mais y ajouter éditeur de code (la super intégration de kate dont tu parles) et suite bureautique (via le kpart koffice), c'est abusé :-/

> Par contre, le navigateur est aussi bon que Firefox voir mieux
Contre un firefox nu, peut être (et encore). Mais j'ai encore rien vu qui arrivait au niveau d'Adblock pour Konqueror (en fait, il lui arrive même de laisser passer des popups...). Et je trouve quand même la navigation par onglet inférieure à Firefox (je la trouve plutôt poussive, et surtout il me permet pas d'ouvrir les liens qui sont censés s'ouvrir dans une nouvellefenêtre dans le même onglet (je ne veux jamais qu'une fenêtre, et si je veux l'ouvrir dans un nouvel onglet, clic du milieu))

> Points faibles de KDE : ça plante beaucoup.
Vraiment, on doit pas parler de la même chose. La seule chose qui ai jamais planté, c'est KMail (une belle erreur de segmentation lorsque j'ai voulu suprimer trop de messages d'un coup). kicker, kwin, dcop, kdesktop et autres programmes "centraux" n'ont jamais planté chez moi...

>Je dis pas "Gnome" c'est la merde, mais que certains points sont vraiment gênants dans une utilisation quotidienne.
s/Gnome/KDE/ (et d'ailleurs je suis d'accord avec toi pour Gnome aussi). Il ya des trucs bien dans KDE (les kioslaves, kget (j'ai installé flashgot juste pour lui :)), klipper, konsole et quelques autres) mais des fonctionnalités dont j'ai pris l'habitude sous XFCE me manquent teriblement - et quand je retourne sous XFCE, je ne ressent auxun manque de fonctionnalité - comme le alt-F5 pour maximiser une fenêtre (par acquis de conscience, je viens de vérifier si c'était pas une autre touche et j'ai appuyé sur alt F4, obligé de recommencer le message :)), ou pouvoir déplacer des fenêtres d'un bureau à l'autre par simple glisser déposer dans la boites des miniatures...

e = ln2 ? Tu as appris où les maths ?

Ben comme apt-get lui -même, pas besoin d'aptitude pour ça :)

> "Au final, notre objectif est de combiner Flash et PDF"
ben ça promet :)

Dans les gagnants de l'IOCCC, il y a quelqu'un qui a fait un serveur HTTP ultra light (supporte en partie CGI, mais pas entièrement et c'est tout... Mais en quelques centaines de lignes de code seulement :o))

Et en python, tu peux faire les deux :)
(cad à la fois gtk.VBox(homogeneous=True, spacing=5) et gtk.HBox(True, 5))

Le langage Boo n'est pas mal, mais l'API est comment dire... horriblement trop complexe pour faire des trucs basiques (compare le module httplib de python et essaie de faire aussi simple avec Mono...). A l'époque où j'ai essayé (il y a 2-3 mois), ça m'a vraiment donné l'impression d'utiliser une bombe H contre un moustique...

C'est pas non plus la mer à boire hein... T'as juste à tester os.name... La vraie critique qu'on pourrait faire, c'est qu'on doit préciser le chemin entier, et encore... c'est pas plus difficile de chercher automatiquement dans $LD_LIBRARY_PATH, /usr/lib et /lib... Ca se fait en quelques lignes de codes. Tiens, juste pour m'amuser:

def LoadLibraryPath(lib):
	search_path = os.getenv("LD_LIBRARY_PATH")
	
	if search_path is not None:
		search_path = search_path.split(os.path.pathsep)
	else:
		search_path = []
	
	for p in ["/lib", "/usr/lib"]+search_path:
		if os.path.exists(os.path.join(p, lib+".so")):
			return LoadLibrary(os.path.join(p, lib+".so"))

Maintenant, il n'y a plus qu'à tester os.name et agir en conséquence (j'avoue que je 'lai pas fait parce que je connais pas trop RiscOS, OS/2 et autres systèmes gérés par Python...). Ca m'a pris plus de temps taper le message que le code :) (c'est la faute à templeet...)

D'ailleurs, ça marche pas non plus avec QtParted sous KDE par exemple ;)

Non, sur http://starship.python.net/crew/theller/ctypes/ il est bien écrit:
> ctypes allows to call functions exposed from dlls/shared libraries
(sous-entendu: n'importe quelle librairie)

Dans le tutorial, tu as un exemple avec /lib/libc.so.6... Rien à voir avec COM ou ActiveX ;)

> [DllImport("opengl")]
> public static extern void FonctionNative(string arg1, int arg2);
> C'est intégré au langage, c'est compilé en code managé, c'est donc portable sans modification et sans avoir à utiliser le langage intermédiaire.

http://wikipython.flibuste.net/moin.py/CodeWindows#head-3508(...)
Contrairement à ce qui est annoncé, c'est pas limité à l'API Windows. C'est pas véritablement intégré au langage, mais c'est pas non plus plus complexe que ton truc ;) (je trouve même là syntaxe plus propre - mais c'est strictement subjectif, c'est juste que j'ai été traumatisé à vie par la syntaxe [Truc(bidule)] par l'API windows ;)...)

C'est un binding ça, non ? Je pense que les langages ne supportant pas ça sont plus rares que ceux qui les supportent ;)

>>> Appels bibliothèques natives multi-plateforme et intégré au langage
>>> en python aussi ... non ? ;-)
>> Non. Ou alors j'ai jamais vu. ...
>os, string, ... bref toutes les libs faisant partie de "python" (les batteries included, et il y en a pas mal ...)

Je pense qu'il pensait plutôt à une sorte de dlopen. Et oui, c'est possible (à tout hasard, le module dl ? :)). Par contre multiplatforme je vois pas comment c'est possible, vu que les libs natives ne le sont pas... Oui alors c'est moi qui n'ait rien compris ;)

Si tu veux VRAIMENT un dico, un petit assert(type(dico) == dict) au début de la fonction devrait faire l'affaire ;)

J'ai pas mon prog sous la main (je l'ai pas avant Noel d'ailleurs), donc me demande pas de me souvenir des fonctions de GTK que j'utilisais ;)
Pour le principe, c'était simplement que lorsque la fenêtre intérieure bougeait, les coordonnée actives du treeview changeaient aussi (j'utilise surement pas le bon vocabulaire, désolé...). Il y a un callback pour surveiller cet événement. Dès que ces coordonnées changent:
- je retire le premier élément (il y a une fonction pour obtenir un élément à partir de ses coordonnées), et le replit
- je remplit l'élement suivant tant qu'il est dans la zone d'affichage (en calculant ses coordonnées)
Ca nécessite uniquement de connaitre la position de l'élément. Je dois l'avouer que ça, je l'ai fait "à l'arrache" (j'ai fais une colonne invisible "position" et je la remplissait dès le dépliage de l'élément parent). Il y avait sûrement plus rapide avec les fonctions de GTK, mais je venais de passer deux jours dans la doc pour réaliser ce que je te décrit, j'en avais marre ;)

Tu peux compiler un script python en bytecode Java (Jython) ou .Net (utilisable avec Mono bien sûr) avec IronPython (qui me semble légèrement mort en passant), mais je vois pas l'intérêt sous un système d'exploitation correct. Pour le système d'exploitation pas correct (désolé, la fatigue, toussa, on fait plus attention aux trolls), ya py2exe. Je sais que pygtk fonctionne avec py2exe, je crois que wxpython aussi (donc logiquement pyqt aussi), mais je sais pas comment ça se passe avec IronPython/Jython (tu peux bien sûr utiliser respectivement Swing/AWT/SWT et GTK#/WinForms, mais dans ce cas tu pourras plus utiliser ton programme dans un autre envitonnement comme CPytohn (le standard). Si tu fais du Swing/AWT/SWT, t'obliges l'utilisation de Jython, idem pour GTK# et IronPython. Quoique GTK# et pygtk ont peut être une API semblable, j'ai jamais touché à GTK#)

Mon avis personnel: Python + PyGTK permet de faire des chose vraiment étonnantes en quelques lignes de code avec un peu d'entraînement. Sous Linux, c'est relativement rapide (tu vas pas faire une application de calculs dessus, mais pour une application "normale", c'est largement suffisant). Sous Windows, tu as py2exe pour failiter la distribution. Bref, c'est le pied
J'ai également pendant un moment fait du GTK(mm/+)/C++, mais une fois que tu as goûté à la souplesse du python, tu ne peux plus t'en passer.

Pour être totalement subjectif, je vais te raconter mon expérience. J'ai eu à faire (pour besoins personnels) une application qui comportait un TreeView structuré de cette manière: 4-5 éléments de base qui contient chacun 1000 éléments fils qui contienent chacun 10 éléments fils. Soient 50 000 élements. J'ai commencé en GTK+/C++ par la méthode bourrin: on remplit tout d'un coup, et on laisse GTK+ se débrouiller avec le dépliage et toussa. Ca ramait à mort, et ça bouffait toute la RAM. Je me suis dit que je devrais calculer uniquement les éléments fils lors du dépliage. Ca ramait environ 2-3 secondes pour les gros dépliages (quand je dit que chaque racine à 1000 éléments, c'est très hétérogène: une en a 500, une autre 3000), mais c'était correct. Mais c'était ingérable en fait. Puis je suis passé en Python+PyGTK et je me suis dit "vu comment ça rame en C++, ça va pas être utlisable". Mais j'ai quand même essayé. Et là ça a été la révélation: grâce à la souplesse de Python, j'ai pu faire en sort que le calcul des sous-éléments se fasse uniquement lors de l'affichage [1]. En fait, contre la lenteur de Python, j'ai largement gagné par le fait que sa souplesse me permettait une architecture très peformante (en C++, ça aurait été facilement 5x plus de classes, méthodes, lignes de codes et erreurs possibles; en C, n'en parlons pas ;)). Ca ne ramait pas au démarrage, quelques millisecondes (à peine visble) aux énormes dépliages (en fait, je me suis permis 10 000 sous éléments et ça a pas ramé plus d'une demi-seconde). Ca saccadait légèrement lorsqu'on descendait rapidement, mais c'était tout.


[1] En entrant dans les détails techniques, je possédais un fichier XML à parser, possédant 5 gros éléments, qui possédaient quelques milliers de sous éléments (variable, de 500 à 10 000 en fait ;)) (qui eux même possédaient des sous éléments, mais ça n'a pas grande importance).
Première architecure: on parse tout, on fait tout dans le TreeView, et basta (ça rame horriblement au démarrage, et je vous explique pas l'occupation mémore...)
Seconde (C++): dès qu'on déplie on élément, alors seulement on crée ses éléments fils. Lorsqu'il y a 500 elems ça va, mais dès qu'on dépasse les 2000, ça rame. Et c'est déjà "lourd" de faire comme ça en C++
Troisième (Python): on dépliant un élément, on lui ajoute le nombre de fils qu'il possède (connus), mais vides: pas la peine de parser et de tout replir. On remplit que ce qui n'est visible, et lorsque la vue change (on scrolle, on redimensionne la fe,être), on renseigne les éventuels nouveaux éléments. Inmaintenanble en C++, une 100aine de lignes en Python, et drolement efficace pour un langage interprété...


Bon, j'arrête là de m'étaler

ls | grep -v '^mon_fichier.txt$' | xargs rm
Ca résoud pas le pb de l'espace, mais ça marche pour .mon_fichier.txt~ ^^