Je recopie des tas de classes d'un autre module, alors qu'on devrait avoir un framework commun (sauf que ce machin est loin d'être assez bien fichu / agnostique pour qu'on puisse objectivement en faire un framework, donc je vais même pas proposer à mon collègue sinon il me fera probablement le faire et j'ai VRAIMENT pas envie). Je dois déplacer la responsabilité dans les items (d'ailleurs pour dire, on a des éléments HTML auxquels on attache un comportement, ce qui requiert de créer une classe View de notre framework qui est supposé créer l'élément, qui est lui aussi un event emitter qui peut envoyer/recevoir des événements de type click, longpress, etc. du coup tu crées des View, et tu ajoutes la view.element au DOM, mais tu les gardes aussi qqpart parce que quand tu ne t'en sers plus il faut appeler view.destroy() et supprimer l'élément du DOM, facile), et pour les événements on a un "mixin" DragListener qui permet d'ajouter cette fonctionnalité à la View (donc dans le constructeur de la View tu fais DragListener.call(this)). La view étant elle-même un event emitter, émettant ses propres éléments, l'élément HTML lui-même émettant ses propres événements, et certains événements pouvant être transmis plus loin doivent être émis sur le parent, on a donc ceci :
// Pour intercepter les événements lancés par le DragListener
this.on('longpress', function(...) { ... })
// Pour un événement classique
this.queryElement().on('click', function(...) { ... });
// Parfois on forwardera l'événement au parent
this.on('dragstart', function(hold, x, y) {
this._cancelClick = true;
if (hold) {
this.parent.emit('itemdrag', this, x, y);
}
}, this);
// Et parfois on l'émettra directement depuis là
this.emit('itemdrag', this, x, y);
// Mais parfois aussi on passera par un autre listener passé par le parent
this.browserEventListener.emit('requestnavigation', loc);
// Et enfin parfois le parent s'abonnera directement à un enfant
this.collection.on('added', this._onCollectionAdded, this);En creusant je vois que ce n'est pas seulement que mes collègues ont mal codé leur bordel, c'est qu'avec ces technos on ne pourrait pas vraiment faire plus simple. Je crois que je commence à rejoindre ENTIEREMENT Kevin au sujet des gens qui écrivent sérieusement des UI en HTML/JS/CSS. Celui qui dit que c'est bien, hype ou je ne sais quoi démontre simplement une ignorance crasse et devrait être un signal d'alarme "ne surtout rien faire avec ce type". Il y a des toolkits faits pour ça. Qt est sans doute excellent. Objectivement, à côté même la Win32 API en C est un pur bonheur. Et on a fait encore mieux depuis.
(J'exclus les applis web hein, ça a un vrai intérêt, et je peux encore comprendre ceux qui utilisent Electron pour porter une appli initialement écrite pour le web.)
et pico8 est plutot intensif question CPU, sur une Pi3 avec une alim a 1.5A officielle j'ai souvent le carré qui s'affiche pour dire "la tension chute un peu trop" avec l'écran officiel, donc il faut supprimer 300 a 400mA juste pour l'écran)
(500 mA contre 330 mA)
