unity-design team mailing list archive

["frederik.nnaji@xxxxxxxxx" <frederik.nnaji@xxxxxxxxx>]

On Fri, Jan 28, 2011 at 14:37, Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> frederik.nnaji@xxxxxxxxx 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/