L I N U X - M A N D R A K E
5.1 (Venice) RELEASE
July, 23 1998
http://www.linux-center.org/mandrake/
``Une distribution Linux prête à travailler, et facile à utiliser''
Base : Linux RH 5.1 GPL et KDE 1.0
Je suis très heureux de vous annoncer que ``Linux-Mandrake'', version
5.1 (Venice) est sortie et téléchargeable librement. Connectez-vous
sur notre site web-officiel :
http://www.linux-center.org/mandrake/indexfr.html
pour savoir où la télécharger.
o Qu'est-ce que Linux-Mandrake ?
----------------------------
Linux-Mandrake est une RH 5.1 GPL mise à jour à laquelle a été
integré KDE 1.0 comme desktop-manager (interface graphique du
bureau) principal. Ces deux composants ont été modifiés et pré-
configurés pour fonctionner correctement ensemble.
o Les objectifs principaux de cette distribution sont :
---------------------------------------------------
- fournir une distribution Linux facile à installer et qui
fonctionne bien, pour ceux qui ne veulent pas passer trop de
temps à installer et configurer leur système Linux. Installez
Linux-Mandrake et UTILISEZ-LE !
- proposer un système Linux complet très attractif pour les
débutants qui viennent "du coté sombre de la force" que vous
connaissez ;-)
- fournir une nouvelle distribution Linux dans un environnement
très proche de ceux que les utilisateurs courants de Linux
connaissent déjà bien (RH 5.1).
- fournir pour les utilisateurs français un système KDE parametré
en langue française, et surtout égalemen : un clavier bien géré
avec des accents qui fonctionnent, aussi bien sous X qu'en
console.
Lorsque votre installation (identique à celle de la RH 5.1)
est terminée, tapez juste `startx' et votre superbe environnement
graphique KDE 1.0 apparaît sans rechigner :-) Maintenant,
cliquez sur l'icône du CD-ROM et vous montez automatiquement
votre lecteur CD et pouvez l'utiliser. Et ceci également en tant
qu'utisateur non privilégié. Même chose pour le lecteur de
disquettes.
o Contenu :
-------
Dans Linux-Mandrake, vous trouverez tous les logiciels déjà
fournis dans dans la RH 5.1 : Emacs 20.2 le fameux éditeur de
texte, Apache 1.2.6 le célèbre serveur web, Netscape 4.05 le
navigateur Internet etc.
Nous avons également poussé notre bonne volonté jusqu'à vous
fournir Gimp 1.0, le clône de Photoshop...
Nous pensons sincèrement que Linux-Mandrake 5.1 est une des
distributions Linux plus puissantes à l'heure actuelle. Et
certainement la plus facile à utiliser.
o Divers :
------
Ceci est une première version pour tests, bien que je pense
*vraiment* que cette distribution est au moins aussi utilisable
que n'importe quelle autre :-)
Je cherche encore des mirroirs FTP !!! merci de me contacter.
D'autres informations sur :
http://www.linux-center.org/mandrake/indexfr.html
Vos remarques et suggestions à propos de Linux-Mandrake seront
très appréciées ! :-)
Gaël Duval - du...@criuc.unicaen.fr
o Merci beaucoup à :
----------------
Stéfane Fermigier (linux-center), Nat Makarevitch (linux-france),
Arnaud Crespin, Philippe Blanfuney (NOL), Sébastien Blondeel, et
mon frère Antoine, pour leur aide et leur soutien enthousiaste
de ce projet.
Les responsables de erm6.u-strabg.fr, ftp.sunet.se et ftp.asci.fr
pour héberger cette nouvelle distribution Linux avec enthousiasme
(je cherche encore des mirroirs FTP !)
RedHat Software pour leurs chouettes distributions.
Les développeurs de KDE pour leur énorme travail.
Mon processeur 6x86 overclocké pour avoir été assez sympa de ne
pas fondre à force de compiler tous les packages Mandrake.
Et bien sûr, Linus et les gens de GNU pour avoir permis toute
cette incroyable révolution du logiciel libre.
o Annexe : contenu plus détaillé de Linux-Mandrake :
------------------------------------------------
Linux Kernel version: 2.0.34
ld.so version: 1.9
glibc version: 2.0.7
egcs version: 1.0.2
gcc version: 2.7.2
RH Linux version: 5.1
KDE version: 1.0
XFree86: 3.3.2
Gimp version: 1.0
Apache version: 1.2.6
Netscape Communicator version: 4.05
emacs version: 20.2
Et bien entendu, tous les packages RPM de la RH (avec toutes les
mises à jour au 17 juillet 1998) !
----------------------------------------------------------------
http://www.linux-center.org/mandrake/indexfr.html
----------------------------------------------------------------
--
////////////////////////////////////////////////////////
// Gael DUVAL - Reseaux & Applications documentaires //
/ LINUX, LINUX, LINUX ///
/////////////////////////////////////////////////////
: L I N U X - M A N D R A K E
: 5.1 (Venice) RELEASE
: July, 23 1998
: http://www.linux-center.org/mandrake/
: ``Une distribution Linux prête à travailler, et facile à utiliser''
: Base : Linux RH 5.1 GPL et KDE 1.0
[...]
: o Qu'est-ce que Linux-Mandrake ?
: ----------------------------
C'est drole, mais qd j'ai vu Mandrake, j'ai pense immediatement
a la personne qui maintient Enlightenment avec Raster, et je me suis
dit: "Tient? une distrib basee sur enlightenment? avec plein de
E machins partout? lisons donc!" :)
: o Contenu :
: -------
: Dans Linux-Mandrake, vous trouverez tous les logiciels déjà
: fournis dans dans la RH 5.1 : Emacs 20.2 le fameux éditeur de
: texte, Apache 1.2.6 le célèbre serveur web, Netscape 4.05 le
: navigateur Internet etc.
Apparament il manque un truc qui est toujours aussi penible que
dans la RH 5.x: Il n'y a toujours pas xemacs.
Etant donne qu'il doit y avoir un remplacement dans KDE vous devez
pas trouver ca grave, mais c'est qd meme desagreable.
: Nous avons également poussé notre bonne volonté jusqu'à vous
: fournir Gimp 1.0, le clône de Photoshop...
C'est parce-que Gimp utilise gtk+ que vous avez du "pousser" votre
bonne volonte? :)
: Nous pensons sincèrement que Linux-Mandrake 5.1 est une des
: distributions Linux plus puissantes à l'heure actuelle. Et
Vous avez chronometre avec la sortie de la Debian 2.0? :)
: certainement la plus facile à utiliser.
oui (enfin j'espere, vu ce qui est decrit plus haut).
: o Divers :
: ------
: Ceci est une première version pour tests, bien que je pense
: *vraiment* que cette distribution est au moins aussi utilisable
: que n'importe quelle autre :-)
Je me doute que ca ne se fait pas, mais je vais qd meme le faire...
Avez-vous laisse gnome dedans, si oui, quelle version? 0.20?
Meme si gnome en tant que desktop doit vous deranger il y a qd
meme qq applis sympathiques dedans (ee par ex).
Notez que l'inverse est aussi vrai pour l'utilisateur de gnome
que je suis par rapport aux outils KDE.
: http://www.linux-center.org/mandrake/indexfr.html
: Vos remarques et suggestions à propos de Linux-Mandrake seront
: très appréciées ! :-)
Xemaaaacs!!!
Lokh.
PS: bo boulo!
> : http://www.linux-center.org/mandrake/indexfr.html
>
> : Vos remarques et suggestions à propos de Linux-Mandrake seront
> : très appréciées ! :-)
>
> Xemaaaacs!!!
c'est noté !! Je mets ça dans la prochaine version (qui sera distribuée
par CD-ROM)...
A+, Gaël.
>
>
> L I N U X - M A N D R A K E
>
>
> 5.1 (Venice) RELEASE
> July, 23 1998
>
>
> http://www.linux-center.org/mandrake/
>
>
> ``Une distribution Linux prête à travailler, et facile à utiliser''
>
> Base : Linux RH 5.1 GPL et KDE 1.0
>
>
>
> Je suis très heureux de vous annoncer que ``Linux-Mandrake'', version
>
> 5.1 (Venice) est sortie et téléchargeable librement. Connectez-vous
> sur notre site web-officiel :
>
> http://www.linux-center.org/mandrake/indexfr.html
[...]
> Vos remarques et suggestions à propos de Linux-Mandrake seront
> très appréciées ! :-)
>
>
> Gaël Duval - du...@criuc.unicaen.fr
tout cela me semble prometteur !
avez vous pensé à mettre à jour la librairie ncurses ?? ;)
cette satanée lib est déjà à la version 4.2 ou plus et dans toutes les
distrib on ne trouve que la 1.9.9e, version buggée qui plus est !
(affirmation confirmée sur le site de ncurses par les auteurs)
si seulement votre distrib pouvait inclure une version plus récente
que la «1.9.9e» de cette lib !
----> <ftp://ftp.clark.net/pub/dickey/ncurses>
AmicaLinuXement,
Denis.
--
.---------------------. « Grâce à l'Internet nous pouvons
( POWERED BY GNU/LINUX ) diffuser l'information et ce malgré
`---------------------' les journalistes »
: tout cela me semble prometteur !
: avez vous pensé à mettre à jour la librairie ncurses ?? ;)
: cette satanée lib est déjà à la version 4.2 ou plus et dans toutes les
: distrib on ne trouve que la 1.9.9e, version buggée qui plus est !
: (affirmation confirmée sur le site de ncurses par les auteurs)
Dans la RH 5.1 il y a les 2, et seule la plus recente est installee
par defaut (la 4.?).
Certains programme demandent cependant l'ancienne version (1.9) et
j'ai ete bien content de la trouver sur le CD pour installer mon
bon vieux package Xemacs 20.x compile en glibc2...
: si seulement votre distrib pouvait inclure une version plus récente
: que la «1.9.9e» de cette lib !
Je ne'ai pas regarde en detail la liste de pacakges, mais si cette
ditrib est basee sur la RH 5.1 il n'y a pas de probleme.
Lokh.
PS: a part le pb de securite qui est apparu ce we bien sur :).
> Je me doute que ca ne se fait pas, mais je vais qd meme le faire...
> Avez-vous laisse gnome dedans, si oui, quelle version? 0.20?
>
> Meme si gnome en tant que desktop doit vous deranger il y a qd
> meme qq applis sympathiques dedans (ee par ex).
> Notez que l'inverse est aussi vrai pour l'utilisateur de gnome
> que je suis par rapport aux outils KDE.
Holala il y en a marre de ce debat sans fin
ca m'epuise a force
je suis plein de bonne volonte pourtant impossible de compiler
gnome sur ma station sous hp UX meme sous linux c'est la plaie
a l'inverse KDE a compile comme une fleur...
Les deux projets n'en sont pas au meme stade c'est clair
et les zelotes de gnmoe feraient mieux de coder car s'ils
veulent bouter KDE en dehors de linux (et pourquoi donc ?)
il va falloir rendre gnome meilleur et pour l'instant
c'est pas encore ca, rappellez moi quand ce sera multi unix
franchement yen a plus que marre
antoine
> je suis plein de bonne volonte pourtant impossible de compiler
> gnome sur ma station sous hp UX meme sous linux c'est la plaie
Notez que je ne compile rien : je suis un gros feignant et
j'installe des paquetages Debian tout faits. Ça me laisse
plus de temps pour lire les News.
> Les deux projets n'en sont pas au meme stade c'est clair
Oui, Gnome est nettement moins avancé que KDE. Pour faire une
démo à un décideur, KDE vaut mieux, c'est clair.
> et les zelotes de gnmoe feraient mieux de coder car s'ils
> veulent bouter KDE en dehors de linux (et pourquoi donc ?)
Parce que KDE dépend d'une bibliothèque non libre (Qt). Ça
ne sert à rien de hurler contre le méchant Bill Gates si on
ne tire pas des leçons du passé et qu'on se laisse enfermer
dans des logiciels privés.
Gnome, au contraire, ne dépend que de logiciels libres.
>
>> et les zelotes de gnmoe feraient mieux de coder car s'ils
>> veulent bouter KDE en dehors de linux (et pourquoi donc ?)
>
>Parce que KDE dépend d'une bibliothèque non libre (Qt). Ça
>ne sert à rien de hurler contre le méchant Bill Gates si on
>ne tire pas des leçons du passé et qu'on se laisse enfermer
>dans des logiciels privés.
>
le choix de QT a l'epoque a ete fait car c'etait le meilleur toolkit a
cette date et il a permis a KDE d'etre fait plus vite donc.
Sinon le license de QT n'est une plaie non plus même si elle est pas
vraiment libre.L'as tu au moins lu ET comprise ?
Et sinon conjointement un clone ameliore de QT en LGPL a ete developpe
: harmony, et ce projet est bientot fini donc je le debat KDE/GNOME
sur les licenses devrait etre clos puisque dans un futur proche QT
sera remplace par harmony qui permettra en autre de changer le look de
KDE.Voir le site KDE.Voila.
(°_°) Myriam & Fraggle (°_°)
UIN ICQ : 13564956
oui.
: Et sinon conjointement un clone ameliore de QT en LGPL a ete developpe:
: harmony, et ce projet est bientot fini
ha?
Je suis alle voir sur "status" d'harmony et apparament ils ont pas
mal avance sur les fonctions de base (glib et gdk chez gnome) mais
il manque qd meme les widgets :).
J'ai bien aime le cote "themes" de harmony, ca m'a fait pense a gtk+.
En plus si j'ai bien compris la psychologie de KDE, les themes ne
sont pas prevu (ni meme souhaite) histoire d'avoir un desktop
uniforme (qui soit pareil sur toutes les machines).
Enfin, ca changera peut-etre dans le futur...
: donc je le debat KDE/GNOME
: sur les licenses devrait etre clos puisque dans un futur proche QT
: sera remplace par harmony qui permettra en autre de changer le look de
: KDE.Voir le site KDE.Voila.
D'apres ce mque j'ai pu voir il y a 4 widgets et demi d'implementees,
et encore, a 50%, les autres ne sont pas commencees.
C'est bien beau de mettre une barre 100% a cote de Qsize ou Qrect, mais
c'est classes la c'est une structure (pardon, classe) et 3 fonctions
(pardon, methodes) pour en recuperer/mettre les champs.
On repparlera d'harmony dans 3 mois.
Fausse alerte donc :).
Lokh.
>
>Je suis alle voir sur "status" d'harmony et apparament ils ont pas
>mal avance sur les fonctions de base (glib et gdk chez gnome) mais
>il manque qd meme les widgets :).
Bon ok quand j'ai dit bientot j'aurais du dire dans quelques mois.ça
va la ? :-)))
Enfin bref tout ça pour dire que la dependance de KDE a QT ne sera
plus dans le futur, c'est tout et c'est tres bien.En plus Redhat a
engage du monde pour bosser sur harmony (source slashdot) donc ça
avance et c'est tres bien.
>
>J'ai bien aime le cote "themes" de harmony, ca m'a fait pense a gtk+.
>En plus si j'ai bien compris la psychologie de KDE, les themes ne
>sont pas prevu (ni meme souhaite) histoire d'avoir un desktop
>uniforme (qui soit pareil sur toutes les machines).
>Enfin, ca changera peut-etre dans le futur...
Oui avec harmony mais ce "pb " vient de QT c'est pour ça.
>
>
>D'apres ce que j'ai pu voir il y a 4 widgets et demi d'implementees,
>et encore, a 50%, les autres ne sont pas commencees.
>C'est bien beau de mettre une barre 100% a cote de Qsize ou Qrect, mais
>c'est classes la c'est une structure (pardon, classe) et 3 fonctions
>(pardon, methodes) pour en recuperer/mettre les champs.
>
>On repparlera d'harmony dans 3 mois.
>
>Fausse alerte donc :).
Ben non Harmony n'est pas encore fonctionnel mais c'est juste pour
recentrer le debat sur les licenses KDE/QT et GNOME/GTK.
QT a ete choisi a l'epoque pour obtenir plus vite un environnent
fonctionnel mais que dans le futur le pb que pose QT a certain n'en
sera plus un et que ceci a ete pense depuis longtemps.Et donc que ce
facheux debat (dispute ???? ) entre GNOME et KDE n'a pas lieu
d'etre.C'est tout.
À propos de la mandrake, qui s'en occupe ?
Est-elle mise à jour avec les updates RH 5.1 qui sortent de temps en temps ?
Si une des personnes s'en occupant pouvait me contacter, l'ARNTT CULTE
(club linux toulousain) doit normalement distribuer à un prix symbolique
une RedHat récente, avec des programmes biens mais non présents par défaut,
de la documentation, etc. lors du salon FAUST/SITEF (nouvelles technologies)
La Mandrake conviendrait bien, si rien n'a été supprimé par rapport à la
5.1 «GPL» (sans realaudio & co) sauf peut être les srcs pour caser plus de
binaires, le public visé se préoccupant certainement peu des srcs, dispo
sur le net de toutes façons.
Merci & À+
--
"Always pass on good advice. It is never any use to oneself" -- Oscar Wilde
Enlever rrremovethis / Remove rrremovethis
Salut / Best regards, Guylhem AZNAR <guy...@rrremovethis.oeil.qc.ca>
Il y a des sites où les packages communs à la Mandrake et
à la RH sont des liens symboliques de l'une vers l'autre. Donc, en théorie,
si la RH est mise à jour, la Mandrake aussi.
eul'Pingouin.
--
François Jeanmougin | groupe de bioinformatique / bioinformatics group
tel:(+33) 3 88 65 32 71 | IGBMC BP 163 67404 Illkirch France
Linux: Booter, certes, mais pourquoi rebooter?
M&F> Et sinon conjointement un clone ameliore de QT en LGPL a ete developpe
"est en developpement" serait plus exact.
Ceci dit; le handicap majeur de KDE est de forcer l'utilisation du C++, alors
que Gnome permets déjà des applications écrites en C, C++, Objective C, perl
et scheme. Quelqu'un connaissant le C mais pas le C++ (ce qui n'est pas si
rare semble-t-il) pourra facilement écrire un programme Gnome; tandis que pour
KDE il devra commencer par apprendre un nouveau langage de programmation.
A part Qt/Gtk, C++/C il semble aussi que KDE aie implementé COM (rebaptisé KOM)
tandis que Gnome utilise CORBA. Par contre là je suis incapable de dire quelles
en sont les consequences de l'un et l'autre choix.
--
Pablo Saratxaga You may say I'm a hacker,
sr...@chanae.alphanet.ch But I'm not the only one.
PGP key 0x8F0E49755 I hope someday you'll join us
http://www.rtfm.be/linux/ And our games will fit in RAM.
>
>A part Qt/Gtk, C++/C il semble aussi que KDE aie implementé COM (rebaptisé KOM)
>tandis que Gnome utilise CORBA. Par contre là je suis incapable de dire quelles
>en sont les consequences de l'un et l'autre choix.
>
>--
J'ai un gros doute sur ça car corba est utilise aussi par KDE
[clone QT]
M&F> Enfin bref tout ça pour dire que la dependance de KDE a QT ne sera
M&F> plus dans le futur
Bien sûr que si. Puisque le but est une compatibilité si pas binaire au moins
au niveau des sources avec QT. Ce sera donc toujours QT qui sera determinant.
Pareil pour lesstif d'ailleurs; que les programmes soient linkés avec lesstif
ou Motifs ils sont toujours dependents de Motif pour ce qui est de la
definition des fonctionalités et capacités disponibles.
: M&F> Et sinon conjointement un clone ameliore de QT en LGPL a ete developpe
: "est en developpement" serait plus exact.
Apres avoir parcouru la mailing-list hier soir, il semble qu'ils
aient aussi un gros probleme juridique. A savoir TrollTech pourrait
les attaquer en justice et personne n'est capable de dire comment
ca pourrait se finir.
Certains trouvent tres desagreables de faire du free software avec une
telle epee de Damocles (c'est le cas du mec embauche chez RH).
Par contre ilk y a du beau monde qui participe a cette discussion
(Bruce Perens, Alan Cox, Stallman.. :)).
: Ceci dit; le handicap majeur de KDE est de forcer l'utilisation du C++, alors
: que Gnome permets déjà des applications écrites en C, C++, Objective C, perl
: et scheme. Quelqu'un connaissant le C mais pas le C++ (ce qui n'est pas si
: rare semble-t-il) pourra facilement écrire un programme Gnome; tandis que pour
: KDE il devra commencer par apprendre un nouveau langage de programmation.
Ouais, au moins le temps qu'un bon UI Builder apparaisse pour Qt (Apres
tu peux toutjours faire du C dans les callbacks :) ).
: A part Qt/Gtk, C++/C il semble aussi que KDE aie implementé COM (rebaptisé KOM)
: tandis que Gnome utilise CORBA. Par contre là je suis incapable de dire quelles
: en sont les consequences de l'un et l'autre choix.
J'ai enetendu parle de KOM mais je ne sais pas ce que c'est.
Par contre KDE utilise aussi Corba, mais la aussi je ne sais pas "lequel"
(gnome vient de laisser tomber mico au profit d'Orbit par ex.).
Lokh.
[reimplemtation libre de QT]
PF> Apres avoir parcouru la mailing-list hier soir, il semble qu'ils
PF> aient aussi un gros probleme juridique. A savoir TrollTech pourrait
PF> les attaquer en justice et personne n'est capable de dire comment
PF> ca pourrait se finir.
Si la reimplementation est faite sans puiser dans le code source de QT
Troll Tech perdrait bcp à faire cela; car le fait que KDE utilise QT est
très important comme vecteur de dissemination; si ils attaquent ceux
qui ont decidé de reimplemnter la lib QT va être boycoté comme Apple le
fut en son temps.
PF> : Ceci dit; le handicap majeur de KDE est de forcer l'utilisation du C++, alors
PF> : que Gnome permets déjà des applications écrites en C, C++, Objective C, perl
PF> : et scheme. Quelqu'un connaissant le C mais pas le C++ (ce qui n'est pas si
PF> Ouais, au moins le temps qu'un bon UI Builder apparaisse pour Qt (Apres
PF> tu peux toutjours faire du C dans les callbacks :) ).
KDE (tout comme Gnome) n'est pas une simple interface graphique mais un
desktop; il y a des choses comme le copier coller, la communication entre
applications, la reconnaissance de types de fichiers, etc. qui doivent être
faits de façon consistente; pour cela un certain nombre de libs existent;
celles de KDE necessitent le C++, donc un UI Builder ne changera pas grand
chose sur ce point je crois.
PF> : A part Qt/Gtk, C++/C il semble aussi que KDE aie implementé COM (rebaptisé KOM)
PF> : tandis que Gnome utilise CORBA. Par contre là je suis incapable de dire quelles
PF> : en sont les consequences de l'un et l'autre choix.
PF> J'ai enetendu parle de KOM mais je ne sais pas ce que c'est.
J'avoue que je ne sais pas non plus ce qu'est exactemment COM et CORBA je
nage un peu. Je sais que c'est deux approches differentes du même problème.
PF> Par contre KDE utilise aussi Corba, mais la aussi je ne sais pas "lequel"
PF> (gnome vient de laisser tomber mico au profit d'Orbit par ex.).
Alors je me trompe peut-être. Note que j'en suis un peu étonné, car quand je
fais un "grep -i orb" sur les libs KDE je n'ai qu'une seule ocurrence
tandis que si je fais de même avec les libs mico ou ORBit (necessaires pour
installer Gnome) j'en ai des centaines.
Est-ce que KDE utilise vraiment CORBA en entier ou simplement une version
minimaliste ?
Tres mal pour TrollTech, quel que soit le resultat.
>Si la reimplementation est faite sans puiser dans le code source de QT
>Troll Tech perdrait bcp à faire cela; car le fait que KDE utilise QT est
>très important comme vecteur de dissemination; si ils attaquent ceux
>qui ont decidé de reimplemnter la lib QT va être boycoté comme Apple le
>fut en son temps.
La reimplementation est faite sans puiser dans le code source en
question. Seule la doc html est utilisee. De plus les choix
d'implementation sont tels que les structures internes sont tres
differentes (ca se voit sans meme avoir a connaitre celles de Qt).
> PF> : Ceci dit; le handicap majeur de KDE est de forcer l'utilisation du C++, alors
> PF> : que Gnome permets déjà des applications écrites en C, C++, Objective C, perl
> PF> : et scheme. Quelqu'un connaissant le C mais pas le C++ (ce qui n'est pas si
>
> PF> Ouais, au moins le temps qu'un bon UI Builder apparaisse pour Qt (Apres
> PF> tu peux toutjours faire du C dans les callbacks :) ).
>
>KDE (tout comme Gnome) n'est pas une simple interface graphique mais un
>desktop; il y a des choses comme le copier coller, la communication entre
>applications, la reconnaissance de types de fichiers, etc. qui doivent être
>faits de façon consistente; pour cela un certain nombre de libs existent;
>celles de KDE necessitent le C++, donc un UI Builder ne changera pas grand
>chose sur ce point je crois.
Autant que je sache, Qt Architect, trouvable a
<URL:http://www.primenet.com/~jtharris/qtarch/> est des plus
sympathiques. Par contre il ne connait pas les widgets KDE.
> PF> : A part Qt/Gtk, C++/C il semble aussi que KDE aie implementé COM (rebaptisé KOM)
> PF> : tandis que Gnome utilise CORBA. Par contre là je suis incapable de dire quelles
> PF> : en sont les consequences de l'un et l'autre choix.
>
> PF> J'ai enetendu parle de KOM mais je ne sais pas ce que c'est.
>
>J'avoue que je ne sais pas non plus ce qu'est exactemment COM et CORBA je
>nage un peu. Je sais que c'est deux approches differentes du même problème.
Le but dans les deux cas, c'est d'avoir un systeme de composants. En
gros un base de donnees d'implementation d'objets que vous pouvez
linker dynamiquement a votre application a tout moment et ce a travers
une interface abstraite independante du langage de programmation.
Ceci inclut aussi la possibilite de communiquer avec des objets
distants de la meme maniere que s'ils etaient locaux.
Les differences entre COM et CORBA ne sont pas primordiales pour le
non-specialiste.
> PF> Par contre KDE utilise aussi Corba, mais la aussi je ne sais pas "lequel"
> PF> (gnome vient de laisser tomber mico au profit d'Orbit par ex.).
KDE utilise mico.
>Alors je me trompe peut-être. Note que j'en suis un peu étonné, car quand je
>fais un "grep -i orb" sur les libs KDE je n'ai qu'une seule ocurrence
>tandis que si je fais de même avec les libs mico ou ORBit (necessaires pour
>installer Gnome) j'en ai des centaines.
>Est-ce que KDE utilise vraiment CORBA en entier ou simplement une version
>minimaliste ?
Ni gnome ni KDE n'utilisent vraiment les possibilites des composants.
KDE se sert surtout des proprietes de communication dans leur suite
office.
OG.
The KDE Free Qt Foundation
The KDE project and Troll Tech AS, the creators of Qt, are pleased
to announce the founding of the 'KDE Free Qt Foundation'.
The purpose of this foundation is to guarantee the availability of
Qt for free software development now and in the future.
The foundation will control the rights to the Qt Free Edition and
ensure that current and future releases of Qt will be available for
free software development at all times. All changes to the Qt Free
Edition license will have to be approved by the KDE Free Qt Founda-
tion which will consist of two members of Troll Tech AS as well as
two members of the KDE project. One of the representatives of the
KDE project will have a double vote to be used in case of a tie.
Should Troll Tech ever discontinue the Qt Free Edition for any rea-
son including, but not limited to, a buy-out of Troll Tech, a merger
or bankruptcy, the latest version of the Qt Free Edition will be
released under the BSD license.
Furthermore, should Troll Tech cease continued development of Qt, as
assessed by a majority of the KDE Free Qt Foundation, and not
release a new version at least every 12 months, the Foundation has
the right to release the Qt Free Edition under the BSD License.
At this point lawyers are working on the details of the agree-
ment. Troll Tech and the KDE project expect to be able to sign the
necessary documents within a few weeks.
We believe the founding of the KDE Free Qt Foundation to be an
unprecedented ground-breaking step, ushering in a new era of soft-
ware development, allowing the KDE project, the free software commu-
nity, all free software developers as well as commercial software
developers to prosper in a mutually supportive fashion.
Bernd Johannes Wuebben Eirik Eng
The KDE Project Troll Tech CEO
wue...@kde.org Eiri...@troll.no
>>J'avoue que je ne sais pas non plus ce qu'est exactemment COM et CORBA je
>>nage un peu. Je sais que c'est deux approches differentes du même problème.
OG> Le but dans les deux cas, c'est d'avoir un systeme de composants. En
OG> gros un base de donnees d'implementation d'objets que vous pouvez
OG> linker dynamiquement a votre application a tout moment et ce a travers
OG> une interface abstraite independante du langage de programmation.
OG> Ceci inclut aussi la possibilite de communiquer avec des objets
OG> distants de la meme maniere que s'ils etaient locaux.
Tiens, où viens se placer OpenStep là dedans ? Il permets aussi de lier
dynamiquement des objets pour créer ou modifier des applications.
Utilise-t-il CORBA ou est-ce encore different ?
OG>>> KDE utilise mico.
>>Alors je me trompe peut-être. Note que j'en suis un peu étonné, car quand je
>>fais un "grep -i orb" sur les libs KDE je n'ai qu'une seule ocurrence
>>tandis que si je fais de même avec les libs mico ou ORBit (necessaires pour
>>installer Gnome) j'en ai des centaines.
OG> Ni gnome ni KDE n'utilisent vraiment les possibilites des composants.
OG> KDE se sert surtout des proprietes de communication dans leur suite
OG> office.
suite que je n'ai pas installé; ceci explique donc peut-être cela :)
--
A bientôt,
Pablo Saratxaga PGP Key available, key ID: 0x8F0E4975
http://www.ncworldmag.com/ncworld/ncw-05-1998/ncw-05-nextten.html
> In article <6r01qm$s...@chanae.alphanet.ch>, Pablo Saratxaga wrote:
> >Alors je me trompe peut-être. Note que j'en suis un peu étonné, car quand je
> >fais un "grep -i orb" sur les libs KDE je n'ai qu'une seule ocurrence
> >tandis que si je fais de même avec les libs mico ou ORBit (necessaires pour
> >installer Gnome) j'en ai des centaines.
Pas tres parlant de faire un grep sur des librairies... Il suffit que
machin ai decidé d'appler son ORB 'machin' et tu ne trouveras pas de
reference a orb dans la librairie. ORB est un concept, pas une
contrainte d'appellation pour l'implementation du modele... :)
> >Est-ce que KDE utilise vraiment CORBA en entier ou simplement une version
> >minimaliste ?
>
> Ni gnome ni KDE n'utilisent vraiment les possibilites des composants.
> KDE se sert surtout des proprietes de communication dans leur suite
> office.
Faux (mais pas tout a fait :) )... Gnome, pour le moment utilise de
maniere quasi exclusive CORBA dans le panel et les applets associées.
En fait, le gros souci d'utilisation de mico etait sa lourdeur (mico
est une implementation de CORBA a but pedagogique... Les auteurs
expliquent clairement sur leur site (dont je ne me souviens plus de
l'URL) que leur but n'est ni la performance ni l'efficacité). De
plus, mico marche en C++, ce qui impliquait de porter une partie du
code en C++ (Gnome s'appuyant sur GTK qui tourne en C - et bindings en
C++ pour les accros :) ). Maintenant, avec ORBit qui est en C, qui est
sensé etre plus efficace et moins gourmand, le passage sous CORBA des
applis devrait se faire de maniere plus fluide ; en tout cas, c'est
dans la TODO list :)
--
Seb C. (mailto:sca...@atos-group.com) | Working for Atos at Lille, France
*********************************************************************
> Excusez-moi pour ma question peut-être idiote. Tout le monde dit que
> Qt l'est pas libre, ce qui pose problème pour KDE. Alors que penser
> de ça : <http://www.kde.org/kdeqtfoundation.html>
>
[snip : The KDE Free Qt Foundation]
Ben bof .. ça dit juste que s'il arrive une tuile a Troll tech (rachat
ou autre) ou que Troll tech abandonne Qt, Qt pourra passer sous
license libre (type FreeBSD). C'est une securité, certes, mais ça ne
change rien au fait que Qt soit non libre et continue d'appartenir a
Troll tech...
PG> Excusez-moi pour ma question peut-être idiote. Tout le monde dit que
PG> Qt l'est pas libre, ce qui pose problème pour KDE. Alors que penser
PG> de ça : <http://www.kde.org/kdeqtfoundation.html>
En effet, c'était un problème, ce ne l'est plus vraiment maintenant;
maintenant le problème c'est les querelles stupides et les rancoeurs
(comprehensibles; personne n'aime qu'on attaque de façon aussi virulente
sa création).
Comme quelqu'un l'a dit il y a quelque temps (eul'pinguoin ? nat ?) les
diferences principales sont maintenant techniques; KDE utilise et impose C++;
Gnome utilise le C pour ses libs et on peut les utiliser en C, C++,
Objective C, scheme (des programmes dans ces 4 langages sont inclus dans
les archives gnome), perl et sans doute d'autres à l'avenir.
Une autre difference est que KDE est un tout très compact, il utilise son
propre session manager et son propre window manager; et on ne peut pas
aisement s'en passer (on perds pas mal de fonctionnalités alors, pa moyen
de lancer le panel par exemple); alors que Gnome peut être utilisé avec
n'importe quel WM (ou même sans :) ) et avec un autre (ou sans :) ) session
manager.
KDE doit faire avec la lib QT mais même si elle est très bien faite elle
n'est pas revolutionnaire.
En tout cas la situation actuelle est très bien ainsi; on a un desktop
fonctionnel et agréable disponible immediatemment; et on un autre que les
developpeurs espèrent faire vraiment innovateur, en developpement actif.
fermer le projet KDE serait à mon avis uine grossière erreur car ça ne
ferait que prolonger l'attente pour disposer d'un desktop.
Je crois, en toute humilite et modestie, et en depit de mon admiration
sans bornes pour Messieurs Nat et Pingouin, que tu fais allusion a un
post (puisque j'avais vu que tu l'avais redirige sur fido), dont je
suis le miserable auteur (ca ira, comme ca :-) ?).
> KDE utilise et impose C++;
Et comment! Etant un ennemi acharne du C++, c'est mon principal grief
contre KDE et Qt. On commence a avoir des bindings Python vaguement en
voie d'etre utilisables, mais encore très limités.
> Gnome utilise le C pour ses libs et on peut les utiliser en C, C++,
> Objective C, scheme (des programmes dans ces 4 langages sont inclus dans
> les archives gnome), perl et sans doute d'autres à l'avenir.
>
Tom et Python.
> Une autre difference est que KDE est un tout très compact, il utilise son
> propre session manager et son propre window manager; et on ne peut pas
> aisement s'en passer (on perds pas mal de fonctionnalités alors, pa moyen
> de lancer le panel par exemple); alors que Gnome peut être utilisé avec
> n'importe quel WM (ou même sans :) ) et avec un autre (ou sans :) ) session
> manager.
>
Il y a une autre chose que l'on devrait regarder serieusement quand
Gnome sera un peu stabilise, c'est la consommations en ressources,
notamment memoire. J'ai cru remarquer, la derniere fois ou j'ai eu
l'occasion de poser les mains sur KDE, que kwm et kpanel
requisitionnaient 3 ou 4 fois plus de memoire que respectivement un
fvwm/AfterStep et un Wharf. Pas normal. A quoi ca sert que Torvalds et
sa bande se decarcassent a faire un kernel aussi compact que possible
si c'est pour apposer par dessus une GUI qui amene une consommation
comparable a un Windows? Que X soit (relativement) gourmand a cause de
ses protocoles d'affichage distants, securises, multiutilisateurs,
c'est normal, mais que le Window manager et/ou le desktop pese aussi
lourd, si ce n'est plus, que X lui-meme, c'est impardonnable.
Apparement, le panel Gnome et de nouveaux Window Manager
Gnome-compliant comme icewm (au passage, ceux qui utilisent fvwm95 et
souhaitent garder son ergonomie auraient tout interet, a tout point de
vue -conso memoire, vitesse, esthetique, configurabilite...- a le
remplacer par icewm quand il sera bien mature) sont nettement plus
legers, par contre, le help-browser est quand meme un peu gourmand au
vu de ce qu'il propose: on a presque une conso equivalente a un GNU
Emacs, simplement pour lire des man pages et des docs Info (ce
qu'Emacs fait merveilleusement)! De son cote, Electric Eyes est aussi
deja plus gourmand que xv alors qu'il n'est pas encore aussi
fonctionnel, etc, etc... Bref, ca m'inquiete un peu, tout ca.
--
Jerome Kalifa
Centre de Mathematiques Appliquees, Ecole Polytechnique.
91128 Palaiseau Cedex, France. (33)169333981
Je confirme. mais il me semble que vous avez été deux
sur ce coup, et que l'ami Patrice y était aussi allé de son couplet sur
la liberté des futurs développeurs... et le portage de l'existent (ben oui,
s'il n'y a "que" le protocole de communication à réécrire pour
intégrer son appli au desktop, c'est mieux que de edvoir tout refaire
dans un langage chiant^Wqu'on en connait pas).
eul'Pingouin.
P.S.: Jérome, tu m'apprends le Python, Jéromeuuuuh?
P.P.S.: On avait parlé de commettre un petit article sur
"ne prenons pas les utilisateurs pour des cons", tu as du temps?
COM et CORBA sont des systèmes permettant de distribuer des objets
que ce soit sur un poste isolé ou à travers un réseau. Il suffit de
respecter les modèles de programmation afin de pouvoir utiliser
ces fonctionnalités. Par COM vous pouvez aussi entendre DCOM
ActiveX et OCX : C'est tout pareil (oupresque, mais je ne connais
pas les différences) !
--
# Thomas Nemeth Heureux l'etudiant qui, comme le ruisseau,
# Toulouse - FRANCE peut suivre son cours sans sortir de son lit.
> Il y a une autre chose que l'on devrait regarder serieusement quand
> Gnome sera un peu stabilise, c'est la consommations en ressources,
> notamment memoire. J'ai cru remarquer, la derniere fois ou j'ai eu
> l'occasion de poser les mains sur KDE, que kwm et kpanel
> requisitionnaient 3 ou 4 fois plus de memoire que respectivement un
> fvwm/AfterStep et un Wharf.
belzebuth:~$ ps aux
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
..................................................................
gaucher 96 0.0 3.1 5544 2004 1 S 06:06 0:02 kpanel
gaucher 97 0.0 2.8 4700 1820 1 S 06:06 0:02 kwm
..................................................................
gaucher 166 0.8 15.3 12936 9752 1 S 06:17 0:46 emacs
root 82 2.4 7.8 11572 4968 ? S 06:06 2:34
/usr/X11R6/bin/Xwrapper:0 -bpp 16
pg.
:> Il y a une autre chose que l'on devrait regarder serieusement quand
:> Gnome sera un peu stabilise, c'est la consommations en ressources,
:> notamment memoire. J'ai cru remarquer, la derniere fois ou j'ai eu
:> l'occasion de poser les mains sur KDE, que kwm et kpanel
:> requisitionnaient 3 ou 4 fois plus de memoire que respectivement un
:> fvwm/AfterStep et un Wharf.
: USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
: ..................................................................
: gaucher 96 0.0 3.1 5544 2004 1 S 06:06 0:02 kpanel
: gaucher 97 0.0 2.8 4700 1820 1 S 06:06 0:02 kwm
: ..................................................................
: gaucher 166 0.8 15.3 12936 9752 1 S 06:17 0:46 emacs
: root 82 2.4 7.8 11572 4968 ? S 06:06 2:34
: /usr/X11R6/bin/Xwrapper:0 -bpp 16
Tu m'empêcheras pas de trouver ça ridicule.
Emacs avec ces 12 Mo, je l'ai essayé une fois, puis hop, rpm -e (plus
facile que rm -fr mais l'intention était identique)
(guylhem@barberouge:guylhem)$ ps aux | grep xcoral
guylhem 838 0.5 2.3 2956 1496 p2 S 17:23 0:00 xcoral
Tiens, je le croyais moins gros ! Enfin, il est quand même très puissant
mais je préfères vi...
(guylhem@barberouge:guylhem)$ ps aux | grep afterstep
guylhem 825 0.6 1.8 1446 1040 p2 S 17:23 0:00 afterstep
(guylhem@barberouge:guylhem)$ ps aux | grep Wharf
guylhem 827 0.4 1.5 1584 956 p2 S 17:23 0:00
/usr/local/bin/Wharf
Et encore, je trouve que c'est trop & on travaille beaucoup pour réduire cette
place (avec -f steprc, afterstep arrive à >1Mo).
Si quelques uns se crèvent pour économiser de la mémoire, ce n'est pas pour
que des boeufs codent des window managers ou des gadgets de plusieurs Mo
chaque ! L'optimisation existe, sans pour autant faire un interface très
rigoureuse/inconfigurable.
Emacs, on l'excusera, car il en fait autant que sa taille ;)
: pg.
--
"Letting people bear arms is letting them kill our children"
> :> Il y a une autre chose que l'on devrait regarder serieusement quand
> :> Gnome sera un peu stabilise, c'est la consommations en ressources,
> :> notamment memoire. J'ai cru remarquer, la derniere fois ou j'ai eu
> :> l'occasion de poser les mains sur KDE, que kwm et kpanel
> :> requisitionnaient 3 ou 4 fois plus de memoire que respectivement un
> :> fvwm/AfterStep et un Wharf.
> : USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
> : ..................................................................
> : gaucher 96 0.0 3.1 5544 2004 1 S 06:06 0:02 kpanel
> : gaucher 97 0.0 2.8 4700 1820 1 S 06:06 0:02 kwm
> : ..................................................................
> : gaucher 166 0.8 15.3 12936 9752 1 S 06:17 0:46 emacs
> : root 82 2.4 7.8 11572 4968 ? S 06:06 2:34
> : /usr/X11R6/bin/Xwrapper:0 -bpp 16
> Tu m'empêcheras pas de trouver ça ridicule.
> Emacs avec ces 12 Mo, je l'ai essayé une fois, puis hop, rpm -e (plus
> facile que rm -fr mais l'intention était identique)
Moi de meme, vive vim :)
> (guylhem@barberouge:guylhem)$ ps aux | grep xcoral
> guylhem 838 0.5 2.3 2956 1496 p2 S 17:23 0:00 xcoral
> Tiens, je le croyais moins gros ! Enfin, il est quand même très puissant
> mais je préfères vi...
Ouais moi aussi et chez moi vim c est:
happy 1707 0.2 2.8 4112 2672 ? S 22:50 0:00 vim -g
pour la version X...
> (guylhem@barberouge:guylhem)$ ps aux | grep afterstep
> guylhem 825 0.6 1.8 1446 1040 p2 S 17:23 0:00 afterstep
> (guylhem@barberouge:guylhem)$ ps aux | grep Wharf
> guylhem 827 0.4 1.5 1584 956 p2 S 17:23 0:00
> /usr/local/bin/Wharf
Moi j'aime bien windowmaker, chez moi c est:
happy 221 0.1 2.8 3740 2692 ? S 19:48 0:21 wmaker -noclip
--
Fabien Penso <pe...@linuxfr.org>
Tel: 06 14 55 27 73 - Fax: 01 46 68 24 82
Microsoft isn't the answer.
Microsoft is the question and the answer is no !
Bien dit !
:> (guylhem@barberouge:guylhem)$ ps aux | grep xcoral
:> guylhem 838 0.5 2.3 2956 1496 p2 S 17:23 0:00 xcoral
:> Tiens, je le croyais moins gros ! Enfin, il est quand même très puissant
:> mais je préfères vi...
: Ouais moi aussi et chez moi vim c est:
: happy 1707 0.2 2.8 4112 2672 ? S 22:50 0:00 vim -g
: pour la version X...
(guylhem@barberouge:guylhem)$ ps aux | grep vim
guylhem 585 3.5 1.2 1324 824 3 S 11:26 0:00 vim
En mode console, ma version X, c'est vim dans un xiterm :-)
:> (guylhem@barberouge:guylhem)$ ps aux | grep afterstep
:> guylhem 825 0.6 1.8 1446 1040 p2 S 17:23 0:00 afterstep
:> (guylhem@barberouge:guylhem)$ ps aux | grep Wharf
:> guylhem 827 0.4 1.5 1584 956 p2 S 17:23 0:00
:> /usr/local/bin/Wharf
: Moi j'aime bien windowmaker, chez moi c est:
: happy 221 0.1 2.8 3740 2692 ? S 19:48 0:21 wmaker -noclip
Pas mal, pas mal... C'est très correct en utilisation mémoire !
De toute façon, aucun window manager (à part Enl) ne peut faire pire que
KWM je crois.
: --
: Fabien Penso <pe...@linuxfr.org>
: Tel: 06 14 55 27 73 - Fax: 01 46 68 24 82
: Microsoft isn't the answer.
: Microsoft is the question and the answer is no !
--
> De toute façon, aucun window manager (à part Enl) ne peut faire pire que
> KWM je crois.
Ah non, pitié, pas de remarque gratuite sur Enlightenment.
Les versions < 0.13 etait relativement gourmande, je l'admet (et les
developpeurs aussi d'ailleurs) pour 2 raisons :
- la premiere, mineure, le code n'etait pas super optimisé, les bases
etant mal jetée dès le départ du projet. D'où une réécriture complète
(les 0.14 et > ). A noter que la 0.14 tourne impec sur ma station HP
qui est bien moins performante que mon PII 233 32Mo (carte AGP 4Mo)
-NB: je ne donne pas ses indications pour faire un quelconque
deballage de ma config, juste pour donner une idee de la valeur des
elements de hard qui compte pour les perfs de E (si kkun veut
comparer...) -
- La seconde est la principale raison de la lourdeur de E <=0.13 : le
theme par defaut utilise une debauche d'effet, qui, bien qu'ils en
mettent plein la vue, mettent a sac les resources de la machine. C'est
une utilisation a l'extreme des possibilités de configuration
autorisées. En clair, tu prends un theme un peu moins gourmand, et E
devrait s'en sortir de maniere honorable... Notamment, les "shape"
windows qui te permettent de decorer tes fenetres avec autre chose
qu'un entourage carré peuvent être très gourmande ; la raison est
toute simple : le serveur X sait parfaitement dessiner des carrés,
mais dès que tu lui demandes d'autres choses un peu "chiante", eh ben
ça lui prend forcement + de temps (genre : pour dessiner des formes
arrondies, ils les decomposent en carré... je te laisse imaginer la
suite...)
> Jerome Kalifa <kal...@cmapx.polytechnique.fr> writes:
>
> > Il y a une autre chose que l'on devrait regarder serieusement quand
> > Gnome sera un peu stabilise, c'est la consommations en ressources,
> > notamment memoire. J'ai cru remarquer, la derniere fois ou j'ai eu
> > l'occasion de poser les mains sur KDE, que kwm et kpanel
> > requisitionnaient 3 ou 4 fois plus de memoire que respectivement un
> > fvwm/AfterStep et un Wharf.
>
> belzebuth:~$ ps aux
>
> USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
> ..................................................................
> gaucher 96 0.0 3.1 5544 2004 1 S 06:06 0:02 kpanel
> gaucher 97 0.0 2.8 4700 1820 1 S 06:06 0:02 kwm
> ..................................................................
> gaucher 166 0.8 15.3 12936 9752 1 S 06:17 0:46 emacs
> root 82 2.4 7.8 11572 4968 ? S 06:06 2:34
> /usr/X11R6/bin/Xwrapper:0 -bpp 16
>
Vois pas le rapport, c'est pas de ca dont je parlais, tu repond a
cote. Emacs c'est un environnement Lisp ultra-complet, ultra-puissant,
ultra-adule par les uns et ultra-deteste par les autres, kpanel et kwm
c'est respectivement les menu Buffer et Tools d'Emacs et l'interface
en Athena.
Tu as donc :
> SIZE RSS
> gaucher 5544 2004 kpanel
> gaucher 4700 1820 kwm
Moi, j'ai
SIZE RSS SHARE
kalifa 1 0 1152 1152 940 afterstep
kalifa 0 0 1024 1024 824 wharf
Sans commentaires.
Si Emacs est gros, c'est qu'on ne peut pas faire autrement. Si kpanel
et kwm sont gros, c'est parce qu'ils ont ete ecrits par des porcs dans
une toolkit de porcs avec un langage de porcs. C'est toute la
difference.
Enfin un bon [TROLL].
Rectification, avec ps aux cette fois (je ne sais pas pourquoi
top/qps/gtop me repondent des aneries sur le champ SIZE qui est a
chaque fois identique au champ RSS).
SIZE RSS
kalifa 1588 984 Wharf
kalifa 1716 1144 afterstep
Je suis encore en AfterStep 1.0, contrairement a Guylhem (j'ai passe
trop de temps a le configurer aux petits oignons pour en changer sans
avoir une tres tres bonne raison). Tiens, Guylhem, t'aurais pas un
projet de convertisseur automatique ~/.steprc -->
~/GNUstep/Library/AfterStep dans tes cartons, par hasard ? Parce que
l'utilisation du .steprc avec afterstep >= 1.4 n'est pas vraiment une
solution.
: Je suis encore en AfterStep 1.0, contrairement a Guylhem (j'ai passe
: trop de temps a le configurer aux petits oignons pour en changer sans
En général, on configure :
* l'apparence (look)
* les associations d'évênements (feels)
* le wharf
Je te conseillerais d'essayer de faire un look & un feel par copier-coller
selon les exemples fournis, car tout le reste est suffisamment bien géré
par défaut.
Pour le wharf, la syntaxe a assez changée, mieux vaudrait tout refaire pour
profiter des dossiers déroulants multi niveaux, des MaxSwallow modules &
MaxSwallow adaptables, des tooltips (balloons -> ballons ? je ne connais
pas le mot français pour désigner de ce truc ; c'est les petites bulles qui
apparaissent lorsque le pointeur reste 1 s sur une option ; je l'ai codé
pour le Pager & Ethan les a codées pour le Wharf)
: avoir une tres tres bonne raison). Tiens, Guylhem, t'aurais pas un
: projet de convertisseur automatique ~/.steprc -->
: ~/GNUstep/Library/AfterStep dans tes cartons, par hasard ? Parce que
Si, mais il est trop peu avancé. Juste un script en perl pour faire
l'aborescence start/
Si tu veux t'y coller, suffit de lire les options du steprc pour les pondre
dans les fichiers de configuration correct (path -> base.ton_bpp, apparence
-> look, pager, wharf, winlist -> eux mêmes ...)
: l'utilisation du .steprc avec afterstep >= 1.4 n'est pas vraiment une
: solution.
Avec la 1.5, si. On s'est battu avec la mémoire, si bien qu'elle est plus
économe que la 1.0 ! À mon avis, cette solution permet une transition en
douceur.
: --
: Jerome Kalifa
: Centre de Mathematiques Appliquees, Ecole Polytechnique.
: 91128 Palaiseau Cedex, France. (33)169333981
--