> kdeui and even kio do not currently depend on nepomuk. a puzzler :) we > should ask Sebastian Trueg for some guidance here i think.
Well, these classes don't depend on nepomuk directly, that is, no nepomuk linking required. The Controller class is completely usable without it. That's why I thought to place Info into kdebase - since kdebase provides nepomuk. > registerDocumentWindow? :) Better than the idea above and is ok as far as I'm concerned. :) > > > where does Info store this information? and shouldn't the persistence > > > be an implementation detail that users of the classes shouldn't need > > > to worry about? right now it's confusing as to which class to use > > > given the duplication in API. > > > > The idea is that Consumer class is an entry-level API - minimum for it to > > be able to *react* to activity events. > > > > Info class, on the other hand, should be for the applications that really > > want to use activities (to be active participants instead of being only > > bystanders) > > what would the definition be for each? > > to me, adding resources to an activity is being a full participant. > changing internal state based on the activity id perhaps isn't. > > if i want to show the name of the activity in the UI somewhere, then i > don't think it's too much to ask me to create an ActivityInfo class. Ok, yes, the name is not that important to entry-level users. I'll move it. > so this would be resolved by saying "this feature set requires nepomuk"? That was the idea. But, we could just add which methods depend on nepomuk running in apidox. > it is, as long as it doesn't increase the size of the enum (e.g. we have > 32bits to work with there) Ok, so we're safe for now ;) > going on. ditto perhaps for the Consumer class. something we can easily > add as an optimization later as well, though. :) Ok ;) Cheerio, Ivan -- There are no such things as applied sciences, only applications of science. -- Louis Pasteur _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel