Nicolas Roard a écrit 1135 commentaires

pfff magic je vois que ça bosse ;-)

(-1)

Au niveau syntaxe, il y a UNE addition syntaxique par rapport au C ... donc effectivement, ça va vite ;)
Au niveau "logique", c'est de la programmation objet, donc un programmeur C++ prendra vite le coup. Un programmeur C sans connaissances de la POO, ben, il faudra qu'il apprenne un minimum ce que c'est de toute façon.
La façon de concevoir une appli peut différer avec C++ grâce au côté dynamique du langage, de la disponibilité des objets distribués, de l'ensemble du framework... Un programme graphique se programmera d'une façon différente (plus rapide), car utilisant le framework GNUstep, et surtout, Gorm. Comportements indéfinis... disons que ObjC est plus simple que C++, donc plus aisément maitrisable. Le plus simple est d'aller jeter un oeil sur les tutoriaux sur http://www.gnustep.it(...) ou d'aller poser des questions sur #gnustep (irc.debian.org)

ddd avec gdb/gcc est le meilleur debugger graphique

ddd est pas mal du tout, mais il existe aussi gvd, qui est excellent je trouve :
http://libre.act-europe.fr/gvd/(...)

Gcc maintient déjà Ojective C qui n'est pas très utilisé

Ben, oui, mais d'un autre côté c'est quand même le langage par défaut sous Mac maintenant... ça apporte un certain nombre de devs je pense, non ?

sur le reste je suis d'accord, l'inclusion d'un patch peut poser des problèmes. Mais bon, à l'extrème on ne touche plus à rien alors.

Est-ce que ce ne serait pas plus intelligent à long terme de porter GNUStep en C++

Ben honnêtement, si c'était faisable, pourquoi pas... le problème c'est que ObjC a bien un intérêt, c'est d'être dynamique à l'exécution. Ce que C++ n'est pas. Alors, oui, on peut imaginer un éventuel portage vers C++, qui "émulerait" toute cette partie dynamique (c'est un peu ce qui a été fait chez mozilla avec Gecko en fait!), le problème c'est qu'on aurait un truc en C++ pas franchement agréable à écrire et à maintenir.
Le truc c'est que GNUstep n'utilise pas ObjC parce que ça fait bien, ou pour être original, mais parce que le langage a des avantages par rapport à d'autres.
Maintenant, à chaque problème le bon outil, est ObjC est excellent pour tout ce qui est GUI, mais pour un backend, C++ peut être éventuellement un meilleur choix (profitons des templates par exemple); c'est à voir.
Bon et puis si vraiment ObjC te sort par les trous de nez, tu peux coder en java, guile, rubby, etc.

Enfin, libre à vous de continuer dans ce qui me paraît une impasse. Déjà qu'il y a Gnome et KDE en face de vous, si en plus vous imposez l'utilisation d'un langage exotique...

Bah chacun son point de vue hein :)
Moi je ne pense pas qu'on ait "Gnome et KDE contre nous", d'une part parce qu'on a pas les mêmes objectifs (multiplateforme), et deuxièmement parce que la "philosophie" derrière est différente. On préfère s'inspirer de NeXT/OPENSTEP que de windows/mac : on essaie de faire des applis petites, qui font bien UNE chose, ergonomiques, avec l'ensemble des logiciels communiquant entre eux pour faire des choses plus complexes.

D'un point de vue personnel, je m'en fous si on devient pas le desktop #1 sous unix, ce qui m'intéresse moi c'est d'utiliser un truc qui me convient. De toute façon, ce qu'on veut faire ne conviendra pas forcément à tout le monde, alors... (je suis admiratif du boulot qui a été fait sur KDE par ailleurs)

Et puis on aura effectivement pas les ressources pour refaire tout ce qui a été fait sur Gnome et KDE en 2 semaines hein :-P maintenant, j'ai aussi confiance dans le fait qu'on arrive à développer plus rapidement (grâce au framework et à Gorm) les applis, et que même sans être nombreux on arrive à faire avancer les choses tranquillement. On verra bien, mais je pense que ça vaut le coup de tenter.

Ca apporte quoi de mixer objc et c++ ?

[D'abord, c'est très orienté GNUstep hein... (normal, mis à part GNUstep, sous linux y'a pas gd monde qui utilise ObjC).]

Donc, principalement, ça apporte le fait de pouvoir utiliser sans se prendre la tête des librairies ou des bouts de code C++ dans des programmes Objective C.

Classiquement, on peut imaginer un projet dont le "backend" est fait en C++, pour raisons historiques par exemple, auquel on veut coller une interface graphique (GNUstep ou Cocoa sur Apple).

Bon. Ben du coup tu construit ta GUI super rapidement en utilisant ObjC, et tu la branche sur ton code C++, voila. Et hop tu bénéficie des avantages GNUstep en plus (services...).

Comme pas mal de librairies intéressantes ont été faites en C++ (OpenH323 ou Gecko par exemple), ça permettrait d'avoir plus facilement des portages vers GNUstep, ce qui est intéressant. Bon y'a certaines libs (Gecko!) qui bénéficieraient aussi largement d'une réécriture en ObjC, mais si en attendant on peut l'utiliser pour batir quand même des trucs, c'est toujours ça de boulot évité pour le moment. Voilou.

Oui, c'est ce que j'avais entendu comme raison à l'époque -- le patch était pour gcc 2.9x donc, comme les types de gcc étaient en train de tout chambouler niveau C++ pour gcc 3.x, ils avaient mis ça de côté -- ce qui peut largement ce comprendre; Mais bon, on en est au 3.2, et Apple a porté son patch sur gcc 3.x aussi ... donc c'est un peu lourd de devoir attendre, encore. Même si on peut comprendre, qu'il y a surement tout un tas de raison, c'est lourd. Voila. Juste pour le noter.

- les développeurs GCC sont très réactifs (je ne sais pas pour ICC vu que je ne l'utilise pas)

Très réactif, peut être pour certaines choses, mais bon l'intégration des patchs d'Apple sur gcc pour mixer ObjectiveC et C++, on les attends depuis LONGTEMPS

ah désolé, mais après une journée bien remplie, moi je résiste pas aux sirènes du troll... donc :

Si la programmation d'un GUI pouvait être aussi simple...
C'est sur que Gtk+Glade ... essayez plutôt Gorm+GNUstep ;)

(et mon -1 ou qu'il est ?)

oui effectivement :)
TAO permet entre autre de n'embarquer que ce qui est nécessaire je crois...

Ah ben d'ailleurs j'avais pas fait gaffe mais dans les liens de l'article il y a le cours de mon prof de l'époque, Daniel Feneuille ..
Un grand merci à lui ! :)

Je me souviens que les cours de première année en DUT étaient entièrement basés sur Ada. Et pour apprendre la programmation, c'est un langage idéal, rigoureux (quelle plaie pour compiler :) et qui pousse je pense à de bonnes pratiques.
Comme en plus il est suffisamment riche pour montrer les algos classiques de façon simple (prog parallèle, etc.) ... Franchement un bon langage. Même si pénible à écrire ;) et qu'il vaut mieux avoir des profs qui expliquent clairement le truc ;)

tout le monde est en train de passé au C

Pardon ???
Heu... non. C++ est une autre des références, java progresse aussi. Mais pour les taches vraiments pointues et nécessitant une certaine robustesse (aéronautique...), Ada reste un grand classique.
Ada apporte pas mal de trucs de base (tasks...), la notion de composants est au coeur du langage, les exceptions et le compilateur sont super fichus, la bibliothèque de base est largement fournie, etc.
Honnêtement, pour un projet de grande taille ou la robustesse serait un point important, je choisirais sans hésiter Ada, et surtout pas C++... et encore moins C !
Pour de l'embarqué, ça dépends de l'utilisation, mais bon en général on attends là aussi une certaine fiabilité, ça se rejoint...

Shelf, oui ==> http://www.roard.com/screenshots/screenshot_panel1.png(...)

je suis d'accord, théoriquement faudrait faire toutes ces modifs pour WMaker ... sauf que du coup, à la fin ce ne serait plus WMaker :)

Par contre, en attendant, on peut facilement rajouter des trucs GNUstep sur wmaker (notifications, dnd), qui permettront une bonne intégration, mais sans avoir besoin de tout casser dans wmaker ... ce serait moins "bien" qu'un WM fait vraiment pour GNUstep, mais d'un point de vue "technique" uniquement : fonctionnellement ce serait pareil.

Donc en attendant IWM ou Woom, c'est une solution plus rapide à mettre en oeuvre :)

un [+] :)

Alors c'est quoi ce bordel??
Ben comme tu dis :)))

Est-ce que ca date du temps ou GNUstep n'etaient pas utilisable et ils ont ecrit une lib speciale?
Oui, à priori... cela fait relativement peu de temps que GNUstep (surtout la partie graphique) est utilisable, WMaker, ça fait une paye qu'il existe. J'ai pas les dates en tête, mais je pense que les débuts des deux projets doivent pas être si éloignés que ça... donc à mon avis kojima, comme pour écrire un window manager il avait pas besoin de tout gnustep, et qu'il voulait surtout un WM qui ait le look'n feel NeXT, il l'a codé en C pour pas attendre que GNUstep ait fini...
Maintenant pourquoi ils n'ont pas aidé GNUstep à implémenter toutes les libs, ça j'en sais fichtre rien (ça les intéressaient pas forcèment ?).

Woom utilisera-t-il WINGs ou GNUstep?
Woom est programmé en Objective C... maintenant le projet n'avance pas très vite, je sais pas trop ou ils en sont. Il existe aussi IWM (Interface WM), mais qui n'avance pas vite non plus. On aura plus vite fait de rajouter ce qui nous manque à wmaker je crois ! :)

Quel est le comble de l'electricien?
aucune idée ? :) question #1 : est-ce que l'ampoule est branchée

Au fait quand il s'agit de papoter sur une news touchant de pres ou de loin a GNUstep t'est toujours de la partie toi :)

Ben ouaip j'adore ça, moi, troller sur des sujets peu connus ¹ :) (la preuve!)
En plus avec GNUstep c'est facile, le projet est bourré de bonnes idées, et je connais bien :)

¹ Injustement méconnus, oui !

Je préfère le gtk aux widget gnustep

Ben vu que gtk est thémable, et que gnustep peut l'être, je suppose que tu ne parle pas du "look" des widgets, mais donc de leur programmation ? :)

support ? quoi dans quoi ?

Un meilleur support de WMaker pour GNUstep, une meilleure intégration avec les applis GNUstep si tu préfère.

intégration ? quoi dans quoi ?
Avec le nombre de softs gtk, je pense que cela renforcerai l'intégration graphique.

L'intégration graphique avec les softs gtk, oui. Mais l'intégration graphique avec GNUstep, non. (oui c'est bête et logique). Pourquoi je dis ça ? parce que voila ce qu'il y a de marqué sur le site de wmaker :

Window Maker is an X11 window manager originally designed to provide integration support for the GNUstep Desktop Environment. [...] Window Maker includes compatibility options which allow it to work with other popular desktop environments, namely GNOME and KDE

Hors, WindowMaker a un support assez léger des applis GNUstep (on va pas cracher dans la soupe, au moins il a un support :), dans le sens ou aucun mécanismes GNUstep n'est utilisé (notifications distribuées, utilisation du pasteboard GNUstep, etc.). Rien de dramatique (et c'est compréhensible qu'il y a 4-5 ans WMaker n'ait pas utilisé GNUstep), mais bon, c'est un peu dommage, et c'est tout ce que je faisais remarquer.

Comme je sais que tu n'aimes pas trop de non-object, j'ajoute que GTK ce n'est pas uniquement en C; utilisons le binding GTK en C-Objective. Qu'en penses-tu ?

Que c'est une horreur :)
Quitte à programmer en Objective C, c'est _franchement_ dommage de pas s'intéresser au framework GNUstep : pour moi y'a pas photo au niveau des possibilitées... Ne serait-ce que les services : http://www.stepwise.com/Articles/Technical/Services.html(...) qui est une techno permettant à l'utilisateur de faire intéagir facilement des applis entre elles, et donc dans l'idéal d'obtenir l'équivalent graphique des applis unix classiques (une appli fait une chose, mais bien, et coopére avec d'autres pour le reste).

Mais bon t'en fait ce que tu veux (d'autant qu'il reste du boulot sur GNUstep), c'est uniquement mon avis perso ! :)

Berk :-(
moi je veux un support amélioré de GNUstep (utilisation des libs GNUstep, envoi de notifications distribuées, ce genre de choses...), une meilleure intégration, etc. Franchement ils disent être le WM Officiel de GNUstep !

Oui c'est sûr ... je parlais en tant qu'hypothèse hein :-P pour un éventuel et fort hypothétique futur navigateur natif Fresco.
Pour X, c'est clairement un des problèmes.

Oui, sauf si tu considère que ta page de mozilla n'est pas un bête bimap généré par le navigateur, mais au contraire un ensemble d'objets instanciés permettant l'affichage... dans ce cas, le client pourra aussi savoir comment redessiner le bidule.

Précisions :

Corba te permet de créer des objets (au sens de la POO), à partir d'à peu près n'importe quel langage, de pouvoir les faire intéragir ensemble¹, d'utiliser des architectures matérielles différentes (petit-boutiens et grand-boutiens). Ces objets sont disponibles sur un "bus objet", et un client peut demander un objet sans savoir ou s'exécute réellement cet objet.

Bref, du bel ouvrage... bien documenté, normalisé, avec pas mal d'implémentations existantes.
Mais une vraie usine à gaz également. D'autant qu'il est rare que l'on ait besoin de tous les avantages/fonctionnalitées de Corba. Personnellement, j'ai une (grosse) préférence pour les objets distribuées GNUstep² . Mais à chaque problème son outil hein.

Concernant Fresco, ils disent qu'ils utilisent toutes les fonctions de Corba et que donc c'est pas du bloat. Si la charge réseau est moins importante que pour X (ce qui est tout à fait possible), c'est surtout grâce à une conception plus haut niveau que X11, plutôt que grâce à Corba...


¹ genre, je crée un objet en Ada, je le dérive dans une sous-classe qui elle est en C, pour finir par une sous-sous classe en C++.

² on va encore dire que je suis partial... mais jettez un oeil sur ce tutorial : http://www.gnustep.it/nicola/Tutorials/DistributedObjects/index.htm(...)
obtenir un objet distribué simplement en modifiant son initialisation, ben... c'est quand même cool :)

??

Non Corba ça te permet d'avoir des objets distribués. C'est à dire que tu as des objets qui peuvent être sur le réseau (une autre machine par exemple), que tu appelle de façon transparente (tu n'as même pas à indiquer le nom de la machine sur laquelle tu va chercher l'objet, Corba se démerde avec le nom de l'objet). Du coup, quand tu envoie des messages à ces objets, ces messages transitent par le réseau (dans le cas ou l'objet est sur une autre machine, ici un affichage déporté par exemple).

Le problème d'X11 c'est que les ordres de dessins sont plutôt bas niveau, alors qu'à priori Fresco est plus haut niveau et fonctionne au niveau des widgets.

Si c'est le cas, on imagine que la charge réseau peut effectivement être (de beaucoup) plus réduite. Exemple : Terminal Server de microsoft (ou rdesktop) marche plutôt pas mal en réseau, entre autre parce que les commandes envoyées sur le réseau sont plus haut niveau, donc moins nombreuses. Alors que X11 sur un modem, c'est pas évident, on va dire :)

Aucune idée ... en tout cas ça fait super longtemps que ça s'appelle Berlin (5 ans ? 6 ans ?), du moins autant que je m'en souvienne.

Mouaif enfin si on utilise pas la transparence réseau de Corba, l'intérêt est de plus en plus mince ....

Le problème (et l'intérêt...) de Berlin, c'est qu'il a son propre toolkit graphique. C'est bien dans un sens (plus grande homogénéité de la GUI...), de l'autre ce n'est pas ça qui va faciliter les portages KDE/Gnome/GNUstep dessus ... (enfin, on peut y aller "bourrin", mais un portage "propre" qui utiliserait les widgets natifs ne serait pas évident.)

Je crains un peu l'utilisation de Corba tout azimut, mais bon là c'est ptet moi qui suis trop méfiant :)

Sinon le projet est intéressant, même s'il avance tout doucement.