A simplified mode only for brightness control with system tray icon or panel widget

[TSultanov]

It would be nice to have system tray/panel widget to quickly control brightness of attached monitors, similar to ClickMonitorDDC Windows util.

[rockowitz]

My initial reaction was that this would make a nice, discrete, project for someone familiar with panel widgets in C or C++ to contribute. Unfortunately, it's not that simple. Changes in the panel widget need to be reflected in ddcui, and vice versa. At the very least all instances of shared library libddcutil would have to be able to communicate, probably over dbus. A more general solution would have a single instance of libddcutil running as a service, ala colord. Regards, Sanford

…

On 12/08/2019 05:28 AM, Timur Sultanov wrote: It would be nice to have system tray/panel widget to quickly control brightness of attached monitors, similar to ClickMonitorDDC <https://clickmonitorddc.bplaced.net/> Windows util. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#16?email_source=notifications&email_token=ADMGY3RDZNQWDWVZK4ME6YTQXTD45A5CNFSM4JXZ5WD2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H64EW2A>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADMGY3WLYJWWKJUG3H2IA6LQXTD45ANCNFSM4JXZ5WDQ>.

[TSultanov]

One option, I think, is to make the ddcui and panel widget live in the same process: ddcui can draw a tray icon via StatusNotifierItem protocol and clicking on "Close" icon in main UI will just hide the window leaving the program running in the background with notification icon visible. Left click on notification icon can show small panel with selected controls, similar to sound level control, and by double clicking or using right click menu user could open the main UI. I'm not sure that engineering a general solution with daemon and multiple interfaces worth it.

[rockowitz]

I've given your suggestion that, essentially, ddcui present 2 distinct UIs. I believe this is possible within Qt - how complicated it would be I don't know. ddcui internals would have to be restructured to enable this. Also, since ddcui would become a long running task, it would need to handle the situation when displays area added or removed. This requires changes to the shared library, API, and the ddcui application itself. This has been on the to-do list for some time. There's proof of concept code that uses udev to detect display addition and removal, The remaining changes have to be thought trough. Before that, however, there ares a lot of "fit and finish" tasks in ddcui that need to be addressed. Bottom line: If someone were to build the user interface for a panel widget, I would consider modifying ddcui to use it. However, this is not nearly as clean as simply having a separate application that uses the API. Thanks again for the suggestion, Sanford

…

On 12/09/2019 03:24 PM, Timur Sultanov wrote: One option, I think, is to make the ddcui and panel widget live in the same process: ddcui can draw a tray icon via StatusNotifierItem protocol and clicking on "Close" icon in main UI will just hide the window leaving the program running in the background with notification icon visible. Left click on notification icon can show small panel with selected controls, similar to sound level control, and by double clicking or using right click menu user could open the main UI. I'm not sure that engineering a general solution with daemon and multiple interfaces worth it. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#16?email_source=notifications&email_token=ADMGY3TCL2K7RUHXA6FBPELQX2SPDA5CNFSM4JXZ5WD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGKR63Q#issuecomment-563421038>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADMGY3VGPOIB7545EEU2HPLQX2SPDANCNFSM4JXZ5WDQ>.

[nahoj]

I think the tray-icon option could be usable without the need to have 2 separate UIs. The behavior could just be that closing ddcui minimize it to tray and that a left click on the tray icon open it back up. Then there wouldn't be any communication complexity, right? Does nothing for the "long-running" part though.