Il y a de cela quelques jours, l’un des membres de l’équipe française d’Enlightenment, Jonathan Atton, a lancé dans les journaux de LinuxFr l’idée d’une interview des membres français du projet Enlightenment.
Pour répondre à cette série de questions, nous nous sommes concertés, Cédric Bail (développeur EFL), Philippe Caseiro (président de l’association e.fr) et Jonathan Atton (développeur d’applications utilisant les EFL), pour vous faire une réponse unique qui révèle notre point de vue en tant qu’équipe.
Certaines questions auraient mérité une réponse bien plus longue, mais nous ne voulions pas nous attarder trop dans des détails. Mais si vous voulez des précisions ou avez d’autres questions, n’hésitez pas à les poster en commentaire, nous y répondrons avec plaisir ! Et nous vous rappelons que nous organisons ce samedi une journée de présentation des EFL en région parisienne (à Montrouge) ; si vous êtes intéressé, il reste encore un peu de place !
fredix : E17 en version stable c’est pour quand ?
Enlightenment France :
When it’s ready. :-D Plus sérieusement, les releases sortent lorsque les todo lists sont vides et lorsque tous les bugs connus sont corrigés, ce qui n’est pas encore le cas de E17 ; en conséquence, les patches sont les bienvenus. Vous pouvez trouver toute la TODO pour E17 à cette adresse : http://trac.enlightenment.org/e/wiki/Release. En plus du code et des graphismes, vous pouvez également soutenir le projet en adhérant à l’association, ou en nous aidant à organiser des évènements / présentations du projet.
Psychoslave : Qu’est‐ce qui rend si long le développement des EFL/E17 ?
Enlightenment France :
Le design nouveau d’un pipeline de rendu pour un toolkit graphique. Le niveau d’attente élevé pour ce nouvel environnement de développement complet qui implique une qualité de code, une très forte optimisation et une grande portabilité. Le tout, sans implication d’industriels pendant de nombreuses années, et avec de nombreuses réécritures pour obtenir un résultat qui nous convienne.
Psychoslave : Si c’est le manque de contributeurs, des idées sur le pourquoi de ce manque ?
Enlightenment France :
Avoir plus de contributeurs de qualité est difficile et prend du temps. Et la tâche à accomplir étant colossale, elle en rebute ou en décourage plus d’un. Surtout qu’on n’hésite pas à réécrire et à jeter du code qui ne convient pas par rapport aux objectifs : faire quelque chose de léger, beau et fluide. Il faut avoir le cœur bien accroché pour participer à un tel projet libre. Aujourd’hui la communauté Enlightenment grossit tranquillement et gentiment en se retrouvant dans ces objectifs.
Psychoslave : Constatez‐vous une recrudescence d’utilisateurs depuis la stabilisation des EFL ? Et le cas échéant, peut-on s’attendre à plein d’applis ?)
Enlightenment France :
L’augmentation des contributions a surtout commencé lorsque nous avons commencé à communiquer, participer à des évènements et aussi lorsque l’attrait pour le monde de l’embarqué a commencé à exploser. La release n’est finalement qu’une étape logique pour pérenniser les efforts de la communauté et nous espérons que cela aidera à son élargissement. Même si, pour l’instant, c’est surtout l’implication forte de Samsung que nous remarquons.
Psychoslave : Les EFL c’est super optimisé, OK, mais côté accessibilité, est‐ce autant top moumoute ?
Enlightenment France :
Pour le coup, l’accessibilité, c’est vraiment un truc très GNOME au final, et ils ont fait beaucoup de travail dans ce domaine. Les EFL sont découpées en différentes bibliothèques, et de notre point de vue la problématique de l’accessibilité est quelque chose qui vient se mettre par dessus l’ensemble, donc indépendant. Personne ne travaille actuellement sur le sujet, et il y a encore beaucoup de travail avant d’arriver au niveau de GNOME.
Xavier Dumont : Enlightenment facile à configurer, c’est pour quand ?
Enlightenment France :
C’est le cas depuis longtemps, même si les problématiques d’ergonomie n’ont malheureusement pas trop été abordées pour l’instant. L’exemple qui montre vraiment qu’on peut maintenant repenser différemment les interfaces de configuration, c’est le module de définition du fond d’écran, qui est, dans sa version 2, nettement plus joli, dynamique et simple à utiliser. Mais, convertir des boîtes de dialogue classiques vers quelque chose de vraiment différent prend beaucoup de temps, surtout du point de vue de la réflexion et du design. Donc, il n’y aura pas trop de travail, malheureusement, dans la release à venir sur ce sujet. Maintenant, si quelqu’un vient juste pour nous filer un coup de main sur le sujet, on sera très heureux de recevoir son aide !
Note : on reproche souvent à E17 d’avoir des fichiers de configuration binaires qui ne peuvent être modifiés par un être humain. C’est faux, il suffit d’utiliser eet pour les convertir en format lisible par un humain, de les éditer avant de les réinjecter dans la configuration de E17.
Xavier Teyssier : J’ai cru comprendre que les EFL sont embarquées dans certains matériels, tels que la Freebox. Avez‐vous des retours (rapports de bogues, patches, etc.) de la part des sociétés intégrant ainsi ces bibliothèques ?
Cédric Bail, pour EF :
Eh bien, j’ai travaillé pendant environ 5 ans chez Free et je suis devenu un des contributeurs principaux des EFL. La communauté autour des EFL est très vivante et les entreprises qui l’utilisent, se rendent vite compte qu’il est facile de faire rentrer un patch qui leur permet d’éviter un horrible hack et de la maintenance problématique de leur coté. De plus, les bibliothèques étant bien isolées, il est assez facile de rentrer dans le code et de pouvoir justement fournir une solution au problème. Cela évite nettement le comportement qui peut arriver avec d’autres toolkits où les gens qui écrivent des applications passent leur temps à contourner le problème dans le toolkit, plutôt que de le régler une fois pour toutes.
Juke : Cédric, va-tu continuer à maintenir Elixir ?
Cédric Bail :
À titre personnel, j’ai quelques projets autour d’Elixir, peut‐être des choses sympas sur le sujet en perspective. Maintenant, tout dépendra de si j’ai le temps. :-) Et puis, on n’est jamais à l’abri que quelqu’un d’autre reprenne ce projet…
Laurent Pointecouteau : Ça donne quoi le projet Elixir, pour faire des jeux compatibles Freebox ? Quelqu’un ici en a‐t‐il tâté ? On peut faire des bons trucs avec ? Est‐ce toujours d’actualité avec la nouvelle Freebox Revolution ? Parce que, bon, un système genre XNA qui permettrait de faire des jeux rapidement pour un engin de salon, ça serait cool, vous ne pensez pas ?
Cédric Bail :
Les EFL sont construites autour d’un pipeline graphique similaire à celui d’un jeu. C’est de là que vient sa performance. Maintenant, ce n’est pas tout pour faire un SDK, et le JavaScript permet d’apporter une touche de simplification au‐dessus de cet environnement. Bien entendu, XNA est bien plus complet et fournit beaucoup d’aide pour le développeur, mais les moyens en jeu ne sont pas les mêmes.
Astaoth : Est‐ce qu’un portage vers Windows / ReactOS est prévu ?
Enlightenment France :
Il n’y a pas aujourd’hui de release 1.0 sur Windows, mais Vincent Torri, le principal développeur du portage Windows, fait un boulot absolument phénoménal et il appréciera facilement de l’aide ! Aujourd’hui, tout ce qui va jusqu’à Evas et Ecore_Evas fonctionne ! Ce qui permet de faire une interface avec Elementary. Il manque la gestion du réseau, dont le portage est en cours, et la gestion des threads qui arrivera par la suite. Mais il est vrai qu’on a majoritairement des développeurs sous Linux et des utilisateurs sous différents Unix, et très peu d’utilisateurs Windows… Ne connaissant pas trop ReactOS, je ne peux que présumer que si cela fonctionne sous Windows, cela fonctionnera aussi sous ReactOS.
Mornik : Est‐il possible de faire un script Shell qui utilise les EFL, comme on peut le faire avec « kdialog » ? Par où commencer ?
Enlightenment France :
Shellelementary est là pour ça, mais aucun membre de Enlightenment France ne l’a jamais utilisé. Tu nous feras un retour à l’occasion !
Mornik : Est‐il possible de faire une interface graphique en EFL et le corps du programme en Java (comme Qtjambi pour Qt) ?
Enlightenment France :
Non, personne n’a pris le temps de faire un binding Java. Par contre, il y a un binding Mono en cours de développement.
Sifu : Est‐ce que les EFL sont aussi accessibles que GTK ou Qt pour faire des petites GUI ?
Englightenment France :
Il y a effectivement de très grosses différences avec GTK ou Qt. Tout d’abord, et ça, il ne faut pas nous mentir, Elementary, la bibliothèque de widgets des EFL, est très loin d’avoir le niveau de finition de GTK ou Qt. Et il est vraisemblable que lors de l’écriture d’une application, il soit nécessaire d’améliorer Elementary aussi.
Ensuite, le point qui restera toujours différent, c’est que la manière de construire une interface avec les EFL ne se fait pas en mettant des widgets dans des tables, des box et autres conteneurs spécialisés. Mais en utilisant Edje et en construisant l’interface autour plus d’un « story board » d’un dessin papier de ce que vous voulez qu’elle devienne. Ça demande de bien penser dès le départ la séparation entre la logique de l’application et l’interface graphique. Cela rend l’écriture de certaines applications plus compliquée et d’autres plus simple, typiquement les applications multimédias sont plus faciles à réaliser.
Aller plus loin
- Le journal à l’origine des questions (162 clics)
- Enlightenment France (545 clics)
- Enlightenment (255 clics)
- Présentation des EFL (217 clics)
# Très intéressant
Posté par Tanki . Évalué à 9.
Tournant sous Enlightenment DR17 depuis quelques années (5-6 ans) je suis, à chaque mise à jour (environ tous les 500 commits), toujours content de constater qu'il y a peu ou pas de régression (et ça c'est bien)
cependant je trouve que les tickets mettent du temps à être corrigés (ex : Ticket 215 qui traîne depuis pfiou ! 20 mois) surtout que la fonctionnalité était présente jusqu'à la disparition de enlightenment_remote
alors on va me dire :
- oui ben, t'as qu'a le corriger !
et moi je vais répondre :
- oui ben, je suis pas codeur, désolé
Ma question donc :
Pourquoi ne pas avoir remis en place les fonctionnalités autrefois présentes avec Enlightenment_remote lors de la disparition de ce dernier ?
ou alors j'ai loupé un truc mais à ce moment là j'aimerai bien que l'on m'explique
Quoi qu'il en soit, jamais je quitterais E17, c'est trop bien, trop beau, trop parfait, donc c'est trop cool (pardonnez mon enthousiasme)
[^] # Re: Très intéressant
Posté par cedric . Évalué à 6.
Alors enlightenment_remote n'a pas disparu, il existe toujours sauf que aujourd'hui, le code est nettement plus maintenable grace a l'utilisation de dbus. Le probleme, c'est que seul les fonctionnalites qu'utilisaient les devs ont ete remise dedans... Et c'est un peu pas de chance pour ton utilisation. Et ton ticket tape exactement la ou le bas blesse dans E17, les interfaces de config pas vraiment ergonomique.
Le fait est aussi, qu'on a tendance à ne pas regarder souvent le bug tracker. Perso, c'est quand je recois les mails du bug tracker que je regarde si je peux le fixer vite fait, si ce n'est pas possible, souvent je n'y reviens pas... Et ca, c'est tres mal. Donc je conseille de refaire un petit ping sur le bug tracker de temps en temps pour demander ou ca en est. Ca reenverra d'ailleur un mail a tous les devs augmentant d'autant la possibilite qu'ils s'en occupent :-)
[^] # Re: Très intéressant
Posté par Tanki . Évalué à 4.
Ok pour enlightenment_remote, je crois que je l'avais vu, mais la pauvreté des actions possibles avec celui ci me laissait penser qu'il y aurait des cliclic bidules pour remplacer les supers trucs qu'il y avait avant.
Pour ce qui est des interfaces de configuration ergonomiques, franchement, par rapport à E16, les configs sous E17 sont un vrai miel
Pour le bug tracker j'avais posté un ticket (le #734) pour Efm (moi j'aimerais bien que ce soit comme rox mais en efl) et j'avais mis un petit mot pour le ticket #215
ça a été pris en compte par raster, après il faut que le temps fasse son boulot
Quoiqu'il en soit, franchement les mecs si j'avais un quelconque talent de codeur je passerai mes soirées à vous aider, mais je suis mauvais, même en html j'oublie comment on fait un tableau ( ou ?? je connais la réponse, bien sur, c'est 42) et le php j'ai oublié...
En tout cas, continuez, vous êtes sur la bonne voie, et quand je montre ma machine à des gens et qu'ils regardent mon Desktop, ben ils font une drôle de tête en général, et ça c'est bien :)
en un mot : MERCI
[^] # Re: Très intéressant
Posté par dest . Évalué à 5.
Avoir des contributeurs qui ne font pas de dev c'est aussi appréciable. Ca permet d'avoir un oeil différent sur les projets et leur utilisation. Je ne suis pas impliqué dans E et ses EFL mais tu peux participer comme tu sembles le faire déjà : bug tracker, documentation, nouvelles idées, aider les utilisateurs sur les forums, irc, ...
[^] # Re: Très intéressant
Posté par cedric . Évalué à 2.
Tout a fait d'accord, il n'y a pas que le code qui compte. L'organisation d'evenenement, de rencontre physique ou de maniere generale juste parler du projet, c'est deja aider et ca compte beaucoup dans la vie d'un projet de logiciel libre !
# Un peu d'histoire
Posté par drakmaniso . Évalué à 10.
C'est amusant de constater l'évolution des différents projets de desktop/wm… Je me souviens d'un commentaire d'un ami lors des premières version d'Enlightenment:
«c'est super Enlightenment, mais ça marche qu'avec un bi-proc.
- ???
- Un proc pour faire tourner le WM, et un autre pour le reste du système et tes applis…»
À l'époque le projet était la définition même du eye-candy, et très peu de machines pouvaient le faire tourner correctement. Aujourd'hui il serait plutôt le chantre d'un certain minimalisme (techniquement parlant), et l'optimisation semble être une des principales préoccupations.
Qui se souvient qu'à ses débuts, Gnome se promettait d'apporter une approche Unix au desktop − une collection d'outils simples et indépendants les uns des autres, le tout garni d'une configurabilité plus que généreuse?
Quand à KDE, l'une des principales sources d'inspiration était initialement le Mac et sa simplicité d'utilisation…
Rhaah… À chaque fois, c'est pareil. Dès que je vois passer une news sur Enlightenment, je deviens nostalgique, et je me met à radoter des souvenirs sur le bon vieux temps. C'est triste de vieillir…
[^] # Re: Un peu d'histoire
Posté par NeoX . Évalué à 3.
fait gaffe papy à pas te peter un Gnu (prononcer Genou) ;)
[^] # Re: Un peu d'histoire
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 2.
Hum, marrant comme on a pas tous les mêmes souvenirs, pour moi kde a toujours été plutot inspiré de windows
et gnome de macos .. comme quoi
[^] # Re: Un peu d'histoire
Posté par drakmaniso . Évalué à 8.
Qu'on se comprenne bien: je parle des toutes premières versions de ces projets.
Pour ce qui est de la source d'inspiration de KDE, je me souviens que plusieurs développeurs faisaient régulièrement référence au Mac. Parmi les premières fonctionnalités implémentées, beaucoup étaient à l'époque associée au Mac (même si Windows a commencé à les a intégrer à peu près à la même époque). Quelques exemples: l'emphase sur le drag'n'drop, la gestion de fichiers via plusieurs fenêtres plutôt qu'un seul explorateur (le fameux mode spatial que gnome essaiera de faire adopter bien plus tard), la volonté de limiter le nombre d'options présentées à l'utilisateur… Le menu global fut implémenté assez rapidement, je ne sais plus si c'était pour KDE 1 ou KDE 2.
Un petit coup d'œil sur l'annonce initiale du projet permet de confirmer cette impression: remise dans le contexte de l'époque, la vision présentée par Matthias Ettrich est clairement plus proche du Mac que de ce que Windows représentait à l'époque.
En ce qui concerne Gnome, c'est plus difficile à dire. Mais je ne me souviens d'aucune référence au Mac aux débuts du projet. L'idée présentée était surtout d'appliquer le concept Unix (de petits outils indépendants qui se complémentent les uns les autres) au desktop. Par exemple, au départ il ne devait pas y avoir de WM officiel imposé, juste un WM par défaut; le desktop devait pouvoir s’accommoder du WM préféré de l'utilisateur.
Autre anecdote amusante, le "Network Object Model" de l’acronyme Gnome marquait la volonté de créer un équivalent au protocole OLE de Microsoft… C'était la technologie hype du moment, mais je crois bien qu'elle n'a jamais réellement trouvée ses utilisateurs… Bref, une philosophie très éloignée du Mac, pour qui les choix techniques sont toujours conditionnés pas les choix d'interface.
Pour en revenir au sujet de la dépêche, il me semble qu'à un moment donné il était prévu qu'Enlightenment soit le WM par défaut de Gnome au tout début du projet (très vite remplacé par Sawfish). Mais je n'arrive pas à trouver de confirmation sur le net… Il y a d'autres dinosaures ici qui pourraient confirmer, ou me corriger?
[^] # Re: Un peu d'histoire
Posté par Puppet_Master . Évalué à 8.
Oui j'ai un dino juste a coté de moi M. Vincent Torri :
" Raster (le créateur de Enlightenment) travaillait chez Red Hat et participait au dev de Gnome. Il avait écrit Imlib (la version 1) pour la pour la partie graphique de gtk et e17 (je ne sais plus quelle version, la 0.14 ou 0.15) était le gestionnaire de fenêtre de Gnome. Raster et Havoc Pennington ont eu un différent concernant le futur du développement, et Raster est parti, avec les changements qui ont été mentionnés (imlib vers gdk et Enlightenment vers un autre gestionnaire de fenêtre). "
Et voila pour la minute histoire, Merci Vincent ;)
[^] # Re: Un peu d'histoire
Posté par Goffi (site web personnel, Mastodon) . Évalué à 6.
Oh merci pour le lien pour l'annonce originelle de KDE, je ne l'avais jamais lue, et c'est d'autant plus intéressant avec le recul: KDE a une place toute particulière pour différentes raisons:
les conséquences sur cette bibliothèque: popularisation, et la pression qui ont conduit à un changement de licence
la popularité de KDE a poussé à la création d'un autre environnement de bureau, GNOME, pour des raisons éthiques. L'ironie, c'est que depuis Qt a changé de licence et KDE est donc "clean" de ce côté, alors que GNOME se fait maintenant critiquer pour l'utilisation de Mono
le message est très intéressant pour la description, et aussi pour les remarques anti-troll à la fin (le premier BTW). Évidemment ça n'a pas loupé pour les trolls :)
En retrouvant l'archive usenet, et les commentaires qui ont suivi on constate deux choses:
à l'époque c'était plus facile de toucher un large public technique: Usenet était beaucoup plus populaire que maintenant (je ne parle pas des alt.bin), et la référence indéniable. Aujourd'hui, tout est éparpillé, et on essaye de compenser ça par des regroupement de type planet. Ajouté à ça un nombre beaucoup plus important de projets qui se lancent, je pense qu'il est plus difficile aujourd'hui de démarrer un moyen ou gros projet.
je n'ai lu que les premières réponses à son message, mais c'est incroyable comme ça n'a pas changé: de nombreux messages de découragement, disant d'utiliser tel langage, tel autre bibliothèque, de contribuer à tel autre projet, etc. Il faut quand même être sacrément sûr de soi pour continuer quand dès le début on se prend des croche-pieds.
[^] # Re: Un peu d'histoire
Posté par Dr BG (site web personnel) . Évalué à 5.
Eh bien pour moi, GNOME 1 était une sorte de copie de KDE 1.1 mais en plus moche (très gris).
KDE : http://www.kde.org/screenshots/images/large/matthiase1.jpg
GNOME : http://www.marsaud.org/images/gnome1.jpg
À l'époque, la configuration de GNOME ressemblait beaucoup à celle de KDE : http://www.linux-kheops.com/doc/redhat71/rhl-gsg-fr-7.1/figs/customizing/gbackground.gif
# Équipe France
Posté par 2PetitsVerres . Évalué à 1.
Quel est le pourcentage de black et de binationaux ? /o
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
# Live CD
Posté par dest . Évalué à 2.
À l'époque où j'étais sous E17, si tu voulais suivre l'évolution et les corrections de bugs, il fallait recompiler en permanence plein d'outils pour avoir quelques choses de fonctionnels. De plus, c'était pas très clair dans quel ordre il fallait compiler etc.
Bref, aujourd'hui, bien que ce ne soit toujours pas sorti officiellement, E17 est-il plus accessible qu'avant ? Des paquets dans des distros qui ne soient pas complètement obsolètes ?
J'aimerais bien regoûter à E pour tester mais sans tout casser sur mon matos. Y'a-t-il un live CD maintenu à jour ? J'avais entendu parler à un moment de Elive. Est-il éloigné de ce qu'il y a dans le dépôt git ou svn ?
[^] # Re: Live CD
Posté par Puppet_Master . Évalué à 1.
Si tu n'utilise pas de distribution Source tu as Archlinux qui l'intègre très bien et que sort des paquets "-svn" dans le dépôt "communauty" qui sont à jour.
Pour les autres distributions je n'ai pas de réponse.
[^] # Re: Live CD
Posté par Jolidragon . Évalué à 3.
Je pense que le problème est là justement, non seulement y'a pas de release, mais en plus c'est pas compilable pour le commun des mortels:
-git qui refuse de checkout pour des histoires de .po récalcitrants (récurent)
-scripts ./configure foireux qui souvent passent alors qu'une dépendance n'est pas présente ou pas à jour, obligeant à chaque fois à recompiler toute la chaîne de dépendances une fois la lib en cause trouvée...
Au final on y arrive quand même, mais faut avoir une sacrée motivation et connaître un peu le truc, j'imagine que beaucoup laissent tomber avant...
Et non désolé, j'ai pas envie de faire tourner un wm sur un livecd, ni de changer de distribution juste pour tester.
C'est pas faute d'avoir essayé, je suis le projet depuis le début, y'a quelques années ça marchais mieux qu'aujourd'hui, "rethink everything", c'est bien beau, mais si c'est juste tout casser sans arrêt pour laisser pleins de fonctions inutilisables...
c'est bien simple:
-l'applet de gestion réseau connman révolutionnaire de marche pas
-l'applet de mixer ne marche pas
-les thèmes sont tous broken vu que forcement l'api change tout les 3-4 matins les mecs n'ont plus envie de les mettre à jour
-On ne peut toujours pas utiliser normalement l'éditeur d'icones sans avoir 1 fois sur trois un bug qui, soit supprime l'icone,soit fait tout planter ( oui j'ai bien essayer de supprimer la config et de la recommencer pour la 12 ème fois ).
-si on tombe sur la bonne version du svn, on arrive à changer le fond d'écran mais c'est pas garanti
-Des fenêtres qui oublient de se redessiner, ou impossible à redimensionner sans utiliser des ruses d'indiens
-le panneau de configuration qui est un bordel sans nom ( configuration, modules ? non ? affichage ? ah non, ça doit être dans modules, ajouter le module de configuration du module, puis ensuite modules, propriété, configuration, non ? Ah désolé je sèche alors)
Alors peut être que les efls sont super rapides, que ça va révolutionner le monde des tablettes tactiles, des téléphones et des freebox, mais en ce qui concerne le gestionnaire e17 en lui même je crois que plus personne n'y crois, j'ai fini par passer à xfce, trop, c'est trop.
mon cent.
[^] # Re: Live CD
Posté par Puppet_Master . Évalué à 2.
Bonjour
Je t'invite a venir nous voir aux Solutions Linux entre Mardi et Jeudi, juste pour te montrer dans les faits que tout ce que viens de dire est simplement faux. Nous seront ravis de t'aider a installer et configurer e sur ton PC.
Je ne trouve aucun rapport de bug a ton nom.
Et juste au passage les sources du projets sont sur un Subversion.
http://svn.enlightenment.org
[^] # Re: Live CD
Posté par Jolidragon . Évalué à 4.
Compiler et installer j'y arrive, mais quand tu part d'une debian, je t'assure qu'il faut vraiment s'en donner la peine, que se soit à la main ou en utilisant des scripts, c'est rare de ne pas tomber sur une lib trop vielle qui fait tout foirer, une lib à jour mais en conflit parce que le path est pas pris en compte, ou alors un make qui échoue parce que c'est en dev et c'est normal.
D'ailleurs, à mon avis, si vraiment ça compilait vraiment si bien que ça, je pense qu'on trouverais certainement des nightly build ou des révisions svn sous forme de paquets pour les principales distributions.
Pour ce qui est rapport de bug,j'ai pas l'habitude d'en faire par rapport a une version svn, je préfère aller demander directement sur irc, où souvent on me réponds que, pas de chance sur ce coup la , j'ai fait mon checkout au moment ou il fallait pas et que c'est normal.
Je pense que si y'avait une version de fixée, en disant voila, celle là, c'est la version alpha,sous forme de paquets ou avec un installeur qui fonctionne simplement, ça permettrais d'avoir plus de retours.
A force de trop jouer sur le coté "ça sera prêt quand ça sera prèt" , c'est toute la communauté qu'est en train de se barrer, regarde les soft dispo sur le svn, combien sont loin d'être terminés et déjà à l'abandon ?
Et pourtant à la base je suis un grand fan de E, en plus l’accueil est toujours sympa sur irc et d'ailleurs je remercie tout ceux qui ont passé du temps pour m'aider, j'avais donc aucun intérêt à en rajouter sur mon message précédent à propos des difficultés d'installation et d'utilisation,si j'étais parisien c'est avec plaisir que je serais venu vous rencontrer,compiler devant vous et vous montrer à quel point ça juste marche pas comme il faudrait.
[^] # Re: Live CD
Posté par be_root . Évalué à 4.
Peut être bodhi ?
http://www.bodhilinux.com/
Installé chez moi, en suis content.
Il se prend pour Napoléon, son état empire.
[^] # Re: Live CD
Posté par Anonyme . Évalué à 5.
Si tu as installé e17 sur ton disque, tu peux le tester dans Xephyr. Dans un terminal:
Xephyr -ac :1 && enlightenment_start -display :1
[^] # Re: Live CD
Posté par bubar🦥 (site web personnel) . Évalué à 2.
Les EFL se compilent facilement, proprement et rapidement. En moins d'une demi-heure toute la clique était compilée sur ma Fedora x86-64, sans jamais avoir auparavant compilé du E, pas possible de se perdre dans les options de compilations, et l'ordre de compilation est parfaitement clair.
[^] # Re: Live CD
Posté par dest . Évalué à 3.
J'ai envie de dire « tant mieux ! ». Ça veut dire que le projet s'améliore au fil des années.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.