Pinaraf a écrit 3682 commentaires

Cherche "hotmail avec thunderbird" dans google (sans guillemets)
et lis le premier lien qu'il trouve !

J'y ai cru...
Seulement, y'a un "détail" de LG3D qui fâche ces outils : c'est de l'OpenGL derrière !
Résultat : la petite démo que j'ai essayé de faire pèse 156Mo (c'est dur à compresser ça bouge tout le temps !), avec 2 frames affichées par seconde :(

Qu'est-ce-qui te dérange dans le fait que ça soit en Java ?
Qu'il n'y ait pas de JVM libre compatible Java 5 ? J'attend beaucoup de gcjx, qui sera intégré dans Gcc 4.1, et qui supportera les fonctionnalités de java 5. Maintenant, les classes nécessaires seront-elles toutes présentes ?

Je n'ai cité là que ce que j'ai déjà préparé sur papier.
Il est très difficile d'expliquer à quoi ressemblera une interface, particulièrement en 3D. De plus, je suis relativement à sec d'idées pour une interface 3D à un lecteur de mails... Je verrai ça quand j'aurai le temps ! (C'est hideya qui a insisté pour que je parle de ça, j'étais pas trop chaud au début.)
Mais rien qu'utiliser Looking Glass avec des applis 2D apporte quelques plus agréables, dont :
1- les thumbnails dans la barre des tâches (ça serait dispo pour KDE 3.5, à confirmer)
2- la possibilité de parquer les fenêtres et donc de voir toutes tes fenêtres en même temps : j'ai l'habitude de ne travailler qu'avec des fenêtres maximisées, pour moi Looking Glass apporte un vrai plus pour ça.

Tu peux te consoler sur la démo de Sun : http://www.sun.com/software/looking_glass/demo.xml(...)
Ça ne correspond pas à la réalité de looking glass actuellement, loin de là !
Tu as plus d'effets maintenant par exemple à l'ouverture / fermeture / réduction des fenêtres...
Les développeurs attendent beaucoup de java3d 1.4 pour faire plus d'effets. D'ailleurs LG3D influence le développement de Java3D.

Malheureusement, je n'ai pas de caméra numérique, et il m'est impossible de réaliser une capture vidéo : voir à ce sujet le journal sur la version 0.6.2, où l'on m'a indiqué quelques outils qui se sont tous avérés incapables de prendre une capture à plus de 2 images par seconde

Tu as vu juste...
Comme XP, c'est moi :)
La traduction du site de Looking Glass, c'est surtout moi !
J'ai mis dépêche dans la traduction : en fait, je prévois de faire une dépêche par version majeure (exemple : http://linuxfr.org/2005/01/22/18146.html(...) qui fut la première version de la branche 0.6) et un journal pour les versions mineures (exemple : http://linuxfr.org/~PieD/17843.html(...) pour la deuxième version de la branche 0.6)
D'ici juillet, y'aura la sortie de la version 0.7... Je vous tiendrai au courant ! Au programme : vitesse, stabilité, utilisation de Java3D 1.4 et donc des vertex shaders notamment...

Une intro à arthur : http://doc.trolltech.com/4.0/qt4-arthur.html(...) (ça roxorise moins que les démos qu'ils donnent)
À noter : on peut dessiner avec arthur sur des tonnes de choses : aussi bien un QImage qu'une imprimante :)

Ce qui manque à E pour être supporté par une boîte, c'est un intérêt commercial. Qt a un énorme intérêt, perso si je devais coder des applis proprios multiplateformes, j'hésiterais entre Qt4 et Java, avec une préférence pour la rapidité et la documentation de Qt ! Qt a une documentation, une grande simplicité dans ses API, une portabilité qui en font un produit au top pour la majorité des développeurs proprios, surtout ceux sous win qui ne veulent plus des MFC, et rechignent à utiliser un autre langage via .net ou java.
En plus Qt a une pub immense via KDE : trolltech montre KDE comme un exemple de ce qu'on peut coder avec Qt. Il y a un très bon comportement de leur part : Trolltech s'est comporté excellemment bien avec la communauté du libre, il y a de vrais échanges ! La communauté KDE influe sur le développement de Qt (y'a des développeurs de KDE qui bossent chez Trolltech), Qt aide énormément le développement de KDE, les développeurs de KDE rapportent et corrigent des bugs de Qt...

Concernant KDE, ils ont des grosses longueurs d'avance sur la majorité des desktop, et c'est pas trois effets minables de transparence à la superkaramba qui suffira pour qu'il change des parties majeures de KDE !
Ils ont besoins de librairies stables, complètes, disposant de bindings Qt si possible, avec une API en C++ sinon... De ce que j'ai vu, Edje et Evas ne peuvent apporter que des emmerdes à KDE. KDE 4 utilisera Qt4, qui explose sans problème Evas si j'en crois les démos d'arthur.

Ha, je ne savais pas... Merci pour la précision.
Sinon, famille API instable, n'oublions pas wine ! Les développeurs de mono en savent quelque chose pour leur windows.forms :)

Encore une fois, Raster n'a jamais prétendu qu'il supportait la véritable transparence
C'est pourtant ce qu'il laisse sous entendre !
[Seth] goes on to talk of "Alpha transparency whenever you want" - Done. Evas.
La transparence partout, ça inclut les fenêtres !
Pour la véritable transparence, c'est ce que j'ai dit plus haut à gnumdk je crois...

Pour travailler avec GL, ça ne me semble pas dur... Qt4 utilise superbement GL dans l'une de ses démos, et le code me semble très simple (beaucoup de listes de coordonnées, de composantes de couleurs...)

Mais quand tu dis Le projet EFL date de bien avant Xorg, Cairo. ça me fait sourire... Le premier code venant de X.org date d"avant 1999 (cf les dates des fichiers sur ftp://ftp.belnet.be/pub/mirror/ftp.x.org(...) par exemple), les extensions comme composite existaient avant X.org 6.8 mais n'étaient pas incluses par défaut... quand à Cairo, le début de son développement date de 2003 au plus tard (je me base sur les dates de fichiers du CVS de cairo, mais il doit y avoir des développements et plans antérieurs). Ces deux projets majeurs sont utilisables, et utilisés ! Mozilla utilise Cairo pour le rendu du SVG, de même entice l'utilise. X.org est utilisé par Looking Glass, KDE, GNOME... Pendant ce temps là, un groupe de 5 personnes codent dans leur coin des librairies qui sont déjà obsolètes alors qu'elles ne sont pas encore sorties, et ils comprennent pas pourquoi les gens s'y intéressent pas.

E17 ne supportera jamais le fake transparency ?
Hem hem !
http://pinaraf.robertlan.eu.org/opacity.png(...) : capture d'écran d'une appli d'E17, elapse, lancée sur mon KDE (ma session E17 merdouille)
Je peux te faire la même avec erss (leur lecteur de flux RSS), et tant d'autres.
C'est ça la fake transparency ! Ils ne peuvent pas avoir de vraie transparence, point barre. Sauf si ils ne la font que dans la fenêtre d'une appli, en l'occurence le bureau dans ses démos (le bureau est une fenêtre, oui oui... Enfin, utilisable tout comme quoi)
Mais si c'est de la vraie transparence ça, alors ça aussi ça en est ? http://sharewebnom.sourceforge.net/notes/test.html(...) (ne marche que sur un navigateur utilisant Gecko, car il y a du XUL/XBL dedans...)
Et je trouve le comportement de Raster complètement anormal vis à vis de Render : oui render est lent, mais plutôt que de rester dans son coin coder son truc pour lui tout seul pourquoi n'aide-t-il pas à l'amélioration des perfs ? Mais non, c'est mieux de laisser le boulot aux autres voyons (merci à Zack Rusin pour son boulot : http://www.kdedevelopers.org/node/view/978(...) Ça au moins ça aide tout le monde, et pas 5 applis sur toutes celles disponibles !)
Pour Gl : c'est stable chez moi, et chez beaucoup de gens vu le peu de problèmes à ce propos sur les forums... en tout cas, j'ai jamais eu de crash à cause de Gl, mes applis 3D marchent aussi bien en fenêtré qu'en plein écran...

Et pour info, E17 n'est pas encore sorti, l'API non stabilisée, aucune doc claire ne semble disponible. Mais les gens de fd.o devraient se précipiter dessus, l'utiliser, et passer au final plus de temps à utiliser les EFL qu'à utiliser les libs existantes ? Hé, l'affichage vectoriel sera dans gtk 2.8 en utilisant cairo, raster veut quand même pas qu'ils utilisent soudainement son toolkit en cassant toute forme de compatibilité avec les applis existantes, et sans être sûr que ça marchera encore dans 3 mois ? Pensez à mono et wine pour les windows.forms : l'instabilité de l'API de wine a poussé les devs de mono à tout recoder. Ils ont donc perdu du temps à cause de wine...

Une question, est-ce que à la sortie d'OSX les anciennes applis classic diposaient de la tranparence et de tout les effets OSX ?
Hum, certains effets oui comme les ombres réelles (pas un truc dessiné sur le fond d'écran comme dans E17), d'une barre de titre semi transparente... Mais je connais trop mal OS X. En tout cas sur Longhorn les applis classiques ont une thumbnail dans la barre des tâches, leurs fenêtres peuvent êtres parquées, y'a des effets sur la transparence, lors de la réduction des fenêtres, lors de leur fermeture...

Ce qu'il y a c'est que Rasterman a un comportement que je trouve complètement délirant, à se surévaluer, surévaluer son boulot, qui est certes important, mais ne mérite pas de remplacer sur le champ tout ce qui existe.
C'est du pur marketing ! Leur "real transparency" ne marche que pour leurs applis, et encore pas toutes apparemment (par exemple elapse ne le supporte pas). Je trouve que c'est honteux de la part d'un projet libre de partir dans un délire comme ça.
Moi aussi je peux faire une appli avec de la vraie transparence et tout... suffit de l'écrire en Javascript, avec du png qui roxorise derrière. mozilla support opacity (attribut CSS3) depuis longtemps, il bat tout le monde non ? Pourquoi personne ne veut l'utiliser pour faire un desktop alors ?

L'extrait de Renaud cité ici vient de la chanson "Miss Maggie", première chanson de l'album Mistral gagnant (1985).
C'est un poème dédié à toutes les femmes, sauf une : Margaret Thatcher.
Cette chanson a provoqué une énorme colère de l'autre côté de la manche :)
Les paroles complètes : http://www.sharedsite.com/hlm-de-renaud/discotheque/8miss_maggie.ht(...)

Mais c'est quoi cet engouement pour E17 ?
Technologiquement, E17 n'est même pas sorti qu'il est déjà dépassé ! La transparence n'existe pas dans E17 telle qu'elle est réalisable en utilisant Composite. Tous les effets d'E17 peuvent être faits en utilisant superkaramba !
De plus, les sacros saintes EFL sont mal documentées, leur API est instable... normal pour un truc en développement, mais comment voulez vous que ça apporte quelque chose à fd.o en l'état actuel ?
Et puis, il y a déjà cairo pour le canvas, les technos de X.org (composite...) pour la transparence. Avec rasterman qui dit "c'est sous performant j'en veux pas" plutôt que de se dire : "y'a un problème, je peux les aider à le résoudre" (très très intelligent comme comportement d'ailleurs), je vois mal une coopération avoir lieu.
Je crois beaucoup plus en l'avenir de Cairo, une progression paisible vers des standards... Pas en une arrivée d'un monstre, de surcroît en forme de cheval de Troie ! (ho regardez c'est tout beau tout mignon... Surtout ne cherchez pas la vraie transparence hein, y'en a pas donc j'évite de montrer cette absence dans mes screen videos)

Désolé pour le lien, j'ai pas fait gaffe :
http://pinaraf.robertlan.eu.org/opacity.png(...) marchera sans mot de passe :)

Tu serais pas comique sur les bords ?
Ton E17 il n'a pas de fenêtre transparente. Ton E17 il n'a pas de vraies ombres aux fenêtres !
Les ombres sont dessinées sur le fond d'écran par jenesais quel composant, les ombres ne passeront pas au dessus d'une autre fenêtre... Très très peu agréable esthétiquement parlant, à des kilomètres de Looking Glass (qui rame de moins en moins), MacOS X, LongHorn ou des effets dispos via composite
Les fenêtres transparentes ne PEUVENT PAS être effectuées sans utiliser composite ou une autre extension au serveur X ou un autre serveur X. J'ai débattu sur ça pendant une bonne heure hier avec un mec de #kde qui n'en démordait pas. Les devs d'E17 ont tranché : j'ai raison, il n'y a pas de vraie transparence.
Après si tu veux la transparence pourrave de E17 tu prends superkaramba : c'est la même méthode ! Pour info, un truc de E17 qui est """transparent""" (lancé sous KDE) : ftp://pinaraf@robertlan.eu.org/opacity.png(...)
Si ça c'est de la transparence...

Des patchs purement inutilisables dans Konqueror... Y'en a qui contiennent même de l'ObjC, c'est dire !

Heu
C'est normal de leur part qu'ils patchent gcc pour l'obj-c/c++ : ils l'utilisent et le fournissent avec leur MacOS X, et emploient ces langages !

Dans incorporation, tu peux mettre afficher dans konqueror par défaut (en mettant bien le service KHTML en premier)
Et dans l'onglet Général, tu peux mettre dans les applications ton firefox par exemple : comme ça, si tu veux ouvrir une page web dans firefox t'auras juste à faire un clic droit > ouvrir avec > firefox

Je me demande quelle distrib t'utilises qui soit assez mal foutue pour générer ce comportement...
Configuration > Configurer Konqueror
Associations de fichiers : tu cherches html. Dans l'onglet incorporation, tu sélectionnes Afficher le fichier dans Konqueror, et tu vérifies dans les services que KHTML est en premier...

J'ai rapporté le bug il y a quelques jours pour un copain, voici ce qu'on m'a répondu :
Please install the latest (1.1.1) version of FoxyTunes.

Je te remercie pour cette information...
Et de une alors :)

Le dossier /etc/rc.d n'existe pas, et il n'y a pas de fichier rc.local dans /etc ! :(