Hi Sebastian, 2012/11/8 Sebastian Kügler <[email protected]>: > * As far as I can see, QWidget-related bits and "service-related" bits are > split, so we're able to drop another ui on top of it for Plasma Active without > much effort. (Even if the UI is a single knob =)) (Correct me if I missed a > few points.) >
Yes this was the idea behind all of it. Each program that want's ti use this can decide to either reuse the available ui or just the the easy to use single parts. It is possible to use the plugin based structure for searching/ metadata fetching and than doe whatever someone wants with the data (a big QVariantMap) and also reuse the actual Nepomuk abstraction, that understands such a QVariantMap structure and allows to easily throw such data into Nepomuk. Conquirere actually uses this to integrate the search/select/save frontend better into the application. The same can easily be done by plasma or other apps that want to use Web Metadata search and/or Nepomuk integration based on key=value pairs > > * The browser integration is a very cool feature. It's nice that it supports > Konqueror, Chrome and Mozilla/NPAPI on multiple platforms. I suppose it works > with both Rekonq and Konqueror? > The browser part is is bit "experimental" and should all of this go into KDE SC i will leave the browser part in extragear. The problem here is that in order to build the NPAPI part the "kinda complicated" firebreath development enviroment is necessary. reKonq support is currently not possible, because it does not have a plugin api available at the moment. > > * Is there any support for images planned? I think especially additional > geolocation information could be really useful (also for other resource types, > by the way. In Plasma Active the user can set a location, it would be cool if > we could retrieve additional info through Nepomuk about the location, and > thereby being able to relate it to other data, think "Photos taken at current > location" =) > Extraction geo information from images/files is the responsibility of the fileindexer Also "all fotos from location lat/long" isn't part of this. What could be added is a way to extend the fetcher to allow ot get information about a specific geo lat/long. Like lat/long is the City London or something like it. In order to save such additional information, we might need to add a new ontology. > > * One UI issue I see is that it installs a toplevel systemsettings module, > while it should be under "Desktop Search", so part of the Nepomuk KCM (which > is also not great at all, UI-wise :/). I could imagine the primary knobs > integration the service into the system a bit like this: > [...] > If we want to add it to our default install by 4.11 (which I support!), those > should be fixed. > I know the current solution is more temporary, but integration into the Nepomuk KCM isn't so easy either. Nonetheless Vishesh wanted to change this part anyway and some mails ago in this discussion there was the idea to combine the MetaData Extractor and Nepomuk. In this step we will come up with a better looking configuration KCM and this would also allow me to reuse the nepomuk System Tray parts to give information about the current progress. So unless this is a stopper to go extragear I would like to wait for this change for the possible 4.11 integration. > > * the binary name for metadataextractor should probably be nepomuk- > metadataexractor or somesuch (matching other related binaries, easier to find > if uses on the commandline). > I think I will rename everything to Nepomuk WebFetcher and than also adapt the commandline program with it. > > * Is the scripting API documented or is it planned? > Yes it is documented in the doxygen output. I will put the same information to techbase later on too. > > * You're shipping pre-generated Nepomuk headers it seems,[...] > This is fixed, now all these files will be generated from cmake. And have a build switch, so this can be avoided after the first generation. > > * Coding Style > > spacing after if statements:if(bla) becomes if (bla > spacing between arguments: foo(firstArg,secondArg) becomes foo(firstArg, > secondArg) > Whupps, I thought I've already changed QtCreator to respect kdelibs coding style. Seems I've missed these parts. I'll fix that. > > * Licensing > > Please consider using the KDE e.V. clause in your licenses, it makes the legal > side a bit more future proof (it's clearer about the (L)GPL successor). You > can find those on http://techbase.kde.org/Policies/Licensing_Policy From what > I can see, licensing overall pretty much complies otherwise, so that's just a > suggestion. I'll change this too. Cheers and thanks for the long input, Joerg
