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)
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

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
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On September 1, 2009, John Tapsell 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, ...
>
> If it's not technically difficult, send a patch :-D
> There have actually been an (several?) attempt to do so, since it also

Qt has achieved this already, without using DBus however. the target needs to
be able to integrate with one of the supported Qt event loops however. Qt,
KDE, Gtk+, Windows and Mac are all supported.

--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Framework


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[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
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Aceler]

John Tapsell johnflux at gmail.com wrote at Tue Sep 1 07:00:55 PDT 2009:
>> 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.

Well, if you turn the focus stealing prevention in Kwin on, it will prevent focus stealing from all windows... including Open/Save dialogs for example. Also, it does not prevent window from raising — you will get an unfocused, but raised window. Very funny :)

This feature, as I think, is useful only if you set focus follow mouse.

--
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Rodney Dawes-2]

On Thu, 2009-09-03 at 11:17 +0000, Aceler wrote:

> John Tapsell johnflux at gmail.com wrote at Tue Sep 1 07:00:55 PDT 2009:
> >> 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.
>
> Well, if you turn the focus stealing prevention in Kwin on, it will
> prevent focus stealing from all windows... including Open/Save dialogs
> for example. Also, it does not prevent window from raising — you will
> get an unfocused, but raised window. Very funny :)
>
> This feature, as I think, is useful only if you set focus follow
> mouse.
>

Eh, preventing focus stealing is very very hard to get right, especially
for very active users that open/close lots of windows quickly.

The funny part though is that The Web is going through all the same bugs
that have already been fixed in the desktop 10 times over, yet again. :(
Try using some ajax-heavy web sites with sub-windows and dialogs and
you'll see what I mean.


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[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

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Thursday, 2009-09-03, Aceler wrote:
> John Tapsell johnflux at gmail.com wrote at Tue Sep 1 07:00:55 PDT 2009:
> >> 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.
>
> Well, if you turn the focus stealing prevention in Kwin on, it will prevent
> focus stealing from all windows... including Open/Save dialogs for example.

I haven't tried the most rigid setting, but I think that even then it respects
transientFor, i.e. knows that it is dealing with a subwindow of the currently
interactive app. At least it does on default settings.

Cheers,
Kevin


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[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
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[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

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[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
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[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

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg