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

[Sergey Udaltsov]

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
Usability@...
http://mail.gnome.org/mailman/listinfo/usability

[John Tapsell-3]

2009/9/1 Sergey Udaltsov <sergey.udaltsov@...>:
> Another issue - stealing focus. In X Window, every app that requests
> focus, gets it.

I think KWin disables focus stealing by default.  Either way, you can
turn it on focus-stealing-prevention.

> 2. Primary X Window selection behavior
> ...
> Conclusion: standardize KDE approach to primary selection

Talk to the gnome people then...  maybe write a freedesktop proposal.

> 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, ...

If it's not technically difficult, send a patch :-D
There have actually been an (several?) attempt to do so, since it also
adds the advantage of being easier to secure, selinux style.  I
thought the portland project was going to have a go, but I can't see
anything on their website about it.

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

meh

>
> 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...).

Write a spec for this and propose it.

> The most serious issues to address: relatively expensive
> outproc calls,

What's outproc?

> no standard VFS used by all DEs

Difficult.  Something portland is/was also trying to solve.


> difficult per-app
> customization of the open/save dialog (used by some apps).

So..  it is "technically difficult" then? :P

> 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.

I think this is being worked on by someone.  Google around maybe.


John
_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability

[Thorsten Wilms]

On Tue, 2009-09-01 at 14:47 +0100, Sergey Udaltsov wrote:

> 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

Much wider scope, but somewhat fitting:
http://thorwil.wordpress.com/2007/04/10/event-to-action-mapping-1/

--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability

[Claes H]

Hi,

I think this list had lots of valid points.

> 3. Open/Save dialogs
>

I would like to add to this a shared state / history between open /
save dialogs to make it easer to open in one application that was just
saved in another application.

Claes
_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability

[Aleksey Shaferov]

Please take a look on another problem found by gnome user from country of bears, vodka and balalayka :).
I think it is relevant to the usability problems.
http://lists.freedesktop.org/archives/xdg/2009-August/010981.html
For Russian-speaking people http://www.linux.org.ru/view-message.jsp?msgid=3991608

_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability

[nf2.email]

On Tue, Sep 1, 2009 at 3:47 PM, Sergey
Udaltsov<sergey.udaltsov@...> wrote:
> 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, ...

I think the first step (and requirement for switchable dialogs) would
be driving everything with a standard VFS engine. That would to a
certain degree structurally align what appears in the dialogs, which
IMHO is the most important thing for usability in the first place.

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

There actually is a spec for this and I implemented it for KDE. It
just hasen't been implemented by GTK yet. AFAIK the problem is the
lack of an appropriate XML parser in the stack below GTK and GLIB
(GIO).

> The most serious issues to address: [...], no standard VFS used by all DEs,

I believe that's - realistically - only solvable by picking one of the
existing VFS implementations as a standard, and wrapping the other
around it. For me it's quite obvious how things would fit together.
The necessary adjustments don't seem to be technically difficult / or
are already beeing worked on (like standardizing password storage).
Getting there is more a matter of the important people saying "let's
bite the bullet and just do it!".

Regards,

Norbert
_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability

[A. Walton-2]

On Fri, Sep 4, 2009 at 9:11 AM, nf2<nf2.email@...> wrote:

> On Tue, Sep 1, 2009 at 3:47 PM, Sergey
> Udaltsov<sergey.udaltsov@...> wrote:
>> 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, ...
>
> I think the first step (and requirement for switchable dialogs) would
> be driving everything with a standard VFS engine. That would to a
> certain degree structurally align what appears in the dialogs, which
> IMHO is the most important thing for usability in the first place.
>
>>
>> There is one closely related issue - the bookmarking mechanism, used
>> in these dialogs, should be standardized as well.
>
> There actually is a spec for this and I implemented it for KDE. It
> just hasen't been implemented by GTK yet. AFAIK the problem is the
> lack of an appropriate XML parser in the stack below GTK and GLIB
> (GIO).

Would that be GMarkup and the corresponding GBookmarkFile? It
certainly sounds like it... We don't currently use it for storing
"Places', but we have a bug(s?) open towards moving that direction[1].

-A. Walton

[1]: off the top of my head would be something like GNOME bug #413076,
for example. http://bugzilla.gnome.org/show_bug.cgi?id=413076

>> The most serious issues to address: [...], no standard VFS used by all DEs,
>
> I believe that's - realistically - only solvable by picking one of the
> existing VFS implementations as a standard, and wrapping the other
> around it. For me it's quite obvious how things would fit together.
> The necessary adjustments don't seem to be technically difficult / or
> are already beeing worked on (like standardizing password storage).
> Getting there is more a matter of the important people saying "let's
> bite the bullet and just do it!".
>
> Regards,
>
> Norbert
> _______________________________________________
> xdg mailing list
> xdg@...
> http://lists.freedesktop.org/mailman/listinfo/xdg

_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability

[nf2.email]

On Fri, Sep 4, 2009 at 4:48 PM, A. Walton<awalton@...> wrote:
> On Fri, Sep 4, 2009 at 9:11 AM, nf2<nf2.email@...> wrote:
>> On Tue, Sep 1, 2009 at 3:47 PM, Sergey
>> Udaltsov<sergey.udaltsov@...> wrote:

>>> There is one closely related issue - the bookmarking mechanism, used
>>> in these dialogs, should be standardized as well.
>>
>> There actually is a spec for this and I implemented it for KDE. It
>> just hasen't been implemented by GTK yet. AFAIK the problem is the
>> lack of an appropriate XML parser in the stack below GTK and GLIB
>> (GIO).
>
> Would that be GMarkup and the corresponding GBookmarkFile? It
> certainly sounds like it... We don't currently use it for storing
> "Places', but we have a bug(s?) open towards moving that direction[1].

As far as i remember the problem with GBookmarkFile is that it does
not preserve "private" metadata nodes which are needed by KDE (see the
example below). Preserving those metadata nodes would probably require
a DOM parser, which is not available inside GLib. Parhaps the
GBookmarkFile implementation should become a dlopened plugin which
links something like libxml2, but i don't know if that would be
possible.

-------- ~/.local/share/user-places.xbel ---------------
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xbel>
<xbel xmlns:bookmark="http://www.freedesktop.org/standards/desktop-bookmarks"
xmlns:mime="http://www.freedesktop.org/standards/shared-mime-info"
xmlns:kdepriv="http://www.kde.org/kdepriv" >
 <bookmark href="file:///bigtemp" >
  <title>bigtemp</title>
  <info>
   <metadata owner="http://freedesktop.org" >
    <bookmark:icon name="inode-directory" />
   </metadata>
   <metadata owner="http://www.kde.org" >
    <ID>1248471539/0</ID>
   </metadata>
  </info>
 </bookmark>
</xbel>
-------------------------------------------------------------

There seems to be another related bug:

http://bugzilla.gnome.org/show_bug.cgi?id=556040

Cheers,
Norbert
_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability

[Reinout van Schouwen]

On di, 2009-09-01 at 21:21 +0200, Claes H wrote:

> I would like to add to this a shared state / history between open /
> save dialogs to make it easer to open in one application that was just
> saved in another application.

I don't think something special is needed for this actually. Apps that
do a Save action should simply make sure they add the saved document to
the Recently used file list. (Maybe this could be promoted to a Gnome
Goal?)

regards,

--
Reinout van Schouwen

_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability