On Tuesday, August 26, 2014 12.13:24 Ivan Čukić wrote: > > Does the library make sense without the daemon? If not then it falls into > > this constraint from https://community.kde.org/Frameworks/Policies : > > > > "Solutions have a mandatory runtime dependencies, it is part of their > > design and where their added value comes from" > > That is the reason it ended up in the same repository. > > But it is not really mandatory. The library does not do anything (at least > not at the moment) but it can function without any issues even if the > service is not present. Meaning that apps don't need to ifdef every part of > their code- base that touches activities in order to properly work without > the service. They will think that there is only one activity, and they can > behave accordingly.
Right; but that's probably not the expected behavior from either an application developer's or a user's POV, correct? I assume they expect that using the library and having the framework for activities installed means it will actually work. That implies having the service with the framework. > While the library is guaranteed to be compilable on crappy^Wvarious > compilers and functional on any platform, the service is not - nor it will > be - it is *nix only with the possibility to be run on other systems (like > plasma). The session handling won't work, that's for sure; that is tightly bound to kwin and ksmserver. That's not entirely unexpected ... (Quite a # of dbus calls in there to complete a single activity changed .. library -> service -> kwin -> ksmerver and back again.) Is it a matter of not wanting to use "dumbed-down" C++11 (so it won't compile on all platforms) or are there really no features in the service which are self-hosting? It seems from a quick read of the code that without kwin/ksmserver, it still switches activities, you just don't get application session handling with that. So it is functional, just missing features? -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.