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

List:       kwin
Subject:    Re: activity switching during logout
From:       Chani <chanika () gmail ! com>
Date:       2010-12-02 21:03:41
Message-ID: 201012022203.42233.chanika () gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On December 2, 2010 21:50:03 Martin Gräßlin wrote:
> On Thursday 02 December 2010 21:44:26 Chani wrote:
> > On December 2, 2010 21:34:08 Martin Gräßlin wrote:
> > > On Thursday 02 December 2010 18:46:20 Aaron J. Seigo wrote:
> > > > On Thursday, December 2, 2010, Chani wrote:
> > > > > thoughts?
> > > > 
> > > > on log out the activity should not be switched automatically just
> > > > because an app needs confirmation of something. just show the window.
> > > > temporarily associate it with the current activity if needed.
> > > 
> > > +1  on that. I think it makes most sense and I even consider switching
> > > desktop as described in Chani's mail as wrong. The other windows should
> > > be brought to the current desktop (though that is not always possible,
> > > window rules might prevent it).
> > 
> > I tried to make it show without being on the activity, and couldn't get
> > it to do anything. do you know how to do that?
> > "temporarily" adding it to the current activity brings the question of
> > how one can actually make that temporary - both ensuring it's
> > unassociated if the user cancels logout, and assuring the association
> > isn't saved if logout continues.
> 
> Could we fake the temporary assignment to current activity in KWin? I'm not
> sure how you handle it in the code, but can't you just call the right
> slot/method with the right parameters?

Client keeps itself in sync with the x properties.
since manage.cpp is part of Client, maybe I could go straight for the 
privates, add a second member to back up the list... or add a flag and have 
isOnCurrentDesktop or isOnCurrentActivity to just return true if it's set...

hmm, yes, that might actually work! :)

> 
> > if the damn window can just say "force showing me
> > everywhere for a bit" that's much nicer...
> 
> bad idea, I know a lot apps would love to say "I'm important, show me" all
> the time. That's like the systray in Windows ;-)

nah, I didn't mean it that way, I meant Client deciding it internally. :)
however, it would make infinitely more sense for ksmserver to tell us who's 
doing SessionInteract at the moment - all this code is useless if someone 
decides to do a "save?" dialog that's not a separate window (say, one inside a 
qgraphicsscene or qml thingy...)

I'm going to end up writing a new session protocol after all. damnit. :)

-- 
Chani
http://chani.ca

["signature.asc" (application/pgp-signature)]

_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin


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