Il faut aussi se rendre compte que glander est un acte citoyen. Si je bossais vraiment à fond, je ferais l'équivalent du boulot de 5 personnes, disons 3, si j'y vais cool. Donc le fait de glander permet à au moins 2 autres personnes d'avoir un emploi.
J'ai pas tout compris non plus, mais si tu veux un truc sous IE qui ressemble a ce que je vois sous moz, faudrait enlever les lignes suivantes à partir des dépêches :
<div style="clear: both;"></div>
Ca m'etonne meme que ca passe sous mozilla. Mon explication serait que comme la boîte est vide, mozilla ignore tout simplement la boîte.
L'attribut clear sert à forcer les côtés vides. Si tu mets clear:both sur un div, ce div n'aura rien, ni à sa droite, ni à sa gauche. Donc il le mettra en dessous de ce qui précède. Les divs qui suivent seront forcément après celui-ci, i.e. soit en dessous soit après (sauf utilisation du float).
Cela dit, mettre un div vide comme ça, c'est très très laid, surtout s'il n'a pas de classe/id, ça n'a pas de sens dans le contenu.
Je crois que tu peux compiler les fichiers c++ avec gcc aussi. gcc fait la distinction selon l'extension du fichier, pour savoir s'il doit compiler en C ou en C++. C'est écrit quelque part dans la man page.
Je crois pas que t'aies bien lu mon post. J'ai bien souligné mon erreur d'expression, loin de moi l'idée de vouloir fusionner les libs, c'est débile.
Quand je parle de la modularité, je parle de l'environnement gnome, et non pas des modules indépendants de gnome. Prenons l'exemple de la libesd, on ne peut s'y soustraire, on ne peut la remplacer. Pour moi c'est pas modulaire au sens ou tu peux débrancher tel partie, pour la remplacer par un autre module, on en rajouter un autre. Il est clair que Gnome n'est pas modulaire. Par contre, et c'est encore heureux, les différents composants, entre autres, les libs, sont modulaires, tu peux, comme tu le dis utiliser l'une ou l'autre avec plus ou moins d'indépendance.
Moi ce qui m'intrigue, et c'est surtout ça le problème, en prenant ton exemple c'est que dans debian :
mon gnome terminal depend directement de libgnome, bonobo, gnomevfs, orbit ...
Alors que pour moi, ca me paraitrait plus logique que gnome terminal depende que de libgnome et que libgnome depende de bonobo, gnomevfs, ...
Maintenant, je pense que c'est peut-être un problème au niveau de la distribution(debian) qui n'est pas explicite au niveau de la hiérarchie des dépendances, et non pas du projet gnome mais bon j'en sais rien du tout.
Pour répondre aussi à la personne au-dessus, comme je l'ai souligné, c'est purement personnel comme impression, et je le sais très bien.
Moi je vois quelques dizaines de libs (atk, art, bonobo, freetype, gconf, ice, orbit, ...) utilisées par les applis gnome (le terminal, evolution, le panel, nautilus, ...). Alors je me dis, pourquoi n'ont-il pas fait un framework commun qui "wrap" tout ça ? Je me suis mal exprimé, au temps pour moi, mais ce que je veux dire c'est que j'aurai vu plutôt un truc qui "englobe" toutes les libs (et non pas fusionner toutes les libs en une seule). On aurait alors : appli gnome -> framework gnome -> libs (gtk, gnome, pango, etc), plutôt qu'un accès direct aux libs. Les libs restants accessibles de manières indépendantes, mais on ne serait plus dans le projet Gnome.
Alors y'a plusieurs raisons possibles, entre autres si on a pas besoin de tout, on utilise que ce dont on a besoin, par exemple j'ecris une appli gnome qui n'utilise pas de son, je ne depend pas de libesd. Mais si les applis sont faites pour tourner sous gnome, les dépendances, utiles ou inutiles, seront de toutes façon installées, et le framework commun prend tout son sens.
Tout ça pour dire que les dépendances reflètent pas vraiment le "tout" que constitue l'environnement gnome. On a l'impression que ça peut être modulaire, mais en fait non, c'est simplement que la couche "framework gnome" est totalement éludée, mais elle existe de manière abstraite.
Ouais tout à fait d'accord pour l'intégration. Mais voilà, pour moi soit tout est intégré, et ça n'a pas de sens de faire 36000 paquets séparés, on en fait un gros. Comme dit c'est personnel, mais j'aime pas voir le libesd là au milieu de nul part à cause d'un malheureux beep. Tu me diras, y'a les meta paquets pour ça, enfin bon c'est autant un problème de distribution/paquetage que de gnome avec toutes ses libs séparées.
Sous debian, gnome-terminal depend directement de libesd alors que moi j'aurais plutôt vu, dans l'optique intégration, une dépendance du genre gnome-terminal->framework de gnome->libesd. Y'a une nuance.
En fait, tu veux une appli Gnome sans Gnome.
Pas tout à fait. C'est plutôt que si c'est une option, en plus de proposer la désactivation (esd en l'occurence), proposer aussi la desinstallation en sus. Ca resterait intégré d'un point de vue global quoi. Moi Gnome, je l'ai toujours utilisé sans son, mais j'ai toujours eu esd d'installé à cause de ça. Sinon à ce rythme, on se retrouve avec un système monolithique qui prend 1.5Go sur le disque pour peut-être 10% d'utile selon les personnes, comme XP...
Enfin bon, Gnome prend effectivement une orientation qui ne correspond plus à mes besoins.
Pour gnome-terminal :
- les tabs
- les polices lissées
- multi-langues (nécessaires pour xjdic)
- la transparence (les trucs eye-candy c'est super utile)
- le paramétrage facile (couleurs, tailles, polices).
Cela dit, Konsole fait ça aussi très bien, d'ailleurs j'ai remis des raccourcis de konsole (shift + fleche gauche/droite) dans mon gnome-terminal. C'est juste que Konsole, c'est completement dépareillé dans xfce :D (et il a l'air de chier pour la transparence aussi).
gnome-session-properties, vires nautilus, sauves la session.
ou
"killall nautilus", lance un autre vm, puis sauve la session.
T'as essayé ? Non parce que chez moi vas-y pour récupérer un background décent après. Sur la 2.0, la 2.4 et la 2.6, soit il perd le wallpaper, soit il le vire, puis il réapparaît comme par magie, soit il le met, mais les transparences des applis marchent plus, ... T'es obligé de faire un gros hack pour que ca marche (dans gconf ou avec xsetroot, enfin sur la 2.6 j'en avais tellement ras-le-bol de le refaire en plus ça marchait pas que je suis passé a xfce)
Gnome-terminal utilise plein de truc, donc il y a plein de dépendances. Voilà, c'est tout. Si tu mets tout dans une librairie, ça change rien (apt sera moins "verbeux" et c'est tout).
J'ai dit que c'était un avis personnel. Mais franchement, un terminal, ca demande pas 36000 dépendances. Si c'était modulaire comme moi je le pense, les 3/4 des dépendances devraient être optionnelles. Si j'ai pas envie d'utiliser le gnome-control-center ni d'avoir du son avec esd, je vois pas pourquoi je devrais être obligé de les installer pour utiliser gnome-terminal. C'est surtout ça le fond de ma critique.
Puis si tu veux n'utiliser que glib, libxml et Orbit tu peux. T'es pas obligé d'installer gtk+, gnomelib, bonobo...
En ce sans c'est modulaire. C'est pas modulaire dans le sens :
- les programmes du bureau Gnome doivent utiliser le moins de fonctionnalité Gnome.
Comme dit, je suis d'accord, mais ils ne devraient pas y être obligés.
hum, d'habitude ils sortent les sources toujours un peu après les binaires (nettoyage des sources et paquetage). Enfin sur la 3.6 j'ai pas suivi non plus.
Je suis assez d'accord avec toi sur ce sujet. Moi j'ai commencé sous Enlightenment (après win98), puis je suis passé à gnome 2.0 à la sortie, avec la 2.6 j'ai laissé tomber, je suis passé à xfce.
Ce que je reproche à gnome : même si l'orientation grand public ne me plaît pas, c'est surtout l'opacité du soft qui a fini par m'énervé. Un truc simple : je voulais virer nautilus de mon bureau, je n'avais pas une grosse machine et je me servais jamais des icones du bureau ni de nautilus. J'ai jamais réussi (c'est surement faisable mais j'ai quand même passé beaucoup trop de temps là-dessus). J'ai jamais non plus réussi a trouver un truc similaire au systray qui marche, je suis surement pas très doué, mais je pense que les gens qui me connaissent savent que si j'y arrive pas c'est qu'il y a vraiment un problème.
Ensuite on s'attend à quelque chose de similaire a windows/kde/macOS/je-sais-pas-quoi. C'est vrai, on s'attend à ça, et c'est vraiment ce qu'on voit en premier, et donc si on retrouve pas ce à quoi on s'attend, on est perdu. Autant Enlightenment ou xfce était radicalement différent, j'ai eu à m'adapter, mais quand le bureau se présente, on voit tout de suite que c'est différent. Quand tu démarre KDE, tu t'attends à retrouver un windows-like, et c'est vrai, c'est un windows-like. Voilà le problème. Alors ils faudraient qu'ils se démarquent vraiment des autres ou qu'ils fassent comme les autres, mais pas entre les 2.
Enfin les dépendances des modules à la con de gnome. En passant à xfce, j'ai pas trouvé de console mieux que le gnome-terminal que j'avais pris l'habitude d'utiliser. Donc j'ai voulu le remettre. Ca m'a pris autour de 50 mega (debian) avec 50 dépendances à la con, en gros j'avais l'impression de reinstaller entierement gnome sauf les quelques trucs en fin de chaine. Alors la modularité, oui, mais c'est tellement entrelacé qu'au final on est obligé de tout avoir, et à ce moment là autant faire une seule lib mais c'est un avis personnel.
Tout ça pour dire que mon expérience de gnome me laisse un souvenir assez mitigé. Si l'on veut se limiter à un usage débutant/classique, et baisser les bras dès qu'on veut faire un truc un peu plus exotique gnome convient très bien, mais son évolutivité par rapport aux utilisateurs qui acquierent de l'expérience est, il me semble, vraiment très limitée.
Allez, si tu veux vraiment un standard utilise la norme ISO 8601 :). C'est pas ce qu'il y a de plus pratique ni de plus efficace, mais c'est ce qu'il y a de plus neutre. Par contre la description laisse beaucoup de liberté, donc ca demande du traitement supplémentaire.
j'sais pas là j'ai quelques liens (google powah) qui y font référence sous mandrake mais bon ça a plus l'air d'être une feature en +. Tiens bah on y fait même référence dans un commentaire de cette astuce : http://linuxfr.org/tips/99.html(...)
update-alternatives --config x-www-browser
Sous debian, ça fonctionne comme ça chez moi. Les applis par défaut sont répertoriées dans /etc/alternatives, grâce à des liens symboliques vers les différentes applis. Le lien x-www-browser pointe sur mon browser par défaut sous x (firefox) J'ai aussi un lien mozilla, si j'ai plusieurs mozilla d'installés. update-alternatives est l'outil pour gérer tout ça.
Enfin bon, je sais pas du tout si c'est pareil sous Mandrake...
Question subsidiaire : je me demande si on peut avoir des alternatives différentes pour chaque utilisateur... je vais méditer ça.
Je chipote, mais je crois que tu confonds les notions de RAD et d'IDE. Un IDE (integrated development environment) n'est qu'un environnement qui regroupe tous les outils nécessaires pour développer un logiciel. KDevelop, Anjuta, voire Emacs sont des IDE. A la limite, on pourrait dire qu'une console, avec les outils pour éditer et compiler, est un IDE.
Les RAD (rapid application development) sont un "sous-groupe" des IDE, qui permettent de développer facilement et rapidement des applications, genre Visual Basic, ou gambas, en général au détriment des performances.
L'auto-complétion n'est qu'un outil parmi d'autres de l'environnement. Personnellement, je ne m'en sers jamais, je code plus souvent en C++, et vaut mieux connaître les APIs sur le bout des doigts pour pas faire de conneries.
PS : t'aurais aussi besoin de la complétion orthographique :).
> en quoi c'est un pb de faire passer mutt par le serveur imap ?
C'est pas un problème, c'est pour éviter d'avoir a taper le mot de passe :p. Tout le monde sait que l'informaticien est fainéant. Cela dit, avec ou sans IMAP, la boîte rend pareil sous mutt.
Enfin, j'ai peut-être pas été assez clair, mais c'est plutôt sur l'utilisation de mutt que je posais mes questions. Le reste, j'ai pas regardé en détails vu que ça marche comme je veux.
Pour le mot de passe différent, en fait tu utilises un autre compte unix (ldap au lieu de celui du user) c'est ça ? J'imaginais plutôt un système de mot de passe à part, mais bon, je suis pas un spécialiste.
Tiens c'est nouveau ça, sûrement la fameuse réforme de l'enseignement :). D'mon temps (y'a 1 an), la sécurité informatique à l'ENST Bretagne, c'était plutôt le minimum syndical... Le seul cours intéressant avait été donné par un prof de Supelec Rennes, où ils ont(avaient ?) un labo sur la sécurité informatique. Ah si y'avait un cours de maths assez intéressant sur la crypto aussi, mais ça restait assez basique.
Enfin bon, je garde un souvenir assez mitigé sur ce point là, ça reste pour moi une école généraliste en télécoms, de loin pas une école d'informatique.
bah comme je dis en dessous, c'est surtout les méandres du midi qu'il faut comprendre, et ça peut t'être utile par la suite. Les softs synth sont qu'une petite partie du problème. J'ai acheté une sblive par convenance parce que :
- j'en avais marre de ne pouvoir jouer qu'un seul son à la fois à moins d'utiliser artsd ou esd. Le premier bouffe des ressources, le 2e chie souvent lors des evenements (play/stop)
- le son du soft synth faisait trop pitié. Cela dit si t'as un synthé vaut mieux l'utiliser plutôt que le soft synth ou le synthé de la sblive.
- ça coutait pas cher
Enfin bon, je pense quand même que réussir à faire marcher un soft synth peut être formatteur pour la suite dans l'utilisation du midi, par exemple brancher la sortie midi du pc sur ton synthé.
Sinon, quand t'auras réussi à faire marcher tout ça, sache que l'interface de RoseGarden est pas des plus intuitives (enfin si on veut faire des trucs avancés) mais la doc est très bien faite et très progressive. J'avais bossé avec pour commencer des travaux de transcription, mais c'est devenu rapidement lourd de noter les notes une par une à la souris alors j'ai laissé tombé, en attendant de me payer un vrai clavier midi :).
Enfin bon, à mon avis le plus dur dans tout ça c'est surtout de comprendre le fonctionnement de MIDI (les ports, les connexions entre port IN/OUT/THRU). Quand on a assimilé ca, la configuration du foutoir devient limpide.
Alors pour timidity j'en avais chié grave aussi, mais j'ai pas les pointeurs sous la main.
Sous debian, y'a un paquet, et un autres avec les soundfonts (je sais pas si le terme est juste), donc timidity et timidity-patches.
T'as besoin du deuxème pour avoir du son. Y'a aussi un fichier de conf dans /etc/ mais ma debian avait fait la conf comme il faut.
Après y'a des commandes obscures pour lancer des fichiers midi vers timidity, j'ai retrouvé cette vieille ligne de shell : timidity -iA -B2,8 -Os -EFreverb=0
Alors ça me servait a lancer timidity et à obtenir un son acceptable (genre playskool) sur mon chipset via686a (ou un truc du genre).
Après avec pmidi, on peut récupérer des infos sur les ports midis : inz% pmidi -l
Port Client name Port name
64:0 EMU10K1 MPU-401 (UART) - Rawmi EMU10K1 MPU-401 (UART)
65:0 Emu10k1 WaveTable Emu10k1 Port 0
65:1 Emu10k1 WaveTable Emu10k1 Port 1
65:2 Emu10k1 WaveTable Emu10k1 Port 2
65:3 Emu10k1 WaveTable Emu10k1 Port 3
Normalement avec timidity ca crée des ports 128:0 et quelques. Ensuite tu peux tester si ton soft synth marche avec : pmidi -p128:0 fichier.mid pour jouer le fichier midi. A ce point là tu dois avoir du son qui sort, sinon y'a une merde.
Si la ça marche, c'est que ton soft synth est en place. Après faut magouiller pour connecter ton soft synth au sequencer, ca se fait avec aconnect/aconnect-gui pour pouvoir l'utiliser dans les softs comme RoseGarden quoique je crois que c'est pas obligatoire pour RoseGarden, qui doit pouvoir gérer des sorties midi multiples.
Tout ça bien sûr, c'est pour alsa (aconnect = ALSA sequencer connection manager). Ah ouais j'oubliais, je crois que faut aussi un module alsa spécifique à l'émulation midi pour les softs synths pour créer des dummy ports ou un truc du genre.
Voilà, j'essaierai de voir ce soir chez moi comment j'avais fait (là je suis en ssh depuis le taf, alors je peux pas tester grand chose :D ).
Accessoirement le codeur de RoseGarden fait référence à un autre soft synth (y'en a d'autres que timidity), j'ai pas testé, enfin au final, je me suis payé une sblive à pas cher :).
J'ai rien trouvé d'autres de plus abouti, et RoseGarden se rapproche de ce que tu peux trouver sur les autres plate-formes (Windows, ou Amiga). J'ai eu l'occasion dans ma jeunesse de faire de la création sur un synthé avec un amiga avec mon prof de musique au collège, et l'interface de RoseGarden est assez similaire.
Apparemment tu peux intégrer des tracks wav dans tes compos dans RoseGarden, mais si tu veux faire du traitement directement sur la musique (rythmes, editer les notes, transposer, etc) t'es obligé de passer par du MIDI.
Perso, je pense que RoseGarden est bien fait pour faire de la compo assistée par ordinateur, et éventuellement sortir des partitions pour après les interpréter en acoustique. Par contre, je pense que si tu veux faire uniquement un assemblage de pistes son genre regrouper plusieurs instruments, ajuster les volumes, jouer/chanter/enregistrer par dessus la musique, et ne pas toucher au détail du contenu, je pense que y'a d'autres outils plus orientés sur ce point (quoique RoseGarden doit le faire aussi dans une certaine mesure) mais là j'y connais rien.
Si tu comptes faire de la musique/compo "classique", j'ai pas trouvé mieux que RoseGarden non plus. Je suis pas un spécialiste mais je crois qu'il y a aussi des outils pour les musiques plus électroniques, pour faire par exemple de la techno, sampling et tout ça.
En effet, Rosegarden fonctionne sur du MIDI, mais cela n'oblige pas à avoir un instrument. Comme tu as l'air d'avoir une carte son bien pourrie, je pense que tu n'as pas de synthé MIDI intégré à ta carte, donc il te faudra utiliser un soft synth, comme timidity par exemple, pour pouvoir faire sortir quelque chose. En gros, avant de pouvoir utiliser RoseGarden, faut dejà que tu puisses lire du MIDI, si ça ça marche, après il suffit de brancher RoseGarden sur ton soft synth.
En général, le port joystick de la CM est un port MIDI, et il te faut un adaptateur port joy->prise MIDI, pour brancher ton synthé. Je sais pas où ca se trouve, surement dans des boutiques spécialisées, mais j'en ai déjà vu.
Pour les cartes plus pros, j'y connais rien, mais la sound blaster live à un synthé hardware, ca evite d'utiliser le soft synth, enfin moi j'en avais acheté une vu que ca vallait plus rien (30 euros en france).
Bon je dis pas grand chose, mais j'ai pas encore de synthé alors j'ai pas pu approfondir le truc :(.
Le truc, c'est que faut pas t'attendre à apprendre le C++ avec l'utilisation d'une lib comme ogre, parce que la communauté et les ressources sont réduites et spécialisées.
Sur ce genre de sujet, tu auras plus souvent des "manières" de résoudre le problème, plutôt qu'une démonstration pas à pas. Donc entre un code visual C++ et un code pour g++, la différence est purement structurelle (makefile, organisation des fichiers,...), et quelqu'un qui s'y connaît un peu en C++ saura quoi copier et quoi modifier, et ce assez rapidement.
L'API ogre est la même que ce soit sous visual C++ ou nux, donc les lignes de code spécifiques aux problèmes 3D seront les mêmes. Le seul problème que tu rencontreras sera les paths des include et des libs, les commandes et paramètres de compilation, rien de plus.
Gedit ça me paraît un peu léger pour coder, enfin tu me diras, moi je code pas mal sous vim aussi ;). En revanche, j'ai trouvé KDevelop très pratique, il gère bien les automake/autoconf et l'arbre des sources.
Si tu veux trouver d'autres moteurs. Les features sont listées ça permet de comparer rapidement (et on peut filtrer la recherche).
C'est marrant parce que je me suis posé la même question que toi y'a pas si longtemps.
Perso, je comptais aussi faire du code avec un moteur 3D, et je me suis décidé pour ogre mais j'ai pas encore eu le temps de m'y mettre.
Ton choix doit se faire selon tes capacités et tes besoins. Comme j'ai déjà eu l'occasion de réfléchir à la question, je vais te donner, de tête, les pour et contre des 2 moteurs.
- je voulais l'import à partir de blender, ce sont les 2 seuls moteurs libres qui le font.
- ogre, c'est qu'un moteur 3D, avec les IO de base. Tu seras obligé, si tu veux du son, d'aller utiliser d'autres libs, on voit d'ailleurs beaucoup de projet intégrant ogre et fmod (pas libre), ou openAL (libre). En revanche, CS intègre beaucoup de features et de plugins (en particulier les plugins pour le son et scripting).
- CS est donc un framework complet pour faire un jeu
- je trouve que CS est pas super accessible, même si le tutorial de la doc est bien fait (API assez obscure). D'ailleurs, je me suis noyé dans le tuto de CS, c'est pour ça que j'ai laissé tomber. En plus la version actuelle a subi des grosses refontes dans l'API, alors beaucoup de bout de code de tutos ne seront plus valide. Mais j'ai pas non plus regardé en détail l'API d'ogre.
- le rendu graphique(*) de CS a pas l'air génial (cf demos), mais j'ai pas une bécane de la mort dernier cri aussi.
- CS existe en paquets debian officiel. Pour ogre, faudra le compiler à partir des sources (bonne chance si t'a une NVidia).
- la compilation d'ogre prend à peu près 1 giga d'espace disque (ouille ça fait mal sur mon petit dd)
- ils existent des jeux commerciaux basés sur ogre.
- les démos d'ogre déchirent plus que celles de CS mais cet argument est fallacieux vu que j'ai vu les dernières démos d'ogre, et seulement celles des paquets debian pour CS. (le tout sur un athlon 700 avec geforce 2mx)
De mémoire (à vérifier donc), ogre a été pensé dès le début multiplatforme. CS a l'antériorité (plus vieux = plus mature?). Mais ils n'ont pas non plus les même objectifs (cf arguments ci-dessus).
(*) je viens de voir les dernier screenshots (ils ont refait le moteur de rendu je crois), ça a l'air pas mal.
# La glande c'est social
Posté par inz . En réponse au journal La belle corinne est une rebelle. Évalué à 6.
[^] # Re: Euh, c quoi le pbm en fait ?
Posté par inz . En réponse au message Pb CSS et clear:both;. Évalué à 2.
<div style="clear: both;"></div>
Ca m'etonne meme que ca passe sous mozilla. Mon explication serait que comme la boîte est vide, mozilla ignore tout simplement la boîte.
L'attribut clear sert à forcer les côtés vides. Si tu mets clear:both sur un div, ce div n'aura rien, ni à sa droite, ni à sa gauche. Donc il le mettra en dessous de ce qui précède. Les divs qui suivent seront forcément après celui-ci, i.e. soit en dessous soit après (sauf utilisation du float).
Cela dit, mettre un div vide comme ça, c'est très très laid, surtout s'il n'a pas de classe/id, ça n'a pas de sens dans le contenu.
# trickle
Posté par inz . En réponse au message Limitation de bande passante. Évalué à 3.
http://monkey.org/~marius/pages/?page=trickle(...)
C'est même portable d'après le site.
# auto detection ?
Posté par inz . En réponse au message Eclipse et projet C ET C++. Évalué à 2.
[^] # Re: ho sigh, windows...
Posté par inz . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 1.
Quand je parle de la modularité, je parle de l'environnement gnome, et non pas des modules indépendants de gnome. Prenons l'exemple de la libesd, on ne peut s'y soustraire, on ne peut la remplacer. Pour moi c'est pas modulaire au sens ou tu peux débrancher tel partie, pour la remplacer par un autre module, on en rajouter un autre. Il est clair que Gnome n'est pas modulaire. Par contre, et c'est encore heureux, les différents composants, entre autres, les libs, sont modulaires, tu peux, comme tu le dis utiliser l'une ou l'autre avec plus ou moins d'indépendance.
Moi ce qui m'intrigue, et c'est surtout ça le problème, en prenant ton exemple c'est que dans debian :
mon gnome terminal depend directement de libgnome, bonobo, gnomevfs, orbit ...
Alors que pour moi, ca me paraitrait plus logique que gnome terminal depende que de libgnome et que libgnome depende de bonobo, gnomevfs, ...
Maintenant, je pense que c'est peut-être un problème au niveau de la distribution(debian) qui n'est pas explicite au niveau de la hiérarchie des dépendances, et non pas du projet gnome mais bon j'en sais rien du tout.
[^] # Re: ho sigh, windows...
Posté par inz . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 3.
Pour répondre aussi à la personne au-dessus, comme je l'ai souligné, c'est purement personnel comme impression, et je le sais très bien.
Moi je vois quelques dizaines de libs (atk, art, bonobo, freetype, gconf, ice, orbit, ...) utilisées par les applis gnome (le terminal, evolution, le panel, nautilus, ...). Alors je me dis, pourquoi n'ont-il pas fait un framework commun qui "wrap" tout ça ? Je me suis mal exprimé, au temps pour moi, mais ce que je veux dire c'est que j'aurai vu plutôt un truc qui "englobe" toutes les libs (et non pas fusionner toutes les libs en une seule). On aurait alors : appli gnome -> framework gnome -> libs (gtk, gnome, pango, etc), plutôt qu'un accès direct aux libs. Les libs restants accessibles de manières indépendantes, mais on ne serait plus dans le projet Gnome.
Alors y'a plusieurs raisons possibles, entre autres si on a pas besoin de tout, on utilise que ce dont on a besoin, par exemple j'ecris une appli gnome qui n'utilise pas de son, je ne depend pas de libesd. Mais si les applis sont faites pour tourner sous gnome, les dépendances, utiles ou inutiles, seront de toutes façon installées, et le framework commun prend tout son sens.
Tout ça pour dire que les dépendances reflètent pas vraiment le "tout" que constitue l'environnement gnome. On a l'impression que ça peut être modulaire, mais en fait non, c'est simplement que la couche "framework gnome" est totalement éludée, mais elle existe de manière abstraite.
[^] # Re: ho sigh, windows...
Posté par inz . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 2.
Sous debian, gnome-terminal depend directement de libesd alors que moi j'aurais plutôt vu, dans l'optique intégration, une dépendance du genre gnome-terminal->framework de gnome->libesd. Y'a une nuance.
En fait, tu veux une appli Gnome sans Gnome.
Pas tout à fait. C'est plutôt que si c'est une option, en plus de proposer la désactivation (esd en l'occurence), proposer aussi la desinstallation en sus. Ca resterait intégré d'un point de vue global quoi. Moi Gnome, je l'ai toujours utilisé sans son, mais j'ai toujours eu esd d'installé à cause de ça. Sinon à ce rythme, on se retrouve avec un système monolithique qui prend 1.5Go sur le disque pour peut-être 10% d'utile selon les personnes, comme XP...
Enfin bon, Gnome prend effectivement une orientation qui ne correspond plus à mes besoins.
Pour gnome-terminal :
- les tabs
- les polices lissées
- multi-langues (nécessaires pour xjdic)
- la transparence (les trucs eye-candy c'est super utile)
- le paramétrage facile (couleurs, tailles, polices).
Cela dit, Konsole fait ça aussi très bien, d'ailleurs j'ai remis des raccourcis de konsole (shift + fleche gauche/droite) dans mon gnome-terminal. C'est juste que Konsole, c'est completement dépareillé dans xfce :D (et il a l'air de chier pour la transparence aussi).
[^] # Re: ho sigh, windows...
Posté par inz . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 1.
ou
"killall nautilus", lance un autre vm, puis sauve la session.
T'as essayé ? Non parce que chez moi vas-y pour récupérer un background décent après. Sur la 2.0, la 2.4 et la 2.6, soit il perd le wallpaper, soit il le vire, puis il réapparaît comme par magie, soit il le met, mais les transparences des applis marchent plus, ... T'es obligé de faire un gros hack pour que ca marche (dans gconf ou avec xsetroot, enfin sur la 2.6 j'en avais tellement ras-le-bol de le refaire en plus ça marchait pas que je suis passé a xfce)
Gnome-terminal utilise plein de truc, donc il y a plein de dépendances. Voilà, c'est tout. Si tu mets tout dans une librairie, ça change rien (apt sera moins "verbeux" et c'est tout).
J'ai dit que c'était un avis personnel. Mais franchement, un terminal, ca demande pas 36000 dépendances. Si c'était modulaire comme moi je le pense, les 3/4 des dépendances devraient être optionnelles. Si j'ai pas envie d'utiliser le gnome-control-center ni d'avoir du son avec esd, je vois pas pourquoi je devrais être obligé de les installer pour utiliser gnome-terminal. C'est surtout ça le fond de ma critique.
Puis si tu veux n'utiliser que glib, libxml et Orbit tu peux. T'es pas obligé d'installer gtk+, gnomelib, bonobo...
En ce sans c'est modulaire. C'est pas modulaire dans le sens :
- les programmes du bureau Gnome doivent utiliser le moins de fonctionnalité Gnome.
Comme dit, je suis d'accord, mais ils ne devraient pas y être obligés.
[^] # Re: Ca n'est pas nouveau....
Posté par inz . En réponse au journal Sources de povray. Évalué à 3.
[^] # Re: ho sigh, windows...
Posté par inz . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 10.
Ce que je reproche à gnome : même si l'orientation grand public ne me plaît pas, c'est surtout l'opacité du soft qui a fini par m'énervé. Un truc simple : je voulais virer nautilus de mon bureau, je n'avais pas une grosse machine et je me servais jamais des icones du bureau ni de nautilus. J'ai jamais réussi (c'est surement faisable mais j'ai quand même passé beaucoup trop de temps là-dessus). J'ai jamais non plus réussi a trouver un truc similaire au systray qui marche, je suis surement pas très doué, mais je pense que les gens qui me connaissent savent que si j'y arrive pas c'est qu'il y a vraiment un problème.
Ensuite on s'attend à quelque chose de similaire a windows/kde/macOS/je-sais-pas-quoi. C'est vrai, on s'attend à ça, et c'est vraiment ce qu'on voit en premier, et donc si on retrouve pas ce à quoi on s'attend, on est perdu. Autant Enlightenment ou xfce était radicalement différent, j'ai eu à m'adapter, mais quand le bureau se présente, on voit tout de suite que c'est différent. Quand tu démarre KDE, tu t'attends à retrouver un windows-like, et c'est vrai, c'est un windows-like. Voilà le problème. Alors ils faudraient qu'ils se démarquent vraiment des autres ou qu'ils fassent comme les autres, mais pas entre les 2.
Enfin les dépendances des modules à la con de gnome. En passant à xfce, j'ai pas trouvé de console mieux que le gnome-terminal que j'avais pris l'habitude d'utiliser. Donc j'ai voulu le remettre. Ca m'a pris autour de 50 mega (debian) avec 50 dépendances à la con, en gros j'avais l'impression de reinstaller entierement gnome sauf les quelques trucs en fin de chaine. Alors la modularité, oui, mais c'est tellement entrelacé qu'au final on est obligé de tout avoir, et à ce moment là autant faire une seule lib mais c'est un avis personnel.
Tout ça pour dire que mon expérience de gnome me laisse un souvenir assez mitigé. Si l'on veut se limiter à un usage débutant/classique, et baisser les bras dès qu'on veut faire un truc un peu plus exotique gnome convient très bien, mais son évolutivité par rapport aux utilisateurs qui acquierent de l'expérience est, il me semble, vraiment très limitée.
# ISO
Posté par inz . En réponse au message Mais quel jour serons nous demain !!!. Évalué à 3.
Y'a aussi le sous-ensemble du w3 (iso-compatible) :
http://www.w3.org/TR/NOTE-datetime(...)
[^] # Re: Y'a ça sous Mandrake ?
Posté par inz . En réponse au message Ouvrir liens avec firefox, pas Mozilla. Évalué à 2.
http://linuxfr.org/tips/99.html(...)
# Y'a ça sous Mandrake ?
Posté par inz . En réponse au message Ouvrir liens avec firefox, pas Mozilla. Évalué à 3.
Sous debian, ça fonctionne comme ça chez moi. Les applis par défaut sont répertoriées dans /etc/alternatives, grâce à des liens symboliques vers les différentes applis. Le lien x-www-browser pointe sur mon browser par défaut sous x (firefox) J'ai aussi un lien mozilla, si j'ai plusieurs mozilla d'installés. update-alternatives est l'outil pour gérer tout ça.
Enfin bon, je sais pas du tout si c'est pareil sous Mandrake...
Question subsidiaire : je me demande si on peut avoir des alternatives différentes pour chaque utilisateur... je vais méditer ça.
[^] # RAD <> IDE
Posté par inz . En réponse au message Interface de programmation. Évalué à 2.
Les RAD (rapid application development) sont un "sous-groupe" des IDE, qui permettent de développer facilement et rapidement des applications, genre Visual Basic, ou gambas, en général au détriment des performances.
L'auto-complétion n'est qu'un outil parmi d'autres de l'environnement. Personnellement, je ne m'en sers jamais, je code plus souvent en C++, et vaut mieux connaître les APIs sur le bout des doigts pour pas faire de conneries.
PS : t'aurais aussi besoin de la complétion orthographique :).
[^] # Re: Mutt, IMAP et Maildir
Posté par inz . En réponse au message Mutt, IMAP et Maildir. Évalué à 2.
C'est pas un problème, c'est pour éviter d'avoir a taper le mot de passe :p. Tout le monde sait que l'informaticien est fainéant. Cela dit, avec ou sans IMAP, la boîte rend pareil sous mutt.
Enfin, j'ai peut-être pas été assez clair, mais c'est plutôt sur l'utilisation de mutt que je posais mes questions. Le reste, j'ai pas regardé en détails vu que ça marche comme je veux.
Pour le mot de passe différent, en fait tu utilises un autre compte unix (ldap au lieu de celui du user) c'est ça ? J'imaginais plutôt un système de mot de passe à part, mais bon, je suis pas un spécialiste.
# Normal
Posté par inz . En réponse au message CSS - Padding et Firefox 0.8. Évalué à 6.
[^] # Re: Ecole de sécurité ?
Posté par inz . En réponse au journal Ecole de Sécurité Informatique. Évalué à 3.
Enfin bon, je garde un souvenir assez mitigé sur ce point là, ça reste pour moi une école généraliste en télécoms, de loin pas une école d'informatique.
[^] # Re: timidity quick'n dirty howto
Posté par inz . En réponse au message Musique sous Linux ?. Évalué à 2.
- j'en avais marre de ne pouvoir jouer qu'un seul son à la fois à moins d'utiliser artsd ou esd. Le premier bouffe des ressources, le 2e chie souvent lors des evenements (play/stop)
- le son du soft synth faisait trop pitié. Cela dit si t'as un synthé vaut mieux l'utiliser plutôt que le soft synth ou le synthé de la sblive.
- ça coutait pas cher
Enfin bon, je pense quand même que réussir à faire marcher un soft synth peut être formatteur pour la suite dans l'utilisation du midi, par exemple brancher la sortie midi du pc sur ton synthé.
Sinon, quand t'auras réussi à faire marcher tout ça, sache que l'interface de RoseGarden est pas des plus intuitives (enfin si on veut faire des trucs avancés) mais la doc est très bien faite et très progressive. J'avais bossé avec pour commencer des travaux de transcription, mais c'est devenu rapidement lourd de noter les notes une par une à la souris alors j'ai laissé tombé, en attendant de me payer un vrai clavier midi :).
[^] # doc
Posté par inz . En réponse au message Musique sous Linux ?. Évalué à 2.
http://linux-sound.org/quick-toots/4-sequencers_and_softsynths/quic(...)
le howto (laborieux, à éviter) :
http://ftp.traduc.org/projets/howto/relecture/MIDI-HOWTO.html(...)
Le doc sur lequel je m'étais basé quand j'avais fait le truc (clair et concis) :
http://www.linuxfocus.org/Francais/September2002/article259.shtml(...)
Enfin bon, à mon avis le plus dur dans tout ça c'est surtout de comprendre le fonctionnement de MIDI (les ports, les connexions entre port IN/OUT/THRU). Quand on a assimilé ca, la configuration du foutoir devient limpide.
[^] # timidity quick'n dirty howto
Posté par inz . En réponse au message Musique sous Linux ?. Évalué à 3.
Alors pour timidity j'en avais chié grave aussi, mais j'ai pas les pointeurs sous la main.
Sous debian, y'a un paquet, et un autres avec les soundfonts (je sais pas si le terme est juste), donc timidity et timidity-patches.
T'as besoin du deuxème pour avoir du son. Y'a aussi un fichier de conf dans /etc/ mais ma debian avait fait la conf comme il faut.
Après y'a des commandes obscures pour lancer des fichiers midi vers timidity, j'ai retrouvé cette vieille ligne de shell :
timidity -iA -B2,8 -Os -EFreverb=0
Alors ça me servait a lancer timidity et à obtenir un son acceptable (genre playskool) sur mon chipset via686a (ou un truc du genre).
Après avec pmidi, on peut récupérer des infos sur les ports midis :
inz% pmidi -l
Port Client name Port name
64:0 EMU10K1 MPU-401 (UART) - Rawmi EMU10K1 MPU-401 (UART)
65:0 Emu10k1 WaveTable Emu10k1 Port 0
65:1 Emu10k1 WaveTable Emu10k1 Port 1
65:2 Emu10k1 WaveTable Emu10k1 Port 2
65:3 Emu10k1 WaveTable Emu10k1 Port 3
Normalement avec timidity ca crée des ports 128:0 et quelques. Ensuite tu peux tester si ton soft synth marche avec :
pmidi -p128:0 fichier.mid pour jouer le fichier midi. A ce point là tu dois avoir du son qui sort, sinon y'a une merde.
Si la ça marche, c'est que ton soft synth est en place. Après faut magouiller pour connecter ton soft synth au sequencer, ca se fait avec aconnect/aconnect-gui pour pouvoir l'utiliser dans les softs comme RoseGarden quoique je crois que c'est pas obligatoire pour RoseGarden, qui doit pouvoir gérer des sorties midi multiples.
Tout ça bien sûr, c'est pour alsa (aconnect = ALSA sequencer connection manager). Ah ouais j'oubliais, je crois que faut aussi un module alsa spécifique à l'émulation midi pour les softs synths pour créer des dummy ports ou un truc du genre.
Voilà, j'essaierai de voir ce soir chez moi comment j'avais fait (là je suis en ssh depuis le taf, alors je peux pas tester grand chose :D ).
Accessoirement le codeur de RoseGarden fait référence à un autre soft synth (y'en a d'autres que timidity), j'ai pas testé, enfin au final, je me suis payé une sblive à pas cher :).
[^] # Re: En fait
Posté par inz . En réponse au message Musique sous Linux ?. Évalué à 2.
Apparemment tu peux intégrer des tracks wav dans tes compos dans RoseGarden, mais si tu veux faire du traitement directement sur la musique (rythmes, editer les notes, transposer, etc) t'es obligé de passer par du MIDI.
Perso, je pense que RoseGarden est bien fait pour faire de la compo assistée par ordinateur, et éventuellement sortir des partitions pour après les interpréter en acoustique. Par contre, je pense que si tu veux faire uniquement un assemblage de pistes son genre regrouper plusieurs instruments, ajuster les volumes, jouer/chanter/enregistrer par dessus la musique, et ne pas toucher au détail du contenu, je pense que y'a d'autres outils plus orientés sur ce point (quoique RoseGarden doit le faire aussi dans une certaine mesure) mais là j'y connais rien.
# Quel type de MAO ?
Posté par inz . En réponse au message Musique sous Linux ?. Évalué à 4.
En effet, Rosegarden fonctionne sur du MIDI, mais cela n'oblige pas à avoir un instrument. Comme tu as l'air d'avoir une carte son bien pourrie, je pense que tu n'as pas de synthé MIDI intégré à ta carte, donc il te faudra utiliser un soft synth, comme timidity par exemple, pour pouvoir faire sortir quelque chose. En gros, avant de pouvoir utiliser RoseGarden, faut dejà que tu puisses lire du MIDI, si ça ça marche, après il suffit de brancher RoseGarden sur ton soft synth.
En général, le port joystick de la CM est un port MIDI, et il te faut un adaptateur port joy->prise MIDI, pour brancher ton synthé. Je sais pas où ca se trouve, surement dans des boutiques spécialisées, mais j'en ai déjà vu.
Pour les cartes plus pros, j'y connais rien, mais la sound blaster live à un synthé hardware, ca evite d'utiliser le soft synth, enfin moi j'en avais acheté une vu que ca vallait plus rien (30 euros en france).
Bon je dis pas grand chose, mais j'ai pas encore de synthé alors j'ai pas pu approfondir le truc :(.
[^] # Re: http://www.ogre-fr.net/
Posté par inz . En réponse au message Moteur 3D Ogre. Évalué à 2.
Sur ce genre de sujet, tu auras plus souvent des "manières" de résoudre le problème, plutôt qu'une démonstration pas à pas. Donc entre un code visual C++ et un code pour g++, la différence est purement structurelle (makefile, organisation des fichiers,...), et quelqu'un qui s'y connaît un peu en C++ saura quoi copier et quoi modifier, et ce assez rapidement.
L'API ogre est la même que ce soit sous visual C++ ou nux, donc les lignes de code spécifiques aux problèmes 3D seront les mêmes. Le seul problème que tu rencontreras sera les paths des include et des libs, les commandes et paramètres de compilation, rien de plus.
Gedit ça me paraît un peu léger pour coder, enfin tu me diras, moi je code pas mal sous vim aussi ;). En revanche, j'ai trouvé KDevelop très pratique, il gère bien les automake/autoconf et l'arbre des sources.
[^] # Re: http://www.3dengines.net/
Posté par inz . En réponse au journal Les moteurs 3D : CS vs Ogre. Évalué à 5.
http://www.happypenguin.org/newsitem?id=4583(...)
Le moteur de CS a été refait, donc mes quelques arguments sur la qualité graphique ne sont plus valables. Et CS existe depuis 1997.
Accessoirement, j'avais déjà répondu à ton message sur le forum c++.
# http://www.3dengines.net/
Posté par inz . En réponse au journal Les moteurs 3D : CS vs Ogre. Évalué à 9.
C'est marrant parce que je me suis posé la même question que toi y'a pas si longtemps.
Perso, je comptais aussi faire du code avec un moteur 3D, et je me suis décidé pour ogre mais j'ai pas encore eu le temps de m'y mettre.
Ton choix doit se faire selon tes capacités et tes besoins. Comme j'ai déjà eu l'occasion de réfléchir à la question, je vais te donner, de tête, les pour et contre des 2 moteurs.
- je voulais l'import à partir de blender, ce sont les 2 seuls moteurs libres qui le font.
- ogre, c'est qu'un moteur 3D, avec les IO de base. Tu seras obligé, si tu veux du son, d'aller utiliser d'autres libs, on voit d'ailleurs beaucoup de projet intégrant ogre et fmod (pas libre), ou openAL (libre). En revanche, CS intègre beaucoup de features et de plugins (en particulier les plugins pour le son et scripting).
- CS est donc un framework complet pour faire un jeu
- je trouve que CS est pas super accessible, même si le tutorial de la doc est bien fait (API assez obscure). D'ailleurs, je me suis noyé dans le tuto de CS, c'est pour ça que j'ai laissé tomber. En plus la version actuelle a subi des grosses refontes dans l'API, alors beaucoup de bout de code de tutos ne seront plus valide. Mais j'ai pas non plus regardé en détail l'API d'ogre.
- le rendu graphique(*) de CS a pas l'air génial (cf demos), mais j'ai pas une bécane de la mort dernier cri aussi.
- CS existe en paquets debian officiel. Pour ogre, faudra le compiler à partir des sources (bonne chance si t'a une NVidia).
- la compilation d'ogre prend à peu près 1 giga d'espace disque (ouille ça fait mal sur mon petit dd)
- ils existent des jeux commerciaux basés sur ogre.
- les démos d'ogre déchirent plus que celles de CS mais cet argument est fallacieux vu que j'ai vu les dernières démos d'ogre, et seulement celles des paquets debian pour CS. (le tout sur un athlon 700 avec geforce 2mx)
De mémoire (à vérifier donc), ogre a été pensé dès le début multiplatforme. CS a l'antériorité (plus vieux = plus mature?). Mais ils n'ont pas non plus les même objectifs (cf arguments ci-dessus).
(*) je viens de voir les dernier screenshots (ils ont refait le moteur de rendu je crois), ça a l'air pas mal.