Au vu du résultat je pense aussi que finalement un peaufinage pourrait suffire pour les inlines CSS je vais essayer de regarder ça demain voir comment nettoyer et me motiver a faire des Widgets icône qui prennent en paramètre l’icône on et off ça serait bcp plus simple.
Si tu veux je te file mes css, mon darksobre customisé et le custom.css
Il faudrai vraiment les nettoyer pour eviter toutes les contradictions css, même niveau performance c’est pas le top.
Ainsi que le template cmd.info.numeric.default
A voir si tu peux ajouter des cmd.info.numeroc.horizontal et .vertical
Il manque aussi le data-category dans le plugin météo (pihole c’est bon mais l’update est pas encore passée)
Faut aussi que tu nous fasse des beaux select !! Comme ceux des widgets des zones qivivo sur mon screen.
Dans l’ensemble même sur les pages équipements etc je suis beaucoup plus doux là !
Pour la div legend de l’objet, sur la gauche avec une seule rangée on aura pas la place d’afficher tout le résumé 
Et faut voir ce qu’on peux faire comme système de grid !! Quitte a interdire la modification en hauteur sur toutes les valeurs, on pourrait forcer un ‹ pas › entre deux valeurs.
ex : 110 → 130 → 150 → 180 → 210 → 240 → 270 → 300
Parce que sérieux, les screens de Jeedom avec des widgets pourris et pas deux tuiles de la même hauteur, çà lui rend pas justice …
Après va quand même falloir tester tout çà en bootstrap 4. Et supprimer la webapp !
A voir la page scénarios, et les répercussions sur les autres pour les gros boutons en haut.
Y’a aussi des problèmes d’alignements ici et là, faudra tout checker.
Et une fois qu’on a un css propre et un moteur bootstrap 4, on ajoute le switcher et on fait le thème light !
Et sinon, y’a qql’un d’autre ici ? Vous en pensez quoi ceux qui disent rien 
C’est très beau ! Sobre et efficace 
Bonsoir,
vraiment bien, me plaît beaucoup 
L’idée de rationaliser la taille des tuiles en hauteur (mais aussi en largeur) est très bonne. Peut-être réduire encore les possibles à partir d’une valeur minimale à définir suffisamment versatile. Ex: 140, 285 (avec 5 d’espace vertical), 430.
L’autre sujet majeur est la suppression de la webapp, à remplacer par la version desktop responsive. C’est le facteur qui fera monter en flèche la jauge WAF 
Mais si bootstrap n’est pas dispo sur mobile, c’est une grosse contrainte non?
J’aime beaucoup les screens, c’est classe
Bootstrap marche en mobile ça pas de soucis juste l’interface mobile actuelle ne s’en sert pas…
1 « J'aime »
AAAAAAAAh ok !!
Ben oui, c’est pour çà qu’il faut la jeter 
Est-ce qu’il ne faudrait pas créer une board pour la V4 ? Je pourrai créer plusieurs sujets sur des trucs, pages etc qu’il faut retravailler. Salon des betas → CoreV4 ?
çà permettra aussi de ne pas mélanger plus tard les discussions de bugs/maintenance en V3, et celles sur le V4.
Parce que là, le sujet commence à être long, et on commence à peine 
Oui mais c’est les icones pro donc pas compatible opensource…
Pour le board j’ai fait la demande a alex
Merci, j’espère ne pas y prendre trop de place 
1 « J'aime »
Dans l’absolu il en faut pas tant que çà. on/off, presence etc … On peux les refaire …
1 « J'aime »
Bonjour,
Alors si je peux faire un petit retour sur l’interface jeedom pour mon premier post ici .
Il faudrait globalement un croisement entre le mode dashboard et le mode design.
Pouvoir de base définir son Template (responsive) sur le dashboard, y choisir ses menus, sous menus, et pouvoir disposer de plusieurs format standard de widget à appliquer à la vollée sur des virtuel ou groupes de virtuels.
Jeedom à un super mécanisme en place avec ces deux composants et si perso j’avais la possibilité de vous conseiller une direction ça serait donc celle ci
Il ne manquerait plus qu’un système de grille modulaire pour obtenir un style un peu plus en adéquation avec ce qui a été fait sur l’affichage mobile (pas l’app)
Hello,
je verrais bien:
- coté serveur : PHP pour la partie moteur, « business logic » et accès base - idem pour le coeur d’un plugin
- une API REST json - extensible pour accueillir les fonctions des plugins
- coté client : HTML CSS Javascript exclusivement dédié à l’affichage. (construit à base d’Angular par exemple) - extensible pour l’affichage d’un plugin
Deux monde s’opposent:
- JQuery et Bootstrap ont été des techno qui ont dépoussiéré l’approche du web. Elles permettaient d’apporter de l’interactivité sur un jeu de pages statiques générées par le serveur.
- Angular ou ReactJS (et autres nouveaux frameworks) vont à l’inverse permettre de créer des applications web (déclinées nativement en versions mobile/desktop/native mobile et native desktop) complètement dynamiques, qui font le focus sur la partie affichage et orienté utilisateur.
Quand on a besoin d’animer quelques pages HTML, jQuery et Bootstrap font très bien le job.
Pour bâtir une application complexe (telle qu’est Jeedom) et permettre à l’utilisateur de la manipuler avec facilité depuis n’importe quel device, un framework dédié est nécessaire. Il permettra de faire plus facilement mieux avec moins. Beaucoup d’initiatives open source autour du DesignMaterial sont concentrées pour mettre l’accent sur la usability. Concepts qui sont bien plus faciles à prendre en compte dans du code dédié exclusivement à l’affichage.
Certes la transition n’est pas facile, mais elle peut être progressive en proposant très tôt l’API JSON sur la base de la version actuelle Jeedom 3, et proposer petit à petit dans la nouvelle UI, les fonctionnalités qui font la force de Jeedom.
Et il sera possible de faire évoluer l’interface utilisateur de Jeedom indépendamment du serveur (sauf si cela nécessite un changement dans l’API REST). Et inversement.
Et même si migrer vers Angular (par exemple) pour la partie cliente n’est pas retenue, Séparer le code et introduire une API REST est à mon sens LA tâche prioritaire.
my 2 cents…
Je suis plutot d’accord dans l’ensemble enfin je l’étais jusqu’a regarder angular, reactjs et vu et sur les 3 framework je me retrouve avec le meme soucis : les plugins en gros les 3 partent du principe qu’il n’y a pas d’ajout dynamique de composant. En gros la quand je lance jeedom je ne sais pas comment un plugin va afficher son widget, il peut confier la tache au core ou dire moi j’ai mon visuel. Et quand il a son visuel le core va le chercher sauf qu’avec angular et autre bien ils veulent tous les composants au moment de la compilation mais dans jeedom c’est pas possible je ne peux pas dire au dev ben faut m’envoyer votre widget (composant au sens angular/react/vue) et je vais le compiler dans le core et dans la prochaine stable vous allez pouvoir vous en servir.
C clair que là c’est tout l’interet de jeedom qui tombe d’un coup !!
Salut @Loic
Cet article explique la façon de créer une application Angular qui charge des plugins « on the fly » : How to build a plugin/extensible application architecture in Angular 5+ | by Paul Ionescu | Reshape Digital | Medium
Est ce que à un moment ce ne serait pas non plus la bonne approche pour uniformiser le rendu général de jeedom d’interdire justement aux devs de trop diverger de certains cadres que tu mettrais en place.
Si tu pars sur des composants de base modulaires pas besoin de devoir en ajouter de nouveaux.
tu déploies au fur et à mesure des releases de nouveaux templates si besoin mais déjà à partir d’une liste de départ il y a de quoi gérer 95% des cas des plugins actuels.
Une direction intéressante qui a été prise est celle de home assistant sur lovelace je trouve. si tu veux zieuter ils ont mis en place une liste de composants plutôt intéressante https://home-assistant-lovelace-gallery.netlify.com/.
Je trouve notamment les approche quand il y a des support type image (valable par exemple pour du chromecast, camera et autre sur jeedom) vraiment pratique et bien plus intégrée qu’un gros pavé qui va disproportionner toute le bloc de l’objet dont il dépend
Personnellement, je en suis pas pour interdire, mais pour expliquer et conseiller.
Oui çà m’énerve les dashboard tout pourrit avec des tuiles jamais de la même taille, qui se bloquent les unes les autres, et des graphisme degeux.
Mais:
- C’est d’abord un choix de l’utilisateur
- C’est aussi ce qui fait la richesse de jeedom, toutes ces possibilités de pouvoir faire finalement ce qu’on veux
- Finalement, çà peux aussi donner des trucs complètement différent mais sympa. J’ai vue passer un design dans un look russe rétro, et si je ne ferai pas çà, c’était bien fait et çà marche.
Donc c’est aussi à Jeedom de montrer le chemin, de proposer des plugins (officiel / conseillé) à l’interface soignée, etc.