nicolassanchez a écrit 408 commentaires

Euh le mieux c'est quand meme que la fenetre se ferme avec un message d'erreur

Oui, mais ça n'est pas du ressort du window manager, il n' aucun moyen de savoir si ton application a planté ou si elle attend quelque chose.

Si ton application est mal codée, le window manager n'y est pour rien.

J'ai déjà eu une application sous windows (98 je crois) qui avait planté et dont la fenêtre masquait une grande partie de l'écran et restait au premier plan, c'était vraiment emmerdant pour règler le problème...

je ne vois pas encore de package wmaker 0.90 dans unstable

wmaker 0.90 est sorti il y a deux jours !!!

Je pense qu'il faut quand-même attendre que le mainteneur se rende compte qu'il y a une nouvelle version :-)

Ah bon ? moi quand je fais apt-get upgrade j'ai des nouvelles versions de logiciels qui s'installent...

Maintenant, snot-ce des nouvelle versions Debian, ou des nouvelles versions "tout court" ?

C'est à chaque fenêtre de gérer son anti-aliasing, le gestionnaire de fenêtre ne
gère que les cadres. Question d'anti-optimisation sans doute.

Non, question de laisser à chacun son travail. Le gestionnaire de fenêtre gère les fenêtres, l'application gère le contenu des fenêtres.

Ça permet, entre autre, de pouvoir bouger une fenêtre même quand l'application a planté (sur win c'est pas possible par exemple)...

AfterStep à pas mal avancé ces derniers temps et les trois plateformes OpenStep divergent de plus en plus au lieu de converger vers un standard...

AfterStep est trop compliqué à mon goût et ses gadgets ne sont pas toujours pratiques (genre le changement de bureau lorsque le pointeur est au bord de l'écran...). Ensuite, les icônes du dock sont difficiles à ajouter ou à paramètrer...

Sinon, c'est quoi les trois plates-formes OpenStep ?

Tout d'abord faut comprendre une chose, OpenStep est une spécification.
Cocoa d'Apple est une implémentation, GNUstep en est une autre.

Elle n'est pas exploitable ? Pourquoi ?

Si c'est exploitable mais les versions de l'AppKit (interface graphique), de Gorm et ProjectCenter n'ont pas encore atteint la version 1.0. Donc en entreprise, je vois mal comment l'utiliser.

L'implémentation d'Apple n'est-elle pas exploitable ?

Si, l'implémentation d'Apple est parfaitement exploitable.

Le problème c'est que cette plateforme se veut portable mais ne semble pas vouloir s'intégrer ailleur que dans un environnement qui lui est dédié

Comme Java, Qt ou Gtk.

des APIs techniques qu'utilisent les 3/4 des langages sont écrits en C... (APIs multimédias, réseau, graphique, etc.)

Oui, c'est juste et dis moi comment tu pourras utiliser les nouvelles bibliothèques écrites en C sous Mono ?

Contrairement à mono, l'ObjC est une surcouche du C, donc question intégration environnement, l'ObjC n'est pas si mal puisqu'il n'y a rien à faire pour utiliser tes bibliothèques C.

mais il ne faut pas s'étonner après si personne utilise cette plateforme.

L'intérêt n'est pas de vendre un produit, mais de faire quelquechose d'efficace et dont on a besoin.
Le jour où GNUstep sera parfaitement exploitable, ne t'inquiète pas, les gens l'essayeront et l'odopteront.

Par contre, mono, tout le monde s'y intéresse, mais est-ce pour ses qualités, où plutôt pour "quoi ? .NET sous Linux ?"...

Et pour finir, qu'Apple ait choisi OpenStep, c'est une marque de qualité pour OpenStep. Car même si Apple n'a jamais vendu autant que MS, Apple a toujours vendu des produits de qualité, débuggés et beaux. D'ailleurs, une fois que t'as goûté à Apple, tu ne manges plus que de l'Apple.

Par contre, .NET, on en entend beaucoup parlé, mais plus souvent pour ses bugs que pour ses qualités.

Ensuite concernant la compatibilité, je crois plus en celle de GNUstep avec Cocoa qu'en celle de Mono avec .NET (y'a déjà des classes dépréciés, des classes doublons etc.).

Alors entre Mono et GNUstep, le choix est évident pour moi, c'est GNUstep.

J'ai regardé la classe NSMovie... elle ne sert pas à grand chose sinon à ouvrir une URL.

J'ai l'impression qu'il faut surtout redévelopper NSMovieView qui apparemment récupère le pointeur vers le film de notre NSMovie.

Sérieux, en python on peut passer les argument sans les noms
ou avec et ca dans le même appel genre...

La possibilité n'est pas suffisante, il faut que ce soit obligatoire.
On sait très bien que si c'est optionnel, dès que tu seras pressé, tu l'oublira.

D'ailleurs, j'ai déjà fait du Python (pour voir ce que c'est) et je n'ai vu nulle part cette syntaxe...

Il y a des environnements de dev qui te proposent la liste des paramètres

Oui, je connais, mais quand tu lis du code, tu ne suis pas ta lecture avec le curseur et l'affichage de la liste n'est pas instantanné.

Je trouve ce principe simple, intéressant et ne nécessitant pas un éditeur évolué pour comprendre le code.

Pour moi le langage c'est une question de goût, un langage ne doit pas être dépendant d'une plateforme, et une plateforme ne doit surtout pas dépendre d'un langage.

Complètement idiot ce que tu dis...
Pour qu'un framework soit efficace, il doit être adapté au langage qui l'utilise et tirer profit de toutes ses particularités.

Je sais MS propose plein de langages pour son .NET. Enfin, des langages qui acceptent .NET à peu près. Par exemple le C++ qui n'a plus droit à l'héritage multiple etc.
Oui, il y a aussi de l'ADA qui tourne après compilation comme du C#, autant développer en C# dans ce cas puisque de toutes façons tu perds tous les avantages liés au langage...

Je crois qu'il faut comprendre qu'un langage ne se limite pas à une syntaxe mais contient également des spécificités à l'exécution. Le framework ne peut pas faire abstraction de ces spécificités, même si MS essaye de nous le faire croire.

Celà revient au même : si je suis obligé de faire table rase de MON existant pour aller vers un autre celà va être très rédibitoire. Je veux bien qu'on me propose quelque chose de nouveau, mais j'aime bien les transition douces, et surtout que je puisse m'intégrer avec l'existant, bref que je puisse faire des appli autour d'une plateforme portable tout en m'intégrant dans les environnements où je les exécute.

Et moi, qui ne connaît que OpenStep, pourquoi t'essaye de m'embrouiller avec tes Qt et Gtk ? moi je veux pas faire table rase de MON existant...

Pour travailler sur GNUstep, tu ne dois pas faire table rase sur tes connaissances. Par contre tu dois apprendre de nouvelles syntaxes (celles de l'Objective-C) et penser tes applications un tout petit peu différemment.

Tes connaissances en développement objet seront nécessaires...
Au fait, je vois que tu as développé sur .NET dans ton cv, ça faisait parti de ton existant ? tu n'as jamais eu à l'apprendre, tu as la science infuse ?

Bon maintenant je vais aller chercher moi même ce qu'il y a d'innovant dans cette plateforme (désolé, je ne vais pas comparer avec ce qu'il y avait y'a 10 ans mais avec ce qu'il y a maintenant) puisque personne veut m'expliquer concrêtement ce que ces superbres APIs vont m'offrir de mieux.

On a donné pourtant pas mal de pistes sur les choses innovantes (le langage, les outils de développement etc.)...

C'est pourtant clair. T'as du mal à comprendre. Rien n'a bougé depuis 10 ans, rien du tout.

Si tu ne comprends toujours pas, GNUstep est un clône d'OpenStep.
Il ne fait donc pas table rase sur l'existant, mais il s'inspire d'un autre existant que celui que tu connais...
Pourquoi voir du côté de Gtk ou Qt alors qu'OpenStep se suffit à lui même.

La seule chose qui ait changé, c'est uniquement pour apple qui a mis de belles couleurs partout.

Mais voilà, ce que je trouve dommage dans GNUStep, c'est qu'elle propose trop de nouveauté et pas assez de possibilité d'intégration dans l'existant.

Tu délires ?

GNUstep est une implémentation libre d'OpenStep qui a 10 ans aujourd'hui.
NeXTstep a été ouvert et est devenu OpenStep. NeXTstep existe depuis au plus tard 1992, soit au moins 12 ans.

GNUstep apporte des nouveautés vieilles de 12 ans...

Quand on te dit que si les specs. OpenStep n'ont pas bougé depuis 10 ans, c'est parce qu'OpenStep était ultra-innovant et bien foutu...

Bon, je suis d'accord en partie. Mais les trois projets sont différents et s'intègrent à leur propre environnement.

application KDE sous Gnome et inversement. Tu trouves pas qu'il y a de nombreux problèmes d'incohérence d'ergonomie entre les interfaces ?

Dans l'un de tes commentaires précédent, on pouvait lire :

que me propose GNUStep pour m'intégrer à l'existant ? Je peux facilement utiliser GTK ou Qt ? Nan parcque en l'absence d'environnement comme Gnome ou KDE pour GNUStep

GNUstep s'intègre parfaitement à WindowMaker.

Si tu ne cherches pas des poux, dis moi où tu veux en venir ?

et maintenant un autre problème : intégration ergonomique, et là je ne connais aucun toolkit qui peut se vanter d'être portable tout en respectant l'intégration.

C'est pas tout à fait vrai car Kde permet par exemple d'utiliser des menus à la Apple après une simple configuration. Donc, sur Apple les menus d'applications Qt seront "ergonomique" par rapport au reste des applications.

Pour obtenir une meilleure intégration, il faudra multiplier les types de fenêtres prédéfinies genre dialogue etc. Chaque implémentation dans un environnement aura son dialogue, etc. spécifique.

il n'y a pas d'intégration voilà quoi...

WindowMaker n'existe pas ?

Si pour vous l'intégration c'est avoir la même geule que son desktop, je suis désolé mais GNUstep est parfaitement intégré à WindowMaker...

Tu veux dire quoi par s'intégrer ?

Quand j'ouvre n'importe quelle application Gnome, KDE ou GNUstep, il se passe la même chose. L'application s'ouvre, fonctionne et c'est tout. Je ne vois pas ce que tu veux de plus ?

Ce qui gère l'intégration des applications c'est la couche window manager de la Xlib. Quand tu ouvres une appli, le window manager est mis au courant et reçois les infos utiles. C'est tout ce dont tu as besoin et ça marche.

Pour le copier/coller, c'est pareil, tu peux copier depuis GNUstep et coller dans du Gnome, et inversement...

Ensuite, si tu parles de boutons dans les menus, je sais pas ou autre chose, tu peux mettre un bouton qui lance une appli GNUstep sur ton KDE...

Plutôt que de chercher des poux dans la tête de GNUstep, essaye et vérifie que ça fonctionne c'est tout.

préfèrent supporter plusieurs environnement (Windows, Gnome et Cocoa) et promettre la portabilité de ce qui DOIT etre portable (bref, pas l'interface)

Mais vraiment n'importe quoi... depuis quand l'interface n'a pas besoin d'être portable ? Surtout pour un truc comme Mono, dont le but est quand même de créer des applications interactives...

Ensuite il me semble qu'il y a une bibliothèque GtkSharp commune à tous les environnements...

objet->drawPoint(10, 15, 3, rouge) (...) même si les varibles passées à la méthode permettent de le savoir

10, 15 et 3 te permettent de savoir de quoi il s'agit ?

echantillon_courant = [[centri nacelles] item: [[[[parcours item: iteration] numero_nacelle] emplacements] item: [[[parcours item: iteration] numero_emplacement] element]]

Oui, effectivement, c'est pas claire du coup...

Faut dire que j'ai considéré que chaque élément de ton truc était un objet, sinon, la syntaxe . ou -> reste valable pour les structures.

Ensuite, ton truc paraît plus claire, mais si tu essayes de comprendre ce qui se passe c'est exactement pareil...

Si tu programmes comme un porc, c'est pas l'Objective-C qui va te sauver... Par contre quand tu programmes proprement, l'Objective-C t'apporte beaucoup.

Comme dit un peu plus haut, tu as ta doc dans le nom des méthodes.

Je ne vois pas le rapport avec Gtk ou Qt...
Quand tu développes en Objective-C, tu utilise le framework GNUstep... Tu vas pas chercher du Gtk ou du Qt. Sinon, développes pas en Objective-C...

A part ça, GNUstep fonctionne très bien sous KDE ou Gnome.

Cependant, pour conserver les principes d'OpenStep, WindowMaker est le plus adapté. D'autre part il me semble qu'un environnement est en train d'être développé en Objective-C (WindowMaker est développé en C...).

Tu me diras que WindowMaker n'est pas bien (il démarre en 2 secondes, y'a pas une jolie image avec des icônes qui clignotent pendant 20 minutes avant de pouvoir travailler :-)), mais il rempli sa mission qui est d'être un window manager et efficacement.

J'ignore quel est l'aspect qui "dérange"

Je ne sais pas non plus, mais il faut dire que l'objective-C est étroitement lié à OpenStep, et du coup n'a pas eu la popularité qu'il méritait.

Maintenant, il faut dire qu'on parle souvent des avantages de GNUstep, mais on oublie souvent de parler de l'Objective-C.

Pour moi l'Objective-C a deux gros avantages :

- il y a très peu de choses qui ont été rajoutées au C. Par exemple, l'holomorphisme est naturel, il n'y a pas besoin de déclarer les méthodes virtuelles etc.

- les déclarations et appels de méthodes sont beaucoup plus claires que tous les langages classiques, par exemple :
- on aura en C++, Java, VB... : objet->drawPoint(10, 15, 3, rouge);
- en ObjC on aura : [objet drawPointWithX: 10 Y: 15 diametre: 3 color: rouge];
Il n'y a aucune discussion à avoir, l'ObjC est 1000 fois plus claire.

Un truc qui a mon avis serait vraiment proche de la perfection, ce serait de finir le bridge Squeak<->ObjectiveC ... on aurait alors l'avantage de Smalltalk ET l'avantage du framework OpenStep et des outils associes :-)

Ça ne serait pas possible en partant de StepTalk ?

Au fait va faire un tour sur le site http://www.gnustep.org,(...) ça évitera des commentaires inutiles.

Y'a un IDE qui s'appelle ProjectCenter, et un créateur d'interface qui s'appelle Gorm. Ces deux outils sont les équivalents de XCode et InterfaceBuilder de Cocoa.

Pour le reste, le framework est bien plus petit et bien mieux étudié (à mon avis, enfin pas seulement le mien...). Contrairement à d'autres environnements, il n'y a pas de doublons parmi les classes, ce qui te permet de trouver beaucoup plus rapidement ce qu'il te faut également. Le système de délégué apporte également beaucoup de comfort pour la gestion des listes et des tables.
Pour parler également du langage, ce qui permet d'accélérer considérablement le développement dans certains cas, c'est l'extension de classes grâce aux catégories...

Sinon, pour ne pas parler de .NET avec lequel j'ai développé quelques trucs, quand tu as un bug dans ton programme sous GNUstep, tu ne fonces pas directement sur Internet pour voire si un bug du framework a été reporté...
En général, quand il y a une erreur, c'est toi le responsable et du coup tu n'as qu'à regarder dans ton code.

Une liste de screenshots est sans intérêt. Le plus intéressant c'est d'avoir un screenshot par application, au moins tu sais ce que tu regardes...

Il y a aussi une brochure de présentation...

Va voir là : http://gnustep.org/experience/apps.html(...)
et : http://gnustep.org/information/Booklet.pdf(...)

Ensuite, GNUstep n'est pas un desktop, mais un environnement de développement, donc ce n'est pas comparable.

Décision politique ? Pas du tout, c'est un choix purement technique.

Qu'ils aient du Linux, du Windows ou du Mac, ça ne changera rien pour toi, en tant que citoyen.

La seule chose que tu puisses demander, c'est que le système soit efficace et pas excessivement cher, et quelquesoit leur choix définitif, je pense que ce sera le cas.

Il me semble que pour l'égalité des chances, il ne faut pas qu'un rapport soit publié avant que l'entreprise concurrente n'ait rendu le sien...