Also could the options inherit from commandDescription metadata by default? In essence both are k=v maps.
Working on the same widget, why doesn’t title: =items[props.item].label work? I’ve tried on an oh-input-card on a page and with a custom widget, but the title just remains blank as if it was not specified. Even specifying an item like title: =items.ITEM_NAME.label does the same thing. I see all over the place you can get item states like items.ITEM_NAME.state…
that items object are not the complete items actually, just their state (and eventual displayState with the transformations applied). It’s retrieved from a completely different API than the items endpoint.
For now if you want an option list the only way to do it is configure an “options” action and select the item - it will open an action sheet when you click the widget.
@ysc, @RGroll, it’s becoming more and more clear to me that we will need some sort of step by step tutorials for creating a custom widget. I took a shot at it using what I could glean from what gets built when I create stuff on the Overview page but’s its clear to me that I don’t have a clue what I’m doing and not getting to where I need to be.
What I was thinking was showing how to create a Chromecast widget showing the now playing image, player controls, volume control, a stop button, and the currently playing app. Bonus points for having it be hidden when the Idle channel is ON.
I was able to build something close to what I was thinking but it’s not one coherent widget. It’s a block with three rows and three disjoint cards.
Even when I add this to my Overview page and set the parameters (very nice feature BTW) it ends up taking the full width of the page and it creates three separate rows of widgets. I was thinking that it would sit there nice and contained within the row and column I created and dropped it into.
I’m sure there is something simple I’m missing here. Maybe I misunderstand the differences between masonary, blocks, and cells or something. like that. And given this is a case where I want this to become a step-by step tutorial, I need to understand what I’m missing, or is this something that just can’t be done.
I really think we need some sort of ste-by-step for Pages like we have with the Things, model, and as of yesterday rules. Am I heading in the wrong direction? Or am I missing something simple?
I totaly agree and also trying to write down some notes of the steps I take while creating my widgets.
But I realized, that it’s kinda hard finding a balance between ‘basic’ custom widgets (without too many classes and styles, which might overwhelm people) and those that are fullfills a real life usecase AND looking good but mostly depends on the usage (and styling) of standard components.
Sounds like a good idea starting with a widget which would be useful for a lot of people and also fullfills the above mentioned limited complexity - what applies here I think.
You can set-up the width of a widget via the ‘Column Options’, individually for each page. The fact, that it creates 3 rows of widgets is related to the use of the component ‘oh-grid-row’.
But this isn’t anything to worry about at all, as the height of the row depends on the largest widget it holds.
The components ‘oh-block’, ‘oh-grid-row’ and ‘oh-grid-col’ are components which were intended to use specifically to match the layout pattern of the pages and so it`s by design that they might extend over multiple rows.
If you just don’t want you components ‘flying’ exchange you ‘oh-block’ root component with a ‘f7-card’-
Which is more arguable, is the usage of pre-made widget-components (like ‘oh-image-card’, ‘oh-player-card’ and so on) inside another widget, whom have styles and classes already applied to them and were build upon the idea that they works as a standalone widget. They are easy to set-up and can be used without fiddling around with the YAML-structure whatsoever.
You can do this, but might loose some flexibility and be forced to remove some of the already applied classes again to make them look nice inside a custom-widget. (like removing borders, shadows and so on)
All of the things I’m talking about here are based on my current knowledge and the experiences I made so far - so take them with a grain of salt. I’m sure @ysc could give you a much more profound answer here.
Another approach (which I personally prefer) would be to use ‘smaller’ components (which the pre-defined components are based on) and rearrange / style them to your needs.
As an example let’s take your widget-idea from above, split it up and try to recreate it with ‘smaller’ components…
From what I understand, you would like to have a frame with 3 rows of contents (1st row: Image of the played media; 2nd row: player controls on the left / volume control and stop button on the right; 3rd row: Name of the currently used app) inside and some basic logic (like hiding elements based on item-status).
So the first thing here would be some card around your content to make it look like a single usable widget. ‘f7-card’ would be the right choice here, as its meant to act as a holder for different widget-components and you can already apply some basic informations like a title, footer, background-color and so on.
title: Chromecast widget example
Now we create the first row inside that card, which should hold the image of the played content. So ‘oh-image’ would be a good fit to that requirement as we can define an image-url here as well as an item, which holds an image(-url).
You might ask, what the reason for the f7-block component is, which the content (f7-row) is sitting in.
We will use this as a container around all the components inside the content area of the widget which we can apply styles and classes to later on. The ‘style’ part inside the oh-image component just makes our image responsive in width and height.
I added an image url for demonstration purposes to the ‘oh-image’ component.
The second row should have 2 columns in which we can put the different components. Each column will adapt to the available space which it sits in - so it will use 50% of the row each in our example.
Instead of ‘oh-player-item’ (which is normaly used as a component inside a ‘oh-list’) we use the standalone version of this control-component which is called ‘oh-player-controlls’ inside the first column and doing the same for ‘oh-slider’ (instead of ‘oh-slider-item’) as well as ‘oh-button’ (instead of ‘oh-label-item’) in the second column.
Now to the 3rd row which should show the title of the currently played app.
This could be realized with a simple component named ‘Label’ which is nothing else than what it says, a label…
As we`re using this basic component, we have to apply some styles to it to make it fit our needs.
How to find the correct wording for the needed control/ element ( or whatever wording should be used in this context), for example a list from which an element could be selected.
How to dynamically fill such list (with items).
I was struggling to find this one as well, Yannick to the rescue! You have to do it via an action, specifically the “options” action. I used a label card and linked the label and action to the same item. The options are pulled automatically from commandDescription metadata or can be provided in the widget properties.
I’m not positive on this but I think there is both a .displayState and a .state on the item. I would expect that you can define displayState either from the item label or the state description metadata. I’ve not played with that though. so I could be easy off.
As for the rest i think I need to suggest and get this out some. But over all your version of the chromecast widget looks exactly like what I was going for. I agree that in the beginners tutorial we want to stick as much as possible to what can be done without editing the code by hand. More to follow after I play with it a bit…
Yes it’s an object but it can have either only state or both state and displayState, depending on whether you have a pattern/transformation applied or not.
To be on the safe side in your expressions you can use this syntax:
=items.MyItem.displayState || items.MyItem.state
It will use displayState and fall back to state if it’s not truthy.
Or http://materialdesignicons.com since that’s the library used by home assistant it gets regular home automation related updates. What would be cool is to be able to reference them in f7-icons. That remains to be seen.