Review Request 122065: Fix activity start and stop.

Martin Gräßlin mgraesslin at kde.org
Mon Jan 26 07:01:25 UTC 2015



> On Jan. 23, 2015, 8:40 a.m., Martin Gräßlin wrote:
> > This looks still wrong to me. The service is still called "org.kde.kwin" while it should be "org.kde.KWin". Ideally this gets changed to a generated adaptor from the DBus interface KWin installs.
> > 
> > To make things worse: the service name is not guaranteed to be "org.kde.KWin" - it can be mangled on multi-head systems. I had considered eporting it to a root window property, maybe I should implement that.
> 
> Martin Gräßlin wrote:
>     And just implemented the announcment of the DBus service: https://git.reviewboard.kde.org/r/122215/
> 
> Ivan Čukić wrote:
>     How will this work?
>     
>     KAMD is a unique instance per dbus session, kwin can have more instances. Which instance handles the session stuff? etc.
>     
>     I don't like the idea of introducing another connection from kamd to X.
> 
> Martin Gräßlin wrote:
>     If KAMD doesn't want to support multi-head (which is fine) it should pick the kwin instance responsible for the X head it's on.
> 
> Ivan Čukić wrote:
>     Sorry, I need more details here.
>     
>     What confuses me is the 'X head it's on' - it is a service, it has no UI to be on a specific head. Or am I misunderstanding what a 'head' is? :)
>     
>     Can you describe (nothing detailed - just a few words) the situation when kwin has multiple instances / multiple dbus services. Does it imply separate X sessions?
> 
> Martin Gräßlin wrote:
>     yes in a multi-head environment one has kind of separate X sessions. E.g. you cannot move windows from one head to another and the windows cannot interact with each other. It's a rare situation and most of our daemons do not support it properly.
> 
> Xuetian Weng wrote:
>     I must misread the qdbus autocompletion, so org.kde.kwin is fine. And it seems to be guaranteed that default screen of kwin uses org.kde.kwin. (others will use org.kde.kwin-screen-XX)
> 
> Xuetian Weng wrote:
>     Ah, sorry. The patch is to fix the wrong interface name, not the dbus service name.
>     
>     I think using org.kde.kwin is fine unless this service name will be removed from kwin. Because it's the dbus name for most common default screen if KAMD don't care about multihead.
>     
>     And If two different kwin are in same dbus-session, they will talk to same ksmserver and close session twice?.. It seems there are still many missing pieces in support activities with multihead.
>     
>     Most people are moving to xinerema so it's really a rare case IMHO...
> 
> Martin Gräßlin wrote:
>     > I think using org.kde.kwin is fine unless this service name will be removed from kwin.
>     
>     it will be removed.
> 
> Xuetian Weng wrote:
>     Is it possible to make kwin gurantee that org.kde.KWin is always owned by the kwin for primary screen? All other kwin is actually forked by kwin itself, and I assume that KWIN_DBUS_SERVICE_SUFFIX will be set by kwin itself in the future.
>     
>     And since all other kwin is forked by the "original kwin", is it possible to make kwin to redirect the start/stop activity request to other kwin? If the all other dbus name can be obtained from the main kwin. Thus we will have only one kwin send request to ksmserver and this problem might be solved perfectly.
>     
>     And actually rename dbus service name to a undeterministic one will simply break the dbus activation if we want to have kwin started by systemd user session. I also used to use display-server dependent dbus name in my project in the past and when people ask me for dbus activation I couldn't simply provide it for them because dbus name is unstable and .service (or systemd unit file) file will not be able to handle such case.

> Is it possible to make kwin gurantee that org.kde.KWin is always owned by the kwin for primary screen?

No, there is no guarantee at all that KWin is on org.kde.KWin.

> And since all other kwin is forked by the "original kwin", is it possible to make kwin to redirect the start/stop activity request to other kwin?

Apart from the fact that KWin forks for each head, KWin doesn't know anything of the other instances and doesn't care. This would require a major refactoring and is also in my opinion wrong. Different X mean different sessions.

> And actually rename dbus service name to a undeterministic one will simply break the dbus activation if we want to have kwin started by systemd user session.

Let's not care about maybe features. KWin will probably never be dbus activated.


- Martin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122065/#review74574
-----------------------------------------------------------


On Jan. 23, 2015, 12:42 a.m., Xuetian Weng wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122065/
> -----------------------------------------------------------
> 
> (Updated Jan. 23, 2015, 12:42 a.m.)
> 
> 
> Review request for Plasma, Martin Gräßlin and Ivan Čukić.
> 
> 
> Repository: kactivities
> 
> 
> Description
> -------
> 
> 1. KWin Interface name is wrong
> 2. kactivitymanagerd doesn't listen on ksmserver anymore, thus subSession{Opened,Closed,CloseCanceled} are not called anymore. It need to send Started/Stopped event by itself when kwin dbus call returns.
> 
> 
> Diffs
> -----
> 
>   src/service/ksmserver/KSMServer_p.h c0f5598 
>   src/service/ksmserver/KSMServer.cpp b5e1467 
> 
> Diff: https://git.reviewboard.kde.org/r/122065/diff/
> 
> 
> Testing
> -------
> 
> Now starting and stopping activity works properly.
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20150126/af6da411/attachment-0001.html>


More information about the Plasma-devel mailing list