Ces bibliothèques sont à la base de la prochaine version du gestionnaire de fenêtres Enlightenment E17.
NdM : merci à Fanf pour avoir également proposé cette nouvelle. Bien que cette annonce ne concerne que les fondations d'Enlightenment, elle permet d'espérer le développement rapide de la nouvelle mouture du plus design des gestionnaires de fenêtres.
Le projet Enlightenment est connu pour la qualité de son Window Manager E, mais moins pour la puissance des outils conçus pour son développement. Les versions précédentes d'Enlightenment étaient basées sur la bibliothèque imlib, réputée alors pour sa flexibilité et sa rapidité.
Lors de son développement préliminaire, Enlightenment 0.17 (aka E17) a vu ses fonctionnalités améliorées et augmentées de telle sorte que de l'avis de ses auteurs, son statut est passé de celui de « Window Manager » à celui de « Desktop Shell ». Cette dénomination est justifiée par les nouvelles capacités d'interaction avec le système offertes par cet environnement graphique.
Durant sa phase de développement, les bibliothèques d'E17 ont été totalement réécrites, et alors que l'on pensait la sortie du Desktop Shell relativement proche, Rasterman, le leader du projet, a décidé de tout remettre à plat, considérant que l'architecture globale des fondations pouvait être améliorée.
Cette remise en question a donné naissance aux Enlightenment Foundation Library, désormais composées de (traduction sommaire):
- Ecore, une couche d'abstraction pour Xwindow et les évènements ;
- Edb, bibliothèque conçue sur Berkeley DB en charge de faciliter l'accès et la portabilité de données relatives à E ;
- Edje, en charge des tâches graphiques complexes ;
- Eet, bibliothèque dédiée à la prise en charge des opérations d'archivage et de compression ;
- Embryo, langage de script basé sur "Small Language" ;
- Emotion, offrant des capacités de prise en charge de la video basée sur libxine ;
- Epeg, pour la création ultra rapide de vignettes au format jpeg ;
- Evas API pour Xwindow capable d'offrir des capacités d'affichage supportant l'accélération hardware, l'alpha-blending, etc ;
- Imlib2, le successeur d'Imlib pour la manipulation d'images.
Aller plus loin
- Le site (5 clics)
- La nouvelle (2 clics)
- Les bibliothèques (3 clics)
# ELF rentrera-t-il dans la danse?
Posté par GhZaaark3 . Évalué à -4.
ça donnerait du sang neuf de plus
Gnome s'barre en vrille et est lourdeau pas possible
KDE3.2... moué j'n'ai rien contre lui il m'a même fort étonné il y a encore peu mais bon Qt, caî pa très bO (l'argument quoi! héhé)
E17, c'est beau, simple, et super pratique mais pas encore aussi complet
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par mansuetus (site web personnel) . Évalué à 1.
"environnement de bureau"
et un
"gestionnaire de fenêtre"
car je vois très mal la différence :/
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par Antoine Reversat . Évalué à 5.
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par GhZaaark3 . Évalué à 4.
Mais loin de moi l'idée de "troller" comme tu dis, en plus vous me saouler avec ce mot.
Non c'est une opinion nourrit par quelques expériences perso, ceci dit je ne nie pas que le problème puisse venir de moi...
Je voulais juste soulevé l'idée que E17 pourrait entrer, disons, dans un niveau supérieur tel celui de l'environnements de bureau ou desktop s'tu veux vu qu'il intégre à présent plus d'outils, qu'il dispose maintenant de sa propre interface utilisateur (j'utilise peut-être le mauvais mot là), d'un gestionnaire de fichier original etc etc.. .
qu'est-ce que vous en pensez?
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par beagf (site web personnel) . Évalué à 4.
What exactly do you mean by "E 17 will become a desktop shell?"
It means that E 17 combines features of a window manager and a file manager. It will provide nicely integrated GUI elements for managing your desktop elements, both files and windows. It does *not* mean that E 17 is another application framework like Gnome and KDE.
Donc E va devenir un gestionnaire de fenêtre, avec un gestionnaire de fichier intégré. Et il fournira en plus tout ce qu'il faut pour construire des interface qui s'integrerons parfaitement à l'environement.
Il faut entendre gestion de fichier au sens large, car il integrera notament un visualiseur d'image (qui est déjà fonctionel et magnifique)
Le tout etant themable à l'extreme.
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par 007 . Évalué à 0.
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par Temsa (site web personnel) . Évalué à 2.
car pour avoir programmé avec les EFL un petit peu, tu n'utilises que les EFL (ecore evenement awl/edje/evas pour l'affichage,imlib2 pour le traitement d'image si pas possible directement pas evas...)pour développer, tout comme je le ferais avec gtk/gnome ou qt/kde.
Les EFL, c'est vraiment un framework pour moi, donc j'aimerais connaître ta définition (j'ai cherché sur wikipedia us, et comme la reponse n'avais rien à voir, je ne mettrait même pas le liens ici)
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par 007 . Évalué à -1.
J'ai parlé de "grosses" applis. Tu peux toujours dire qu'on peut faire de "grosses" applis avec la libc et la libX11 mais je te souhaites du courage.
Les possibilités fournis par Gnome n'ont rien à voir avec E même si les EFL peuvent être suffisantes pour beaucoup d'applis.
> c'est vraiment un framework pour moi
Comme la libc. Mais j'ai parlé de grosses applis.
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par Temsa (site web personnel) . Évalué à 1.
Un gimp, un mplayer, un filemanager, c'est pas hyper compliqé a faire avec ces libs.
Un navigateur basé sur gecko ne me semble pas plus hors de portée...
En fait je vais pauser la question autrement:
Tu retrouves tout ce qu'il faut pour faire des applis d'un taille conséquente (y compris une base de données optimisée pour les settings et ce genre de choses), ca va du timer au widgets standards, à la gestion de thèmes, de font, d'image, la compression, en passant par les listes chainées et au canevas... tu veux quoi de si merveilleux qui est uniquement dans kde et gnome pour toi ?
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par 007 . Évalué à -2.
Pour les mêmes raisons que les nombreux développeurs gnome et kde :
- Ça bouffe de la place mémoire et ça utilise mon CPU dernier cri pour rien et j'aime ça.
- Ça me donne un côté décideur pressé qui fait craquer les filles.
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par GhZaaark3 . Évalué à 1.
On peut considèrer les EFL comme un framework, dés lors...
ça va être le pied, et on va avoir des themes terribles, optimisés et surtout facilement accèssibles pour le graphiste non codeur. Non pas que ça ne soit pas possible avec GTK ou QT, mais ça reste quand même chaud de faire un theme en natif...
+
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par 007 . Évalué à -1.
Rigolo. Il y a quelques années (j'ai plus testé E depuis un bon moment) c'était Enlightenment qui était "lourdeau pas possible" alors qu'il ne fesait "que" gestionnaire de fenêtre.
Pour les vrilles, je me demande quand E va nous faire une belle figure. Le délais entre release se chiffre en années maintenant...
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par Carpe Sébastien . Évalué à 10.
Que ce soit Gnome ou Kde, ils deviennent chacun de plus en plus lourd (avec un bémol pour KDE qui essaye de réduire les besoins matériels).
Ceci dit, c'est assez compréhensible, on peut difficilement faire tourner un browser, des outils bureautique et une pléïade d'applet sans que ça mange sur la RAM.
Personnellement, je suis développeur et j'utilise Eclipse. Mon PC n'a "que" 256 Mo de RAM, l'utilisation de desktop style gnome ou KDE est prohibitif sur ma config pour que j'en fait (ça swappe a mort). Sans compter que je n'utilise que peu des applications des desktops sus-sités. Actuellement j'utilise XFCE, et c'est très suffisant. au repos (sans rien de lancé), Il mange beaucoup moins qu'un gnome ou un kde ; et, au besoin, je peux toujours lancer evolution, konqueror, ou n'importe quelle autre application KDE/Gnome en cas de besoin.
Pour en revenir à E, je pense, vu le temps qui a été passé dessus, que les librairies de base seront de très bonne qualité et très efficaces (rasterman a toujours été très bon en X11), ce qui pourrait permettre de sortir un E17 "qui déchire sa race" + quelques outils annexes. Pour ce qui est de l'émergence d'un nouveau desktop sous Linux, je ne me fait pas trop d'illusion : E a 2-3 ans de retard, les développeurs potentiels ont tous été drainés par KDE ou gnome (à part quelques projets "marginaux" -xfce, rox, etc...-), alors l'avenir de E en temps que desktop, j'ai des doutes (l'histoire est pleine de programmes/librairie/environnement de qualité supérieure mis à la poubelle pour cause de manque de popularité). Reste que j'attend avec une certaine impatience le retour du WM qui reste clairement l'un des meilleurs, même après quelques années d'absence.
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par 007 . Évalué à -10.
Ça c'est une légende. Compares la place mémoire d'un Gnome 1.4 avec Gnome 2.6 (j'utilise pas KDE, donc je ne sais pas). Compares avec l'évolution du matériel et reviens ici pour un bilan...
> j'utilise Eclipse
Et tu oses dire que Gnome et KDE sont "lourds"...
En fait, j'en ai rien à foutre de ces "conneries", pleurnicheries.
Linux, la libc, Gnome/KDE, etc, etc, etc ont de plus en plus de fonctionnalités et bouffent de plus en plus de mémoire. Si ça ne plait il faut installer une distribution avec Linux 2.0.
Pour ma part, je n'ai pas l'intention de retourner sous Linux 2.0 et FVWM 2 avec un PC de 5 ans ou un PC de maintenant.
Qui ici utilise une vieille distribution (hors Debian :-)).
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par dcp . Évalué à 1.
Haaa bon....
Ben c'est pas Gnome ou KDE ou (rajouter_ n'importe_quoi_ici) qui pèse lourd alors....
Histoire de forker le Troll je vois pas trop l'intérêt de ses éditeurs...
Un bon shell UNIX, un emacs ou un vim, la pléthore d'outils UNIX (grep, find, sed, awk, tac, cut...) et on a un environnement de développement sans aucun équivalent...
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par kra . Évalué à 6.
sinon, les fonctionnalites de navigation dans le code (style sauter a la definition d'une variable/methode etc.. en faisant ctrl click), le refractor qui est tres puissant, la recherche des references a une variable/methode etc.. (et pas juste un grep -R monNomDeMethode bourrin)
bref, le seul defaut que je trouve a eclipse c'est la qualite de l'editeur de texte qui est plutot bof bof..
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par kra . Évalué à 5.
importation automatique des classes voulues, ecriture des squelettes des interfaces implementees, generation automatique des getters/setters, la foultitude de plugins (de totalement inutile a indispensable), la todo list bien pratique, la machine virtuelle lancee en permanence, on travaille avec des classes et non avec des fichiers.
Des editeurs de GUI, possibilite de lier la javadoc au code, navigation dans le code "a la browser" (alt gauche/droite pour se deplacer aux derniers points d'edition), completion automatique bien pratique quand on ne se rappelle plus trop des specifs des classes...
etc. etc. etc.
en fait, c'est comme le telephone portable, au debut, on se dit que ca sert a rien, pis apres on se rend compte que c'est quand meme 'achement utile.
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par Vincent Bernat (site web personnel) . Évalué à 3.
Et surtout, l'éditeur n'est pas "pourri", puisque c'est sa fonction première et cela me semble tout de même le principal. Le seul truc que tu n'auras pas, c'est l'éditeur de GUI.
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par kra . Évalué à 1.
apres, les gouts et les couleurs hein, chacun fait fait fait c'qu'il lui plait plait plait, mais qu'on vienne pas me dire qu'emacs n'est qu'un traitement de texte.
pitite question pour ma culture perso : est ce que la recherche de fonction etc.. est intelligente?
je m'explique sous eclipse, quand tu cherche une methode, il te retourne uniquement celles qui correspondent a la signature (ie: typeRetour Classe.nomMethode(args) ), et pas celle qui correspondent juste au nom (ie: autreType AutreClasse.nomMethode(args)
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par Vincent Bernat (site web personnel) . Évalué à 2.
Non, elle ne sait pas ce qu'est une signature. Cela dit, y'a un bidule proprio que l'on colle par-dessus emacs et qui sait alors faire des choses beaucoup plus fines. Je ne connais plus le nom.
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par Matthieu Lemerre (site web personnel) . Évalué à 1.
http://l-lang.org/ - Conception du langage L
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par Frederick Ros . Évalué à 2.
> plait plait, mais qu'on vienne pas me dire qu'emacs n'est qu'un
> traitement de texte.
Arghh .. Emacs n'ext *pas* un traitement de texte. Emacs est un editeur de texte extensible .. Il s'appuie sur des outils exetrnes pour augmenter ses possibilite (pour les tags par exemple) .. Comme le fait vim et certains autres ...
> pitite question pour ma culture perso : est ce que la recherche de
> fonction etc.. est intelligente?
> je m'explique sous eclipse, quand tu cherche une methode, il te
> retourne uniquement celles qui correspondent a la signature (ie:
> typeRetour Classe.nomMethode(args) ), et pas celle qui
> correspondent juste au nom (ie: autreType
> AutreClasse.nomMethode(args)
Non .. mais ECB doit le faire. Il s'agit d'un package poru Emcas qui le transforme en "IDE" .. Il est apparamment vraiment pas mal pour peu que l'on fasse du C/C++ ou du Java. On peut bien sur lui ajouter de nouveau langage mais il faut alors s'investir un peu ...
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Non. Eclipse est à Emacs ce que Emacs est à vi, ou même ed. Ce n'est pas *du tout* le même niveau de fonctionalités.
Mais tu n'apprécies les features d'Eclipse que lorsque tu travailles sur un projet Java sufisamment gros (disons plus de 10KLOCS), en dessous la lourdeur d'Eclipse te pénalise plus qu'autre chose.
C'est un débat récurrent ici, chaque fois que quelqu'un parle d'Eclipse ou d'un autre IDE du même genre (Intellij Idea par ex.) il y en a un pour sortir la liste des modules Emacs qui "font tout pareil". C'est souvent comique (bravo pour le 'M-x make' pour la compil à la volée, très réussi), et la personne qui s'y colle ne connait évidemment pas du tout Eclipse (et à peine Emacs).
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par Gawan . Évalué à 2.
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par kra . Évalué à 1.
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par dcp . Évalué à 4.
M-x make sous Emacs
! make sous vim(ou vi)
fonctionnalites de navigation dans le code
etags et ctags sous emacs ou sous vim
Voir aussi l'excellent taglist sous vim (source browser pour C, C++, Java, ...)
http://www.geocities.com/yegappan/taglist/images/taglist_java.gif(...)
Bon, ceci dit je m'enflamme pas, hein !
Chacun utilise ce qu'il veut :-)
Ce que je dis juste, c'est que les "gros éditeurs tout intégré", ne font généralement que reprendre ce qui existe déjà à coté.
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par kra . Évalué à 1.
l'avantage est d'avoir tout deja integre et de pas avoir a chercher ce qui pourrait convenir.
mais bon, les gouts et les couleurs, hein, c'est po qqchose qui se discute..
sinon, pour la compilation a la volee, c'est a la volee, ie pas de meta chose a taper, ca se fait tout seul : tu sauve ton fichier et la compile se fait toute seule en arriere plan sans que t'ai rien a demander, je te garantit que c'est vraiment confortable..
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par Jean-Baptiste Mayer . Évalué à 4.
Non, ça c'est de la compilation incrémentale.
La compilation à la volée d'eclipse c'est comme le correcteur orthographique de Word et consorts: il compile au fur et à mesure que tu tapes, et il te souligne les erreurs de compilation en rouge :)
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par SoWhat . Évalué à 1.
Je crois que c'est ce qui m'a le plus énervé quand j'ai essayé de l'utiliser! Ca doit pouvoir se désactiver, mais les fichiers de configurations en xml disséminés un peu partout sont un peu confus pour moi. Le xml c'est bien mais c'est pas très lisible (ceci dit, un fichier de conf emacs c'est encore pire: il faut apprendre le lisp avant de faire quoi que ce soit...)
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par Keos . Évalué à 2.
Pourquoi diable t'embetes tu a aller trifouiller du xml alors que Eclipse possede une interface de config. ( lisible pas comme le XML ).
En plus tu ne peux pas manquer cette option, elle est dans le premier paneau (Workbench).
Comment c'est deja la pub de Ducros qui se decarcasse ? :o)
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par syj . Évalué à 0.
Rasterman justifiait cette consommation car il préferrait sacrifier de la mémoire, afin pré-calculer certaine opération et ainsi décharger le CPU.
Car à l'époque et c'est tjs vrai, l'augmentation de la mémoire d'un PC coûte bien moin cher que l'augmentation de la fréquence d'un CPU.
Je n'ai pas reussi à retrouver l'article sur Google.
Qui se rappelle de l'époque de E14 et E15 qui était recommandé uniquement pour les Workstations Alpha de Digital ou les très gros PC de l'époque. Je dois même encore avoir le Dream qui en parle. C'est peut être sur cette revu que j'avais lu cette interview d'ailleur.
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par Temsa (site web personnel) . Évalué à 2.
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par Julien Portalier . Évalué à 4.
Et pour le général, mon desktop lancé sous GNOME comparé à la consommation avec E16, ça n'a rien à voir ^^
Pour ce que j'ai pu voir des EFL, ça a l'air d'être vraiment le plus optimisé possible (comprendre léger, rapide, réactif tout en étant efficace et sans sacrifier au eye candy). Suffit de voir epeg par exemple. Sachant que E17 est conçu à la base pour tourner aussi bien sur un tout petit PDA que sur un gros desktop, c'est prometteur ^^
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
J'ai des souvenirs de discussions avec Raph Levien ou Havoc Pennigton qui n'étaient pas exactement de cet avis :-). Mais c'était il y a longtemps (vers 99 ou 2000), il a pu changer depuis.
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par errno . Évalué à 0.
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par oliv . Évalué à 3.
Un gestionnaire de fenêtres, un gestionnaire de fichier, des applis simples (visualiseur d'images,éditeur de texte, outils de configurations, etc.).
Ceci dit, il n'y a pas que Gnome et KDE dans la vie (je partage +/- ton avis sur ces 2 là). Rox est vraiment impressionant sur une petite machine. XFCE aussi (si on remplace son gestionnaire de fichiers par Rox-Filer ;) ).
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par Julien Portalier . Évalué à 3.
Et encore plus sur une "grande" machine ^^ Perso je n'utilise que lui pour manipuler mes fichiers. Sachant qu'en plus il respecte de plus en plus les standards de freedesktop, c'est le navigateur de fichier par excellence je trouve.
Bon, certes je ne serai pas contre le même mais architecturé autour des EFL ^^
# Xwindows
Posté par dinomasque . Évalué à -5.
BeOS le faisait il y a 20 ans !
[^] # Re: Xwindows
Posté par dinomasque . Évalué à -4.
le temps de poster mon message mesquin la brève a été corrigée.
BeOS le faisait il y a 20 ans !
# Accélération graphique matérielle
Posté par philou (site web personnel) . Évalué à 4.
[^] # Re: Accélération graphique matérielle
Posté par Carpe Sébastien . Évalué à 3.
E sera beau. L'équipe de dev a quelques compétences en terme de graphisme, alors u peux être sur que ce sera beau.
Et on peut compter sur Rastermen pour faire en sorte qu'il soit le plus rapide possible. Après, faudra voir à l'utilisation, mais tu peux être certain que ce sera efficace.
Actuellement, la seule chose qui m'empèche de remettre un bon vieux E16 à la place de mon desktop actuel, c'est qu'il faudrait que je me retape les fichiers de config texte à la main -avec leur syntaxe proprio-, et j'ai pas le courage (ni le temps, d'ailleurs).
[^] # Re: Accélération graphique matérielle
Posté par Homer . Évalué à 4.
[^] # Re: Accélération graphique matérielle
Posté par tgl . Évalué à 2.
[^] # Re: Accélération graphique matérielle
Posté par Temsa (site web personnel) . Évalué à 1.
De plus il est possible de "scripter" directement pas mal de choses, graphiquement, rien qu'a partir de edje (enfin du fichier de thème si tu préfères)
[^] # Re: Accélération graphique matérielle
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
[^] # Re: Accélération graphique matérielle
Posté par Temsa (site web personnel) . Évalué à 2.
à comparer avec la transparence du nouveau E16.7 qui est touts de même moins réactive (mais très jolie :D )
[^] # Re: Accélération graphique matérielle
Posté par Temsa (site web personnel) . Évalué à 4.
oui, tu as quelquechose d'hyper réactif et d'hyper beau. C'est pour ça que je dis souvent que pour moi EFL/E17 c'est LA révolution du desktop telle qu'on le connais...
[^] # Re: Accélération graphique matérielle
Posté par snt . Évalué à 3.
[^] # Re: Accélération graphique matérielle
Posté par sweafty (site web personnel) . Évalué à 2.
Par exemple : http://atmos.org/view/edjes/shots/creepy_engage.png(...)
atmos est l'un des 2 dvppeurs de entrance (le gestionnaire de connexion graphique pour e17). Le site de entrance est hébergé chez son crétateur à savoir xcomp sur http://xcomputerman.com.(...)
Perso j'ai essayé entrance et engage et j'ai vraiment été bluffé par la qualité de ces 2 softs. Les animations dans entrance sont tout simplement sublimes, c'est dommage ca se voit pas sur les screenshots, fo le voir pour le croire :) Ca promet !!
j'ai fait un petit shot de mon entrance : http://base-art.net/static/entrance2.png(...)
# Intégration aux nouveaux projets
Posté par mickabouille . Évalué à 5.
Maintenant qu'elles ont pris un peu d'age et de corps, où en est EFL là dessus?
[^] # Re: Intégration aux nouveaux projets
Posté par Temsa (site web personnel) . Évalué à 1.
Je me demande même si on les verra pas un de ces jours débarquer aussi sous Windows...
# et xcl/xcb?
Posté par Maclag . Évalué à 1.
[^] # Re: et xcl/xcb?
Posté par Maclag . Évalué à -1.
# Intégration avec KDE et/ou Gnome ?
Posté par Ontologia (site web personnel) . Évalué à 1.
C'est vraiment dommage car un desktop KDE "classique" avec E16 comme gestionnaire de fenêtre doit être assez génial (j'a jamais essayé, car jamais trouvé où était le fichier de conf de KDE à ce sujet), ne serait-ce que la possibilité de voir une réelle minitature de ses différentes fenêtres dans les différents bureaux afin de reconnaitre du premier coup d'oeil où est telle ou telle (lorsque l'on a 15 fenêtre cela arrive vite...)
Bref quid de KDE avec un gestionnaire de fenêtre valable (terme totalement subjectif) ?
(je ne parle pas de Gnome je ne l'utilise plus depuis 2 ans, mais on peut se poser la même question)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Intégration avec KDE et/ou Gnome ?
Posté par Homer . Évalué à 2.
Si par un malheur sans nom (dont je doute), quelque chose rendait E17 inutilisable avec gnome, reste toujours que l'on peut se servir de l'EFL (c'est fait pour), et donc toutes les applis de qualité qui en découlent.
Si c'est juste pour le pager, il y aura surement moyen d'en écrire un qui soit compatible avec les bureau de gnome. Mais par exemple, je n'ai qu'un bureau gnome, mais plusieurs avec ion. Et pout autant ion s'intègre trés bien avec gnome.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.