colomar wrote:Okay, first of all, throwing a notification when the player pauses doesn't make sense anyway. I press Pause, the music stops playing, the button appearance changes, that's enough feedback. And Amarok doesn't throw a notification when pausing, so I'd suggest filing a bug about that for Clementine. A system notification about something as unimportant as pausing the music player is simply wrong.
When I resume playing by using a global shortcut, it does make sense to display the currently playing track (depending on how long I've paused, I may have forgotten which track was playing), but the notification does not make sense when I see the track in the popup anyway. Actually, I don't need any notification for actions I've triggered on the player's main UI either. The HIG says "Use a notification to inform about a non-critical problem that is not directly relevant to the user's current task." When I'm interacting with the music player's main UI, then that definitely is my main task.

So you've spotted a general problem with media player notifications here which should be fixed. However, implementing a system that prevents notifications about media play from being shown when they're triggered from either the main UI or the Plasma popup might be too complex for a simple polishing fix.

Actually, notifications are a general topic which we should talk about in further detail. Here, Celeste Lyn Paul (former leader of the KDE usability group) can help a lot here because she has written her dissertation about desktop notifications.

Ah yes, that seems complicated indeed. I will then try to fill a bug on Clementine later.

However I still think that we should not display the notifications on top of the SytemTray menu thing. I guess we can discuss this in a different thread.

On another note:
Who else thinks that the Kickoff icon and the desktop switcher applet should be vertically centred in the panel?
Picture:

Sogatori wrote:Who else thinks that the Kickoff icon and the desktop switcher applet should be vertically centred in the panel?
Picture:

I know Marco tried several iterations of vertical centering and what you see here the best compromise to avoid overlapping with the highlight line. I'm thinking eventually we'll have to find a better visual solution than the highlight line to show that an applet in the panel is selected...

I think that the highlighting line makes little sense for kickoff and the calendar. The system tray needs it because it reinforces what applet is open. The task manager needs it to show what windows are open and the state of those windows. The calendar and kick off doesn't have those needs, and showing the line causes problems with the placement of the the icon.

I also agree with Sogatori, if the system tray is open, don't show notifications, instead make the notification bubble ping.

Sogatori wrote:Second thing:
I have a weird bug in Kickoff, which prevents the "m" key from toggling the search function. So when I open up kick of and start to type "menu" I end up with "enu" instead. I asked a developer about it, but he isn't affected. However, I later spoke with another person in #plasma who seems to experience the same.
I'd be nice if someone here could try it out too, if they have Next installed. Right now the evidence is a bit meagre to report a bug.

See https://bugs.kde.org/show_bug.cgi?id=335469
Everyone is affected, it only depends if something is selected in the launcher. The dev you talked to likely had someting selected.
Anyway the maintainer of the component is having a look .

kdeuserk wrote:

Sogatori wrote:Second thing:
I have a weird bug in Kickoff, which prevents the "m" key from toggling the search function. So when I open up kick of and start to type "menu" I end up with "enu" instead. I asked a developer about it, but he isn't affected. However, I later spoke with another person in #plasma who seems to experience the same.
I'd be nice if someone here could try it out too, if they have Next installed. Right now the evidence is a bit meagre to report a bug.

See https://bugs.kde.org/show_bug.cgi?id=335469
Everyone is affected, it only depends if something is selected in the launcher. The dev you talked to likely had someting selected.
Anyway the maintainer of the component is having a look .

Ah that's good to know!

I found a bugreport concerning the Pause notification in Clementine. https://github.com/clementine-player/Clementine/issues/2450
It doesn't look like this is going to be fixed any time soon though as the bug report is quite old already.

alake wrote:

Sogatori wrote:Who else thinks that the Kickoff icon and the desktop switcher applet should be vertically centred in the panel?
Picture:

I know Marco tried several iterations of vertical centering and what you see here the best compromise to avoid overlapping with the highlight line. I'm thinking eventually we'll have to find a better visual solution than the highlight line to show that an applet in the panel is selected...

I can see this being true for the Kickoff icon, alake, but the workspace indicator doesn't have any highlight line.
What I also didn't notice was that the Kickoff icon has less padding on the left - towards the screen boundary - than to the right. I know that the right padding probably is the result of the combined padding of Kickoff and the workspace indicator, whoever, maybe we should think about adding the doubled ammount of padding to plasmoids that reside next to the screen edge. I'm not sure tough how feasible this is code wise.

Sogatori wrote:

alake wrote:

Sogatori wrote:Who else thinks that the Kickoff icon and the desktop switcher applet should be vertically centred in the panel?
Picture:

I know Marco tried several iterations of vertical centering and what you see here the best compromise to avoid overlapping with the highlight line. I'm thinking eventually we'll have to find a better visual solution than the highlight line to show that an applet in the panel is selected...

I can see this being true for the Kickoff icon, alake, but the workspace indicator doesn't have any highlight line.
What I also didn't notice was that the Kickoff icon has less padding on the left - towards the screen boundary - than to the right. I know that the right padding probably is the result of the combined padding of Kickoff and the workspace indicator, whoever, maybe we should think about adding the doubled ammount of padding to plasmoids that reside next to the screen edge. I'm not sure tough how feasible this is code wise.

Yeah, I think you're right Sogatori. It may well be the panel padding which is defined from the panel edge inward. A full-width panel on the bottom edge purposefully removes the padding from the left and bottom to let the panel applets get mouse events at the edge of the screen (Fitt's law and all that). That leaves the padding for the top edge. In fact that's how it works on plasma 1 as well. I'm not sure of the best fix, except reducing the panel padding in the plasma theme so there is less obvious difference. May be worth it since that doesn't require a code change...

I do think though the kickoff icon is also translated down more than the panel padding to accommodate the highlight line. I'm starting to think it really might be worth skipping the highlight line on anything other than the taskbar and the systray - that's where the active item distinction is most important anyway...

alake.

I like the idea that i read somewhere a while ago about using the highlight line above entries in the taskbar to indicate progress in things like file transfers etc but what's the purpose of the highlight line in the rest of the taskbar, particularly the system tray - apologies if that's a daft question?

If it's just to indicate which system tray applet's just been clicked on, could fading or greying out the rest of the system tray icons work (they are black & white so it might look ok), effectively making the active icon much darker than the rest, be a possible solution if it was viable code-wise?

@alake and others
I'm trusting you to find a solution that's elegant and good looking

Yesterday it came to my attention that the close icon in the notifications are off-centred. Notmart already knows about it and the bugreport can be found here. If I did something blatantly wrong or missed something in the report, please contribute!

Now to a "bug" I'm not sure how to report efficiently (or where for that matter). The new setting dialogues which use QtQuick Component (maybe I'm wrong here) use an animation when one changes the category. Take for example the desktop settings:
1.) Right click on the desktop
2.) Click "Default Desktop Settings"
3.) Select "Mouse Action" on the left sidebar
4.) Watch the switch animation going from the right to the left
5.) Select "View" from the left sidebar
6.) Watch the switch animation going from the right to the left
IMHO when one changes to the previous category the animation should be inverted, so 6.) should go from the left to the right instead of the other way round. I'm not sure if I explained it in an understandable way.

Finally I'm back.
Yesterday I finally managed to fix my plasma installation thanks to the people in #project-neon and #plasma. Special thanks to bshan and shadeslayer. So I can finally open the panel configuration dialogue and resize my panel and even access the widget explorer. Huzzah!
I then came here to report something only to be interrupted by a power outage (the 4th in my lifetime!) which then screwed up my computer graphics .·´¯`(>▂<)´¯`·.
Well, I managed to repair it, more or less.

I'd like to reference this discussion here.
Our HIG doesn't yet have something on the use of animations. I'd like to propose a first rule:

Never use an animation which follows the mouse movement with a delay.

I have to largely agree with Blingly, these animations generate the feeling that the system has to cope with some heavy load in the background and thus feel unresponsive and slow. Two current examples are Kickoff and Plasma's tooltips.
Kickoff has these button on the bottom that let one change the category:

One only has to hover over one of these buttons to switch the category, however, this effect is applied with some delay. Especially when one wants to quickly switch categories this gets rather annoying. I think this effect should either be applied without delay, given that these button are big enough to avoid hitting them accidentally, or the whole effect to be dumped in favour of a navigation where one has to click to change the category. Please comment.

Another issue are the transformations in Plasma's tooltips. When one hovers over and item in the new system tray a tooltip appears, when one hovers over a different item, the previously shown tooltip morphs into a new one. However, this animation seems to cause more problems than it solves, especially when the mouse moves along a vertical path. The tooltip sometimes wiggles a bit till it snaps into position again, or it appears e.g. too far on the right and then has to move left again. Additionally, this effect follows the mouse with some delay. Not only does this constant morphing make the tooltips feel unnecessary busy, but the delay in following the mouse makes it feel unresponsive.
IMHO we should drop this animation, too, and exchange it for the one that also context menus use. So, when the mouse hovers over an item for the first time there's some delay until the tooltip shows up. If the mouse moves to a different item in the same applet e.g. the system tray, then the tooltip appears instantly.
This is all rather complicated to word for me. I hope you got what I mean.

Sogatori wrote:FTwo current examples are Kickoff and Plasma's tooltips.
Kickoff has these button on the bottom that let one change the category:

One only has to hover over one of these buttons to switch the category, however, this effect is applied with some delay. Especially when one wants to quickly switch categories this gets rather annoying. I think this effect should either be applied without delay, given that these button are big enough to avoid hitting them accidentally, or the whole effect to be dumped in favour of a navigation where one has to click to change the category. Please comment.

If the hover mechanism is used for selection then I can understand the logic for a delay: Preventing inadvertent switching. Hovering is ambiguous; there are a lot of reasons the cursor could be in a particular region of the screen. For example, the user may just have moved the cursor out of the way to see or interact with something. So I think there is a certain logic for a delay there. What matters, I think is that if the selection is clicked the response should be immediate; clicking is a deliberate, unambiguous action. I'd have no objections if the selection animation (not the hover delay) was sped up or eliminated. If the delay is truly bothersome, then we should remove the hover-selection mechanism altogether. In the old kickoff, there was an option to disable selection on hover. The hover selection doesn't bother me so long as I get an immediate response when I click.

Another issue are the transformations in Plasma's tooltips. When one hovers over and item in the new system tray a tooltip appears, when one hovers over a different item, the previously shown tooltip morphs into a new one. However, this animation seems to cause more problems than it solves, especially when the mouse moves along a vertical path. The tooltip sometimes wiggles a bit till it snaps into position again, or it appears e.g. too far on the right and then has to move left again. Additionally, this effect follows the mouse with some delay. Not only does this constant morphing make the tooltips feel unnecessary busy, but the delay in following the mouse makes it feel unresponsive.
IMHO we should drop this animation, too, and exchange it for the one that also context menus use. So, when the mouse hovers over an item for the first time there's some delay until the tooltip shows up. If the mouse moves to a different item in the same applet e.g. the system tray, then the tooltip appears instantly.
This is all rather complicated to word for me. I hope you got what I mean.

Yeah, I understand and appreciate the effort behind the tooltip animations but, I agree that it might be better if we did away with animations between two different tooltips. Everywhere. I can't think of a benefit they serve, but I'm eager to hear if anyone has any thoughts there. I propose you file a bug report requesting removing tooltip animation between different tooltips. That should get the ball rolling and we can see where it goes. I'll chime in on the bug report if you'd like. You've always been good at this Sogatori, but I'll mention it anyway: Try to be gentle in the bug report. Someone thought this was a good idea and may be proud of their efforts here. I just want to make sure we respect that in the process.

alake wrote:If the hover mechanism is used for selection then I can understand the logic for a delay: Preventing inadvertent switching. Hovering is ambiguous; there are a lot of reasons the cursor could be in a particular region of the screen. For example, the user may just have moved the cursor out of the way to see or interact with something. So I think

the delay on hover is necessary to have the current design of kickoff working at all, otherwise one would have to have too much attention of moving the mouse in exactly a vertical line from the kickoff button to the contents, to not switch page.

Yeah, I understand and appreciate the effort behind the tooltip animations but, I agree that it might be better if we did away with animations between two different tooltips. Everywhere. I can't think of a benefit they serve, but I'm eager to hear if anyone has any thoughts there. I propose you file a bug report requesting removing tooltip animation between different tooltips. That should get the ball rolling and we can see where it goes. I'll chime in on the bug report if you'd like. You've always been good at this Sogatori, but I'll mention it anyway: Try to be gentle in the bug report. Someone thought this was a good idea and may be proud of their efforts here. I just want to make sure we respect that in the process.

about the current set of animation in general, i'm in favor of making them faster, but not in removing them.
The design goal was always removing any kind of "artificiality" and the worse kind in uis is things that appears or disappear by "magic", that is a thing that doesn't really happen anywhere else.
tooltips for instance, i don't want them to "magically" disappear and magically reappear in another place.
as for the tabbar, signals in a nice way you switched to a tab to the left and to the right, again not magically disappear and reappear.


Then, there will be always someone against every and each kind of animation, but there should be a global, single setting for that.

notmart wrote:about the current set of animation in general, i'm in favor of making them faster, but not in removing them.
The design goal was always removing any kind of "artificiality" and the worse kind in uis is things that appears or disappear by "magic", that is a thing that doesn't really happen anywhere else.
tooltips for instance, i don't want them to "magically" disappear and magically reappear in another place.
as for the tabbar, signals in a nice way you switched to a tab to the left and to the right, again not magically disappear and reappear.


Then, there will be always someone against every and each kind of animation, but there should be a global, single setting for that.

I at least don't want it as much to be removed rather than replaced. I think the current animation is unnecessary busy. I'd prefer a slight fade-in and -out like it's done with context menus.
I agree on the notion that nothing should just "magically" appear out of nowhere, but I think it should be a guideline and not a dogma. I think that using the old "if there's a simple way to do it, then make it simple" advice.
I like to keep it simple and consistent. So we have to ask us, what warrants this sliding animation instead of a simple fade-in and -out? And what makes it so different from other places which work in similar ways, like application menus.
I understand the point you (and the other plasma devs) make about magically appearing, and indicating that the old tooltip (I think you called it page in IRC) is still there when one moves to the next item. However, I think that a slight-in and an ever so light slide-up animation from where the mouse pointer is would to the job, too with looking much calmer. If there's a mouse hovered over an item in the task bar (bottom of the screen), then the tooltip could slightly slight up to indicate that the tooltip corresponds with the item where the mouse is. Just an idea.
Some devs also said that they like the continuity the sliding animation indicates. I guess we have just two ways of looking at it. For me the content they display is much more important than what displays the content, in this case the tooltips. So for me two tooltips are different and don't share anything besides being tooltips. The same thing is true for me for menus i.e. I wouldn't want to indicate a continuity between the History and Bookmarks menu in Firefox. I guess that's just a different way of looking at it.

I like the tabbar animation. However, the content should not move in the same direction all the time ignoring the order of the tabs i.e. from the right to the left no matter if the user chooses to go "back" or not.

I hope I could illustrate my concerns. I'm in no way against animations, I simply think they should be as "subtle" to the eye as possible and not appear busy.
I'd would really like if you Plasma devs could speed up the animations a bit. I'd really like to see how it looks when they are faster.

Sogatori wrote:Some devs also said that they like the continuity the sliding animation indicates. I guess we have just two ways of looking at it. For me the content they display is much more important than what displays the content, in this case the tooltips. So for me two tooltips are different and don't share anything besides being tooltips. The same thing is true for me for menus i.e. I wouldn't want to indicate a continuity between the History and Bookmarks menu in Firefox. I guess that's just a different way of looking at it.

You definitely have a point here: A tooltip should be visually connected to the thing it informs about, not to other tooltips.

One thing that i've noticed is that when you right click on the taskbar digital clock in the current Plasma you get a menu entry 'Digital clock settings Alt+D,S' this same shortcut appears in several other system tray context menus too.

I posted this query a while ago:
viewtopic.php?f=66&t=121382

The thread got 80 reads and the only response was (in my own words) - 'that shortcut opens the primary desktop settings dialog and not the Digital clock settings, it's not working'. Having that broken shortcut just adds clutter & confusion and in the Neon5 daily snapshot that i just tried the shortcuts are still in the context menus, except now it doesn't do anything at all (it doesn't open the 'primary desktop settings dialog').

ken300 wrote:One thing that i've noticed is that when you right click on the taskbar digital clock in the current Plasma you get a menu entry 'Digital clock settings Alt+D,S' this same shortcut appears in several other system tray context menus too.

I posted this query a while ago:
viewtopic.php?f=66&t=121382

The thread got 80 reads and the only response was (in my own words) - 'that shortcut opens the primary desktop settings dialog and not the Digital clock settings, it's not working'. Having that broken shortcut just adds clutter & confusion and in the Neon5 daily snapshot that i just tried the shortcuts are still in the context menus, except now it doesn't do anything at all (it doesn't open the 'primary desktop settings dialog').

It's probably something that has been there forever, broken almost forever but nobody cared to either fix or remove it. It's definitely a bug. I'd suggest filing a bug which says that it should either be fixed or removed (I'd vote for removing unless someone can explain what it's actually useful for). I assume devs will choose to remove it given that it has probably been broken for a long time and nobody cared.