On Thursday 04 of June 2009, David C. Rankin wrote:
Listmates,
A Couple of issues for kde43B1 today. (First KDE43 - Rocks!) I never thought I would type those words....
First issue, the "Next" and "Previous" desktop keyboard shortcuts are not defined. There should be a consistent default for users regardless of whether the wm is kwin or compiz. Defining ctrl+alt+left for previous and ctrl+alt+right under global shortcuts -> kwin works fine. (I'll reference ctrl+alt as CA hereafter)
Next, the ctrl+f1 -f4 shortcuts for desktop 1-4 are horribly inefficient due to the left ctrl being at the absolute bottom of the keyboard while the F'keys are at the absolute top. This eliminates the chance of an efficient switch without having to reposition your hands on the keyboard and then reset after the key combo is entered. Even using the right ctrl (which many laptops do not have) requires a stretch with the left hand to reach the F'keys. If the CA+left and CA+right are defined for the 'previous' and 'next', that takes care of the problem, but if anyone can suggest another scheme for desktops 1-4, it would really help get rid of some keyboard inefficiency.
I suggest discussing this upstream, e.g on the kde-usability list (http://www.kde.org/mailinglists/). This does not seem to be openSUSE-specific in any way.
On the same topic of desktop cube rotate efficiency, what is the mouse rotate activation sequence? The CA+leftmouse that compiz uses is great. ctrl (left pinky) + alt (left thumb) and leftmouse with the right hand feels natural by now. Where can we set this in 43? If we can't set it, then that is something to add. If we are consistent across the WM's then a whole lot of confusion can be avoided and the learning curve cut in half.
There is no mouse activation of the cube in KWin now (https://bugs.kde.org/show_bug.cgi?id=163121).
Next (a polish [not Polish]) issue. The animation in all the effects seems rigid or jerky compared to the similar compiz effects. "Cover Switch", "Flip Switch", etc. just seem to jump to the next item without a smooth transition. Adjusting animation duration seems to have little or no effect. Is there something that can be done here?
Works fine here with nvidia. Possibly card-specific. These kinds of bugreports often last until somebody with a similar setup gets bored or tired of it and tries playing with the code.
The "Present Windows" (compiz scale clone) randomly thumbnails the window representations on the desktop seemingly without any rhyme or reason (no alignment, etc..). Can this be updates to work more like its compiz counterpart where you get 1, 2 or 3 "rows" (as needed) of windows of similar size (unless they are just really small windows to begin with)? It looks visually a whole lot better than a hodgepodge or smattering of different sized windows on the desktop.
There actually is a reason for the layout, but if you don't like it, the fixed grid mode can be selected in the settings for this specific effect in the configuration module.
Also on wobbly windows, the current "advanced" adjustments make no sense. Wobbly is basically set up as a spring and mass damper. The relevant constants are the (1) the spring constant (or stiffness) [ that one is right ] (2) damping (or friction) and (3) mass (applied force, tension or displacement). "Wobbliness, "drag" and "move factor" are horribly confusing and just make no technical sense. From working with all of them for a while it seems that the settings are actually fighting each other (like a double-double negative) Here again, being consistent with compiz (where they got the spring constant "Spring K" and friction right) would be a plus.
Upstream. -- Lubos Lunak KDE developer -------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: l.lunak@suse.cz , l.lunak@kde.org Lihovarska 1060/12 tel: +420 284 084 672 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org