Articles précédents : Articles
- [85] Le Monde défend le « piratage privé »
- [16] Linuxworld, c'était mieux avant ?
- [25] Génération de clefs à partir du bruit électrique de la puce
- [41] Des milliers de personnages virtuels pour la bataille d'Helm
- [7] Linux sur des téléphones portables
- [17] Fujitsu et Intel s'allient dans les serveurs Linux
- [50] Un point c'est tout.
- [72] IBM présente TCPA "tel qu'il aurait dû être"
- [29] SCO revendique des droits sur Linux
- [4] Linux au 7ème ciel
Liens connexes
- KDE-PIM Hackfest : short summary report (560 hits)
- libgda/libgnomedb/mergeant 0.10.0 released (506 hits)
- KOffice 1.3 release schedule (524 hits)
- Desktop Enhancements! (1458 hits)
- Learn to use GNOME (668 hits)
- KDE Dot News (463 hits)
Dépêche modérée par
Articles : Des nouvelles du desktop
Posté par Nÿco (Jabber id, page perso, ). Modéré le 29 janvier 2003.
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.
![[en]](../../../images/en.png)
KDE-PIM Hackfest : short summary report (560 hits)-
libgda/libgnomedb/mergeant 0.10.0 released (506 hits)
-
KOffice 1.3 release schedule (524 hits)
-
Desktop Enhancements! (1458 hits)
-
Learn to use GNOME (668 hits)
-
KDE Dot News (463 hits)
> Lire les commentaires (91 commentaires, moyenne: 1,7).
XFree 4.2.99
A noter aussi que XFree4.3 (pas encore sorti) ajoute un meilleure gestion du curseur avec possibilité d'utiliser des thèmes, animation, transparence,....
Cf http://www.kde-look.org/content/show.php?content=4805(...)
C'est mon desktop qui est heureux :)
-
[^]Re: XFree 4.2.99
Posté par Infernal Quack (Jabber id, page perso, ) le 29/01/2003 à 14:07. (lien). Évalué à 3.D'ailleurs http://jimmac.musichall.cz/i.php3?ikony=71(...)
J'aime bien la remarque sur IE (qui sux)
-
[^]Re: XFree 4.2.99
Posté par FRLinux (page perso, ) le 29/01/2003 à 14:27. (lien). Évalué à 3.En parlant de XFree 4.3.a_venir, Mandrake et RedHat ont commence a utiliser ce concept de curseurs transparents.
Steph-
[^]Re: XFree 4.2.99
Posté par Cyril (page perso, ) le 29/01/2003 à 18:03. (lien). Évalué à 1.manque plus que le support de l'alpha sur les fenêtres elle mêmes (avec une petite accélération matériel pour que sa chie bien) pour pouvoir avoir une gui aussi belle que celle de Mac OS X ;-)
-
[^]Re: XFree 4.2.99
Posté par Merlin Lenchanteur () le 29/01/2003 à 18:18. (lien). Évalué à 1.Tu peux utiliser DirectFB pour ca.
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 (page perso, ) le 29/01/2003 à 19:29. (lien). Évalué à 1.Et surtout affreusement pas stable à mon avis :-(
-
-
-
-
[^]Re: XFree 4.2.99
Posté par matiasf () le 29/01/2003 à 15:40. (lien). Évalué à 3.Il me semble qu'il devait y avoir dans peu de temps la possibilité de changer la résolution à la volée. Je ne parle pas de <ctrl><alt><+> ou <->. Je parle d'un système à la windows. Le plus gros avantage est de permettre à l'utilisateur de changer de résolution sans être root.
-
[^]Re: XFree 4.2.99
Posté par wismerhill (page perso, ) le 29/01/2003 à 16:02. (lien). Évalué à 2.Je comprend pas bien ta remarque.
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 () le 29/01/2003 à 16:19. (lien). Évalué à 5.Par exemple sous Windows lorsque tu changes la résolution, tu changes aussi la taille du bureau. Ctrl-Alt-[+-] ne change pas la taille du bureau. De plus, sous X11, il faut changer /etc/X11/XF86config (être root) et redémarrer X11 (donc fermer les applis etc...).
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 (page perso, ) le 29/01/2003 à 16:47. (lien). Évalué à 3.Mais c'est très bien comme ça!
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 () le 29/01/2003 à 16:51. (lien). Évalué à 2.Je ne domande pas de remplacer le fameux <ctrl><alt><+> ou <-> !
> 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 () le 29/01/2003 à 16:59. (lien). Évalué à 1.Çà marche aussi si xdm est lancé ?
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 () le 29/01/2003 à 17:11. (lien). Évalué à 4.Je recommence.
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 () le 29/01/2003 à 18:09. (lien). Évalué à 1.Je recommence.
À 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 () le 29/01/2003 à 18:52. (lien). Évalué à 3.Çà ne peut pas marcher car il faut relancer X11. Pour relancer X11, il faut tuer gdm qui a récupéré ton login. A moins de stocker des infos temporaires dans un fichier ou de les envoyer au gdm père. Afin, pour les terminaux c'est encore plus problématique (même si c'est sous GNU/Linux). gdm n'étant pas le père du serveur. Le process gdm doit alors "dire" à l'autre machine de relancer X11.
-
[^]Re: XFree 4.2.99
Posté par HappyPeng () le 29/01/2003 à 19:47. (lien). Évalué à 1.Effectivement. Dans ce cas, je corrige mon information : pourquoi ne pas pouvoir relancer le serveur X depuis GDM si l'on souhaite modifier ce paramètre ? (par ex. le relancer en ouvrant la session)
-
[^]Re: XFree 4.2.99
-
-
[^]Re: XFree 4.2.99
Posté par Vivi (page perso, ) le 30/01/2003 à 10:05. (lien). Évalué à 1.Pour relancer X11, il faut tuer gdm qui a récupéré ton login.
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 Jak () le 29/01/2003 à 16:31. (lien). Évalué à 1.Non, le problème du Ctrl-Alt-[+/-], c'est que ça ne change pas la résolution du bureau, mais seulement celle de l'écran. Et franchement, ce n'est pas ce qu'il y a de plus pratique. Cela dit, je m'en contente tout-à-fait, vu que je n'ai pas besoin de changer de résolution toutes les 5 minutes. Même chose d'ailleurs pour la profondeur de couleurs. Ça n'est pas primordial (Oui, Windows peut le faire, et après ? ça ne me servait pas non plus quand j'utilisais Windows, alors bon ...).
--
« Le savoir, n'est-ce pas, est un bien précieux. Trop précieux pour ne pas être partagé. »
- Battologio d'Epanalepse, in De Cape et de Crocs, Acte VII (Ayroles & Masbou)-
[^]Re: XFree 4.2.99
Posté par Infernal Quack (Jabber id, page perso, ) le 29/01/2003 à 16:40. (lien). Évalué à 2.Si c'est très utile pour tester l'utilisabilité d'une aplli en 800x600 ou d'un site-web.
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-
[^]Re: XFree 4.2.99
-
[^]Re: XFree 4.2.99
Posté par Nÿco (Jabber id, page perso, ) le 29/01/2003 à 17:20. (lien). Évalué à 2.ah oué, cool ! ça peut même servir à d'autres trucs...
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(...)--
Jabber ID : xmpp:Nyco@jabber.fr
-
-
-
[^]Re: XFree 4.2.99
Posté par web123 () le 29/01/2003 à 16:57. (lien). Évalué à 1.Pour évaluer cette fonctionnalité, il ne faut pas penser à son PC perso. Quand t'es en entreprise, on te file un PC sous windows et tu peux changer de résolution sans demander un compte admin, sans déranger l'admin, sans changer la configuration de celui qui bosse aussi parfois sur ce PC. Certains supportes le 1600x1200, d'autre n'y vois rien, etc...
Pour mon PC "à la maison" c'est vrai que j'en ai à foutre.-
[^]Re: XFree 4.2.99
Posté par Annah C. Hue (page perso, ) le 30/01/2003 à 07:53. (lien). Évalué à 3.Évidemment, sous windows l'utilisateur peut péter tout le système facilement, sans déranger l'admin, alors changer de résolution n'est qu'une fonctionnalité parmis d'autres.
-
-
-
[^]Re: XFree 4.2.99
Posté par Mathieu Pillard (page perso, ) le 29/01/2003 à 16:36. (lien). Évalué à 2.ca devient lourd, a chaque fois la meme remarque...
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 () le 29/01/2003 à 16:47. (lien). Évalué à 2.Cette remarque est fortement incomplète. En effet le système actuel permet à l'administrateur (root) de décider à quelles résolutions va pouvoir accéder l'utilisateur (évitant ainsi à ce dernier de faire la configuration, voir de déteriorer le matériel, etc.) ce qui est très "Unix-like" (les utilisateurs ne configurent pas le matériel) ; je trouve cela plutôt positif.
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
Au moins, au niveau des desktop, il n'y a pas une prolifération de projets concurrents comme c'est le cas pour les window-manager, les clients mails et autres editeurs de texte... puisqu'il n'y a que 3 desktops : Gnome, KDE et WindowMaker.
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.
-
[^]Re: Des nouvelles du desktop
Posté par alenvers () le 29/01/2003 à 15:56. (lien). Évalué à 1.Décidément, je ne comprendrai jamais rien aux gestionnaires de desktop...
Moi, j'estime que fluxbox et X permette de gérer mon desktop.
Pour ma part, Gnome et KDE n'apporte que de la lenteur et de la lourdeur (par contre leurs toolkits respectifs sont exploitable, d'ailleur j'utilise galeon, le panel de gnome et bcps d'applics...). Windowmaker ne m'a jamais plu (avis personnel).
Les applics, je dis OUI, les usines à gaz NON ! Laissez mon P200 souffler !-
[^]Re: Des nouvelles du desktop
-
[^]Re: Des nouvelles du desktop
Posté par web123 () le 29/01/2003 à 16:31. (lien). Évalué à 3.Plus important que le desktop, GNOME et KDE permet de faire de bonne appli :
- galeon
- evolution
- kmail
- kdevelopper
- gnucash
- etc...
Si tu utilises une de ces applis, tu utilise GNOME ou KDE (même sous fluxbox).-
[^]Re: Des nouvelles du desktop
Posté par alenvers () le 29/01/2003 à 16:53. (lien). Évalué à 0.J'utilise des librairies pas un gestionnaire de desktop...
-
[^]Re: Des nouvelles du desktop
Posté par Infernal Quack (Jabber id, page perso, ) le 29/01/2003 à 17:07. (lien). Évalué à 3.Justement.
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 :)-
[^]Re: Des nouvelles du desktop
Posté par alenvers () le 29/01/2003 à 17:47. (lien). Évalué à 0.Une libraire partagée c'est fait pour être partagé. Mais dès qu'un gnome-session est lancé ca rame !
-
[^]Re: Des nouvelles du desktop
Posté par wismerhill (page perso, ) le 29/01/2003 à 18:06. (lien). Évalué à 1.Ouais, c'est même pire avec KDE.
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 (page perso, ) le 29/01/2003 à 16:52. (lien). Évalué à 2.Les applics, je dis OUI, les usines à gaz NON ! Laissez mon P200 souffler !
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 !-
[^]Re: Des nouvelles du desktop
Posté par alenvers () le 29/01/2003 à 17:00. (lien). Évalué à 3.Meme sur une machine plus puissant c fluxbox. Le mail mutt/fetchmail/procmail/spamassassin (mutt via ssh c'est quand meme plus pratique). Editeurs xemacs et vim.
Le dragNdrop ? Filemanager ? Pour quoi faire ? Bash et raccourcis c'est plus rapide Tab-tab et retab et !wmc pour les trucs indispensables...
Gravure ? 4 lignes de bash et cdrecord (écrit une fois utilisé beaucoups).
Et pourtant, j'ai commencé comme beaucoup par Haïr la ligne de commande. Mais désolAI, j'AI pas trouvé mieux pour le moment...-
[^]Re: Des nouvelles du desktop
Posté par Infernal Quack (Jabber id, page perso, ) le 29/01/2003 à 17:10. (lien). Évalué à 0.Normal si tu essayes pas de voir ailleurs :)
-
[^]Re: Des nouvelles du desktop
Posté par alenvers () le 29/01/2003 à 17:49. (lien). Évalué à 1.Et pourtant, j'ai commencé comme beaucoup par Haïr la ligne de commande. Mais désolAI, j'AI pas trouvé mieux pour le moment...
Il me sembalit que c'était explicite : j'ai vu ailleur.-
[^]Re: Des nouvelles du desktop
Posté par Infernal Quack (Jabber id, page perso, ) le 29/01/2003 à 18:05. (lien). Évalué à 1.Si tu as commencé avec les interfaces graphiques il y a 5 ans et depuis tu as arrêté c'est normal. Depuis çà a beaucoup progressé ;)
Et puis c'est pas incompatible. Personnellement j'ai toujours konsole de lancé sur mon KDE :)-
[^]Re: Des nouvelles du desktop
-
-
-
-
-
-
-
[^]Re: Des nouvelles du desktop
Posté par Nicolas Roard (page perso, ) le 29/01/2003 à 16:00. (lien). Évalué à 3.puisqu'il n'y a que 3 desktops : Gnome, KDE et WindowMaker.
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 () le 29/01/2003 à 16:36. (lien). Évalué à 2.> Finalement MDI se rends compte qu'utiliser un langage orienté objet avait quelques avantages par rapport au C
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 (page perso, ) le 29/01/2003 à 17:18. (lien). Évalué à 0.Faux!!!
car tu peut tjs passer par un binding C++->C-> langage au pire :)-
[^]Re: Des nouvelles du desktop
Posté par web123 () le 29/01/2003 à 17:46. (lien). Évalué à 3.> un binding C++->C
?!
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 (page perso, ) le 29/01/2003 à 18:12. (lien). Évalué à 1.bon un exemple (approximatif) pipo
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 () le 29/01/2003 à 19:33. (lien). Évalué à 0.J'avais oublié qu'on pouvait faire du C avec un compilateur C++. L'appel de fonction C++ ne marchant pas depuis un programme compilé par un compilateur uniquement C. De même les objet statiques peuvent exécuter du code avant la fonction main() ce qui n'est pas possible en "pure" C.
-
[^]Re: Des nouvelles du desktop
Posté par Raphael Junqueira (page perso, ) le 29/01/2003 à 20:39. (lien). Évalué à 1.ben vi c assez simple ;)
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 () le 29/01/2003 à 21:25. (lien). Évalué à 1.> et ca je pense que ca marche en pure C non ?
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 (page perso, ) le 29/01/2003 à 21:48. (lien). Évalué à 1.oki,
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 () le 29/01/2003 à 22:45. (lien). Évalué à 3.> L'appel de fonction C++ ne marchant pas depuis un programme compilé par un compilateur uniquement C.
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 (page perso, ) le 29/01/2003 à 23:03. (lien). Évalué à 1.ben c bien comme je l'avait explique au-dessus.
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 () le 30/01/2003 à 04:44. (lien). Évalué à 2.Si si c'est possible. Il faut utiliser les ctors.
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 (page perso, ) le 30/01/2003 à 10:09. (lien). Évalué à 1.joli :)
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
-
-
-
-
-
-
-
-
[^]Re: Des nouvelles du desktop
Posté par wismerhill (page perso, ) le 29/01/2003 à 16:06. (lien). Évalué à 2.Revois la définition d'un desktop sur freedesktop.org (http://www.freedesktop.org/desktops/(...)), WindowMaker n'est pas un desktop complet (il n'a pas de framework), c'est cependant plus qu'un simple gestionnaire de fenêtre.
Par contre tu oublie GNUStep dans ta liste des desktop.
-
[^]Re: Des nouvelles du desktop
Posté par Brice Arnould ( un_brice ) (page perso, ) le 29/01/2003 à 16:16. (lien). Évalué à 1.Je suis pas sûr que de pouvoir utiliser des trucs à la .net/c# va accèlerer le dvpt de Gnome ("Zut, j'ai marché dedans!"). Et puis je connais pas le projet mais j'ai l'impression que c'est pas bientôt fini -_-.
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...--
Respect à RMS.-
[^]Re: Des nouvelles du desktop
Posté par web123 () le 29/01/2003 à 16:48. (lien). Évalué à 1.> .net/c# va accèlerer le dvpt de Gnome
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 (page perso, ) le 29/01/2003 à 16:59. (lien). Évalué à 2.KDE c'est uniquement C++
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 (page perso, ) le 29/01/2003 à 17:21. (lien). Évalué à 1.y a la meme chose avec bonobo, mais tjs est il que dcop est bcp plus utilisable que bonobo (encore trop proche de corba a mon gout)
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 () le 29/01/2003 à 17:49. (lien). Évalué à 1.> ils sont "automatiquement" generes pas un script
Tu as un lien pour information.-
[^]Re: Des nouvelles du desktop
Posté par Raphael Junqueira (page perso, ) le 29/01/2003 à 18:27. (lien). Évalué à 1.voilou, j'ait faillit ne pas voir ton reply a cause de mon mozilla qui delire (vivement que je rentre chez moi)
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 () le 29/01/2003 à 20:35. (lien). Évalué à 1.Corrige moi si je dis une connerie car je ne connais pas très bien KDE.
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 (page perso, ) le 29/01/2003 à 20:48. (lien). Évalué à 1.non ;)
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 () le 29/01/2003 à 17:39. (lien). Évalué à 1.> Faux.
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 (page perso, ) le 29/01/2003 à 18:35. (lien). Évalué à 1.en fait du point c++ c'est plus facile.
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 Fremy (page perso, ) le 29/01/2003 à 16:50. (lien). Évalué à 1.Cherche desktop sur sourceforge et sur freshmeat, et tu dechanteras. Deja, a chaud, tu peux ajouter enlightment a ta liste.
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 () le 29/01/2003 à 16:50. (lien). Évalué à 1.Je reconnais que c'est un peu maladroit de dire que WindowMaker est un "desktop" au même titre que Gnome et KDE.
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 (page perso, ) le 29/01/2003 à 16:58. (lien). Évalué à 1.et ROX ? il est parfait ROX (http://rox.sourceforge.net/(...)) leger, rapide, complet vraiment bien quoi.
-
[^]Re: Petites précisions
Posté par Christophe Badoit (page perso, ) le 29/01/2003 à 17:03. (lien). Évalué à 1.Mouarf posté en même temps.. !
-
-
[^]Re: Petites précisions
Posté par Nicolas Roard (page perso, ) le 29/01/2003 à 17:51. (lien). Évalué à 2.WindowMaker et GNUstep constituent bien un ensemble cohérent de librairies et d'applications.
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 Christophe Badoit (page perso, ) le 29/01/2003 à 16:57. (lien). Évalué à 1.Euh, y'a rox aussi, qui peut se limiter à un file-manager (comme gmc) ou etre un desktop complet (sessions, panel, punaiseurs, docklets, ...).
http://rox.sf.net(...)
-
[^]Re: Des nouvelles du desktop
Posté par HappyPeng () le 29/01/2003 à 16:57. (lien). Évalué à 2.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.
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 (page perso, ) le 29/01/2003 à 17:32. (lien). Évalué à 4.arf ca va troller, enfin bon
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 () le 29/01/2003 à 18:09. (lien). Évalué à 0.> glib, gtk+, <gestion>, ...
çà 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 (page perso, ) le 29/01/2003 à 18:19. (lien). Évalué à 2.C'est un argument,
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 Martien () le 29/01/2003 à 18:25. (lien). Évalué à 3.Ben par exemple on a bcp dit qu'il n'y avait pas de rival à évolution coté kde.
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 (page perso, ) le 29/01/2003 à 20:58. (lien). É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 (page perso, ) le 29/01/2003 à 23:09. (lien). Évalué à 1.Le fait d'utiliser le C++ comme langage principal au lieu du C est-il un si grand avantage ?
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 () le 30/01/2003 à 00:03. (lien). Évalué à 1.> > Le fait d'utiliser le C++ comme langage principal au lieu du C est-il un si grand avantage ?
> 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 (page perso, ) le 30/01/2003 à 01:36. (lien). Évalué à 2.evolution ? exemple idéal oui :)
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 () le 30/01/2003 à 02:32. (lien). Évalué à 3.> d'environ UN MILLION de lignes C pour evolution.
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 (page perso, ) le 30/01/2003 à 03:38. (lien). Évalué à 2.> d'environ UN MILLION de lignes C pour evolution.
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 (page perso, ) le 30/01/2003 à 09:57. (lien). Évalué à 1.C'est clair que c'est assez enorme bien que l'ensemble kmail et autres doit s'appocher de cette taille (mais bon une bonne partie est maintenant consideree comme appartenant au framework de base de kde)
> 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 (page perso, ) le 30/01/2003 à 10:12. (lien). Évalué à 2.Bof. Çà dépend. Sinon les développeurs de Linux, apache, php, etc... sont un peu c.. .
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 () le 30/01/2003 à 12:03. (lien). Évalué à 1.> Ça fait au moins 2 ans de boulot Autant pour moi (annonce evolution 1.0) : http://www.businesswire.com/cgi-bin/f_headline.cgi?bw.120301/213370452 The culmination of two years of open source development > mais qu'il faut beaucoup plus de monde pendant plus longtemps sur une appli GTK+ Un peu plus de monde je le conçois mais beaucoup plus de monde ... non.
-
[^]Re: Des nouvelles du desktop
Posté par Guillaume Laurent (page perso, ) le 30/01/2003 à 13:30. (lien). Évalué à 2.Un peu plus de monde je le conçois mais beaucoup plus de monde ... non.
Ç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
Salut.
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 (Jabber id, page perso, ) le 29/01/2003 à 16:49. (lien). Évalué à 3.Nautilus est plus léger car il a une facheuse habitude de jeter du leste chez moi : Des fichiers core de 20 Mo :)
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 ?
-
[^]Re: Gnome 2.2 rc2
Posté par Raphael Junqueira (page perso, ) le 29/01/2003 à 21:03. (lien). Évalué à 1.1) c'est pas un mal, car bien qu'il soit assez beau je supportait pas ca vitesse de rafraichissement
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)
Cette page a été générée par Templeet en 0.3872s (dont 0.0993 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.