[Feature Request] Bluetooth Tray Utility

[klardotsh]

I don't think this needs to be anything too excessive, though I'm not sure I'm a fan of Gnome Shell's implementation of just telling you number of connections and linking you to System Settings to do anything useful. A simple popover could be made to actually be functional (and maybe still leave a link to the Bluetooth Settings pane).

This is another one I might take a hack at myself if nobody else goes for it first.

[ikeydoherty]

A temporary solution will be supporting natray an appindicator via budgie-panel applets. In the long run I agree, a popover should do the work itself. The idea I had is having them done via StatusApplet, and each sub indicator can expose a control widget to be placed within a popover, and each one designed and implemented from the individual indicators (this goes for sound too)

[klardotsh]

I see the Status Applet widget currently holds the "widgets" for battery and sound... if I'm understanding you correctly you want to implement Net/BT/whatever using similar "widgets", that expose a Budgie Popover (like the clock does) on click?

[ikeydoherty]

Yup, so the Status Applet would have the popover and that would be populated from the individual indicator/widget things, (need a good name for them) so that there is just one popover for that entire applet, no matter which one you click on (GNOME refers to that as an aggregate menu)

[klardotsh]

Aaaaah. Gotcha. Not quite what I thought you meant, but accomplishes the same thing. I don't know that I'm quite a good enough GTK ninja to accomplish something like that, but I could take a shot at it when I get some free time (as making that part of the tray useful is pretty imperative for me to be able to use Budgie full-time).

Personally, what I'd throw in the Status Applet (and allow them to be rearranged, perhaps):

• Volume Control
• Power / Battery
• Network Management
• Bluetooth Management
• libnotify Notification Center
• freedesktop systray (this wouldn't have popover support since there's no rhyme or reason to how applications implement the systray)

Thoughts?

I'd personally just call them subwidgets, but that's my inner developer (read: lack of naming ability) shining through :P

[ikeydoherty]

I named this thing Budgie - lack of naming ability is common it seems :P For a systray I think we can keep that as a separate applet, as we still have the option to place an applet in the status area. Its merely aesthetic but it makes it look like its all part of the same thing :) Agreed on the other stuff, but wrt. notifications maybe this is something we can also handle inside the window manager? This way we can get super pretty animations and stacking, as opposed to trying to kludge a GtkWindow into place

[klardotsh]

Personal thought on notifications comes from how KDE used to handle them (no idea these days as I haven't used it full-time in quite a while). They had a panel item that housed the notification center that was hidden if there were no unread notifications. Notification comes in, the icon showed up (we could have a simple GTK widget instead of an icon, this could be a GTK equivalent of Bootstrap's Badges (I know GTK can do them somehow; Geary has them for unread counts per mailbox)), and showed a popover of whatever the notification was.

Image because I suck at explaining things

"Stacking" and updating notifications is easy because we're just jamming more stuff into the subwidget's GtkPopover.

There's my 2 cents.

[klardotsh]

I believe this is similar to how ChromeOS handles notifications as well, for the record. Ironically enough I'm actually typing this on a Chromebook C7, but not in ChromeOS so I can't actually test this.

[ikeydoherty]

I like the idea, concerned that the icon you mention (Numerable) is being deprecated, but meh. We'll make our own =P The irony is not lost on me.. ^^ Another thought is actually supporting active vs passive notifications, i.e. a notification from gnome-music could have a next/back/pause control, so we'd need that in place. From what I gather you just create a d-bus service that conforms to the spec

[klardotsh]

While supporting active notifications is obviously doable, I seem to recall those kinds of notifications being deprecated quite a while ago (or at least recommended against). This was mostly caused (again) by Canonical, but still. I can't think of any notifications with buttons ever popping up on my GNOME system, though I might be forgetting one.

[ikeydoherty]

Yeah I can only think of gnome-music right now, and GNOME Shell uses notifications in a very odd way. The very term notification suggests its passive, as opposed to interactive composited dialog, which is what GNOME Shell really has..

[klardotsh]

Aaaagh. Have a headache from staring at code too long today... regardless, branched and began work on the unified Popover. Strictly speaking that functionality now exists, and clicking the battery vs. the sound icon populates the popover differently.

Basic Sound Applet modifications made to have it do something half-useful (moving the Scale widget has no effect on the volume because GVC refuses to let me set the volume of a stream...)

https://github.com/iv597/budgie-desktop/tree/status_applet_popovers

Only bug I know of so far with this is that the tails now draw to the top left corner of the widget it points at, rather than centered. This has something to do with the modifications I made to make sure a popover never bleeds over onto monitors Budgie Panel isn't running on, and I haven't taken the time to debug it.

[ikeydoherty]

I'm gonna be awkward now.I more meant all widgets are always in one popover, no need for detection of which one to show, show them all :)

[klardotsh]

That's gonna be a visual disaster when you factor notifications into this. Allowing each widget to draw its own popover "child" and only showing the relevant child, in my opinion, is much cleaner visually.

Obviously it can be done either way, I'm just thinking visual design wise. GNOME Shell has done it both ways and in my opinion the old way (the way I've implemented here) was much cleaner looking. If I'm recalling correctly, ChromeOS also does it this way.

KDE's Plasma 5 has the happy median here, everything's one giant popover, but it's tabbed/paned so only one child widget's popover_child is showing at a time. Also a possible alternative.

[ikeydoherty]

Not sure why this is a disaster? That popover is essentially a quick settings popover, it wont be able to show notifications

[klardotsh]

I think I'm getting details confused about various portions of this - I'll go ahead and work on the single popover method for now and we'll figure out notifications support whenever that happens to come up :P

[ikeydoherty]

Lol, I like your method. You win one internet :D

[ikeydoherty]

Closing due to inactivity