jeudi 10 avril

Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Astuces :: Suivi :: RDF

Articles précédents : Développeur

Liens connexes

Vidéos Flash (3334 hits)
Vidéo "custom" palette (452 hits)
Vidéo palette steptalk (339 hits)
GNUstep Gorm (1146 hits)

Dépêche modérée par

Nyco

Dépêche éditée par

Développeur : Gorm 1.0 est disponible

Posté par Nicolas Roard (page perso, ). Modéré le 30 octobre 2005.

Gregory John Casamento, le mainteneur de Gorm, vient d'annoncer ce samedi la version 1.0.

Qu'est-ce que Gorm ? Il s'agit d'un "constructeur d'interface" permettant facilement de créer des applications graphiques avec GNUstep.

GNUstep est un ensemble de bibliothèques implémentant la spécification OpenStep (ce qui assure une large compatibilité entre GNUstep et Cocoa sous MacOSX), et fonctionnant sous Linux, BSD, Windows.

Des vidéos (en Flash) montrant comment utiliser Gorm sont disponibles.

Vidéos Flash (3334 hits)
Vidéo "custom" palette (452 hits)
Vidéo palette steptalk (339 hits)
GNUstep Gorm (1146 hits)

> Lire la dépêche (56 commentaires, moyenne: 3,1).

Gorm est un "constructeur d'interface" très puissant et facile à utiliser. Il est intéressant pour son approche radicalement différente de la quasi-totalité des constructeurs d'interface existants (à l'exception, évidemment, d'InterfaceBuilder sous Cocoa/Mac OS X) : au lieu de simplement "dessiner" une interface et générer le code correspondant, Gorm permet de positionner et manipuler directement les objets "réels" de l'interface.

Un fichier gorm (contenant une interface graphique) est en fait la sérialisation du graphe d'objets de cette interface. Cette approche évite de générer du code, et permet également de réaliser tout un ensemble d'opérations directement dans Gorm plutôt qu'à la main -- on peut évidemment définir les attributs des composants, mais également les relations entre objets, les messages envoyés par les objets, etc. -- le tout sans perdre aucune possibilité.

On n'est de plus pas limité à des objets graphiques, il est tout à fait possible d'instancier et connecter des objets non-graphiques dans Gorm.

Cette approche permet ainsi de se concentrer sur le code réellement utile ; tout le reste pouvant être effectué dans Gorm.

Un aspect intéressant est la possibilité de se créer ses propres palettes d'objets et d'étendre ainsi facilement les possibilités de Gorm (voir la vidéo "custom palette" en lien, ou la vidéo StepTalk qui intègre un interpréteur SmallTalk directement dans Gorm !).

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.

[+] C'est moche

Posté par wahnby () le 30/10/2005 à 13:44. (lien). Évalué à -5.

C'est mon avis perso tout a fait subjectif mais je pense pas qu'un toolkit tel que celui la puisse avoir du succé tant qu'il reste par defaut aussi moche (je parle bien sur de l'apparence des applications). C'est tres loin de ce qu'on peut faire avec gtk ou les libs de e17

[^]Re: C'est moche

Posté par Nicolas Roard (page perso, ) le 30/10/2005 à 13:51. (lien). Évalué à 9.
Heu.. tu parles du thème "NeXT" tel que visible sur http://gnustep.org/experience/Gorm.html ou du thème utilisé dans les vidéos ?

Sinon GNUstep est thémable hein.. Il ne l'est pas par défaut (ceci dit ça va pas tarder), il faut utiliser Camaelon (dispo sur le cvs d'étoilé), mais ça marche sans problème.
- [^]Re: C'est moche
  
  Posté par MsK` () le 30/10/2005 à 14:31. (lien). Évalué à 3.
  C'est vrai qu'avant c'était très moche, mais maintenant ... bah c'est un peu moins moche en fait ... A l'intérieur des fenêtres ( bouton toussa ) c'est plutot sympa avec camaelon. Mais par contre pour les wm, les bordures de fenêtre, la barre supérieure avec le nom, les menus, etc, pouah, y'a du boulot de ce côté la... :/
  
  ( 200% subjectif )
  
  --
  \_o<~~~~
  - [^]Re: C'est moche
    
    Posté par Nicolas Roard (page perso, ) le 30/10/2005 à 14:37. (lien). Évalué à 7.
    Heu.. ben oui mais bon la barre des fenêtres, les bordures, toussa, c'est gêré par le Windows Manager hein, ici WindowMaker, pas par GNUstep... (bon en fait GNUstep peut aussi gêrer ses fenêtres lui même, mais c'est pas très pratique si tu as d'autres applis non-GNUstep ;-)
    
    Reste les menus oui, mais ils sont thémables également...
    
    'fin bon..
    - [+] [^]Re: C'est moche
      
      Posté par MsK` () le 30/10/2005 à 16:19. (lien). Évalué à -2.
      bah moi ce que je vois c'est que que ce soit window maker, étoilé ou backbone, ca reste le même design ...
      
      --
      \_o<~~~~
      - [^]Re: C'est moche
        
        Posté par Nicolas Roard (page perso, ) le 30/10/2005 à 16:33. (lien). Évalué à 5.
        Ben ouaip hein, c'est tout bêtement car ça reste window maker !
        
        Ce que "contrôle" un toolkit (Gtk, Qt, GNUstep, etc.) sous X11, c'est "l'intérieur" des fenêtres, pas les fenêtres/titres de fenêtres -- ça, c'est du ressort du windows manager, en l'occurrence WindowMaker.
        
        Donc bon, c'est normal que ça reste le "même design" pour les fenêtres, vu que le programme est le même...
    - [^]Et les applets dockables ?
      
      Posté par maximegb (page perso, ) le 31/10/2005 à 12:38. (lien). Évalué à 1.
      Sont-elles thémables, elles aussi ?
      Paske c'est quand même très austère par rapport à un bon thème gkrellm
      - [^]Re: Et les applets dockables ?
        
        Posté par Nicolas Roard (page perso, ) le 31/10/2005 à 13:00. (lien). Évalué à 3.
        Ben heu oui elles sont thémables avec WindowMaker... mais elles ne sont pas des applets GNUstep hein de toute façon.. WindowMaker != GNUstep
- [^]Re: C'est moche
  
  Posté par wahnby () le 31/10/2005 à 09:28. (lien). Évalué à 1.
  Je parle du thème NeXT parce que j'ai pas vue les vidéos parce que j'ai pas flash parce que çapucépalibre. Sinon j'ai regardé un peut les screen de Camaelon et en effet c'est deja plus joli qu'avant.
  - [^]Re: C'est moche
    
    Posté par Nicolas Roard (page perso, ) le 31/10/2005 à 11:59. (lien). Évalué à 3.
    parce que j'ai pas flash parce que çapucépalibre.
    
    Et swfplayer ? chez moi ça marche (linux/ppc) ...
- [^]Re: C'est moche
  
  Posté par SubBass () le 31/10/2005 à 13:59. (lien). Évalué à 3.
  salut Nicolas,
  
  tout d'abord merci pour tes vidéos, elles sont très sympas a regarder même pour quelqu'un comme moi qui n'est pas programmeur, juste curieux... mais de la curiosité à la mise en pratique, il n'y a qu'un pas que Gorm va me faire franchir (je suis en train de l'installer pour l'essayer avec mes grosses mimines)
  
  par ailleurs, quelqu'un connait il un site regroupant des vidéos tutoriales comme celles ci pour d'autres applications ? je trouve le concept interessant pour approcher le néophyte qui peut se retrouver pris au dépourvu devant la richesse d'une interface...
  
  quel outil as tu utilisé pour créer tes vidéos ? libre ?
  
  merci pour vos réponses (et merci pour ton accent français qui me rend l'anglais plus facile ;)
  - [^]Re: C'est moche
    
    Posté par Nicolas Roard (page perso, ) le 31/10/2005 à 23:46. (lien). Évalué à 3.
    Je ne connaît pas de sites regroupant des vidéos tutoriales, mais c'est une bonne idée ! surtout qu'elles sont de plus en plus courantes... (faut dire que c'est _très_ pratique pour pouvoir justement montrer quelque chose..)
    
    Pour l'outil que j'ai utilisé, oui, c'est libre, j'avais écrit un post expliquant ça quand j'avais fait la première vidéo:
    
    http://camaelon.blogspot.com/2005_06_01_camaelon_archive.htm(...)
    
    bon et pour l'accent français ouaip hein n'en rajoutes pas :D je fait ce que je peux ..

[^]Re: C'est moche

Posté par Cyril (page perso, ) le 01/11/2005 à 17:01. (lien). Évalué à 4.
En fait, GNUStep reprant exactement les mêmes couleurs et le design de NextStep.
Seulement, à l'époque de NextStep, les écrans des machines sur lesquelles NextStep tournait avaient une image beaucoup plus claire, ce qui fait qu'a l'époque ou ce thème à été créé, il avais plus une couleur dans le style du theme par défaut de GTK1 sur les écrans de l'époque.
Mais maintenant, c'est plus trop ça.

Glade/libglade

Posté par fredix (Jabber id, page perso, ) le 30/10/2005 à 13:54. (lien). Évalué à 8.

Dans le même genre une vidéo flash vient de sortir pour montrer l'utilisation de Glade et la libglade avec Ruby. Mais le principe reste le même si on utilise le C, C++ ou python.

http://ruby-gnome2.sourceforge.jp/hiki.cgi?RubyZilla

On remarquera l'utilisation extrêmement simple de Gecko :)

--
RubyFrance

[^]Re: Glade/libglade

Posté par Nicolas Roard (page perso, ) le 30/10/2005 à 17:07. (lien). Évalué à 5.
Plutôt intéressant, mais ça illustre justement les différences entre les deux modèles (Gorm/IB et les autres comme Glade). Par exemple, il n'a pas de palette contenant un objet Gecko, il crée une custom view et l'instancier "à la main". Idem, dans le source ruby il y a plein de code d'init qui serait inutile avec Gorm. Et ça impact aussi les relations entre objets; comme Glade ne "connaît" pas l'objet Gecko, tout ce qu'il peut faire c'est envoyer des signaux à l'application quand les boutons sont cliqués; on doit donc créer des méthodes dans l'appli ruby qui appellent les méthodes correspondantes de l'objet Gecko.

Sous Gorm, aucun code ne serait nécessaire.

La démo "équivalente" à celle ci sous OSX, avec InterfaceBuilder et WebKit, consiste effectivement à dnd les boutons sur une fenêtre, puis dnd l'objet WebKit, puis de linker les actions des boutons à des méthodes de l'objet WebKit. Le tout sans une ligne de code, dans InterfaceBuilder. Et on peut tester le programme sans avoir à le compiler. Une fois WebKit compilé pour GNUstep (ce qui devrait être faisable avec la prochaine release de gcc apportant *enfin!* objc++), aucun problème pour faire la même chose sous Gorm -- c'est exactement le même principe qu'avec la vidéo "custom palette" en lien de l'article.
- [^]Re: Glade/libglade
  
  Posté par Nicolas Roard (page perso, ) le 30/10/2005 à 17:59. (lien). Évalué à 5.
  En fait si j'essaie de synthétiser... tout l'intérêt de Gorm/IB est que:
  
  - gêrer les relations/attributs dans Gorm/IB permet d'éviter beaucoup de code "de liaison", ce qui permet de se concentrer sur le code "utile"
  
  - ce mécanisme n'est en aucune façon limité à des objets prédéfini, mais marche avec n'importe quel objet (graphique ou non-graphique),
  du moment qu'on l'a défini dans Gorm (à la main avec l'éditeur de classes ou en chargeant un .h)
  
  - les palettes fournissent des objets prêts à l'emploi et il est facile de créer ses propres palettes
  - [^]Re: Glade/libglade
    
    Posté par fredix (Jabber id, page perso, ) le 30/10/2005 à 20:04. (lien). Évalué à 4.
    Oui ca serait pas mal que Glade arrive un jour au niveau de Gorm.
    
    --
    RubyFrance
    - [^]Re: Glade/libglade
      
      Posté par gallenza () le 31/10/2005 à 03:54. (lien). Évalué à 4.
      AMHA Glade n'a pas pour but d'avoir les fonctionnalités de Gorm car il a été conçu dans un esprit totalement différent.
      Et ceci est directement lié à leur langage cible principal (et d'implémentation), c'est-à-dire C pour l'un et Objective C pour l'autre.
    - [^]Re: Glade/libglade
      
      Posté par Erwan (page perso, ) le 31/10/2005 à 07:52. (lien). Évalué à 6.
      Ce que j'ai trouve sympa en particulier dans la video, c'est que quand on s'approche du bord une ligne rouge apparait pour laisser un espace.
      
      Bref, si Glade avait des trucs similaires rendait plus facile l'implementation d'applications "HIG-compliant", meme les applications amateur auraient un look bien plus sympa.

à l'exception, évidemment...

Posté par Clément varaldi (page perso, ) le 30/10/2005 à 16:39. (lien). Évalué à 1.

(à l'exception, évidemment, d'InterfaceBuilder sous Cocoa/Mac OS X)

C'est pas tout à fait la formulation que j'aurais utilisé... Je dirais plutôt que Gorm est un *clone* de interfacebuilder (en plus moche).

Mis à part le fait que ça utilise openstep (d'où quelques classes qui rappellent cocoa), je dirai que niveau interface, c'est *exactement* interface builder. Les mêmes fenêtres. Les mêmes actions.

Il n'y a donc rien d'innovant, pour moi c'est de la copie. Par contre, le truc bien, c'est qu'à la différence de interface builder, c'est libre :)

[^]Re: à l'exception, évidemment...

Posté par CrEv (page perso, ) le 30/10/2005 à 16:56. (lien). Évalué à 2.
oui mais interface builder ne s'appurait-il pas simplement sur un équivalent provent d'openstep ?
En clair, gorm "copie" interface builder ou gorm _et_ interface builder s'inspirent d'un équivalent provenant d'open step ?
- [^]Re: à l'exception, évidemment...
  
  Posté par Nicolas Roard (page perso, ) le 30/10/2005 à 17:01. (lien). Évalué à 3.
  InterfaceBuilder sous OSX est le descendant direct d'InterfaceBuilder sous NeXT/OpenStep. Je ne suis même pas sûr qu'ils aient modifié grand chose dans leur code source lors du passage OPENSTEP->Cocoa.

[^]Re: à l'exception, évidemment...

Posté par Nicolas Roard (page perso, ) le 30/10/2005 à 16:59. (lien). Évalué à 3.
En même temps, vu qu'IB est ce qu'on fait de mieux, c'est pas un désavantage de l'avoir copié ;-)

Sinon oui, Gorm est un clone au niveau UI de IB. Il a ceci dit des trucs en plus que IB n'a pas, comme un export/import facile des chaînes de caractères contenu dans un fichier gorm (== pour la traduc).

Donc oui, Gorm n'est pas particulièrement innovant par rapport à IB; mais il l'est par rapport aux restes des constructeurs d'interface :-)
Et puis surtout, il est libre. Et à mon avis c'est là son principal intérêt, car du coup on peut vraiment imaginer tout un tas de "custom palettes" contenant des objets, pour batir facilement un programme (je rappelle que les objets ne sont pas nécessairement des widgets!).

Alors qu'IB se cantonne à un créateur d'UI finalement, sans aller au dela (vers un "assembleur de composants logiciels"); c'est plus dû à des raisons sociologiques (pas hyper intéressant pour des boites de proposer des palettes IB, et manque de documentation) que technologiques, mais ce qui ne marche pas tant que ça dans un modèle commercial (ventes/mise à dispo de composants) a bien plus de chance de marcher dans un modèle libre (ou on a justement _intérêt_ à partager les composants logiciels).

[^]Re: à l'exception, évidemment...

Posté par farvardin (page perso, ) le 31/10/2005 à 08:20. (lien). Évalué à 10.
c'est vraiment pénible de devoir lire à chaque fois que vous faites un commentaire sur GNUstep "moui déjà c'est moyen comme truc, pompé sur mac osx, mais bon surtout keske c'est moche, c'est gris".

C'est énervant surtout que personnellement je trouve cela très épuré et élégant, mais ça c'est question de goût, et surtout C'EST COMPLETEMENT THEMABLE avec Cameleon, comme il a été dit plus haut.
Mais non, et cela continue, "c'est gris, c'est moche, c'est pas eye-candy comme crystal / keramik / windows xp et gnagnagna et gnagnagna"

Dans pas longtemps GNUstep arrivera à cela :
http://jesseross.com/clients/gnustep/ui/concepts/

apparemment il y avait un thème gtk qui utilisait cela, mais le site n'est plus disponible ( cf http://article.gmane.org/gmane.comp.lib.gnustep.ui/574 )

--
"Every line of code that is written to our standards is a small victory ; every line of code that is written to any other standard is a small defeat. "
Evangelism is War
- [^]Re: à l'exception, évidemment...
  
  Posté par eJah () le 31/10/2005 à 10:31. (lien). Évalué à 7.
  C'est bien joli !
  Il y a fort à parier que lorsqu'une release sortira proposant les themes (parceque si j'ai bien compris pour le moment il faut uiliser la version CVS pour en bénéficier) et si c'est ce thème qui sera installé par défaut, ça va attirer pas mal de monde et de développeur.
  
  Eh oui, malgré tout, le "look" joue beaucoup dans l'adoption d'un bureau/wm/graphic toolkit, et ce, aussi bons soient-ils...
  - [^]Re: à l'exception, évidemment...
    
    Posté par Nicolas Roard (page perso, ) le 31/10/2005 à 11:30. (lien). Évalué à 1.
    En fait non, on a pas besoin de la version CVS de GNUstep pour avoir les thèmes, on a juste besoin de Camaelon, et c'est tout, pas besoin de patch. Mais la dernière version de Camaelon est en effet sur le cvs d'étoilé (http://www.etoile-project.org)... donc bon.. ceci dit on peut récupérer les tgz des builds journalières...
    
    Maintenant, ce que fait Camaelon est deux choses:
    - modifier les widgets pour que leur "dessin" soit géré par une seule classe donnée
    - une implémentation de cette classe qui utilise des images pour dessiner les widgets (thèmes pixmaps)
    
    Grâce à Objective-C on a en effet pas besoin que cette modif des widgets soit intégrée à GNUstep, vu qu'on peut remplacer du code à la volée. Cependant, ce serait mieux que ce code soit quand même intégré à GNUstep lui même (histoire de pas avoir à reporter les modifs de GNUstep dans Camaelon par exemple), et ça c'est en cours en ce moment. Même si ça ne changera pas grand chose pour l'utilisateur final :-)
- [^]Re: à l'exception, évidemment...
  
  Posté par Nicolas Roard (page perso, ) le 31/10/2005 à 11:23. (lien). Évalué à 1.
  Dans pas longtemps GNUstep arrivera à cela :
  http://jesseross.com/clients/gnustep/ui/concepts/
  
  Oui enfin c'est déja possible avec Camaelon, cf:
  http://www.roard.com/screenshots/screenshot_ukuug2005.png
  (reste 2-3 bricoles peut être à corriger, et par rapport aux dernières "versions" de Nesedah celle ci est trop lumineuse, mais bon..)
  
  C'est le thème Nesedah de Jesse Ross (http://www.roard.com/gnustep/Nesedah.theme.tgz)
  - [^]Re: à l'exception, évidemment...
    
    Posté par Aurélien Girard () le 31/10/2005 à 13:40. (lien). Évalué à 2.
    Est-ce que Camaelon marche sous MacOSX ?
    - [^]Re: à l'exception, évidemment...
      
      Posté par farvardin (page perso, ) le 31/10/2005 à 13:45. (lien). Évalué à 2.
      non, c'est uniquement pour gnustep. Après, peut-être est-il possible de porter gnustep sous osx, mais c'est encore une autre affaire, et peut être pas la philosophie de la chose.
      C'est vrai que cela manque de pouvoir modifier le thème d'osx (à part avec de shareware pas très stable parait il)
      
      --
      "Every line of code that is written to our standards is a small victory ; every line of code that is written to any other standard is a small defeat. "
      Evangelism is War
      - [^]Re: à l'exception, évidemment...
        
        Posté par Gohar () le 01/11/2005 à 10:15. (lien). Évalué à 2.
        Moi je trouve que ça manque pas.
        
        Au contraire, à mon sens, les thèmes sont anti-ergonomiques au possible. Au moins, sous Mac OS X, tu as toujours exactement le même environnement d'un poste à l'autre.
        
        Et le paradigme du bureau étant le monde réel, on ne change pas le papier peint de son bureau tous les jours.
        
        Enfin, Apple est certainement l'éditeur qui a le plus pensé à l'ergonomie et s'il n'y a pas de thèmes sous Mac OS X, il doit certainement y avoir une très bonne raison.
        
        Pour le libre, je verrais bien KDE thémable à mort et Gnome, pas du tout...
        
        [^]Re: à l'exception, évidemment...
        
        Posté par agmk () le 01/11/2005 à 11:48. (lien). Évalué à 1.
        > Pour le libre, je verrais bien KDE thémable à mort et Gnome, pas du tout...
        
        C'est pas déjà un peu le cas ? (je sens que je vais me faire moinsser)
        
        --
        Wr ar fbhunvgr cnf ha qrfgva sharfgr à yn cncnhgé. Nzra.
        
        [^]Re: à l'exception, évidemment...
        
        Posté par Mildred (Jabber id, page perso, ) le 01/11/2005 à 13:56. (lien). Évalué à 1.
        J'utilise Gnome ...
        Je peux choisir un thème
        Je pourrais même en écrire un si je savais faire
        
        Gnome se personnalise très bien au niveau des thèmes. Je ne vois pas ce que tu lui reproche.
        
        --
        La Roue du Temps
        
        [^]Re: à l'exception, évidemment...
        
        Posté par farvardin (page perso, ) le 01/11/2005 à 15:05. (lien). Évalué à 4.
        je pense qu'il voulait dire que KDE est très thémable car il trouve le thème de base est moche (contrairement à OSX), alors que Gnome n'aurait pas besoin d'être thèmable car le thème de base est bien fait.
        C'est à discuter, mais concernant osx pouvoir changer le thème serait vraiment un plus, le thème de base même s'il n'est pas mal est vite lassant (d'ailleurs je m'en suis tellement lassé que maintenant je suis 100% sous linux...)
        
        --
        "Every line of code that is written to our standards is a small victory ; every line of code that is written to any other standard is a small defeat. "
        Evangelism is War
        
        [^]Re: à l'exception, évidemment...
        
        Posté par Christophe Bliard (page perso, ) le 02/11/2005 à 00:42. (lien). Évalué à 3.
        :-)
        
        - Pourquoi utilises-tu Linux ?
        - Parce que le thème de Mac OS X est lassant.
        
        [^]Re: à l'exception, évidemment...
        
        Posté par Aurélien Girard () le 02/11/2005 à 18:31. (lien). Évalué à 5.
        "Au moins, sous Mac OS X, tu as toujours exactement le même environnement d'un poste à l'autre."
        
        Sauf que d'une application à l'autre tu as des thèmes complètement différents (Merci Apple qui pense à l'ergonomie ...)
        
        [^]Re: à l'exception, évidemment...
        
        Posté par Gohar () le 02/11/2005 à 21:40. (lien). Évalué à 2.
        C'est là où la logique d'Apple trouve ses limites: ce n'est pas et ce ne peut pas être une distribution. Que le monde du libre profite de son avantage!
- [^]Re: à l'exception, évidemment...
  
  Posté par Clément varaldi (page perso, ) le 31/10/2005 à 12:39. (lien). Évalué à 2.
  c'est vraiment pénible de devoir lire à chaque fois que vous faites un commentaire sur GNUstep "moui déjà c'est moyen comme truc, pompé sur mac osx, mais bon surtout keske c'est moche, c'est gris".
  
  Tout d'abord :
  
  Comme dit dans un commentaire entre les deux notres, si les screenshots et les vidéos utilisaient les-dits thèmes, peut-être que les gens regarderaient d'un autre oeil. Seulement voilà, parmi tous les screenshots qui nous sont donnés de voir, bien rares sont ceux qui utilisent un thème un peu moins austère.
  
  Alors oui, ça peut être "plus joli", mais on ne nous le montre jamais. Alors tu veux qu'on dise quoi ? Que c'est magnifique ?
  
  Ensuite :
  
  Tu t'es attardé sur une toute petite partie de mon commentaire, une parenthèse en plus, qui n'était là que pour donner un peu de subjectif. Dommage que ce soit la seule lecture que tu ais faite de mon commentaire. Il faut croire qu'on écrit parfois dans le vide.
  
  Je rappelle donc : Gorn, c'est Interface Builder (et sur la vidéo, c'est plus moche, j'y peux rien, libre à toi de proposer la même vidéo avec un joli thème), mais en libre.
  
  Pour le commentaire portant sur le python dans Gorn, je sais pas ce qu'il en est. PyObjC est relativement bien fait si on utilise Mac OS X, et permet de faire de bien bonnes choses, même si... La documentation est inexistante. pydoc n'est pas complet, loin de là. Moi quand je cherche de la documentation pour pyobjC, je vais voir... La doc de l'objective-C et j'adapte en espérant que ça marche à l'arrivée (ce qui n'est pas toujours le cas, mais souvent quand même).
  
  Maintenant, arrêtez de nous critiquer quand on dit que c'est moche, et filez faire des screenshots dignes de ce nom ! Si e17 a du succès, c'est pas pour rien. J'adorerais que gnustep ait le succès qu'il mérite. Simplement, il n'attire pas.
  
  PS : vous pouvez même inutiliser mon commentaire, il est là pour ça :)
  - [^]Re: à l'exception, évidemment...
    
    Posté par Nicolas Roard (page perso, ) le 31/10/2005 à 13:11. (lien). Évalué à 3.
    si les screenshots et les vidéos utilisaient les-dits thèmes, peut-être que les gens regarderaient d'un autre oeil.
    
    Ben heu.. les vidéos utilisent le thème Nesedah hein, pas le thème NeXT. Par contre sur gnustep.org en effet les sshots n'utilisent que le thème NeXT. Maintenant bon à priori tu n'aimes pas non plus Nesedah, que veut tu que je te dise :D -- Nesedah c'est un thème fait de façon à rester "clean" tout en étant plus "moderne", et apparemment qui plait à beaucoup -- mais évidemment on ne peut plaire à tout le monde..
    
    Apparemment ça reste trop austère pour tes gouts.. j'imagine qu'il faudra des thèmes plus fisher price en effet, même si c'est pas du tout ce qui m'intéresse moi.. :-)
    -- reste à trouver des gens pour les faire, ces thèmes..
    
    Sinon, oui, Gorm, c'est en gros IB en libre, même si il y a des différences. Et c'est tout ce que ça te fait ? :)
    
    J'adorerais que gnustep ait le succès qu'il mérite. Simplement, il n'attire pas.
    
    C'est clair que les sshots rebuttent beaucoup de monde.. :-/ même si certains (rares) aiment le thème NeXT, c'est évident que beaucoup se contentent de juger de la qualité de GNUstep en se basant uniquement sur les sshots. C'est dommage, mais assez compréhensible. Ca fait raler vu qu'on dispose pourtant d'un moteur de thème, mais lui aussi sous-utilisé. Enfin bon, les choses progressent (doucement..), on verra bien..
    - [^]Re: à l'exception, évidemment...
      
      Posté par Yusei (page perso, ) le 01/11/2005 à 09:02. (lien). Évalué à 5.
      
      même si certains (rares) aiment le thème NeXT
      
      Ça n'intéressera personne, mais je tiens à le dire: à une époque j'ai même tenté d'utiliser un thème NeXT pour GTK, parce que je trouvais que ça allait bien avec mon wmaker... mais le thème était buggué alors j'ai renoncé.
      - [^]Re: à l'exception, évidemment...
        
        Posté par gallenza () le 01/11/2005 à 13:31. (lien). Évalué à 3.
        Le thème GTKStep marchait très bien avec GTK1 et puis n'a pas été mis à jour au passage à GTK2...depuis j'ai arrêté de NeXTifié toutes mes widgets (TkStep jamais mis à jour non plus), et je me suis même mis à douté du fait que GNUStep allait conquérir le monde :-(
  - [^]Re: à l'exception, évidemment...
    
    Posté par farvardin (page perso, ) le 31/10/2005 à 13:25. (lien). Évalué à 4.
    non, en fait tu étais le deuxième ou le 3ème à faire ce genre de commentaire, ne le prend pas spécialement pour toi :)
    
    Je pense que les développeurs de GNUstep devraient pas mal communiquer à partir du thème Nesedah, un peu comme Apple le fait pour Aqua, et même si on a la liberté d'utiliser autre chose (thème classique ou complètement différent), cela donnerait une unité à Gnustep, unité qu'il a déjà avec sa charte graphique actuelle, mais décriée par beaucoup, ce que je peux comprendre, même si je ne partage pas leurs critiques (j'aime tellement cela que j'ai installé un thème gnustep classique pour toutes mes applications gtk et gtk2 :) )
    
    --
    "Every line of code that is written to our standards is a small victory ; every line of code that is written to any other standard is a small defeat. "
    Evangelism is War

avec python ?

Posté par farvardin (page perso, ) le 31/10/2005 à 08:29. (lien). Évalué à 1.

j'ai toujours du mal à me faire à la programmation en objective C (idem pour le C ou le C++) par contre j'ai plus de facilités avec python. J'ai déjà réussi à faire un petit programme et une interface avec glade, pygtk et tepache, en suivant par exemple la procédure ici :
http://primates.ximian.com/~sandino/python-glade/

C'est vraiment très facile. Mais j'aimerai bien pouvoir faire la même chose avec gnustep et gorm, est-ce qu'il existe qque chose de similaire ?

question subsidiaire, est-ce que le problème avec gnustep et les dernières versions de freetype 2 est résolu ?

--
"Every line of code that is written to our standards is a small victory ; every line of code that is written to any other standard is a small defeat. "
Evangelism is War

[^]Re: avec python ?

Posté par oops (page perso, ) le 31/10/2005 à 11:04. (lien). Évalué à 2.
>C'est vraiment très facile. Mais j'aimerai bien pouvoir faire la même
>chose avec gnustep et gorm, est-ce qu'il existe qque chose de
>similaire ?

Pas encore....
Il y a bien PyObjC http://pyobjc.sourceforge.net/ mais il est dit :
"There is limited support for GNUstep, most of the unittests pass on GNUstep on Linux/ix86. However, we do still have some serious problems with real scripts."

De même pour Perl : http://camelbones.sourceforge.net/
"The latest CVS version of CamelBones builds successfully on my Debian GNU/Linux PC, under GNUstep. It's an early effort, and not all of the self-tests pass, but many of them do. The Building from source page has more about building under GNUstep"

C'est sur la bonne voie donc .....

Par contre on peut faire des choses avec Ruby / Java ou guile ( en plus du C et ObjC et bientôt C++ bien sur ).

Mais comme toi j'aimerais bien un support python et Perl.
- [^]Re: avec python ?
  
  Posté par farvardin (page perso, ) le 31/10/2005 à 13:39. (lien). Évalué à 2.
  ce que j'ai bien aimé avec tepache, et ce qui m'a vraiment permis de débuter à programmer avec, c'est qu'il permet de générer automatiquement à partir d'une interface glade un code python fonctionnel, où toute action de l'interface graphique est remplacée par des messages standard. Par exemple : "clic sur bouton1 qui produit message2", "on_copier1_activate called with self.copier1
  " etc.
  Cela fait un squelette particulièrement facile à modifier pour remplacer par de vraies fonctions en python.
  S'il y avait cela avec Gorm et Gnustep, cela deviendrait beaucoup plus facile pour les novices de construire des applications (python était plus accessible que objc)
  
  --
  "Every line of code that is written to our standards is a small victory ; every line of code that is written to any other standard is a small defeat. "
  Evangelism is War

Une killer application ?

Posté par Erwan (page perso, ) le 31/10/2005 à 13:40. (lien). Évalué à 4.

Il faut faire comme les gars de Mono : pour faire de la pub, il faut developper des applications utiles, qui n'ont pas encore d'equivalent. Si GNUStep est si formidable et accelere le developpement, ca ne devrait pas etre tres dur ;).

Toujours sur l'exemple de Mono, c'est avec des applications comme Muine, F-Spot, TomBoy ou Beagle que Novell fait sa pub. Et dans le lot il y a au moins F-Spot et Beagle qui sont developpes par Novell.

Alors, a quand l'application que tout le monde veut, developpee avec GNUstep ?

[^]Re: Une killer application ?

Posté par farvardin (page perso, ) le 31/10/2005 à 13:54. (lien). Évalué à 2.
il y a déjà stepbill :

http://www.linuks.mine.nu/stepbill/

(oui, je sais, c'est porté à partir de xbill)

sinon il y a quand même quelques applications bien sympa :
http://www.linuks.mine.nu/gnustep/

--
"Every line of code that is written to our standards is a small victory ; every line of code that is written to any other standard is a small defeat. "
Evangelism is War

[^]Re: Une killer application ?

Posté par Matthieu C () le 31/10/2005 à 23:59. (lien). Évalué à 3.
Paje(un logiciel de visualition de trace avancé) ne doit pas avoir d'equivalent...

[^]Re: Une killer application ?

Posté par oops (page perso, ) le 01/11/2005 à 10:46. (lien). Évalué à 0.
>Il faut faire comme les gars de Mono : pour faire de la pub, il faut

Comme les gars de Novell tu veux dire ?

>developper des applications utiles, qui n'ont pas encore d'equivalent.

Gorm / Paje / TAMS ....
Non il manque Novell et Miguel de Icaza je pense plutôt....

Quoique ... :)

L'autre problème c'est que les développeurs GNUstep aime le Look NeXT ( et ils ont raisons ) et les thèmes ont tendance à faire perdre en ergonomie par rapport à l'orginal.

Et comme le singe préfère la voiture rouge ......
- [^]Re: Une killer application ?
  
  Posté par Erwan (page perso, ) le 02/11/2005 à 04:01. (lien). Évalué à 8.
  Gorm / Paje / TAMS
  
  C'est soi des applications de developpement (donc il faut deja avoir envie de se mettre au developpement GNUstep), soi des trucs hyper-specialises. En tout cas rien qui s'adresse au geek moyen.
  
  Non il manque Novell et Miguel de Icaza je pense plutôt....
  
  Non, Miguel de Icaza il a beau dire "Mono est genial", tant qu'il n'y avait pas d'applications Mono il avait tendance a se faire foutre de lui. En plus, gnustep beneficie du capital de sympathie MacOSX chez les geeks alors que Mono n'a que le capital de haine de MS. Mais Nat et d'autres de chez Novell ont montre ce qu'on pouvait faire avec, et ca s'est enclanche : des developpeurs exterieurs a Novell se sont mis a utiliser Mono et une communaute assez large s'est cree.
  
  Le probleme des themes c'est un faux probleme. Tu as deja entendu quelqu'un dire "j'aimerai bien utiliser cette appli, mais gnustep est trop moche" ? Les gens qui critiquent le theme le font juste sur la base de screenshot.
  
  Bon, vous faites comme vous voulez, mais a mon avis c'est ce qui manque a gnustep. Il suffit d'identifier un domaine ou une appli manque, ou alors on peut mieux faire (il y en a a la pelle) et vous codez une appli que tout le monde veux. Les geek vont se mettre a utiliser gnustep, a l'avoir installe chez eux et a s'habituer au look&feel next. Et dans le lot quelques uns vont vouloir essayer les outils qui vous ont fait produire cette merveille.
  
  Il ne faut pas oublier qu'un framework c'est fait pour developper des applications "utilisateurs", si c'est pour developper des outils de developpement le serpent se mord la queue et ca ne sert a rien.
  - [^]Re: Une killer application ?
    
    Posté par Nicolas Roard (page perso, ) le 02/11/2005 à 11:09. (lien). Évalué à 2.
    Franchement, je suis entièrement d'accord avec toi.. mais bon, le problème c'est qu'il y a peu de devs sur GNUstep, et que donc le dev de GNUstep lui même passe avant le dev d'applis... et les devs qui codent des applis tendent à écrire les applis de base nécessaire pour un bureau (GNUMail, GWorkspace, Zipper, AddressBook, Vindaloo, etc) ou des applis de dev (Gorm, ProjectCenter, DataModeller, etc). Maintenant, c'est sûr que plus il y aura de personnes intéressées, plus il y aura d'applis -- d'autant que les outils de devs sont là pour aider :)
    
    Mais pour le moment ça se mort un peu la queue, oui :-/ -- ceci dit ça ne peut que nécessairement s'améliorer, et ça s'améliore, mais lentement...
    
    Enfin si tu as des idées d'applis géniales à implémenter, n'hésites pas à te lancer hein :-P nous on dit pas non !

approche radicalement différente

Posté par Vincent Pelletier () le 02/11/2005 à 11:23. (lien). Évalué à 2.

Je voudrais citer un EDI ayant une approche de ce style (qui tient en un inspecteur d'objet plus complet que la moyenne, pour ce que j'en ai vu) pour ce qui est du dessin des interfaces graphiques :
Borland [Delphi|C++ Builder|Kylix]

Sorti du saimal saipalibreu, je ne vois (-yais) rien à reprocher à cet EDI. Je l'ai utilisé dans mes années pré-linux, et j'ai vraiment adoré. J'ai ensuite trouvé très domage que Kylix ait eu un écho aussi ténu, y compris la version gratuite autorisant la distribution GPL (à vérifier, je n'y ai pas remis les mirettes depuis un moment) des applications resultantes accompagnées les librairies Borland.

[^]Re: approche radicalement différente

Posté par Frédéric Lopez () le 02/11/2005 à 18:14. (lien). Évalué à 2.
http://www.lazarus.freepascal.org/

Theme Engine à base de QT/GTK

Posté par Bonnefille Guilhem (page perso, ) le 02/11/2005 à 22:56. (lien). Évalué à 2.

Je crois que j'avais déjà posé la question, mais puisque "tout le monde" (enfin, les gens d'ici) trouve que le thème NeXt est moche, et que KDE/GNOME c'est beau, ne serait-il pas possible (au moins théoriquement) d'utiliser QT ou GTK pour dessiner les widgets ?

Il me semble qu'il est (ou sera) bientôt possible de dessiner du GTK en s'appuyant sur Qt (ou l'inverse).

Je crois que le découpage en couches est bien fait sous GNUStep, donc (toujours théoriquement) ça ne devrait pas être impossible d'intercepter l'ordre de dessin d'un bouton pour le soumettre à GTK.

Ou alors faut faire des bindings GNUStep/GTK comme on commence à voir du Java/GTK/GNOME.

[^]Re: Theme Engine à base de QT/GTK

Posté par Nicolas Roard (page perso, ) le 03/11/2005 à 14:34. (lien). Évalué à 6.
ne serait-il pas possible (au moins théoriquement) d'utiliser QT ou GTK pour dessiner les widgets ?

Théoriquement, oui. Mais vu qu'on a déja un moteur de thème (camaelon), ben heu pour le moment je préfère me concentrer dessus hein :-)

Là pour le moment camaelon contient en fait deux parties:

- des categories sur les classes widgets, modifiant le code de façon à ce que toute la partie "dessin" soit effectué par une seule classe, GSDrawFunctions
- un moteur de thème pixmaps utilisant ce mécanisme pour fournir une implémentation de GSDrawFunctions qui utilise des pixmaps pour le dessin des widgets

Ca marche bien, et pas besoin de patcher quoique ce soit (merci objc). Maintenant, ce serait quand même intéressant de basculer la première partie (les modifs des widgets) directement dans le cvs gnustep, histoire que ce soit par défaut et de pas avoir d'éventuels problèmes de synchro entre les deux codes. C'est justement ce que je suis en train de faire en ce moment, et ça devrait être commité rapidement.

Une fois ce refactoring directement intégré dans le cvs, Camaelon ne sera plus qu'une implémentation donnée de GSDrawFunctions; l'implémentation par défaut de GSDrawFunctions étant tout simplement le code actuel du "thème" NeXT.

Bref pour simplifier, ça changera pas grand chose pour Camaelon, ni pour les utilisateurs de Camaelon / les gens qui veulent un thème. Mais par contre ça devrait aider/faciliter si quelqu'un veut faire une implémentation d'un thème autre qu'avec Camaelon. Exemple:

- un "thème" Windows qui utilise l'api de thème de win32, pour GNUstep/Windows, parce que bon ce serait mieux dans l'idéal qu'un thème pixmap fait avec Camaelon
- un thème qui utiliserait le moteur de thème de Gtk ou Qt
- autres thèmes "programmés" (comme le thème actuel NeXT), c'est à dire sans utiliser de pixmaps

voila voila..
- [^]Re: Theme Engine à base de QT/GTK
  
  Posté par Bonnefille Guilhem (page perso, ) le 04/11/2005 à 18:01. (lien). Évalué à 2.
  Merci pour cette réponse fort détaillée.
  
  Une petite question supplémentaire toutefois : à ton avis, quel serait le volume de boulot pour implémenter un GSDrawFunctions/Gtk ? Plus précisément, de quel ordre sont les "commandes" à réinterpréter ? Est-ce que les trucs à implémenter sont du genre "Tracer un bouton à telle position", ou "Tracer une liste..." ?
  
  En gros, en implémentant GSDrawFunctions on gère des notions de niveau toolkit graphique ou plutôt de niveau X11 ?
  
  Enfin, en même temps je sais pas comment ça fonctionne Gtk, ni à quel niveau de gtk il faut attaquer pour réutiliser le moteur de thème.
  - [^]Re: Theme Engine à base de QT/GTK
    
    Posté par Nicolas Roard (page perso, ) le 05/11/2005 à 11:59. (lien). Évalué à 3.
    Les trucs à implémenter sont pour la plupart du genre "dessine un bouton", "dessine le cadre d'une NSBox", etc. En gros tu reçoit une zone rectangulaire et la vue qui s'y rapporte, et à toi de dessiner dedans. Donc rien de bien difficile, et j'imagine que ça doit pas être trop compliqué de créer un thème utilisant Gtk (au pire en créant une image via Gtk et en composant cette image), mais bon en même temps je connais pas bien Gtk, donc faut voir.

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 : Gorm 1.0 est disponible

[+] C'est moche

[^]Re: C'est moche

[^]Re: C'est moche

[^]Re: C'est moche

[+] [^]Re: C'est moche

[^]Re: C'est moche

[^]Et les applets dockables ?

[^]Re: Et les applets dockables ?

[^]Re: C'est moche

[^]Re: C'est moche

[^]Re: C'est moche

[^]Re: C'est moche

[^]Re: C'est moche

Glade/libglade

[^]Re: Glade/libglade

[^]Re: Glade/libglade

[^]Re: Glade/libglade

[^]Re: Glade/libglade

[^]Re: Glade/libglade

à l'exception, évidemment...

[^]Re: à l'exception, évidemment...

[^]Re: à l'exception, évidemment...

[^]Re: à l'exception, évidemment...

[^]Re: à l'exception, évidemment...

[^]Re: à l'exception, évidemment...

[^]Re: à l'exception, évidemment...

[^]Re: à l'exception, évidemment...

[^]Re: à l'exception, évidemment...

[^]Re: à l'exception, évidemment...

[^]Re: à l'exception, évidemment...

[^]Re: à l'exception, évidemment...

[^]Re: à l'exception, évidemment...

[^]Re: à l'exception, évidemment...

[^]Re: à l'exception, évidemment...

[^]Re: à l'exception, évidemment...

[^]Re: à l'exception, évidemment...

[^]Re: à l'exception, évidemment...

[^]Re: à l'exception, évidemment...

[^]Re: à l'exception, évidemment...

[^]Re: à l'exception, évidemment...

[^]Re: à l'exception, évidemment...

avec python ?

[^]Re: avec python ?

[^]Re: avec python ?

Une killer application ?

[^]Re: Une killer application ?

[^]Re: Une killer application ?

[^]Re: Une killer application ?

[^]Re: Une killer application ?

[^]Re: Une killer application ?

approche radicalement différente

[^]Re: approche radicalement différente

Theme Engine à base de QT/GTK

[^]Re: Theme Engine à base de QT/GTK

[^]Re: Theme Engine à base de QT/GTK

[^]Re: Theme Engine à base de QT/GTK