[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Fwd: App-start on proper desktop - some thoughts...
From:       tibirna () kde ! org
Date:       2000-06-01 4:30:09
[Download RAW message or body]

On Wed, 31 May 2000, Waldo Bastian wrote:

> 1) Some applications, such as Netscape, force themselves to pop onto the
> current desktop.  No clue why this is happening, any ideas?  KDE2
> applications work flawlessly.

Netscape and Java windows have the bad habit of doing everything the
reverse way :-(

> 2) Applications that use splash screens and/or multiple windows don't
> really behave the way a user would expect, e.g: the splash screen is
> mapped onto the original desktop, but any additional windows will pop up
> on the current desktop.

I didn't understand from your expose what mechanism/algorithm you're using
to achieve desktop capturing, but I think it should be possible to make
your mechanism ignore (or move over) splash screens. These are, usually,
modeless windows without any decoration at all, so they should be
identifiable. Just capture the next window after.

> 3) Kicker doesn't use KRun when you launch an application by using an icon
> on the panel itself.  Any reason why?

Only konqui and help icons are like this, 'cause they use (used to
use up to today?) kfmclient. The others should use KRun, if I
well understood. 

> I have a few thoughts on #2.  One is to implement a timer, for say 3
> seconds, where all windows that are mapped after the initial will still
> have the initial desktop property.  However, it seems what's missing here
> is only windows have a concept of current desktop - not the applications
> themselves.  How about we extend Rik's kmapnotify lib even further - it
> can set a WM_APP_PID property on each opened window, which KWin can use to
> determine which process owns which windows.  Then, this can be done
> properly - kwin can keep track of the concept of current desktop by PID,
> and ensure new windows are mapped onto the same desktop that the
> application currently 'resides' on.  The PID property may even be valuable
> for other code, too.

Hrrrmm! The X windows (clients) are always stored in a tree. Each
application has one (or more, details below) toplevel windows and a bunch
of child windows (transients or not). By walking on this tree, you can
tell what window pertains to what app, no need to store the PID.

On the contrary, if an app decides to have many toplevel windows, then
this should be because it has a good reason to do so, and an attempt from
us to force them grouped around the PID could only go bad. Think of
netscape windows. You would never be able to have multiple netscape views
spawned from the same process on multiple desktops.

KWin already implements mechanisms for keeping windows of a same app
(toplevel + children) on the same desktop.

> I'm really undecided on the second solution though.  Many current X
> applications don't really seem to know about 'desktops', and the above
> code could cause problems?  Definitely need some more opinions here.

Well, the "desktop" is an invention of the virtual window managers, and
it's not more than hiding a bunch of windows and showing them
automatically when changing from a desktop to another. And this is of
course the job of the WM, no need for the app to know anything about it.

> In addition, I'm setting a new window property.  Should this be
> part of the emerging window manager standard, even if a private kde
> extension?

Not necessarily. But creating new window properties should use the most
conservative principles possible. For the sake of future development.

> I'd like to investigate these a bit further before I either commit or
> decide this is a bad idea, but at least I'm making progress :)

Wait for Matthias Ettrich. What I said here is pure garbage,
possibly. He's the definite fundamental window manager functionality
master for KDE.


-- 
Cristian Tibirna     : ctibirna@total.net     : www.total.net/~ctibirna
PhD Student          : ctibirna@gch.ulaval.ca : web.gch.ulaval.ca/~ctibirna
KDE contact - Canada :  tibirna@kde.org       : www.kde.org

[prev in list] [next in list] [prev in thread] [next in thread]