disable fx prior to first 4.6 startups

[Duncan]

Felix Miata posted on Thu, 07 Jul 2011 17:29:52 -0400 as excerpted:

> On 2011/07/07 22:54 (GMT+0200) Alex Schuster composed:
> 
>> schrieb Felix Miata:
> 
>>>  I've done several new installations lately, openSUSE 11.4 and Kubuntu
>>>  11.04, all on i865G video, in each case doing system updates (to e.g.
>>>  4.6.4) prior to first X start. All have been very difficult to get
>>>  into anything after starting X, including systemsettings to turn off
>>>  the broken desktop FX. Phantom windows come and go, including main
>>>  menu& panel&  clock settings, How on further i865G installations can
>>>  I configure a system globally to disable desktop FX by default? Will
>>>  it be the same for 4.7?
> 
>> I'm not sure if I understand this right... so the active desktop
>> effects mess up everything, and it is even hard to start systemsettings
>> and turn them off?
> 
> Exactly. I can rarely remember the run command hotkey. If I did, I'd
> open Konsole and try doing things from that, or run command.
> 
>> Try Alt+Shift+F12, this toggles the desktop effects. I use it on a PC
>> (not
> 
> Another hotkey combination I'll probably forget as fast as I discovered
> it, or at least not remember when I need to.

FWIW, for such things I tend to (try to) remember mostly that something 
is /possible/, along with enough about it to look it up again or ask 
about it later, should the need arise, as opposed to (ineffectively) 
trying to remember specific details.

The more general approach seems to work quite well, for me, as I'm able 
to retain general data about far more "tricks and workarounds" than I 
might otherwise remember, generally enough to successfully look it up 
later, if it proves to be needed.  This stands me in good stead not only 
personally but in all the various lists I follow, where I can thus more 
often be of help to someone experiencing an issue I'd never come across 
on my own.

In this case, it sounds like you tend to have access to more than a 
single computer.  As such, all you need to remember is that there is such 
a keyboard shortcut, and you can look up the details on a working system, 
should you need it.  But chances are, after doing that a couple of times, 
you'll remember it anyway, because then you'll have enough additional 
actual experience with it to create an associated memory that's much 
harder to forget the details about, than some arbitrary hotkey combo with 
no actual experience to back it up.

What I'd therefore try to remember in this case, is that such a hotkey-
combo exists, and where one finds it on a working system -- in the same 
place one might find other similar hotkey-combos, in kcontrol 
(systemsettings that aren't system-settings -- actually the problem you 
have here but see below, but rather, user-specific kde settings, so the 
kde3 term kcontrol remains far more accurate and is thus the term I use).

In kcontrol, the key is to remember to look for shortcuts.  In this case, 
it's under common appearance and behavior, shortcuts and gestures.  Once 
there, one has to choose between three different modules, custom, 
standard, or global, and getting the right one the first time might be 
difficult.  But there's only three, so if one isn't it, the next is easy 
enough to switch to.

In this case, we want global keyboard shortcuts.  Then you must figure 
out which kde component that shortcut controls.  Looking at the available 
choices, kwin looks likely, and indeed, that's where the setting is 
found.  Then you have to find a description that matches your memory of 
the function you're trying to find the hotkey for.  The keywords 
"suspend" and "compositing", whichever one you happen to remember 
easiest, is next.  Sure enough, "suspend compositing" is a listed 
action.  Clicking it lets you see what the default shortcut is, for that.

So if all you remember is that it's compositing that you're trying to 
control and that there's a hotkey for it, plus have the general knowledge 
that such settings are configured in kcontrol/systemsettings (that aren't 
systemsettings...) you should be able to look up the specific hotkey on a 
working system, looking for shortcuts in kcontrol, and using general 
logic to find the specific module and setting after that.

Meanwhile, it won't help here but for actually use and FWIW, I've 
reassigned most of the various kwin shortcuts I actually use to winkey-
modifier shortcuts.  In kde, the windows key is normally listed as meta 
(or occasionally as super), but remembering win-X, where X is usually the 
first letter of what I'm trying to do, and the winkey is associated with 
kwin, that is, windows functions, is a whole lot easier than the 
arbitrary alt-shift-control-fN keys that kde defaults to.  So win-s 
toggles suspend compositing here, win-g triggers the desktop-grid effect, 
win-c triggers the cube effect, win-ctrl-s (win-s being already taken) 
toggles the snow effect, etc.  (win-end closes a window, win-pgup 
maximizes, win-pgdn minimizes, win-home rolls it up into the titlebar, 
win-insert toggles the window-menu, win-h hides/unhides the titlebar and 
window decorations... ctrl-win-up and ctrl-win-dn zoom in and out, ctrl-
win-left returns to 100% zoom...)

Win-<key> is simply easier to remember for me...

>> You can also edit ~/.kde/share/config/kwinrc, and set Enabled=false in
>> the [Compositing] section.
> 
> That would not be a global fix. That file doesn't even exist on a new
> install until after KDE gets started, and then only for each
> individual's first login.

> On 11.4, I couldn't find a kwinrc in any of /etc, /opt, /var or /usr.

It's worth noting here the way kde's config stacks.  In general, a user's 
~/.kde/share mirrors the same config structure under (for most distros at 
least, I'd guess, some may have /opt/kde/share or some such, instead)
/usr/share, and kde's operational config for any user running it comes 
from an overlaying of the user config over the global config, with the 
user config taking precedence if they conflict.  For most things, kde 
only saves DIFFERENCES from the defaults to a user's home dir.

So if a ~/.kde/share/config/kwinrc file exists with certain settings, 
then those SAME settings should be possible to set in a global config 
file located at /usr/share/config/kwinrc.  If that file doesn't exist, 
simply create it, include the sections and specific settings you need for 
your global config, and if a user hasn't specifically overruled those 
settings, they should apply as one would expect.

I haven't tested this specific case, but I bet it'll work as the global 
config overlaid by the user config mechanism is supported by kdelibs' own 
config functionality, so an app creator would have to deliberately go out 
of their way to code their own config storage solution in ordered to 
break it.  This information should be quite helpful to you indeed, both 
for this specific case and in the future.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.