En regardant très rapidement les sources de lynkeos, ça semble relativement simple à porter. Le seul truc bien évidemment (on fait pas de miracles malheureusement), c'est que l'on peut oublier le support Quicktime :-) (y'a une implémentation de quicktime sous linux ??)
M'enfin pour le reste, c'est à dire faire du traitement sur des images, à priori, y'a pas de raison. Je jette un oeil demain, si je peux.
J'ajoute que ce qui est VRAIMENT top (a mon avis), c'est bien le constructeur d'interface, Gorm. Car c'est plus qu'un simple constructeur d'UI -- il travaille directement avec les objets (un fichier interface etant simplement les objets utilises serialises sur disque). Donc tu ne fait pas que positionner tes widgets, tu as en meme temps toutes les relations inter-objets sauvegardes, leurs parametres, etc (et tu fait ca a partir de Gorm, bien sur). Du coup, ca te fait sauter pas mal de code que tu devrait te taper sinon (et ce n'est pas de la generation de code, justement).
Vu qu'on travaille avec des objets, tu peux aussi te creer tes propres palettes d'objets (pas forcement graphiques) a utiliser dans Gorm et les lier avec ton programme, les instancier, etc. Gorm permet egalement de creer rapidement des objets quelconques et genere le code Objective-C dans ce cas.
Ajoutons que du coup, tu peux tester l'interface de ton programme 'en live' sans meme qu'il soit necessaire de compiler quoi que ce soit -- les objets sont instancies a la volee et ca roule. Pratique pour tester rapidement le fonctionnement.
Bref, on fait de prog orientee objet et ca se sent. Et de plus, le framework graphique (AppKit), est vraiment particulierement bien fichu. vraiment. Il est tres tres rare qu'on ait besoin par exemple de deriver une classe; on utilise plutot des objets delegues, etc.
Un truc qui a mon avis serait vraiment proche de la perfection, ce serait de finir le bridge Squeak<->ObjectiveC ... on aurait alors l'avantage de Smalltalk ET l'avantage du framework OpenStep et des outils associes :-)
mouaif, sauf qu'on peut ptet imaginer aussi que pour avoir un systeme qui fait gagner vachement de temps aux developpeurs, ledit systeme doit fournir un max de trucs deja fait -- et que donc ledit systeme est lui, plutot long a coder. Ce qui est le cas avec GNUstep, tout etait a implementer avant de pouvoir vraiment tirer partie du systeme pour developper des applis..
On peut aussi se dire que malgres tout, c'est quand meme plutot efficace, si tu regardes le peu de developpeurs qui ont bosses dessus et ce qui existe aujourd'hui (meme si c'est pas parfait).
Concernant le dev rapide d'appli avec OpenStep, c'est en effet en general plus rapide a coder qu'avec d'autres trucs -- en particulier grace a InterfaceBuilder/Gorm, selon mon experience et selon l'avis de ceux qui ont essayes :-)
Maintenant c'est sur que par exemple Qt est une tres bonne lib, et que donc la difference de rapidite entre un dev fait avec OpenStep et un dev fait avec Qt est moins flagrante qu'il y a dix ans (et quelque part, encore heureux !).
Reste que l'on developpe tres rapidement en utilisant OpenStep, ca, c'est une evidence. Et que je pense que ca reste plus rapide pour developper une appli graphique que nombre d'autres solutions. Ce serait bien cool que l'editeur EOF graphique soit enfin release, ca serait pas mal pour les bases de donnes aussi.. :) m'enfin bon..
Ce ne sont pas vraiment des extensions "propriétaires" -- rien ne nous empêche de les implémenter hein. D'ailleurs, NSToolbar a été committé par Quentin il y a quelques mois. Et ce sont simplement des widgets "nouveaux" plus que des extensions..
Je ne pense pas qu'Apple les ait créé juste par plaisir d'être "incompatible" avec OpenStep (vu qu'il le restent de toute façon..)
vi, entre autre à cause du flou artistique pour définir GNUstep -- desktop, environnement de prog, etc? -- perso moi je considère que c'est un environnement de dev, pas un desktop. Un desktop basé sur GNUstep, il y a quelques projets: http://www.nongnu.org/backbone/(...) http://home.gna.org/garma/(...)
.. ou là il y a des sections "screenshots" ;-)
m'enfin je suis d'accord que le "marketing" du projet GNUstep lui-même est un peu faiblard, pour être gentil, et on essaie de changer ça en ce moment...
Concernant le moteur de thème, j'ai pas eu le temps de bosser dessus depuis quelque temps (pas eu le temps de bosser sur GNUstep non plus..), et je recommence juste à coder dessus -- avec dans l'idée de faire une nouvelle release très bientôt. Pfiou j'ai un problème moi, à faire du release early, release often :-)
Sinon en gros, la majorité de ce que je voulais modifier pour -gui est commité, donc il ne reste "plus" qu'à finaliser le moteur lui-même, ce qui devrait être assez rapide.
Concernant les icones, ça progresse, c'est en bonne voie. On a fait un guideline avec quentin pour les icones, et on est en pourparler avec quelques graphistes (d'ailleurs je viens de recevoir les deux premières icones dans ma bal aujourd'hui.. ;-) http://www.quentinmathe.com/gnustep/documentation/UI/icons/(...)
Juste pour préciser, MultideskOS est une mauvaise blague. Il s'agit d'un type qui a voulu faire un "OS", pour aboutir à un shell graphique pour DOS (remarque, dit comme ça, on pourrait penser à microsoft ;-). Certains lui sont tombés dessus (online :-) en se foutant de sa gueule..
Depuis, c'est devenu un gimmick de linuxfr pour quelques uns.
L'environnement est "spécial" ? ... ben... disons que c'est une des grandes forces de Squeak (et des environnements Smalltalk en général), au contraire !
Ceci dit, tu as l'air de mélanger pas mal de choses. Squeak est une implémentation libre de Smalltalk, les e-toys ne sont qu'une partie de ce que propose Squeak lui-même.
Bon. Prenons ça par le début. Smalltalk est le premier langage véritablement OO, développé dans les années 70 au Xerox Parc, standardisé en 1980. D'ailleurs le terme de programmation orientée objet vient d'Alan Kay (créateur de Smalltalk). Cf. Wikipedia: http://fr.wikipedia.org/wiki/Smalltalk(...)
Mais plus qu'un langage, Smalltalk est aussi (généralement) un environnement de programmation -- disposant de tous les outils nécessaires : browser de code, débugger, refactoring browser, etc. Différentes implémentations de Smalltalk existent, dont Squeak.
Squeak en tant que tel mets l'accent sur le multimédia (et dispose ainsi d'une palanquée d'outils/librairies pour jouer avec le son, la 3D, la vidéo, etc.) ainsi que sur son utilisation par des enfants (via les e-toys, qui sont grosso-modo des objets programmables de façon graphique et facilement utilisables par des enfants, ce qui leur permet ainsi de réaliser des programmes sympas sans écrire une ligne de Smalltalk). L'interface graphique sous Squeak est assez puissante (vectoriel, etc.), même si je suis perso pas très fan des morphs (les composants graphiques utilisées pour l'UI)..
Concernant le langage Smalltalk lui-même, il est vraiment simple à utiliser (Alan Kay a toujours travaillé dans l'optique de transformer un ordinateur en un "expérimentateur d'idées" et non une simple boite à calculs, et entre autre a beaucoup travaillé avec des enfants -- d'ou son travail sur Smalltalk puis Squeak). Malgrès (ou grâce) à cette simplicité, Smalltalk est extrèmement puissant, en particulier grâce à ses capacitiées réflexives (introspection, etc.) et par le fait que TOUT est objet.
C'est sûr, ça nécessite de réfléchir un peu différemment que ce que l'on ferait avec un langage procédural style C ou Pascal (C++ lui est batard, de toute façon), mais bon, après tout, la POO commence quand même à rentrer dans les moeurs, non ? :-)
Au niveau des capacitées du langage... bien évidemment Smalltalk est puissant et absolument pas contraint à une utilisation donnée. Par contre, historiquement, le fait que techniquement Smalltalk fonctionne avec une machine virtuelle a sûrement du contribuer à limiter son usage (lenteur, gc..). Mais franchement, c'est du passé, surtout avec les machines actuelles (après tout, certains utilisent bien Java, alors...)
Je ne connais pas bien Rebol, mais Squeak n'est absolument pas "caché" : Squeak est écrit lui-même en Smalltalk (enfin, un sous-ensemble compilable), et on peut justement jeter un oeil sur le code de toutes les librairies !
Bref, je n'ai peut être pas échappé aux trolls ^_^ mais en toute honnêteté, Smalltalk est véritablement un langage passionnant et simple à apprendre (et franchement, je pense que jeter un coup d'oeil dessus ne fait pas de mal à un développeur curieux). Squeak lui-même a des contraintes non présentes dans d'autres Smalltalk (comme le fait de ne pas vraiment s'intégrer au système "hôte" en proposant une fenêtre/écran unique ou tout s'exécute...), mais globalement c'est vraiment un projet intéressant.
Et puis, nombre de choses assez géniales pour développer quand on utilise Smalltalk n'existent pas ou alors de manières réduites dans les autres langages, genre le refactoring browser (permettant de réaliser automatiquement un refactoring donné), ou le fait que la compilation soit incrémentale (genre ton programme bug, ça ouvre le débugger, tu peux corriger l'erreur et cliquer sur continuer, et plaf, la méthode que tu as corrigée est recompilée à la volée et ton programme continue là ou il s'était arrêté -- pas mal pratique et fait gagner beaucoup de temps !), voire même tout simplement l'existence du workspace pour tester rapidement des bouts de code...
Vraiment, développer avec est agréable et rapide. Comme de plus le langage dispose d'un garbage collector, pas de problèmes de manip mémoire (source de la plupart des erreurs...)
Il existe des passerelles pour utiliser des bibliothèques externes à partir de Squeak, et des bindings Qt sont théoriquement faisable, mais je ne crois pas qu'il y en ait pour le moment. Ceci dit, ce n'est pas vraiment l'optique de Squeak -- je pense que pour de la prog smalltalk permettant de faire des applis plus "classiques" on peut jeter un oeil au smalltalk de cincom (utilisation gratuite, par contre, aie aie pour une utilisation commerciale...), ou au smalltalk/X (http://www.smalltalk.org/versions/ExeptSmalltalkX.html(...)), gratuit et libre pour une utilisation commerciale (je sais plus s'il est libre tout court par contre, j'ai un doute).
Un truc que je vous conseille de regarder, c'est Seaside, un serveur d'applications web assez génial (inspiré de WebObjects, mais avec des trucs très cool en plus), et dispo pour Squeak (on peut tout à fait lancer Squeak sans son affichage graphique).
Voila voila... sinon perso, pour de la prog graphique, j'ai pas vu mieux qu'OpenStep et InterfaceBuilder, mais hein ;-) (et dire qu'il y a même une implémentation FSF avec GNUstep et Gorm et que si peu de gens aident ... snif... ). Mais bon, Qt est pas trop mal (cependant, C++ ...).
Juste pour confirmer que le multi-thread n'est pas forcèment la panacée : GNUMail (lecteur de mail comme son nom l'indique) était à l'origine en multi-thread, mais les dernières versions sont passées en IO non bloquantes et ont virés les threads. Et ben ça marche mieux, plus rapide et plus fluide. Comme quoi, les idées évidentes (utilisation des threads) ne sont pas forcèment toujours les bonnes :)
C'est pour ça qu'il y a la possibilité d'avoir la hauteur des arcs contrainte... de toute façon, je doute qu'un treeview soit bien plus pratique avec ce thread là ! :-)
Sinon pour le côté "on repère mieux avec le nom de l'auteur et le sujet", rien n'empêche d'avoir une bulle d'aide l'indiquant (mais bon, ça n'y est pas pour le moment sur gnumail).
Enfin tout ce que je peux dire, c'est que l'utilisant, je trouve ça effectivement plus pratique que le treeview traditionnel. Libre à vous de tester.
la hauteur des arcs et le fait que ca passe au dessus ou au dessous n'est pas determinant -- c'est juste pour alleger la representation.
Fouilli et peu clair, ca depends -- le screenshot a ete pris expres lors d'une conversation assez chargee -- mais il faut surtout comparer au systeme plus classique de treeview. Et la, c'est effectivement plus clair/compact/efficace que si on avait utilise une treeview.
Par rapport a une representation arborescente, c'est plus compact, ca monte mieux en charge, la position des nodes ne bouge pas si on ajoute de nouveaux messages (stabilite) et on voit mieux les relations entre messages.
Le gros interet c'est qu'il est tres simple de faire des traitements par dessus ensuite -- on peut tout a fait imaginer d'utiliser des couleurs differentes pour visualiser par exemple les differents protagonistes, etc. L'inspecteur de GNUMail pourra justement servir a jouer sur ces parametres.
Hm... Tu recoit des mails au fur et a mesure, classes par exemple par leur date d'arrivee (cas le plus probable). Parfait. Mais si tu "discute" par mail, tu vas avoir une serie de messages disperses (car par exemple d'autre mails sont arrives entre temps...).
Une solution est de faire alors un classement par sujet... Par exemple avec mutt: http://www.jhweiss.de/img/mutt_index.png(...)
Et tu represente les relations entre les mails (qui a repondu a qui) par un arbre.
Le probleme c'est que si tu restes dans cette config, quand un nouveau mail arrive il n'est pas forcement visible de suite a l'ecran (car le classement est forcement different...). Donc la plupart des gens fonctionnent avec le classement par date; mais n'empech, avoir la visu arborescente est parfois bien pratique.
Les threadarcs permettent d'avoir cette visualisation, de facon plus efficace que le traditionnel arbre vertical (a la mutt), et de plus on peut continuer a avoir le classement par date (ou n'importe lequel) en plus.
Bref, on visualise bien mieux la conversation, et c'est plus efficace pour naviguer dedans.
Bien evidemment c'est surtout utile pour de longues conversations, souvent le cas si tu est abonne a des mailing-lists.
rassure toi, de une tu as le droit de faire des copies privées (du moins pour le moment encore), justement pour répondre à ce scénario de 1 utilisateur et n supports, voir même 1 utilisateur ~ cercle familial.
De deux ... les droits d'auteurs sur un CD sont minimes par rapport au prix du CD (quelques poucents), donc leur suppression aurait peu d'impact sur le prix final.
Et puis, même si ton idée était plausible, on peut facilement imaginer un scénario amusant ou les majors, arguant de "frais de traitement", ne toucheraient pas au prix du CD mais sucreraient au passage les droits d'auteur si le client indique qu'il dispose déja du CD ;-) (ce serait bien dans leurs manières)
Oui, les jobs MacOSX ou Objective-C ne courrent pas encore les rues ... m'enfin, la situation c'est clairement amélioré avec justement l'apparition d'OSX. Perso j'ai eu 2-3 fois des demandes pour bosser sur des logiciels OPENSTEP pour des banques (à une époque, certaines ont utilisés NeXT/OPENSTEP), si tu est sur Paris il y a peut être des possibilitées de ce côté là (j'en sais pas beaucoup plus vu que je n'ai jamais donné suite...).
De rien :-) -- je pense que ce sont des technos qui valent la peine de s'y intéresser, même si tout n'est pas parfait, il y a un potentiel certain..
\begin{remarque générale}
Au fait, quand vous lisez des articles dans LMF, n'hésitez pas à écrire aux auteurs pour des conseils, remarques, questions ou autre. Très très peu le font, et du coup ce n'est pas forcément évident de savoir si on a fait un "bon" article que les gens apprécient ou un article nul ou qui n'intéresse personne... avoir un peu de feedback est utile ! :-)
\end{remarque générale}
[^] # Re: Cocoa/Linux
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche 10 ans d'OpenStep. Évalué à 3.
M'enfin pour le reste, c'est à dire faire du traitement sur des images, à priori, y'a pas de raison. Je jette un oeil demain, si je peux.
[^] # Re: Re:
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche 10 ans d'OpenStep. Évalué à 1.
[^] # Re: Y'a pas le GUI dans la Re: :)
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche 10 ans d'OpenStep. Évalué à 1.
[^] # Re: Re:
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche 10 ans d'OpenStep. Évalué à 5.
Vu qu'on travaille avec des objets, tu peux aussi te creer tes propres palettes d'objets (pas forcement graphiques) a utiliser dans Gorm et les lier avec ton programme, les instancier, etc. Gorm permet egalement de creer rapidement des objets quelconques et genere le code Objective-C dans ce cas.
Ajoutons que du coup, tu peux tester l'interface de ton programme 'en live' sans meme qu'il soit necessaire de compiler quoi que ce soit -- les objets sont instancies a la volee et ca roule. Pratique pour tester rapidement le fonctionnement.
Bref, on fait de prog orientee objet et ca se sent. Et de plus, le framework graphique (AppKit), est vraiment particulierement bien fichu. vraiment. Il est tres tres rare qu'on ait besoin par exemple de deriver une classe; on utilise plutot des objets delegues, etc.
Un truc qui a mon avis serait vraiment proche de la perfection, ce serait de finir le bridge Squeak<->ObjectiveC ... on aurait alors l'avantage de Smalltalk ET l'avantage du framework OpenStep et des outils associes :-)
[^] # Re: enlarge your penis
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche 10 ans d'OpenStep. Évalué à 3.
On peut aussi se dire que malgres tout, c'est quand meme plutot efficace, si tu regardes le peu de developpeurs qui ont bosses dessus et ce qui existe aujourd'hui (meme si c'est pas parfait).
Concernant le dev rapide d'appli avec OpenStep, c'est en effet en general plus rapide a coder qu'avec d'autres trucs -- en particulier grace a InterfaceBuilder/Gorm, selon mon experience et selon l'avis de ceux qui ont essayes :-)
Maintenant c'est sur que par exemple Qt est une tres bonne lib, et que donc la difference de rapidite entre un dev fait avec OpenStep et un dev fait avec Qt est moins flagrante qu'il y a dix ans (et quelque part, encore heureux !).
Reste que l'on developpe tres rapidement en utilisant OpenStep, ca, c'est une evidence. Et que je pense que ca reste plus rapide pour developper une appli graphique que nombre d'autres solutions. Ce serait bien cool que l'editeur EOF graphique soit enfin release, ca serait pas mal pour les bases de donnes aussi.. :) m'enfin bon..
[^] # Re: cocoa et "write once compile everywhere"?
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche 10 ans d'OpenStep. Évalué à 3.
Je ne pense pas qu'Apple les ait créé juste par plaisir d'être "incompatible" avec OpenStep (vu qu'il le restent de toute façon..)
[^] # Re: :)
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche 10 ans d'OpenStep. Évalué à 4.
http://www.nongnu.org/backbone/(...)
http://home.gna.org/garma/(...)
.. ou là il y a des sections "screenshots" ;-)
m'enfin je suis d'accord que le "marketing" du projet GNUstep lui-même est un peu faiblard, pour être gentil, et on essaie de changer ça en ce moment...
[^] # Re: IHM
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche 10 ans d'OpenStep. Évalué à 10.
Sinon en gros, la majorité de ce que je voulais modifier pour -gui est commité, donc il ne reste "plus" qu'à finaliser le moteur lui-même, ce qui devrait être assez rapide.
Concernant les icones, ça progresse, c'est en bonne voie. On a fait un guideline avec quentin pour les icones, et on est en pourparler avec quelques graphistes (d'ailleurs je viens de recevoir les deux premières icones dans ma bal aujourd'hui.. ;-)
http://www.quentinmathe.com/gnustep/documentation/UI/icons/(...)
[^] # Re: squeak, mais encore?
Posté par Nicolas Roard (site web personnel) . En réponse au journal Squeak, c'est fun. Évalué à 1.
d'ailleurs un dev qui bosse sur gnustep était ptet intéressé pour porter ça... on verra bien, c'est vrai que ça serait sympa.
[^] # Re: déjà vu
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Projet de traduction de Squeak en Français. Évalué à 1.
Depuis, c'est devenu un gimmick de linuxfr pour quelques uns.
Sinon, oui, Squeak, c'est bien. Cf ce que j'en pense plus en détail : http://linuxfr.org/comments/469379.html#469379(...)
[^] # Re: squeak, mais encore?
Posté par Nicolas Roard (site web personnel) . En réponse au journal Squeak, c'est fun. Évalué à 5.
Ceci dit, tu as l'air de mélanger pas mal de choses. Squeak est une implémentation libre de Smalltalk, les e-toys ne sont qu'une partie de ce que propose Squeak lui-même.
Bon. Prenons ça par le début. Smalltalk est le premier langage véritablement OO, développé dans les années 70 au Xerox Parc, standardisé en 1980. D'ailleurs le terme de programmation orientée objet vient d'Alan Kay (créateur de Smalltalk). Cf. Wikipedia: http://fr.wikipedia.org/wiki/Smalltalk(...)
Mais plus qu'un langage, Smalltalk est aussi (généralement) un environnement de programmation -- disposant de tous les outils nécessaires : browser de code, débugger, refactoring browser, etc. Différentes implémentations de Smalltalk existent, dont Squeak.
Squeak en tant que tel mets l'accent sur le multimédia (et dispose ainsi d'une palanquée d'outils/librairies pour jouer avec le son, la 3D, la vidéo, etc.) ainsi que sur son utilisation par des enfants (via les e-toys, qui sont grosso-modo des objets programmables de façon graphique et facilement utilisables par des enfants, ce qui leur permet ainsi de réaliser des programmes sympas sans écrire une ligne de Smalltalk). L'interface graphique sous Squeak est assez puissante (vectoriel, etc.), même si je suis perso pas très fan des morphs (les composants graphiques utilisées pour l'UI)..
Concernant le langage Smalltalk lui-même, il est vraiment simple à utiliser (Alan Kay a toujours travaillé dans l'optique de transformer un ordinateur en un "expérimentateur d'idées" et non une simple boite à calculs, et entre autre a beaucoup travaillé avec des enfants -- d'ou son travail sur Smalltalk puis Squeak). Malgrès (ou grâce) à cette simplicité, Smalltalk est extrèmement puissant, en particulier grâce à ses capacitiées réflexives (introspection, etc.) et par le fait que TOUT est objet.
C'est sûr, ça nécessite de réfléchir un peu différemment que ce que l'on ferait avec un langage procédural style C ou Pascal (C++ lui est batard, de toute façon), mais bon, après tout, la POO commence quand même à rentrer dans les moeurs, non ? :-)
Au niveau des capacitées du langage... bien évidemment Smalltalk est puissant et absolument pas contraint à une utilisation donnée. Par contre, historiquement, le fait que techniquement Smalltalk fonctionne avec une machine virtuelle a sûrement du contribuer à limiter son usage (lenteur, gc..). Mais franchement, c'est du passé, surtout avec les machines actuelles (après tout, certains utilisent bien Java, alors...)
Je ne connais pas bien Rebol, mais Squeak n'est absolument pas "caché" : Squeak est écrit lui-même en Smalltalk (enfin, un sous-ensemble compilable), et on peut justement jeter un oeil sur le code de toutes les librairies !
Bref, je n'ai peut être pas échappé aux trolls ^_^ mais en toute honnêteté, Smalltalk est véritablement un langage passionnant et simple à apprendre (et franchement, je pense que jeter un coup d'oeil dessus ne fait pas de mal à un développeur curieux). Squeak lui-même a des contraintes non présentes dans d'autres Smalltalk (comme le fait de ne pas vraiment s'intégrer au système "hôte" en proposant une fenêtre/écran unique ou tout s'exécute...), mais globalement c'est vraiment un projet intéressant.
Et puis, nombre de choses assez géniales pour développer quand on utilise Smalltalk n'existent pas ou alors de manières réduites dans les autres langages, genre le refactoring browser (permettant de réaliser automatiquement un refactoring donné), ou le fait que la compilation soit incrémentale (genre ton programme bug, ça ouvre le débugger, tu peux corriger l'erreur et cliquer sur continuer, et plaf, la méthode que tu as corrigée est recompilée à la volée et ton programme continue là ou il s'était arrêté -- pas mal pratique et fait gagner beaucoup de temps !), voire même tout simplement l'existence du workspace pour tester rapidement des bouts de code...
Vraiment, développer avec est agréable et rapide. Comme de plus le langage dispose d'un garbage collector, pas de problèmes de manip mémoire (source de la plupart des erreurs...)
Il existe des passerelles pour utiliser des bibliothèques externes à partir de Squeak, et des bindings Qt sont théoriquement faisable, mais je ne crois pas qu'il y en ait pour le moment. Ceci dit, ce n'est pas vraiment l'optique de Squeak -- je pense que pour de la prog smalltalk permettant de faire des applis plus "classiques" on peut jeter un oeil au smalltalk de cincom (utilisation gratuite, par contre, aie aie pour une utilisation commerciale...), ou au smalltalk/X (http://www.smalltalk.org/versions/ExeptSmalltalkX.html(...)), gratuit et libre pour une utilisation commerciale (je sais plus s'il est libre tout court par contre, j'ai un doute).
Un truc que je vous conseille de regarder, c'est Seaside, un serveur d'applications web assez génial (inspiré de WebObjects, mais avec des trucs très cool en plus), et dispo pour Squeak (on peut tout à fait lancer Squeak sans son affichage graphique).
Voila voila... sinon perso, pour de la prog graphique, j'ai pas vu mieux qu'OpenStep et InterfaceBuilder, mais hein ;-) (et dire qu'il y a même une implémentation FSF avec GNUstep et Gorm et que si peu de gens aident ... snif... ). Mais bon, Qt est pas trop mal (cependant, C++ ...).
[^] # Re: spamassassin vs thunderbird
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche SpamAssassin devient un projet Apache, et corrige une faille de sécurité. Évalué à 1.
http://perso.club-internet.fr/branchum/brown.htm(...)
excellent auteur. Le recueil de nouvelles "fantômes et farfafouilles" est très bien et fortement conseillé :-)
[^] # Re: tentative spamassassin + sylpheed [complètement HS]
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche SpamAssassin devient un projet Apache, et corrige une faille de sécurité. Évalué à 3.
[^] # Re: autres implémentations
Posté par Nicolas Roard (site web personnel) . En réponse au journal Thread Arcs. Évalué à 2.
[^] # Re: hum
Posté par Nicolas Roard (site web personnel) . En réponse au journal Thread Arcs. Évalué à 4.
Sinon pour le côté "on repère mieux avec le nom de l'auteur et le sujet", rien n'empêche d'avoir une bulle d'aide l'indiquant (mais bon, ça n'y est pas pour le moment sur gnumail).
Enfin tout ce que je peux dire, c'est que l'utilisant, je trouve ça effectivement plus pratique que le treeview traditionnel. Libre à vous de tester.
[^] # Re: hum
Posté par Nicolas Roard (site web personnel) . En réponse au journal Thread Arcs. Évalué à 1.
[^] # Re: hum
Posté par Nicolas Roard (site web personnel) . En réponse au journal Thread Arcs. Évalué à 3.
Fouilli et peu clair, ca depends -- le screenshot a ete pris expres lors d'une conversation assez chargee -- mais il faut surtout comparer au systeme plus classique de treeview. Et la, c'est effectivement plus clair/compact/efficace que si on avait utilise une treeview.
Par rapport a une representation arborescente, c'est plus compact, ca monte mieux en charge, la position des nodes ne bouge pas si on ajoute de nouveaux messages (stabilite) et on voit mieux les relations entre messages.
Le gros interet c'est qu'il est tres simple de faire des traitements par dessus ensuite -- on peut tout a fait imaginer d'utiliser des couleurs differentes pour visualiser par exemple les differents protagonistes, etc. L'inspecteur de GNUMail pourra justement servir a jouer sur ces parametres.
Le papier d'IBM est tres interessant a lire pour explorer le pourquoi du comment et les possibilites : http://www.research.ibm.com/remail/publications.html(...) , " THREAD ARCS: An Email Thread Visualization "
[^] # Re: hum
Posté par Nicolas Roard (site web personnel) . En réponse au journal Thread Arcs. Évalué à 3.
Une solution est de faire alors un classement par sujet... Par exemple avec mutt: http://www.jhweiss.de/img/mutt_index.png(...)
Et tu represente les relations entre les mails (qui a repondu a qui) par un arbre.
Le probleme c'est que si tu restes dans cette config, quand un nouveau mail arrive il n'est pas forcement visible de suite a l'ecran (car le classement est forcement different...). Donc la plupart des gens fonctionnent avec le classement par date; mais n'empech, avoir la visu arborescente est parfois bien pratique.
Les threadarcs permettent d'avoir cette visualisation, de facon plus efficace que le traditionnel arbre vertical (a la mutt), et de plus on peut continuer a avoir le classement par date (ou n'importe lequel) en plus.
Bref, on visualise bien mieux la conversation, et c'est plus efficace pour naviguer dedans.
Bien evidemment c'est surtout utile pour de longues conversations, souvent le cas si tu est abonne a des mailing-lists.
[^] # Re: C'est deja interdit, donc illegal.
Posté par Nicolas Roard (site web personnel) . En réponse au journal Il va être illégal de copier un CD sur son ordinateur ou son baladeur. Évalué à 2.
De deux ... les droits d'auteurs sur un CD sont minimes par rapport au prix du CD (quelques poucents), donc leur suppression aurait peu d'impact sur le prix final.
Et puis, même si ton idée était plausible, on peut facilement imaginer un scénario amusant ou les majors, arguant de "frais de traitement", ne toucheraient pas au prix du CD mais sucreraient au passage les droits d'auteur si le client indique qu'il dispose déja du CD ;-) (ce serait bien dans leurs manières)
[^] # Re: Petit probleme
Posté par Nicolas Roard (site web personnel) . En réponse au journal Photos confs RMLL .... Évalué à 2.
[^] # Re: Visuellement ca donne ca
Posté par Nicolas Roard (site web personnel) . En réponse au journal LSM / Bordeaux, informations du dedans ?. Évalué à 2.
[^] # Re: Pour ceux qui avaient encore un doute...
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Le Medef prend position pour les brevets logiciels. Évalué à 5.
[^] # Re: Merci
Posté par Nicolas Roard (site web personnel) . En réponse au journal Article WebObjects LMF + Sources + exemples. Évalué à 2.
[^] # Re: tant que j'y suis
Posté par Nicolas Roard (site web personnel) . En réponse au journal Article WebObjects LMF + Sources + exemples. Évalué à 2.
[^] # Re: Merci
Posté par Nicolas Roard (site web personnel) . En réponse au journal Article WebObjects LMF + Sources + exemples. Évalué à 2.
\begin{remarque générale}
Au fait, quand vous lisez des articles dans LMF, n'hésitez pas à écrire aux auteurs pour des conseils, remarques, questions ou autre. Très très peu le font, et du coup ce n'est pas forcément évident de savoir si on a fait un "bon" article que les gens apprécient ou un article nul ou qui n'intéresse personne... avoir un peu de feedback est utile ! :-)
\end{remarque générale}