> 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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
