On Fri, Jan 28, 2011 at 14:37, Matthew Paul Thomas m...@canonical.comwrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
frederik.nn...@gmail.com wrote on 19/01/11 07:28:
...
Imagine you're writing your essay in your favourite Word Processor,
typing, clicking, panning and zooming, whatever.
Now there's this word you couldn't find in the Word Processor's
built-in dictionary, so you need to open your favourite Browser to find
it online.
Now there are precisely 2 things that can happen:
1) the browser starts up immediately, i.e. before you get the chance to
interact with anything else
2) the browser starts up delayed, i.e. you get enough time to start
typing, clicking or otherwise interacting with another app, before
browser's launch is complete
*now*, in case 1 we have all the conditions satisfied for arrogantly
raising the browser window, because since the menu-interaction
(clicking the browser's launcher) and *now*, no human-computer
interaction has taken place anywhere else (disregarding eye movement
for now..).
...
The reason that doesn't work is that the window manager has no idea that
the thing you clicked on was a browser launcher. So it has no idea that
your click, and the window that opens a few seconds later, are related.
wouldn't an event logging service hooked into the WM and into the respective
launching layers and panels e.g. Docky and AWN or Unity help with that?
A toolkit and window manager that worked together could solve this, by
saying, for an event handler, something like (for example) this handler
is likely to open a window of class 'Msgcompose', 'Thunderbird'.
hmm.. i was not aware that there is such a large chasm between window
management and content.
This is indeed a larger issue imo! Bridging this canyon would open up a lot
of dead-ends in DE oriented interaction design.
[...]
And if that toolkit was used for most applications on the platform, the
window manager could then be harsher on windows that opened without that
kind of omen -- opening them unfocused unless there had been a period of
inactivity longer than Compiz uses now.
But as long as Ubuntu suffers from toolkit proliferation, and the
toolkits and the window manager don't talk to each other, all the window
manager can do is guess. And sometimes it will guess wrong.
when i first read your article about *A unified menu bar*¹, i was so
impressed with how much valuable impressions one could gain by just glancing
over the images already.
The part about toolkit proliferation became self-explanatory by reading its
title already.
This problem seems rooted so deep inside our FOSS desktop, that it might be
unachievable right now, even though it would be outstanding in terms of
consistency and going-by-the-book.
What would probably be more helpful than telling everyone to focus on using
one toolkit, could perhaps be to offer them a unifying bus through which
they can do some more IPC.
I know that platform interoperability was largely improved with the
introduction of dbus and xdg-utils. couldn't these technologies be of help
here?
In my beginners mind i'm already scheming up several approaches that would
work on a theoretical level. Are there realistic options here?
¹ http://design.canonical.com/2010/05/menu-bar/
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help : https://help.launchpad.net/ListHelp
