Nicolas Roard a écrit 1135 commentaires

Qu'est-ce que tu entends par "supporter les attributs" ??

Concernant les signaux, il y a, évidemment, Objective-C.

C'est un langage objet inspiré de SmallTalk, étendant le C Ansi, et c'est utilisé chez GNUstep et chez Apple (Cocoa). Tout passe par des envois de messages -- ce que tu appelle "signaux". Accessoirement ce modèle permet très simplement d'avoir des communications entre objets, ou que soient les objets (dans des processus séparés, sur différentes machines...) -- bye bye corba. Et ça en 3 lignes de codes à l'initialisation (une fois l'objet initialisé, on s'en tape qu'il soit ailleurs, il se manipule exactement comme un objet local).

D'ailleurs, c'est entre autre grâce aux capacité d'Objective-C (dynamisme, messages, catégories...) que la programmation d'applis graphiques est si agréable avec OpenStep.

Alors bon, MDI aurait mieux fait de venir aider GNUstep à l'époque que de se lancer dans de la programmation objet... en C (vraiment, je trouve ça inexplicable).

http://www.roard.com/docs/(...)

D'ailleurs stephan a envoyé ce mail aujourd'hui, à propos justement de la sortie de xpdf 3.0 :

I just wanted to announce some great news that are related to the
newest release of xpdf (3.0). First, this release supports PDF 1.5
and thus PDFKit & ViewPDF will do also. The second and greatest
improvement is that xpdf now sports a new architecture that allows
the rendering of PDF content to a bitmap independent from a device
(like X11). I will base the PDFImageRep in PDFKit on this new architecture
so that no effort is needed to render the content. The biggest advantage
is that PDFKit will take advantage of the render engine in xpdf which
is actually very good (IMHO). Second, all improvements that are made
to xpdf's PDF support could be taken over to PDFKit without too much
hassle. Last, but not least, NO MORE GHOSTSCRIPT, this is a huge
improvement since it greatly simplifies the architecture.

Donc en gros c'est utilisation du moteur de xpdf en remplacement définitif de ghostscript, avec en plus deux avantages :
- c'est une appli GNUstep, donc tirant partie des services, etc.
- on devrait donc avoir NSPDFImageRep (http://developer.apple.com/documentation/Cocoa/Reference/Applicatio(...)), cad la possibilité pour toutes applications GNUstep utilisant des images d'utiliser indistinctement des PDF à la place.

va chercher bonheur, va ! :-)

On peut noter aussi ViewPDF.app -- un visualisateur PDF GNUstep que l'on peut trouver ici : http://mac.wms-network.de/gnustep/imageapps/viewpdf/viewpdf.html(...)

sshot : http://mac.wms-network.de/gnustep/imageapps/viewpdf/snapshot_viewpd(...)

Il utilise au choix Ghostscript ou un rendu PDF basé sur xpdf.

J'ai pas trop eu le temps de faire plus joujou que ça aujourd'hui, m'enfin l'ergonomie ne m'a pas semblé si dramatique ? enfin bon je vais lire la doc un peu plus en détail :-)

Sinon, d'accord avec toi, maliwan est un projet _très_ intéressant. Mais bon c'est pas la même chose, c'est orienté bitmap, pas vectoriel.

Ben ... en fait, j'imagine que l'on doit pouvoir faire fonctionner GNUstep sous Windows sans trop de problèmes si on utilise le serveur X de cygwin, et en utilisant le backend X11 de GNUstep pour l'affichage.

Mais quand on parle de GNUstep/Windows, on parle en fait du portage sous windows directement, cad avec un backend graphique windows utilisant la gdi, etc. C'est ça qui est encore en alpha.

Franchement, aucune idée précise, car je ne l'ai jamais installé (j'ai pas de machines sous windows). Maintenant, pour ce que j'en sais, les choses bougent en ce moment, et ça a l'air d'évoluer. Les classes non-graphiques (Foundation) marchent depuis longtemps, pour les classes graphiques c'est considéré comme instable, mais bon ça progresse. Il y a quelques mois, on m'avait envoyé ces screenshots :
http://www.roard.com/screenshots/gnustep_on_windows1.jpeg(...)
http://www.roard.com/screenshots/gnustep_on_windows2.jpeg(...)
http://www.roard.com/screenshots/gnustep_on_windows3.jpeg(...)

J'imagine que les choses ont progressé, mais j'en sais pas plus, désolé. A priori ça reste encore "alpha" quand même.

question de goût effectivement -- la plupart des devs GNUstep apprécient le look NeXT en fait ;-)

Maintenant pour faire simple ... il est /possible/ de changer le look (style http://www.roard.com/screenshots/screenshot_theme21.png(...) ou http://www.roard.com/screenshots/screenshot_theme20.png(...)) mais pour le moment il n'y a pas vraiment d'outils simples pour le faire. En fait j'ai écrit un petit truc (http://www.roard.com/camaelon/(...)) pour ça, mais ça demanderait une mise à jour pour coller avec les versions actuelles de GNUstep (et résoudre certains problèmes, et rajouter des fonctionalités, et des thèmes, et... mes journées font 24h).

Quand à utiliser Gtk, la réponse est non, les deux frameworks sont suffisamment dissemblables dans leur architecture pour que mapper l'un sur l'autre ne soit pas vraiment un truc ultra-évident à pondre (pour un intérêt relatif, on va dire ...)

Mon avis rapide : il reste des bugs (ça a planté une fois) et des trucs à fignoler (genre l'utilisation des primitives postscript pour les dégradés serait mieux), mais bon, pour une toute première release sous GNUstep, c'est vraiment cool !

Ce qui serait bien c'est que d'autres programmeurs NeXT/OPENSTEP commencent à releaser leurs programmes pour GNUstep ;-) -- Cenon est parmis les premier "gros" logiciels OPENSTEP a avoir fait le pas vers GNUstep, et c'est encourageant :-)

En effet beaucoup de programmeurs NeXT pensent que GNUstep n'implèmente que partiellement les API, etc. -- bref, que le projet est morribond et ne permet pas le portage d'applis. Il n'y a pas qu'eux d'ailleurs, beaucoup de gens ont cette image, en partie parce qu'il y a quelques années le projet avancait effectivement très lentement !

Mais depuis 2 ans, on assiste à une amélioration constante, et le nombre d'utilisateurs et de programmeurs augmentent régulièrement -- le succès de MacOSX par ailleurs n'y est sans doute pas innocent, avec le renouveau d'Objective-C.

Pour ceux que ça intéresse, voici un article présentant GNUstep plus en détail : http://www.roard.com/docs/lmf1.article/(...)

ainsi que d'autres docs : http://www.roard.com/docs/(...)

Et accessoirement, il y aura un stand GNUstep au Fosdem, donc n'hésitez pas à venir poser des questions ...

c'est fait.

non, c'est Secret Service. Si je me souvient bien, le Secret Service, en plus d'assurer la protection du président, est censé s'occuper des cas de contrefaçon (je pensais que c'était uniquement concernant la contrefaçon de monnaie, mais à priori ça a l'air plus large)

hmm, disons que je pense qu'il vaut mieux d'abord avoir un logiciel qui marche avant de le porter ;-)
Mais bon, sinon, oui, avoir une appli qui compile sous OSX et sous GNUstep, ça fait toujours de la bonne pub pour GNUstep ! (et puis bon, dans le cas qui nous intéresse, porter un browser GNUstep utilisant WebCore sur OSX ne devrait pas être spécialement délicat)

Pour alex, je lui transmets, merci !

ben, l'idée pour ce que j'en sais (fabien est sûrement plus au courant, ça fait un mois que je suit plutôt d'assez loin ce qu'il se passe) est effectivement de faire un browser à partir de WebCore assez rapidement. A priori plutôt penchant du côté de Safari que de Mozilla (ie, un browser simple et pratique, pas une suite web). Quand à le porter sous OSX par la suite ... pourquoi pas, mais j'imagine que ça ne doit pas être dans les trucs à faire absolument dans l'immédiat :)
Pour les plugins, aucune idée. J'imagine qu'il devrait être possible de réutiliser les plugins mozilla de la même façon qu'avec konqueror... mais bon, là encore, je pense pas que ce soit un truc qui sera fait dans l'immédiat..
Sinon ça m'étonnerait qu'il y ait quelque chose à récupérer dans Camino -- le rendu (et un peu plus) est complètement fait côté WebCore, ce qui reste à faire par dessus est donc une gui simple, pratique, et intuitive. Faire une gui sous OSX/GNUstep n'est pas exactement compliqué, essayer de récupérer celle de Camino ne serait qu'une perte de temps àmha (d'autant qu'il faudrait de toute façon refaire les nibs avec Gorm). Sinon, pour le moment, c'est plus une démonstration de WebCore qu'un browser complet à priori !

A propos, tu as reçu le mail d'Alex Perez qui voulait te contacter à propos de tes (magnifiques) icones ? :-)

Le problème, c'est que l'interdiction dans un pays anglophone de "lindows" est difficilement faisable -- à mon avis. D'une part parce que Windows est quand même là bas un mot générique, d'autre part si Microsoft a tous les droits sur les termes ressemblant à "windows", que doit on dire à propos du système X-Window ?? ah, zut, il s'agit d'un système existant avant MS Windows... et puis faut pas pousser, le terme "lindows" est quand même assez distinct du terme "windows" -- les gens ne sont pas complètement débiles ... (du moins, pas sur des volumes pouvant inquiéter microsoft amha).

Par contre, dans un autre pays, non-anglophone, c'est sûr que le point de vue de microsoft a plus de poids.

Ceci dit, la démarche de microsoft est un brin étrange, car l'énorme pub dont bénéficie lindows était quand même largement prévisible... ce qui n'est finalement pas si intéressant pour le monde linux, vu l'approche démentielle choisie par lindows (ie, compte root) ...

ben l'installation, ce n'est pas le plus embêtant... en fait, le plus simple, si tu as une debian, c'est d'utiliser les applis packagés par Chad Hardin ... (en dehors des paquets officiels gnustep pour debian, mais avec largement plus d'applis et des trucs plus récents).
[cf. http://www.osnews.com/story.php?news_id=4818(...) ]
Pour l'utilisation, ça dépends des applis. GNUmail marche plutôt bien, le reste, c'est plus aléatoire ... même si ça progresse vite. Dans une optique purement utilisateur, un environnement basé sur GNUstep ne serait pas assez costaud/complet je pense. Maintenant, pour un développeur, ça l'est largement pour développer des applis GNUstep en utilisant Gorm (un équivalent du fameux InterfaceBuilder dispo sous NeXTSTEP/OPENSTEP/MacOSX) ...

Attendons que Stefan mette en place un cvs pour récupérer WebCore ..

Heu, c'est à dire ? faire un thème NeXTSTEP pour Mozilla quoi, histoire que ça paraisse s'intégrer plus harmonieusement aux applis GNUstep ? Ben, oui, c'est bien sûr possible (si ce n'est pas déja fait), mais l'intérêt est assez limité ...

- d'une part, ce ne sera pas une appli GNUstep
- d'autre part on gardera la "lourdeur" de mozilla

Que ce ne soit pas une appli GNUstep, on peut penser que ce n'est pas grave (et ça ne l'est pas), mais c'est dommage, car dans ce cas on aura pas une coopération complète entre les applis GNUstep -- pas d'utilisation des services, gestion du presse papier limitée par rapport à GNUstep, etc. Bref une intégration un peu foireuse, un peu comme si tu voulais utiliser khtml avec un bureau gnome. Ca marche, mais c'est un peu dommage, car on y perds.
Et accessoirement, si on change le look GNUstep pour autre chose (genre http://www.roard.com/screenshots/screenshot_theme21.png(...) ou http://www.roard.com/screenshots/screenshot_theme22.png(...)), le mozilla thèmé ne suivra pas ...
Et puis bon, comme tu le dis, WebCore est plus vaste et plus intéressant (intégration simple d'un composant web dans des applis)

récemment, j'ai répondu par la négative à une offre d'emploi (j'ai trouvé ailleurs), et je leur ait fait remarquer qu'un site "web" *uniquement* en flash, pour une boite d'info, c'était pas top. La réponse n'a pas tardé : "insolent ! on ne vous oubliera pas !" ... j'ai réenvoyé un mail en leur expliquant que je n'avait pas *pu* consulter leur site à cause de ça, et là, pas de réponse...

Enfin bon, des fois les DRH sont chatouilleux, faut le savoir ;-)

Faut se mettre à GNUstep dans ce cas ... :-)
Pour le dev, c'est vraiment cool. Pour le bureau, pas encore, mais ça commence à venir (et ce qui fait plaisir c'est que les applis ont pas mal la tendance à vouloir coopérer proprement entre elles et éviter le bloat).

Avec une debian, on peut utiliser les paquets simplygnustep :

deb http://simplygnustep.sourceforge.net/Packages/(...) binary-i386/
deb-src http://simplygnustep.sourceforge.net/Packages/(...) source/

Faire "apt-get update"

Puis "apt-get install sgstep-meta-user"

et "apt-get install sgstep-meta-developer"

Il y a même des jeux :

"apt-get install sgstep-meta-games"

Il me semble que Mézières avait surtout bossé les personnages et Moebius les décors non ? enfin en tout cas la parenté graphique entre le 5eme élément et Valérian et assez évidente ...

Le prochain film qui sort basé sur une BD, c'est pas Blueb avec cassel ?

Ce n'est pas disponible ? étonnant, c'est quand même une fonctionnalitée bien appréciée des développeurs, et présente un peu partout (dans vim et emacs par exemple...).

Le terme anglo-saxon utilisé est "folding", fait une recherche là dessus, tu trouveras peut être un plugin eclipse pour cela...

Démago ? dans le style "tous pourris" ? oui, peut être. Mais bon sinon, ça me semble plus cynique que naïf :-)

? si tu récupères la sortie, elle n'est pas censé être compressée. Libre à toi de réenregistrer un CD audio à partir de ça. Si par contre tu veux compresser, ou si ce que tu récupères est déja un flux numérique compressé, ma foi passer par VMWare ne change rien au problème (pas de pertes supplémentaires par rapport à ce que tu as à l'origine).

Non, la seule "solution" côté Majors, c'est de faire passer des lois pour imposer du matos qui limiterait en hard la recopie numérique (c'est bien ce qu'ils aimeraient obtenir), ou du moins à essayer d'imposer ce genre de matos (un peu comme les magnétoscopes avec protection macrovision).

L'un dans l'autre, en jouant sur ce tableau là, et en utilisant EUCD, DMCA et droit d'auteur, ils pensent pouvoir limiter sérieusement la casse et garder leur business model actuel (ie, même si certains bypassent les protections, ce ne sera qu'un pourcentage minime, espèrent-ils). On verra...

Oui, une adaptation de SOS Bonheur avec un bon réalisateur, ça pourrait être absolument décapant ... trop peut être pour qu'on puisse espèrer une telle adaptation :-)

linux n'est pas basé pour autant sur du proprio, Bitkeeper est un outil !

Heu ... je n'ai pas dit que linux était "basé" sur du proprio. Par contre, oui, le développement de linux est basé sur du proprio. Et simplement, l'analyse qui peut être faite, et mise en avant par certains (microsoft, sco...), est une réthorique jouant sur des idées du style "tout seul, les LL ne peuvent rien faire, ils doivent piquer du code/des idées/des outils au proprio, gnagnagna gnagnagna"... bref, si on peut se passer du proprio, c'est mieux, on prête le flan à moins d'attaques ("attaques" médiatiques ou techniques).

C'est mieux pour de multiples raisons -- philosophiques, "le proprio c'est mal", publicitaire "vous voyez bien que le LL c'est qu'un gadget", voire philosophico-pragmatique "le proprio c'est mal parce qu'on risque de s'enferrer dans une logique d'appropriation du contenu".

Et le problème est bien là -- certes, on peut considérer bitkeeper comme un outil, au même titre qu'un éditeur de texte. Mais bitkeeper permet de gêrer quelque chose en plus que les sources du kernel, il garde/génère également toutes les méta-informations concernant le développement du kernel. Ne vouloir utiliser que bitkeeper est abandonner ces informations là à un outil propriétaire -- et donc avoir le risque de s'enferrer dedans -- et dangereux, du moins dommageable à long terme.

Cela ne veut pas dire que, en pratique, cela posera un problème -- simplement que c'est possible. Et malheureusement, c'est le cas -- cf. la licence controversée de bitkeeper ...

Donc oui, on est pas obligé de n'utiliser que du LL. Mais utiliser du propriétaire présente un risque, plus ou moins grand. Dans le cas d'outils génériques (compilos, éditeurs de textes...) le risque n'est pas très grand, car les outils sont facilement remplaçables. Dans le cas d'autres outils, cela peut être plus gênant -- c'est un peu comme si, sous prétexte que Microsoft aurait mis à disposition il y a cinq ans Word sous linux, tout le monde utilisait Word pour écrire de la doc sous linux. Tant que le statu quo est là, pas de problème, on peut lire les docs -- mais il ne faut pas oublier que l'information est captive. C'est tout le problème des logiciels propriétaire (en sus de la problématique de visibilité/partage/réutilisabilité du code).

Bref ... la réponse idéale n'est pas de se contenter d'un logiciel propriétaire, mais d'écrire un logiciel libre équivalent. Maintenant, on peut tout à fait comprendre l'usage de logiciel propriétaire quand il n'existe pas d'équivalents aussi bons -- et c'était le cas pour BitKeeper. Mais pour autant, il ne faut pas oublier ce qu'on mets en jeu, et essayer si possible de motiver des gens pour faire un LL équivalent ou supérieur au logiciel propriétaire utilisé. Hors ce qui a été mis en avant avec BitKeeper c'était simplement "on utilise un logiciel propriétaire, et alors ? ça nous fait gagner du temps" sans chercher plus loin. Et ça, c'est plutôt un raisonnement à très court terme, et la position de RMS sur ce sujet était tout à fait logique, valable, et cohérente. Et d'ailleurs, la suite a donné raison à RMS (cf problèmes BitKeeper, sa licence ...)

Beaucoup semblent uniquement concernés par des "gains" à court terme, et perdent totalement de vue la raison d'être des logiciels libres. Se retrouver avec un système libre contenant du proprio, ce ne devrait être qu'un pis aller, pas une fin en soi, c'est mon avis.

Est-ce que l'émission sera disponible en ligne, ou idéalement distribuable ? et en quoi consistait le colloque, quels ont été les recommandations émises ? Et surtout, est-ce que sur place vous avez trouvé une réelle volonté de changement, de moyens, etc. ?
En tout cas ça fait toujours plaisir de voir que les choses avancent dans le bon sens :)