Re: Moving Baloo forward
Hi Vishesh, 2014/1/17 Vishesh Handa m...@vhanda.in http://community.kde.org/Baloo Could someone please prooof read this page and let me know where it can be improved? I experimented a bit with Conquirere and its possible port to a sql like database. While it is possible, it means I need to change a lot (depended solely on Nepomuk for this one) At the end, without Nepomuk, Conquirere is just KBibTeX which is part of KDE too. Thus I would rather see KBibTeX expanded to pdf/project like behavior rather than putting a lot of effort into copying something that exists, is well testen and widly used already. The Webminer will be ported though, as it can be simply used without nepomuk if applications just want to fetch data and save the data in their own database.
Re: KDEReview: Nepomuk-Controller QML
I guess which icons are shown in the system tray is a setting of the system tray applet, no? Yes but I have now a proper plasma update script, so this issue should be solved now. The script will be installed by default so any user should be updated correctly
Re: KDEReview: Nepomuk-Controller QML
I'd say the Messages.sh pot filename are wrong for both the dataengine and the applet. Please confirm with the plasma developers what's the catalog name that will be loaded but yours doesn't seem to follow the pattern. I see, the i18n techbase article says every qml app needs plasma_applet_ infront of the pot filename same for DataEngine and plasma_engine. I've changed the Messages.sh and some related problems. Thanks for the Hint.
Re: KDEReview: Nepomuk-Controller QML
Assuming this setting is stored in some KConfig based file, wouldn't it be possible to migrate it using kconf_update? Good question. The config is saved in plasma-desktop-appletsrc and I need to add: [Containments][3][Applets][25][Configuration][Applets][36] geometry=0,0,24,24 immutability=1 plugin=nepomukcontroller-qml zvalue=0 it seems the old nepomuk controller did not save to this file instead if this program will be removed from the system it won't start. Have to explicitly start it via $ nepomukcontroller to start it here
Re: KDEReview: Nepomuk-Controller QML
The minor version upgrade process all throughout the KDE/Plasma 4 releases started off as a fairly steady source of minor nits and irritants for users. The Nepomuk controls themselves are already fairly well-known so it's even more important IMO that if they are deprecated that they don't simply disappear completely the first time a new KDE 4.11 user logs in. That is true, I do hope though to increase the awareness of what Nepomuk does in the background by exposing not just the fileindexer but also especially the workload the pim indexer is doing. While the look and feel of the systray will be completely different it is mostly an improvement of the currently rather hidden dialog that comes up. One detail though is missing, the old systray was able give a number of indexer file resources. This number is missing from my QML approach. Not sure how important this number is, as it isn't really a good measure or even a measure at all how big the Nepomuk database is at all. Likewise it would be a good idea to ensure our Release Notes for 4.11 (if any are started) reflect the migration so that our packagers can ensure they change package dependencies if deemed appropriate. I would write a blogpost about this, as soon as this goes into SC. IS there any other action I need to do to ensure packagers are aware of the change? The current nepomukcontroller is enabled in the systray (right click on the systray-settings-enable additional entries) this step must be done for the new nepomuk controller to allow a seamingless transition. Not trying to discourage, but just some things to think about. Don't worry, exactly these kind of thoughts are why the review process exist. I'd rather have overly worrying reviewers than being responsible for an unpleasant transition due to my change. Kind Regards, Joerg
KDEReview: Nepomuk-Controller QML
So after a first introduction in plasma, I like to get this thing into SC. The Nepomuk-Controller aims to replace the current system tray Nepomuk applet. This one allows to suspend/resume and show information for all the indexers, thus this gives any user a small hint what happens in the background and allow them to suspend it, if they need to. For the review I have pushed the branch nepomukcontroller-qml into kde-workspace. You can find the important parts at plasma/generic/dataengines/nepomuk plasma/generic/applet/nepomuk-controller The dataengine as well as the applet is only installed if Nepomuk-Core/Soprano is found as build dependency. This would deprecate: kde-runtime/nepomuk/controller/ and need current nepomuk-core master For an easy to install version there is also: http://quickgit.kde.org/?p=scratch/jehrichs/nepomukcontroller-qml.git Some Pictures: http://wstaw.org/m/2013/03/20/nepomukcontroller-qml1.jpg http://wstaw.org/m/2013/03/20/nepomukcontroller-qml2.jpg http://wstaw.org/m/2013/03/20/nepomukcontroller-qml3.jpg http://wstaw.org/m/2013/03/20/nepomukcontroller-qml4.jpg Any help/comments are welcome. Since my first mail on the plasma devel list, the dbus calls are asynchrone now, the FileWatch service is not shown on default, but can be enabled if the user wants, and the licence should be fine now. Kind Regards Joerg
Re: KDEReview: Nepomuk-Controller QML
Why workspace when you are deprecating something in runtime? All other Plasma::DataEngines and applets (battery, network) are in workspace too. While runtime/plasma has only some generic stuff. So in general it felt like the better place. In addition I think this service info tool is not a runtime dependency, like the KCM, kioslaves for nepomuk and the systray seemed to have ended in runtime only, because it got added there all together. Regards, Joerg
Re: Nepomuk Metadata Extractor moved to KDE Review
Hi, On Tuesday, December 04, 2012 14:17:33 Jörg Ehrichs wrote: This sounds a bit like you're ignoring most of the feedback you got. No didn't ignore any reviews. I've changed/implemented each and every suggestion/review I've got. Sorry, I think I came over a bit disrespectful for your work, it wasn't meant that way. Don't wory I didn't took this personally :) The additional systemsettings module to me is actually one of the biggest problems, because it adds clutter to an interface that is very widely used, it affects other applications and overall complexity of our system. This could be alleviated by grouping the webminder KCM under Desktop Search, I'd suggest to do that until those two are integrated. I don't like the current solution either, but currently I could only remove it from the settings or have it in its own category. The Desktop Search is not implemented as category section like the input devices but shows the kcm_nepomuk only. In order to allow this settings module to show up together with nepomuk this should be changed first. That why I like to wait till the 4.11 change. One more thing I ran into when installing it (already three weeks ago) is that it uses a lot of dependencies, many of them python libraries to interact with specific webservices. [...] A warning would be handy. I had to hunt down the missing modules from runtime errors, which is probably the worst way to go about it. [...] Ah, I missed that. :) The CMake warning could point to the README, maybe? I've added a cleaner INSTALL file and a proper warning t othe cmake. Beside that, the system settings module tells you why the plugin fail. But hopefully this will is not necessary for most end-users late ron. Could it be ported away from PyKDE? I've not looked at the code, but if the dependency is not that heavy, maybe it could be changed? The PyKDE/PyQt stuff wasn't added by me. This is on the other hand currently the only solution to allow plugins to have their own configuartion. For all the dependency problems in case this hopefully get into SC. Should the integration with nepomuk get a bit deeper i could still put the plugin parts somewhere else, where the dependencies are not the problem anymore (whereever this might be) In the worst case have the plugins, execpt a few basic ones (so all with PyKde dependency) in extragear and by default this can only fetch basic data while the user has still the chance to add better plugins or write his own as the structure that supports it is always on board. This might be the best solution after all. So if I get your ok for the current status I'll tell the admins to move this to extragear first. Regards, Jörg
Re: Nepomuk Metadata Extractor moved to KDE Review
This sounds a bit like you're ignoring most of the feedback you got. No didn't ignore any reviews. I've changed/implemented each and every suggestion/review I've got. Except the few opened points you mentioned that are necessary to get it into 4.11 As these points mean, I'll have to change /add stuff to nepomuk to make the integration better, this isn't something, that's possible at the moment. That's why I like to postpone these few changes, get this in extragear and fix all the last mentioned integration issues for 4.11. One more thing I ran into when installing it (already three weeks ago) is that it uses a lot of dependencies, many of them python libraries to interact with specific webservices. Many of them are not mentioned specifically by CMake, as their runtime dependencies, so it took me quite some time to figure out those dependencies. I wanted to add these stuff to CMake first (so you get notified that these packages are missing) But I found a few ml discussions saying, that runtime dependencies should not be added to cmake (via find_package). If you disagree, I could try to make add some FindCMake files for the python stuff. But i think this is not the best way to deal with it. Currently there is a README, explaining all the dependencies. I wanted to add some more help for packagers too (mainly rewrite whats in the readme but with more details) I also see this as a problem for a possible KDE SC integration. Without a lot of external dependencies, the project is fairly useless. That's true, without the python dependencies no data will be fetched and basically the program does nothing. But this wouldn't break anythink in this case too, and the normal nepomuk-fileindexer needs external libs too. So is it really a big deal to depend on these libraries for runtime/workspace or wherever this could go in 4.11? I'm also not sure we can sensibly depend on PyKDE in modules as central as kde-runtime or workspace. As the tvdb-mail plugin is the only one that needs it, this plugin could stay maybe in extragear in a repo for additional plugins or maybe I could add GHNS support later on and put it there. Do you see a way to a) reduce the number of dependencies or at least make it more obvious how to install nepomuk-webminer in a more obvious way? The build dependency for poppler and TagLib will be removed when I integrate this more into the fileinder (or better reuse the newly written fileinder which mostly duplicates my current approach anyway) For the python stuff I could combine requests/httplib2/urllib2 as far as i know, as they du basically the same. And of course add some PACKERS-INFO or INSTALL readme to make all the other runtime dependencies from the current README more prominent. Would this work for you? Regards, Jörg
Re: Nepomuk Metadata Extractor moved to KDE Review
Hi Sebastian, 2012/11/8 Sebastian Kügler se...@kde.org: * 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
Re: Nepomuk Metadata Extractor moved to KDE Review
Hi Vishesh, thanks for the input. 1. You have multiple extractors - One for resources which extract information from the file, and some web-extractors. Considering that Nepomuk now allows easy Qt based extractor plugins, how about we move your code over there? Your poppler based code would be quite useful. Same goes with the ODF. Yes, when I've started the project the new file extractors wasn't available. I do intent to switch to the new fileindexer way combined some the current filename analyzing (unless this can go into the fileindexer too) About moving the pdf/odf analyzer over. I thought you already copied the important parts to the new indexer? If they are still missing, I'll add them later on. 2. Project Name - If one moves the extractors away, the only part that is left is the web-extractors. Why not rename the project to Nepomuk-WebExtractor or something similar? I know a project by that name already exists, but that can be removed. It's a dead project. If we can ignore the naming issue with the old project, I really like to rename it to Nepomuk-WebExtractor as this fits the purpose of the system the most. 3. I would eventually like this to be a part of the KDE SC release. Web Extractors are something that I have wanted for a very very long time. I'm not sure if we can get this into 4.10, but I'd definitely like it to be a part of 4.11. I would like to be part of KDE SC, i assume its way to late for 4.10 due to feature freeze but 4.11 sounds nice too. I could go extragear for now and move it back to kde-runtime when master is unfrozen again? As to where it should be placed. I agree with Sebastian Kugler, kdelibs is not the place. We had initially planned on splitting kde-runtime/nepomuk into multiple repositories, but we're now waiting for KF5. Do you think this could go under kde-runtime (not in that repo) Just wonder if runtime is the really best place. Beside the fact that its a standalone program, it also can serve as a library which can be used by others. While this is mostly a like to have case the additional searching capabilities could be nice in Bangarang, Amarok, Okular and other programs working with media files. Would such a library component still fit into runtime? Or should is just ignore this fact for now, as it is unlikely that this will be integrated into other programs is the near future. 4. ResourceWatcher - [...] This way, you would avoid using the ResourceWatcher, and everything would be better integrated. But I'm not sure how we would go about this, so lets stick with the current architecture for now. This sounds like a nice idea. We can figure something out I do have a few ideas in this area, but not really the time to work on such large changes at the moment. 5. Auto generated SimpleResource Headers - You've included them in your repo. That was what we originally wanted. We didn't want to repeat the mess that happened with breaking kdepim cause of ontology changes. Got to know this was the intended way to go. Does anyone have a problem with having generated headers in the code? One could generate them on the fly, but that would be slow (Jorg says around 10 minutes?) and if something is changed in the ontologies, the classes would change drastically thereby affecting the code. I could push my latest changes which allows to easily use a cmake switch to generate updated ontology classes. This would combine both solutions, as long as it is fine to add such generated classes into the repo. Cheers, Joerg
Re: Nepomuk Metadata Extractor moved to KDE Review
Yes, when I've started the project the new file extractors wasn't available. I do intent to switch to the new fileindexer way combined some the current filename analyzing File name analyzing? This is used to get additional information from video files. Example videos Big.buck.bunny.mp4 (movie title big buck bunny) TvShow some.Show.s24e03 (Some Show Season 24 Episode 3) as those information are rarely saved as metadata in the file, it is necessary to extract them from the filename instead. I was hoping to find some library to do the odf parsing. Also, your poppler based analyzer tries to get the title from the first page. That seems pretty cool. As odf file are pure archive files with the metadata as xml document, it might be easy enough to do this parsing on our own. This is what I have done using KZip and some basic xml parsing. If you like i'll write a parser for 4.11 Just wonder if runtime is the really best place. Beside the fact that its a standalone program, it also can serve as a library which can be used by others. While this is mostly a like to have case the additional searching capabilities could be nice in Bangarang, Amarok, Okular and other programs working with media files. Would such a library component still fit into runtime? Or should is just ignore this fact for now, as it is unlikely that this will be integrated into other programs is the near future. I see your point. Now even I'm confused. It seems to come under the same category as nepomuk-core which contains libraries and runtime components, which the libraries require. Anyway, we won't have to figure this out for a couple of month at least. I'll postpone this decision than for a while and stick to extragear until we can decide properly on this issue again
Re: Nepomuk Metadata Extractor moved to KDE Review
i18n is something I never liked about KDE, it is a big magic box to me and i'm always glad if it works somehow. I guess you did not automagically learn how to code in C++, you read about it, asked people and then learnt. The same applies to i18n handling, it's just a big magic box because you never cared to learn Thats true. Its just that everytime I read through techbase and though I fully understood this issue I seem to have missed something. Well at the end to get these kind of errors kde review exist, over time I should have deald with all the usual problems and should be ok with it. Do we need to have a whole folder (sro) full of autogenerated files? I had this in a README todo I totally forgot about it. I did add this locally, but this means a simple cmake run now takes around ~20min on a quite powerfull machine. But you only need that on the first compile, no? Yes this would be a one time thing, although it needs an additional compile switch to deactivate this generation for the second run at the moment, as the cmake file to generate this is not away of any caching mechanism and I have currently no clue how to add it. I'm not sure if this is a really good solution. On the other hand, i don't have to deal with changes in the Shared Desktop Ontology and update these generated fiels always. What do you think? should I upload the change and live with the very long compilation problem? We don't keep moc files in the repo, keeping them would be faster compile times, but autogenerated files in a repo always seemed a bad idea to me. Thats true and if this class generation was as quick as the moc file generation I would never have asked to get around it At the end, most people will not compile this from source but rather use distro packages and thus this is a rather small problem I will push my changes tomorrow. You are also missing the export (if that class is suposed to be used externally, that i guess it is since you are installing it) Should I add getter/setter for each function? Yes Doesn't this make the dpointer stuff kinde pointless, as I need to add/change the functions everytime I add something (like I would do with the current way) And? Adding functions is fine SC and BC wise, read http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ on why d-pointers are important. I might have had a kinda wrong understanding about the d-pointer issue than. I'll change the struct into a full class with appropriate getter/setter and the d-pointer. Thanks for the hints and help. Cheers Joerg
Re: Nepomuk Metadata Extractor moved to KDE Review
Hi Sebastian, 2012/10/31 Sebastian Kügler se...@kde.org But I assume this is something the packagers have to split. That would be almost making sure that it will hit users. In general, never assume something's going to be fixed by packagers, they, too, need something that can just be slapped into a package, and which should behave well by default. :/ I've changed the way the background service works now. First: If the servcie is started the first time (which happens automatically when it is installed) It will disable itself and also alter the restart-on-reboot nepomuk config file. This means, if the user really wants to have automatic fetching, he needs to enable it in the config on its own and noone is forced to expose their private data/file on their disk if they do not want it (or if they are not aware of it) Second: The automatic fetcher can be limited to a specific resource type. This means, it can be enabled for video and/or music only while the private documents are not looked up. In this case the user must use the manual extarctor gui if he really wants soem documents to be looked up. In the default configuration, the document lookup is disabled. Third: It is now possible to search for the preferred plugin only. Beforehand, all availabe plugins would be used, this is not the default case anymore, but can be enabled again. This should hopefully be enough privacy settings and don't leave any user with a system that does not do what he expects. Cheers, Jörg
Re: Nepomuk Metadata Extractor moved to KDE Review
Hi Albert, thanks for your input. I have a few questions about them though. 2012/11/5 Albert Astals Cid aa...@kde.org How are you handling the i18n in the lib part? It seems like you'd need a KCatalogLoader in there. i18n is something I never liked about KDE, it is a big magic box to me and i'm always glad if it works somehow. is it enough to call K_CATALOG_LOADER(metadataextractor); to make this work? Or do I have to change anything else? Do we need to have a whole folder (sro) full of autogenerated files? I had this in a README todo I totally forgot about it. I did add this locally, but this means a simple cmake run now takes around ~20min on a quite powerfull machine. I'm not sure if this is a really good solution. On the other hand, i don't have to deal with changes in the Shared Desktop Ontology and update these generated fiels always. What do you think? should I upload the change and live with the very long compilation problem? metadataparameters.h is installed but does not have the export nor uses a d- pointer publicationspipe.h is installed and missing a d-pointer, same for nepomukpipe.h There are also some classes with no private date but no d-pointer either, if you need to expand I've added d-pointer for all classes, except metadataparameters.h. i'm not really sure how to transform this struct into a class with d-pointer. Should I add getter/setter for each function? Doesn't this make the dpointer stuff kinde pointless, as I need to add/change the functions everytime I add something (like I would do with the current way) Or is there a way to expose the dpointer itself in a getter, so i can get all variables behind it? Is there some other clever way to deal with it? The MetaDataParameter is merly a container that is used at different places, to hold all the information. Kind Regards, Joerg
Re: Nepomuk Metadata Extractor moved to KDE Review
Hi, Just a small question regarding the name - what do you think about renaming it to Nepomuk Metadata Retriever / Fetcher / Miner ... I don't really care about the naming, so I'm fine to rename it. The application is called MetaData Extarctor because Web-Extractor is already taken. This is an old GSoC that never got out of playground for various reasons. So I took the next best option and added Nepomuk infront to indicate its a Nepomuk tool. Extractor might be correct, because it extracts data from the web ;) Well fwiw, the names you suggested seems the same to me (to get data from Nepomuk) :) Maybe File Metadata Extractor / Retriever / Miner...? Or append for Nepomuk? File Metadata Miner does sound ok. So in case the current naming might be a problem, I'll change it into this. Any votes on this isue?
Re: Nepomuk Metadata Extractor moved to KDE Review
Hi, First: If the servcie is started the first time (which happens automatically when it is installed) It will disable itself and also alter the restart-on-reboot nepomuk config file. Not sure I get it, what's the use of this? You assume user installs it - is fine with requesting metadata for files from online sources, I think. I'm not sure what changes between the first and the second run, however. The reason this is in is the following setup: * User installs it / or it might be installed by default on a distro * User thinks he can just use it to search for metadata on its own (Dolphin ServiceMenu integration) * While in the background the Nepomuk2:Service queries all documents/videos/music files automatically As there is no notice about this happening and Nepomuk starts all service automatically. The mentioned change above disables the service (and adds the necessary config entry so it will not be started on next restart of kde) This will now prevent a user from accidental exposing data to the internet unless he explicitly starts the service on his own. This means, if the user really wants to have automatic fetching, he needs to enable it in the config on its own and no one is forced to expose their private data/file on their disk if they do not want it (or if they are not aware of it) Maybe after first installation, it makes sense to actually ask the user. I'm usually not a huge fan for this, but in the case of possible inadvertend privacy breach, it's warranted to be proactive here. I could imagine: At first run popup comes up, You've installed online metadata extraction. It will collect additional metadata from the web (such as ... and ...), but it can reveal files on your disk to third parties. Only enable this for file types that do not affect your privacy. If in doubt, disable it. (Links to config, metadata extraction should probably have a separate page in the Nepomuk KCM.) I don't like pop-up dialogs to inform the user that something that might be harmful was started, So as mentioned above, a disabled by default service seems to be the way better solution here. In the default configuration, the document lookup is disabled. Makes sense, lookup for music and video is enabled by default, I suppose? yes music/video is enabled by default, once the service is started by the user. Third: It is now possible to search for the preferred plugin only. Beforehand, all availabe plugins would be used, this is not the default case anymore, but can be enabled again. What's the preferred plugin? Is that a plugin for a specific service, a specific resource type, or ...? The preferred plugin is a user selected plugin for each resource type (music, movies, tvshows, documents). Each plugin (written in python/javascript/ruby) represents one website, where data can be searched/extracted from. Currently the defaults for this: Documents: Microsoft Search Academics Music: Musicbrainz TvShows: thetvdb Movies imdb This should hopefully be enough privacy settings and don't leave any user with a system that does not do what he expects. Is there any UI for this? Yes there are ui parts for all the above mentioned settings in the KCM. I'll blog about the latest changes in the next days. I think this is a very cool feature, and has the possibility to make Nepomuk really shine. Your work on it is much appreciated! Thanks I really hope this stuff will make it a lot easier to fill the Nepomuk DB with more information so all programs can make proper use of it (Bangarang already does this quite nicely) Cheers, Jörg
Re: Nepomuk Metadata Extractor moved to KDE Review
Hi, 2012/10/31 Burkhard Lück lu...@hube-lueck.de: You extract all messages to one catalog called metadataextractor. But the control module loads a catalog called kcm_metadataextractor and thus is untranslated. This patch solves this issue: [...] Thanks I've changed this. Jörg
Re: Nepomuk Metadata Extractor moved to KDE Review
2012/10/31 Sebastian Kügler se...@kde.org: This doesn't look like it's kdelibs material anyway, so it's not affected by the kdelibs freeze. The only reason to put in into kde-libs is the fact, that all other Nepomuk stuff is in there too. I'm not sure where to put it consequentially, though, it does sound like something useful to have in a base system at first glance, as it would really be a good way to show how Nepomuk is useful beyond what the filesystem already offers. That's my problem, I have no idea where it really could belong. So I'll settle for extragear/base for now as I think that's the best solution for now. While most parts can be safely installed by any user, the Nepomuk2:Service should only be installed/activated, if the user is aware of its function. As it tends to query web resources a lot (especially when nepomuk indexes files the first time). This is not something someone wants on a low bandwidth/Mobile/Limited internet connection But I assume this is something the packagers have to split. Cheers, Jörg
Re: Nepomuk Metadata Extractor moved to KDE Review
Hi, 2012/10/31 Sebastian Kügler se...@kde.org: While most parts can be safely installed by any user, the Nepomuk2:Service should only be installed/activated, if the user is aware of its function. How are you going to make sure the user is aware of its function? Currently only in the KCM configuration dialog. This lets the user enable/disable it. But it is enabled by default. If it doesn't behave as the user would expect it to (i.e. first, not render the system unusable for a long time, query third party sourcees), it needs fixing. The key is not that it does something, the key is that it should provide value to the user, not break his or her system, or endanger privacy. Can't you come up with a gentle solution? It should: - not bog down the system - make sure the user understands which online resources are queried Those might need some UI work, but I think it could turn the metadataextractor into something rather useful *and* user-friendly. I'm not really sure what the user would expect when he installs the program. This program is delivered under the premission to find metadata on the internet automatically for all files. So basically the user is aware what this means. For the Dolphin integration this means the user has to activate it for each file/folder on his own, so this should be fine. I'm just not sure if the automatic background service is what a user really expects. There is currently a KCM installed along with it, that lets the user decide which web-resources will be queried. Also the KCM allows to enable/disable the background service that will automatically fetch additional information for each music/video/document once the Nepomuk fileindexer is aware of it. The current implementation allows to set the amount of processes that are used to fetch this data at the same time. The default is 1 process, but even ~6 are no problem and do not stress the system to much. I have tested is with my hd full of tvshows and even thoug hit takes a long time, the fetching progress wasn't noticeable while using the computer normally. So unlike Nepomuks old file-/mailindexer that could stress the system, this is rather harmless. I couldn't spot any differences apart from the fact that there was a constant low network traffic in the background. What might be the problem is that the user might not be aware that this will query some webresources in the background by default, which like i mentioned is not really a good idea for traffic limited connections (not that a lot of traffic is produces, but sometimes each kb counts) So the UI part is available. I guess the best solution would be to disable the background service by default and let the user enable it if he really wants to use it. This could either be done be by the packagers, as during installation the nepomukserverrc file needs to be changed. Or I'll do a first run check in the service part and disable it, again the first time the service is started. But I assume this is something the packagers have to split. That would be almost making sure that it will hit users. In general, never assume something's going to be fixed by packagers, they, too, need something that can just be slapped into a package, and which should behave well by default. :/ I have sadly no idea how to make it easier for packagers, in the end having separate packages that allows to deinstall the service if it is really not needed is the very best solution. In general even if everything is in one package, the user won't see any performance loss. What on the other end might be a problem is the privacy issue i haven't thought about yet. As I do ask (microsoft bing) for any found document, if there is more information available, this could be problematic. I will change the service so so the lookup for a specific resource type (namely documents) can be switched of separately. and beside the first run disabling of the serivce also disable the document search as initial settings. Its better to let the user enable it on its own decision that passing all information right away to some Internet search engine. Jörg
Nepomuk Metadata Extractor moved to KDE Review
Hi all, today I've moved my metadata extractor into KDE Review [1]. As kde-libs is frozen till kf5 I like to get this into extragear/base (unless anyone has a better idea where to put this). For those who are unaware what this little program does: This programs is an extension to Nepomuk and is able to find additional metadata for videos/music and documents on the Internet. Based on filename / previous metadata extraction / mimetype one of the existing python plugin based (thanks to KROSS) fetcher are called, to get more information for a file. This can be, title, season, episode, writer, author, cast, cited references and so on. All this data is saved into Nepomuk and can be used with Dolphin / Bangarang to get more information from your files. The program is integrated into the dolpin service menu, can be called as command-line program, runs as a Nepomuk2::Service in the background (can be switched off) and has also adapters to be able to integrate into Konqueror and Chromium. More information on it can be found on my blog [2]. Some more technical description is available via doxygen. Please review the current codebase to help this getting as stable as possible. Thanks in advance, Joerg [1] https://projects.kde.org/projects/kdereview/nepomuk-metadata-extractor [2] http://joerg-weblog.blogspot.de/search/label/Metadata%20Extractor
Re: Move the wacom tablet kcm out of kdereview
Am Samstag 26 März 2011, um 17:44:41 schrieb Albert Astals Cid: scripty never moves stuff, i just did move it though. Thanks for helping me out on this. Joerg
Move the wacom tablet kcm out of kdereview
Hi everyone, I would like to move my wacomtablet prohram out of kdereview finally. Its there way to long now, as I've silently misused the kdereview section for my slow development and this wasn't my intention after all. As I have to change a few parts to adopt to the latest xf86-wacom-driver updates to fix the last remaining bugs and I believe I have to do this more often (It looks like the guys responsible for the driver changing a lot to the better lately). I would like to move somewhere in extragear. Now for the questions, is extragear the right place? or should i go back to playground? And while I'm about to move the program anyway, is there someone who can help me to move to git too? Kind regards Joerg Ehrichs
