dimanche 04 janvier

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Développeur

Liens connexes

GNUstep (1332 hits)
Gorm (515 hits)
GWorkspace (447 hits)
WP: Qu'est-ce que GNUstep ? (1457 hits)

Dépêche modérée par

Ragnagna

Dépêche éditée par

Développeur : Nouvelle version de GNUstep : compatibilité avec InterfaceBuilder

Posté par Nicolas Roard (page perso, ). Modéré le 30 août 2006.

Le projet GNUstep vient de publier de nouvelles versions de ses frameworks : Base 1.13, GUI 0.11, et une nouvelle version du constructeur d'interface graphique de GNUstep, Gorm (1.1).

Il est maintenant possible de lire et sauver des fichiers "nib" venant de MacOS X.

Quelques explications : avec GNUstep et Cocoa, l'interface d'un programme est généralement créé via un outil graphique (InterfaceBuilder sous Mac OS X, Gorm sous GNUstep) et sauvée dans un fichier "nib". Le format des nib étant propriétaire, GNUstep avait son propre format lui permettant d'être portable. Apple ayant décidé de basculer avec les dernières versions d'OS X à un format XML, il était théoriquement possible d'ajouter le support des nib OS X à GNUstep. C'est désormais chose faite !

GNUstep (1332 hits)
Gorm (515 hits)
GWorkspace (447 hits)
WP: Qu'est-ce que GNUstep ? (1457 hits)

> Lire la suite (52 commentaires, moyenne: 2,9). [dépêche : 1792 caractères]

La nouvelle version de Base apporte de nouvelles classe : NSPredicate, meilleure gestion des URL (implémentant les dernières additions d'Apple aux API), et améliore également le support sous Windows.

Du côté de GUI, le changement le plus notable est le support de l'encodage par clé (key encoding) pour toutes les classes graphiques -- ce qui veut dire qu'il est maintenant possible de lire et sauver des fichiers nib venant de Mac OS X.

Il est donc maintenant possible de prendre un programme Cocoa et de le recompiler tel quel sous GNUstep, sans nécessiter de recréer l'interface graphique avec Gorm. De la même façon, on peut prendre un programme GNUstep et le recompiler sous OS X, sans devoir recréer l'interface sous InterfaceBuilder. Bref, un gain de temps extrêmement appréciable, d'autant plus qu'un "nib" contient bien plus que la description de l'interface graphique -- c'est en fait une sérialisation du graphe d'objet, contenant du coup tous les attributs et relations entre objets...

En dehors de cette avancée, les bugfixes usuels, améliorations sur de nombreuses classes (NSWorkspace, GSSystemManager, NSHelpManager, NSTableView, NSToolbar, etc.), support du RTFD, un brin de nettoyage du côté graphique, un commencement de l'intégration avec camaelon (thème), un meilleur support de la GDI sous Windows, ainsi que des progrès sur le backend Cairo.

GWorkspace vient juste de sortir une nouvelle version (0.8.3) , qui apporte beaucoup de bugfixes, ainsi que de la documentation en ligne.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

youpi c'est mercredi !

Posté par Aurélien Girard () le 30/08/2006 à 14:42. (lien). Évalué à 6.

Est-ce qu'on peut manipuler les nib bit par bit ?

~> []

--
BeOS le faisait il y a 10 ans.

[^]Re: youpi c'est mercredi !

Posté par yoho (page perso, ) le 30/08/2006 à 16:44. (lien). Évalué à 10.
Oui ! prenons un exemple : foobar.nib après un rot13 devient nibbar.foo

Incompétence

Posté par Rémi baudruche () le 30/08/2006 à 18:12. (lien). Évalué à 6.

Je m'exuse d'avance pour mon incompétence dans ce dommaine.

Bref, j'y comprend pas grand chose sur le rapport avec mac-os

Ca veux dire qu'on pourra faire tourner des programmes mac-os sous gnu-step et inversement ?
J'ai comme l'impression d'être à coté de la plaque....

[^]Re: Incompétence

Posté par ThesmallgamerS () le 30/08/2006 à 18:16. (lien). Évalué à 6.
Cela veut dire simplement que maintenant on peut compiler une application MacOSX directement sous GNUStep et elle marchera directement (dans la théorie, hein). Et vice-versa.

Avant, le fichier qui décrivait l'interface du programme était incompatible avec GnuStep. Il fallait donc en faire un autre pour porter un programme sous GnuStep.
- [^]Re: Incompétence
  
  Posté par anakin () le 30/08/2006 à 18:54. (lien). Évalué à 9.
  Nuance : ca ne concerne pas l'application mais l'interface seulement...

[^]Re: Incompétence

Posté par Clément varaldi (page perso, ) le 30/08/2006 à 19:31. (lien). Évalué à 8.
En gros (en trèèèèès gros), un .app contient un .nib, du code, et des données. Les données, ma foi, restent des données. Le code est généralement en ObjC, mais ce n'est pas obligatoire, on peut utiliser du perl, du python, etc.

Le .nib, c'est un descriptif de l'interface. Donc, d'une part, les fenêtres, comment les divers éléments s'agencent... Mais aussi et surtout, comme le dit la dépêche, tout ce qui lit l'interface au code. Pour faire une espèce de comparaison un peu foireuse, l'interface, c'est la carrosserie de ta voiture, le code de l'application, le moteur. Le .nib va contenir la carrosserie, mais aussi ce qui lit la carrosserie au moteur.

En général, tu construis donc une interface, à laquelle tu vas lier des événements, des actions, des descriptifs d'objets...
Ensuite, tu génères des templates de code, et tu remplis. C'est très pratique :)
- [^]Re: Incompétence
  
  Posté par Nicolas Roard (page perso, ) le 30/08/2006 à 20:21. (lien). Évalué à 4.
  juste à préciser, quand même: les templates de code consistent simplement à créer pour toi les fichiers des classes éventuellement définies dans Gorm/IB (cad, juste le header et les déclarations des méthodes). Ce n'est pas du tout du code généré pour créer/gêrer l'interface -- ce qui est la grande différence entre l'approche Gorm/IB et le reste des constructeurs d'interface -- vu que l'interface et tout le reste sont déja des objets; un "nib" est simplement la sérialisation dans un fichier de l'ensemble des objets composants l'interface.
  
  Il y a deux principaux avantages à cette approche: 1) ça fait largement moins de code à écrire ou maintenir 2) un nib n'est pas du tout limité aux objets "graphiques" (boutons et autres) mais on peut tout à fait inclure dans le nib n'importe quel objet (objet controlleur de l'interface, un objet métier, etc)
  
  Du coup on peut aussi créer des palettes d'objets à soit et utiliser Gorm (ou IB) comme un outil de RAD très haut niveau, et créer un programme en deux-clics de souris sans une ligne de code ;-) -- bref cette approche permet de réutiliser très facilement des composants.
  
  voir les vidéos de démo: http://xdev.org/gnustep/ (flash)
  - [^]Re: Incompétence
    
    Posté par L Guillaume () le 30/08/2006 à 21:05. (lien). Évalué à 1.
    Et du coup, MS qui est passé a Xcode pour pouvoir porter Office mac en Universal Binaries va pouvoir sortir dans la foulée la version linux de Office :-)
    - [^]Re: Incompétence
      
      Posté par Nicolas Roard (page perso, ) le 30/08/2006 à 21:11. (lien). Évalué à 5.
      Vu qu'office mac utilise Carbon et pas Cocoa, ça semble déja mal barré ;-)
      - [^]Re: Incompétence
        
        Posté par L Guillaume () le 30/08/2006 à 21:19. (lien). Évalué à 0.
        pour la version office X ou office 2004 oui... mais pour la prochaine release, MS a migré d'outil de dév et est maintenant sous Xcode. Il doivent aussi utiliser cocoa car la prochaine version d'office sera "Universelle" (i.e. tournera sous PPC et x86). Et Carbon ne permet pas de réaliser des applis universelles.
        
        [^]Re: Incompétence
        
        Posté par Larry Cow () le 30/08/2006 à 21:27. (lien). Évalué à 1.
        Euuaaah? Carbon ne permet pas de créer d'applis "universelles"? C'est quoi cette histoire, tu aurais des liens? Parce que j'ai des paquets d'appplications "natives" quartz (pas de X11, donc) qui ne sont manifestement pas en Cocoa (Firefox, les outils d'admin Mysql, etc.) et qui sont clairement en UB...
        
        [^]Re: Incompétence
        
        Posté par L Guillaume () le 30/08/2006 à 21:28. (lien). Évalué à 1.
        ah ? bah alors me suis gourré ;)
        
        [^]Re: Incompétence
        
        Posté par L Guillaume () le 30/08/2006 à 21:36. (lien). Évalué à 1.
        http://www.schwieb.com/blog/2006/06/11/rebuilding-a-house/
        effectivement ce n'est pas pour la prochaine release le passage à cocoa
        
        [^]Re: Incompétence
        
        Posté par Larry Cow () le 30/08/2006 à 21:45. (lien). Évalué à 4.
        Pas lu l'article en entier, mais je tiens à rappeller que le but ultime n'est _pas_ de supprimer Carbon au profit de Cocoa. Les deux APIs sont complémentaires, l'une (privilégiée) étant accessibles aux développeurs ObjC (et, jusqu'à peu, Java) et l'autre, moins pratique mais capable de la même chose à 90%, aux développeurs C et C++ (du moins aux développeurs C++ qui veulent pas toucher à ObjC++).
        
        Tant qu'il y aura portage d'applications vers le Mac et que l'ObjC ne sera pas plus répandu, Carbon n'a aucune chance de commencer à disparaître. Le contraire consisterait à se couper de la plupart des développeurs, et Apple n'en a clairement pas envie.

À quoi bon ?

Posté par GPLorDIE () le 30/08/2006 à 22:32. (lien). Évalué à 0.

Je n'ai jamais compris l'interet de GNUstep, non vraiment...
Ce projet rend service à Apple en familiarisant des milliers de développeurs à leurs API propriétaires. Comme toute les API ne seront jamais réimplémentées à 100% dans GNUstep tôt ou tard le développeur libre franchira le pas et passera à Xcode et tout ce qui va avec et il sera perdu pour le monde GNU/Linux (ou BSD, etc etc).

[+] [^]Re: À quoi bon ?

Posté par Gniarf () le 30/08/2006 à 22:40. (lien). Évalué à -2.
et il sera perdu pour le monde GNU/Linux (ou BSD, etc etc)

ne mélangeons pas les torchons et les serviettes.

--
"Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008

[^]Re: À quoi bon ?

Posté par Nicolas Roard (page perso, ) le 30/08/2006 à 22:54. (lien). Évalué à 10.
Ben... les API ne sont pas propriétaires, d'une part... et de deux, l'intérêt n'est selon moi pas (que) d'être compatible avec Apple. L'intérêt c'est de pouvoir disposer de ces api et des outils comme Gorm pour programmer, tout simplement car ce sont des outils assez géniaux !

Pour faire simple: si Apple n'avait pas racheté NeXT et transformé NeXTSTEP en Mac OS X, et même imaginons que NeXT ait coulé complètement... Et bien il y aurait toujours des gens développant GNUstep. L'api et des outils comme Gorm sont, par eux-mêmes, intéressants. Ca reste l'environnement de développement le plus génial et bien foutu que je connaisse (si on excepte Smalltalk -- mais si Smalltalk est un environnement/langage assez fabuleux, l'api est une bouse à bien des égards comparé à OpenStep).

Le fait qu'Apple utilise Cocoa n'est que la cerise sur le gateau pour ceux que ça intéresse; on n'est pas du tout dans le cas de Wine par exemple, ou je doute que les développeurs bossent sur Win32 car ils trouvent l'api agréable à programmer.

[^]Re: À quoi bon ?

Posté par - - () le 01/09/2006 à 06:38. (lien). Évalué à 8.
l'intérêt de gnustep ?

c'est que l'API openstep et les outils de développement de NeXTstep allié à Objective C en faisait le meilleur environnement de développement unix du moment.

maintenant c'est Xcode/cocoa sous Os X. voilà tout.

---------------------
Gnustep est la plus grande erreur de Gnome et KDE : ils auraient du tous se lancer dans gnustep

voilà ce que je pense.

oui gnustep était (est?) balbutiant à l'époque mais tout le prototypage était fait, le langage Objective C gommait bien des débats stériles sur C/C++/JAVA/Mono etc grâce à un runtime puissant et complet
et non l'api n'est PAS propriétaire.

enfin bref, gnustep est simplement victime d'une non-rencontre. au moment du lancement de Kde par dessus QT et de Gimp 0.x les développeurs ne sont pas tombés sur gnustep ou le modèle de gnustep semblaient être trop compliqué pour le simple but du moment.

mais ce fut une erreur.
- [+] [^]Re: À quoi bon ?
  
  Posté par toctoc1 (page perso, ) le 01/09/2006 à 19:56. (lien). Évalué à -1.
  NB : ce matin, ton post était à zero XP, et je suis content de voir que tu es revenu en positif. Je ne comprennais pas pourquoi tu avais été moinsé... ;)
  
  Autant je comprends ton argumentaire sur les qualités intrinsèques de gnustep, autant (et je reconnais que c'est terriblement subjectif) je trouve l'ensemble terriblement laid et dépassé (esthétiquement et ergonomiquement).
  
  je fais le parallèle avec les voitures : la Fuego était une chouette bagnole. Mais qui roule encore en Fuego?
  
  vous pouvez moinser, c'est pas un souci... :D
  
  --
  Faites de l'escrime et du pentathlon à Perpignan !!!
  - [^]Re: À quoi bon ?
    
    Posté par Nicolas Roard (page perso, ) le 01/09/2006 à 21:03. (lien). Évalué à 2.
    oui bon... utiliser un thème peut être ? http://www.etoile-project.org/etoile/blog/
- [^]Re: À quoi bon ?
  
  Posté par Miguel Moquillon (Jabber id, page perso, ) le 04/09/2006 à 13:53. (lien). Évalué à 1.
  Juste pour rajouter que, à mes yeux, et au regard de mon expérience dans le développement objet de logiciels, OpenStep accompagné de son outil InterfaceBuilder/Gorm reste encore le meilleur environnement de développement sous Unix (et même comparé aux autres tares, heu pardon, outils équivalents, sous WIndows).
  
  Le seul environnement que je trouve plus évolué qu'OpenStep avec son InterfaceBuilder/Gorm est Squeak (un environnement Smalltalk), mais son ergonomie et surtout son approche micro-monde peut rebuter (j'avoue avoir moi même du mal).

RTFD

Posté par oops (page perso, ) le 01/09/2006 à 09:25. (lien). Évalué à 0.

Je me demande quel est l'intérêt d'un tel format ?

Il n'est en rien un format standard ( ni standard normalisé / ni standard de fait ).

[^]Re: RTFD

Posté par Nicolas Roard (page perso, ) le 01/09/2006 à 10:39. (lien). Évalué à 4.
L'intérêt ? bah ... effectivement, il n'est ni normalisé ni répandu -- la seule plateforme capable de lire du rtfd en dehors de GNUstep est Mac OS X (et NeXTSTEP/OPENSTEP évidemment).

Mais le RTF est le format par défaut sous NeXT/GNUstep/ OS X pour le texte enrichi; et GNUstep savait donc déja lire/sauver du RTFD. Étendre le parseur pour du RTFD était trivial. le RTFD est une simple application du concept de bundle (en gros, considérer un répertoire comme un document) à un document RTF : c'est tout bêtement un répertoire contenant un ou plusieurs fichiers RTF accompagnés éventuellement d'images ou fichiers liés.

Bref 1) c'était simple à ajouter 2) ça existait sous NeXT et OS X 3) surtout, c'est un moyen simple de sauver facilement n'importe quel contenu enrichi à partir de n'importe quel textview, même contenant des images. Du coup par exemple, TextEdit peut être utilisé comme mini traitement de texte, il suffit de drag'n dropper des images dans la vue texte.

Accessoirement, le code pour lire/sauver du RTF(D) est gêré par un bundle (~plugin) sous GNUstep -- on peut tout à fait avoir le même genre de bundle pour d'autres formats (je voudrais d'ailleurs ajouter HTML en sauvegarde par exemple). Et la beauté de la chose du tout objet c'est là encore que toutes les vues textes disposeront de cette capacité automatiquement... (sans même recompiler)
- [^]Re: RTFD
  
  Posté par Nicolas P. (page perso, ) le 01/09/2006 à 12:22. (lien). Évalué à 1.
  
  (sans même recompiler)
  
  Tiens, c'est intéressant. Les bundles GNUstep ou Cocoa ne sont donc pas implémentés sous forme de librairies ? Ou alors ça vient du fait qu'en objective C les appels de méthodes sont résolus à l'exécution ?
  
  --
  this != '|' ;
  - [^]Re: RTFD
    
    Posté par Nicolas Roard (page perso, ) le 01/09/2006 à 13:44. (lien). Évalué à 3.
    Ce sont bien des librairies; mais effectivement c'est entre autre parce qu'Objective-C utilise un runtime pour le passage de message (cad, le code est bien compilé -- ça reste du C -- mais les messages eux sont dynamiques).
    
    Ceci dit, ce que je dit marche(rait) aussi avec des "plugins" normaux -- c'est juste qu'objective-c est dynamique et baigne dans le polymorphisme... donc ce genre de chose est faisable bien plus facilement.
    - [^]Re: RTFD
      
      Posté par Aurélien Girard () le 01/09/2006 à 14:11. (lien). Évalué à 2.
      Est-ce que c'est comme ça que marchaient les translators de BeOS ?
      Pourtant BeOS n'utilise que du bon vieux C++ des familles (tout le système de messagerie inter-processus était une API C++)
      
      --
      BeOS le faisait il y a 10 ans.
      - [^]Re: RTFD
        
        Posté par Nicolas Roard (page perso, ) le 01/09/2006 à 14:23. (lien). Évalué à 2.
        Je connais pas dans le détail les translators de BeOS, mais c'est probablement une archi similaire -- ce que je voulais dire c'est que faire ça en ObjC c'est trivial ("de base" avec le langage quoi) alors qu'avec C++ c'est évidemment possible (c'est bêtement un plugin -- une librairie partagée hein !) aussi. Mais bon avec un langage dynamique, ce genre d'archi logicielle "ouverte" est évidemment plus simple, alors qu'avec un langage plus statique, ben... c'est moins souple et faut se taper le boulot à la main...
      - [^]Re: RTFD
        
        Posté par oops (page perso, ) le 01/09/2006 à 17:04. (lien). Évalué à 3.
        >Pourtant BeOS n'utilise que du bon vieux C++ des familles (tout le système de
        > messagerie inter-processus était une API C++)
        
        Ce n'est pas inter-processus. C'est un runtime ( donc de plus bas niveau ).
        
        http://www.macdevcenter.com/pub/a/mac/2002/05/24/runtime_par(...)
        et
        http://www.macdevcenter.com/pub/a/mac/2002/05/31/runtime_par(...)
        
        pour plus d'infos.
        
        [^]Re: RTFD
        
        Posté par Nicolas Roard (page perso, ) le 01/09/2006 à 17:23. (lien). Évalué à 1.
        D'un autre côté, on dispose de DistributedObject (DO) sous GNUstep :-P donc faire de la prog inter-processus c'est facile :D -- les objets distants se comportent comme étant locaux (2 lignes à changer en déclarant son objet..). Et les distributed notifications aussi... ;-)
        
        [^]Re: RTFD
        
        Posté par shbrol () le 02/09/2006 à 19:45. (lien). Évalué à 2.
        Ca a l'air sympa pour le developpeur ce que tu nous decris. J'ai vu sur la page de Gorm un lien vers les mini-tutoriels de N. Pero, et aussi un lien vers un livre sur Objective-C. Est ce que ca suffit pour demarrer un petit projet, ou bien il y a d'autres sources d'info ?
        
        [^]Re: RTFD
        
        Posté par Nicolas Roard (page perso, ) le 02/09/2006 à 20:10. (lien). Évalué à 3.
        Oui, les tutoriels de Nicola sont bien pour démarrer. Jette un oeil sur http://www.roard.com/docs/ , je link pas mal de docs/tutoriels (quoique ça fait un bail que je l'ai pas mis à jour). Sinon la plupart des tutoriels pour Cocoa et/ou les docs d'Apple sont utilisables tels quels.
        
        Comme ide, y'a aussi ProjectManager (http://home.gna.org/pmanager/) qui est plutôt sympa.
        
        Comme bouquin, je conseille celui d'Aaron Hillegass, excellent (plutôt l'édition anglaise que française, dont j'ai trouvé la traduc très moyenne, mais bon..). Y'a aussi celui de Garfinkel qui est paraît il très bien. Ils sont orientés Cocoa (même si Aaron parle de GNUstep, m'enfin il parle d'une vieille version...), mais sont focalisés sur le framework, donc appliquables plus ou moins tel quel à GNUstep. Concernant Objective-C uniquement, il y a le très complet petit guide d'O'Reilly sur Objective-C.
        
        [^]Re: RTFD
        
        Posté par oops (page perso, ) le 04/09/2006 à 07:59. (lien). Évalué à 5.
        Je dirais dans l'ordre :
        
        - Apprendre le C
        - Apprendre les grand design patterns
        - Le petit guide O'Reilly ( Apprendre l'ObjC lorsque l'on connait le C est tivial )
        - Les APIs GNUstep
        
        [^]Re: RTFD
        
        Posté par Miguel Moquillon (Jabber id, page perso, ) le 04/09/2006 à 14:06. (lien). Évalué à 1.
        Je ne connaissais pas ProjectManager. Que vaut il par rapport à ProjectCenter ?
        Ce que j'aime dans l'approche de ProjectCenter est qu'il suit celle de Smalltalk ; en effet, je n'aime pas les approches à la Visual C++ où d'un côté tu as une arborescence de tes sources (que je trouve moins facile à utiliser), de l'autre ton code et pour finir tout un tas de boites de propriétés et une liste arborescente du contenu de tes classes d'objets, attributs et méthodes mélangés. J'epsère que ProjectManager ne va pas tomber dans ce travers horrible, mais au vue des captures d'écran, je crains le pire.

http://jesseross.com/clients/gnustep/ui/concepts/

Posté par ctorah () le 02/09/2006 à 14:51. (lien). Évalué à 1.

Ca va ressembler à ça un jour ou pas?
http://jesseross.com/clients/gnustep/ui/concepts/

Le truc du bas serait jolie à la place de window maker

[^]Re: http://jesseross.com/clients/gnustep/ui/concepts/

Posté par Nicolas Roard (page perso, ) le 02/09/2006 à 15:34. (lien). Évalué à 3.
Oui et non -- le thème est déja utilisé par étoilé ( http://www.etoile-project.org et http://www.etoile-project.org/etoile/blog/ , voir les screnshots) .. mais au final pour étoilé on a par défaut un menu horizontal à la mac os, et on veut un "dock" avec des tabs plutôt que le dock montré sur le concept 01.
- [^]Re: http://jesseross.com/clients/gnustep/ui/concepts/
  
  Posté par ctorah () le 02/09/2006 à 21:50. (lien). Évalué à 1.
  J'ai le souvenir que tu promettais ce look pour demain à Gnustep, y a de ça 2-3 ans!
  - [^]Re: http://jesseross.com/clients/gnustep/ui/concepts/
    
    Posté par Nicolas Roard (page perso, ) le 02/09/2006 à 22:33. (lien). Évalué à 2.
    Que veux tu dire ? Je me souviens pas avoir présenté les choses comme ça, mais bon, possible, je suis un incorrigible optimiste combiné à un sale procrastinateur :-)
    
    Si tu parles du support des thèmes sous gnustep, ça fait très longtemps qu'on peut les utiliser... La seule chose c'est que le dit support n'est pas inclu par défaut, faut utiliser Camaelon, mais c'est pas la mort à utiliser hein... J'ai une branche sur le repository gnustep pour intégrer certaines parties de camaelon, mais j'avance pas très vite (j'ai plein d'autres trucs sur le feu, et une thèse à finir). L'intégration serait un _plus_ pour diverses raisons, mais n'est pas nécessaire -- la preuve, on utilise Camaelon avec étoilé, et on utilise bien le thème Nesedah par défaut...
    
    Accessoirement, le look en question, ça peut difficilement faire 2-3 ans -- au pire ça fait dans les un peu plus d'un an, vu que c'est dans ces environs qu'il a été créé par jesse ross si je dit pas n'importe quoi.
    
    'fin bon c'est comme tout hein, si y'a des contributeurs tout ça avance plus rapidement, bizarrement :-)
    - [^]Re: http://jesseross.com/clients/gnustep/ui/concepts/
      
      Posté par ctorah () le 03/09/2006 à 12:34. (lien). Évalué à 1.
      oups, mea culpa, c'était pas y a 2-3 et cétait pas toi
      http://linuxfr.org/comments/643059.html#643059
      
      C'est juste que le concept 01 m'avait bien plu et j'avais pensé que ça remplacerai avantageusement window maker.
      
      mea culpa
- [^]Re: http://jesseross.com/clients/gnustep/ui/concepts/
  
  Posté par Miguel Moquillon (Jabber id, page perso, ) le 04/09/2006 à 14:14. (lien). Évalué à 2.
  Puis-je sugérer que vous n'imposiez pas votre façon de voir sur ce que doit ressembler un environnement de bureau. C'est à dire que l'on ait la possibilité de personnaliser suffisemment l'environnement de bureau pour qu'il puisse correspondre à nos attentes et à notre façon de voir (un peu à la FVWM).
  
  Par exemple, pour le système d'onglets à la place d'un dock, pourquoi pas, mais le menu horizontal, je ne suis pas très chaud.
  En fait, je préfère l'approche du menu vertical de NextStep mais qui serait "accolé" à l'extrémité supérieur gauche de la fenêtre de l'application et qui disparaitrait lorsque l'on passe d'une application à l'autre (au lieu d'être toujours situé au coin supérieur gauche).
  A côté de ceci, par rapport au dock, j'aime bien l'approche d'apwal.

Installer GNUStep ?

Posté par Mildred (Jabber id, page perso, ) le 02/09/2006 à 22:22. (lien). Évalué à 4.

Je dois dire que j'aimerais bien savoir comment installer un environnement GnuStep. je me rapelle une fois avoir essayé mais je n'avais pas compris par où commencer.

- D'abord, les paquets GNUStep des distributions sont ils en général à jour (avec étoilé et tout) ou alors je dois tout compiler à la main ?
- Quels programmes installer (GWorkspace ?) et qu'est ce que je dois mettre dans mon ~/.Xsession ?
- Il me semble qu'on utilise WindowMaker comme gestionnaire de fenêtre ... comment intégrer le mieux les applications GNUStep et WindowMaker.
- Le style de WindowMaker s'adapte il aux styles etoilés ?
- Comment utiliser le gestionnaire de fichiers GNUstep ? Imme semblait que j'avais du mal à ouvrir un fichier avec une application X classique.

J'ai vraiment envie de l'installer, pour le découvrir, pour faire des programmes utilisant GNUStep ... mais lorsque je vais sur le site, je ne vois rien de tout ça, et le site insiste pour dire que c'est juste un frameword. Enfin, derrière il y a quand même un bureau comme on peut le voir sur bon nombre de sceenshoots.

--
La Roue du Temps

[^]Re: Installer GNUStep ?

Posté par Nicolas Roard (page perso, ) le 02/09/2006 à 23:30. (lien). Évalué à 6.
Pour les paquets GNUstep, en général debian est à jour, pour le reste je ne sait pas trop... les ports FreeBSD devraient être ok également, il me semble. Ceci dit concernant debian, les paquets n'ont pas encore été updaté avec la nouvelle version, mais les mainteneurs sont en train des les préparer.

Ceci dit, c'est pas non plus bien difficile à compiler à la main... si les dépendances sont installées.. Un post d'il y a deux jours de Yen-ju : http://www.etoile-project.org/etoile/blog/2006/08/short-guid(...) explique tout ça.

Comme programme, ça dépends de ce que tu veux... GWorkspace comme file manager par exemple; si tu installes étoilé, EtoileMenuServer, etc.

Concernant WindowMaker, non, il ne s'adaptera pas aux thèmes gnustep; pour étoilé on a notre propre window manager, Azalea.

J'ai vraiment envie de l'installer, pour le découvrir, pour faire des programmes utilisant GNUStep ... mais lorsque je vais sur le site, je ne vois rien de tout ça, et le site insiste pour dire que c'est juste un frameword. Enfin, derrière il y a quand même un bureau comme on peut le voir sur bon nombre de sceenshoots.

C'est tout le problème... ce n'est qu'un framework, oui; mais d'un autre côté, il fournit tout ce qu'il faut (presque) pour avoir un bureau (cad que le framework fournit aussi quasiment tout les services nécessaires à un bureau -- notifications, préférences, notion de workspace commun, etc), de telle sorte que simplement utiliser une appli comme gworkspace (pour avoir un gestionnaire de fichier) et d'autres applis utilisant gnustep suffit pour avoir un bureau bien intégré (cf le livecd). D'ou l'ambivalence de GNUstep. Si tu veux, c'est au même niveau que les KDE libs -- elles ne sont pas le bureau KDE, mais elles fournissent tout ce qu'il faut pour créer des applis qui ensemblent forment un bureau.
Sauf qu'en plus, GNUstep fournit des applis pour le développement (Gorm, project center, etc) et même des applis qui sont carrèment fait pour un bureau comme gworkspace.

Mais GNUstep en tant que projet n'a pas eu comme objectif (et rétrospectivement c'est certainement une erreur) de créer un bureau. Il aurait fallu avoir cet objectif depuis longtemps, ou au moins un projet frère chargé d'en créer un...

Pour le moment, étoilé progresse bien, et régulièrement; mais on n'a pas encore un truc tout prêt à utiliser offrant un bureau nickel. Étoilé reste pour le moment une série de librairies, d'outils et d'applications (aaargh on dirait gnustep !!!). Mais bon on espère très fort avancer vite fait vers un bureau réellement utilisable :-D et en particulier, un filemanager + desktop + gestionnaire de session qui tienne la route (gworkspace ne nous plait pas pour diverses raisons).

En attendant.. ben je dirait que la combinaison gworkspace + window maker reste le plus sûr, plus project manager pour le développement ( http://pmanager.sf.net ) et gorm évidemment..
- [^]Re: Installer GNUStep ?
  
  Posté par Mildred (Jabber id, page perso, ) le 03/09/2006 à 08:37. (lien). Évalué à 7.
  C'est bête, juste après mon post, je me seuis lancée dans la compulation de GNUstep ... et c'est très simple : http://gnustep.made-it.com/BuildGuide/ (et c'est la dernière version).
  
  Après, ce que je me demande, c'est comment utiliser GWorkspace. J'ai un exemple très concret. Mon fichier .Xsession (ou .xinitrc, j'ai oublié) contient un script qui va grace à xmessage me demander quelle session je veux lancer (Gnome, Xfce, Etoile, Fvwm ...). Je voulais le modifier pour rajouter Etoilé dans la liste à l'aide de mon éditeur favori (kwrite)
  Je prend GWorkspace, je vais jusqu'au fichier et j'essaie de l'ouvrir, rien à faire, rien ne se passe. Le clic-droit ne propose pas bien plus de choix, je finis par me résoudre à utiliser thunar.
  
  Sinon, dans les System Preferences, section Modifier Keys, le changement des touches de fonctions ne marche pas du tout, du moins je n'arrive pas a faire quelque chose qui puisse être remarqué. De plus dans la section Volumes, il s'obstine à me mettre les chemins par défaut dans Mount points for removable media (/mnt/*) alors que mon système utilise /media/*
  
  De plus, avec Azalea lorsqu'on maximise une fenêtre comme Epiphany, la barre de titre se retrouve cachée par la barre de menus. Un peu gênant même si Alt-clic sur la fenêtre permet d'afficher le menu du WM.
  
  Voila mes premières impressions. Mais bravo pour ce joli bureau. Avec un panel en bas qui permet de switcher entre les fenêtre, d'avoir des bureaux virtuels et une zone de notification pour gajim, gmpc et d'autres, c'est parfaitement utilisable. Reste à switcher vers des applications GNUstep qui sont malhereusement trop rares.
  
  --
  La Roue du Temps
- [+] [^]Re: Installer GNUStep ?
  
  Posté par Mildred (Jabber id, page perso, ) le 03/09/2006 à 08:40. (lien). Évalué à -2.
  C'est bête, juste après mon post, je me seuis lancée dans la compulation de GNUstep ... et c'est très simple : http://gnustep.made-it.com/BuildGuide/ (et c'est la dernière version).
  
  Après, ce que je me demande, c'est comment utiliser GWorkspace. J'ai un exemple très concret. Mon fichier .Xsession (ou .xinitrc, j'ai oublié) contient un script qui va grace à xmessage me demander quelle session je veux lancer (Gnome, Xfce, Etoile, Fvwm ...). Je voulais le modifier pour rajouter Etoilé dans la liste à l'aide de mon éditeur favori (kwrite)
  Je prend GWorkspace, je vais jusqu'au fichier et j'essaie de l'ouvrir, rien à faire, rien ne se passe. Le clic-droit ne propose pas bien plus de choix, je finis par me résoudre à utiliser thunar.
  
  Sinon, dans les System Preferences, section Modifier Keys, le changement des touches de fonctions ne marche pas du tout, du moins je n'arrive pas a faire quelque chose qui puisse être remarqué. De plus dans la section Volumes, il s'obstine à me mettre les chemins par défaut dans Mount points for removable media (/mnt/*) alors que mon système utilise /media/*
  
  De plus, avec Azalea lorsqu'on maximise une fenêtre comme Epiphany, la barre de titre se retrouve cachée par la barre de menus. Un peu gênant même si Alt-clic sur la fenêtre permet d'afficher le menu du WM.
  
  Voila mes premières impressions. Mais bravo pour ce joli bureau. Avec un panel en bas qui permet de switcher entre les fenêtre, d'avoir des bureaux virtuels et une zone de notification pour gajim, gmpc et d'autres, c'est parfaitement utilisable. Reste à switcher vers des applications GNUstep qui sont malhereusement trop rares.
  
  PS: linuxfr me dit que «Votre commentaire a déjà été posté» alors que ce n'est pas le cas lorsque je lis la dépêche. Si je le poste en double, veiller l'excuser, merci
  
  --
  La Roue du Temps

[+] Plagiat

Posté par gaolinn () le 04/09/2006 à 09:10. (lien). Évalué à -8.

Sinon à part repomper le travail des copains ils font quoi les Linuxien

[^]Re: Plagiat

Posté par Mickaël L () le 04/09/2006 à 10:39. (lien). Évalué à 4.
Au choix :

1. Il implémente une API/norme/cequetuveux publique? (java, openstep, posix...)
2. Il ressucite une API qui est morte et que certains voulaient continuer à utiliser? (longtemps avant l'autre résurrection par apple)
3. Il s'amuse avec des trucs sympas entre deux séances de prog en C++ ou avec les APIs win32...

À toi de voir, je sais pas moi...

[^]vive le pompage

Posté par Rémi baudruche () le 04/09/2006 à 10:50. (lien). Évalué à 3.
On pense qu'on a une idée quand on a oublié à qui on l'a emprunté !

J'ai trouvé tout seul cette jolie phrase ! si si !

Moi ce qu'il me plait avec le ll c'est justement le pompage : si quelqu'un a déja fait quelque chose autant le pomper et tant qu'a faire l'améliorer plutôt que de réinventer la roue à chaque fois
- [+] [^]Re: vive le pompage
  
  Posté par gaolinn () le 04/09/2006 à 11:10. (lien). Évalué à -4.
  Il pourrait aussi inventer de nouveaux concepts plutôt que de pomper et de toujours répéter que le logiciel propriétaire bride sa créativité.
  
  La créativité c'est quoi pour les Linuxiens, repomper à tours de bras ou inventer de nouveaux concepts.
  - [^]Re: vive le pompage
    
    Posté par oops (page perso, ) le 04/09/2006 à 11:26. (lien). Évalué à 4.
    Peux tu définir : "nouveaux concepts" et me donner deux / trois examples ?
  - [^]Re: vive le pompage
    
    Posté par Thomas Douillard () le 04/09/2006 à 11:35. (lien). Évalué à 4.
    La créativité, ça veut pas dire nécessairement réinventer la roue systématiquement. En l'occurence, GNUStep c'est une API propre, agréable et puissante d'après ses défenseurs. Il vaut mieux se concentrer sur une API révolutionnaire ou sur les applis qu'on pourra créer une fois cette API et l'IDE associé terminés ?
    
    Un autre intérêt : l'interropérabilité facilitée entre OSX et tous les OS sur lesquels tourne GNUStep.
    
    Enfin, dire que GNUStep n'invente pas de nouveaux concepts, certe, mais de là à dire qu'il y a pas de créativité dans le LL, c'est douteux. Par exemple : de nombreux chercheurs publient du code en GPL, du code issu de recherche, donc pas forcément utilisable tel quel, mais à priori avec des trucs inédits dedans ...
  - [^]Re: vive le pompage
    
    Posté par Erwan (page perso, ) le 04/09/2006 à 21:39. (lien). Évalué à 3.
    Si tu etais un peu plus malin tu comprendrais que l'informatique, c'est plein de gens differents, qui developpent des logiciels pour des raisons differentes, et choisissent une licence pour une raison qui leur est propre.
    
    Il n'y a pas "le logiciel libre" (ou "les linuxiens") contre "le logiciel proprietaire" comme deux equipes de foot qui s'affronteraient. C'est (excuse-moi parce que ca fait trop longtemps que je lis des trucs comme ca) completement con de comparer libre et proprio comme deux equipes qui s'affrontent.
    
    Tu peux trouver des gens qui font du logiciel proprietaire et qui se detestent (Apple et Microsoft), des gens qui font du LL et qui ne s'entendent pas tres bien (Emacs et VIM) voire se detestent car ils ont une facon de penser completement differente (Emacs et XEmacs).
    
    Tu peux aussi trouver des gens qui melangent libre et proprio (nvidia), ou des boites qui font du libres et passent un accord avec un editeur de softs proprios (Mozilla Corp et Google).
- [^]Re: vive le pompage
  
  Posté par Larry Cow () le 04/09/2006 à 11:30. (lien). Évalué à 8.
  J'ai trouvé tout seul cette jolie phrase ! si si !
  
  Tu veux dire que tu as oublié à qui tu l'as empruntée? ;)

**ils pourraient mettre à jour leur #$*%£@ de page !!!!!**

Posté par Nicolas P. (page perso, ) le 08/09/2006 à 22:13. (lien). Évalué à 0.

J'ai commencé à installer tout ça et je commence à comprendre pourquoi mon GWorkspace ne fonctionne pas. Leur #$*%£@ de page de téléchargements ( http://wwwmain.gnustep.org/resources/downloads.php?site=ftp%(...) ) pointe toujours sur la version 0.10.3 de gnustep-gui alors que la version 0.11 vient de sortir et doit être indispensable !

--
this != '|' ;

Revenir en haut de page

Articles précédents : Développeur

Liens connexes

Dépêche modérée par

Dépêche éditée par

Développeur : Nouvelle version de GNUstep : compatibilité avec InterfaceBuilder

youpi c'est mercredi !

[^]Re: youpi c'est mercredi !

Incompétence

[^]Re: Incompétence

[^]Re: Incompétence

[^]Re: Incompétence

[^]Re: Incompétence

[^]Re: Incompétence

[^]Re: Incompétence

[^]Re: Incompétence

[^]Re: Incompétence

[^]Re: Incompétence

[^]Re: Incompétence

[^]Re: Incompétence

À quoi bon ?

[+] [^]Re: À quoi bon ?

[^]Re: À quoi bon ?

[^]Re: À quoi bon ?

[+] [^]Re: À quoi bon ?

[^]Re: À quoi bon ?

[^]Re: À quoi bon ?

RTFD

[^]Re: RTFD

[^]Re: RTFD

[^]Re: RTFD

[^]Re: RTFD

[^]Re: RTFD

[^]Re: RTFD

[^]Re: RTFD

[^]Re: RTFD

[^]Re: RTFD

[^]Re: RTFD

[^]Re: RTFD

http://jesseross.com/clients/gnustep/ui/concepts/

[^]Re: http://jesseross.com/clients/gnustep/ui/concepts/

[^]Re: http://jesseross.com/clients/gnustep/ui/concepts/

[^]Re: http://jesseross.com/clients/gnustep/ui/concepts/

[^]Re: http://jesseross.com/clients/gnustep/ui/concepts/

[^]Re: http://jesseross.com/clients/gnustep/ui/concepts/

Installer GNUStep ?

[^]Re: Installer GNUStep ?

[^]Re: Installer GNUStep ?

[+] [^]Re: Installer GNUStep ?

[+] Plagiat

[^]Re: Plagiat

[^]vive le pompage

[+] [^]Re: vive le pompage

[^]Re: vive le pompage

[^]Re: vive le pompage

[^]Re: vive le pompage

[^]Re: vive le pompage

ils pourraient mettre à jour leur #$*%£@ de page !!!!!

**ils pourraient mettre à jour leur #$*%£@ de page !!!!!**