unity-design team mailing list archive

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

On Fri, Jan 28, 2011 at 15:52, frederik.nnaji@xxxxxxxxx <
frederik.nnaji@xxxxxxxxx> wrote:

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

ok, i found this on the xdg ML... i think Lennart will give it a shot:
http://www.mail-archive.com/xdg@xxxxxxxxxxxxxxxxxxxxx/msg06365.html
a sample of the email:

> My rough plan is to introduce systemd sooner or later as session manager into GNOME and then come to a new definition of what an app is along the lines of "one cgroup per app, matching one .desktop file".
>
> That information would then be available to things like gnome-shell to match processes to apps to desktop files to windows, instead of the current heuristics everybody uses.
> The goal in the long run is definitely to give the foreground app an extra CPU boost, where gnome-shell decides what the foreground app is.
>
> Perhaps this will address the problems discussed above!?
Or would toolkit-WM IPC in userland be more preferable and more viable
solution in our case?