I agree that this is a bit more complicated then it looked in the beginnig so I'll just add my vision on this: 1. This should be considered for simpler use cases, I think if we start considering switching layouts inside OOo document it'll be just separate discussion on its own. Current use for example in KDE (as I have one request) is from Parsley ( <a href="http://edu.kde.org/parley/">http://edu.kde.org/parley/</a>) - the author says there's a demand from users, so we can't just ignore that. For that use case you have separate input fields for different languages and it'd be natural if application can automatically switch when you focus to e.g. English word or Ukrainian word... 2. Global/per application/window switching: 2.1. Are there any cases where application have to switch layout not for itself but for the whole desktop - I don't have any good example but I would not rule it out completely: may be somebody wants to have his own layout switching, e.g. with voice recognition module... 2.2. If system is not in per application or per window layout mode (but in global layout mode), we may have to go two ways:  1) assume global switching is what user wants, so whether he switches with keyboard or DBUS it affects all apps  2) emulate per app/win switching just for DBUS client(s) there might even be a flag "switch_type: {global, app, win}" 3. Now if we have per application/window switch, I think we can just enforce that switch by DBUS happens only for requested app/window. Then we need another parameter "window" - thus we escape races Lubos described here. 4. BIG alternative - is to stick to components (like those that gonna be used in screensavers) - they provide integrated nice UI and in cases like screensavers/dm provide better solution. Theoretically we can add some features to provide non-ui control, i.e. make component invisible  and add some API to control layout. Of course in this case we tie up the app into switcher. So all apps that need this feature will be desktop/switcher-bound. So far I am not defending any direction but rather putting how I see possible solutions so we can discuss that. Andriy