Re: [kde] Mapping physical screens to KDE containments
- Date: Mon, 11 Apr 2016 16:18:39 +0200
- From: Martin Steigerwald <martin@xxxxxxxxxxxx>
- Subject: Re: [kde] Mapping physical screens to KDE containments
On Montag, 11. April 2016 10:01:36 CEST Duncan wrote:
> Felix Miata posted on Sun, 10 Apr 2016 23:06:01 -0400 as excerpted:
> > Nick Coghlan composed on 2016-04-11 12:42 (UTC+1000):
> >> Using a multi-monitor setup under Plasma 5 (Fedora 23), I have a
> >> problem where the configured panel applet will disappear and not come
> >> back if an external monitor is reconfigured to clone the laptop
> >> monitor, and then switched back to being an independent screen.
> > Looks like you must have found the explanation why I have a whole bunch
> > of F23 and F24 installations in which I never see a panel any more. I'm
> > never using a laptop, but I do have several multi-output gfxcards to
> > which I only sometimes connect more than one display. When I do, it's
> > always in an extended desktop mode configured manually either using
> > xrandr or xorg.conf*
> > via /etc/X11*.
> A similar problem here, tho on a triple-monitor setup with a permanent
> layout configured in xorg that plasma would ideally simply leave alone...
> only it doesn't.
Well multi monitor support in Plasma with X11 still has a lot of issues.
> Oh, and krunner often refuses to popup after I come back from screen-
> blanking as well.
> * For krunner, the problem seems to be that after the screen blanking,
> it's confused about what the coordinates of the focused (xinerama/randr)
> screen are and hitting the krunner hotkey will apparently "display and
> focus" the krunner window as whatever was focused loses focus, except
> that whatever coordinates krunner actually pops up at aren't actually on-
> monitor anywhere that I can see, so who knows /where/ it's popping up,
> obviously not on the focused monitor (aka xinerama screen).
[Bug 354546] New: krunner window appears outside of visible area after
reconnecting a screen
and quite annoying.
> + My workaround involves two things:
> +a) setting up a kwin window rule for krunner.
> On the matching tab, window class, exact match, krunner krunner, with
> match whole window class checked, window role unimportant, window type
> normal window, window title exact match, krunner. (Description aka rule
> name is your choice, I simply called my rule krunner, here.)
> On the size and position tab, initial placement, force, under mouse.
> (That's not quite the normal behavior but at least I can always find it
> then.) Ignore requested geometry, force, yes.
> +b) When krunner won't appear, I simply force-quit and restart it, with a
> script that runs these commands:
> kquitapp5 krunner
> sleep 1
> krunner &
> (The sleep, backgrounding with &, and disown, may or may not be actually
> necessary, but I'm actually using a generic script with the name filled
> in as a variable, so anything I restart that way gets the same
> treatment. If it's necessary, failure to do it will cause the just
> restarted app to terminate again when the script ends, a problem the
> disown avoids.)
Feel free to add your work-arounds especially the window rule one to the bug
report, well or maybe add just your mail as a link, to not clutter kde
bugtracker too much.
That said I didn´t see this krunner issue in a while with self-compiled KF5 on
top of Debian unstable/experimental Plasma + KF5 packages.
> * For plasma panel, a rather limited workaround uses much the same two-
> part technique. The limit is that because plasma5 doesn't set unique
> window class, window role and window title for each of its panels (as
> plasma4 did), the rule will apply to all panels and possibly to other
> popups like the add plasmoid dialog (aka add widgets, aka plasma/widget
> explorer). If you have just one panel that's fine, but more panels
> becomes problematic, and now that the plasmoid explorer is affected by
> the same rule, I have to temporarily disable the rule any time I want to
> add new plasmoids/widgets.
> + Two part workaround with additional limits:
> +a) window rule for plasma panel
> Matching tab: (I call it simply plasma panel.) Window class, exact
> match, plasmashell plasmashell, match whole window class checked. Window
> role unimportant (this is where plasma4 distinguished them, with roles
> such as panel#1, panel#2, etc, so the rule could apply to a specific
> panel; unfortunately the window role is blank for panels in plasma5, so
> that doesn't work any more). Window type, Dock(panel). Window title,
> exact match, Plasma. (Setting dock type is absolutely vital!! Otherwise
> you'll get matches on things like the activities/desktops, etc, **NOT**
> what you want!!)
> Size and position tab: Screen, force, <appropriate screen number,
> experiment if needed>. Optional: position, apply initially, <as
> Forcing the screen aka monitor number should make sure it appears on the
> same monitor consistently. If you only set this, you should be able to
> get away with multiple panels at different positions, but they'll all be
> forced to the same screen/monitor.
I´d rather like to avoid that kind of static configuration, but I see how that
is tricky. What works meanwhile for me that at least it get its right for two
external display configuration. One at work, one at home, with ThinkPad T520
Full HD display as internal one. Both external displays have Full HD and the
panels I placed there usually stay there, I am not sure tough whether I put a
panel there for each display and Plasma just digs out the configuration for
that screen again and so if I connected all three displays it would have all
> Another alternative for kwin that will work in most cases:
> kwin_x11 --replace.
I use that a lot in various situations.
> But while that's simpler, from my experience it's not always as reliable.
And yes, it doesn´t work always.
> * For the activities switching monitors, I find that the problem usually
> fixes itself with a simple plasmashell restart, using the script above.
I still do this by hand.
Just killall plasmashell and plasmashell called from krunner. And for krunner
as I still needed it from kickoff menu.
> Oh well... On the bright side, it'll probably be fixed in a few years...
> just in time for them to dump it and start on the all new and buggy kde/
Multiscreen issues are not just Plasma, the go through the complete stack. But
yeah, some can be pretty annoying. Like this one:
[KScreen] [Bug 360563] black screen on session restore until removing
Its quite an experience when you log in and are greeted by a black screen, but
not something I´d expect from a reliable desktop environment.
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
More info: http://www.kde.org/faq.html.