Rethink UI

[2nv2u]

Hi, I would like to present an idea in structuring the UI a bit different. I for example have 2 bridges and the menu gets way to big with all the light / groups of all bridges at the same time. Since the bridges represent a location I rarely need them both to be visible at the same time, so my suggestion would be:

Menu:

{ Bridge one }

• { Bridge one } radio button (selected)
• { Bridge two } radio button

---

• Settings (considering my other ticket, this might be a nice compromise considering you will not see this all the time)
• Refresh

---

• All accessories

Lights

• All lights

Rooms

• All rooms

Groups

• All groups

Scenes

• All scenes

In the settings you could select which option should be open by default (lights selected as default) or removing the sub menu all together for people who do not care for any of the menus. Also rooms can be something similar to the bridges and an option to select in the bridge menu. I'm not sure if sub sub menus is possible though, that would be kinda required...

I did something similar in my syncthing extension.

[vchlum]

Hi @2nv2u !

First, I am glad it works with multiple bridges:-). I only own one bridge, so multiple bridges are not tested:-(, but I do my best to get it to work too. I consider buying a second bridge just for testing and debugging:-) Maybe a secondhand bridge - because I actually don't need it:-)

I am quite sure the sub sub menus are not supported in Gnome 3.x. I am not sure what Gnome 40 brings to us, I will check this possibility.

The current UI is inspired by the original Philips Hue app, but honestly, I do not know how the original UI deals with multiple bridges... Could you share? Maybe we could inspire here.

I would suppose that some people could use more than one bridge at the same location. So, I would like to preserve the possibility to use multiple bridges without switching.

I will think about improving the UI. I really consider buying the second bridge now. It would help me.

[2nv2u]

It works fine, if they are both on the same network, it just doesn't really make sense.. You can ask me to test something anytime, so you don't need 2 for now. ;)

As for the hue app, it forces you to select a different bridge somewhere buried deep in the settings. In all very cumbersome and switching between them is too much of a hassle. For one, I would like it to have the ability to select the default bridge depending on wifi connection for example, something that might be useful for your extension too. I have 2 bridges in different places, so the wifi more or less determines where I am and it could switch accordingly.

The sub menu issue is something I was wondering too, maybe this can be done in a similar way like the sub menu in the settings of gnome shell itself works, it's a nice way of doing so and it would be familiar too. If this is possible I would even put the color wheel in a sub menu when a light / zone is clicked.

Another possible way of restructuring is:

{ name of bridge }:

• List of groups / zones with on / off and sliders (Clicking on one will open the { name of zone / room } menu with this zone / room)
• --separator--
• List of bridges (Clicking on one will change this menu to show option from this bridge)
• --separator--
• Setting
• Refresh

{ name of zone / room }:

• List of light on / off and sliders

Do you have zones created and if so how do you use them? I, for example, basically just use them to group lights together to use them as a single one (same fixture for example), so from that perspective treating them like a single light would be preferable. I don't get why they didn't allow these groups "zones" to be created in the rooms themselves in the first place.

[2nv2u]

As for the multiple bridges at one location, you need a serious amount of lights for that to make any sense and like I mentioned, switching between them in the hue app is going to make people question their existence.. ;) It is however possible of course...

[vchlum]

Thanks.

I thought the original app would be a bit more friendly for multiple bridges. So not using multiple bridges at the same time sounds fine now.

I actually use only one zone and I have all lights in this zone for the whole flat. I frequently use scenes. I have my scenes in each room and I usually turn on the lights with the scenes. ...or I simply turn on the whole room if I remember the last state of the room:-)

In your proposal, if I understand it correctly, you suggest listing the zones/rooms twice. I would like to keep the switches of the rooms/zones on the top level. Since I personally use them. You suggest putting switches of zones/rooms within the "name of bridge" item. I do not understand why listing zones/rooms twice...

I like the idea to switch to a bridge based on the connected wifi. Though my intention was that the use case with two bridges - each in a different place (different wifi) could work like this: You simply connect to wifi on the new place and pressing the button "refresh menu" would refresh your local bridge and the other bridge should disappear. If you turn on the notebook on a new location the local bridge is automatically connected no additional action needed. Does it work like this? If yes, I do not see additional value in checking the name of the wifi :-)

I would like to have the color wheel in the submenu. Thought of it for the first time but it is created from separate buttons. It would be very expensive to create it multiple times within the menu. I felt tied by the gnome-sheel when I created this part.

[2nv2u]

I'll create an example of what I mean, the whole purpose is to make the interface cleaner with less stuff, having things twice on the screen defeats that purpose. I'll keep you posted.

It's correct that if I turn of a bridge it will disappear (it shows a notification though, which is fine), if it's reachable however you see them both at the same time, that can be desired behavior of course, but in my case it isn't.

For the colorwheel, is this something useful? https://developer.gnome.org/gtk3/stable/GtkHSV.html It's marked deprecated though....

[vchlum]

I gave it a thought and I like the original-philips-app-like menu. The Rooms/Zones in top-level should have the switches - the switches easily indicate in which room is at least one light on. Which is (at least for me) a very important feature/information. To actually see it on the top level.

New menu could be like this:

• [bridge name1]
  • [accessory 1]
  • [accessory 2]
  • [separator]
  • [Switch to 'bridge name2']
  • [Switch to 'bridge name3']
  • [separator]
  • [refresh menu]
  • [settings]
• [zone 1]
  • [All]
  • [Light 1]
  • [Light 2]
  • [Scene 1]
  • ...
• [zone 2]
  • ...
• [room 1]
  • [All]
  • [Light 1]
  • [Light 2]
  • [Scene 1]
  • ...
• [room 2]
  • ...
• [entertainment areas]
  • <no changes>

In the settings, a new button "Set as default" would be available for each bridge. (or dropdown box with wifi networks maybe?) The default bridge would have the button "Unset default". Without the default bridge, all bridges would be displayed.

I don't get why they didn't allow these groups "zones" to be created in the rooms themselves in the first place.

IMHO, the answer is because 'rooms' and 'zones' are the same level objects in the data from the bridge. Rooms and zones are all "groups". Just like entertainment areas - also just "groups".

For the colorwheel, is this something useful?

The Gtk objects are fine in the prefs part of the extension. In the extension itself, the Gtk is available but not useful because you need the Clutter objects in the menu. Since the gnome-extension is single-threaded, you can not use Gtk window with some gtk color selector here. From what I know, only the used ModalDialog is available as a window and the Gtk object can not be added to the ModalDialog.

[2nv2u]

Seems ok to me, but I would suggest to put the rooms / zones into a sub menu too so that they can be hidden when you want to control lights / scenes inside. Also, since I ordered the options in a hierarchical way, I would put the entertainment menu underneath the bridge

• Bridge (shows the selected bridge name)
• Entertainment (shows name of enabled area)
• Rooms / Zones (with switches & sliders) clicking on the line will open the light menu below and change the text of this menu item to the selected room / zone
• Scenes
• Lights (with switches & sliders)
• [ Control (colorwheel etc.) optional instead of the popup and only if goup / zone / light selected that can be changed ]

I'll make a mock-up of what I mean, it will not compromise the room overview you want to be viewed instantly, don't worry. I might take some time though, I'm a bit short on spare time at the moment.

[vchlum]

I hope I understand... I like it, but honestly... I do not want to use this type of menu daily. I believe some people could appreciate such a type of menu, so I will add it to the settings. Optionally.

If you wish, see the branch new-menu. It still needs some testing and debugging, but it looks like this:

Once you could spare some time, you could tell me if this what you mean... In case you decided to test it, you need to go to settings, use the tab general, and enable "Use compact menu", which is a suitable name in my opinion.

Also, multiple bridge support is improved on the branch... but not tested. You should be able to prefer your bridge. I will get my second bridge tomorrow.... I hope. So a more stable version comes later.

[2nv2u]

Damn you're fast! :)

Don't forget to open the lights or groups menu when opening the menu from the panel, if you call menu.open(false) on it, it will be open immediately without you being able to see it opening, it will be just like the "old" menu so to say. You can make an option in the settings to select with menu should be open at default.

[2nv2u]

So when no room is selected open the room menu at default and make the room name "Room & Zones", this would be pretty much exactly like how you're plugin was before. When a room / zone is selected you could make that menu default when opened.

Maybe hide the light and scenes in the case no room is selected. (I have some code to animate this nicely in case you're interested)

You can install and check my syncthing extension to see what I mean, there I also open these submenu's immediately.

[2nv2u]

I will test it of course btw, no question about it!

[vchlum]

Damn you're fast! :)

Well, our country is in a pretty serious lockdown due to covid:-(

if you call menu.open(false) on it, it will be open immediately without you being able to see it opening

Thank you, that is useful!

(I have some code to animate this nicely in case you're interested)

If the code is not in your extension, please share. ...or just point to a line in your extension.

I checked your extension. I will address your comments tomorrow.

[vchlum]

I updated the new-menu branch with a commit addressing your comments and some miscellaneous fixes.

The compact menu remembers the last open menu and opens the menu for you. Also, fast switching between menus is possible (via item in the bridge menu).

[2nv2u]

I'll check and come back to you, thanks!

[2nv2u]

I checked your implementation, first of all, nice job!

Some pointers / (new) ideas:

Generic

• The default open menu should be either Rooms & Zones or Lights, it should not remember what it was.
  • No room selected: Rooms & Zones is open when the menu is opened.
  • Room selected: Lights, Scenes or Control is open when the menu is opened.
• Make a setting to select the default Lights (default), Scenes or Control menu to be opened.
• Make a setting to reset the room selection when the menu closes.
• I miss the sliders in the rooms / zones, these controls should be on all the rooms / zones and lights. I would also suggest putting the slider under the text to make room for the text and icons for the lights (like in the app). Now the width of the menu chances in the Lights menu because of the sliders, not very nice.
• Padding / margin in the menu and the settings should match the other settings / menu's in the whole shell.
• Slider and buttons should have the color (mix) of the light(s) as background.

Bridge

• I see both bridges at the same time, I would still suggest to select them in the sub menu of the bridge if there are more then one. Lets skip the WIFI idea for now.
• In the bridge sub menu having the refresh and settings separate seems more appropriate, you won't see this menu all the time and it's more descriptive, combining them is not necessary here.

Rooms & Zones

• When you click on a room / zone the menu should not close but should open the Lights, Scenes or Control menu like the setting mentioned above.
• When you click on a room / zone the selected item should swap with the Rooms & Zones menu text / item, so you could select the whole "home" again later if you wanna "deselect" the room in the Rooms & Zones menu now having the Room / Zone as name.
• Put a separator between rooms and zones.
• Optional: Clicking on a zone (and maybe room) should also make the Control menu available (this will allow controlling a zone / room with all lights together).

Lights

• Add light icons

Control

• Individual light menu with saturation, brightness, light warmth, set of colors and color-wheel? (Although that probably very difficult).
• If above menu would be there the selected light concept should work similar to the room selection. Selecting a light should make this menu representing the light and make the option in the lights menu Lights representing all of them. Similarly if zones / rooms would be controlled this way too.

Hope it gives some more food for thought, in all I think it would make your already nice extension even more powerful!

If you would be ok with it, I would be happy to help out in the new-menu branch...

[vchlum]

Thank you for your ideas! Appreciate! I will address them (or most of them).

• You can select a preferable bridge in the settings already. Once you click the 'prefer' button the menu will show only one bridge. If this preferred bridge would be offline, other bridges will be shown.
• When you click on a room / zone the menu is closed because I do not know how not to close. I will investigate the gnome-shell code.
• If we add sliders under the light/room names, the line would be quite thick. But I will try it. Hopefully, some St.BoxLayout could be used for this. EDITED: It looks like this: IMHO, I would not do this in the light menu. With a lot of lights in one room or zone, the menu would be too thick.
• Light icons are not included because... Philips offers an icon pack and asks for using the right icon for the right light. I also saw a list of bulbs with types, so most of them can be properly set. Anyway, you can have a non-Philips branded bulb connected to the Philips hue bridge and then I do not know which icon to use. Also, no icon combined with some icons is ugly. I decided not to use light icons at all instead of using the wrong icon or even combine icons/no-icons items.
• I will try to redesign the color control (color-wheel) later.

If you would be ok with it, I would be happy to help out in the new-menu branch...

Of course, any help is appreciated.

[2nv2u]

I don't think it looks bad, except the spacing itself, it's too crammed. Things need to be spaced out a bit.

You can select the icons in the app for lights as well, I don't know how this is stored in the data itself, but I use it, gives a visual identifier to the real thing especially in the color selector. Can you try the slider under the text in the lights as well?

Concerning the menu closing stuff, check my extension, if the activate method doesn't propagate (I just don't call the super) it doesn't close the menu, In my last version I moved the rescan option to the device menu as well but when you click on it it will open the folder menu immediately, works nicely!

Concerning helping you out, I'll see if I can do something about the spacing when I have some time (maybe this weekend).

[vchlum]

I already resolved the closing menu issue with rewriting appropriate function like this: foo.menu.itemActivated = (animate) => {};

This is how the lights menu looks like... It could be really long with a lot of lights in the room.

All the changes will be on the new-menu branch.

[2nv2u]

I personally feel both solutions aren't very elegant, I wanted to actually call some stop propagation method on the supplied event in the handlers, which to me is the most elegant way, but couldn't find any documentation about it and my trial on error searching for it didn't reveal it either. If anything I learned from writing extensions for gnome-shell, it's that the documentation is seriously crappy.

Regarding the length of the menu itself, it's kinda the result of having a lot of lights and the way they decided to set this up. I would have preferred the rooms / zones (grouping) to be hierarchical so you would be able to show just fixtures etc. instead of the individual lights. Luckily if it extends the screen it will show a scrollbar in the sub menu itself, I already have this in your old menu structure, I barely had space for the sub menu's at all already because of all the zones and rooms in both bridges.

I'll check it out again! :)

[vchlum]

I learned that the best documentation for gnome-shell is the gnome-shell code...

I still feel like remember the open-state of items "Rooms & Zones", "Lights", and "Scenes" is useful. (Ok, not items like the bridge...) I think it can be usefully substitution for the suggested options in settings. If I use scenes, there is a pretty high chance I would need the scenes opened again. Similar with lights. Honestly, I wouldn't know how to decide in the settings - what to set to be my default. Because I use both frequently. Moreover, It can also substitute the point with deselect room/zone because it will remain open if you open it.

[vchlum]

I had to revert "open lights menu after clicking on room/zone". Seems like opening a menu from 'button-press-event' of different menu cuts some important call of the original menu and the whole menu sometimes closes, and color of selected items was broken... I will investigate later. I already spend few hours with those two lines of code ...without luck.

[2nv2u]

Strange, I just changed the activate method of the PopupBaseMenuItem without calling the super and it seems to work perfectly fine, never noticed anything weird...

https://github.com/2nv2u/gnome-shell-extension-syncthing-indicator/blob/ddacad196bae43b06b72d1dd5157004f26e8ba82/extension.js#L301

[vchlum]

I honestly do not want to omit the super function. At least... unless I know what is in it:-)

The Control menu seems to be easy... I already use BoxLayout in the current color picker. It can be easily added to PopupMenuItem. First try looks good:

[2nv2u]

The super function just emits the activate event. Something registered the close method to it and thats exactly what I didn't want it to do.. :) But you're right it will prevent it emitting events completely, but since I couldn't find how to stop the event from propagating I just made sure it didn't by not emitting it at all, not very elegant, but it works. I'm not even sure if it supports stopping propagation. Regarding not opening the lights menu, that is a major UX thing to me, now it feels only the text changes while you would expect to be able to control it lights at least.

Not putting the All Rooms & Zones option in the sub menu btw will leave you not being able to go back to controlling the whole place (home), not really desirable either. I also think the slider should be on the top Rooms & Zones menu as well, you can then remove the all item from the Lights menu.

About the control stuff, awesome! :D

About the layout itself though, it's not very visually appealing, neither does it give very fine grained control. The nicest thing would be to have a full circle with a gradient to white in the center and pick the color of where you click. Just like in the app itself. I could make a nice svg (or even css style) for it but I'm not sure if it's easy to plug the colors out of it.

Another possibly easier way is to use 3 sliders and a switch:

• Switch (or button) between ambiance (color temp) and full color. This will switch rainbow to the kelvin temp scale and disable the saturation one.
• Color rainbow fully saturated row above slider 1
• Saturation row from selected color to white above slider 2
• Brightness row above slider 3

Add 4/6 buttons (circles) on the bottom which you can select (click) that will hold the chosen color so that you can click on it again with another light to also let that one use the same color.

Depending on the light itself some options need to be disabled of course, the (old) iris doesn't support the ambiance (light temp) and the ambiance doesn't support the full color option. The only white ones don't support either.

Small question, are you ok me being critical about it? I'm just trying to help in case I come over demanding or anything.. :)

[vchlum]

Regarding not opening the lights menu, I will find a way.

Please, what do you mean by "Not putting the All Rooms & Zones option in the sub menu btw will"? I actually do not understand how do you want to deselect the selected room/zone. Could you elaborate?

Sliders have been added to the top menu room/zone item. I do not want to remove the "All" item from the lights menu. There is a difference. The switch on group is for ANY light but the switch on All is for ALL lights. So If you turn on one light in the group, the group switch is on but all item switch is still off. You still can switch the all item to turn on the remaining lights in the group.

Regarding the color picker layout, if you prepare the SVG, We could test it using a built-in function in gnome-shell. There is a function for getting color under the mouse pointer. It is already used for track cursor mode in the entertainment mode.

Since you have ideas, being critical is really fine:-) No problem here.

Do you use the entertainment areas? You didn't mention anything about the UI related to it yet. If you have thoughts here, please share.

[2nv2u]

Let me know when you do, I have to do some refactoring then as well.. :)

The current Rooms & Zones misses the switch (and possibly slider) to turn the whole house on and off, it's there in the app. Considering that, if you select a room / zone now, you cannot go back to controlling all of them until the extension reloads (locking the screen or rebooting). That to me seems undesirable, you need to be able to go back to the start state, so that's why I proposed to replace (or add to the top and remove the selected one) the room / zone you selected with the All Rooms & Zones option in the sub menu.

I get your point about the difference between all light and the group, good catch, I would suggest putting the All Lights control on the Sub menu itself then, just like the Rooms & Zones.

I'll see what I can do for the color-wheel, meanwhile I made a concept for the sliders already, I like the wheel way more though. But I'll share it anyway:

I'll keep on it then, I think it starts to turn out very nicely!

No, I don't use the entertainment areas, but I'll have a look at it!

Btw the control stuff looks great! Way more useful to me like this, do however put the slider and switch on the menu item as well.

[vchlum]

Concerning the menu opening issue, I ended up with:

item.originalActivate = item.activate;
item.activate = (event) => {
    menuToOpen.open(false);
    return item.originalActivate(event);
}

...and it works like a charm.

That was a good point with the whole house... I was wondering how they do that because a group with all lights is not listed between groups... It turned out that there is a hidden group with id zero containing all lights:-) Since it is not listed, I am afraid of the need to have a special request to the bridge because of this group. Not very convenient though, but should be possible.

Your concept looks great! Although, I think the color wheel would be faster to control.

[2nv2u]

I'm not sure if what you did makes sense, calling the super would have done the same thing: activate(event){ super.activate(event); } This is the function of the parent: activate(event) { this.emit('activate', event); }

Regarding the open(false) make it open(true), then the menus will nicely animate into each other (like clicking the other menus).

[vchlum]

IMHO, it does make sense. I do not use inheritance from the popupitem here, but I create the object with the 'new' operator. Here, super belongs to another object.

Anyway, the top-menu items can control what is suitable now. Finally, I was able to remove 'all' item from the lights menu.

[2nv2u]

If you would have extended it, it would be the same then.. ;)

Regarding the Lights menu, just keep it "Lights", did you btw leave the slider out on purpose?

I'll start looking into the color-wheel. In all I think it starts to come together pretty nicely, don't you agree?