> Shouldn't the service be part of the framework? > How usable is the framework without the service? > Compiling is good, but running is even better :-)
This is the reason why the split has not happened before. The purpose of the library is: [1] - to report document/resource events to the service [2] - to allow applications to see what activities exist, to see what is the current activity, and to request activity creation, switching, etc (these few latest features are generally intended to be used by the workspace, not by the application, but it can be used by anyone). If the service is not running [1] is ignorred (nowhere to send the data to), [2] shows that there is only one activity present and applications do not need to implement two different behaviours for activity-enabled and activity-disabled environments. So, applications that do link to activities will run and work uninterrupted even if the service is not present. Currently, more than a few apps have ifdefs for kactivities-enabled/disabled, which is not the ideal situation. At some point, somebody might want to implement the [1] for windows or mac using the platform systems for usage tracking. Cheers, Ivan _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
