Auto-discard notification

[Marco Martin]

another one..
______
First, sorry that it took me so long again to reply. This is my first free 
weekend after almost three months without any time to breathe.

Am Dienstag, 25. Mai 2010, um 18:55:39 schrieben Sie:
> thanks for the feedback. at the same time .... we could poll 100 users and
> get list of 10 "things i like the least" and a list of 10 "things i hate
> the most". such lists are nearly useless because, while a nice efficient
> way for the maker of the list to get their issues out in one place, it is
> completely unmanageable for us as developers.
> 
> bugs.kde.org is there for a reason.

Okay, I also wanted to get some feedback before submitting bugs (which I'll do 
when I have a little more time, hopefully in July).

> On May 23, 2010, Reinhold Kainhofer wrote:
> > 1) Whenever a new notification appears, the whole panel is unhidden and
> > hides the bottom of the current window (which makes working impossible if
> > you are typing e.g. in a konsole window).
> > 
> > 2) When you display the calendar (by clicking on the clock), the whole
> > panel is unhidden and does not hide until you hide the calendar, too. You
> > can work in other applications just fine, but the panel will always hide
> > the bottom part of the window.
> 
> can't make everyone happy. and when the panel is being interacted with,
> most people in most situations expect the panel to remain visible. 

Yes, I agree with you on that point: If I interact with the panel and e.g. 
display the calendar, it makes sense to show the panel (so, I retract my 
Nr.2).
However, if I don't interact with the panel (for example, when a new mail 
arrives on an automatic mail check), it does not make sense to me to show the 
panel, as I'm not interacting with the panel. I only want/need to see the 
notification, not the whole panel.

That way, the "unintrusive" passive notification is massively intrusive 
(hiding a large part of the screen, in particular the status bar in a 
maximized window and a toolbar on the bottom, or in the konsole the command 
line you are currently typing!).


> > The notifications appear on the external display though (which is again
> > embarassing, they should appear on the main laptop display, not on the
> > beamer)
> 
> fixing x.org's interesting ideas of how to arrange displays is not in our
> mandate. sorry. we just follow the screen #ing, which is actually what most
> people who connect their laptop to an external display tend to want.
> 
> again, can't please everyone.

Yes, but a user will blame plasma (which displays the notifications on the 
"wrong" screen) for the problem. (Just like KDE is blamed that Qt's printing 
system is so much worse than KDE3's kprinter)
As a user, I don't care which of the underlying libraries is to blame. Rather, 
I observe that the application I'm using is not doing what I want / would 
expect it to do.
I just wanted to let you know.

> > 10) The configuration of the Panel is just so different from everything
> > else...
> 
> yes, and different is "bad'. thankfully there are people who aren't afraid
> of different. it's how we make progress as a species.

No, it's not different that is bad. It's inconsistency that's bad...

For example, resizing any other window or any other splitter means clicking 
exactly on the border or splitter and dragging it from the old position to the 
new position. In plasma (both in the panel configuration as well as in the 
applet on the desktop) in contrast, one has to click on a pre-defined are 
somewhere completely else and drag that to remote-control the panel/applet 
size...


There is also another problem with the configuration and panel hiding:
If you have automatic panel hiding enabled, and you want to add a new applet, 
the panel with the list of available applets will be shown, but the panel 
itself will be hidden! 
Only if you drag an applet to the bottom of the screen, the panel will be 
shown again...

> > 11) when I have the panel configuration panel open and accidentally move
> > the cursor just one pixel out of the panel, the config panel is
> > immediately hidden and I have to open it again manually -- very annoying
> 
> "focus follows mouse" is a broken concept imho, but it is working exactly
> as it is supposed to in your case. if you wish to use focus follows mouse,
> you need to also accept the misfeatures it brings. things work as they do
> because it's what works best and as expected for the explicity focus case.

It might be broken in your opinion, to me it makes working much more efficient 
(in particular in combination with keyboard shortcuts)...

About this particular issue: Wouldn't it work to have visible plasma panes 
behave like popup menus? If you move your mouse out of a popup menu (or a menu 
from the menubar), then the menu is still not hidden and the focus does not 
change. Only if you click somewhere else, then the applet is hidden.


Furthermore, many of the various plasma plasmoids all behave differently 
(first four examples are mainly from the systray, the rest is from separate 
plasmoids):

-) Calendar: 
If you move the mouse from the panel to the applet, the panel stays visible. 
It also stays visible, even if you move the mouse out of the applet, you can 
work in any application and the calendar (plus the panel) stays visible until 
you click on the clock again. (Same behaviour for the notification applet)

-) Device manager applet: 
If you move the mouse into the applet's pane, the panel is hidden, the applet 
stays. If you move the mouse out of the applet, it is hidden automatically. 
(That behavior is also displayed by several other applets)

-) Mixer applet: 
If you move the mouse from the panel to the applet, the panel is hidden. if 
you move the mouse out of the applet, the applet stays visible, until you 
click on some other window.

-) KBluetooth: 
Shows a popup menu, but that menu is hidden if you move the mouse out of the 
menu. In contrast, the identical (!) popup menu on a right-click on the 
bluetooth icon is not hidden if you move the cursor out of the menu (which is 
the default behavior by any other popup menu in any other application)

-) Folder quick access, Konqueror/Kate sessions, K-Menu (Kickoff-style):
If you move the mouse from the panel to the plasmoid's pane, the panel stays 
visible. As soon as you move the mouse out of the plasmoid's pane, the 
plasmoid and the panel are both hidden immediately

-) K-menu (traditional mode):
Shows a normal popup menu: If you move the mouse from the panel to the menu, 
the panel stays visible. If you move the mouse out of the menu, it still stays 
visible until you click somewhere outside the menu.

As you can see, there are at least six more or less different behaviours of 
applet and panel hiding displayed by the applets...

I my eyes, a behavior like the mixer applet would be the most useful (i.e. not 
hiding the applet if you miss an item near the border by a few pixel, but 
hiding only if you click somewhere else). This is also the behavior of all 
popup menus.



> > 12) Every now and then the vertical offset of the devices in the device
> > manager panel is messed up and the device list seems to start at a large
> > negative offset, so only the last few pixel of the whole list is visible
> > any more. I can't exactly reproduce it, but it seems to happen when the
> > actions for a device are shown in the list and then something happens
> > that hides the panel without calling that action....
> 
> bugs.kde.org, will require screenshots.

Okay, will do (means I have a screenshot, but have not yet found the time to 
report on bko; I hope to get around in July).

> > 14) About the horizontal lists for adding applets I already wrote a while
> > ago, so I won't repeat it here, but I still think the horizontal list is
> > much worse than the former vertical list.
> 
> repeating yourself when a conclusion has been reached with no new input to
> offer only gets you closer to being ignored by me. here's why: we won't see
> eye to eye on everything.

I totally understand that you made your decision, and that it won't change 
(even more, since I don't contribute with any code). Sorry if I made that 
point sound sub-optimal, but I wrote that mail in a 45 minutes break before a 
long rehearsal for a concert tour.


I just wanted to understand why the horizontal list is better. I couldn't find 
any searchable archive of the mailing list (the archive at mail.kde.org is 
non-searchable :( ), and so far I didn't hear any argument why the horizontal 
list ist better. You only told me that "it becomes rapidly apparent during 
usage of the interface across these use cases that the old dialog with a 
vertical listing was really not great."

Honestly, I don't really understand what are the problems in these cases, and 
I see even less how the horizontal list is better.

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org
  End of encapsulated message