KDE 3.1 est sorti bien entendu, mais aussi la release candidate 2 de GNOME 2.2.
Mais voici d'autres bonnes nouvelles :
* Un résumé de la rencontre des principaux protagonistes (Hackfest) de KDE-PIM (qui a eu lieu début janvier),
* Les versions 0.10.0 de libgda, libgnomedb et mergeant sont sorties (GNOME-DB),
* L'agenda des sorties de KOffice 1.3 a été publié,
* Quelques améliorations du look de GNOME (thèmes, curseurs, et icônes, mais aussi fonctionnalités SVG),
* Une liste dédiée à l'optimisation de KDE a été lancée,
* Des guides tout frais pour GNOME 2.2.
Aller plus loin
- KDE-PIM Hackfest : short summary report (2 clics)
- libgda/libgnomedb/mergeant 0.10.0 released (2 clics)
- KOffice 1.3 release schedule (3 clics)
- Desktop Enhancements! (2 clics)
- Learn to use GNOME (3 clics)
- KDE Dot News (2 clics)
# XFree 4.2.99
Posté par Infernal Quack (site web personnel) . Évalué à 9.
Cf http://www.kde-look.org/content/show.php?content=4805(...)
C'est mon desktop qui est heureux :)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: XFree 4.2.99
Posté par Infernal Quack (site web personnel) . Évalué à 3.
J'aime bien la remarque sur IE (qui sux)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: XFree 4.2.99
Posté par FRLinux (site web personnel) . Évalué à 3.
Steph
[^] # Re: XFree 4.2.99
Posté par Cyril . Évalué à 1.
[^] # Re: XFree 4.2.99
Posté par Merlin Lenchanteur . Évalué à 1.
http://www.directfb.org/(...)
Maintenant tout depend de ton modele de carte graphique... mais si c'est du Matrox par exemple, t'as le support alpha et une bonne accélération matériel tres correct.
http://www.directfb.org/modules.xml(...)
J'ai pas encore essayé l'accélération matériel avec ma GeForce2, mais vu les 10% de support ca doit etre affreusement lent...
QQ'un a deja testé?
[^] # Re: XFree 4.2.99
Posté par wismerhill . Évalué à 1.
[^] # Re: XFree 4.2.99
Posté par matiasf . Évalué à 3.
[^] # Re: XFree 4.2.99
Posté par wismerhill . Évalué à 2.
Ctrl-Alt-[+-] permettent justement de changer la résolution sans être root.
Par contre ce qui sera nouveau dans XFree 4.3 c'est qu'il sera aussi possible de changer la profondeur des couleurs à la volée.
[^] # Re: XFree 4.2.99
Posté par matiasf . Évalué à 5.
Enfin, s'il y a un poste X11 utilisé par plusieurs comptes, il ne peut pas voir de configuration de la résolution en fontion de l'utilisateur.
[^] # Re: XFree 4.2.99
Posté par wismerhill . Évalué à 3.
Ce serait très chiant si la taille du bureau changeait, les fenêtre sont soit redimensionnées automatiquement, soit débordent du bureau (voir sont dehors). Et pour les icônes sur le bureau c'est encore pire, ça te fout le bordel dans ton organisation.
J'avais beaucoup pesté sur win à ce sujet du temps où je l'utilisais, j'avais été enchanté de voir le système du bereau virtuel de X.
Enfin, s'il y a un poste X11 utilisé par plusieurs comptes, il ne peut pas voir de configuration de la résolution en fontion de l'utilisateur.
Si, en définissant plusieurs Layout dans le fichier de config, ensuite tu utilise l'option -layout pour choisir celui que tu veut..
[^] # Re: XFree 4.2.99
Posté par web123 . Évalué à 2.
> Si, en définissant plusieurs Layout dans le fichier de config, ensuite tu utilise l'option -layout pour choisir celui que tu veut...
Çà marche aussi si xdm est lancé ?
Non.
[^] # Re: XFree 4.2.99
Posté par HappyPeng . Évalué à 1.
Non.
Vous apportez une bonne question, mais aussi une mauvaise réponse. Est-il possible avec un xdm de base de choisir sa session ? Non. Mais GDM, KDM et autres nous ont apporté cette possibilité. Pourquoi ne pas imaginer, si cette possibilité est incluse dans XFree, qu'elle soit supportée par ces outils ? L'utilisateur pourrait alors choisir la taille de son bureau virtuel.
[^] # Re: XFree 4.2.99
Posté par web123 . Évalué à 4.
Prenons un exemple.
J'installe 100 poste sous linux. Je ne veux pas pour des raisons évidente que les utilisateur est le compte root. En tant qu'admin, je ne veux pas être dérangé pour un changement de résolution (virtualdesktop).
En effet, certain poste mon être pour des personnes qui ont une vue moyen et veulent du 800x600 en 17 pouce, d'autre aime le 1600x1200, etc...
La solution de ne pas lancé gdm au boot n'est pas bonne. On ne peut demander à des utilisateur moyen qui sont habitués à du tout graphique de se logguer en mode texte puis lancer X11.
J'ai quoi comme solution ? mettre Xconfigure avec le suid bit. L'utilisateur le lance dans un console qui sa session et se logue à nouveau. Je lui donne un moyen de "niquer" la conf.
C'est un des problème d'X11. la taille du bureau virtuel est fixé par l'administrateur et non par l'utilisateur.
[^] # Re: XFree 4.2.99
Posté par HappyPeng . Évalué à 1.
À supposer qu'X11 offre la possibilité de choisir la taille de ce bureau virtuel au lancement, par exemple par une option de la ligne de commande et non par une modification d'un fichier de configuration, une hypothetique nouvelle version de GDM permettrait à chaque utilisateur de profiter de cette fonctionnalité.
[^] # Re: XFree 4.2.99
Posté par web123 . Évalué à 3.
[^] # Re: XFree 4.2.99
Posté par HappyPeng . Évalué à 1.
[^] # Re: XFree 4.2.99
Posté par tgl . Évalué à 1.
[^] # Re: XFree 4.2.99
Posté par Vivi (site web personnel) . Évalué à 1.
Non, X est lancé par gdm. D'ailleurs gdm peut relancer X ('faut cocher une option) quand tu quittes ta session.
[^] # Re: XFree 4.2.99
Posté par web123 . Évalué à 2.
[^] # Re: XFree 4.2.99
Posté par Vivi (site web personnel) . Évalué à 1.
[^] # Re: XFree 4.2.99
Posté par Jak . Évalué à 1.
[^] # Re: XFree 4.2.99
Posté par Infernal Quack (site web personnel) . Évalué à 2.
Quand je vois par exemple gnome-mixer (ou un nom du genre), il n'a clairement pas été testé sur une petite définition :( Même en 1024x768 il dépasse sur les bords
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: XFree 4.2.99
Posté par Stephane Chauveau . Évalué à 7.
[^] # Re: XFree 4.2.99
Posté par Nÿco (site web personnel) . Évalué à 2.
xnest an X server that is itself an X client. This allows you to run a server within a server; this is occasionally useful for testing new window managers and other X clients.
Xnest relies upon its parent X server for font services.
http://www.xfree86.org/4.2.1/Xnest.1.html(...)
[^] # Re: XFree 4.2.99
Posté par web123 . Évalué à 1.
Pour mon PC "à la maison" c'est vrai que j'en ai à foutre.
[^] # Re: XFree 4.2.99
Posté par Annah C. Hue (site web personnel) . Évalué à 3.
[^] # Re: XFree 4.2.99
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
en fait il ne s'agit pas de resolution mais de Virtual Screen : en changeant la resolution ca ne change pas la taille de ce virtual screen, ce qui rend le changement un peu inutile...
[^] # Re: XFree 4.2.99
Posté par HappyPeng . Évalué à 2.
Si votre machine est bien configurée, vous pouvez accéder à toutes les résolutions ainsi, sans redémarrer votre serveur X.
Le plus gros avantage est de permettre à l'utilisateur de changer de résolution sans être root.
C'est donc un faux problème, puisque vous pouvez le faire (sous réserve d'une 'bonne' configuration).
Le problème réel est la taille du bureau virtuel, qui elle est fixée au lancement du serveur X et ne change pas avec les changements de résolution, ce qui effectivement donne un résultat différent de ce que l'on trouve avec d'autres interfaces graphiques type celle de Windows.
Le changement de bureau virtuel de façon dynamique serait-il possible sous X ? Serait-ce une bonne chose ? Devrait-il être spécifié pour chaque résolution ? Je n'en sais rien.
# Re: Des nouvelles du desktop
Posté par maxoub . Évalué à -5.
J'ai l'impression que KDE bénéficie d'un avantage technique important avec C++ et Qt, ce qui permet au projet de se développer rapidement et proposer une palette très riche et très cohérente d'applications.
Espérons que mono (http://www.go-mono.com(...)) donnera à Gnome les (nouvelles) bases dont il a AMHA besoin.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Des nouvelles du desktop
Posté par web123 . Évalué à 3.
- galeon
- evolution
- kmail
- kdevelopper
- gnucash
- etc...
Si tu utilises une de ces applis, tu utilise GNOME ou KDE (même sous fluxbox).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Des nouvelles du desktop
Posté par Infernal Quack (site web personnel) . Évalué à 3.
Ca sert à quoi d'avoir des applications qui réinventent la roue à chaque fois niveau interface, drag&drop, affichage d'image, boite de dialogue,... Le framework de KDE et Gnome sont là pour ça.
Non seulement c'est plus facile à programmer mais en plus il y a une véritable cohérence entre les applications. Et on peut faire des d&d entre elles. On peut intégrer l'une dans l'autre. On peut les manipuler de la même façon via dcop ou bonobo.
Si une nouvelle fonctionnalité géniale est développée (décrochage des menus, menus transparents, Raccourcies claviers à la emacs, portage sous autre chose qu'XFree,...) bin il n'y a rien à changer et tout le monde en profite :)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Des nouvelles du desktop
Posté par wismerhill . Évalué à 1.
Quand tu démarre un prog KDE à partir d'un autre environnement (disons konqueror sous xfce), il va te démarrer un serveur dcop, j'ai aps trouvé de moyen de désactiver ça :-(
Idem quand tu démarre par exemple kmail distant à travers un tunnel ssh, il te démarre des trucs inutiles (kdeinit dcopserver) qui vont communiquer avec le serveur X distant alors que tu veut juste consulter tes mails. À travers une conenction adsl c'est pas cool :-(
[^] # Re: Des nouvelles du desktop
Posté par Tony Gencyl . Évalué à 2.
Et bien tu installes fluxbox+X, sylpheed pour le courrier, xcdroast pour graver, et qq p'tites applis legeres, et le P200 ne souffrira pas trop ...
Par contre si (comme pas mal d'entre-nous), il y a de la ressources de dispo (plein de RAM, bon gros DD, proc rapide), un KDE ou un Gnome ca vaut la peine ... drag'n drop nickel entre Nautilus et les autres applis (comme evolution, pour faire des attachements), le nouveau systeme de gravure de CD sur Gnome2.2 (enfin, un vrai systeme integre a un filemanager !) ....
Nan franchement, un vrai core KDE ou Gnome, qd on a une machine assez puissante, c'est excellent !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Des nouvelles du desktop
Posté par Infernal Quack (site web personnel) . Évalué à 0.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Des nouvelles du desktop
Posté par Infernal Quack (site web personnel) . Évalué à 1.
Et puis c'est pas incompatible. Personnellement j'ai toujours konsole de lancé sur mon KDE :)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Des nouvelles du desktop
Posté par Nicolas Roard (site web personnel) . Évalué à 3.
Heu ... non. D'une part il y a d'autres desktop (XFCE ou GNUstep par exemple, et j'en oublie), et puis WindowMaker n'est PAS un desktop, c'est un window manager.
J'ai l'impression que KDE bénéficie d'un avantage technique important avec C++ et Qt, ce qui permet au projet de se développer rapidement et proposer une palette très riche et très cohérente d'applications.
me too. Enfin KDE a commencé avant gnome, mais d'un autre côté j'ai l'impression qu'il y a eu (au moins un temps) plus de programmeurs gnome que kde. Du moins pour les applications -- il y a pas mal d'applis intéressantes utilisants gnome (gnomemeeting,gnumeric..). A mon avis l'utilisation d'un langage orienté objet et d'une bonne bibliothèque de base a permis à KDE de ne pas se laisser distancer.
Espérons que mono (http://www.go-mono.com(...)) donnera à Gnome les (nouvelles) bases dont il a AMHA besoin.
Beaark. Finalement MDI se rends compte qu'utiliser un langage orienté objet avait quelques avantages par rapport au C pour faire de la POO. Résultat, son but est d'avoir des applications hybrides [Mono/C]+Gtk pour la transition, pour finir par uniquement du Mono/Gtk . Franchement je sens venir une grosse usine à gaz, mais bon, je me fait ptet des idées.
[^] # Re: Des nouvelles du desktop
Posté par web123 . Évalué à 2.
L'utilisation de C sous GNOME est pour permettre les bindings. Et il en existe plein sous GNOME/GTK (php, perl, python, java, bientôt C#, etc...). Les bindings sont beaucoup plus difficile à réalisé avec des librairies C++ (parfois impossible pour certain language).
[^] # Re: Des nouvelles du desktop
Posté par Raphael Junqueira . Évalué à 0.
car tu peut tjs passer par un binding C++->C-> langage au pire :)
[^] # Re: Des nouvelles du desktop
Posté par web123 . Évalué à 3.
?!
Convertir du c++ en C je le conçois facilement. Par contre le binding d'une librairie vraiment orienté objet...
Tu as un exemple ?
[^] # Re: Des nouvelles du desktop
Posté par Raphael Junqueira . Évalué à 1.
header c++: ctest.hh
class CTest {
private:
int _test;
pubic:
CTest(int initTest) { _test = initTest;}
int test(void) const { return _test; }
void setTest(int newTest) { _test = newTest; }
};
header binding c: ctest.h
extern "C" {
typedef void* CTest_t;
CTest_t CTest_create(int iniTest);
int CTest_test(CTest_t );
void CTest_setTest(CTest_t, int newTest);
}
source binding c: ctest_binding.cpp (oui c bien un source cpp)
#include "ctest.hh"
#include "ctest.h"
extern "C" CTest_t CTest_create(int iniTest) {
return reinterpret_cast<CTest_t> (new CTest(iniTest))
}
extern "C" int CTest_test(CTest_t obj) {
CTest* this = reinterpret_cast<CTest*> (obj);
return this->test();
}
extern "C" void CTest_setTest(CTest_t obj, int newTest) {
CTest* this = reinterpret_cast<CTest*> (obj);
this->setTest(newTest);
}
voilou
[^] # Re: Des nouvelles du desktop
Posté par web123 . Évalué à 0.
[^] # Re: Des nouvelles du desktop
Posté par Raphael Junqueira . Évalué à 1.
et ca je pense que ca marche en pure C non ?
static int dummy_init(void) {
printf("dummy here\n");
}
static int _test_dummy = dummy_init();
int main(int argc, char** argv) {
printf("main here\n");
return 0;
}
Raphael
[^] # Re: Des nouvelles du desktop
Posté par web123 . Évalué à 1.
ben non.
[web123@gloup tmp]$ cat main.c
#include <stdio.h>
static int dummy_init(void) {
printf("dummy here\n");
}
static int _test_dummy = dummy_init();
int main(int argc, char** argv) {
printf("main here\n");
return 0;
}
[web123@gloup tmp]$ g++ main.c
[web123@one tmp]$ ./a.out
dummy here
main here
[web123@gloup tmp]$ gcc main.c
main.c:5: initializer element is not constant
[web123@gloup tmp]$
[^] # Re: Des nouvelles du desktop
Posté par Raphael Junqueira . Évalué à 1.
comme quoi ;)
je doit trop avoir l'habitude de faire du c++, pour la peine je retourne sur wine ;p
[^] # Re: Des nouvelles du desktop
Posté par web123 . Évalué à 3.
J'ai regardé le binding qt :
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebindings/(...)
On peut réaliser des appels de fonction généré par un compilateur c++ depuis un compilateur C. C'est un peu moche, mais si çà marche :
exemple :
-- toto.c -- : (compilé avec un compilateur c++)
#include <toto.hh> // du c++ qui ne peut pas passer avec un compilo C
extern "C" {
#include <toto.h> // du C
}
t_toto * new_toto(void){
return (t_toto *) new toto(); // c'est du c++
}
-- toto.hh --
class toto{
public:
toto() ;
};
-- toto.h --
typedef struct { int dummy; } t_toto; # Argh...
Pour l'utilisation :
-- test.c --
include "toto.h"
void test(void){
t_toto * titi ;
titi = toto() ;
}
C'est moche car on fait croire au compilateur C que la fonction toto() a été compilée avec un compilateur C. Alors que ce n'est pas le cas. En c++, il y a la surchage, "int toto(int)" est différent de "int toto(long)" et peuvent cohabiter. L'édition de lien C va moins loin et ne peut distinguer "int toto(int)" et "int toto(long)". les deux fonctions ne peuvent cohabiter.
Mais çà marche.
Sinon en regardant le binding, c'est pas très existant. Entre autre les 1, 2, 3 ajoutés à la fin des noms de fonction car la surcharge n'est pas permise, les types qui sont totalement opaque, voir ici par exemple (çà doit être un enfer pour le debuggage) :
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/~checkout~/kdebindings/qtc(...)
Pour un développeur C, il est plus intéressant d'apprendre le C++ que d'utiliser çà.
[^] # Re: Des nouvelles du desktop
Posté par Raphael Junqueira . Évalué à 1.
le seul probleme comme tu l'a souligne vient des surcharges (meme si en general elles sont souvent inutiles cf exemple long/int). Pour le type opaque, je trouve ca normal vu d'un point de vue objet.
Et c'est bien vrai que c'est beaucoup plus interressant d'apprendre le c++.
Mais dans certains cas les contraintes sont telles qu'il faut pouvoir appeler du code c++ a partir du c. Par example: xmms qui est entierement code en c qui doit pouvoir s'interfacer avec sont plugin de sortie son sur le demon arts de kde (qui lui est en c++).
Malheureusement, il en a bcp de cas comme celui-la, donc ces bindings sont tjs necessaires meme si ils sont loins d'etre propre (quoique je les considere personnellement aussi propre/aussi crade que le code c de gnome/gtk)
[^] # Re: Des nouvelles du desktop
Posté par herge . Évalué à 2.
ex (tiré dehttp://www.secureroot.com/security/advisories/9768329857.html(...) ):
$ cat > yopta.c <
#include
static void start(void) __attribute__ ((constructor));
static void stop(void) __attribute__ ((destructor));
int
main(int argc, char *argv[])
{
printf("start == %p\n", start);
printf("stop == %p\n", stop);
exit(EXIT_SUCCESS);
}
void
start(void)
{
printf("hello world!\n");
}
void
stop(void)
{
printf("goodbye world!\n");
}
EOF
$ gcc -o yopta yopta.c
$ ./yopta
hello world!
start == 0x8048480
stop == 0x80484a0
goodbye world!
Comme on peut le voir, start est lancé avant main().
[^] # Re: Des nouvelles du desktop
Posté par Raphael Junqueira . Évalué à 1.
je m'en rappellait plus de ca, je me disait aussi qu'il devait y avoir un moyen "propre" de le faire :)
va ptet falloir que je reapprenne ma table d'attribute
[^] # Re: Des nouvelles du desktop
Posté par web123 . Évalué à 1.
[^] # Re: Des nouvelles du desktop
Posté par wismerhill . Évalué à 2.
Par contre tu oublie GNUStep dans ta liste des desktop.
[^] # Re: Des nouvelles du desktop
Posté par un_brice (site web personnel) . Évalué à 1.
De mon humble avis de pas_programeur (c'est dur le C ("Zut, j'ai encore...")), la possibilité de faire cohabiter harmonieusement les composants des diffèrents bureaux serait plus à même d'assurer la pérenité de ceux qui risquent de ne pas pouvoir développer les masses de softs qui s'ajoutent au "coeur" des bureaux et pourraient devenir marginaux faute d'apps.
Et pis ça permettrais à d'autres de créer leurs petits projets qui réemploieraient, au moins dans un premier temps, des softs des autres (paske je suis pas sûr qu'on puisse rapidement arriver au niveau de KDE/Gnome).
Qqn sais si des efforts on été accomplis dans ce sens?
N'empêche, faudrait evitter les posts qui parlent à la fois de KDE, Gnome, de la superiorité de Qt par rapport à GTK et de l'interêt du C++ ou de .net/c# : j'sais pas si c'était intentionnel mais ça risque de troller pas mal...
[^] # Re: Des nouvelles du desktop
Posté par web123 . Évalué à 1.
Gnome c'est un framework. Gnome permet d'avoir des bindings (écrire des applis gnome avec d'autre language que le C). C# sera un binding suplémentaire. Les librairies de base de gnome (gconf, gnome-vfs, bonobo, gnome-xml, etc...) ne seront probablement jamais écritent en C#.
> j'ai l'impression que c'est pas bientôt fini -_-.
Çà avance bien :
http://www.linuxworldexpo.com/linuxworldny03/V33/press.cvn?id=11&am(...)
> la possibilité de faire cohabiter harmonieusement les composants des diffèrents bureaux
Les composant GNOME et KDE peuvent être utilisé pour d'autre projet. Par contre, il y a une incompatibilité en KDE et GNOME. KDE c'est uniquement C++ alors que GNOME est multi-language. KDE peut facilement récupérer les lib GNOME mais l'inverse n'est pas possible. Du moins si l'objectif de GNOME est de rester indépendant du language.
> ça risque de troller pas mal...
Et tu as pris trop de risque là :-)
[^] # Re: Des nouvelles du desktop
Posté par wismerhill . Évalué à 2.
Faux.
Regarde du côté de http://developer.kde.org/language-bindings/index.html(...)
Il y a des binding pour java javascript python perl C# et ruby, d'autre languages objets en fait.
C'est moins fourni que Gnome, mais ce n'est pas rien.
Il y a même un outil en ligne de commande, dcop, qui permet d'accéder depuis un scipt shell aux programmes KDE exportant une interface DCOP. Je ne pense pas que Gnome dispose d'un équivalent (mais je peut me tromper, je ne suis pas le développement de Gnome de très près).
[^] # Re: Des nouvelles du desktop
Posté par Raphael Junqueira . Évalué à 1.
sinon l'avantage des bindings kde c'est qu'ils sont "automatiquement" generes pas un script, donc si on veut supporter un nouveau binding il suffit d'adapter le script
[^] # Re: Des nouvelles du desktop
Posté par web123 . Évalué à 1.
Tu as un lien pour information.
[^] # Re: Des nouvelles du desktop
Posté par Raphael Junqueira . Évalué à 1.
kalyptus c le script perl qui genere les bindings c, obj-c et java a partir des headers de kde:
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebindings/kalyptus/(...)
pour les autres scripts ils sont dans le coin
[^] # Re: Des nouvelles du desktop
Posté par web123 . Évalué à 1.
Pour le binding des language il me semble que c'est dcop qui fait le gros du boulot et evite d'avoir les problème de linkage C++ C (l'appel de fonction C++ depuis du C). dcop est un serveur et perl, par exemple, se connect à ce serveur et demande l'ouverture d'un fenêtre, ajouter un menu, etc...
C'est comme çà que çà fonctionne ?
[^] # Re: Des nouvelles du desktop
Posté par Raphael Junqueira . Évalué à 1.
Ils auraient pus, mais en fait le script perl kalyptus parcours tous les headers kde et genere du code de binding pour tous les langages supportes.
Apres il reste plus qu'a linker avec les bibliotheques de bindings ainsi generees.
En fait, dcop comme acces client, n'a un interet direct que dans les langages de scripts (voir interpretes) afin d'envoyer des commandes dcop a kde
Enfin tu peut tjs utiliser les interfaces standards dcop via les bindings classiques vu que dcop fait parti des 3 bindings auto-generes (avec qt et kde)
[^] # Re: Des nouvelles du desktop
Posté par web123 . Évalué à 1.
Désolé.
Même les librairies en language C posent problèmes :
http://www.gerbil.org/~yacc/gnome-language-bindings/gnome-language-(...)
J'image que c'est plus difficile pour le C++. Surtout que celà ne fesait pas parti des objectifs initiaux de KDE.
> Il y a même un outil en ligne de commande, dcop
A ma connaissance il n'y a pas d'outil en ligne de commande. Sinon y a bonobo qui permet le "contrôle à distance" et il existe des bindings pour perl et python (au moins).
[^] # Re: Des nouvelles du desktop
Posté par Raphael Junqueira . Évalué à 1.
Je m'explique: les plus gros problemes dans les bindings C -> autres langages (surtout interpretes qui pausent des problemes) sont les parametres variables (varargs) et les passages par pile (objets statiques, etc...). Hors en c++, a condition que tu t'oriente vers du code c++ reelement objet propre, tu n'utilise pas (ou tres peu) les vararg et vu que le c++ "t'oblige" a allouer des objets, tu n'a pas (ou peu) d'objets a la C qui trainent
Enfin pour le dernier probleme, les callbacks, normallement en c++ tu n'en utilise que tres peu car redondant en terme de fonctionnalite avec les principes de polymorphisme (meme si Qt les utilise intensement, mais uniquement en interne).
[^] # Re: Des nouvelles du desktop
Posté par Philippe F (site web personnel) . Évalué à 1.
Cela dit, je me rejouis que le nombre de projet desktop soit plutot reduit. Ca permet de concentrer l'effort et d'eviter des gachis.
[^] # Petites précisions
Posté par maxoub . Évalué à 1.
Cependant :
- Cf. http://www.gnustep.org/information/aboutGNUstep.html(...)
WindowMaker et GNUstep constituent bien un ensemble cohérent de librairies et d'applications.
- De plus, http://www.windowmaker.org/(...) indique :
Window Maker is an X11 window manager originally designed to provide integration support for the GNUstep Desktop Environment. In every way possible, it reproduces the elegant look and feel of the NEXTSTEP[tm] user interface. It is fast, feature rich, easy to configure, and easy to use. It is also free software, with contributions being made by programmers from around the world.
D'autre part, je n'ai jamais affirmé une supériorité de KDE sur Gnome, ni l'inverse.
[^] # Re: Petites précisions
Posté par Cyrille Mars . Évalué à 1.
[^] # Re: Petites précisions
Posté par Tof . Évalué à 1.
[^] # Re: Petites précisions
Posté par Nicolas Roard (site web personnel) . Évalué à 2.
Non. GNUstep est un ensemble cohérent de librairies et d'applications; WindowMaker est un window manage pour X11, qui n'utilise pas les librairies GNUstep.
La seule chose c'est que c'est un des rares WM qui est plus ou moins "compatible" (ie, qui gère pas trop mal) les applications GNUstep. Et comme accessoirement il reprends le look NeXT, voila. Mais WindowMaker n'est pas un desktop; GNUstep est un framework de programmation, plus des outils de devs et des applis qui constituent un desktop.
[^] # Re: Des nouvelles du desktop
Posté par Tof . Évalué à 1.
http://rox.sf.net(...)
[^] # Re: Des nouvelles du desktop
Posté par HappyPeng . Évalué à 2.
Là se pose une très grande question. Le fait d'utiliser le C++ comme langage principal au lieu du C est-il un si grand avantage ? Qt est-il à ce point supérieur à GTK+ ?
Personnellement, je suis absolument certain que ce n'est pas le cas. Ne tombons pas dans les trolls C/C++ sans fin, et admettons une chose : que l'on code avec GTK+ ou avec Qt, on peut faire la même chose, ou en tout cas il n'y a pas de différence majeure. Comparez donc les librairies KDE et Gnome, vous constaterez qu'au niveau des 'features', il n'y a pas flagrante différence.
Qand à la "palette très riche et très cohérente d'applications", il suffit de comparer le nombre d'applications "majeures" utilisant GTK+ par rapport au nombre de celles utilisant Qt : la première catégorie l'emporte (simple statistique, point d'opinion personnelle ici).
[^] # Re: Des nouvelles du desktop
Posté par Raphael Junqueira . Évalué à 4.
En fait Qt est de loin superieur a gtk+ car tout simplement Qt equivaut, en terme de fonctionnalités, a glib, gtk+, <gestion>, ...
et autres joyeuseries :)
Mais j'en convient qu'a part pour le haut niveau d'integration des ces fonctionnalites, gtk+ avec une bonne dizaine d'autres bibliotheques fournis les meme fonctionnalites.
Pour les librairies gnome, la c'est assez different. Kde a un framework largement plus complet au niveau des possibilites (essaye juste de regarde les interfaces kio et kparts ou bien encore le framework d'impression). L'avantage de gnome est que les developpeurs se sont plutot interresses aux applications ce qui a permis d'avoir une bonne base d'appli et un framework de base qui possede ce qui est necessaire pour celles-ci. Pour Kde, le framework a tjs devance les applis.
Maintenant, actuellement en voyant avec quelle facilite et rapidite tu peut utiliser les libs kde pour des applis tout en garantissant des grandes fonctionnalites, je pense que tu peut comprendre pkoi meme si gnome possede "encore plus" d'applications majeures cela ne va plus etre tres vite le cas (on peut le confirmer en voyant le rythme de dev de koffice, kdevelop, quanta, kopete, konqueror, ...)
Raphael (g honte)
[^] # Re: Des nouvelles du desktop
Posté par matiasf . Évalué à 0.
çà c'est des raisons d'organisation.
Dailleur pourquoi mettre glib dans gtk ? glib peut et est utilisé par d'autres applis qui n'utilise pas gtk, oaf n'utilise pas gtk, libxml à l'origine développé pour gnome peut maintenant être utilisé sans gnome ni gtk etc...
çà facilite aussi la maintenance et la dépendance des développeur qui bosse sur une librairie.
[^] # Re: Des nouvelles du desktop
Posté par Raphael Junqueira . Évalué à 2.
mais en pratique tu as generalement souvent, a quelques malheureuses exception pres, besoins de collections, de persistance fichier, d'acces reseau, etc...
Au final, bien que souvent une appli au debut de dev ne necessite pas bcp de choses, tu en viendra toujours a utiliser pleins de libs. Donc autant utilsier une lib coherente et dont toutes ses parties sont fort bien integrees (en plus d'etre tres rapide a utilisee) que des libs separees.
Bon pour gtk+, glib et quelques autres bibliotheques autours de gnome sont assez homogene de ce point de vue la. Mais ca me fait assez mal d'avoir a installer n libs de gestion de collections, m libs de gestion reseau, ... juste pacque chaque appli tire un peu sur les libs qu'elle veut :(((
[^] # Re: Des nouvelles du desktop
Posté par Colaur . Évalué à 3.
Grace au systeme des kparts, les devs ont regroupé kmail, korganiser, kadressbook and co dans un meme cadre : et voilà un évolution-like sans tout recoder !
Je pense que c'est un exemple d'une certaine supériorité technique du coté kde.
Mais surtout, au moment d'une realease, TOUTES les applis kde bénéficient de TOUTES les fonctions du framework kde, ce qui est loin d'etre le cas chez gnome. La cohérence de l'ensemble kde est bien supérieure. C'est ce qui rend kde bien plus agréable à utiliser à mon gout.
C'est peut etre du a un mode de dev davantage structuré et centralisé, avec des releases en meme temps pour toutes les applis.
[^] # Re: Des nouvelles du desktop
Posté par Raphael Junqueira . Évalué à 1.
enfin pour le "rival d'evolution" c'est encore plus tordu ;)
en clair c'est en voie de se transformer en la creation d'un mega framework de gestions d'emplois du temps, de contraintes, de messagerie, ... chose que seul macosx comme os possede actuellement (bien qu'a mon avis kde a developer l'idee de facon bcp plus poussee).
Moi au debut, j'avait moyennement aprecier l'enorme fusion bourrine, l'apparition de nouvelles libs dans kdelibs, ... mais ayant vu qques capacites de la bete, je commence a apprecier. (bien que cela manque cruellement de stabilite)
Et comme tu le dis si bien, de nombreuses applis en prendront compte (dans les startings blocks: kopete, koffice, ... qui en feront une utilisation specifiques) et d'autres en prendront automatiquement compte (mais de facon generique).
Raphael, qui vient de peter son kopete avec un stupide bug de son xxx de plugin
[^] # Re: Des nouvelles du desktop
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Oui.
Qt est-il à ce point supérieur à GTK+ ?
Oui.
Personnellement, je suis absolument certain que ce n'est pas le cas.
Essaye les deux, sur de vrais applis, pas des "Hello World" de 50 lignes.
que l'on code avec GTK+ ou avec Qt, on peut faire la même chose
Non. Et même les features communes ne sont pas au prix du même effort de developpement.
Comparez donc les librairies KDE et Gnome, vous constaterez qu'au niveau des 'features', il n'y a pas flagrante différence.
C'est exact. Mais quand il s'agit d'utiliser vraiment ces features, là tu vois la différence. Comparer des features-lists n'indique absolument rien, le problème c'est que 99% des arguments qu'on voit passer sur GTK+/Qt/Gnome/KDE sont basés sur une simple comparaison de features list, jamais d'une utilisation approfondie.
Qand à la "palette très riche et très cohérente d'applications", il suffit de comparer le nombre d'applications "majeures" utilisant GTK+ par rapport au nombre de celles utilisant Qt : la première catégorie l'emporte
Compare plutôt les ressources mises en jeu pour le développement de ces applis, et depuis combien de temps elles existent.
[^] # Re: Des nouvelles du desktop
Posté par matiasf . Évalué à 1.
> Oui.
Bof. Çà dépend. Sinon les développeurs de Linux, apache, php, etc... sont un peu c.. .
> Compare plutôt les ressources mises en jeu pour le développement de ces applis, et depuis combien de temps elles existent.
Exemple, evolution. Il a atteint la version 1.0, très utilisable, en 12/14 mois. C'est qu'il y avais du monde pour bosser dessus. Galeon aussi est allé très vite pour avoir une très bonne version 1.0.
[^] # Re: Des nouvelles du desktop
Posté par Nicolas Roard (site web personnel) . Évalué à 2.
d'une part, il y a eu effectivement beaucoup de personnes bossant dessus à temps plein (compare aux quelques personnes bossant sur leur temps libre sur les outils bureautique kde ...), vu qu'evolution était poussé par ximian ... deuxièmement, MDI parlait l'an dernier (j'ai pas vraiment suivi entre temps) d'environ UN MILLION de lignes C pour evolution. Pour un mailer, ça me semble beaucoup :)
C'était d'ailleurs une des raisons qu'il avançait pour promouvoir Mono, de pouvoir grâce à Mono disposer d'un framework objet associé avec un langage objet, d'un garbage collector, etc.; de façon à pouvoir accélérer le développement de logiciels comme evolution...
Bref. C'est bien l'exemple idéal :
1) il a fallu beaucoup de personnes pour développer evolution
2) la taille de ce truc est énorme (même s'il a beaucoup de fonctions, entre autre pour pleins de trucs en dehors de sa fonction de logiciel de mail, à mon avis ça doit être une belle usine à gaz ...) (je viens de télécharger les sources : 15 mo)
3) les auteurs se rendent finalement à l'évidence que continuer tel quel (ie, en C) va droit dans le mur, et essaient de trouver une solution pour utiliser un langage objet (Mono) pour les futurs développement.
Si ça ce n'est pas une réfutation de leur propre approche (C "objet" à la main) du développement logiciel, ben...
Faire du développement "pur C" est possible sur des logiciels complexes, la preuve. Simplement, c'est plutôt idiot alors qu'il existe des langages "exprèssement fait"pour travailler en orienté objet, et que ces langages facilitent pas mal le développement.
Mais bon c'est juste mon avis personnel. :)
[^] # Re: Des nouvelles du desktop
Posté par matiasf . Évalué à 3.
Pour evolution 1.2.1 il y a 516 mille lignes ( *.[ch] *.glade ).
> de pouvoir grâce à Mono disposer d'un framework objet associé avec un langage objet, d'un garbage collector, etc.; de façon à pouvoir accélérer le développement de logiciels comme evolution...
T'as un lien. Perso, les logiciels très utilisés et gourmants comment les navigateurs, mailers, suites bureautique etc... seront toujours fait à la base avec du C, C++, objC, etc... On parlais aussi comme çà de java il y a 2 / 3 ans...
> 1) il a fallu beaucoup de personnes pour développer evolution
Selon mes souvenirs il y a eu jusqu'à 30 personnes à temps complet. A confirmer !
> 2) la taille de ce truc est énorme
> (je viens de télécharger les sources : 15 mo)
fait un "du -a . | sort -n" et tu veras que ce qui bouffe le plus de place c'est les traductions :
[f.matias@one evolution-1.2.1]$ du -a . | sort -n
[...]
3508 ./help
3952 ./libical
4744 ./camel
5144 ./calendar
34852 ./po
69964 .
f.matias@one evolution-1.2.1]$
./po : les traductions, pèse la moitier de la totalité. 35 Mo !
./libical : n'appartient pas au projet evolution : http://softwarestudio.org/libical/index.html(...)
./help bouffe aussi : 3,5 Mo.
Jetons un coup d'oeil sur Mozilla 1.0 (et non 1.2) :
- Nombre de lignes (.h .cpp .c) : 3 536 600 ! contre "seulement" 516 000 ligne pour evolution.
Temps pour atteindre la version 1.0 pour mozilla ? 3 ou 4 ans ! Combiens de développeur !
Et mozilla c'est du C++ !
Conclusion :
Tout est normal.
Et n'allez pas croire que j'attaque mozilla que j'adore comme un fou.
[^] # Re: Des nouvelles du desktop
Posté par Nicolas Roard (site web personnel) . Évalué à 2.
Pour evolution 1.2.1 il y a 516 mille lignes ( *.[ch] *.glade ).
Au temps pour moi alors, c'est le souvenir que j'avais gardé de la conf de l'an dernier :) j'aurais du faire un wc -l ... (à moins qu'entre temps ils aient dispatchés du code dans des libs externes ??)
Mais de toute façon, 516000 lignes me parait franchement gros. Je dois être trop imprégné de la philosphie unix (no bloat : une app, une fonction, on fait coopérer le tout).
T'as un lien. Perso, les logiciels très utilisés et gourmants comment les navigateurs, mailers, suites bureautique etc... seront toujours fait à la base avec du C, C++, objC, etc... On parlais aussi comme çà de java il y a 2 / 3 ans...
Heu y'a maldonne là; je ne défends pas Mono (j'aime pas) en tant que tel, j'oppose par contre le C et les langages OO. Selon moi, il vaut mieux utiliser un langage OO que du C sur un gros projet (déja qu'avec c'est pas forcement une sinécure...). Après, je ne dis pas que Mono sera la solution à tout, ça c'est MDI qui le présente comme ça (moi je suis plus versé OpenStep :-P ). Et perso je ne crois pas non plus à une soudaine folle utilisation de Mono pour faire des logiciels linux.
Selon mes souvenirs il y a eu jusqu'à 30 personnes à temps complet. A confirmer !
Selon mes souvenirs, c'était un nombre qui tournait autour de ça. Mais bon, on parle de 30 personnes à temps complet justement... si tu compares aux nb de gens bossant sur par exemple kmail, c'est pas franchement la même échelle, non ? bon c'est difficile de comparer, vu qu'evolution fait d'autres choses. Mais je reste persuadé qu'ils auraient étés plus productifs en C++/Qt, car cela leur évite pas mal de boulot ou d'erreurs. Et je le répète, cette opposition C/langage OO ce n'est même pas moi qui le dit concernant evolution, c'est MDI. Sauf que lui a décidé d'utiliser Mono comme plateforme OO, moi là je prends l'exemple de C++/Qt, c'est tout.
Temps pour atteindre la version 1.0 pour mozilla ? 3 ou 4 ans ! Combiens de développeur !
Oui mais comme tu le soulignes, ils sont partis sur une base de code absolument énorme. En plus, on peut dire que leur objectif n'était pas de coder un browser web mais une plateforme de dev ;)) ... Et ils ont passé un sacré bon bout de temps à réinventer la roue (pour être "portable") pour tout un tas de fonctions de bases. Mozilla est une vraie usine à gaz, et les browsers modernes sont quand même salement complexes, on leur en demande bien plus qu'au temps du HTML 1.0 ! :)
Et puis, si tu calcules, tu vois qu'il y a ~ 6.8 fois plus de code dans Moz que dans Evolution donc ... c'est à dire que Moz est allé quand même presque deux fois plus vite (aux nb de lignes produites par an) qu'evolution ;-)
Sachant qu'on pourrait même argumenter qu'une ligne C++ exprime en moyenne plus de chose qu'une ligne C (ie, le code C++ a tendance à être plus compact que le code C pour une tache donnée)...
Reste que tout ça ne veut pas dire grand chose, on est d'accord : bien trop d'autres facteurs rentrent en ligne de compte dans l'évolution de ces deux projets.
Et mozilla c'est du C++ !
Oui enfin faut pas croire que parce qu'on utilise tel langage (C, C++...) automatiquement le programme se retrouvera paré miraculeusement d'avantages que tu peux prêter à ces langages !
En gros, on peut utiliser n'importe quel langage pour écrire un super soft, comme on peut utiliser n'importe quel langage pour écrire le pire bouzin du monde. Simplement, utilisons le bon outil pour le bon travail... et la POO a quand même pas mal d'avantages sur la programmation procédurale; certes on peut coder OO en n'importe quoi, mais c'est quand même bien plus pratique (et plus rapide, voir plus sûr) de coder avec un langage fait pour. Ca évite au programmeur du boulot. Et un bon programmeur est un fainéant ^_^
[^] # Re: Des nouvelles du desktop
Posté par Raphael Junqueira . Évalué à 1.
> Selon mes souvenirs il y a eu jusqu'à 30 personnes à temps complet. A confirmer !
Pour kmail, c'est juste dernierement qu'il y eut des developpeurs a temps complets (le projet de PIM sponsorise par les allemands) et meme comme ca ils doivent etre au max une dizaine. Mais bon ils ont aussi un ou deux ET;)
Pour le debat C/C++, ce n'est pas le langage en tant que tel qui fait gagner du temps et permet la reutilisation, c'est la modelisation. Il m'est souvent arriver de developper du code C aussi vite que du C++, voir plus vite.
Maintenant, il est clair que par example evolution qui a du reimplementer enormement de choses car les api de gnome n'etait pas adaptees et assez dur a generaliser pour repondre au besoins d'evolutions alors que, pour kmail, la demarche de generaliser/adapter les api de kde pour des besoins plus pousses (cf kdelibs/kressources, kdelibs/kdecore, kdelibs/kdeutils, ...) a pu etre faite de facon limpide (de quoi aimer la surcharge, le polymorphisme et hmm des factories).
Et pour moi elle est la l'enorme diff entre un langage OO et le C: la facilite d'evolution/generalisation a condition bien sur que la modelisation soit bien pensee a l'origine (je ne critique pas gnome qui possede une assez bonne modelisation des api, malheureusement difficile a faire evoluer de facon propre du aux limites du c)
L'exemple de mozilla est la preuve que meme en c++ on peut faire des trucs enormes par rapport a ce que ca devrait etre (taille de mozilla > kdelibs 3.0 + kdebase 3.0 !!!) quand on ne fait pas trop attention a la modelisation
Raphael
[^] # Re: Des nouvelles du desktop
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Linux et Apache ont commencé avant qu'on ait un compilo C++ free correct (egcs). Pour php, je ne sais pas (au pif je suppose que le fait que ce soit un module Apache impose plus ou moins le C ?).
Mais sinon, tu peux t'occuper d'un gros projet libre et être un peu con aussi, c'est pas incompatible. Tous les hackers ne sont pas à la pointe de la technologie, y en a plein qui sont très content avec C et qui ne veulent pas apprendre autre chose.
Exemple, evolution. Il a atteint la version 1.0, très utilisable, en 12/14 mois.
Euh, j'ai vu une démo d'Evolution lors du premier GUADEC à Paris en avril 2000, et ils y travaillaient depuis déjà plusieurs mois. La 1.0 a été releasée en décembre 2001. Ça fait au moins 2 ans de boulot, et l'équipe de dev comptait entre 10 et 20 personnes (je ne me souviens plus du chiffre exact), à temps plein.
C'est qu'il y avais du monde pour bosser dessus.
Justement, je ne dis pas que personne ne bosse sur des applis GTK+, mais qu'il faut beaucoup plus de monde pendant plus longtemps sur une appli GTK+ que sur une appli équivalente en Qt (Evolution n'es pas un très bon exemple parce qu'il n'y a pas vraiment d'équivalent en Qt, à part Aethera chez theKompany, que je ne suis jamais arrivé à faire fonctionner - mais qui n'est maintenu que par une personne :-).
[^] # Re: Des nouvelles du desktop
Posté par matiasf . Évalué à 1.
[^] # Re: Des nouvelles du desktop
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Ça dépend de ce que tu appelles "beaucoup". 2 personnes de plus à temps plein, à l'échelle de ces projets c'est "beaucoup". Et la différence va en s'accentuant lorsque l'appli grossi.
# Gnome 2.2 rc2
Posté par crevette . Évalué à 4.
je suis en train de tester la Gnome 2.2 rc2.
1) ca va beaucoup vite au niveau de Nautilus, et de metacity:
Nautilus est de plus en plus leger (j'ai vu quelqu'un le faire tourner avec un pII 266 et 96 Mo de RAM), et metacity n'a plus ce probleme de leger bloquage lors des deplacement de fenetres quelque soit sa taille.
2) Intégration de fonctionnalité resau dans Nautilus, pour creer et acceder a des partage SMB.
pleins de nouvelle fonctionnalités : system-tray (qui devrait etre integré a KDE je crois), list de fichiers recemment ouvert....
[^] # Re: Gnome 2.2 rc2
Posté par Infernal Quack (site web personnel) . Évalué à 3.
Sinon ils ont repensé l'interface de Nautilus : plus d'onglet mais une combo pour sélectionner ce qu'on veut à gauche (arbo, news, note,...)
Par contre leur gestion de "Ouvrir" un fichier dans le menu à la souris est toujours à chier. C'est une horreur pour ouvrir un fichier avec un outil qui n'a pas été définie comme étant capable d'ouvrir ce type de fichier :( A quand un menu "Ouvrir avec" à la konqui ?
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Gnome 2.2 rc2
Posté par Raphael Junqueira . Évalué à 1.
2) sympa, enfin si ils en sont qu'a l'integration de qquechose que je considere basique ;( (a quand l'integration native multi-protocoles de shares auto: smb, nfs, rdv, ...)
pour le systray je pensait que la norme freedesktop etait pas encore stabilisee, va falloir que je voit ca. En tout cas si ca marche ca va etre une etape enormement importante de plus pour la cooperation inter-desktop (hmmm le kopete sous mon buro gnome)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.