Plasma Issues [Was: KDE's Plasma: How not to do lists...]

[Aaron J. Seigo]

On June 13, 2010, you wrote:
> > > 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.

first off, if the problem is elsewhere we can't fix it in plasma. putting 
hacks into plasma, even if possible, masks problems that later then become 
bugs all over again when things shift underneath us. i don't *care* if people 
blame plasma. the goal isn't to avoid blame. the goal is to provide reasonable 
software. if the problem is in Qt or x.org or whatever and there are no 
reasonable work arounds for it, then we have to live with it until it is 
fixed. we've been through this again and again, and it's a primary reason 
we've made any sort of useful progress on the f/oss desktop in the last few 
years.

anyways, as for showing "on the wrong screen", we received a report with a 
clear description, means to reproduce, etc. and it should be fixed in 4.5. 
this particular problem actually had nothing to do with hotplug. so this one 
is thankfully fixed at least.

> > > 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...

how often do you resize a panel? edge dragging panels is a great way to piss 
people off as its far too easy to do. been there done that with kicker, thank 
you. the panels (and desktop) are most useful in "unlocked" and i'm not about 
to add yet a third state just to allow edge dragging.

> 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...

works here, using trunk.

> 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)

beucase it so happens that the calendar is one item that when shown people 
often want it to remain visible while they work on something else.

> -) Device manager applet:
> If you move the mouse into the applet's pane, the panel is hidden, the
> applet stays.

not in trunk, at least.

> If you move the mouse out of the applet, it is hidden
> automatically. (That behavior is also displayed by several other applets)

focus follows mouse.
 
> -) 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.

yes, it's using a traditional menu which grabs the mouse and enters its own 
internal event loop.

the above can be repeated for most of the rest.
 
> 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.

that's what you get when you don't use focus follows mouse. if someone wishes 
to experiment with a patch that does mouse grabbing to emulate popup menu 
behaviour closer, we could see how that goes. we have to be careful about 
possibilities where the mouse is not ungrabbed, and how it interacts with 
normal popup menus that are shown in reaction to events on the applet while it 
is in its own mouse grab.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20100615/382abdfe/attachment.sig