[OH3] Main UI - New „main_widget“ - development and testing [deprecated]

Sounds great - I like the idea of a whole of house summary for lights, shutters, doors - something like @ysc cards but lets get @Dimitris to make something beautiful for the page having a bit more space

No, please send me the latest code, as we also might need some adoptions like the light widget (passing the groupd into the widget and doing the repeater logic in there.

Take @Dimitris design suggestions and start implementing missing widgets, reqork some of the existing designs to give it an equal look and feel.
Al in all, do what you like, I will just try to get the logic and functionality right…

Most important, write the introduction :wink:

Is it worth trying to template a framework for widgets - maybe a parameter of an array of widget types to cater for everyone wanting different things? For example security isn’t really a focus for me but my amplifier source/volume etc is so if I could swap out those but maintain a templates approach the community could make these sub widgets and switch them out depending on what ea h person wants

Yes, sound like a good idea

News :
I have added @RGroll 's Weather Card to the project to be shown on the fist page now.
There is als a new " locationTitle: " config for the main_widget, where you can enter your location name to be shown in the weather widget, if not set, it defaults to “Somewhere”.
I have only changed the name of the widget to fit our naming scheme, nothing else.

A our first post has exceeded the forum limit for postings, We soon have to split the widget codes from the first post to seperate ones and only add links…

@Team. Something serious happened. I’ll be back in a week or two. The biggest sorry i’ve ever give to my life.
Here is the latest files:
Widgetsv2.pdf (493.0 KB)
Allign.pdf (69.9 KB)
Navbar_details.pdf (71.9 KB)
Allign_v1_details.pdf (68.4 KB)

At his point and until my return in this project, @Nic0205 will take care for design fine tuning.
See you all in a week or two.
@hmerk @JustinG Please continue to help him with your unique unmistakable way.

@Nic0205 -Please archive this, just in case.
HOMEUIv7_draft_experim [Recovered].pdf (760.5 KB)
See you Pal.

Sorry to hear, wish you all the best !

1 Like

At All,
a spend some thoughts about again restructurin this new topic a bit to overcome the posting limits.
Therefore I will create seperate topics in the marketplace category and add links in the first topic.
This will alow us to add changelogs and make installation for users easier.
Adding a alpha tag should make clear that this is still work in progress.

Done !

@Andrew_Pawelski In my perspective, the default selection for Home, must be the Scenes menu -at least in this very first version.

This maybe is the most wanted task now. Can anyone do that? The concept now is very clear, that we need is someone to do the heavy lifting in writing.

Hey Dimitris,

sorry to hear such bad news. Hope all thing will be managed.

I wish you all the best

Looks cool - even though the color theme suits not really - but one thing after the other.

General question: Following @Andrew_Pawelski approach - at a first step we could define a standard height for the widgets. I will try this for light and shutter widget.

This will be a bit difficult, might work for the simple lightswitch, but not for the more complex color light.
But in general, we should define templates and a color scheme, one for light mode and one for dark mode. We than can autodetect the used mode…

Mmm…Dimitris shown for the same widget a minimal widget and also expanded. I think to start to think if the card-content could be visible and hided, otherwise need to start to think that all eidgets need to be expandable like my rollershutter card…
Nasic functions when minimized and all controls when expanded.

I’m sorry for this news…take all the time you need. We’re all with you.

After nearly a week of stewing on the question, I had finally given up hope and earlier this morning, I was going to report that sorting the buttons and then reordering them for the looping menu was, in fact, impossible. Before I got around to posting, I had a flash of insight and have now developed a method for doing just that. It’s only slightly more cumbersome than the previous looping menu version, but can take into account an optional sorting parameter to pre-sort the buttons. It can also be adapted fairly easily to sort by other parameters as well (basically any potential key in the object returned by the repeater).

Here’s the PoC code:

uid: demo:sorted_looping_menu
tags: []
props:
  parameters: []
  parameterGroups: []
timestamp: Sep 11, 2022, 4:46:14 PM
component: f7-row
config:
  style:
    align-items: center
    display: flex
    flex-direction: row
    flex-wrap: nowrap
    height: 2em
    justify-content: space-between
    width: 100%
slots:
  default:
    - component: oh-button
      config:
        action: variable
        actionVariable: buttonIndex
        actionVariableValue: =(vars.buttonIndex || 0) + 1
        iconF7: chevron_left
        iconSize: 2em
        style:
          flex: 0 0 auto
    - component: oh-repeater
      config:
        for: menuArray
        fragment: true
        in:
          - name: Al's Room
          - name: Betty's Room
          - name: Charlie's Room
          - name: Dining Room
            order: 10
          - name: Elizabeth's Room
          - name: Front Room
            order: 2
        map: loop.menuArray_source
      slots:
        default:
          - component: f7-row
            config:
              style:
                display: flex
                height: 2em
                justify-content: center
                overflow: hidden
            slots:
              default:
                - component: oh-repeater
                  config:
                    for: menuButton
                    fragment: true
                    in: =loop.menuArray
                    filter: loop.menuArray_idx == 0
                    map: (loop.menuButton.order || 0).toString().padStart(3,'0') + '&' + loop.menuButton_idx
                  slots:
                    default:
                      - component: oh-button
                        config:
                          style:
                            flex: 0 0 auto
                            height: 2em
                            order: =(((vars.buttonIndex || 0) % loop.menuButton_source.length) + loop.menuButton_source.length + loop.menuButton_idx) % loop.menuButton_source.length
                          text: =loop.menuArray[loop.menuButton_source.sort()[loop.menuButton_idx].split('&')[1]].name
    - component: oh-button
      config:
        action: variable
        actionVariable: buttonIndex
        actionVariableValue: =(vars.buttonIndex || 0) - 1
        iconF7: chevron_right
        iconSize: 2em
        style:
          flex: 0 0 auto

In the code, any element without an order parameter is assumed to be order 0 and any elements with tied order options are left in the sorting of the original array. This is exactly how the order parameter for flexbox sorting works which is intentional because this method takes advantage of that.

Based on that if you look at that the dummy array in the code the final order should be the bedrooms in alphabetical order (they all have order 0 so they’re left in the original order) followed the Front Room (order 2) and then the Dining Room (order 10):
image
image
image

The trick that makes this work without the ability to do more advanced sorting in expressions is to use two nested repeaters. The first repeater contains the actual array, and, in fact, maps the entire array to each of it’s elements. Then the next repeater does three things: 1) it uses the first repeaters array is its input, 2) uses the filter property to only do its repeating during the first iteration of the first repeater, and 3) maps its output to a value that contains the property to sort by and the original index of the value.

This works because it gives us the original array (the first repeater’s output) to refer back to while still being able to transform the second array (which causes a loss of most of the data) for easy sorting. The combination produces a final array that includes all the original data in the desired, sorted order. Then we can apply the menu looping modifications directly to the order parameter and let the flex box do the work on the second reordering.

There’s just a little bit of work to do to make sure that this extends to a more real-world example with an array derived from items and the defaultWidgetOrder metadata, but I don’t see any theoretical reason why this should not work.

There is no need for apologies; life always comes first. Best wishes, whatever the serious event may be.

1 Like

perhaps the idea I have didnt quite get understood. I was thinking that say the bottom option for security could be swapped out for say an AV button - all via paramaters - this might be a Key-value paramater that when set shows the correct button and then a particular subwidget (so no security zones but perhaps aplifier settings) this way the community could make their own widgets for their own needs and “plug” them in - the template idea is just that - the styles and colors are all set and its just a different set of items shown?

If Im way off and this is going against the design principles or its making things very complex please discard, Im jsut thinking of my own use case (I dont have security, scenes or HVAC) and it may well be the same for others

OK, this version is now workable for various repeater item lists and is responsive to the Default Widget Order Index metadata.

Example:
image
With Attic and Basement having widgetOrder metadata:


Produces the menu items in the desired order with looping:
image
image
image

Widget Code:

uid: demo:sorted_looping_menu
tags: []
props:
  parameters: []
  parameterGroups: []
component: f7-row
config:
  style:
    align-items: center
    display: flex
    flex-direction: row
    flex-wrap: nowrap
    height: 2em
    justify-content: space-between
    width: 100%
slots:
  default:
    - component: oh-button
      config:
        action: variable
        actionVariable: buttonIndex
        actionVariableValue: =(vars.buttonIndex || 0) + 1
        iconF7: chevron_left
        iconSize: 2em
        style:
          flex: 0 0 auto
    - component: oh-repeater
      config:
        for: menuArray
        fragment: true
        sourceType: itemsWithTags
        itemTags: Floor
        fetchMetadata: widgetOrder
        map: loop.menuArray_source
      slots:
        default:
          - component: f7-row
            config:
              style:
                display: flex
                height: 2em
                justify-content: center
                overflow: hidden
            slots:
              default:
                - component: oh-repeater
                  config:
                    for: menuButton
                    fragment: true
                    in: =loop.menuArray
                    filter: loop.menuArray_idx == 0
                    map: ((loop.menuButton.metadata && loop.menuButton.metadata.widgetOrder && loop.menuButton.metadata.widgetOrder.value) || 0).toString().padStart(3,'0') + '&' + loop.menuButton_idx
                  slots:
                    default:
                      - component: oh-button
                        config:
                          style:
                            flex: 0 0 auto
                            height: 2em
                            order: =(((vars.buttonIndex || 0) % loop.menuButton_source.length) + loop.menuButton_source.length + loop.menuButton_idx) % loop.menuButton_source.length
                          text: =loop.menuArray[loop.menuButton_source.sort()[loop.menuButton_idx].split('&')[1]].label
    - component: oh-button
      config:
        action: variable
        actionVariable: buttonIndex
        actionVariableValue: =(vars.buttonIndex || 0) - 1
        iconF7: chevron_right
        iconSize: 2em
        style:
          flex: 0 0 auto

@JustinG: Really really nice - I thank you so much!

@hmerk: I would try to test this cool stuff and then update the main_widget code.

How do we coordinate us? Should I update the code at GitHub - you have a look at it and then publish to the add-on thread or any other way?

I would try to have a look at it this evening…