Dans jeedom, il est possible de rendre visible ou non des commandes.
Il serait intéressant en plus de pouvoir rendre les commandes inactives.
Le core permet déjà quasiment de faire cela, il manque juste une ligne dans le fichier cmd.class.php ainsi qu’un mot clef à ajouter aux widget.
J’ai testé et ça fonctionne bien sans régression.
Un exemple d’utilisation : quand ma télé (l’équipement est un virtuel) est éteinte, les boutons sont inactifs.
@Salvialf je ne comprends pas pourquoi tu as rejeté ma pull request… Tu dis que le core ne peux pas intégrer les spécificités de chaque plugins, et je suis d’accord avec ça, mais là, c’est bien une fonctionnalité core que j’ai proposée, pas spécifique à un plugin !
Salut @scanab,
Déjà Tu as effectué cette PR sans aucune explication, nous ne pouvons pas deviner ce que tu as derrière la tête.
En l’état, après y avoir à nouveau regardé en détail, ça semble bien répondre à un besoin spécifique personnel. En effet, s’il s’agit d’une nouvelle fonctionnalité du core alors toutes les commandes action doivent être mises à jour en conséquence et des outils/options intégrés au core pour définir, entre autre, ce setDisplay('readonly',1)… Cela va représenter au final pas mal de code à écrire et à maintenir pour une histoire d’affichage. Sans compter qu’il faudra également documenter tout ça.
Un widget custom, avec paramètre optionnel par exemple, semble tout indiqué pour répondre à ta demande.
Avec un widget custom, ce sera compliqué à modifier par scénario… En tout cas, je ne vois pas comment.
Et si je fais une PR avec tout le code dont tu parles, elle sera refusé ? Je veux bien le faire, mais pas si c’est refusé par défaut.
J’avoue que pour un projet open source, j’ai un peu de mal à comprendre le processus de contribution…
Tu propose un widget y’en a 20 en desktop et pareil en mobile …
Et les setter getter dans les class etc ?
Aucune explication de comment ça doit marcher, être intégrer dans des plugins etc.
Regarde les premières 4.3.x le nombre de problèmes suites à des pr acceptés justement. Un peu de sérieux, open source c pas fourre tout …
Dsl mais à un moment ça déborde … on se tape des journées à debugger/fixer des PRs, nous aussi on est open source, jusqu’à un certain point.
Pas d’énervement 
.
Je ne propose pas de widget justement, mais juste une manière d’accéder à un fonctionnement du core qui existe mais n’est pas accessible : désactiver un input.
C’est @Salvialf qui propose de faire plutôt un widget, moi je ne trouve pas ça optimal.
L’intégration dans les plugin n’est pas vraiment un sujet, ce n’est pas le but. Dans ce que j’ai fait, je l’utilise avec le plugin virtuel sans aucune modification de celui-ci.
Ok, il faut que j’explique un peu plus. Mais avant de reproposer un PR, je souhaite juste savoir si mon boulot va aller directement à la benne ou non…
Ton PR était justement sur UN widget Core. çà veut dire que derrière on dois adapter tout ceux là de la même façon
Et l’intégration dans la class cmd pour le gérer, pour que pas seulement toi mais tout le monde plugins etc puissent l’utiliser.
J’admets mon tors et me propose de tous les adapter si je refais un PR.
Ok, idem ci dessus. C’est vrai que moi j’ai utilisé un bloc code dans un scénario.
Pas de soucis, et dsl me suis pris la tete sur un bout de code.
Mais comprend qu’on peu pas tout accepter comme PR … Y’a des conséquences derrière.
Pour ma part je ne vois pas l’intérêt d’ajouter cette option dans le core Jeedom alors que chacun voudra sa propre manière de cacher/afficher différemment/désactiver des commandes.
A la base tu as un bouton on/off sur ton équipement qui montre son état donc s’il est off pas de raison de cliquer sur une action. D’autre part Jeedom est suffisamment ouvert pour que tu puisses faire ça simplement, c’est d’ailleurs tellement simple que tu n’as pas percuté sur tous les tenants et aboutissants en le faisant ! Pour finir ça fait bcp de code juste pour un affichage différent dans certains cas…
Bonjour,
Petite question complémentaire pour comprendre l’idée:
C’est juste visuel ou c’est supposé aussi bloquer la commande si utilisé via scenario ou assimilé (commande virtuel, action après exécution…) ou depuis api ou app mobile etc?
Si c’est juste visuel, j’ai l’impression que ca peut être géré dans un widget du coup, donc sans changement core.
Si c’est partout, ca veut dire que tous les plugins officiels et tiers doivent être adapté pour gérer cette nouvelle option et ça bonjour la galère
Une fois de plus, l’idée n’est pas ajouter une manière de cacher afficher quelque chose, mais de donner l’accès à la fonctionnalité déjà existante dans les styles du core qui active ou désactive un input. Donc pas différentes manières de faire.
J’avoue ne pas comprendre ce que tu veux dire.
Peut être que je n’ai pas compris comment faire ça sans modification du core, mais dans ce cas je veux bien une explication : je veux juste ajouter la classe CSS préexistante ‹ disabled › à une commande via un scénario.
Juste visuel sur l’ihm : ajout de la classe CSS ‹ disabled ›. L’idée est que si je rend les commandes invisible, la tuile se retrouve super grande et vide…
Oui, juste en ajoutant une petite classe CSS déjà existante dans le core : ‹ disabled ›
Tu reprends le widget de ta PR et dans ton scénario :
$cmd->setDisplay('parameters', ['disabled' => 'disabled'])->save();
Oui « juste » pour ton besoin personnel comme je le dis depuis le début. Parce que sinon c’est pas « juste » ajouter une classe CSS mais du code à ajouter de partout comme nous sommes 3 à te l’expliquer.
Je ne penses pas que ce soit juste pour mon besoin personnel au vue des quelques likes de ma proposition…
Que je me propose de faire
Ma question est simple. Si je fais le job, un travail qui ne me servira pas à moi seul ni à un seul plugin à priori, ,est-ce que oui ou non, ça partira directement à la benne ? Parceque si c’est le cas, je ne vais pas perdre de temps à le faire.
Je pense avoir été clair, je t’ai même donné la solution en une ligne. Tu ne veux pas comprendre, ce n’est que de l’affichage ça n’a rien à faire dans le core. Il ne suffit pas d’écrire les fonctions, il faut les documenter et les maintenir et pourquoi ces options d’affichage et pas d’autres ?
Donc non pas la peine de faire de PR pour ça.
Hello,
Idem si on parle D’affichage c’est le rôle du widget.
et à la liste des implications, j’ajouterais alexa, Google home, homekit etc… on fait quoi ? « Oui mais j’ai indiqué disabled pourquoi je le vois dans alexa ? »
Alors non, tu n’as jamais été clair. Mais là oui, tu l’es, ça ira à la poubelle. Je n’ai jamais voulu imposer une solution, juste demander à ne pas travailler pour la communauté pour rien.
Pour info, le core gère beaucoup d’affichage. Et si un utilisateur défini une commande comme non visible, elle sera tout de même interprété par Alexa pour reprendre ton exemple.
Pourquoi ces fonctions d’affichage et pas d’autre ? Je te répondrai plutôt pourquoi pas d’autre justement ! Un produit est fait pour s’améliorer continuellement, c’est ce que demande les utilisateurs de nos jours. Un logiciel statique est un logiciel mort.
Je ne dit pas pour autant que cette évolution en particulier est indispensable ni même une bonne idée, mais c’est votre réaction qui est détestable.
Je suis un des premiers utilisateurs de jeedom, bien avant la création de l’entreprise. Je sais que ça ne me donne aucun droit pour autant. Je lis depuis longtemps sur ce forum des critiques sur ce qu’est devenu Jeedom sans m’en mêler, mais je commence à mieux comprendre.
Je dois dire que je regrette amèrement l’époque révolu de @Loic qui était toujours avenant, même avec sa concision qui le caractérise.
Une fois de plus, ce n’est pas le fait que vous refusiez une évolution qui me dérange, mais la façon de faire.
Et pour info @Salvialf , je ne sais pas si déplacer ce sujet dans une partie du forum uniquement visible par les développeurs est une tentative de masquer les dissensions, mais en tout cas, c’est certain que comme ça les utilisateurs ne pourrons pas donner leur avis …
Sur ce, bonne fin de soirée.
Tu me fais bien rire !
Tes arguments sont fallacieux… Je ne m’étendrai pas mais tu as le statut dev ce sujet a donc totalement et légitimement sa place ici !
Et oui jeedom est un outil formidable, la preuve il répond direct à ta demande avec une ligne dans un scénario ! C est y pas merveilleux ça ?
Quand à l’évolution de jeedom, heureusement que du tri est fait et que l’optimisation du core est recherchée. Tout ce sujet en est un parfait exemple.
Faudrait que tu m’expliques en quoi mes arguments sont fallacieux, dans la mesure où je n’argumente pas dans mon précédent message…
Ensuite, ce n’est pas parceque je suis dev que je ne dois m’adresser qu’à des devs !
Et enfin, j’ai bien dit que je ne remettais pas en cause l’acceptation ou le refus d’une PR, mais la manière de faire.
Mais bien content d’avoir égayé ta nuit 