freem a écrit 4934 commentaires

Oui, mais pas assez souple pour plaire à tout le monde. Le tiling émerveille ceux qui l'aiment… Et fait fuir un paquet d'autres. C'est un concept intéressant mais pas assez universel selon moi (d'ailleurs sinon il serait forcément plus utilisé).

C'est clair. Cela dis, en tant que professionnel, tu as dû voir windows 8, avec leur interface anciennement nommée metro. C'est du tiling, clairement. Primitif, mais tiling malgré tout.
Je doute que MS fasse des choix complètement stupides, et, pour tout dire, il m'a fallu une contrainte de place de l'écran pour passer au tiling. Mais maintenant que je l'ai découvert, je ne peux plus m'en passer.
Même chose pour Mme Michu? Peut-être… ou pas.
Toujours est-il que grâce à leur puissance, MS arrivera à imposer w8 (c'est évident, pour moi, qu'on aime ou pas).
Et par la même, à remettre au goût du jour le mode tiling. Je pense qu'on y gagnera pas mal niveau ergonomie :D

Pour le coup du "sinon il serait forcément plus utilisé", j'ai envie de citer l'objet qui se situe entre toi et ton écran. Le clavier. Dis-moi, sans rigoler, que la dispostion azerty (ou qwerty, pour ce que ça change…) est universelle, pour voir?
Ce que j'ai appris, avec linux, c'est que les gens, moi y compris, ne choisissent presque jamais en connaissance de cause, mais plutôt quand on ne leur laisse pas le choix.
Les stacking window manager, ce sont les derniers nés, des gestionnaires de fenêtres. Ils ont plus de succès parce qu'ils ont un meilleur côté "bling-bling", mais en terme d'efficacité, il n'est pas rare de voir les gens redimensionner leurs fenêtres les unes après les autres (perte de temps) ou bosser uniquement en plein-écran.
Il est aussi intéressant de voir que la plupart des logiciels modernes implémentent un gestionnaire de fenêtre interne, qui permet d'émuler un tiling: regardes les IDE (gestion des fichiers, éditeur de texte, fenêtres de débogage…), regardes les navigateurs, regardes excel, word (oui, oui, le côté MDI, c'est une gestion des fenêtre, qui appartiens au tiling: en fait, il s'agit d'une barre des tâches qui permet de sélectionner un document qui apparaîtra en mode plein-écran… le tout dans l'application, bien entendu) … Rarement les gens utilisent le mode stacking des MDI, le plus souvent, c'est le côté tiling ou full screen qui est populaire.
Je crois vraiment que c'est le stacking qui est le moins universel.

Et j'ajouterais, mais là c'est le professionnel qui parle ;-), qu'il faut aussi composer avec l'évolutibilité de l'interface… Imaginer ce qu'on pourra lui demander de faire demain, et imaginer comment on pourrait bien la faire aujourd'hui pour conserver demain la même logique et efficacité tout en rajoutant des fonctionnalités. Ça, pour les applications de production en entreprise, c'est indispensable… Je peux te le dire, c'est une sacré prise de tête :-)

Ce dernier point, les développeurs le connaissent: écrire une application qui demain aura perdu la moitié de ses fonctionnalité, remplacées par de nouvelles en nombre pas forcément égal. Mais bon, c'est aussi ce qui est sympa dans ce job.

Si tu veux tout savoir, je suis plutôt de ton avis. Mais avec Vista, Microsoft s'est surtout senti obligé de renouveler visuellement leur OS et de leur donner un gros coup de jeune, car ils commençaient à vraiment passer pour des paysans face à OS X et mêmes aux DE de linux dont le look se modernisait à vitesse grand V. Aero, les effets visuels et la reprise du concept de Dock, c'est avant tout du rattrapage plutôt que de l'innovation hein… Mais venant de Microsoft ça ne surprendra pas grand monde.

Le concept des dock… c'est quoi? C'est pas le fait de pouvoir coller un dossier sur une bord de l'écran et qu'il s'y affiche, en restant quand on reboote? Ca existe depuis windows 95 ça.
D'ailleurs, il est intéressant de noter que les win 9x avaient la possibilité d'utiliser un pseudo mode tiling. Windows XP aussi, dans une moindre mesure. Allez, un TP pour ceux qui un de ces OS chez eux:
Lancez plusieurs applications.
Appuyez sur CTRL et maintenez la touche enfoncée.
Cliquez gauche sur divers boutons de la barre des tâches, successivement.
Cliquez droit sur l'un des boutons que vous avez précédemment sélectionnez, et admirez les options qui s'offrent à vous, en terme d'organisation de fenêtre….
A noter que depuis windows vista, ce n'est plus possible.

Autre exercice:
Prenez une icône de dossier, et faites-la glisser vers un bord de l'écran, puis relâchez. Ensuite, cliquez-droit dans le "dock" qui est apparu, et jouez avec les options. Faites-vous plaisir. ;)

Bref. Les fonctionnalités que j'ai décrites, bien que méconnues, sont apparentées, et pas qu'un peu, à un fonctionnement en tuile. Primitif, c'est vrai… Inconnu du grand public, c'est vrai aussi. Mais aussi la raison qui fait que je n'arrive pas à passer à un windows plus récent que XP.
Le tiling, pas assez universel? Vraiment? C'est pourtant instinctivement ces que les gens utilisent, même avec leur stacking. En tout cas, je vois rarement un empilement de fenêtres ou les gens jouent avec les plans.

Marrant, ton discours me donnerai envie de l'essayer.

Malheureusement, j'ai un problème personnel et presque entièrement subjectif avec Qt… tant que je n'aurai aucune raison professionnelle de l'utiliser, je doute de franchir la barrière de mon dégoût. C'est stupide, je sais… mais j'ose espérer qu'on à tous ce type de barrière :)

(la chaîne de compilation de C++ est déjà assez chargée comme ça. J'ai dis, presque entièrement subjectif :) presque, parce que du coup, c'est infernal à utiliser Qt avec un IDE classique, et je n'aime pas du tout QtCreator. Goûts, couleur, tout ça… et mes goûts à moi sont clairement dans le minimal.)

Juste, deux question pour le coup. Tu dis qu'on ne peut plus coder dedans, mais, j'imagine que ça implique que l'on peut lier "mécaniquement" une boîte de dialogue à un contrôle? Bon, pas que ça me semble difficile à implémenter, mais je ne l'ai pas vu dans tous les RAD… outils dont la moyenne de ceux que j'ai essayé vole franchement très, très, très bas, niveau qualité du code généré et stabilité de l'outil!
La seconde question porte sur le fait du travail supplémentaire impliqué par ce type d'outil.
J'ai constaté que régulièrement, quand on modifie un truc dans le code, soit ça pourrit le RAD, soit le RAD l'écrase ensuite, quand on y retourne pour modifier un truc. Même combat ici, ou …?

Intéressant point de vue.

De mon côté, je ne sais pas si l'ombrage est un vrai plus, puisque je n'utilise en général que des applications en "plein écran": tiling window manager. Quand ce n'est pas du pseudo plein écran, la coupure est suffisamment nette pour, je pense, que mon cerveau n'aie pas à réfléchir.
Je pense que ce paradigme est de loin le plus ergonome, en fait. Après, je n'ai aucune preuve scientifique, juste une impression et l'expérience qu'un utilisateur accumule de DOS à windows 7, en passant par dosshell, win3.1 et win 9x. Et un peu de gnome 2, qui m'a très vite fait fuir, de KDE que j'ai apprécié en BTS (y'a 6 ans, je sais pas quelle version c'était, j'étais encore windowsien à cette époque) et de XFCE.
Ma préférence à toujours été à la simplicité, j'ai toujours eu en horreur le thème de wXP, par exemple. Avec les tiling WM et les logiciels en ncurses, je suis comblé: y'a pas plus simple :D

Pour ce qui est du manque d'ergonomie des logiciels sous linux, je dirai juste que, comme tu l'indiques, il s'agit d'un sujet complexe. Hors, souvent les gens qui créent les logiciels sous linux sont des développeurs. Les graphistes sont toujours recherchés dans les projets que je peux voir, et je doute fortement que beaucoup de projets puissent se targuer d'avoir des ergonomes dans les contributeurs réguliers.
Naturellement, la pléthore de projets n'ont pas souvent les moyens pour avoir déjà un dev payé, alors un ergonome…
Et je ne sais pas pour les autres, mais dans le peu d'études que j'ai faite, il n'a jamais été question d'ergonomie. La seule chose que je crois savoir c'est qu'il y a un nombre de menus à ne pas dépasser (7?), une histoire de mémoire immédiate…

Un autre point qui me semble essentiel: je n'ai pas l'impression que les ergonomes soient toujours d'accord. Ca ne ressemble pas vraiment à une science exacte, en somme.
Tu cites Mac OS et Windows… je n'ai pas noté de progrès dans l'ergonomie quand j'ai vu Vista et w7 arriver, bien au contraire, j'ai trouvé que ça tenait plus du retour en arrière sur certains points. Par contre, w8 que tout le monde critique, j'ai "testé" dans un supermarché, et j'ai bien aimé. Mais bon sang, ils ont quand même un sacré retard dans les gestionnaires en tuile!
Parce qu'être capable de docker une appli d'un côté de l'écran mais pas de l'autre, par exemple, je ne trouve pas ça ergonomique. Pour un droitier, ça va (c'est le côté droit qui marchait quand j'ai testé) mais un gaucher? J'imagine que ce n'est pas si bien que ça…

Toujours est-il que vu que tu sembles connaître le sujet de l'ergonomie, si tu as des liens vers de bonnes documentations bons conseils, je suis preneur.

Ah, dernier point:
Je ne suis pas d'accord avec toi sur le rôle des toolkit. Le but n'est pas d'imposer un type d'interface, mais de rendre la création d'interface simple, en épargnant au dev de s'emmerder à refaire la roue à chaque fois.
Alors, effectivement, il y a un effet de bord qui fait que, souvent, toutes les la plupart des interfaces faites avec un même toolkit se ressembleront (encore que… si on prend le cas de wxWidgets, ça change en fonction de la plate-forme, puisqu'ils utilisent en fait les toolkits natifs :) )
Mais comme il a été dit, ce n'est pas systématique, les antivirus windows sont une preuve, msn en est une autre, ainsi que skype, … bref.
Chaque toolkit fournit la possibilité de customiser le moindre contrôle. Si ce n'est pas fait souvent, je parie que c'est plus par souci d'économie que d'ergonomie.
Et si cette fonctionnalité est proposée, c'est qu'elle est nécessitée par les développeurs, ou par leurs clients.

Je trouve les RAD wysiwyg très bien. Il ne faut juste pas en abuser. Par exemple, avec Qt Designer, tu peux intégrer des widgets créés avec Designer ou du C++ ou encore du Python (ce n'est pas trivial la première fois), et t'occuper simplement de les positionner les uns par rapport aux autres.

Oui, très bien, pour du prototypage. Ou de petites applications.
Allez, rien que pour le fun, faites une calculatrice avec un RAD, puis faites-la à la main.
Celui qui va faire avec le RAD va faire 10 boutons séparés (pour une base 10), celui qui fait à la main, en bon flemmard de dev, fera un tableau de 10. D'ailleurs, avec un peu de jugeote, il fera un tableau dynamique, comme ça la calto passe en 2 lignes de code de 10 à 2 à 16 à 8 boutons numériques… ou pourquoi pas 20…

Bon, certes, ce n'est qu'un cas très précis, pas généralisable. Et j'utilise des RAD, moi aussi. Pour le prototypage, et le dev crado, c'est bien, ça accélère.
Par contre, si je veux un code propre et une appli légère, non, parce que les layouts permettent de régler le problème de la présentation très facilement à la main, et que si mon appli dois être légère, ça veut aussi dire qu'il vaut mieux ne pas trop charger l'interface.

De plus QtDesigner gère très bien les layouts.

Certes. Comme tous les RAD en fait. Au moins ceux dignes de ce, bien sûr…
Mais les layouts ont l'immense avantage de se gérer très facilement à la main. (en plus de redimensionner l'application sans casser toute l'interface, hoff kource)
Du moins, avec wxWidgets (que j'utilise sur une appli, mais faut que je trouve un meilleur framework portable parce que ça m'agace. Et me parlez pas de Qt, c'est le pire que je connaisse, avec sa manie de modifier la chaîne de compilation, mais de qui se moc t-on? )

Ca me rappelle qu'il faut que je finisse mon mécanisme qui me permet de générer une interface basée sur des fichiers de conf et les lier à une action implémentée dans un plugin. (Ca existe certes déjà, mais c'est amusant à coder, et puis l'existant à trop tendance à utiliser de l'xml, que je conchie n'apprécie guère. D'autant que je base mon code uniquement sur boost et la stl (et wx, mais faut que je templatise tout ça parce que je compte switcher mon appli à autre chose de plus léger, mieux conçu, qui n'utilise que la STL quand c'est possible, et qui ne fasse que l'IHM quand j'aurai fait le plus gros. D'ailleurs, quelqu'un à une idée?), je pense que ça pourra être utile à d'autres que moi :D )
Histoire que je n'aie plus besoin de me coltiner toute l'interface de mes applis systématiquement, et que l'utilisateur puisse changer jusqu'à l'ordre des boutons de menus/toolbars, sans devoir compiler ni passer par une interface.
Allez, zou, je retourne coder moi.

Ce n'est pas mon cas.
L'idéal que tu décris me donne envie de vomir, d'ailleurs…

Il y a plusieurs catégories de personnes, qui voient le "bureau" différemment. J'en vois 3, à l'arrache:
_ Les "tout fournit, tout de suite, sans config" comme toi, qui vont utiliser des choses comme KDE et Gnome.
_ les gens qui pensent que seule une base doit être commune, avec une configuration commune et centralisée, laissant le choix des applications remplissant des besoins précis à l'utilisateur, qui se dirigent plus vers les bureaux du genre d'XFCE ou LXDE, reposant sur un jeu de librairies communes aux application formant le coeur.
_ les gens comme moi, qui estiment que l'idéal, ça n'existe pas, mais que le plus proche, c'est de sélectionner chaque petite application qui compose le système, et de configurer le tout pour que tout marche comme une horloge suisse, sans heurts et avec une régularité impressionnante (bon, ok, j'en rajoute, pour donner un p'tit côté humoristique ;) )

Et dans chaque catégorie, les gens ne sont pas d'accord pour un seul modèle, ce qui peut résulter ou pas en une "concurrence" des projets (1ère: Gnome vs KDE vs Unity vs… pour la 2nd: XFCE vs LXDE vs E16 E17 pour la dernière, rien que les wm: i3, ratpoison, twm…) et le pire, c'est que je trouve que c'est globalement bien ainsi (même si certains pourraient fusionner parfois…)

Je pense que E17 correspond à la 2nde catégorie, mais que, tout simplement, le jeu de fonctionnalités qui leur semble vital est nettement plus réduit que les autres. Pour l'instant, du moins.

Des sites tous accessibles par API… mais… HTML est très bien, bon sang! Et les DE ont un navigateur (bon, ok, pas tous), on y peut rien si les gens estiment qu'il est mal intégré… d'ailleurs, ceux qui l'estiment ont qu'a faire mieux, pour voir… je serai curieux de voir le résultat.
De toute façon, j'ai l'impression que les gens savent de moins en moins utiliser un PC non connecté…

Pour le coup du "cul entre deux chaises": LXDE à commencé avec juste l'explorateur de fichier. Certes, c'était il y a moins longtemps et ils ont maintenant un ensemble d'applications… mais toutes ces applis n'ont pas été dev par la même communauté, et d'ailleurs, toutes n'utilisent pas la même base de libs.
Il y a l'ambition d'un toolkit… peut-être que ce toolkit est juste la pour permettre aux gens de faire des applis portables et légères? Parce que de ce côté là, il y a un manque plus qu'évident! Qt, WxWidgets… c'est pas vraiment ce que j'appelle léger. Pour GTK, je sais pas, jamais essayé.
Il paraît que E17 fonctionne sous windows, après tout… (faut vraiment que je teste, ça!)
Pas même KDE ne peux, aux dernières nouvelles que j'en ai eu, prétendre fonctionner sous windows sans problèmes. Et j'ai testé y'a moins de 6 mois, ça ne fait qu'installer quelques applications, et même pas le gestionnaire de fenêtres! (alors que bon… si on pouvait remplacer le wm de windows, ce serait pas mal quand même. Certains ont essayé… peu ont réussi :) )
E17 propose justement un wm… qui semble tourner sous winchose…

Que penser de Ploum qui a été obligé de créer une boîte e-mail sur hotmail et une autre sur gmail et qui doit régulièrement regarder dans ces deux boîtes aux lettres pour voir s'il a reçu des messages (oups, je voulais dire: comptes sur facebook et google+) ?

Que ploum n'a pas pensé à configurer un compte pour qu'il renvoie directement les mails vers la seule adresse qu'il utilise vraiment?
Ah, pardon, ce n'est pas possible avec les réseaux sociaux… Et c'est bien pour ça que les mails sont bien plus intéressants. Pour l'IRC, on peut utiliser des bots pour faire la même chose. Avec le téléphone, il y a aussi des possibilités de redirection.
Bon, je te quote, mais pas pour dire que je ne suis pas d'accord, au contraire même :)

Le reste du message n'a d'ailleurs rien (ou pas grand chose) à voir avec le tiens.

Alors, oui, ceux qui s'enferment, ce sont ceux qui se brident à une seule plateforme de réseau social fermé, les empêchant par la même d'aller voir ailleurs facilement (je ne parle pas du fait qu'un outil ait son code source ouvert ou pas, ça n'a rien à voir, les sources de hotmail et gmail ne sont pas distribuées, pourtant on peut transférer ses données sans problèmes).

Quant au problème des utilisateurs qui ne savent pas se servir d'un mail mais qui "gèrent" facebook… hier mon frère se plaignait qu'un de ses "amis" partageait tous les contenus au lieu de simplement les plussoyer. C'est donc bien une preuve que fesses de bouc n'est pas si bien manipulé que ça.
D'un autre côté, sur la mailing list debian, les gens qui ne respectent pas les règles ne sont pas assassinés (enfin, pas tout de suite) on leur explique comment faire les choses correctement.

Et pour finir, le coup du "gégé est pas invité", avec facebook et les règles d'accès qui changent tout le temps, j'ai pas l'impression que ce soit plus simple que par mail.
Par mail, tu as 2 solutions, la prise de tête super efficace, et la vite fait mal fait:
_ configurer une mailing-list, très efficace, mais demande un minimum de compétence et de temps
_ simplement faire un envoi à plusieurs personnes, en précisant dans le message de ne faire que des "répondre à tous".

Par ailleurs, dire que quelqu'un ne sait pas se servir des mails mais qu'il sait se servir de facebook, c'est quand même un superbe délire: éventuellement, quelqu'un peut ne pas savoir se loguer dans son client mail, mais ce sera la même chose pour facebook. Après, l'interface la plus complexe, c'est certainement pas celle des clients mail.
Au mieux, on peut dire qu'une personne ne connaît pas les us et coutumes de la liste qu'elle à rejoint (citer le message entier ou n'en prendre que la partie utile, répondre avant ou après le message, ne pas hijacker les threads parce que certains se fient à je-ne-sais-quoi dans le header plus qu'au titre… des us et coutumes, tout ça…).

Dans ce cas, pourquoi avoir répondu la même chose que les réponses plus haut? :P

J'ai mis en gras les passages qui me semblaient un peu gênants, si ce n'est faux…
Non pas que je suis contre l'imposition plus forte de riches, je ne pense pas qu'il faut tomber dans l’excessif pour justifier cela. Déjà mélanger la méthode de gain de vie d'un artiste et d'un financier c'est maladroit tellement que cela fonctionne différemment. Et dire qu'un artiste qui gagne beaucoup de sous l'a volé ( ou eu au détriment d'autres personnes ), c'est un peu du foutage de gueule aussi. L'argent que les artistes perçoit gagne son argent que parce qu'il y a un public derrière qui le donne. N'aller pas voir les films, n'écoutez pas de musique, etc. et ils ne gagneront plus rien du tout. Il ne faut blâmer que ceux qui les payent. ;)

Actuellement le salaire est défini suivant le ratio offre-demande, plus il est facile de trouver une personne apte à réaliser un travail, moins il coût cher et à l'inverse, plus c'est rare, plus cela coût cher. Au contraire de la tâches des ouvriers où hélas les compétences demandées ne sont pas très rares et du coup le salaire chute malgré la pénibilité derrière (car on sait que si l'ouvrier part ou n'accepte pas son salaire, on pourra trouver ailleurs une personne apte à réaliser le travail pour ce salaire). Dans le cas des artistes, si on veut qu'ils gagnent moins, il suffit de ne pas voir ce qu'ils font et ça chutera tout seul, le consommateur est en réalité responsable de cet état de fait et non l'artiste qui n'a forcé personne.

Moi aussi, j'ai mis en gras ce qui me semblait faux…

Déjà, lorsque l'on gagne de l'argent, c'est forcément au détriment de quelqu'un d'autre: il faut toujours que quelqu'un se défasse d'une somme.

Pour le salaire qui est définit suivant le ratio… pas tous, franchement. Trouver des gens qualifiés pour faire un mur droit, ou installer correctement l'électricité, ce n'est pas si évident.
Et pourtant, c'est pas super payé. On préfère recruter des incompétents payés au SMIC qui salopent le boulot, avec un bon avocat derrière pour assurer les plaintes des clients, qui râlent parce que le boulot ne respecte pas le contrat.
On critique souvent les projets informatiques pour être incapables d'être finis à l'heure, mais ce ne sont pas les seuls, dans le bâtiment aussi, c'est rarement livré à l'heure, et souvent parce qu'un entreprise merde.
Au passage, on a d'ailleurs de la chance, il y a le SMIC, qui permet d'avoir au moins de quoi survivre (plus ou moins facilement) quand on travaille 35H par semaine.
Donc le coup de l'offre et de la demande… bof bof. Si c'était vrai, certains ouvriers auraient de bonnes payes, sans forcément faire d'heures sup ou bosser la nuit/les week-end, et quant à la compétence des actionnaires, j'aimerai qu'elle soit réelle et pas supposée, le monde n'aurait pas connu de crise économique depuis longtemps si c'était le cas.

Quant au "il suffit […] ça chutera tout seul" c'est vrai, mais dans une certaine mesure seulement. De mémoire, j'ai une taxe quand j'achète un disque dur pour financer ces pôvres gens et lutter contre les ravages du piratage du vol de la contrefaçon.

Dégainant, ou dédaignant?

Reste à savoir si la suppression d'un organe inutile cause la mort :D

Ta voisine, elle s'appellerait pas mellissa et serait pas métis à tout hasard?

/me ->[]

Idem, un compte avec le CV qui cible mes objectifs en terme de carrière.
Déjà contacté plusieurs fois, depuis 3 semaines, dont une offre intéressante.

Vue ma situation perso & pro, c'est pas plus mal d'avoir un plus:
chômage régulier, pas de diplôme au-delà du bac… bref

Et puis, s'ils veulent vendre mon cv, grand bien leur en fasse, j'y gagne aussi !

Par contre, 0 photo, pas d'avis politique, pas de troll, pas de déconne… la seule chos qu'ils pourraient vendre c'est mon @mail… comme linuxfr, en somme.

La dame serait-elle comme les cannes (femelle du canard, bien que dans le cas précis, on puisse parler de conards…) et capable de courir et trembler 1H après décapitation?

A remarquer que nombre de nos têtes pensantes n'ont pas besoin de réfléchir avant de déblatérer des conneries, et d'utiliser OpenOffice.org comme firewall, alors peut-être que leur ôter le chef permettrait de consommer moins d'énergie (ben oui, la tête est bardée d'organes inutiles et qui consomment fatalement de l'énergie, quid de la taxe carbone?) et donc d'être plus écologiques…

Appel au troll… et envie d'y répondre pour ma part :P

PS: excusez le ton insultant, c'est plus le jeu de mot qui me faisait rire :]

E17 supporte les tuiles avec un module.

Et il support le mode stacking avec un module aussi, histoire qu'on puisse supprimer le stacking et n'avoir que le tiling? xD

Quand à l'utilisation sur un téléphone portable, c'est déjà fait, ça s'appelle Illume.

(Quant* ce me semble :P c'est juste histoire de faire chier comme tout le monde ici hein ;) )
Je disais justement que sa légèreté annoncée permet de s'en servir sur de faible machines, comme des téléphones. Je disais simplement que je doute très fortement que gnome/kde en soient capables.

Déjà, les RAD (joujoux pour placer les contrôles et qui génèrent un fichier qui sera utilisable dans le code par la suite) j'ai personnellement appris à m'en passer… parce que chaque modif dans le code risque de tout péter à la prochaine modif dans le RAD!

Maintenant, à l'époque ou l'on plaçait les contrôles au pixel, ouai, c'était utile.
Maintenant, on utilise souvent la technique du "je te fout un layout, je \"configure\" ce layout pour qu'il prenne que des contrôles à l'horizontale, et j'y ajoute N contrôles et 3 layouts " qui fait que les RAD ont bien moins d'intérêt que par le passé.
En tout cas, peut-être pas "on", mais moi, déjà.

Les RAD, c'est bien pour pondre un prototype, mais le code généré est rarement maîtrisé, souvent crade, régulièrement instable (dans le sens ou le code bougera… quoique j'en ai vu faire du code qui plante, aussi, c'est toujours très drôle).

A noter que les critiques sur le code généré, je ne suis pas le seul à les faire: même si je ne peux pas le prouver ici, mes collègues sont justement en train de virer du code généré par un framework contre du code fait main… comme quoi.

Pour le reste, jamais testé les EFL. Et je n'en ai pas l'intention pour le moment, quoique, si ce gestionnaire de fenêtre marche vraiment sous windows, ça pourrait me convaincre.

When it is ready :D

La réponse est simple:
sur une base de mauvaise information, comme l'ont montré les post avant le tien (qui, au passage, sont plus constructifs, puisqu'ils indiquent le pourquoi, et proposent même mieux, ce dont je suis gré aux auteurs qui ont ma reconnaissance.)

PS: "p'tet" est l'abréviation de "peut-être" qui indique une possibilité, pas une affirmation accompagnée de 100% de certitude.
Placée devant l'affirmation que le RPI est libre, elle indique plus ou moins clairement, que je suppose ce dernier point.
Supposition qui est manifestement erronée, donc, mea culpa

Ce n'est pas si évident que tu ne sembles le penser.

Il existe des projets libres qui sont morts, pas parce que la communauté était inexistante, mais parce que les dev n'ont plus eu le temps.

L'exemple que je connais: autorealm. Sur la page de sourceforge, près de 5 ans après la dernière version, toujours plus de 200 téléchargements à la semaine. Une mailing list ou il y a toujours des discussions.

Mon avis sur le fait que personne n'ai repris le code lui-même: pas portable, langage payant (delphi), pas super documenté. Donc, sans développeur actif, impossible de réutiliser le code.

D'autres ont tenté des réécritures, en python et en C++, mais encore une fois, rien qu'essayer d'exécuter ne donne rien, sauf pour une reprise C++/Qt, qui arrive à charger une carte, et afficher les objets composés de lignes droites normales (pas les fractales, ni les courbes).
(Assez lisible, cette dernière version, d'ailleurs… dommage que j'avais déjà implémenté une certaine partie de la bête et de façon trop différente. Dommage aussi que la personne avait fait le dev "dans son coin" sans utiliser de forge, ce qui m'aurait peut-être permis de la trouver et d'y contribuer…)

Du coup, j'ai commencé une réécriture, en C++, en faisant super gaffe à avoir un code le plus clair possible, et 100% portable.
Il y a une une contribution: quelqu'un à finit le CMakeFiles.txt que j'avais commencé.
C'est tout.

Certes, ce n'est pas un jeu, mais un logiciel de dessin, pas forcément hyper célèbre. Mais il n'empêche que la communauté sait rester vivotante même sans nouvelles versions… ce qui ne l'empêche pas de ne pas vraiment contribuer. J'ai peut-être choisi un langage trop complexe, cela dis.
Quand je dis qu'elle ne contribue pas, je n'en tiens rigueur à personne: il faut du temps, et des connaissances, pour ça.

Toujours est-il que je rejoins l'avis des auteurs de plee-the-bear: les outils de communication, ça coûte cher en temps.
J'ai tenté de maintenir un wiki, j'ai lâché l'affaire, trop compliqué. Le seul truc que je maintiens au final, c'est le bug tracker, parce que c'est juste utile pour me permettre de me rappeler ce qu'il faut que je fasse. Utile. Pas vital, quand on est seul sur le dev.
Je lâche un message sur les mailing list, de temps en temps, histoire d'informer des progrès… mais bon, les progrès sont lents, vu que j'ai une vie à côté, et d'autres projets de dev qui me tiennent à coeur, et même un peu plus qu'autorealm, au final.

La conclusion, c'est que pour qu'un projet open source ne meure pas, il faut simplement une motivation égoïste de la part de l'auteur: que le projet lui serve, que ce soit en terme de fun à coder ou parce que l'outil lui sera utile après. Je pense même qu'il faut les deux, pour arriver à garder la motivation.

(qui sont vues une fois et basta).
Je suis p'tet crétin, mais je dois avouer que même 10 ans après, celle de worms me fait toujours autant rire :)
D'ailleurs, je l'avais oublié, merci de me la rappeler :)

Je suppose que tout ce qui ne tue pas la machine est obsolète de nos jours, donc seuls gnome et KDE ne le sont pas, sous linux.

Plus sérieusement, je ne vois pas non plus ce qu'il a de dépassé…
Ah, si!
Maintenant, on retourne aux tiling window manager a priori, donc c'est effectivement un retard puisqu'il ne semble pas gérer les tuiles ^{^}

Mais de ce point de vue la, ce sont les DE qui viennent enfin de s'y coller (windows 8 déjà) qui sont en retard, et pas juste 10 ans…

Je pense qu'a l'heure du mobile, ceux qui sont en retard, c'est ceux qui pompent toutes les ressources et gâchent la place de l'écran.
E17 n'a pas l'air d'en être. Après, faut voir à l'usage.

Tu as oublié bash.

Hé bien, de mon côté, je vais me contenter de vous souhaiter bonne chance.
Pour une fois qu'une boîte édite des jeux pour un autre système que windows, on va pas se plaindre.

En plus, y'a même une démo!
Du coup, "dommage" que j'aie une debian, vais devoir soit installer wine soit booter sous windows -.-' pour tester ça (parce que la dernière fois que j'ai tenté de dpkg un truc compilé pour buntu, ça marchait pô: conflits de symboles avec libc6, ABI cassée.)

Oh, après, pas à un moins près ^{^}
Pi j'ai envie de troller, alors tant pis :D

Le souci, c'est justement, et uniquement pour moi, que leur définition colle à certaines distro qu'ils ont refusé de mettre dans leur liste pour des prétextes fallacieux.
(Oh, merde, mon message le plus court de la soirée! Heureusement, on peut mettre une parenthèse inutile pour ajouter de la longueur stupide… 30% du message, en l'occurrence :D)

• ton 'gros' fichier PNG sera surement plus petit que les 4 'petits' fichiers (factorisation des entêtes et du dictionnaire de compression).

Sans compter le bête fait que la place occupée sera plus grosse parce que 4 blocs non utilisés complètement seront utilisés au lien d'un seul, en effet :)
Le terme de "gros" fichier n'avait pas pour but d'indiquer un gain de place, mais bien un problème d'organisation des ressources.
Ne serait-ce que pour la création d'une frame, il me semble plus simple de créer la 1ère, copier le fichier pour en créer un nouveau, le modifier en fonction de ce que l'on veut, et ce, autant de fois que nécessaire, plutôt que de modifier un seul fichier, au risque de déborder sur l'image d'a côté.
Sans parler d'ajouter une frame à une animation que l'on trouve trop grossière, sait-on jamais.

• tu n'auras peut être même pas besoin de découper : tes frames sont empilées verticalement

Arf mais quel boulet je fais… pourquoi je pensais à les concaténer à l'horizontale…

, il suffira de jouer sur les pointeurs (ta 1ère frame c'est les 128x128 premiers pixels, la 2ème les 128x128 suivants etc…).

Là, j'ai envie de dire que ça dépends de la technique utilisée pour lire l'image.
Je viens de regarder, le code est en C, ce que j'ignorais (ça va raccourcir mon post du coup).
Effectivement, les pointeurs sont une solution.
Mais j'ai aussi vu qu'il utilise la SDL, et, de ce que je me souviens de la SDL 1.2, la logique utilisée est très proche de l'orienté objet: une sructure de données, et un jeu de fonctions pour manipuler cette structure.
Impossible d'utiliser les pointeurs, donc, pour n'afficher que telle ou telle zone d'une image, il faudrait donc utiliser des instances de SDL_Rect: composées de 4 entiers, c'est très lourd et nécessiteras des calculs à chaque fois que l'on voudra changer de zone de dessin. Si les calculs ne sont pas fait dans le code du jeu, ils le seront par la lib de toute façon…

Utiliser des fichiers séparés permet de faire un simple

int nbFiles;
char *files[nbFiles];// impossible in C, IIRC
SDL_Surface animation[nbFiles];// but easy to implement
// code to fill files with the list of file names for that animation

for(int i=0;i!=nbFiles;++i)
  animation[i]=SDL_LoadImage(fichier);

NB: je ne me rappelle plus les noms et paramètres précis de la SDL, pas utilisée depuis au moins 2 ans…

Et avec un moteur 2D moderne (utilisant en fait des quad OpenGL et des textures) une simple translation des coordonnées de textures suffit à changer de frame.

L'openGL, c'est un truc qu'il faut que j'apprenne à utiliser et à l'intégrer dans wxWidgets, c'est justement sur ma todo list pour autorealm…
Faut que je prenne le temps de chercher des bouts de code à lire et modifier… donc je ne peux pas parler de la simplicité de ce dont tu parles :)
D'ailleurs, si trouver des ressources pour openGL 2 et plus récent me prends trop de temps, vais finir par lâcher l'affaire et rester sur l'openGL 1 pour laquelle j'ai de la doc, et qui me poserais pas de souci si j'avais réussi a appliquer la tesselation correctement.

Ce dont je doute en revanche, c'est que ta simple translation soit plus beaucoup plus simple que l'approche objet à laquelle j'aurai tendance à penser pour un code 2D (qui consisterais à chaque affichage de l'animation à incrémenter un compteur interne avec un p'tit modulo pour éviter l'overflow, pour afficher l'image correspondante précédemment chargée dans un tableau dynamique. Pas plus de 40 lignes de code réel pour la classe entière, et une seule pour l'utiliser.)

Mais ça, c'est faisable sur n'importe quelle distro basée sur Debian, inluant gnewsense, donc.

C'est aussi ce que je fais systématiquement :P