Hello,
L’alpha est passée en v4.4 ce matin.
Remarque sur les deprecated de la doc dev, on pas tester mais si çà casse trop de plugins on attendra la v4.5 voir v4.6. Le but n’est pas de rendre quoique ce soir obsolete au détriment des utilisateurs.
Petit avis perso, on a manqué de beta testeurs sur le cycle v4.3, donc n’hésitez pas à tester, sur un vieux Pi, une VM etc on a besoin de vous !
Illustration des checkboxs (voir changelog et doc dev)
J’aime l’arrivée de ce menu contextuel, vivement qu’on puisse l’utiliser dans les plugins 
(on en avait parlé ;-))
Je l’ai fait en pensant aux plugins. Tu peu déjà le mettre en checkant si la fonction existe
Oui pour les checkbox mais je pensais plus de manière générique, genre un ul>li caché dans la page et une class sur n’importe quel élément
Ça m’a intrigué ce teasing, installation en cours du coup
A tester en alpha 
5 messages ont été scindés en un nouveau sujet : getElementById is null avec un seul thème
Hello,
Quelques news depuis … Novembre 
Énormément de changements ces deux derniers mois !
On a littéralement déconnecté jQuery du Core 4.4 ! C’est un boulot juste monstrueux, puisqu’il a fallut réécrire tout le front-end en pur js : les actions et fonctions, les délégations des events, etc. Mais surtout il a fallut construire une architecture complète sur laquelle s’appuyer, notamment pour gérer tous les appels ajax, qui passait avant par jQuery 
Au final, on se rend compte que jQuery masque énormément de choses et qu’il a fallut apprendre… Mais c’est un mal pour un bien, on a repris le contrôle total du front-end
Bien sur il n’y a pas que les js et les fonctions, il y a aussi les plugins jQuery et les libs dépendantes de jQuery. On en récrit beaucoup, et intégré quelques nouvelles en pur js.
On a notamment développé en interne la lib jeeDialog() qui gère maintenant tous les popup, alertes, boites de confirmations, et boites de dialogues (qui sont maintenant maximisable!). Idem pour jeeComplete, jeeCtxMenu, jeeFileUploader, jeeResize, etc … 
Nous avons aussi intégrer SortableJS, une des meilleures libs pour la gestion des drag/drop. Ce qui, par exemple, améliore la gestion des déplacements de blocs dans les scénarios.
Adieux donc jQuery Autocomplete, jQuery bootbox, jQuery UI, jQuery Sortable, jQuery caret, jQuery contextMenu, jQuery FileUpload etc etc ! 
Aujourd’hui, il nous reste deux libs à remplacer :
Pour les curieux (et les devs du Core et de plugins), vous pouvez tester vos plugins sur le Core sans Jquery ni Bootstrap (oui on a rendu le Core bootstrap less aussi… 
).
Pour cela, éditez le fichier desktop/php/index.php et mettez la variable loadJquery à false : $loadJquery = false;. Par contre attention, vous ne pourrez pas rouvrir l’éditeur si vous fermez la fenêtre puisqu’il a besoin de jQuery. Mais les devs ont généralement un accès direct aux fichiers de leur alpha.
Bref, tout ceci pour vous tenir au courant des évolutions du Core, qui ne sont pas … légères ! Et les performances de l’interface sur cette 4.4 sont juste pas comparables … 
A tout réécrire on est aussi, forcément, tombé sur des bugs ou incohérences ici et là qu’on a bien sur laissé 
.
Aux devs de plugins, pas d’inquiétude, tout a été pensé pour éviter au maximum de casser quoique ce soit. Testez vos plugins en alpha, si quelque chose ne va pas on essayera d’apporter une solution. Pour l’instant, rien ne presse pour les plugins puisque tous ceci ne sera dispo qu’à partir de la 4.4. Mais un jour … Doc dev.
En attendant la beta 4.4, on entre dans une phase de stabilisation de l’alpha où il va falloir dénicher le moindre petit bug… tout ayant été récrit, il y en a forcément ! Le top serait de remplacer les qql libs dépendantes de jQuery qu’il reste, afin de proposer une 4.4 full $less sur laquelle pourront s’appuyer les plugins plus tard.
Merci kiboost pour ce GROS travail de refonte du code de Jeedom. Et au vu de ce que tu annonces, sera très visible 
Ta présentation de l’évolution me donne envie de ne pas attendre la Beta pour tester.
Est-ce que ça veut dire qu’il est aussi préférable de nettoyer toutes présence de jQuery dans le code des plugins (pour les aopel AJAX, ou sur les templates) ?
Comme j’ai essayé de le dire, je pense que c’est beaucoup trop tôt pour les plugins. Ça voudrait dire les mettre en minimal require 4.4 qui n’est même pas encore en beta. La 4.4 a maintenant deux fichiers, dans core/dom/ domutils et domui qui fournissent tous les outils pour gérer les ajax et pleins d’autres trucs. Et forcément, pas dispo avant 4.4.
La 4.4, au delà de rendre le Core indépendant de jquery et boostrap, pose les fondations et les outils/libs sur lesquels pourront s’appuyer les plugins sur les versions suivantes. Mais pour moi tant que 75/80% des users ne sont pas en prod dessus, c’est trop tôt pour les plugins.
Encore tout frais, on a remplacer toutes les tables datasorter par du full js ! Avec une lib plus maintenu, qui reste une très bonne base (pas mal de forks), qu’on a repris et développée.On perd le resize des colonnes, à voir si on en refait un ou pas …
Reste la lib jstree …
Bonjour Kiboost.
Les choses évoluent vite cotté MQTT, et je m’interroge sur la faisabilité, plus encore, la facilité de mettre en place un type d’installation / architecture permettant d’avoir plus de béta testeurs.
(A commencer par moi ! 
)
car cela deviendra sans aucun risque pour eux (nous) !
Je m’explique :
J’ai 2 SmartBox (une qui tourne, et une en dépannage) et un NAS, mais comme vous l’avez dit d’autres auront un vieux PI, NAS, etc
je pourrais donc avoir une architecture comme :
Ainsi, l’installation peut tourner sur la béta, mais à n’importe qu’elle moment, je peux éteindre la Smart Béta, démarrer la Smart Stable, et vice versa, (sans avoir à me soucier de mes réseau Zigbee et Zwave qui restent déportés sur le NAS), et ainsi que le commun des mortels (sans VM et tout le tralala) switch facilement de stable / béta / stable.
Akenad a sortie un de ces fameux RETEX hier.
Je croix comprendre que, grâce au avancées sur MQQT, déporter tous les contrôleurs sur un NAS sera donc bientôt presque facile !??
Avec un bon tuto / RTEX sur :
Beaucoup pourront tester…
Sans criser…!
Je précise / insiste : C’est une QUESTION !! 
BIS : Je ne dis pas "il suffirait de… " (je ne me suis pas encore lancer dans l’aventure du MQTT alors impossible d’affirmer quoi que ce soit) mais après pas mal de lecture, envie de vous demander SI « Vous semblerait-il possible, grâce aux avancés de l’intégration de MQTT de…? »
(car si OUI, je vais sagement attendre ce moment là…)
Vous souhaitant une bonne journée.
Dans la théorie c’est pas impossible, mais faut quand même tout mettre en place pour que çà tourne bien.
Et en alpha/beta on envoi souvent des séries d’ordres à des équipements, donc si derrière ce sont de vrais équipements de prod, pas facile au quotidien … Sur mon alpha j’ai pas mal de scénarios qui tournent souvent, tous les jours, pour bouger des trucs, envoyer des events, collecter tout çà en log timeline etc … Alors si madame vois les volets et les lumières bouger sans arrêt, l’alpha va finir enterrée au fond du jardin 
C’est noté !
Merci pour ton retour.
De toute façon c’était plutôt un « A mettre dans un coin de sa tête » !
Pour un jour, quand les base du MQTT seront bien solide dans Jeedom.
D’ici là, l’idée aura eu le temps de faire du chemin chez toi…
Pour info, nous venons de poser la dernière pierre du jQueryless !
Vous pouvez tester vos plugins sur le Core sans Jquery ni Bootstrap. Pour cela, Réglages > Système > Configuration, onglet équipements, Core js (dev).
Le core est donc maintenant totalement indépendant ! Seul l’éditeur de fichiers a encore besoin de jquery, et il le load, donc même en Mode js, il fonctionne.
L’alpha ne devrait donc plus beaucoup bouger, place à la chasse aux bugs !
Est-ce que les plugins devront migrer vers cette nouvelle version, et perdre la compatibilité avec la version précédente ? Ou bien est-ce qu’on pourra avoir plusieurs branches pour conserver la compatibilité avec l’existant, ou un autre mécanisme de rétro-compatibilité ?
Bonjour
Nous ne ferons pas plusieurs branches c’est trop compliqué a maintenir mais on ne fera pas en 4.4 de plugin qui marcheront pas en 4.3 (hors nouveau plugin) du moins pendant les premiers mois de la 4.4
Voir quelques messages plus haut : Core Alpha -> Go v4.4! - #10 par Piug
Le Core a toujours quelques trains d’avance sur les plugins, c’est normal. Et adapter les plugins est bien trop tôt, il faut attendre que la 4.4 se répande … 
4.4 le core y passe
4.5 les plugins peuvent y passer + possibilité des deux systèmes
4.6 les plugins y passent
Pour y aller progressivement
