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) _______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
