Registered Member
|
Back in the 3.x days, we had this setup working pretty well. With the advent of kde4, looks like we're there's alot more weight being thrown behind running one screen over both displays. But this causes a problem for us. We need a fully functional and _distinct_ panel running on the other monitor. I can add another panel to the display, but all the desktops are tied to the config in the primary display. My main concern is getting full panel and start menu functionality on both displays, and that launching menu items/desktop entries will open on the display the icon is clicked.The dragging of apps between displays is not at all important to us (hence the running as 2 screens), nor is any glx/compiz fancy decoration or 3d toys (but for the record this is all nvidia hardware running the nvidia module)
I'm familiar with some of the hacks required to get kde4 (4.4.5 squeeze version) to run in a dual head, 2 screen setup. I have an xorg setup, and an autologin script that restarts kwin for both displays. And that essentially gets it up and running. But it definitely feels like a hack. Some kde native apps will only work one on display, alt-tab stops working on one display, alt-f2 only on one display etc. FWIW, we are currently running squeeze, but transitioning over to wheezy shortly (4.8.4) Any ideas on getting a distinct second display to work in a single screen setup? |
KDE Developer
|
No, that's not supported and IMHO cannot be supported without violating EWMH specification |
|
You should maybe specify what you actually want.
"Virtual Desktop" is a concept to group visibility of windows. While implementing independent virtual desktops per screen is not compliant with the (multiscreen unaware...) NETWM/EWMH spec (there's no protocol in place for pagers or other VD controllers like mousewheeling the desktop) it would be possible to implement a custom scren aware virtual desktop behavior in a simple kwin script - just that it is limited to it's own functionality (ie. the script can assign some shortcuts, but pagers etc. will still alter the VD for the entire desktop) However you stated that:
Where the first part should be really not the least problem and the second one is mostly related to not having the active screen follow the mouse ("kcmshell4 kwinoptions") and preventing windows from calling for an initial position (kcmshell4 kwinrules) resp. have the launcher and application support the startup information - yet there's no guarantee and no way from the windowmanager to link "this click" to "this window showing up". KDE 4.4.5 is btw. *tremendously* dated, multihead support (independent X11 screens w/o ability to move windows around) got at least some improvements later on - nor is scripting supported for that version. |
Registered users: Bing [Bot], Google [Bot], q.ignora, watchstar