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)
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...
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...
Alors, je ne fais que lister (sans retester) : la glib (version 1.2.10), monkey-bubble et SDL
Je sais c'est peu... Mais j'ai pas testé sur tous les paquets du monde !
Actuellement, debian stable utilise gcc 2.95
La plupart des distributions utilisent gcc 3.2 ou 3.3...
Quand est-ce-que toutes les distributions utiliseront gcc 4.0 par défaut ? D'ici 3 ans, histoire que gcc 5.0 soit là avec d'autres "strictitudes" en plus ?
Parce que trop d'applications ne compilent pas avec gcc4, et certaines ne passent même pas sur gcc3.4 ! Quand toutes les distribs utiliseront gcc4, toutes les applis seront "obligées" de compiler dessus...
Mais d'ici là, comment feront ceux qui font une LFS et qui veulent compiler plus vite (et profiter de -fvisibility) ? Patcher tous les programmes pour ça est tout sauf marrant !
À noter : les mdbtools sont surtout utiles pour transférer les données de la "base" access sur une vraie base de données (sqlite, postgresql ou même mysql). En effet, le support en écriture n'est pas très stable (d'après leur site, j'ai pas testé)
Tu crois n'avoir que 3 utilisateurs sur ta machine ?
Y'en a bien plus il me semble !
postgres est un utilisateur "système", disposant de droits restreints à certains dossiers particuliers.
Tu peux néanmoins chercher les fichiers de configuration de postgresql (ils sont dans /etc), le choix de l'utilisateur doit être dedans
De même que sous windows, tu dois lancer postgresql par un service et pas en lançant directement postmaster !
Je ne suis plus sous mandrake, mais il me semble que dans le centre de contrôle mandrake tu trouveras un outil de gestion des services (dans Système) : depuis cet outil, tu pourras facilement lancer postgresql, et c'est lui qui s'occupera de pas mal de "détails"
[^] # Re: linux vers mac os x
Posté par Pinaraf . En réponse au journal Tiger vient de sortir. Évalué à 2.
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.
[^] # Re: linux vers mac os x
Posté par Pinaraf . En réponse au journal Tiger vient de sortir. Évalué à 2.
Sinon, famille API instable, n'oublions pas wine ! Les développeurs de mono en savent quelque chose pour leur windows.forms :)
[^] # Re: linux vers mac os x
Posté par Pinaraf . En réponse au journal Tiger vient de sortir. Évalué à 1.
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.
[^] # Re: linux vers mac os x
Posté par Pinaraf . En réponse au journal Tiger vient de sortir. Évalué à 1.
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...
[^] # Re: linux vers mac os x
Posté par Pinaraf . En réponse au journal Tiger vient de sortir. Évalué à 2.
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...
[^] # Re: linux vers mac os x
Posté par Pinaraf . En réponse au journal Tiger vient de sortir. Évalué à 2.
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 ?
# Renaud
Posté par Pinaraf . En réponse au journal Violence routière. Évalué à 6.
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(...)
[^] # Re: linux vers mac os x
Posté par Pinaraf . En réponse au journal Tiger vient de sortir. Évalué à 1.
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)
[^] # Re: linux vers mac os x
Posté par Pinaraf . En réponse au journal Tiger vient de sortir. Évalué à 3.
http://pinaraf.robertlan.eu.org/opacity.png(...) marchera sans mot de passe :)
[^] # Re: linux vers mac os x
Posté par Pinaraf . En réponse au journal Tiger vient de sortir. Évalué à 3.
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...
[^] # Re: Pas encore ca avec Konqueror
Posté par Pinaraf . En réponse à la dépêche David Hyatt fait passer le test Acid2 à Safari et contribue à Konqueror. Évalué à 3.
[^] # Re: Alors...
Posté par Pinaraf . En réponse à la dépêche David Hyatt fait passer le test Acid2 à Safari et contribue à Konqueror. Évalué à 4.
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 !
[^] # Re: types mime
Posté par Pinaraf . En réponse au message Khtml SANS konqueror !!!. Évalué à 2.
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
# types mime
Posté par Pinaraf . En réponse au message Khtml SANS konqueror !!!. Évalué à 6.
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...
# connu ?
Posté par Pinaraf . En réponse au message Bug Foxytune || amarok. Évalué à 2.
Please install the latest (1.1.1) version of FoxyTunes.
[^] # Re: Une réponse sur deux
Posté par Pinaraf . En réponse au message Je veux une touche... Ou un clavier multimédia fonctionnel sur KDE !. Évalué à 2.
Et de une alors :)
[^] # Re: Une réponse sur deux
Posté par Pinaraf . En réponse au message Je veux une touche... Ou un clavier multimédia fonctionnel sur KDE !. Évalué à 2.
[^] # Re: À quand son utilisation partout ?
Posté par Pinaraf . En réponse à la dépêche Sortie de GCC 4.0. Évalué à 2.
pouf pouf
[^] # Re: À quand son utilisation partout ?
Posté par Pinaraf . En réponse à la dépêche Sortie de GCC 4.0. Évalué à 2.
Je sais c'est peu... Mais j'ai pas testé sur tous les paquets du monde !
[^] # Re: À quand son utilisation partout ?
Posté par Pinaraf . En réponse à la dépêche Sortie de GCC 4.0. Évalué à 5.
Pour moi, strict n'est pas vraiment négatif, surtout dans le cas d'un langage de programmation
# À quand son utilisation partout ?
Posté par Pinaraf . En réponse à la dépêche Sortie de GCC 4.0. Évalué à 4.
La plupart des distributions utilisent gcc 3.2 ou 3.3...
Quand est-ce-que toutes les distributions utiliseront gcc 4.0 par défaut ? D'ici 3 ans, histoire que gcc 5.0 soit là avec d'autres "strictitudes" en plus ?
Parce que trop d'applications ne compilent pas avec gcc4, et certaines ne passent même pas sur gcc3.4 ! Quand toutes les distribs utiliseront gcc4, toutes les applis seront "obligées" de compiler dessus...
Mais d'ici là, comment feront ceux qui font une LFS et qui veulent compiler plus vite (et profiter de -fvisibility) ? Patcher tous les programmes pour ça est tout sauf marrant !
[^] # Re: ODBC
Posté par Pinaraf . En réponse au message Accès à une base Access (MDB) sous Linux. Évalué à 3.
[^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
Posté par Pinaraf . En réponse au message problème avec postgres. Évalué à 2.
Y'en a bien plus il me semble !
postgres est un utilisateur "système", disposant de droits restreints à certains dossiers particuliers.
Tu peux néanmoins chercher les fichiers de configuration de postgresql (ils sont dans /etc), le choix de l'utilisateur doit être dedans
[^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
Posté par Pinaraf . En réponse au message problème avec postgres. Évalué à 2.
(Tu peux soit utiliser l'assistant de mandrake, soit la commande adduser postgres)
# Pourquoi faire simple quand on peut faire compliqué ?
Posté par Pinaraf . En réponse au message problème avec postgres. Évalué à 3.
Je ne suis plus sous mandrake, mais il me semble que dans le centre de contrôle mandrake tu trouveras un outil de gestion des services (dans Système) : depuis cet outil, tu pourras facilement lancer postgresql, et c'est lui qui s'occupera de pas mal de "détails"