DiZ a écrit 134 commentaires

http://wallfire.org/(...)

> pas con, faudrait faire un plugin openoffice mail pour ceux la :)

http://groupware.openoffice.org/(...)

ok, merci de ces precisions.

>Elle construit les widgets au fur et à mesure de leur lecture. libglade est aussi
>capable de connecter directement les "evenements" sur les widgets aux
>fonctions callbacks de ton code

Oui mais comment il sait que ton code contient bien ce callback au lancement de l'executable/interface ( pour par exemple grisé l'interface si le callback n'exsite pas) ?

Oui bien sur la gestion des signaux (je crois que c'est le terme employé chez QT)
est fait pour pallier le manque de "dynamisme" de C++.

La différence c'est que pour QT c'est implémenté de assez haut niveau (donc a priori plus lent) alors que c'est inclus dans le langage pour ObjC et que pour l'un ce n'est appliquable que pour l'interface graphique et l'autre c'est builtin.

>libglade te permet de charger, en dynamique, tout ou partie d'un fichier XML et >constuit pour toi l'ensemble des widgets qui y sont décrits (et éventuellement les >affiche). Bref la construction de l'interface par ton programme tient en 3 lignes de >code avec libglade.

Je suis pas sûr de comprendre ?

Comment ils font ca en C (et de facon propre) ?

Parce que pour Renaissance ils utilisent le coté dynamique (et le runtime) de ObjC ....

Cela dit je voit pas l'intérèt "réel" d'avoir une interface décrite en XML .....

>(j'ai déjà un peu étudié la question et il me semble que l'installation du >framework GNUstep pour simplement ajouter un client léger sur un Linux >Desktop soit un peu trop énorme :-(

Tout depends de ce que tu appels énorme ...

Ca vaut un qt + kdelibs je pense pour make Foundation

Si tu cherche quelque chose de très léger tu as qtopia/opie pour qt et pour et MyStep/myPDA pour GNUstep
http://www.dsitri.de/wiki.php?page=Projects(...)

>à quel niveau ?

Ajout de methodes qui existe dans 10.3 et pas dans GNUstep , implementation de NSToolBar (berk :) .....

>De ce que je viens de lire c'est plutôt pour être exécuté sur ces 2 autres architectures.

Oui aussi, ll faut savoir que GNUstep fonctionne bien sur Darwin/X11 (ce qui est pas mal pour faire du cross developpement ..)


Pour moi la compatibilité avec Cocoa est bonne et pour OpenStep (pas NeXtstep) *très* bonne (voir par exemple un *gros* logiciel de DTP/dessin vectoriel comme Cenon (http://www.cenon.info(...)) pour s'en rendre compte)

Maintenant si les developpeurs Cocoa ne font pas attention (ajout de AppleScript/ quicktime/ CoreFoundation/ Carbon) on ne peut pas y faire grand chose ...

Un document expliquant les différences (minimes) entre Cocoa & GNUstep
+ une liste de frameworks libre permettant de ne pas utiliser leur vielle librairies mac serait le bienvenue :)

> Pour la compatibilité Windows, on repassera.

Pas besoin de cygwin, seul MinGW suffit

ftp://ftp.gnustep.org/pub/gnustep/windows/(...) pour le binaire.

>En gros, il aimerait que le serveur X devienne une application OpenGL
>comme une autre. Un driver se résumerait alors à un driver OpenGL. Or, ATI
>et NVIDIA fournissent déjà un tel driver; De plus, ce driver OpenGL est
>indépendant de la structure, des releases, etc du serveur X.

Oui cela a déjà plus ou moins été essayé dans d'autres projets (en tout cas dans un des backend GNUstep).
Le principal problème rencontré par l'auteur était justement les drivers propriétaires OpenGL (dans son cas nVidia) qui semblait relativement buggué. (et indébuggable :)

Pour avoir vu Keith Packard au FOSDEM, il s'accordait a dire que c'était effectivement un problème.
Maintenant il semble prévoir une architecture plus "ouverte" aux développeurs de drivers (au sens technique aussi bien que relationel)

>Ça fait un peu discours de pilier de bistrot

C'est pas fait pour ca Linuxfr ??

>La majorité des applications cocoa sont loin de pouvoir tourner sous >GNUStep du fait que sous OS X toute l'API graphique délègue à QuickTime

N'importe quoi.
Je n'ai pas vu plus de 3 logiciels utilisant Quicktime dans les logiciels libres écrit en Cocoa.

Et de toute façon la compatibilité interessante est au niveau de Foundation et des frameworks externe (AdressBook .......)

Les développeurs GNUstep n'ont aucune intention de toute façon de refaire les horreur (ergonomie/design de certaines API) du canard boiteux qu'est MacOSX.

Bizarre.

Ici tout le monde utilise OOo sans problemes de compatibilité (on test régulièrement) .... surtout pour un simple CV.
Je te conseil cependant pour les documents non modifiables de les sauvegarder/envoyer en pdf.

Le backend ghostscript va être supprimé.
Seul le PDFKit basé xpdf va rester.
Le but c'est d'avoir le rendu xpdf, les fonctrionaités d'acrobat ( bookmark/thumbnails,slideshow....) et l'intergration à la NeXT (services...)

0penGroupware mais le connecteur est propriétaire.

>euh ... dans quel sens?

Que tu peux développer des applis avec sachant qu'il y a quelques bugs dans AppKit et que Gorm fonctionne relativement bien.

>Par contre les applications sont-elles reelement utilisables pour tous les jours >(le client mail par exemple ou autre .
Oui GNUMail et d'autres applications sont utilsables.

Le plus embêtant c'est les problèmes récurents de focus.. notament parce qu'aucun Window Manager ne gère correctement les spécificités GNUstep (les niveaux de fenêtres par exemple)

Cela rend l'utilisation désagréable.

> En parlant de GNUstep, j'aurrais voulu savoir si il etait suffisament utilisable.

Pour un dévelopeur oui.
Pour un utilisateur non.

> L'auteur de la news a oublie de preciser qu'il faut s'enregistrer :/

Et toi tu as oublié de mettre tes lunettes :-)


" Note : Il est nécessaire de s'identifier sur le site d'Alcôve pour télécharger ce livre blanc."

Je ne sais pas si cela est tres légal (surement pas) mais je peux te fournir des CD NEXSTEP 3.3 et NEXSTEP developer + EOF .
Pour OPENSTEP il faut que je fouille dans les cartons....

> des opérations comme le scroll ou le drag'n drop me paraissaient un peu lentes.

Non c'est une feature pour faire venir des développeurs Apple/Cocoa.
Il ne reste plus qu'a peindre en bleu et c'est parfait.

> Ce qui me gêne dans le menu vertical, c'est que j'ai l'habitude d'avoir plein d'applis à
>l'écran et jamais maximisées, donc j'utilise le bureau sur toute sa largeur. Pour passer
>d'une appli à une autre, j'aurais forcément dû placer les menus à différents endroits, et je
>ne trouve pas ça très pratique, contrairement à un menu à la MacOS X qui est toujours
>placé en haut, au même endroit pour toutes les applis.

Oui c'est a l'utilsateur de gérer son bureau/fenêtre/menu.
Il est garanti (c'est dans le Guidline) que ces derniers se trouveront la ou vous l'avez mis pour la dernière fois (ce que de nombreuses applications ne font pas toujours dans d'autres monde...)

Donc ca demande à l'utilisateur de s'organiser....
Mais cela est bénéfique.

Par exemple avec les menus détachables, j'ai toujours le menu "Service" à gauche lorsque j'utilise le FileViewer, alors que c'est le menu Format qui est détaché lorsque j'utilise l'éditeur RTF.
Pour une application ou j'utilise peu le Menu (typiquement les Player Video/Music) le menu peut être hors écran..

Bien sur cela reste une question d'habitude ...

>Tu as regardé le code source ? Y'a des choses réutilisables ??

Il y aura pas mal de bonnes choses a prendre oui !
Notamement lorsque tout sera passé sous GNUstep ...

Un copier/coller des différents fichier OVERSVIEW/README :

SOPE
======
- basic libraries for HTML, HTTP, IMAP4, XML, LDAP, ... processing


et

PDA
===
Contains the daemons and applications required to sync OpenGroupware.org with
Palm devices.


Probablement réutilisable pour des logiciels (desktop) orienté groupware (il y a icalendar aussi)

DocumentAPI
===========
- a wrapper which puts the "Document" abstraction on top of Logic
- this is used mainly by the WebUI and the XmlRpcAPI

et

webUI
=====
The HTML user-interface of OpenGroupware.org.

A noter que tout est ou va etre (lu dans les TODO) implémenté en Bundle (plugins).


Par contre c'est de l'Objective-C donc ... il faut s'y mettre :)

On peut cependant accéder à OpenGroupware via XML-RPC....

GNUstepWeb & Gdl2 sont LGPL http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-libs/gdl2/ http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-libs/gsweb/ il y a d'autres librairies... Par contre je ne sais plus si cela fait partie de projet GNU (comme GNUstep ...)

Un grand merci a Manuel (et orange-concept) ainsi qu'aux autres auteurs de GNUstepWeb et gdl2 (majoritairement soutenus/développés par des entreprises).
Sans leur énorme travail, le libre aurait du attendre bien longtemps avant d'avoir un serveur d'application libre et de qualité.

http://developer.apple.com/techpubs/macosx/Essentials/SystemOvervie(...)