[Usability] Desktop usability issues: some comments from the country of bears, vodka and ISO8859-5

[Sergey Udaltsov <sergey udaltsov gmail com>]

Preface

Recently, there was an interesting discussion concerning desktop
standards and usability. Russian-speaking people can read it here:
http://aceler.livejournal.com/771037.html

I think, the list of discussed issues and conclusions is worth
publishing on xdg maillist, so here I am doing my best translating
from Russian...

This text does not express my personal opinion, but still I think the
issues are valid anyway

1. Window Managers

GNOME and KDE use different strategies in the "application - WM"
interaction. As the result, KDE apps in GNOME environment do not
remember window sizes - every time, when started, they occupy full
screen. In contrast, GNOME apps, being run under kwin, are trying to
dictate their window sizes, sometimes conflicting with the kwin's
opinion on that subject. As the result, the window size at startup is
unpredictable. You can see it if you run exaile in kwin.

Another issue - stealing focus. In X Window, every app that requests
focus, gets it. In some cases, it causes frustration - for example,
when OOo startup takes a while, user might switch to another window,
and then SUDDELY find himself in OOo. We insist that explicit
immediate focus change on request is a bad idea. If some app has
focus, it should keep it till user explicitly switches. If another app
wants it - it can kindly inform user that it need some attention...
There are already ways to do that.

Conclusion: address these matters in the specs regulating WM behavior (EWMH)

2. Primary X Window selection behavior

In GNOME/GTK, primary selection includes whatever is selected on the
screen. That includes automatically-selected text fragment like file
autocompletion string. In KDE primary selection includes only text
explicitly selected by the user, no automatical selection performed.
GNOME/GTK's approach creates serious problems in some cases. For
example, consider server addition dialog in XChat. Once you add new
server, it appears as 'newserver/6667', then you double-clicks (to
edit it) - and ... the server name is immediatly selected, so whatever
you had in your primary selection previously is overridden. Of course,
you still have keyboard with Ctrl-C/Ctrl-V but it is a different
mechanism. Same story about "Run Application" dialog (Alt-F2) - if
you're using it, you're loosing whatever you had selected before.

Conclusion: standardize KDE approach to primary selection

3. Open/Save dialogs

The dialogs are platform-specific, it is a well-known fact. It would
not be technically difficult to provide the selection mechanism -
allowing user to choose the dialog variant he likes best. It can be
done using DBUS calls. Once this interface is standardized, the
dialogs could be implemented using FLTK, openmotif, ...

There is one closely related issue - the bookmarking mechanism, used
in these dialogs, should be standardized as well.

Conslusion: There is a need in DBUS standard on this interface.
Additionally, we need some convension for bookmarks (something like
directory .config/bookmarks with symlinks or .desktop files or
smth...). The most serious issues to address: relatively expensive
outproc calls, no standard VFS used by all DEs, difficult per-app
customization of the open/save dialog (used by some apps).

4. Hotkeys and layout switching shortcuts are sometimes not compatible

This bug is as ancient as X11 and XKB. Once you configure Ctrl+Shift
as layout switching (=group switching) shortcut in XKB, you cannot use
it in "normal shortcuts". The root cause of that is that X11 always
acts on key press, not on key release - and you cannot assign
different actions on key press and key release.

Conclusion: X.Org/XKB should be (incompatibly?) fixed: allow
specifying separate actions on key press and key release. It most
probably would explode a living hell of issues, but we'll never know
till we try.

5. Global hotkeys are controlled in several places.

GNOME apps tend to start gnome-settings-daemon (otherwise they look
weird). And g-s-d may grab some shortcuts. If it happens in KDE, the
results may be unpredictable - two sets of hotkeys are interfering...

Conclusion: actually, none. We need a good idea here

6. Independend passwords/keys storages

Conclusion: We need either single cross-desktop wallet or, at least,
secure DBUS interface to access one.

We have to keep in mind that desktop standard are not only for
GNOME/KDE bundled apps, but also for apps created by ISV. It would be
nice if we guarantee that 3rd party apps look nice in any
fdo-compatible environment, out of the box, with the minimal
(reasonable) effort from developers. This might be the more essential
issue than making GNOME apps look nice in KDE and vice versa. Just
consider Firefox ignoring file extensions handling in KDE. Consider
Opera having issues with GNOME notification are (tray)..

Any opinions, comments?

Cheers,

Sergey (on behalf of a little Russian-speaking FOSS crowd)