Ce standard solide et bien défini s'ancre doucement mais sûrement dans le paysage du développement logiciel, et permet de programmer des applications en quelques heures au lieu de jours, semaines ou jamais, en utilisant une API de développement qui n'a pas nécessité de modifications significatives depuis dix ans, car particulièrement bien faite, simple et qui répond aux besoins des programmeurs...
Aller plus loin
- GNUstep (11 clics)
- Brochure GNUstep (5 clics)
- Présentation GNUstep (15 clics)
- Article d'introduction sur GNUstep (2 clics)
- OpenStep (13 clics)
- Apple Cocoa (3 clics)
# :)
Posté par Jiel (site web personnel) . Évalué à 1.
Bon anniversaire!
[^] # Re: :)
Posté par Julien MOROT (site web personnel) . Évalué à 6.
À part un joujou pour codeur, GNUStep n'a pas interressé grand monde jusqu'à présent.
Je sais l'API rox, toussa... mais la GUI est laide et il n'y a pas ou presque d'applications codées pour exploiter l'environnement même si d'après certains GNUMail.app rox KMail/Evolution.
Au contraire de KDE et Gnome qui sont homogènes, qui offrent une API tout aussi propre, comportent un bon nombre d'applications et qui ont une large communauté d'utilisateurs. Et ce dernier point fera toujours la différence...
[^] # Re: :)
Posté par Anonyme . Évalué à 6.
Inutile de relancer le troll ;)
Pour un resumé des episodes precedents :
http://linuxfr.org/2004/06/14/16526.html(...)
[^] # Re: :)
Posté par Ramso . Évalué à 4.
> Inutile de relancer le troll ;)
Tu veux un argument ? Y'a pas de section « screenshots » sur leur site !
[^] # Re: :)
Posté par Nicolas Roard (site web personnel) . Évalué à 4.
http://www.nongnu.org/backbone/(...)
http://home.gna.org/garma/(...)
.. ou là il y a des sections "screenshots" ;-)
m'enfin je suis d'accord que le "marketing" du projet GNUstep lui-même est un peu faiblard, pour être gentil, et on essaie de changer ça en ce moment...
[^] # Re: :)
Posté par Philippe F (site web personnel) . Évalué à 3.
[^] # Re: :)
Posté par nicolassanchez . Évalué à 3.
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.
[^] # Re: :)
Posté par Beretta_Vexee . Évalué à 1.
Franchement c'est quand même trés fort GNUstep, ils arrivent a avoir moin apps qu'un envrionement/OS comme Plan9.
C'est pas tous ca mais j'ai mon portage du Hurd sous multidesk OS a effectué moi ;-)
[^] # Re: :)
Posté par oops (site web personnel) . Évalué à 3.
>l'environnement GNUstep, j'ai nomé GNUmail...
C'est marrrant en regardant la :
http://wiki.gnustep.org/index.php/All%20GNUstep%20Applications(...)
j'ai noté une 50 taine d'applications juste vite fait ( entre system Apps/ Net & Graphics)
Tu ferais pas du FUD par hasard ?
[^] # Re: :)
Posté par LeRat . Évalué à 1.
Il me semble qu'il ne fait que fournir un desktop, à l'origine.
Effectivement, cette part du projet prend de l'ampleur, pour ma plus grande joie (I luv it) et mon plus grand regret (ça devrait être clairement séparé...)
[^] # Re: :)
Posté par mrlem (site web personnel) . Évalué à 2.
En première page du site gnustep tu as une toute petite image, et si tu cliques dessus, ça te montre un exemple d'environnement gnustep...
[^] # Re: :)
Posté par oops (site web personnel) . Évalué à 3.
> dernier point fera toujours la différence...
Je pense que le nombre d'utilisateur Cocoa n'a rien a envié à celle de KDE ou Gnome.
Pareil pour le nombre d'applications ou de développeurs
[^] # Re: :)
Posté par - - . Évalué à 10.
sigh...
(les goûts et les couleurs... la gui est belle, cohérente, "useable", sobre, le reste ce n'est que parce que les gens sont devenus allergique au gris et les icônes ont vielli)
>et il n'y a pas ou presque d'applications codées pour exploiter l'environnement même si >d'après certains GNUMail.app rox KMail/Evoluti
sigh...
non GNUMail ne "rox" pas evolution (a la rigueur kmail) mais on pouvait dire de même de Gnome 1.0 et kde 1. ben vi, le travail est long, y a eu des déboires, des gens se sont d'avantage intéressé à gnome ou kde, etc etc
personne ne dit le contraire : GNOME ET KDE sont de loin plus avancés que GNUStep
mais mais mais , GNUStep est une BONNE fondation, une BONNE technologie
et NON CE N'EST PAS PRET pour le DESKTOP de Mr TOut le monde
mais TOUTE infrastructure (gnome, c# , cocoa, java etc) sont des "jouets" pour développeurs, TOUTE ont besoin qu'au début des gens "dingues" s y mettent pour crédibiliser la plateforme, sortent de VRAIS applications, etc
notons que gnustep a un (petit) jeu de logiciels. y a pas que gnumail dans la vie.
>Au contraire de KDE et Gnome qui sont homogènes, qui offrent une API tout aussi
l'ergonomie de openstep est infiniment plus codifié et stricte que KDE ,et Gnome a encore besoin d'un HIG 2.0 pour clarifier non plus bêtement le "look", mais aussi le Feel (quel menu, quel genre de boite de dialogues, etc)
en particulier parce que openstep peut tout simplement s'appuyer sur celle de nextstep ou se mettre à jour sur celle de apple cocoa.
> propre, comportent un bon nombre d'applications et qui ont une large communauté >d'utilisateurs. Et ce dernier point fera toujours la différence...
y a longtemps, un vieux avec une barbe me disait exactement les même raisons pour lesquelles Gnome/kde n'avait pas d'avenir, y avait déjà trop de gens embringué dans XLib et Motif et quitte à tout refaire, autant se plier au règne windows et faire du MFC en C++
evidemment y a PEU de changes (ou malchances selon votre humeur) que gnustep soit un jour une plateforme populaire, tout simplement parce que gnome (ou kde) ont atteint dans une très grande part l'attente d'un bureau opensource CONVIVIAL
il est maintenant plus "rapide" d'améliorer gnome, que de contribuer à peaufiner gnustep et faire tout plein d'applications. Gnustep a raté son rendez vous avec l'histoire y a quelques années. a moins d'un soudain débarquement de développeurs avide de coder du objective C comme des oufs et de distributions importants qui se découvrent une passion gnustep, je vois pas.
mais qui c'est ce que réserve l'avenir.
En attendant, il est vrai que je préfère apprendre et utiliser Cocoa sur mac os X avec Xcode et interface builder. clairement le meilleur langage, la meilleur API (cohérente et archi-complète) et outils de developpements que j'ai eu le plaisir d'utiliser. Ha si les outils de gnustep étaient aussi avancés, avec 150 développeurs dessus. j'ai clairement pas les compétences pour débugguer le backend gnustep xlib ou accéler leur version du interface builder, bref, jsuis dépendant de la venu de vrai hacker de talent.
faute de "mieux", Gnome est de plus en plus un excellent bureau et l'Histoire continue.
MAIS Ne donnez pas de faux arguments, on disait LA MEME CHOSE DE GNOME 1 et KDE 1 y a des années !!! et regardez finalement le chemin parcouru. ne parlez pas trop dans l'affirmatif absolu.
[^] # Re: :)
Posté par Pierre Tramo (site web personnel) . Évalué à 3.
Bof, un des avantages du logiciel libre est quand meme un personnalisation poussée. il suffit de voir le nombre de theme sur les sites comme kde-look, gnome-look. Il y a des tonnes de bureaux, de wm... Il y en a pour tout les gouts.
l'ergonomie de openstep est infiniment plus codifié et stricte que KDE ,et Gnome a encore besoin d'un HIG 2.0 pour clarifier non plus bêtement le "look", mais aussi le Feel (quel menu, quel genre de boite de dialogues, etc)
C'est aussi un défaut, quand on voit le menu détaché, personellement je ne connait rien de plus chiant. Il faut avoir wmaker(un wm qui n'a plus évolué depuis 2002) pour que ça soit utilisable. Il y avait bien un patch qui circulait a une époque, mais il n'a jamais été commité à ma connaissance. Il faudrait pouvoir laisser le choix à l'utilisateur.
autant se plier au règne windows et faire du MFC en C++
Quand meme pas, Les MFC, c'est "un peu" de la merde
[^] # Re: :)
Posté par reno . Évalué à 4.
mais qui *sait* ce que réserve l'avenir.
D'habitude je ne suis pas specialement stricte sur l'orthographe, mais celle la elle pique un peu! Bon vue la taille de ton poste, tu as du aller un peu vite :-)
[^] # Re: :)
Posté par Philippe F (site web personnel) . Évalué à 2.
Yeps. Sauf que KDE a commence il y a 8 ans, ce qui doit bien faire 7 ans pour Gnome. En 7 ans, on a fait beaucoup plus que GnuStep en 10 ans et ca ne fait que s'acceerer (cote Gnome + KDE) . Ou en sera-t-on dans 10 ans ?
[^] # Re: :)
Posté par Erwan . Évalué à 3.
[^] # Y'a pas le GUI dans la Re: :)
Posté par Guesdon Manuel (site web personnel) . Évalué à 3.
Un exemple de site en GNUstep+GNUstepWeb+gdl2:
CyberDVDFilm: http://www.cyberdvdfilm.com(...)
Manuel
[^] # Re: Y'a pas le GUI dans la Re: :)
Posté par oops (site web personnel) . Évalué à 1.
>ligne de commande et des applis web (avec GNUstepWeb par exemple:
>http://www.GNUstepWeb.org(...(...)) ).
Est-ce qu'il y a une chance de voir SOPE (le serveur d'application de OpenGroupware) et GNUstepWeb se réunir un jour.
Parce que cela fait, si j'ai bien compris, deux implémentations de WebObject.
[^] # Re: Y'a pas le GUI dans la Re: :)
Posté par Guesdon Manuel (site web personnel) . Évalué à 1.
Cela dit gsweb est stable; la derniere version a été optimisée (2 à 3 fois plus rapide dans beaucoup de cas),...
Manuel
[^] # Re: Y'a pas le GUI dans la Re: :)
Posté par Nicolas Roard (site web personnel) . Évalué à 1.
# IHM
Posté par Anonyme . Évalué à 3.
J'avais lu sur les forums officiels que certaines personnes commencaient a vouloir changer les choses a ce niveau (apparence, icones, ...). Qu'en est-il aujourd'hui ?
[^] # Re: IHM
Posté par Nicolas Roard (site web personnel) . Évalué à 10.
Sinon en gros, la majorité de ce que je voulais modifier pour -gui est commité, donc il ne reste "plus" qu'à finaliser le moteur lui-même, ce qui devrait être assez rapide.
Concernant les icones, ça progresse, c'est en bonne voie. On a fait un guideline avec quentin pour les icones, et on est en pourparler avec quelques graphistes (d'ailleurs je viens de recevoir les deux premières icones dans ma bal aujourd'hui.. ;-)
http://www.quentinmathe.com/gnustep/documentation/UI/icons/(...)
[^] # Re: IHM
Posté par Nicolas Bourdais (Mastodon) . Évalué à 4.
http://www.roard.com/camaelon(...)
Le site de gnustep en parle dans la réponse au bouquin de Aaron Hillegass.
http://www.gnustep.org/resources/BookClarifications.html(...)
# cocoa et "write once compile everywhere"?
Posté par Pierre Tramo (site web personnel) . Évalué à 2.
Si je me souviens bien, il y avait une série d'extensions proriétaires a apple, comme NSDrawer et NSToolBar. Qu'en est il aujourd'hui? Est ce qu'apple a retiré ces extensions ou les gardent il pour empecher les gens de porter des applications vers gnustep?
[^] # Re: cocoa et "write once compile everywhere"?
Posté par Nicolas Roard (site web personnel) . Évalué à 3.
Je ne pense pas qu'Apple les ait créé juste par plaisir d'être "incompatible" avec OpenStep (vu qu'il le restent de toute façon..)
[^] # Re: cocoa et "write once compile everywhere"?
Posté par Talou (site web personnel) . Évalué à 1.
http://home.gna.org/gswebkit/(...)
A suivre !
[^] # Re: cocoa et "write once compile everywhere"?
Posté par oops (site web personnel) . Évalué à 2.
>http://home.gna.org/gswebkit/(...(...))
http://lists.gnu.org/archive/html/discuss-gnustep/2004-09/msg00118.(...)
En gros il va falloir attendre gcc-4.0 ....
[^] # Re: cocoa et "write once compile everywhere"?
Posté par Talou (site web personnel) . Évalué à 1.
C'est un peu rageant en effet... J'espèrais pouvoir tester les sites en lives dans un khtml sauce apple directement sous linux... mais c'est pas pour aujourd'hui :/
Dommage
# enlarge your penis
Posté par TImaniac (site web personnel) . Évalué à 7.
On peut avoir des arguments ? En quoi cette plateforme, surement superbe, permet-elle de développer plus rapidement une application ? qui de plus s'intègrera dans tous les environnements sur toutes les plateformes ? Parcque bon, celà fait quand meme longtemps que ca se saurait si ce saint graal avait été atteind...
Sinon ben bon anniversaire, et contrairement à ce qui est dit plus haut, celà peut-etre très beau, cf Cocoa.
[^] # Re: enlarge your penis
Posté par Pierre Tramo (site web personnel) . Évalué à -1.
[^] # Re: enlarge your penis
Posté par Nicolas Roard (site web personnel) . Évalué à 3.
On peut aussi se dire que malgres tout, c'est quand meme plutot efficace, si tu regardes le peu de developpeurs qui ont bosses dessus et ce qui existe aujourd'hui (meme si c'est pas parfait).
Concernant le dev rapide d'appli avec OpenStep, c'est en effet en general plus rapide a coder qu'avec d'autres trucs -- en particulier grace a InterfaceBuilder/Gorm, selon mon experience et selon l'avis de ceux qui ont essayes :-)
Maintenant c'est sur que par exemple Qt est une tres bonne lib, et que donc la difference de rapidite entre un dev fait avec OpenStep et un dev fait avec Qt est moins flagrante qu'il y a dix ans (et quelque part, encore heureux !).
Reste que l'on developpe tres rapidement en utilisant OpenStep, ca, c'est une evidence. Et que je pense que ca reste plus rapide pour developper une appli graphique que nombre d'autres solutions. Ce serait bien cool que l'editeur EOF graphique soit enfin release, ca serait pas mal pour les bases de donnes aussi.. :) m'enfin bon..
[^] # Re: enlarge your penis
Posté par TImaniac (site web personnel) . Évalué à 1.
Et quel IDE permet de tirer pleinement partie de cette plateforme ? Parcque bon, question productivité, on peut y aller à coup de Visual Studio, et là aussi tu vas pouvoir anlarger ton penis en encore moins de temps...
Sérieux je veux des arguments.
[^] # Re:
Posté par nicolassanchez . Évalué à 6.
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.
[^] # Re: Re:
Posté par Nicolas Roard (site web personnel) . Évalué à 5.
Vu qu'on travaille avec des objets, tu peux aussi te creer tes propres palettes d'objets (pas forcement graphiques) a utiliser dans Gorm et les lier avec ton programme, les instancier, etc. Gorm permet egalement de creer rapidement des objets quelconques et genere le code Objective-C dans ce cas.
Ajoutons que du coup, tu peux tester l'interface de ton programme 'en live' sans meme qu'il soit necessaire de compiler quoi que ce soit -- les objets sont instancies a la volee et ca roule. Pratique pour tester rapidement le fonctionnement.
Bref, on fait de prog orientee objet et ca se sent. Et de plus, le framework graphique (AppKit), est vraiment particulierement bien fichu. vraiment. Il est tres tres rare qu'on ait besoin par exemple de deriver une classe; on utilise plutot des objets delegues, etc.
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 :-)
[^] # Re: Re:
Posté par nicolassanchez . Évalué à 3.
Ça ne serait pas possible en partant de StepTalk ?
[^] # Re: Re:
Posté par Nicolas Roard (site web personnel) . Évalué à 1.
[^] # Re: enlarge your penis
Posté par nicolassanchez . Évalué à 2.
[^] # Re: enlarge your penis
Posté par TImaniac (site web personnel) . Évalué à 1.
Ben, à part le fait qu'il sont apparement plutôt fier du fait que le framework n'a quasiment pas bougé depuis 10 ans (ce dont je m'en fou pas ma à vrai dire, ce uqi compte pour moi, c'est ce que je peux faire maintenant et si je peux toujours faire tourner ce que j'avais fait avant), je n'ai vraiment rien vu de spécial qui fait que cette plateforme roxe largement J2EE ou .NET.
Donc bref, c quoi qui enlarge mon penis ?
[^] # Re: enlarge your penis
Posté par Anonyme . Évalué à 1.
Sans trop rentrer dans le troll, je pense que GNUStep pour l'instant est tout de meme une solution a ne pas ecarter. En effet .NET sous unix (cad mono) commence a peine a etre exploitable (pour les perfos c'est pas encore ca), et Java a quelques problemes de licences qui, sans trop vouloir etre extremiste, pose un reel probleme d'independance de ce types d'applications.
On se retrouve donc avec 3 plate-formes differentes, a faire le choix entre les perfos, et les problemes de licences. C'est a toi de decider apres ce qui est prioritaire pour toi en misant sur l'une de ces technos en esperant peut etre qu'a l'avenire les choses changeront dans le bon sens.
J'ai volontairement ecarté Gnome et KDE qui ne sont pas multiplate-forme ainsi que Mozilla qui est plus destiné a de "petites" appli ou a des appli web.
[^] # Re: enlarge your penis
Posté par TImaniac (site web personnel) . Évalué à 0.
C'est pas le tout de promettre l'interopérabilité, mais si celà doit se faire au détriment de l'ergonomie parcqu'il n'y a pas d'intégration voilà quoi...
[^] # Re: enlarge your penis
Posté par nicolassanchez . Évalué à 2.
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.
[^] # Re: enlarge your penis
Posté par TImaniac (site web personnel) . Évalué à 3.
Ah bon le langage est limité à la plateforme ? (???)
Je ne vois pas le rapport avec Gtk ou Qt...
Ben si, moi j'en vois 1 : si j'ai envie d'intégrer une appli écrite en Objective-C dans un environnement Gnome ou KDE. S'il n'y a aucune possibilité d'intégration de cette plateforme aux environnements existant, je comprends nettement mieux pourquoi personne n'utilise NeXTStep en dehors de l'environnement MacOSX qui a été développé pour...
C'est gentil la portabilité
C'est gentil un beau langage
C'est gentil une belle plateforme super puissante et performante qui n'a pas bougé depuis 10 ans et qui va grandement augmenter ma productivité
Mais si je ne peux même pas concevoir une application desktop qui s'intègre ailleur que dans un environnement dédié, ben je dis que c'est normal que ce soit au même stade depuis 20 ans.
Un projet comme Mono a l'avantage de ne pas promettre systématiquement la portabilité, ils préfèrent supporter plusieurs environnement (Windows, Gnome et Cocoa) et promettre la portabilité de ce qui DOIT etre portable (bref, pas l'interface)
[^] # Re: enlarge your penis
Posté par nicolassanchez . Évalué à 3.
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...
[^] # Re: enlarge your penis
Posté par TImaniac (site web personnel) . Évalué à 3.
T'as sûrement remarqué, on peut faire tourner une 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 ? Pourquoi à ton avis on trouve des applications gMachin et kMachin si une seule suffisait ?
Pourquoi KDE existe ? pourquoi Gnome existe ? S'il n'y avait aucune différence, que la seule était le window mamager, y'a longtemps que les projets auraient fusionné...
Je parle d'ergonomie, il y a des chartes graphiques à respecter dans chaque environnement, et aussi une charte d'ergonomie (nom des menu, emplacement des boutons, format d'une fenêtre de conf, accessibilité, etc.)
Je cherche pas des poux à GNUStep, je m'apercois juste que c'est normal que ce projet en soti toujours à ce stade (pas utilisé).
Mais vraiment n'importe quoi... depuis quand l'interface n'a pas besoin d'être portable ?
Depuis que de nombreux programmeurs croivent que Java & Co vont résoudre tous les problèmes de portabilité, se sont ensuite rendu compte que y'avait un problème d'intégration visuelle (en partie résolu avec des thèmes utilisant les toolkit natifs) 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.
Icaza le dit clairement, la portabilité c'est bien, mais pas au détriment de l'interface.
Mono propose GTK# pour utiliser GTK. Après le fait est que GTK tourne sous MacOSX et Windows, celà peut être une solution portable efficace lorsqu'on ne se soucis pas de faire un soft de qualité (on veut juste qu'il marche partout).
Après Mono marche très bien avec les WinForms sous Windows, et ils bossent d'arrache pied sur Cocoa#, sachant que Qt# est existe également. A ton avis pourquoi ils s'amusent avec tous ces toolkit ? Pour faire joli ?
[^] # Re: enlarge your penis
Posté par nicolassanchez . Évalué à 3.
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.
[^] # Re: enlarge your penis
Posté par TImaniac (site web personnel) . Évalué à 1.
Vi mais comme tu me l'as gentiment fait remarqué dans un de mes commentaires précédents, pour moi l'existant desktop actuellement c'est Gnome et KDE. WindowMaker voilà quoi.
Ca sert à rien d'avoir une plateforme portable si elle ne s'intègre pas dans les environnements les plus utilisés, surtout pour une plateforme desktop.
"C'est super portable, mais on vous conseille d'utiliser WindowMaker"
youpi.
Donc, sur Apple les menus d'applications Qt seront "ergonomique" par rapport au reste des applications.
Youpi alors t'as trouvé une astuce de KDE pour ressembler à Apple et tu crois avoir contredis ma affirmation qui dit que les applications 100% portables s'intègre très mal lorsqu'elle change d'environnement.
Moi je veux rien configurer, je veux utiliser mon application de la même manière que j'utilise les autres applications de mon environnement, sans de voir m'adapter aux particularités "ergonomiques" issue de l'environnement initial de développement.
Pour obtenir une meilleure intégration, il faudra multiplier les types de fenêtres prédéfinies genre dialogue etc.
Dans la plateforme ? Oui c'est une solution, mais on perd une grosse partie des spécificités de chaque plateforme en se contentant des points communs. Ou alors on en est rendu à "imiter" certains composants absent de tel ou tel environnement.
Et puis il ne faut pas oublier qu'il n'y a pas que les fenêtre prédéfinies qui demandent de l'intégration, c'est tout l'interface qui doit être pensée en conséquence.
A l'heure actuelle, la seule solution est de faire une application ou la couche de présentation est bien différenciée du reste de l'application, et de réécrire cette couche pour chaque environnement cible. C'est la seule manière d'avoir une solution de qualité, on se contentera de la portabilité de s autres couches.
J'espère que tu comprends mieux pourquoi je trouves que cette plateforme est jolie mais a oublié le principal objectif de toute solution desktop : l'intégration. Je crois que c'est une des principales causes de ce qui lui arrive. Heuresement que MacOSX l'utilise, parcque sinon j'y verrais pas beaucoup d'intérêt...
[^] # Re: enlarge your penis
Posté par Barnabé . Évalué à 0.
Tu es donc le client idéal pour GNUstep, la plateforme qui homogènise le plus l'ergonomie des applications.
[^] # Re: enlarge your penis
Posté par TImaniac (site web personnel) . Évalué à 2.
Manque de po, j'ai pas de mac.
[^] # Re: enlarge your penis
Posté par golum . Évalué à 3.
ton habitude de mettre des Vi partout ca serait appréciable
Avec ce petit "Vi" on t'imagine derrière ton clavier prendre un air un peu arrogant limite à faire passer tes interlocuteurs pour des c...
Mais je me trompe peut-être , c'est peut-être parce que tu fais de la pub pour ton nouveau projet de portage de Vi sous Mono ;-)
[^] # Re: enlarge your penis
Posté par TImaniac (site web personnel) . Évalué à 2.
Nan je m'étais jamais rendu compte qu'on pouvait interpréter ce mot comme ça, il n'y a aucune arrogance derrière en tout cas :)
[^] # Re: enlarge your penis
Posté par thecat . Évalué à 5.
Cette ergonomie à était trés "pensée" à la base, aprés c'est une question de gout. Donc effectivement une application GNUStep qui démarre sous KDE, sa fait aussi "tache" qu'une application GNOME.
Par contre le look&feel de GNUStep n'est _complet_ que si l'on utilise un windowmanager de type WindowMaker, en gros, GNUStep est alors dans son element.
je m'apercois juste que c'est normal que ce projet en soti toujours à ce stade (pas utilisé)
Je ne vois pas trop pourquoi ... par-ce-que sont ergonomie est trop differentes des poids lours que sont GNOME et KDE?
Ce n'est que depuis trés récemment que l'on peut avoir un bureau KDE ou GNOME trés unifié et sans une application qui fait tache au milieu car il n'existe pas d'equivalent sous G ou K.
Il y a quelques années, tout etait depareillé et on avait des applis gnome; kde, motif et TCL/TK en même temps.
Maintenant il est vrai que cela risque de "choquer" maintenant avec le niveau d'intégration que certains desktop on, mais normalement tu est sencé utilisé le desktop de GNUSTEP: GWorkspace.
Maintenant Mono :
On sait tous que tu trouve cette plateforme super-geniale, qu'elle roxe tout ca mais bon, qu'est-ce-que ca viens faire?
Pour l'instant un framework _complet_ existe pour étres utilisé avec obj-c, c'est GNUStep.
Le nombres d'autres framework ou bibliothèques (comme QT ou GTK) accessible directement via l'obj-c (par bibnding ou autres) est trés limité (surtout en IHM : je n'en vois pas d'autres!). Mais personne ne t'interdit de le faire.
Donc effectivement, vouloir ecrire une application qui s'intègre à KDE ou GNOME en obj-c, c'est moins evident, mais cela n'a rien a voir avec GNUStep.
Autres choses, et pour rentrer un peu plus dans ton troll, obj-c est un excellent langage pour réutiliser l'existant: interfacage direct avec le C, interfacage direct avec le C++ (bon OK, l'equipe de GCC à encore ca dans le TODO mais Apple le fait trés biens), et quelques possibilitées du langages qui n'existent pas ailleur (category, protocol). Ca c'est vnu langage proposant _vraiment_ quelques chose (pas comme c#).
Enfin, GNUStep n'est pas la pour enlarger ton p*, ni même faire croitre ton CA de 250% cette anné, ni même étres 'in' ou flashy branché, et encore moins d'etre sexy ou 'aware'.
Le but c'est d'implémenter des compcept qui, mêmes si ils ont été définis il y a lontemps, sont reconnus (Apple les utilisent!) et sont toujours d'actualité voir en avance même comparé avec d'autres plateforme soit-disant moderne comme mono ou java (en particulier les objets distribués)
[^] # Re: enlarge your penis
Posté par TImaniac (site web personnel) . Évalué à 2.
Je me rend bien compte que la plateforme GNUStep a été pensée dans un nouvel environnement, peut être innovant (j'ai pas testé je ne jugerai donc pas).
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 le dis toi même, utiliser GTK ou Qt pour la partie graphique tout en conservant la plateforme GNUStep, c'est pas l'idéal et y'a pas beaucoup de bindings.
J'ai pris l'exemple de mono parceque je connais bien cette plateforme, et que bien entendu je cherche à comparer une nouveauté (même s'il elle a 10 ans) avec ce que je connais.
La news dit clairement que GNUStep ca roxe, et beaucoup ont l'air de se demander pourquoi elle n'est pas utilisé. Je lis partout que un des gros avantage de rapidité de développement (notamment sur leur site), c'est la portabilité. Mais tu le dis toi même, elle n'est pas bien utile pour l'interface puisque c'est GWorkspace son environnement de prédilection.
Moi je veux une plateforme qui me propose un environnement mais qui me propose aussi de m'intégrer dans les autres environnement. Je trouves celà beaucoup plus important dans le cadre d'une portabilité.
[^] # Re: enlarge your penis
Posté par nicolassanchez . Évalué à 2.
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...
[^] # Re: enlarge your penis
Posté par TImaniac (site web personnel) . Évalué à 2.
Mais celà ne change rien à ce que je dis, celà ne sert à rien de proposer quelque chose d'innovant si c'est pour faire table rase de l'existant.
Pour moi j'associerai désormais TrucStep à la plateforme de MacOSX, mais en aucun cas j'associerai cette plateforme à un choix de portabilité parcque celà s'intègre nul part (ou tout de moins rien n'est fait dans ce sens)
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.
[^] # Re: enlarge your penis
Posté par nicolassanchez . Évalué à 2.
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.
[^] # Re: enlarge your penis
Posté par TImaniac (site web personnel) . Évalué à 2.
vi mais ce ne sont que des pistes, un peu comme dans les mails "enlarge your penis", mais csuffit pas dire c'est innovant pour que ca le soit.
Je veux des exemples concrêt qui me montre que 1 plateforme a de nette avantages par rapport à une autre.
le langage
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.
les outils de développement
Pareil je veux une comparaison avec ce que propose les autres plateformes.
Rien n'a bougé depuis 10 ans, rien du tout.
Ca je sais mais je m'en fou :) Je veux comparer la plateforme maintenant, pas y'a 10 ans. J'écris pas un livre d'histoire, j'essai de savoir quel potentiel a cette plateforme actuellement vis-à-vis de ses promesses.
Il ne fait donc pas table rase sur l'existant, mais il s'inspire d'un autre existant que celui que tu connais...
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.
La seule chose qui ait changé, c'est uniquement pour apple qui a mis de belles couleurs partout.
Oué enfin Apple a fait plus important je trouve : il a conçu des applications concrêtes, bref, un existant.
[^] # Re: enlarge your penis
Posté par nicolassanchez . Évalué à 4.
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 ?
[^] # Re: enlarge your penis
Posté par TImaniac (site web personnel) . Évalué à 3.
Pour ce qui est de l'indépendance du framework vis-à-vis d'un langage, il suffit de prendre l'exemple de GTK qui a été conçu pour être "bindé" facilement et donc utilisable depuis ton langage favori.
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.
Les langages ont beaucoup de points communs, et leurs environnements d'exécution aussi. De toute façon il est toujours possible d'ajouter ce qui manque dans le framework et qui est vital au langage (héritage multiple en Eiffel au dessus de .NET par exemple)
Il ne faut pas oublier que tous les langages sont conçu pour tourner sur des architectures de proc au mode de fonctionnement similaire, il est donc tout à fait possible de faire la même concentration au niveau d'une machien virtuelle par exemple.
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...
Mais justement, que vas-tu devoir faire si tu veux faire une application qui s'intègre dans Windows ou Gnome ?
---> OpenStep se vente d'être portable mais ne t'encourage pas du tout à t'intégrer dans les autres environnements, tu ne trouves pas celà contradictoire ?
Pour travailler sur GNUstep, tu ne dois pas faire table rase sur tes connaissances.
Mon existant n'est pas limité à mes connaissances mais aussi à tout ce que j'ai codé, et apprendre un nouveau framework complet c'est légèrement rédibitoire comme qui dirait. Le langage ca encore c'est surmontable (et parfois agréable)
Au fait, je vois que tu as développé sur .NET dans ton cv, ça faisait parti de ton existant ?
Justement tiens, puisque tu en parles, ben quand je développe une appli qui cible plusieurs environnements, je peux me baser sur la même plateforme (Mono), utiliser le toolkit graphique et m'intégrer comme je l'entend dans les différents environnements sans toucher au reste de mon appli, et cerise sur le gâteau, je peux même réutiliser mes compétences en GTK quand je codais en C, réutiliser la doc existante, les tutoriaux, réutiliser mes libs écritent en C, etc.
[^] # Re: enlarge your penis
Posté par thecat . Évalué à 4.
Bon ecoute, arrète de dire que c'est une avancé terrible d'avoir ces langages sur .Net.
-Pour Eiffel, l'implémentation est du pur hack de gros sagouin (bin faute de mieux quoi, fait tenir un langage avec heritage multiple, types ancrés et assertion sur une plateforme qui ne le supporte ...) ISE à juste réaliser cela pour faire un coup de pub pour son langage (Bertrand Meyer à fait des conférences pour Microsoft) mais aucun utilisateur du langage Eifel penserrais à utiliser mono (Eiffel et deja cross-plateforme).
-Pour Caml, ce lanage posséde déja un interpréteur, une VM, un compilo natif et pleins de bibliothèques, et le tout disponible pour plus d'architecture que .Net (ou mono) donc pouvoir le compiler sur .Net n'est absloument pas une avancé!
Pense que l'on pourrait réaliser un compilateur d'a peu prés n'importe quel langage pour qu'il produise du basic par exemple, oui cela n'aurrait aucun interet, un peu comme .Net qui supporte 50 langages différents.
il suffit de prendre l'exemple de GTK qui a été conçu pour être "bindé" facilement et donc utilisable depuis ton langage favori
Bon faut un peu arreter la, les 'binding' ne sont qu'un pis-aller. Ca se comprend trés biens pour des langages comme python mais un véritable langage (dont le but est une compilation native) aurra des plus qui nécessiteron de réécrire les bibliothèque pour utiliser ces + (en eiffel les agents par exemple)
OpenStep se vente d'être portable mais ne t'encourage pas du tout à t'intégrer dans les autres environnements, tu ne trouves pas celà contradictoire ?
Heu non ... je ne croit pas à une ergonomie parfaite et unique. Mais j'aime cette de NeXT mais bon c'est vrai que les frameworks pourrait y travailler dessu (sous formes de fichier de conf peut-etres?). Mais quel framework propose cela?
et apprendre un nouveau framework complet c'est légèrement rédibitoire comme qui dirait. Le langage ca encore c'est surmontable (et parfois agréable)
Donc tu voudrais un seul framework et plusieurs langages qui l'utilise (tiens ca ressemble à .Net ...). Bon c'est que tu n'a riens compris aux differents apports des langages. Si mon langage possède l'héritage multiple, je _veux_ que le framework l'utilise, si mon langage possède les assertions, je _veux _ que mon framework l'utilise, si mon langage et fonctionel pur, je _veux_ que mon framework soit fonctionel pur, si mon langage et // ou distribué, je veux que mon framework en tienne comptes, sinon il n'y a _aucun_ interet à choisir tel ou tel langage (mis a part des notions discutables de syntaxe).
[mono tou ca ...] je peut utiliser le toolkit graphique et m'intégrer comme je l'entend dans les différents environnements sans toucher au reste de mon appli
Heu je fait une application en c# sur mono en utilisant gtk#, elle aurra le look&feel de kde si je l'utilise sous kde, de gnome sous gnome, de cocoa sous macOS, de windows sous windows? Non? ha bin GNUStep c'est pareil.
Par contre quand tu dit que tu t'intègre comme tu l'entend sans toucher au reste de ton applis, tu doit quand même recoder toutes la partie IHM non?
[^] # Re: enlarge your penis
Posté par TImaniac (site web personnel) . Évalué à 1.
Mais tu ne t'ai jamais dis qu'on pouvait avoir besoin d'utiliser quelque chose qui n'est pas disponible dans ton framework ?
A part en C où tu vas tout trouver, tu vas devoir te taper tes bindings à la main ?
SI .NET supporte de nombreux langages ce n'est pas juste à cause de la syntaxe, c'est aussi pour pouvoir utiliser facilement du code existant, justemetn écrit dans ce langage.
Heu non ... je ne croit pas à une ergonomie parfaite et unique. Mais j'aime cette de NeXT mais bon c'est vrai que les frameworks pourrait y travailler dessu (sous formes de fichier de conf peut-etres?). Mais quel framework propose cela?
Aucun que je ne connaisse en tout cas.
C'est bien pour celà que j'ai fortement réagit à cette news :
permet de programmer des applications en quelques heures au lieu de jours
alors que cette plateforme se veut portable. Ce qui m'a fait encore plus sursauter c'est de voir qu'on ne semble pas encourager l'utilisation d'autre toolkit que celui fournit avec GNUStep : bonjour l'encouragement à l'intégration, surtout dans le domaine du dsktop.
Donc tu voudrais un seul framework et plusieurs langages qui l'utilise
Pas forcement, ce que je veux c'est pouvoir réutiliser l'existant et m'y intégrer. Tout les moyens sont bons, mais il ne faut pas refuser l'intégration avec comme excuse la portabilité.
Bon c'est que tu n'a riens compris aux differents apports des langages
Je me rend bien compte que beaucoup de langages ont des spécificités (héritage multiple, ou même esprit même du langage : fonctionnel, impératif, etc.) , mais je constate une chose : la plupart des APIs disponibles sont principalement orientés objet : on vous fournit un ensemble de classes et d'interface (au sens large) pour utiliser nos fonctionnalités, servez-vous en.
Après je suis d'accord que les classes de base des langages doivent évidemment proposer des foncitonnalités propres à chaque langage (d'ailleur souvent ces classes font partie du langage ou de la "base" du langage).
Mais quand il s'agit de réutiliser, et surtout proposer à la réutilisation, il faut utiliser les points communs entre tous les APIs, et c'est là qu'une plateforme comme Mono permet de gagner à mon sens beaucoup plus de temps (suffit de voir le temps mis pour pondre une plateforme productive, vu qu'il s'appui sur un existant éprouvé) que de s'amuser à refaire totalement une plateforme pour un unique langage.
GNUStep est pour moi trop fermé, d'ailleur ça va biend ans la politique actuelle de Apple tiens :) (désolé pour le troll, pas besoin de réagir =) )
Non? ha bin GNUStep c'est pareil.
Sauf que Mono te propose tous les outils pour que tu puisse t'intégrer dans les principaux environnement, c'est dans la philosophie de la plateforme (Qt#, WinForms, GTK#, Cocoa#).
tu doit quand même recoder toutes la partie IHM non?
pas toute, la partie la plus haute oui. Tu peux garder toute la couche de contrôle de l'IHM à mon sens. J'en ai un peu marre de toutes ces promesses à la Java de portabilité totale, promesses reprises par GNUStep sur leur site web, alors qu'à l'arrivé on se retrouve avec des trucs bizzares, les programmeurs clamant faire tourner leurs appli sur toutes les plateformes, et c'est l'utilisateur qui en patie. Je trouve celà en tout cas vraiment dommage pour ce qui est du desktop. Pour ce qui est des appliactions plus spécialisées ou destinées aux informaticiens celà me dérange beaucoup moins.
[^] # Re: enlarge your penis
Posté par golum . Évalué à 2.
Pas d'accord! les caractéristique d'un langage conditionnent ce qu'on peut faire avec et si on s'en sert pour batir un framework, les autres langages wrappés dessus devront s'adapter aux limitations (différences) associées au langage d'implémentation
Les exemples sont nombreux mais en voici un explicite qui fera plaisir au gnustep addicted ici présent puisque c'est l'aveu du propre developpeur du toolkit graphique Fox ecrit en C++.
http://www.fox-toolkit.org/faq.html#CALLBACKS(...)
dixit pour les pressés
"Were FOX written in Objective-C, one could achieve the goal of type-safety as well; C++ clearly limits our choices"
[^] # Re: enlarge your penis
Posté par TImaniac (site web personnel) . Évalué à 2.
Pour moi tu veux faire un API, tu le fais dans le langage que tu veux, mais l'idéal est tout de même de lui donner une interface "générique" utilisable par le maximum de langage, bref principalement de simple méthodes, et pourquoi pas orienté objet, ce qui correspond à la plupart des langages.
Après il peut être possible de rajouter une couche au dessus pour faciliter l'intégration dans un langage particulier, mais pour moi un framework (autre que le framework qui contient String & Co, les APIs de base d'un langage quoi) n'a pas pour ambition de s'intégrer dans un langage mais de fournir une base sans qu'on est besoin de réinventer la roue dans chaque plateforme.
Enfin si tu préfères toujours réinventer la roue, ne pas favoriser l'interopérabilité des plateformes, et proposer des solutions dispo que pour un seul langage, libre à toi de l'écrire en Objective-C, mais il ne faut pas s'étonner après si personne utilise cette plateforme.
[^] # Re: enlarge your penis
Posté par nicolassanchez . Évalué à 3.
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.
[^] # Re: enlarge your penis
Posté par TImaniac (site web personnel) . Évalué à 2.
Parcque la plateforme Mono est une implémentation de .NET, et que .NET a été conçu pour réutiliser facilement l'existant, notamment du code écrit en C.
C# inclu les notions de pointeurs, de structure, etc., c'est pas pour rien.
[DllImport("mylib.so")]
void monprototypedefonction(String param1, truc param2);
et hop maintenant je peux l'utiliser.
Autre facilité : le compilateur C++ de Microsoft permet de mixer code managé et code natif, il suffit de faire :
#include <stdio.h>
et zou ca marche.
De plus j'ajouterai qu'en plus des facilités offertes, la philosophie de la plateforme encourage à réutiliser l'existant.
Enfin Mono propose une interface pour utiliser facilement du code .NET depuis l'extérieur, Mono est alors vu comme n'importe quelle bibliothèque.
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.
A vrai dire sans connaître ObjC je m'attendais à cette compatbilité, mais j'ai commencé à douté en lisant les commentaires de certains... tu me rassures :)
Le jour où GNUstep sera parfaitement exploitable,
Elle n'est pas exploitable ? Pourquoi ?
L'implémentation d'Apple n'est-elle pas exploitable ?
C'est bien parcque Apple a choisi cette plateforme pour son OS que je m'y intéresse et que je ne doute pas qu'elle a des qualités. 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é, et tant que j'ai pas de mac, ben...
Ensuite concernant la compatibilité
Je parlais pas de la compatibilité d'implémentation (celle de Mono a quand même pour objectif de faire tourner une appli Windows sans la recompiler, ce qui marche très bien pour la partie ASP.NET par exemple), mais d'interopérabilité, bref d'intégration avec l'existant.
[^] # Re: enlarge your penis
Posté par nicolassanchez . Évalué à 2.
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.
[^] # Re: enlarge your penis
Posté par TImaniac (site web personnel) . Évalué à 2.
Ce n'est pas du tout le but affiché par Gtk ou Qt qui sont de simple toolkit graphique, pas une plateforme complète.
Quand à Java voilà pourquoi je ne l'aime pas :)
[^] # Re: enlarge your penis
Posté par Erwan . Évalué à 2.
[^] # Re: enlarge your penis
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: enlarge your penis
Posté par Guesdon Manuel (site web personnel) . Évalué à 1.
Stop the FUD (tm) !
Il est utilisé et meme en environnement commercial:
o Turbocat WebMail,
o eCommStep,
o OpenGroupware (qui utilise gnustep-core ou qui devrait l'utiliser bientot).
Sans compter que certains developpeurs du projet d'en servent pour leurs boite en interne ou pour leurs clients.
On avait meme faillit s'en servir pour le portail boursier Voila, il y a quelques années...
Manuel
[^] # Re: enlarge your penis
Posté par bleh . Évalué à 1.
Tu sais un langage reste quand même limité par les API disponibles. La seule API complète qui utilise Objective-C est le framework GNUStep mais il y'a eu dans un passé récent des tentatives de faire des bindings Gtk pour Objective-C. Bref je te conseille de lire ce site :
http://www.foldr.org/~michaelw/objective-c/(...)
Ca te permettra d'avoir une vision plus précise de ce que permet Objective-C et ses avantages par rapport à d'autres langages. Parce que pour l'instant tu discutes sans vraiment connaître, ce qui donne une discussion où on a clairement l'impression que tu cherches à démontrer que GNUstep c'est ringard mais sans argument.
Mais si je ne peux même pas concevoir une application desktop qui s'intègre ailleur que dans un environnement dédié, ben je dis que c'est normal que ce soit au même stade depuis 20 ans.
Tu dis toi même que les applis Gtk ne sont pas intégrées dans KDE par exemple. On est typiquement dans un cas où l'application ne s'intègre pas correctement ailleurs que dans un environnement dédié et pourtant c'est utilisé. Il y'a d'autres raisons qui font ce framework est moins utilisé et il n'y a clairement pas que l'integration.
[^] # Re: enlarge your penis
Posté par Anonyme . Évalué à 1.
C'est a mon avis l'un des principaux problemes de GNUStep actuellement. C'est beau d'avoir un "supair framework", si celui-ci n'est pas capable d'etre integré entierement dans l'environement cible, cela pert de son interet.
Tu peux tres bien decider d'utiliser GNUStep base qui te fournira des objets independants de l'IHM (par exemple : gestion des strings, collections, heure, filesystem, ...) et qui te garantie une independance de la plateforme tout en utilisant derriere GTK ou Qt (via un wrapper C tant que gcc n'est pas capable de marier le C++ a l'ObjC) pour l'IHM.
L'avantage est une integration parfaite dans l'environnment, mais tu perd un peu de l'interet de GNUStep. A mon avis c'est une tres mauvaise solution.
Ou alors tu accepte la contrainte d'avoir un truc horrib^R^R gris ;) qui n'est pas du tout integré, et qui ne fonctionne pas si bien que ca sous windows, et tu croises les doigts pour que le support de windows arrive au bout et que l'IHM Gnustep soit themable. C'est pour ca que je prete beaucoup d'attention au projet de nicolas, Cameleon, car il permettra d'utiliser des skins "approchant" le theme du desktop (un peu comme firefox aujourd'hui).
[^] # Re: enlarge your penis
Posté par nicolassanchez . Évalué à 1.
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...
[^] # Re: enlarge your penis
Posté par TImaniac (site web personnel) . Évalué à 2.
Cette solution est pénible, je te l'accorde (celà donne du boulot au programmeur), mais je ne vois pas d'autres solutions pour obtenir une parfaite intégration, critère pour moi relativement vital pour une applicatoin desktop tout public.
Le choix des thèmes qui s'intègre ne résoud que le problème d'intégration visuelle, pas d'ergonomie.
[^] # Re: enlarge your penis
Posté par Nicolas Roard (site web personnel) . Évalué à 3.
Les thèmes, non. Les fichiers interface, oui. Comme expliqué précédemment, les fichiers "interface" sont bien plus que la description visuelle de l'UI, et tout ça est fait à partir de Gorm, ce qui est quand même vachement pratique. Ce que je n'ai pas (ré)expliqué, c'est que tu peux avoir un fichier d'interface *par* language -- ce qui permet de justement faire mieux coller l'UI aux spécificités d'un language (par exemple, le fait que le français ait des mots généralement plus longs que l'anglais...) -- un programme GNUstep étant organisé dans un répertoire (un "bundle") contenant, en plus du (ou des) binaires, les ressources utilisées par le programme.
À terme, pour l'intégration KDE/GNOME/Windows/etc., on devrait étendre ce mécanisme. Du coup, tu auras d'un côté un thème, pour avoir "l'intégration visuelle" dont tu parle, et tu pourras avoir un autre fichier UI pour résoudre le problème d'ergonomie.
Effectivement, pour le moment, ce n'est pas encore possible -- mais ça en soit ce n'est pas foncièrement difficile à faire (comme je l'ai dit.. c'est déja le cas pour les langages) maintenant qu'on a un GNUstep qui commence à bien tourner.
GNUstep n'est pas la solution ultime qui enlarge ton penis, mais y'a très clairement des possibilitées très intéressantes. Maintenant, personne ne t'oblige à y jeter un coup d'oeil.
[^] # Re: enlarge your penis
Posté par Erwan . Évalué à 2.
[^] # Re: enlarge your penis
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 4.
Généralement, une bonne motivation.
Sinon, il paraitrait qu'il existe des petites pilules bleues, un genre de poudre verte pour la bite...
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Oui et Non Re: enlarge your penis
Posté par Guesdon Manuel (site web personnel) . Évalué à 3.
Pour Windows, ca progresse AFAIK.
Il suffit de suivre les listes de discussion pour voir la progression.
Manuel
[^] # Re: enlarge your penis
Posté par deftones_chris . Évalué à 2.
Perso, je suis développeur Cocoa (donc sous osX) et depuis que j'ai découvert Objective C et ce framework , j'ai beaucoup de mal a aller sur d'autres :)
Côté arguments... déjà le langage utilisé (objC). Si tu veux avoir plus d'infos dessus, une recherche sur Google t'en donnera beaucoup plus (à quoi bon faire un copier coller ici).
Et il y a également le framework en lui même qui est bien pensé avec pas mal de bonnes idées (comme les delegate par exemple).
Je ne détaille pas plus car si tu veux vraiment essayer alors tu iras sur les sites web qui en parlent. Dans le cas contraire, cela serait une perte de temps et d'espace. Pour moi GnuStep tout comme Cocoa sont des bijoux de conception pour les déveleppeurs (surtout comparé à GTK par exemple). Dès que le look sera plus fun, il aura un succés fou :) Regardez, GTK s'est développé alors que pourtant .... (heureusement que la version 2 est sortie ;) )
PS: à l'équipe de Gnustep, j'espère que tout ce qui touche aux bindings en Cocoa pourra être intégré (et j'imagine que cela doit être du boulot).
# article wikipedia à compléter
Posté par j (site web personnel) . Évalué à 2.
[^] # Re: article wikipedia à compléter
Posté par modr123 . Évalué à 0.
en réalité c'est Next qui a racheté apple
ok je suis déja pati -> []
# Lien OpenStep
Posté par j (site web personnel) . Évalué à 2.
OpenStep n'a plus de page officielle ?
http://fr.wikipedia.org/wiki/OPENSTEP(...)
# Hors sujet mais pas tant que ça
Posté par fmaz fmaz . Évalué à 10.
1. OpenStep, c'est bien mangez-en, vous coderez plus vite, mieux tout ça;
2. Connais pas mais si c'était mieux, ça se saurait.
Je ne connais pas OpenStep mais le second type d'argument m'ennerve.
Il y a maintenant 8 ans, on m'a fait découvrir ocaml.
J'ai assez vite trouvé que c'était pas mal: un langage qui compile en natif mais
qui tourne aussi sur une machine virtuelle, c'est bien,ça permet de ne pas
toujours recompiler. En plus, à l'époque, le code compilé tournait peut-être
2 fois plus vite que la version natif. Ce langage était (et est toujours) développé
à l'INRIA par une petite équipe de bourrins.
À la même époque, on commençait à entredre parler de java: la révolution,
on a inventé les machines virtuelles, vous pourrez ne compiler qu'une seule
fois et ça tournera partout. Moi, ça me faisait rire. Surtout que j'ai eu à coder
en java à cette époque, sur la jvm de SUN (j'étais sur solaris). La révolution
java, je la trouvai risible. Mais les marcketeux de chez SUN étaient bons et
SUN avait assez de sous pour que tout le monde crois que java était génial.
Je ne dis pas que ce langage n'apportait rien mais il était déjà très en retard
sur beaucoup de points par rapport à certains langages académiques. Vous
allez dire que je lance un FUD et que dans cette enfilade de messages, on en
tient un et c'est suffisant. Ce que je voudrai dire, c'est que les personnes
à qui je parlais d'ocaml me disaient toutes que si ocaml, c'était bien, ça se
saurait, que les gens l'utiliseraient etc...
Quelques années plus tard, à la fac, j'ai eu un projet « compilation ». Le
langage était imposé: ocaml. Il y a eu des haut cris: ocaml, c'est de la
merde... La prof à tenu bon. En trois mois, toute la promo a appris un
nouveau langage et a écrit un compilateur pour un sous-langage de
smalltalk. Et toute la promo était fan d'ocaml. Cette même année, un prof
a tenu à ce qu'on fasse un projet en C++. Le premier jour, je lui ai dit que
C++ n'était pas adapté à ce qu'il voulait faire et qu'ocaml serait mieux.
Il a tenu bon. Trois mois plus tard, aucun projet ne fonctionnait et en deux
heures, je lui ai codé son truc en ocaml. Il m'a répondu que peut-être mon
truc fonctionnait mais c'était forcément lent. On a fait la course. Mon truc
codé en 2 heures en ocaml allait plus vite que le sien codé en C++.
Dites les gens, le problème de beaucoup de projets est que c'est chaint
de réfléchir. On veut pondre un truc vite. Alors on ne prend pas le temps
de réfléchir, on fonce tête baissée et on sort une première version. Et puis
on se rend compte que c'est largement sous-optimal alors on modifie la
spécif et on sort une seconde version, puis une troisième...
En 96, quand je codais en java, le compilo me sortait déjà qu'un certain
nombre de chose que je faisais étaient « deprecated ». Ils avaient du
réflichir longtemps avant de les définir pour que si peu de temps après, ce
soit déjà deprecated.
Alors, je me répète, je ne connais pas OpenStep mais
1. Si les spécifs d'OpenStep n'ont pas changée en 10 ans et qu'elles
permettent de faire des trucs (cf. cocoa), je trouve que ce point seul
justifie qu'on s'y intéresse;
2. Affirmer que si c'était bien, ça se saurait et que de toute façon,
C++, qt, gtk ou n'importe quoi d'autre, c'est fondamentalement mieux,
c'est d'une connerie et d'une étroitesse d'esprit affolante.
Frédéric
P.S. Le fait que je n'ai lu aucun vrai argument contre OpenStep et le
fait que la spécif reste d'actualité me font penser qu'OpenStep, c'est
bien mangez-en.
[^] # Re: Hors sujet mais pas tant que ça
Posté par Larry Cow . Évalué à 4.
C++, qt, gtk ou n'importe quoi d'autre, c'est fondamentalement mieux,
c'est d'une connerie et d'une étroitesse d'esprit affolante.
Sans compter que c'est grosso-modo l'argument du fan-club des produits Microsoft.
"Franchement, si Linux c'était vraiment mieux que Windows, y'a longtemps qu'on n'utiliserait plus que ça."
Chapeau bas, messieurs.
[^] # Re: Hors sujet mais pas tant que ça
Posté par j (site web personnel) . Évalué à 4.
(Il y eut une corrélation de langage pour Objective-C, mais ça n'a pas eut de suite)
[^] # Re: Hors sujet mais pas tant que ça
Posté par 007 . Évalué à -2.
Ça reste généralement vrai même si peut-être ici ce n'est pas le cas.
Ce qui me gène dans ton argument c'est qui ne s'appuie que sur l'incompétence des autres et les autres ne sont rien moins que les développeurs du logiciel libre qui dans la grande majorité des cas savent adopter de nouvelles solutions et sont relativement insensible aux propos marketing. Java n'est pas un succès délirant dans le logiciel libre. Python est très utilisé, ruby se fait une "place au soleil", etc.
> 2. Affirmer que si c'était bien, ça se saurait et que de toute façon,
C++, qt, gtk ou n'importe quoi d'autre, c'est fondamentalement mieux,
c'est d'une connerie et d'une étroitesse d'esprit affolante.
Il doit bien y avoir de solides raisons autre que la "paresse" pour que les gens développent gtk+, gnome, KDE, ... alors qu'il y a déjà OpenStep. Nier ce fait, c'est aussi faire preuve "d'une étroitesse d'esprit affolante".
[^] # Re: Hors sujet mais pas tant que ça
Posté par Larry Cow . Évalué à 4.
Tu aurais une "solide" raison pour justifier le manque d'intérêt de la communauté pour OCaml? C'est pourtant un langage libre, fiable (typage fort et strict et tout), performant (la version compilée n'a pas à rougir devant C++), souple (possibilité de choisir entre du bytecode, de l'interpreté pur ou du natif), interopérable (via le C, notamment), et j'en passe.
La seule raison que je vois à ce manque d'intérêt, c'est qu'il prône un mode de pensée qui n'est pas beaucoup répandu: le fonctionnel. Sans aller jusqu'à taxer les gens du libre de paresse, il faut bien admettre que quand on n'a pas l'habitude, on a du mal à s'y mettre. Et moi-même, malgré tout l'intérêt que je porte à ce langage, je me tourne de plus en plus vers python.
C'est, il me semble, un phenomène similaire qui frappe Openstep et ObjectiveC. J'ignore quel est l'aspect qui "dérange" (à mon avis, c'est dû à son approche du paradigme objet très éloignée de la vision C++/Java), mais je pense que c'est plus un "rejet" de la part de la communauté qu'un réel vice de conception dans le langage ou dans l'API.
[^] # Re: Hors sujet mais pas tant que ça
Posté par 007 . Évalué à 0.
Non. Et d'ailleur je ne connais pas OCaml.
Je ne dis pas que OCaml est de la "bouse" car il est peu utilisé. Tu as peut-être raison lorsque tu dis que OCaml est injustement impopulaire et les différents arguments que tu avances sur du _vécu_ sont pertinents et intéressants.
Je dis simplement que "2. Affirmer que si c'était bien (...) c'est d'une connerie et d'une étroitesse d'esprit affolante" n'est pas la marque d'une personne "large" d'esprit :-)
> je pense que c'est plus un "rejet" de la part de la communauté qu'un réel vice de conception dans le langage ou dans l'API.
Mais "voilà"...
Le problème du chois d'un langage (ou autre) est qu'il est fortement basé sur des considérations qu'on ne peut ramener à sa "conception" ou son API. Il y a tout un tas de contraintes qui influence énormément.
Au premier abord, le C est nul et se fait explosé par le C++. Dans la pratique, le C reste génial et pas pour des raisons de conceptions évidentes. Le C++ aussi est génial :-) Et OCaml sûrement aussi :-)
Quoi ? Oui, python aussi :-)
Je crois que ça suffit maintenant.
[^] # Re: Hors sujet mais pas tant que ça
Posté par nicolassanchez . Évalué à 4.
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.
[^] # Re: Hors sujet mais pas tant que ça
Posté par golum . Évalué à 0.
[^] # Re: Hors sujet mais pas tant que ça
Posté par dab . Évalué à 2.
Je comprends cependant pourquoi celà peut paraitre plus clair au yeux de certains.
C'est un peu comme si la doc de la méthode était dans le code l'appelant. Pas besoin de chercher à quoi correspond le premier paramètre de la méthode, le deuxième, etc..
On le voit directement ( même si les varibles passées à la méthode permettent de le savoir).
[^] # Re: Hors sujet mais pas tant que ça
Posté par Philip Marlowe . Évalué à 0.
echantillon_courant := centri.nacelles.item (parcours.item (iteration).numero_nacelle).emplacements.item (parcours.item (iteration).numero_emplacement).element
[^] # Re: Hors sujet mais pas tant que ça
Posté par nicolassanchez . Évalué à 2.
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.
[^] # Re: Hors sujet mais pas tant que ça
Posté par Philip Marlowe . Évalué à 0.
Le rotor de la centri contient donc des nacelles munies d'emplacements qui peuvent contenir des échantillons. Il y aurait moyen de décomposer un peu plus le traitement, mais je trouve que ça se lit déjà très bien comme ça...
[^] # Re: Hors sujet mais pas tant que ça
Posté par Larry Cow . Évalué à 2.
... parce que tu sais de quoi ça parle. Si je te sors un compute_values(str, valx, valy, 0) hors contexte, tu risques fort d'avoir du mal à comprendre la logique sous-jacente (en plus c'est un exemple pris au hasard, mais bon).
Le fait de nommer les paramêtres, que ce soit façon SmallTalk/ObjC ou façon python, permet d'améliorer grandement la lisibilité du code.
En plus, dans le cas d'ObjC, les étiquettes des paramêtres sont pris en compte dans la signature de la fonction. Ca permet une forme de polymorphisme paramêtrique, mais totalement désambiguïsée.
[^] # Re: Hors sujet mais pas tant que ça
Posté par Philip Marlowe . Évalué à 0.
Il y a des environnements de dev qui te proposent la liste des paramètres au moment où tu invoques la routine. A contrario de ce que tu dis, le fait de ne pas nommer les paramètres permet d'alléger l'écriture... On ne peut pas tout avoir.
[^] # Re: Hors sujet mais pas tant que ça
Posté par nicolassanchez . Évalué à 3.
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.
[^] # Re: Hors sujet mais pas tant que ça
Posté par Philip Marlowe . Évalué à -1.
Je suis foncièrement d'accord avec toi. Il se trouve juste que j'ai appris la COO avec SmallTalk dont la syntaxe m'a fait souffrir, et que j'ai eu à en connaître d'autres qui me font moins mal. D'accord pour l'éditeur simple, mais si tu es avec un environnment évolué (qui simplifie le travail), dans le cas de certains hop ! un clic droit sur la routine, on ramène le lien sur une sous fenêtre et paf ! on a une image plus ou moins complète de la routine que l'on avait sous les yeux. C'est pas mal non plus.
[^] # Re: Hors sujet mais pas tant que ça
Posté par Larry Cow . Évalué à 2.
Avoir des aides au niveau de l'éditeur est bien entendu une bonne chose, mais (dans ce cas précis) je vois ça un peu comme une rustine, un moyen de combler une défficience du langage.
[^] # Re: Hors sujet mais pas tant que ça
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Hors sujet mais pas tant que ça
Posté par Larry Cow . Évalué à 2.
[^] # Re: Hors sujet mais pas tant que ça
Posté par golum . Évalué à 1.
C'est encore mieux
Vive Anaconda
[]<---
[^] # Re: Hors sujet mais pas tant que ça
Posté par golum . Évalué à 1.
je me corrige
"oui et quand tu peux choisir entre les 2 modes dans le même langage, c'est encore mieux
pour un peu me moinsserais moi même na!
Sérieux, en python on peut passer les argument sans les noms
ou avec et ca dans le même appel genre
objet.drawpoint(15, 50, red=50, blue=100, green=200)
pour les premiers l'ordre est important pour les autres non.
[^] # Re: Hors sujet mais pas tant que ça
Posté par nicolassanchez . Évalué à 2.
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...
[^] # Re: Hors sujet mais pas tant que ça
Posté par Philip Marlowe . Évalué à 0.
echantillon_courant := centri.nacelles.item (le_bon_numero_de_nacelle).emplacements.item (le_bon_numero_d_emplacement).element
Et décomposé comme ça, ça se comprend de suite.
[^] # Re: Hors sujet mais pas tant que ça
Posté par nicolassanchez . Évalué à 3.
10, 15 et 3 te permettent de savoir de quoi il s'agit ?
[^] # Re: Hors sujet mais pas tant que ça
Posté par golum . Évalué à 2.
ce qui me gène c'est que le peremier paramètre soit lié avec le nom du message drawPointWithX;
c'est pourquoi je précisais
[objet drawPoint X: 10 Y: 15 diametre: 3 color: rouge]
m'apparait plus naturel
# Cocoa/Linux
Posté par djibb (site web personnel) . Évalué à 3.
(je n'y conncais rien en prog, c'est juste pour savoir si ca se fait ou si faut s'ecrimer comme nu diable et refaire la GUI)
Le logiciel est la :
http://lynkeos.sourceforge.net/french/index.html(...)
Si c'est possible et que quelqu'un(e) est intéressé(e)... On est hyper preneur !! ("on" c'est l'équipe de ca : http://www.lin4astro.org(...) )
[^] # Re: Cocoa/Linux
Posté par Nicolas Roard (site web personnel) . Évalué à 3.
M'enfin pour le reste, c'est à dire faire du traitement sur des images, à priori, y'a pas de raison. Je jette un oeil demain, si je peux.
[^] # Re: Cocoa/Linux
Posté par gnujsa . Évalué à 3.
Quicktime For Linux (sous LGPL):
http://heroinewarrior.com/quicktime.php3(...)
Mais apparement ça n'est que pour les videos quicktime non-compressées.
[^] # Re: Cocoa/Linux
Posté par Nicolas Roard (site web personnel) . Évalué à 1.
Très intéressant ! m'en vais tester tout ça :-)
Espérons qu'ils ont implémentés les fonctions utilisées par lynkeos..
Merci!
[^] # Re: Cocoa/Linux
Posté par Nicolas Roard (site web personnel) . Évalué à 1.
Et comme Lynkeos utilise NSMovie (un fontend Cocoa pour quicktime) un peu partout (c'est a dire que son "unite de travail" ce sont des films, en fait...), ben c'est chiant. En y allant a la hache, ca compile, m'enfin, ca fait plus grand chose :)
Avec une separation plus claire Quicktime/non Quicktime, ou en ajoutant une classe d'abstraction, on doit pouvoir l'utiliser sans trop de problemes sous linux (d'autant qu'il utilise pas franchement des capacitees fabuleuses de quictime: il utilise juste le fait de traiter une serie d'image comme un film) mais en l'etat, c'est un chouilla plus de boulot que de recompiler, vu qu'il faut modifier l'architecture du programme pour faire ca proprement... et j'ai pas trop le temps :) (d'autant que je vois que vaguement a quoi sert le programme :)
M'enfin s'il y a un courageux, ou si vous arrivez a convaincre les auteurs de faire une version "sans quicktime" .. c'est toujours le probleme quand on utilise un truc proprio :-/
[^] # Re: Cocoa/Linux
Posté par djibb (site web personnel) . Évalué à 2.
1) on a pas besoin du quicktime. moi ce qui compte c'est qu'il me pernne mes 300-500 images. Après, qu'elles soient dans le conteneur Quicktime ou avi... pour l'astro on s'en fiche.
>: il utilise juste le fait de traiter une serie d'image comme un film
voila, c'est ca que je voulais dire. aulieu d'enregitrer 500fichiers, on en a qu'un... bof, ca change rien.
>d'autant que je vois que vaguement a quoi sert le programme :)
Le programme sert a :
charger des images, faire des tranformée de fourier dessus pour arrriver a les aligner. Puis additionner ces images, pour en faire 1 belle. et enfin faire des traitements dessus (deconvolution)
[^] # Re: Cocoa/Linux
Posté par Nicolas Roard (site web personnel) . Évalué à 2.
[^] # Re: Cocoa/Linux
Posté par Larry Cow . Évalué à 3.
Je n'ai aucune idée de ce que fait le NSMovie de GNUstep actuellement, ni de la charge de travail nécessaire pour encapsuler ffmpeg dedans, mais ça fournirait un moyen relativement portable de travailler avec des vidéos.
[^] # Re: Cocoa/Linux
Posté par Nicolas Roard (site web personnel) . Évalué à 2.
par contre pour un programme qui veut rapidement integrer une video, ca doit etre faisable.
[^] # Re: Cocoa/Linux
Posté par nicolassanchez . Évalué à 2.
J'ai l'impression qu'il faut surtout redévelopper NSMovieView qui apparemment récupère le pointeur vers le film de notre NSMovie.
[^] # Re: Cocoa/Linux
Posté par gnumdk (site web personnel) . Évalué à 2.
# Questions sur la portabilité
Posté par Gabriel . Évalué à 2.
Juste pour faire le point sur l'état de l'art, comme dirait mon client : Qu'est-ce qu'il en est de la portabilité?
Linux<->Apple <-> Windows (surtout)
Est-ce une question de méthode, pour être portable? Ne pas utiliser certaines méthodes par ex.
Est-ce qu'on peut envisager d'utiliser XCode pour directement faire du code qui tournera sur linux voire Windows? Ou est-ce difficile?
Merci d'avance et longue à lisp fortran net data forth l'assembleur gnuStep!
[^] # Re: Questions sur la portabilité
Posté par Erwan . Évalué à 3.
* Apple: aucun probleme. Ca sera meme du natif, et la rigueur tu peux aussi faire tourner GNUStep dessus (c'est de l'unix)
* Linux => GNUStep: si tu n'as pas programme sur un Mac en utilisant les extensions proprios, pas de probleme
* Windows: GNUStep compile avec cygwin ou MinGW, mais cygwin et cie ca vaut ce que ca vaut (pas une super integration avec le systeme qu'il y a en-dessous).
http://www.gnustep.org/information/machines_1.html(...)
[^] # Re: Questions sur la portabilité (Windows)
Posté par Larry Cow . Évalué à 4.
Par contre, certaines applications GNUstep (GWorkspace, notament) font certaines assertions sur la plateformes sous-javente (en gros, ils considèrent qu'ils ont affaire à un Unix-like). Résultat, ça ne compile même pas sous Windows. Mais c'est, à mon avis, quelque-chose qu'on retrouve surtout dans des applis très liées au système (ce qui, pour moi, est le cas d'un shell graphique).
En fait, la grande question de GNUstep sous Win, c'est son utilité. Du fait des problèmes avec GWorkspace, utiliser un bureau GNUstep complet sous Win n'est pas actuellement envisageable. Et déployer une seule application bien spécifique est rendu un peu délicat par le look "détonnant" de GNUstep.
Cette situation n'est aucunement définitive, et il y a des développeurs soucieux d'améliorer le support de la plateforme Microsoft, et il y a des développeurs (coucou Rio) soucieux d'apporter les thèmes à GNUstep. Mais pour le moment, pour une appli graphique, c'est un peu prématuré.
[^] # Re: Questions sur la portabilité (Windows)
Posté par Nicolas Roard (site web personnel) . Évalué à 3.
J'ai rapidement compile deux-trois applis, voici un screenshot pour ceux que ca interesse: http://www.roard.com/screenshots/gnustep-windows.png(...) -- les applis detonnent pas tant que ca (ok, apres un tour dans Preferences.app pour changer les couleurs, j'avoue :-) -- et faire un theme XP ne devrait pas poser de problemes..)
Bon par contre le backend GDI il est pas encore au niveau de backart, hein...
# Un peu de mémoire...
Posté par Barnabé . Évalué à 5.
Du genre « Linux c'est de l'UNIX, ça a 30 ans, il faut vivre avec son temps »; « C'est un joujou pour développeur »; « Ca fait pas tourner mes applications »; « c'est pas beau » ( Celle la, c'était il y a longtemps... )
Franchement, ça me gonfle un peu d'entendre les mêmes arguments ici, contre GNUstep.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.