Tu peux ajouter un console.log() dans le code et regarder dans le debugger où est le problème.
Par exemple, tu dois voir les traces suivantes si tu ajoutes :
if (link_id == "") {
// frame navigation : set focus on first button
console.log('affichage du design du premier bouton');
$('#' + data.buttons[0].link + ' li').click();
}
Merci encore pour ton tuto, j’ai réussi a faire fonctionner le menu comme je veux, a une exception pret.
J’ai chercher sur ce post et sur goo…le mais je ne trouve pas la solution.
Comment faire pour que la frame du contenu soit transparente et laisse apparaitre le fond d’ecran definit dans le design de base ?
Ce que je ne comprends pas c’est c’est bien le cas pour le menu qui une fois que j’ai defini la frame en transparent, je vois bien que derriere le fond d’ecran est la.
Je fais pareil pour la frame du contenu, je sauvegarde, la je vois bien que la frame est transparent, donc jusque la ok.
Par contre dés que je click sur un lien du menu, le design correspondant apparaît avec un fond gris sombre alors que le design est bien lui aussi en transparent.
Ok, merci pour l’info.
Donc attendre un correctif.
Comme contournement, je vais juste appliquer le fond à tous les design aussi et accepter le petit décalage entre le menu et le contenu pour l’instant.
j’avais opté pour le menu menuHoverShow, je préfère avoir le menu sur le cote plutot que sur le dessus, sur un ecran 1280x800 c’est préférable.
Par contre les icones du menu menuHoverShow sont trop petites et trop rapprochées.
J’ai donc modifié le code pour pouvoir personnaliser leur taille et espacement uniquement par parametrisation du fichier perso.json
j’ai rajouté deux variables :
icon-height : espacement entre les icones (en px)
icon-size : taille de l’icone (en px)
marche pas mal chez moi avec
icon-height : 50px
icon-size : 34px
je pourrais proposer une autre modif, je voudrais ton avis sur son impact potentiel …
tu définis la classe fa pour le formatage de la barre des menus.
Or cette classe existe deja (dans le core ?) et est utilisee par differents widgets chez moi, donc la redefinition de cette classe s’applique a tous ces widgets aussi, et c’est pas tres beau…
ici, je garde l’application de la classe fa, sans la redefinir, et je definis en plus une classe myfa correspondant a la classe fa initialement definie, comme ca je ne touche pas aux widgets qui utilisaient deja la classe fa.
aucun impact sur la barre de menu, mais quels pourraient etre d’autres effets collateraux ?
Salut,
Très intéressant ton post.
En ce qui me concerne j’utilise une version du menu FB$33 ou l’ensemble du design est sur une seule page et le où menu permet de se décaler dans la page.
Il y a donc également un seul menu, comme dans ta version.
Mais il n’y a rien à charger quand tu cliques sur une des options du menu puisque la page est déjà chargée.
En regardant la version que tu proposes, je me pose la question de savoir quel est le temps de réaction après un clic sur le menu ?
En effet, ce sont 2 visions différentes de gérer la navigation par menu et c’est donc à chacun de choisir en fonction du contenu de ses pages, de ses supports de navigation, de la puissance de son Jeedom, de ses priorités, etc…
C’est évident que la navigation entre écrans ne sera jamais aussi efficace avec des frames que la navigation sur un seul écran. Mais ça reste largement acceptable et très rapide. C’est l’équivalent de la transition entre designs d’un menu classique sans frame, sauf que ça passe dans une frame avec les avantages que j’ai remontés.
Pour moi, les inconvénients du menu « une page » sont les suivants :
Premier chargement pouvant être très long en fonction du nombre et du contenu de chaque écran : on doit tout charger même si on veut consulter que la première page (ce qui peut être pénalisant si certaines pages sont bien remplies)
Il n’est possible de mettre plusieurs fois un élément sur plusieurs pages du menu (pas de duplication sur ton design unique). Il faut alors passer par la création de virtuels pour dupliquer tous les éléments que tu souhaites dupliquer. Ca peut rapidement devenir complexe à gérer et à créer.
Si tu veux inverser 2 pages, il faut déplacer tous les éléments de chaque page (ou jouer avec les liens des boutons mais il faut alors modifier le code du menu lui même)
Pour un menu avec frame (et json), j’ai déjà remonté les avantages mais en rappel, en comparaison des points ci-dessus :
Il est extrêmement simple d’inverser 2 boutons juste en modifiant le json de paramétrage (inverser les 2 ids des designs concernés) sans toucher au code ni au contenu des éléments de design
Il est possible d’utiliser plusieurs menus pointant vers les mêmes écrans sans toucher au contenu de ces écrans, et sans besoin de les dupliquer (ex : menu hyper complet avec écrans supplémentaires pour tout gérer, menu typé multimédia avec seulement les liens vers des écrans multimédia, menu simple avec un nombre d’écrans limités défini en fonction de chaque utilisateur (Mari, femme, enfants, chien-ouais mais non-, etc…)
En résumé, tu peux créer autant de menus - différents - que tu souhaites sans jamais toucher au contenu des designs de contenu : seul le design des menus seront modifiés (par un fichier de configuration json, sans modification de code).
Tu peux donc par exemple utiliser un menu différent chaque jour ou en fonction de la météo, de ton humeur, … sans toucher au contenu
N’y vois surtout aucun militantisme pour ma solution plus que pour un menu à design unique , mais plus un rapide comparatif, chacun choisira en fonction de ses besoins et contraintes
Edit : ce menu fsb33 géré par frame est aussi disponible depuis le plugin #plugin-pimpjeedom en version beta mais déjà bien utilisé. Avec @Salvialf, on intégrera le maximum de mes menus actuellement disponibles en DIY pour rendre simplissime la création (et modification) de ces menus par de simples clics ! 2 autres menus sont actuellement disponibles et d’autres à venir.
J’ai adapté le menu avec des iFrames à mes besoins. J’ai commencé à créer mon design en créant un design pour chaque page du menu dans une iFrame. J’ai trouvé que les changements de pages dans le iFrame étaient peu élégants, avec apparition furtive de la roue entre deux affichages de pages. J’ai donc décidé de faire évoluer l’ensemble du theme vers une utilisation avec des sections, sur une seule page de design. J’ai modifié la structure du JSON et j’ai modifié le code pour ajouter cette possibilité de navigation par section dans une iFrame. Cela fonctionne très bien, la navigation est instantanée. Mais, car il y a un MAIS, le chargement de la page dans l’iFrame est long, très long, très très long. Au fur et à mesure que j’avançais dans le design des sections, la page devenait de plus en plus lourde à charger. De plus, j’ai multiplié quelques virtuels que je souhaitais afficher sur plusieurs sections à la fois. Face à cette lenteur de chargement de la page, je viens de prendre la décision de faire marche arrière (beaucoup de temps perdus) et je laisse tomber ce principe de navigation qui est très élégant et rapide. Je pense que cela dépendra du design plus ou moins chargé qu’on a envie de créer.
Et @noodom , je me sens bien plus à l’aise pour modifier le code html et css, j’ai beaucoup appris depuis deux ou trois semaines. Merci pour ton aide.
Salut Bruno,
Merci de ton retour
C’est le principe du menu que j’évoquais et que j’utilise depuis des années.
C’est vrai qu’il y a quelques inconvénients comme tu l’indiques et comme le détaillait noodom juste avant. Dans le cadre de mon utilisation, cela ne pose pas de problème.
Le design est long à charger, mais tu ne le charges qu’une seule fois - et après, quel bonheur d’avoir instantanément la page que tu souhaites.
La version de noodom ne manque pas d’attrait, et pourrait me tenter un jour si je me sens limité avec la version page unique (mais bon c’est du boulot de tout reprendre !).
Par contre la version que j’utilise ne fonctionne plus correctement depuis la version 4.1.17 de Jeedom. Je pense qu’il y a des fonctions jscript qui ne sont plus compatibles.
J’ai réussi à refaire fonctionner sur Fullykiosk, mais pas sur mon navigateur de Pc, et je ne maitrise pas suffisamment le développement web pour corriger seul.
Pourrais-tu partager les fichiers codes de ton menu pour que je puisse remettre le mien en état de fonctionner stp ?
Il y a souvent des soucis de rafraichissement sur les designs. Alors pour être sur d’afficher des états synchro avec les équipements, je rafraichis la page à l’allumage de la tablette. Du coup on attend trop devant elle pour prendre la main dessus. Mais c’est certain qu’une fois la page chargée, la navigation est instantanée et ça fonctionne bien. Mais bon, je suis revenu en arrière tout de même.
Je vais créer un nouveau post pour ne pas polluer celui-ci. Il faut que je prenne le temps d’apporter des explications pour bien configurer le JSON.
Je suis en v4.1.18 et je ne rencontre pas de soucis particulier sur les designs. Tu utilises peut-être des fonctions précises qui ne sont plus supportées. J’ai quelques doutes.
Mon design est issue du travail de F$B33 et noodom. Mon menu a été personnalisé en disposition verticale, à droite de la page. j’ai aussi ajouté un pied de page qui apparait à toutes les pages.
Je vais essayer de trouver le temps rapidement pour publier mes fichiers et expliquer comment les utiliser.
Je suis occupé à jouer avec le menu en vertical, et il fonctionne impeccablement.
Toute fois j’aimerai apporter une petite modification visuel et je n’y arrive pas à trouver ça dans le code.
Je suis sur une Google Home 8" résolution 1024x640 ;(
Lorsque le design se lance, le menu est réduit au stricte minimum
et comme je dois bien viser pour faire apparaitre le reste
Est-il possible de tout faire apparaitre directement au chargement du design?
J’ai déjà désactiver le « auto_reduce_menu » sur 0, pour en faire un menu ouvert permanent.
Ok je viens de voir que le 1er bouton ne s’afficha pas au complet (icône de Jeedom), je dois mieux adapter la position.
Mais ma question reste toujours. Comment avoir le menu au complet sans presser une 1ere fois sur la seule icône dispo au chargement?
