Indicators applet and Clock applet placement for Bionic 18.04

Thoughts & Feedback
#1

I apologize if this should be in the Development section, please feel free to move to where it belongs.

I had reason to play around with the applets due to a doubling issue I encountered and I had the indicators show up without the clock temporarily. When I added the clock I was about to move it to is usual, traditional layout placement when I stopped to consider how it looked:

Screenshot at 2018-04-06 20-54-16.png1365Ă—49 69 KB

imageedit_1_5376155033.png1305Ă—255 422 KB

Since there is a technical issue blocking us from being able to get a clock loading as an indicator in time for the 18.04 release what do you think about adjusting the default placement of the clock so the new indicators are at the far end of the panel on Traditional Layouts and placing the clock in front of that. This allows the new system idicator applet with the gear to act as the shutdown menu and feels more natural and closer to what we had as a Traditional layout than having the shutdown menu being in front of the clock.

You all know I'm a strong advocate for the Traditional Layout to be unchanged and the face of the distro, but since change is unavoidable in this case I'm asking if it would make sense to make this adjustment for the duration of the Bionic LTS just to allow the upstream changes to take effect and then it can be placed back like before with the new clock indicator in front of the system indicator?

#2

Hi, I asked myself exactly the same question a while ago and experimented with applet arrangement. Actually, the default setup has its benefit: the clock applet has its place and does not move back and forth along the panel. If an application uses indicator, it populates the indicator applet from the left side. If you place clock to the left:

  1. any appearing or disappearing indicator will force the clock applet to move (btw the same happens with legacy keyboard layout indicator); the applet itself is a massive one, and this movement is noticeable;
  2. your program indicators will appear inside indicator area, so user application indicators will be “surrounded” by system indicators and applets – not a perfect solution IMO.
    Moving to Ayatana indicators will eventually solve all these issues, I hope.

Regards

2 Likes
#3

Huh. Now that’s a valid point, I’m basically replacing one issue and creating another. I’ll have to see how it works out in real use with my applications with system tray icons.

I guess the question is how much of a paper cut is it to have that issue versus the issue of the strange placement of the system applet?

I do see it’s not a cut and dry question like I thought it might be now.

Is this even something that bothers people?

#4

or better yet just make the clock part of the indicator applet or at least make it available that way

#5

Dev team is actually working hard on this issue. If I recall correctly, the integration is planned for 18.10 and 19.04 cycles.
Also you may want to check this topic:
https://ubuntu-mate.community/t/make-top-right-panel-in-mutiny-more-like-unity

1 Like
#6

ninja’d! by @ironfoot

There’s a way to do that but it requires a bunch of packages that are Gnome related and unused for anything but the clock. Not ideal. I know from discussions previously that there was a way to install just the needed packages for function and then configuration needed to be done from dconf-editor, which is again not ideal.

I did the homework on this in a previous thread, you can see it there rather than me rewriting everything already said. Do note the link in that post where Wimpy explains that it is something they are aware of and working on upstream and behind the scenes.

This was just a suggestion on how to possibly workaround the situation until upstream decouples things enough to be useful for our needs in this distro.

1 Like
#7

ok I was not aware that it was even in the works I would like that much and although I put the clock like you I do have issues with it moving for a new indicator and not returning after the indicator is gone at times, also a removable drive indicator would be nice to, maybe that’s to much for the applet though :smiley:

#8

Can someone please explain the benefit of this indicator obsession that seems to have gripped the UM developers?

Can anyone explain why the distro keeps moving away from one of the best things about linux - the ability for the user to determine the look, feel and configuration. For example there is talk about where the clock goes and if it should be shoehorned into the indicator applet. Whether or not any of that takes place, it all flies in the face of the things i most like about UM. I decide where the clock goes.

These indicators - there are 4 (count 'em!) in Startup Programs, and what offends me deeply is, since I’m not planning to use indicators I removed the entries. After reboot they were back. This screams Microsoft BS, not Linux. Whose idea was auto-resurrecting options the user has elected to remove?

This, along with some of my experience so far with Beta 2 does not bode well for UM. Experience like invisible panel apps, which fail to appear every time you add one, then you eventually reboot and discover you have 17 instances of the same panel app loaded! I may be wrong, but I suspect most or all of my panel problems are brought on by this indicator business. In 17.10 panel wants to make invisible my CPU Freq applet. In 18.04 it’s the Notification Area that hides.

Since 2006 I cannot recall these sort of issues with previous releases of Ubuntu. I was so please a couple years back when I heard Mate was to become a standard Ubuntu flavor.

Basically I’m just venting. And no response is needed, unless you CAN explain some of these things!

1 Like
#9

The old notification area (aka “system tray”) applets use x11 to embed their own program in the panel. This means each icon looks and behaves differently. With indicators each icon can present a similar menu, but it’s not drawn by the backend program, but by the panel or its indicator applet, and they talk to their backends over d-bus. They are supported by Unity (RIP, but people will use 16.04 for a while still), KDE and even Gnome with an extension. They will work on Wayland since they don’t rely on x11-specific features. There’s probably also a security argument, although that’s never been a reason I’ve seen. [fixed phone keyboard typos]

Not trying to convince you, just explaining it as I understand it.

4 Likes