Fork plugin Widget

Bonjour @ tous,

Petite question à l’attention de la team Jeedom:

  • Serait-il envisageable de forker, modifier et proposer personnellement le plugin widget sur le market des plugins en V4 ?

Quelles pourraient être les éventuelles contraintes ?

Pas sûr d’avoir les compétences pour y parvenir mais si la team n’y est pas opposé je pourrais déjà essayer et voir ce que je serai en mesure de mettre en place…

…Quand je dis « team jeedom » je t’inclus dedans @Loic

C’est vraiment juste par curiosité pour savoir ce qui serait adaptable et quelle serait votre réaction si le plugin apparaissait via un tiers sur le market ?

Bonjour,
En V4 le core ne l’utilise pas dans le Dashboard, je ne vois pas comment tu pourrai l’utiliser !
Par contre si tu a des idées de template (widget) et même l’envie d’en faire n’hésite pas à nous soumettre l’idée :wink:
Plus le core a de template widget en v4 plus on pourra faire de chose :wink:

Bonjour,
Personnellement je suis pas pour ça risque de créer de la confusion pour les utilisateurs. Je pense qu’il vaut mieux améliorer le systeme internet de widget du core (j’ai déjà une liste pour la 4.1 d’amélioration) et comme le dit alex voir les widgets les plus demandé pour les ajouter.

Je suis bien d’accord avec l’idée d’ajouter des widgets au core dans l’avenir.
Mais en plus de la notion de « widgets les plus demandés » je pense qu’il y a la notion de « widget qui manque cruellement » : c’est à dire une info ou une action qui ne peut pas pour le moment être visualisée de manière satisfaisante.
Je vais prendre un exemple: une direction sur 360° (vent, soleil, …) dans Jeedom 3.x on pouvait la représenter par une sorte de flèche sur un cadran ce qui ne me semble pas idéal car je ne sais jamais s’il faut prendre la flèche comme un indicateur qui pointe sur la direction en question ou comme une girouette dont la pointe indique la direction vers laquelle va le vent. Dans Jeedom 4.x, si on veut rester limité aux plugins du core, on ne peut la représenter pour le moment il me semble que par un affichage de l’angle en degré en texte ou une horrible jauge sur 180°.
Je ne pense pas que si on fait un référendum ce type d’info apparaisse dans le palmarès et pourtant à mon avis il manque cruellement.
Franchement si on vous dit que le vent souffle à 203° combien d’entre nous sont capables de monter la direction avec leur main ?
Par contre si on dit que le vent souffle sud-sud-ouest je suis sûr que c’est plus parlant pour tout le monde (cf Point cardinal )
Je suis sûr qu’un widget basé sur cette idée serait la meilleur solution pour les plugins météo et autre.
Bien sûr ceux qui préfèrent une valeur numérique auraient toujours le choix puisque cette possibilité existe déjà.
Il est déjà tout à fait possible de créer un tel widget avec le template info numeric multistate et soit des images inspirées de la rose des vents soit des textes comme N, S, SO, SSO
Problème mineur certes mais ce n’est qu’un exemple. Et qui montre aussi la richesse des templates multistate.

Bonjour @Alexandre,

Merci pour le retour :slight_smile: ! Effectivement je n’avais pas pensé à la possibilité de créer un template directement je vais m’y essayer dès que possible.

@Loic: Tu es bien ok pour pour d’éventuels pull-request dans ce sens ?

Merci pour vos réponses en tout cas.

Bonne journée

Oui pas de soucis pour les PR dans ce sens, par contre je préviens je vais être pointilleux dessus

@vedrine ton exemple est deja possible en v4 très facilement par les template multistate avec un test type : si #value# > 0 && #value# < 90 alors affiche XXXX

@Loic oui oui c’est pour çà que je disait « Il est déjà tout à fait possible de créer un tel widget avec le template info numeric multistate et soit des images inspirées de la rose des vents soit des textes comme N, S, SO, SSO » mon idée était simplement qu’un tel widget soit dispo pour éviter à tous les utilisateurs intéressés de refaire le travail.

A ben ya juste a me donner le code a mettre sous la forme :

	'heatPiloteWire' => array('template' => 'tmplmultistate','test' => array(
						array('operation' => '#value# == 3','state' => '<i class=\'icon jeedom-pilote-eco\'></i>'),
						array('operation' => '#value# == 2','state' => '<i class=\'icon jeedom-pilote-off\'></i>'),
						array('operation' => '#value# == 1','state' => '<i class=\'icon jeedom-pilote-hg\'></i>'),
						array('operation' => '#value# == 0','state' => '<i class=\'icon jeedom-pilote-conf\'></i>')
					)),

Je l’ajoute dans la configuration et c’est bon

Hello,

Je suis un peu perdu sur cette partie.

J’ai deux trois widgets perso assez poussés, genre l’hygrothermographe ou les volets avec ce genre de rendu :

image

N’étant pas chez moi c’est dur de vous montrer les possibilités du widget, mais il réagit sur le fond en fonction de l’heure et de la météo.
Oscillo ou battant classique, ou coulissante
Il y a une porte de garage aussi.
et ça ne sont pas des photos mais du code trouvé codepen dont l’auteur est d’accord pour le partage, il a aussi Jeedom de mémoire.
D’autres exemple sur des virtuels :



image
image

C’est à reprendre/améliorer, mais ça manque cruellement selon moi.

Il y a aussi en exemple dans ma tête celui pour les vannes popp qui est utilisé par plusieurs personnes sauf erreur de ma part.

concernant celui sur les fenêtres, je pense qu’il faudrait voir à se mettre d’accord car il y en a plusieurs qui trainent un peu partout et qui ne sont pas tous aux mêmes niveaux, ou au pire, avoir effectivement un template ou l’on adapte les images. Mais je ne dis pas que c’est facile.

Mais le soucis c’est qu’il faut leur associer un packet de commande additionnelles quand on’applique certains widgets.
Autant pour l’hygrothermographe, j’ai des idées sur l’amélioration possible maintenant que j’ai pu avancer sur la compréhension du code, autant pour les fenêtres, c’est plus compliqué.
Ca n’est pas dans ma top list pour l’instant, mais pour que je sache vers quoi je dois m’orienter.

Les fenêtres ça mériterait un plugin pour y indiquer, la partie météo/ horaire pour l’image de fond et juste choisir ses ouvrants en indiquant le type (coulissant/oscillo/etc)

Bonjour,

C’est compliqué la, les widgets sont très beau ya rien a dire, on pourrait les integrer mais gerer les multicommandes non, la c’est compliqué deja pour nous mais un utilisateur lambda j’en parle meme pas.

Dans l’idée on pourrait juste l’état de la fenêtre (ouvert/fermer) pour le jour nuit en js sur l’heure avec un nuit et jour fix

Ou et c’est la que ca demande bcp de boulot tu affectes le widget a toute les commandes, il se masque tous sauf le 1er et chacun remonte sont état au premier. Je pense c’est faisable faudrait tester sur le hygro

Oui on verra ce que ça dit dès que j’ai du temps et si besoin, je peux partager le code si besoin.

Oui je veux bien histoire que je fasse la base

Voici le ZIP avec les images, les fonts et le code.
cmd.info.numeric.HygroThermographe_TaG.zip.pdf (3,0 Mo)
il faut enlever l’extension .pdf pour obtenir le zip

Merci je l’avais recuperé du market, je viens de pousser en alpha/beta le widget.

Attention j’ai fait enormement de nettoyage (plus de gestion de taille de texte de batterie et signal), la tu as juste température et humidité. Important ca se base sur les générique type il est donc important de bien les avoir mis correctement

Heu j’ai du mal à suivre là ?! Tu vas inclure tous les widgets tiers dans le core ? …Juste HygroThermographe ? Pourquoi celui-là et pas d’autres ?

…J’ai sûrement raté un épisode mais je m’étonne de voir un widget tiers inclus dans le core direct comme ça. Du coup je fais des PR en incluant mes widgets (dont certains doivent être utilisés par de nombreux utilisateurs) dans le core et c’est bon ?

Non non mais c’est pas du tout ce que j’ai fait… On va inclure certain widget tierce dans le core mais sélectionné on va tout mettre ca va être ingérable. Pourquoi je suis partie de lui ? Car je voulais un widget utilisant des multiples commandes pour vous faire un exemple pour pouvoir faire ce type de widget tout simplement. Lui était simple (le code de base), mais si tu regarde le code je l’ai vraiment vraiment simplifié je pense ya 2 à 3 fois moins de ligne de code (mais en contre partie il fait moins de chose)

OK je comprends mieux merci d’avoir pris le temps d’expliquer.

donc tu utilises ‹  ›#generic_type#‹  › pour identifier le type de données si j’ai bien compris ?! ça ne recherche que dans l’équipement concerné par le widget ?

C’est pas une recherche c’est un peu plus compliqué :

  • tu appliques le widget sur toute les commandes concernée par celui-ci
  • ensuite le widget va faire en sorte de ne s’afficher que une fois (en masquant tous sauf le 1er)
  • puis chaque widget (meme les masqué) mette a jour le 1er (celui visible)

Dernière question: Comment intégrer un Template ?

J’ai ajouté un fichier *.html avec tmpl dans le nom mais ce n’est pas suffisant:
tmplswitch

Où faut-il déclarer ce template afin de pouvoir le sélectionner ici ?: