On Fri, Jan 28, 2011 at 15:52, frederik.nn...@gmail.com < frederik.nn...@gmail.com> wrote:
> On Fri, Jan 28, 2011 at 14:37, Matthew Paul Thomas <m...@canonical.com>wrote: > >> -----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? > ok, i found this on the xdg ML... i think Lennart will give it a shot: http://www.mail-archive.com/xdg@lists.freedesktop.org/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?
_______________________________________________ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp