> On Jan. 23, 2015, 7: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. > > Martin Gräßlin wrote: > > 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. > > Ivan Čukić wrote: > Vhat is the rationale behind removing org.kde.KWin? > > I get that it does not fit the multi-head thing well, but > 1) does it make significant problems in that case? > 2) is multi-head really a significant use-case to care that it makes > problems? > > I'm asking this as a general question, not only for this patch. > > Namely, IIRC, the X session stuff will not exist on Wayland, so this > might not be as important as one would think (aka, this will need to be > reimplemented in a different way at some point). > > Martin Gräßlin wrote: > org.kde.kwin is going to be removed as it's a left-over. We have > transitioned to org.kde.KWin and support there a proper watch service to be > able to take over the service name (there's a race when restarting kwin). > > org.kde.KWin on the other hand is not guaranteed, as there is an env > variable which can change the service name. > > Xuetian Weng wrote: > Who would use this environment variable? I don't see kwin itself use it, > will startkde use it? Or it will just be used by user randomly? > If it's only used by kwin, let's not say it's not guaranteed. People can > always use any env variable in a wrong way that will break the system/desktop > functionality. > > I don't even see how kwin avoid dbus name conflict in current code (for > org.kde.KWin. There's code for org.kde.kwin to avoid this by using screen > number). > > Martin Gräßlin wrote: > > I don't even see how kwin avoid dbus name conflict in current code > > You can trust me - I know KWin's code. If I say there is code for it, > then there is :-) Have a look into dbusinterface.cpp
I hate what I'm going to propose since it will be a bad 'fix'. The only rationale I have behind it is that it should not be temporary code that spans a decade of kde versions, since it should become irrelevant in a world without X. 1. Access org.kde.KWin as the service, or using what is specified in the environment variable. - KAMD and KWin do not need to share the environment, so this might break on some set-ups - Does not work for multi-head (but kamd is not designed to be on multiple sessions, anyhow) + Works in the most common use-cases 2. Use the root window property. + Proper way to do it, maybe - Will not support multi-head since kamd does not, might get confused which KWin to contact. Maybe a possibility would be to actually contact all KWin instances, and deal with them all, but IMO that would be an overkill. - Would introduce another place in which KAMD needs to know about X - Ivan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122065/#review74574 ----------------------------------------------------------- On Jan. 22, 2015, 11:42 p.m., Xuetian Weng wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122065/ > ----------------------------------------------------------- > > (Updated Jan. 22, 2015, 11:42 p.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
