Rethink UI about hue-lights HOT 73 CLOSED

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:

from hue-lights.

Hi @vchlum, sorry for the long radio silence.
I haven't looked into it for a while, I was kinda too occupied, but I took some time to click through it again.

In general it seems to work pretty well, thumbs up, I do have some (small) pointers though:

• The sliders jump around selecting light or rooms (seems to switch briefly to the overall brightness), distracting and kinda weird.
• I personally still have the preference to open the room menu as default or the light menu when a room is selected. Previous menu seems illogical and just the rooms one does not make when you selected one.
• Adding to that I would like to be able to set a default room per bridge (now you have to select it again after restarting or even locking your screen). Controlling a certain room where you are located, so opening it from this point of view makes more sense.
• Control menu is empty for light only having brightness, it should be disabled (or not there).
• Rename the control menu to Color & Temperature.
• Clicking on the room menu should not reset the selected light.
• Make the margin / spacing of the menu item bigger (especially height), it feels very cramped now.
• Another possible nice feature would be to disallow a fully closed state of all menus, if you click on an open menu it will close but open the menu you came from.
• Margin / spacing and alignment in the settings menu is terrible.

Some nice to have features:

• Possible default bridge on wifi connection.
• Make bridge settings like the network connection menu (using the plus sign to add bridges and having the entertainment stuff etc. in the darker box).
• Add entertainment options to the bridge settings.
• Move notification lights to bridge settings.
• Maybe add "All" to the Lights and Rooms & Zones menus, it's not really that obvious it controls all of them.

Now for some major design considerations:

I still feel that the lights menu should have the room as title (and controls), the control menu can then have the light as title (and controls) and not be a submenu when it doesn't have color or temp control. Currently it just doesn't seem to feel quite right.
This however leaves the room menu hanging. I think it would be best located in the bridge menu, everything currently in there seems not really that relevant in daily usage. I personally would remove the switch menu item and the accessories (who uses this? maybe for in the settings?), add the bridge switch to the top, separator, the rooms & zones menu content, separator, settings (make this an option in the settings itself) and refresh (is this really needed?) and open this menu as default when no room is selected. Also the "All rooms & zones / lights" don't need to be removed anymore, clicking on it will just open the next menu.
This would cleanup the menu significantly (removes the lights and control menu) and make it a bit more logical in my opinion.

Just my 2 cents again.. ;)

from hue-lights.

To clarify the last idea:

• [ bridge 1 ] (switch all on / off)
  • Switch [ bridge 2]
  • Switch [ bridge 3]
    • separator
  • All Rooms & Zones
    • separator
  • Room 1
  • Room 2
    • separator
  • Zone 1
  • Zone 2
    • separator
  • Settings (optional?)
  • Refresh (needed?)
• [ selected room ] (switch on / off & brightness) (can be selected as default)
  • All Lights
    • separator
  • Light 1
  • Light 2
• [ selected light ] (switch on / off & brightness) (not a sub menu when no extra features supported)
  • Color Wheel (if supported)
    • separator
  • Temperature Slider (if supported)
• Scenes (when existing)
• Entertainment Areas (when existing)

from hue-lights.

• The sliders jump around selecting light or rooms (seems to switch briefly to the overall brightness), distracting and kinda weird.

Please, elaborate. I do not understand. The sliders of light should always be the brightness of the light. The sliders of a group are the average value of the brightness of lights that belong to the group and are ON in the moment. If you are turning lights on/off the group sliders are jumping. I consider it to be desired behavior.

Everytime you select a room or light the slider of the menu it represents briefly changes into some value (without color) before it takes the value of the selected room / light, even the on/off button changes state.

from hue-lights.

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.

from hue-lights.

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.

from hue-lights.

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...

from hue-lights.

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.

from hue-lights.

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....

from hue-lights.

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.

from hue-lights.

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.

from hue-lights.

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.

from hue-lights.

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.

from hue-lights.

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.

from hue-lights.

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

from hue-lights.

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.

from hue-lights.

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).

from hue-lights.

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

from hue-lights.

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...

from hue-lights.

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.

from hue-lights.

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).

from hue-lights.

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.

from hue-lights.

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! :)

from hue-lights.

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.

from hue-lights.

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.

from hue-lights.

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

from hue-lights.

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.. :)

from hue-lights.

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.

from hue-lights.

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.

from hue-lights.

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.

from hue-lights.

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).

from hue-lights.

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.

from hue-lights.

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?

from hue-lights.

OK. Yes, the slider on the lights menu would be the same as on the group menu. Doesn't make sense to have a duplicate slider. The bridge provides only one brightness data for a group. (make sense, but the data seems bugged to me sometimes - later I can make an average group brightness from the real state - TODO)

Agree, looks really good now! Still not sure if I should make it the default menu because some people can be used to the original menu, which still seems suitable for smaller instances.

I will look into the item's background colors based on light color... but I am afraid of having a similar/same color for the label/slider/icons.

from hue-lights.

Yes true, fair point, it still needs to be at the control menu though.

Regardless of it being the non default option, I think it will be very similar if the group menu would be open at default.
I respect your decision to not make these menu's open on default though.

About the color, just make sure that white never really is white, for the white themes black won't be an issue. ;)

from hue-lights.

Control on Control menu done. First, I thought the brightness would be next to the color wheel. I will remove the brightness next to the color wheel.

I made the group menu open by default and added an option to settings for remember menu state.

The color issue is not so easy:-) As far as I know, a lot of users use ubuntu, which looks like this:

That is why I added the bright/dark icon pack.

Basically, we should expect other themed distributions too... so any color on the foreground is theoretically possible. So I need to check the real color of the foreground and act accordingly.

from hue-lights.

Oh, I realized you wrote: "white themes black won't be an issue" right after clicking the comment button... so you considered other themes. Maybe the background colors could be optional in the settings. For sure.

from hue-lights.

I made the background color for single lights possible. It is only on the light items. I do not know how to create the color transition for groups like in the original app, and one-color background for a group doesn't make sense.

I had to slightly skew the colors by decreasing alfa part of the color. With alfa 254, it looks like this:

Not readable for most of the colors. I set the alpha to 170/254. Also, the algorithm for getting RGB out of bridge data doesn't seem perfect yet.

from hue-lights.

I agree that this makes the text unreadable, my idea was not to make the background of the whole item this color though.
I meant the background of the slider (bar) and switch, so just the blue color, way more subtle and shouldn't interfere much with the normal look.

I would also just make the "Back to Rooms & Zones" just the same item as everything else (button and slider and just the Rooms & Zones title), perhaps putting a separator between it like between the rooms and zones and keep it at the top would be a good idea though. I would also remove the room / zone selected from the menu since it's already the tom menu then.

Also the default menu should be light when a group / zone has been selected and don't reopen it on extension menu close, but before you open it again.

Isn't mixing the color of the groups an option? Haven't checked how it will look like, but I mostly use scenes which have similar colors so mixing them would result in a recognizable color I assume.

I also use ubuntu btw, so indeed my menu has a light theme.

Another thing, the group slider turns on all lights on and set's the brightness the same for all lights. That doesn't really make sense, it should keep the relative brightness of all lights and keep the ones who are off off. The app does this correctly.
It also doesn't seem to show the current brightness of the group.

from hue-lights.

Created some color wheels, hope it's useful:
https://github.com/2nv2u/hue-lights/tree/main/media

from hue-lights.

The color wheel looks much better, thanks!

...and it works well.

Although, the gnome-shell theme style wasn't able to recognize the SVG format. A format error was shown. (I added it as a 'background-image' to the St.Bin's style. I do not see any other way how to put it there..) Other apps considered the format to be valid, so I used Inkscape and "saved it as", which removed your header and the file was actually almost twice the size... Maybe some small error in your file? Could you please check? I used version 64.

Would you be willing to create also a bar for the white temperatures transition, please?

Oh, I see... To change the color of the sliders and switches make sense. That would require changing the style of the objects too. WIll look into it.

The group brightness is a known bug to me. It uses the data from the bridge, this is what the bridge provides... Will try to improve it. They probably do that using the individual lights data, not group data. I will need to do it this way too.

from hue-lights.

I'll see what's off, I thought I added all necessary tags, I wrote a script to generate it from scratch, having to draw it was too cumbersome.. ;)
I liked you using the 64 one, it's a little more stylish and also doesn't show artifacts like the higher count ones do.

I'll also look into the the temperature one, do not forget to put the switch and slider on the control menu item too!

from hue-lights.

I have bad news regarding the switch color. They use SVG for on/off state. No color change possible.

I can only change the color of the sliders:

Control top-menu item already contains the switches, but only if a light is selected. For a group, the switches are already on the room/zone top-menu item. No need for a redundant switch.

from hue-lights.

Also the default menu should be light when a group / zone has been selected and don't reopen it on extension menu close, but before you open it again.

I am sorry I do not understand this.

Also, I think I will hide sliders in case the light/group is off. This will actually help with fixing the group brightness issue.

from hue-lights.

Hmm, that sucks (and is kinda stupid IMHO). Too bad (for now), don't color the slider control knob though.
Maybe I'll change the switches to have a transparent background so we can set it ourselves.
It is however possible in a browser to alter SVG's at runtime, but doing this in GJS seems like begging for torture.. :)

Control top-menu item already contains the switches, but only if a light is selected. For a group, the switches are already on the room/zone top-menu item. No need for a redundant switch.

Got it, I just looked at your screenshot and missed it.
Do remove the brightness slider from the control menu though.

I am sorry I do not understand this.

What I mean is you switch to the default menu's when the extension menu deactivates, you can see it happening before it fades away. You need to do this when you open it, not on close.
The same effect also still happens when you haven't selected a room yet.

Also, I think I will hide sliders in case the light/group is off. This will actually help with fixing the group brightness issue.

What do you mean? If the whole group is off shouldn't it be just in the off state anyway?
Personally I like the consistency more and the ability to set the brightness immediately is a bonus.

Can you btw set the version="1.1" attribute into the tag in the SVG I made for the color wheel and see if that works?

from hue-lights.

You are right, the menu was opened on state-changed, not on "open". Fixed.

Personally I like the consistency more and the ability to set the brightness immediately is a bonus.

I consider it is a nice bonus too. Now, the lights are turned on with brightness-slider change, which results in controlling/turning-on the whole group by the group slider. It means if you use a group slider it will turn on the remaining lights in a group. In order to defuse this behavior, the nicest thing would not turn on lights with slider change. IMHO, that is why the original app hides the sliders for deactivated lights/groups. I will try to get the nice behavior.

Tag to version 1.1 did not help. The tool gitg is also not able to display your SVG. I think you can use gitg to get to know when it is OK.

from hue-lights.

I checked gitg, seems to work fine with the old images here, can you just commit the code (without the image) so I can debug it directly?

from hue-lights.

Sure, done.

from hue-lights.

Mixing the color for group sliders works very well. Done.

from hue-lights.

Fixed it, it just didn't like the comment section...

Added the temp bar too!

The wheel looks nice, some minor things though, clicking on the top of the wheel changes the color into cyan, the light itself doesn't change though. Also the corners (grey area) is also sensitive to clicking, that's not really nice.
Is it possible to put an icon (like the knob of the slider) on the location of the color on the wheel?

About the colors of the sliders, this doesn't work for the ambiance (and just white) lights.

from hue-lights.

Thank you! It looks much better now. I added the new bar in RGB mode (need to find out how to convert from RGB to color temperature, seems to be quite unusual). I used a convert table before your bar.

I do not know how to resolve the sensitive corners yet. It is a known issue to me. Not sure if it's possible to change the St.Bin from rectangle to circle or something like that. Will investigate, no promises now.

The new color features work in RGB only (for now). Tomorrow (Hopefully, but holidays ending and I need to do my regular work), I will add the features for the ambiance/temperatures of white. I keep it on top of my TODO.

from hue-lights.

Np, at least I could contribute a little too!

I've been thinking about the selection of the groups, zones and lights.
Now the selection of the group changes the top menu of the group while the selection of the lights changes the control menu.
This behavior should be consistent.
1 solution is to change the title of the light menu to the room / zone or change the title of the light menu to the selected light. Going for the first option means you won't have to add the "going back" items in the sub menu anymore and thus possibly the nicest option. What do you think?

I hope in all you like how it's turning out and that is was worth your effort, at least I appreciate it a lot, thanks again!

Small thing, change the color on mouse down, not on click, that way you can "drag" around to the color you like.
And one more thing, the open / close animation glitch (just opening without animating at all) when no room is selected is still there.
What is the temperature of white switch doing?

from hue-lights.

It is a much better tool with this menu. I think, I will set the new menu as the default menu:-).

Concerning menu consistency, I think it will be always broken because we have both ALL and ANY group light switches. I think both are important.

• Option one means to have "Rooms & zones" on top-menu item all the time and change the top-item light menu instead, right? I like how you can see only the room you need/select. More importantly, we have the switch for ALL lights on the light menu and ANY light on the group menu. One of them would be removed.

• IMHO, option 2 is not an option because clicking on the top-menu item "lights" will revert the control menu to control all lights in the group. This feature would miss, but it could be resolved by adding the "back" item for lights too. And again, we would miss the ALL lights item on top-menu item.

Mouse down event is not possible. I think "button-press-event" is the best possible.

Temperature of white switch was for color bulbs without the white ambiance. If you turn it off the white color is not in kelvin but in RGB. (I have also non-Philips branded color light like this) I believe I will be able to get rid of this switch.

from hue-lights.

It is a much better tool with this menu. I think, I will set the new menu as the default menu:-).

Great, nice you like it too!

Concerning menu consistency, I think it will be always broken because we have both ALL and ANY group light switches. I think both are important.

I'm not sure if your explanation holds up, consistency is always more important, trust me.
Why is the ANY / ALL difference so important anyway, what use case does it have? You can even argue it's confusing...
I would probably be ok with the switch showing the ANY state and switching would turn all off and go to last state, effectively undoing the previous action, currently that just turns on all lights making me unable to cancel my turn off action.

Your all light concept kinda represents it being one, which in itself is fine, but then making it a light in the menu again would make more sense and having a slider to control the brightness would be something to consider again too, just like any other.
Group brightness is relative (like the ANY notion) and light brightness is then absolute (like the ALL notion).
In all, I'll think about it a little more too...

clicking on the top-menu item "lights" will revert the control menu to control all lights in the group.

This is also inconsistent behavior with the group / zone menu for example.

I believe I will be able to get rid of this switch.

This would be great, it's not self explanatory and seems to be able to be taken care of programmatically.

from hue-lights.

Understood. So then a see an option with changing the light top-menu item with the selected light (instead of on control) and let's have the "back" item in the lights menu too. The back item can carry the ALL light switch.

I use the ALL switch to turn on the remaining lights in a group (in case some light is already on). Without it, you would need to turn on the remaining lights one by one, or turn all off and then on.

from hue-lights.

And one more thing, the open / close animation glitch (just opening without animating at all) when no room is selected is still there.

Hmm, please elaborate. I thought the whole menu should just fade in with the room&zone menu opened without seeing opening it. That seems OK to me. Or maybe I just can not find the glitch...

from hue-lights.

Clicking on any menu Rooms & Zones, Light or Control when you haven't selected a room and have one of these menus already open makes the clicked on menu open instantly without animating while the menu you were in shows the closing animation.
This does not happen when you have selected a room, so only when the room menu shows "Rooms & Zones".

I'll come back on the consistency issue a little later.

from hue-lights.

I always use foo.menu.open(true) for the menus. Try the latest code but I find out: On my 4K display, it is OK and the animation is there. On a smaller screen, the animation is super fast. My second bridge with two bulbs is animated even on the smaller screen as expected. I think the speed of the animations correlates with the number of items and size of the screen but it doesn't work well and this is the result. I checked Gnome40 and the menu animation is missing for all. I can only guess that they removed the feature instead of fixing it:-) Edited: in gnome 40 the animation is just much faster for all menus

from hue-lights.

You're right that the animation is there, but it's not based on the actual length of the menu.
I think you are starting the animation (opening the menu) before you finish adding / hiding items in both the Groups & Zones and Lights menu. So try to finish setting the menu up before opening it.

from hue-lights.

I don't think so. At least I wasn't able to find such a bug... I checked and the menu and it is constructed before opening.

I created a mini extension to test the menu. The result is that once the scroll bar appears in the submenu, the animation is not nice and it is super fast. With 4K resolution, only the last 100-item submenu causes the fast animation. As the resolution is lower and the scrollbar is on more submenus, the animation is also fast for those submenus.

That is why the animation is so fast with numerous lights.

from hue-lights.

Hmm, then it's a gnome shell bug, guess we have to live with this for now then. ;)
Thanks for trying to figure it out though...

You seem to have find a way to color the switches, great!
Not a fan of coloring the knob though...

The temp bar seems not to function properly, just clicking a little beyond the white makes the light completely blue, anything after it has no effect anymore (I did made the slider bluer (hotter) then the lights can achieve, otherwise you can't see the difference on the screen, want me to change it to the actual range?)

Also the color wheel is not representing the color I clicked, especially in the upper regions.
Clicking on blue makes the lights more violet then blue (this also applies to the background color of the slider, it's not the color I clicked on).

from hue-lights.

Yes, I used colorize effect on the switches for the on-state. Not possible to use on some part of it only. Unfortunately, I do not see a way to make it better without modifying the SVG. Make it e.g transparent and change the background would not be good because the background is square. The colorized background would be around the switch too. (Same problem as the corners of the color wheel being active).

Temp. bar fixed. You created the temp bar 2200K-9200K, which looks better than 2200K-6500K (the hue lights are capable of). I checked the original app and it seems like they also use relative temperature, so no need to change the SVG. Now, the temp bar controls the range 2200K-6500K.

Concerning the color wheel, it seems pretty precise to me. Tested mostly on the Philips hue play. The violet blends into the blue in the top section... So it is there. Do you use Philips Hue branded lights? If not, we could need some user-calibration for other brands. Anyway, I will investigate it more.

The color of the sliders is a color that is got from the bridge (XY color converted to RGB). The color from the color wheel is picked and converted to XY. The conversions may not be perfect. Please, try to use this tool and send me the RGB of imprecise color, I will investigate.

from hue-lights.

The latest commit contains a consistency fix, based on your second option:

change the title of the light menu to the selected light

from hue-lights.

Hi @2nv2u, do you have more comments? No rush at all, just asking because you were pretty active and then got silent. I did some testing and it seems ready for release to me. I would like to know whether to wait for more comments from you. I squashed the commits on the new-menu branch.

from hue-lights.

Hi @vchlum, yes yes, I didn't disappear, just too busy that's all. I'll check it out asap ok!
I'll also come back on the consistency issue we discussed earlier.

from hue-lights.

Hi, @2nv2u thank you again for your help! Do you have any more ideas for this topic? Are you satisfied with the UI/UX?

from hue-lights.

Thank you @2nv2u very much for your time and for the valuable input. I will process it. Although, it could take some time. I will think about the major design adjustment. Thanks again.

PS: I intend to create the settings from scratch once I will have time for it (I learned javascript and gjs on this extension so this was the first attempt:-)). I am aware it is terrible:-)

from hue-lights.

No problem at all! If anyone should be thanked it's you! I merely shed some "light" on it, that's all. :)
Don't take my terrible statement as a bad thing though... ;)

About the redesign consideration, I was thinking to play around in my fork to see what feels more natural and too much, just thinking about it is usually not enough. I might be tinkering with it when I have some spare time.
To me the less is more philosophy is leading, if something isn't used much, feels counter intuitive and/or making things more complicated it's better not to have it at all. This isn't an easy task though.

Keep it up! Your dedication is admirable!

from hue-lights.

I will keep track in this post of what has been done. This post will be edited.

Things to fix:

• The sliders jump around selecting light or rooms (seems to switch briefly to the overall brightness), distracting and kinda weird.
  • FIXED ec99253
• I personally still have the preference to open the room menu as default or the light menu when a room is selected. Previous menu seems illogical and just the rooms one does not make when you selected one.
  • DONE 0bb467f
• Adding to that I would like to be able to set a default room per bridge (now you have to select it again after restarting or even locking your screen). Controlling a certain room where you are located, so opening it from this point of view makes more sense.
  • DONE b9b0515 - although in a bit different way - the selected room/zone and light is saved for each bridge and it is restored on the rebuilding menu. It works similar to the requsted feature.
• Control menu is empty for light only having brightness, it should be disabled (or not there).
  • FIXED b9b0515
• Rename the control menu to Color & Temperature.
  • DONE b9b0515
• Clicking on the room menu should not reset the selected light.
  • FIXED b9b0515
• Make the margin / spacing of the menu item bigger (especially height), it feels very cramped now.
  • FIXED 74d7673
• Another possible nice feature would be to disallow a fully closed state of all menus, if you click on an open menu it will close but open the menu you came from.
  • DONE a5d38b1
• Margin / spacing and alignment in the settings menu is terrible.

Some nice to have features:

• Possible default bridge on wifi connection.
  • DONE 11044d6
• Make bridge settings like the network connection menu (using the plus sign to add bridges and having the entertainment stuff etc. in the darker box).
• Add entertainment options to the bridge settings.
• Move notification lights to bridge settings.
• Maybe add "All" to the Lights and Rooms & Zones menus, it's not really that obvious it controls all of them.
  • DONE b9b0515

from hue-lights.

• The sliders jump around selecting light or rooms (seems to switch briefly to the overall brightness), distracting and kinda weird.

Please, elaborate. I do not understand. The sliders of light should always be the brightness of the light. The sliders of a group are the average value of the brightness of lights that belong to the group and are ON in the moment. If you are turning lights on/off the group sliders are jumping. I consider it to be desired behavior.

from hue-lights.

Hi @2nv2u! Could you please check the default branch and share your opinion on the menu's default opening behavior? Once the room is selected, the light menu is opened by default as suggested.

My feeling is that switching back to opening the room menu by default is a bit unintuitive. You need to click on "All rooms and zones" and my concern is that it is not clear and the users would feel like there is no way back to the behavior of opening the room menu by default.

Maybe adding some small button to the selected room item for switching back could improve it?

from hue-lights.

I'll soon start investing a little bit more into the OS stuff, I'll come up with a more elaborate comment later. :)

from hue-lights.

I am closing this issue as not active. Thank you again for your help:-)

from hue-lights.