Version: (using KDE 4.2.85)
Installed from: Ubuntu Packages
Dolphin lost the ability to display information about the dimensions of a picture. It's neither shown in the information sidebar nor in the tooltip anymore in KDE 4.3 Beta1. Should be visible in both.
Thanks for the bug report.
Note that this was reported for the tool tip (but not for the Information Panel) already in bug 184335.
@Janet: Is your image folder indexed by Strigi/Nepomuk?
I activated nepomuk but don't want to use strigi. You don't want to tell me that showing the picture dimensions is bound to strigi?
Strigi indexing must be activated to get all meta data informations in a generic way. There have been a lot of technical issues with the approach done until KDE 4.2 (mainly: blocking Dolphin) and we don't plan to add image specific meta data reading into Dolphin itself like it is done in applications like Gwenview or Digikam.
With enabled strigi the performance on my notebook is completely going down the drain, no way using it. Unpleasing (or better: what a mess!), because I feel completely "blind" not being able to see the picture dimensions in the file manager, at least either in the tooltip, the information panel or the file properties. So this concerns all KDE filemanagers, even krusader which uses the same file properties dialog. Wow, you really leave me with a real pain in the stomach, but thanks for the explanation. So this is not a bug but a wish for a strigi-less picture dimension information inside the filemanagers, preferably in the tooltips of dolphin. Will you close it as wontfix?
No, I won't close this as wontfix because from a users point of view I fully agree to your opinion: It should not be necessary to have strigi just for getting the dimensions of an image.
Without going too much into technical details: The Nepomuk/Strigi approach is only used in Dolphin's information panel. The tooltips and the properties dialog are not affected and behave 1:1 like in KDE 4.2 -> other file managers behave like they did in KDE 4.2. However this also means we still have the "blocking issue" here under certain circumstances.
I'm not happy with this, but I cannot really do something against this without investigating a lot of time into code outside the scope of Dolphin. But if too many user will complain, I'll have to do something against this... The issue is that this affects not only the image size, also other meta information is affected.
I've changed the status to NEW and will leave it as bug report, not as wish.
I'd also love to see the information about the width and height of a picture in the tooltips and the information panel of dolphin again without having to activate strigi. Strigi slows down the system a lot and awfully clutters up the harddisk and I don't need all other functions of a desktop search (despite the IMHO really not desktop search related information about picture sizes). The width and height of a picture is the most important information about a picture IMHO beside the preview so it's a "must" to have it available. Maybe there is another way to get this information in dolphin without strigi? Wouldn't it be possible to read it from an alternative exif application that doesn't collect information like strigi but just reads it from the picture when you access the picture?
I activated strigi for testing but I still don't get the picture dimenstions anywhere, neither in the tooltip nor sidebar.
Did you activate Nepomuk too? After the initial activation it takes some time until the folders are indexed (this can take some hours depending on the size of your data).
Nepomuk is activated, strigi is running, no picture dimensions at all.
I have now managed to get the desired information for some rare files in some rare directories. Strigi/Nepomuk is running since 07.2009 on a daily base and often the machine is on overnight but it still doesn't seem to have indexed more than a minor percentage of my files though I by now have an index of over 4 GB. I cannot believe this is really necessary just for getting some picture information in dolphin. Please detach this information in dolphin from strigi and make it available on-the-fly on file access again.
Bug 212915 seems to be a duplicate? Maybe you can change the title of this report to something like the 212915 title?
Hi Peter Penz, I sent you an email on July 5, 2009 5:36:11 PM because I wanted to vote on the ToolTip complete Meta Data information. It might be there for 4.4 9I do not see part of the feature list!!), but plz confirm this, cuz having it in the tooltip is a possible, but incomplete, workaround for the information panel problem. (unless it's there already but does not work for me and I need to check on my libs)
Whether it will or not be there for 4.4, plz bring back the meta data in the information panel. This is part of the Top 10 most useful feature in Dolphin and everyone uses it one day or another, some (like me) every single day. It is actually for me a turn off to move from KDE3.5 to KDE4.3! And openSUSE 11.2 will be released in mid-November with 4.3.1 (or 4.3.2).
I use meta data for txt, pictures, audio and video files. VERY important for me as well. And as a full 100% linux KDE user, I vote on behalf of millions of other users. :) So you got all your votes, now. :)
Thank you for your comprehension, though I understand technical difficulties behind this (I work in IT). If there are such difficulties now and with previous versions like in KDE3 there were no problems, it's because some other developments/features are clashing with this one and it gets harder and harder to have all the developments/features in without affecting something else (performance, blocking, etc.). Hopefully you or someone will find a good compromise... and quickly (the hardest requirement to meet).
In my attempt to at least make this work with all possible indexing, I activated Nepomuk and Strigi, added libexiv2 and all exif packages I could find, plus added the sesame2 package and in both Kubuntu 9.10 (debian) KDE4.3.2 and openSUSE RC1 (red hat) KDE4.3.2. I could never see any of the meta data on any type of file. Nepo and Strigi say they are activated, without errors.
So how to you get your long list like on your blog?
@Francis: Is the Nepomuk Indexer visible in your Plasma panel at the bottom right of your screen? If this is the case: Could you please click on the Nepomuk Indexer and tell me the used Nepomuk store size (it is visible at the bottom of the dialot). Thanks!
Hi Peter, tnx for the follow-up!
After a while the strigi now fails to initialize. On both distros. I have created a new virtual machine for Kubuntu from scratch, but I cannot enable it anymore, this strigi is so complex and sensitive.
I remember the file was UNDER 100megs for sure. Maybe just a few megs. Does it need to be very big to contain all file indexes? It seems even at 4GB (Janet) it was not providing information.
I tried Konqueror but it does not have a function to give meta data. Since Tooltip does not display meta data info, we are stuck. I think from a user point of view tooltip would be a nice workaround until the information panel gets the info in a cleaner way, but that's only my opinion.
Strigi is now functional. I simply rebooted a few times and it decided to work.
I also did the following:
sudo ln -s /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server/libjvm.so /usr/lib64/libjvm.so
I tried creating a service menu in ~/.kde/share/kde4/services/ServiceMenus with the following:
[Desktop Action GetExif]
Exec=exiv2 %f > ~/tmp/exiftemp && kdialog --textbox ~/tmp/exiftemp 510 510
Name=Get Exif Information from Picture
That did not help.
I have almost 2700 files indexed for 85megs, I get a few RARE files for which I can choose the meta data info, but none with picture dimensions and the ones for which I want the info don't have it.
So even with the indexing it's not a good solution, as not all files will display the info and of course no files outside the indexed folders can potentially display the info.
Now back on that tooltip feature showing all meta data info, why not taking a look there?
@Francis: The problem is not related to whether the data should be shown in the tooltip or in the information panel. If the issue is solved for the information panel, it automatically is solved for tooltips too (see http://ppenz.blogspot.com/2009/11/information-panel-and-tooltips.html for further infos).
The main issue is that there is currently no fallback solution for the case where Strigi/Nepomuk is disabled. It can be solved technically, but the effort is quite high - for KDE 4.4 I don't have the time to implement such a fallback solution, because of other more important tasks and issues that must be fixed first :-(
Ok understood. I thought I read somewhere that the tooltip was not using strigi to get the exif info, I might have misread.
I see you updated the blog, that's good for follow-up.
So you target 4.5 to have that fixed for both tooltip and info panel?
That's most probably about summer 2010, right?
Then if you are confident to get over this for all files of all folders of all devices showing all meta data info, for summer 2010, I think we can live until then, knowing a solution is possible and would be targeted. I can accept the compromise, it would be much better than "maybe we'll fix it" or "no idea when and if"... I love so much that feature, it's so useful. :(
But we must then ensure it will be part of the 4.5 features list.
> But we must then ensure it will be part of the 4.5 features list.
I cannot promise to fix this for KDE 4.5 - in the longterm Nepomuk/Strigi will be a central part of KDE, so providing a fallback solution has no high priority on my task list. In KDE 4.4 Nepomuk will already be a lot faster and should also be less resource hungry, maybe this solution is sufficient for the majority of users.
And by using strigi, does this will inevitably mean that not all files will show the info right away? Or by enabling strigi any files inside the indexed structure will immediately display the info?
Because if displays the info for 1 to 10% of the files, that's not a solution. It will not mean the file you need the info for will display it, it would mean the info will be displayed if strigi decides to and the user will have no control over that.
Strigi only requires a lot of time for the initial indexing when you do a fresh installation, afterwards new files will be indexed within an unnoticeable short time (from a users point of view immediately).
Ok, I'll keep an eye with time. And if it will get faster and less resource hungry, then I agree it would be a good solution for most users.
I'll update to 4.4 in Feb.
If you ever get to fully fix this, plz update this bug so we get the notice.
I know it's already been said that it's not a priority, but I am still putting my votes in that this information should be present even without Nepomuk and Strigi. I currently don't need these two services, and if I enabled them, it'd be two services running and a bunch of hard drive space used just for some image dimensions being displayed on Dolphin. Not optimal behavior, in my opinion.
Ok after a while and when you let strigi the time to gather its info, it does seem to show exif to many files. You have to wait and maybe try a few times and it will show. Then when you reboot, you will lose all info, the files that were showing exif now don't show it anymore and you either have to wait again or you are out of luck and you will never see the exif anymore. Like I said, strigi seems to control whatever it wants to show, whenever it wants to show it.
It also does not show the same info as in KDE3, for instance the width and height on video files is not always shown, but in KDE3 it always was, no matter the codec.
So it's far from working, but there is no choice to wait and see if 4.4 will help with a better strigi or for another type of fix someday. Make strigi more powerful and reliable for this info and that could be sufficient.
"The main issue is that there is currently no fallback solution for the case
where Strigi/Nepomuk is disabled. It can be solved technically, but the effort
is quite high"
I totally refuse to believe this. Reading size information from images is ALREADY BEING DONE for the purpose of creating thumbnails in preview mode - how would you get the thumbnail size right otherwise? I don't believe there is anything difficult about just DISPLAYING this information!
I definitly do not want to go with Strigi/Nepomuk - these are the first things beeing diabled on my test maschines as I do not get any benefit from them.
I still want these extra information when the nepopmuk database is corrupted. Or when working from a readonly device (cdrom).
*** Bug 184335 has been marked as a duplicate of this bug. ***
> I totally refuse to believe this. Reading size information
> from images is ALREADY BEING DONE for the purpose of creating
> thumbnails in preview mode
Honestly speaking I don't want to start technical discussions in the bug tracker. If you think it is so straight forward we are open for suggestions at email@example.com.
I tried exiftool (install package libexiftool or something close) with a servicemenu file and it works. Except for txt files, but all images and videos, for example, get the full meta data info. It pops in a kdialog window and you have to right-click the file and select the service menu. But it shows an impressive list of additional info.
Are there technical reasons why Dolphin could not use that external library (exiftool) and pipe the information to the tooltip and info panel?
Create a file named whatever you want *.desktop, like "exif-servicemenu.desktop" in ~/.kde/share/kde4/services/ServiceMenus/ with this:
[Desktop Action GetExif]
Exec=exiftool %f > /tmp/exiftemp && kdialog --textbox /tmp/exiftemp 510 510
Name=Show Meta Data
Then right-click files and select your new menu.
SVN commit 1047680 by ppenz:
Images: Instead of showing the meta data for "Width:" and "Height:" separately with other items in between, they are merged as "Width x Height:" and added to the top of the sort order.
M +56 -2 kmetadatawidget.cpp
WebSVN link: http://websvn.kde.org/?view=rev&revision=1047680
Created attachment 38269 [details]
Information Panel with merged width/height properties
This seems like a terrible design decision, I'd just like to second Comment #26 From Dr. Nikolaus Klepp
*** Bug 194785 has been marked as a duplicate of this bug. ***
*** Bug 212915 has been marked as a duplicate of this bug. ***
*** Bug 193883 has been marked as a duplicate of this bug. ***
I have been using Nautilus for file browsing in KDE 4.3.4. It shows file context sensitive metadata beautifully. As a user, the Gnome model of incremental improvement while maintaining and adding to function I have found far superior to the KDE4 burn and crash model. The idea that KDE4 can capture Windows and Mac, relinquish control of development to QT and maintain the user functionality of KDE3.5 has clearly not worked. Good luck winning users back.
> I have been using Nautilus for file browsing in KDE 4.3.4.
Due to bug #55804 I have also replaced Dolphin with Nautilus. While I don't want to repeat the trolling of comment #36, I must state that Nautilus has the meta-data done right. In the Properties dialogue, there is an Image tab with metadata available, such as image type and size.
First of, Happy New Year.
Well, additional info (meta data) is much more than just picture dimensions, but the latter is very common and a good start to provide more infos in the future.
For my usage, details such as number of lines, number of characters, file type (DOS, UNIX, etc.), number of words, audio codec, video codec, video height-width, picture dimensions, these are all details I use every day. KDE 3.5 has all those right out of the box if proper packages are installed, no configuration required, no database used, super quick, etc, all that inside the tooltip (using Konqueror).
I wish KDE4 will someday provide the same, as it was part of KDE3 and that I thought KDE4 was supposed to keep all of KDE3's features and offer more. It's very rare when we improve or upgrade applications that we remove features. There is a lot of potential in KDE4, at least for my usage. I'm just hoping this bug will deserve a higher priority in 2010. (and that Dolphin will have a list of previous folders viewed when right-clicking on the back button, but that is another story lol :))
There is an action which shows these information with right click on the file. Can't this one be implemented inside Dolphin?
*** Bug 224826 has been marked as a duplicate of this bug. ***
I'm not sure if I would say something new, but quick looking though the thread did show same suggestion.
So, I think having nepomuk+strigi is a very good option to get any file metadata from one place in every app, but I don't understand why having the file in the index is a must to get any info from it. I have been playing with strigi for some time ago, and as I know, it allows to get any info from any file (for sure the file type from the supported list) very quickly, and the indexing staff is something that lives above strigi - it just takes info strigi provides and puts it so some index. For example, I could run strigi from command line for some particular file in the input, and it printed all the info it could get from it directly to console without any indexing.
So, I see at least 2 good options for dolphin to implement this feature without breaking the whole strigi+nepomuk beatiful concept:
1. If nepomuk API does not provide any info for the particular file, just call strigi directly for that file, so it would give exactly the same info that nepomuk could give (except ratings, tags and other non-strigi staff) - this would be the same info nepomuk uses for his indexes.
2. Extend nepomuk API (actually even API itself won't change - only internal impelmentation), so it would do exactly same thing, but would hide from other apps under same calls - even better - no need to change dolphin and all other apps working with nepomuk - this would start working transparently - if the file is not in the index, just call strigi for it and return available info.
Anton, your proposal is insufficient because "strigi+nepomuk beautiful concept" is your personal opinion that many people don't share. There are people who won't tolerate no freakin' indexing security-compromise-ware on their system. Ability to access and display metadata must NOT be dependent on Niepomóg *) engine even being installed.
*) "Niepomóg" is a nickname given to Nepomuk by Polish users who dislike it. The nickname can be translated as "no-help".
Szczepan, you probably did not understand my suggestion entirely, because "Ability to access and display metadata must NOT be dependent on" "indexing security-compromise-ware" is exactly what I suggested, only except "engine even being installed" part.
Strigi is not only about indexing, at the 1st place strigi is about taking data from files.
I would mark 3 layers in the problem
1. Strigi file analyser engine. It could be thought of like Solid for hardware or Phonon for multimedia. Take file as input and give all available info at the output. Different file types are supported with special file analyser plugings. For example, info from PNG images is retrieved with png-anyliser-plugin, which knows everything about PNG format, info from JPG images (resolution, EXIF data etc) is retrieved with jpg-analyser-plugin, which knows everything about JPG format. If at some moment you would like to add support for another image format (let it be TIFF for example), you just write another tiff-anyliser-plugin and add it to strigi - info about TIFF files would appear in all programs who use Strigi (Dolphin in our case) at once and for free. And please note, that no indexing at this moment - the file analyser plugins just live in your system as usual .so library files and are not loaded to any kind of service or daemon. I hope you will not argue, that until now this concept is "nice and beautiful".
2. Here it comes indexing. Strigi indexing service (or nepomuk indexing service - not sure exactly who of them handles this staff) goest though the whole filesystem, takes each file, retrieves all its data with the help of Strigi file analysers described above and puts it to database index, so it can then be quickly searched. That indexed data is made public to client programs with the correspoinding API. This point is what some people do no like - index takes place on the hard disk and indexing daemon takes memory and CPU while it is running all the time.
3. Client programs (Dolphin in our case) takes the file and asks Strigi indexing API if has some info about it in the index database. If the file is already indexed by indexing daemon, the info would be available, if not - dolphin would not show any useful info about it.
Now Stop here. Dolphin (point 3) could work in a different way - it could take file data not from index database (point 2), but directly from Strigi file analysers framework (point 1).
So everybody are happy here - Dolphin developers do not have to care about supporting all the file formats (with libpng, libjpg, libtiff, libodf etc) and duplicate the same code across the programs - all this info is available from strigi analyser API and plugins. Those people, who do not want to have any indexing staff on their system (and actually even those who use it) are happy too - this would all work even without indexing service enabled.
And also wanted to provide some usecases, which show that relying _only_ on indexed file data is not sufficient even for those people, who have indexing enabled in their system.
1. By default, indexing is enabled only for user home directory. So, in my home directory I would see dimencion/EXIF info for pictures; but if I go to for example "/usr/share/pixmaps" which is not indexed, I will not see all those info for pixmaps.
2. By default, indexing is disabled for removable media, but even if it were enabled, this would not make much sense. I want to put SD-card with 5000+ photos from my photocamera (or from the photocamera of my friend), quickly scroll file list to the middle and check properties of image number 2587 - size/resolution/EXIF info should already be there instantly - even if I have option to index removable media in strigi, I do not want to wait while this new SD card would be analysed. The info should be taken directly from the file on user request - all other options are just not good here.
3. There are virtual dynamic file systems (like fuse-based), which should never be indexed by strigi, though strigi file anyliser plugins would still be able to take data from files on those systems. It is natural, if Dolphin would show all info for any file in any filesystem if it is indexed or not.
If Dolphin used strigi file anylisers API, all those usecases would be solved, relying only on indexing API brings many problems which are nearly impossible to solve.
@all: I've increased the priority for this bug report and will try to find a solution also for systems without activated Nepomuk + Strigi indexing. I've adapted the code for KDE SC 4.4.0 already to have a base for this, but still it needs a lot of work. One problem is that a lot of code that is needed to solve this issue is maintained completely outside of Dolphin and it needs time to get patches in...
I'd also kindly ask to stop technical discussions regarding Nepomuk, Strigi indexing + Strigi as part of this bug report, if you're not really familiar with the code and the runtime behaviour. There are some metadata related things that worked very well in KDE 3.5, which don't work anymore in KDE 4.x and believe me: I'm not happy about this myself. The code for this is located outside Dolphin and I had to struggle with issues like "Dolphin blocks for 5 seconds when hovering about file x" for a long time (and still have to: e. g. when opening the properties dialog, which is kdelibs code and blocks the UI in a lot of situations).
Well, I'll concentrate to fix this things in kdelibs as far as possible during the KDE SC 4.5 cycle and hope that this bug can be closed then :-)
Peter Penz, please answer a simple question: How ***DO*** you generate thumbnails for the thumbnail view in Dolphin without *already having the code in there* that reads the image dimensions? How ***DO*** you know how much memory to allocate for the thumbnail bitmap?
The conjecture that Dolphin actually connects to a Trans-Turingian Image Dimensions Oracle is easily disproven by the fact that thumbnail generation works even without the internet connection. ;)
The routine *is there somewhere*.
Just *call it*, and display the information it returns.
@Szczepan: Dolphin does not create any thumbnails itself. The thumbnails are created by a very generic thumbnail system in kdelibs. What Dolphin gets is only the finished, small thumbnail - which is the purpose of the thumbnail system. The thumbnail system does not - and should not - expose any information about the original data. This is the task of KFileMetaInfo, Nepomuk, Strigi... It is a lot more complex than you think. Just "call the routine" as you say is not possible, as:
a) This may not done in the context of the Dolphin process, as it would block Dolphin.
b) "the routine" is a loadable plugin which has been written for the thumbnail API
So just trust me that I'll do my best to fix this for KDE SC 4.5 and believe me that if it would be so easy as you say, that I'd have implemented it already for KDE 4.0.
*** Bug 226603 has been marked as a duplicate of this bug. ***
> if it would be so easy as you say, that I'd have implemented
> it already for KDE 4.0."
OK, it is now 19:02 local time. Plan for for the night:
* determine what image format libraries Dolphin already has a dependency on
* write a command line tool to extract image dimension information from each of these formats
I am starting right now and if I am not done by 7:02 tomorrow then I will admit that the task is indeed anywhat difficult.
Use "identify" from ImageMagick, it already has what's needed most.
I think that dolphin team have already stated their intention to fix this issue for 4.5 - this is the best possible result this bug report could achieve, so I do not see the point trying to continue discussion is such manner. I think you should also understand, that writting a console program which takes picture dimesions from 10 image formats (which can probaly can be done in 10 minutes after reading imagemagic option list) is not the same as itegrating same thing into program of same complexity level as dolphin. The point here is not only about physical ability of reading picture data from particular file, but also about keeping code base in a clean state (picture data reading code should not be copy/pasted across each application which needs it, but should be located in single place somewhere in kdelibs) and also about perfomace staff like multithreading and ui-blocking which was already described few posts above (reading picture data from one file in single command in not the same as reading same data from 10000 files in single folder and not being hanged for visible time period). Sorry for further spam, I am stopping posting to this thread.
Thanks Anton for the good summary of the real issue here, I could not have said it better. I'd also like to note that I won't do any further comments to this thread anymore. Instead I'll try to do my best to fix this in a clean manner for KDE SC 4.5...
> I think that dolphin team have already stated their intention
> to fix this issue for 4.5 - this is the best possible result
> this bug report could achieve,
Which is still a very disappointing result given the age of the problem. 4.5 will arrive in half a year or worse.
> I think you should also understand, that writting a console
> program which takes picture dimesions from 10 image formats
> (which can probaly can be done in 10 minutes after reading
> imagemagic option list) is not the same as itegrating same
> thing into program of same complexity level as dolphin.
Sure. The latter should take 10 days.
> (picture data reading code should not be copy/pasted across
> each application which needs it, but should be located in single
> place somewhere in kdelibs)
Your priorities are wrong. Idealistic dreams about having your code in gazillionth normal form are *not* an excuse for *removing features* and having users wait before you actually bring your code into gazillionth normal form, which is a goal you will *never* achieve.
If there are problems with the old implementation, focus on fixing them first, and then tinker with your new super-elegant reorganization in a sandbox that does not affect users. What's that with Dolphin being blocked while generating thumbnails? Is a worker thread used? No? What's the original bug# for that defect? I'm genuinely interested in trying to fix the old implementation even if it would only be used temporarily.
> I'd also like to note that I won't do any further comments
> to this thread anymore. Instead I'll try to do my best to
> fix this in a clean manner for KDE SC 4.5...
Had you instead decided to fix this in a quick, dirty and temporary way for KDE SC 4.0.1, then all the energy you have wasted on defending your wrong choice in this thread could have been put to work on the final clean fix, which would then probably be ready by now.
Thank you for your efforts, your time and work - and your patience, Peter! Thumbs up!
A small suggestion: nepomuk should not be disableable: in any case, it does not consume significant amounts of resources. I believe the problem comes from the indexing of files, which triggers bad behaviour from linux, which hates high disk io (particularly annoying with slow ssd's).
My suggestion/wish would be to implement a strategy similar to the generation of thumbnails: index (always) these files seen in the current directory of dolphin in priority. And these in the viewport first. And these hovered/selected in priority. Nothing changes compared to the current state of affairs, except users get their metadata right away. And a small progress bar goes a long way to give the impression of speed.
And you can always add the files in the DB, if they are remote/on removeable media, the search interface only needs to indicate that -- and it would help me, as in "ah, I had these files in THAT USB key, on on THAT server".
That misses the point. I definitly do not want to use any indexing of my files - I think you can come up with a hand full of good no-goes for indexing yourself. If the decision is "KDE4 + indexing" or "no KDE4" then it'll be no KDE4.
Indexing IS reading meta-data and putting it in some suitable form for display, and caching it for efficiency. You can't have your cake and eat it too! You either want your files' meta-data read and displayed or not.
As a KDE4 user -- user, mind you, not developer -- I got angry when reading the comments on this bug report, and I greatly admire the maintainers for staying so calm and polite in the face of such abuse.
The issue is that meta-data should be displayed for files not yet indexed. A possible solution is to index files that are displayed in the viewport or selected, possibly discarding the info as you go, depending on the speed of the operation. A separate mechanism for meta-data extraction seems like code duplication.
As a user of nepomuk, I would greatly appreciate the results of the indexation to be added to the DB. This would allow me to direct the order of indexation, which is useful when you want to browse newly copied directories.
> Indexing IS reading meta-data and putting it in some
> suitable form for display,and caching it for efficiency.
> You can't have your cake and eat it too! You either want
> your files' meta-data read and displayed or not.
Your logic here is flawed. Yes, I _can_ have the metadata extracted and presented AND NOT cached. It is very simple: do the extracting and presentation, *DON'T* do the caching.
Problems with current approach:
* no possibility to tell Niepomóg/Zrzygi: "Hey, Niepomóg/Zrzygi, I am browsing *this particular folder* right now, and I want to see the dimensions of *this particular image RIGHT NOW*, not in three monts when you finally decide to index *this particular folder*, so I, your user and lord supreme, *ORDER YOU* to *INTERRUPT* whatever you are doing right now, and index *this particular file RIGHT NOW*, then other files in *this particular folder, NON-RECURSIVELY* (if I am interested in what is in the subfolders, I will tell you), and when you are done with this, you are free to resume the interrupted activity.
* indexes will get out of date. While it is acceptable to get a few false positives when doing a full-text search, it is *NOT* acceptable to be presented with *FALSE* information about e.g. image dimensions because the image changed since it was indexed.
* (this should really be the first item) Everything that makes searching easier is a *HUGE* privacy concern. Some people will want to *disable* all indexing engines and would rather deal with more time-consuming direct searching than risk their privacy. Therefore important functionality *MUST NOT* depend on indexing engines, and (to be pedantic) *MUST NOT* trigger the activation of the indexing functionality of indexing-and-other-stuff combo services like Niepomóg/Zrzygi.
SVN commit 1096472 by ppenz:
Show meta information also for files, which are not indexed (or in the case if Nepomuk is turned off).
Beside the new translations the fix is based on several other fixes in kdelibs + strigi and cannot be backported to KDE SC 4.4.x.
As soon as the meta data widget has been moved to kdelibs, this meta data information will also be available in the properties dialog.
M +3 -0 CMakeLists.txt
M +8 -25 panels/information/kloadmetadatathread.cpp
M +0 -7 panels/information/kloadmetadatathread_p.h
M +9 -9 panels/information/kmetadatawidget.cpp
A panels/information/nfotranslator.cpp [License: LGPL (v2)]
A panels/information/nfotranslator.h [License: LGPL (v2)]
WebSVN link: http://websvn.kde.org/?view=rev&revision=1096472
Peter, first tnx a lot for coming up with something.
Secondly, you say it cannot be backported to 4.4.x, so the next stable release we should expect all these fixes to be in is 4.5.0?
@Francis: Yes, the fix will be available with KDE SC 4.5
"Yes, the fix will be available with KDE SC 4.5"
... which means "in a year or more", which is a bloody shrieking foaming shame on you. You should have implemented a TEMPORARY QUICK FIX using e.g. imagemagick directly, and THEN start working on an oh-so-elegant fix.
KDE 4.2 was released on January 27th, 2009: Release KDE 4.2
KDE 4.3 was released on August 4th, 2009: Release KDE 4.3
KDE 4.4 was released on February 9th, 2010: Release KDE SC 4.4
Pretty much every 6 months, though I haven't seen a release schedule for 4.5 yet, I hope it may be somewhere around August 2010.
Now according to wikipedia, KDE SC 4.5 is scheduled for June 2010. I don't believe June, but certainly before 2011.
> ... which means "in a year or more", which is a bloody
> shrieking foaming shame on you.
@Szczepan: I think you need to work on your manners and how to communicate with people. I'd recommend that you have a look on http://www.kde.org/code-of-conduct.
Beside being impolite here, I think you are not aware how much you've proven your lack of understanding of technical details by your replies.
> I think you are not aware how much you've proven
> your lack of understanding of technical details by
> your replies.
And I think you are perfectly aware of how obvious it is how deliberately wrong you are.
Fix STILL not backported to 4.4.2.
Crying, mucus-squirting shame.
NOT fixed as of 4.5 RC3.
I open a directory containing an image, hower the mouse over the image, and the information panel DOES NOT show image dimensions.
If this is because strigi indexing is not enabled for this directory, then the REQUIREMENT of removing the dependency on strigi configuration IS NOT MET. The requirement is NOT to remove the dependency on strigi/nepomuk. It may stay there. The ABSOLUTE REQUIREMENT is just that the duty of setting up one's strigi configuration does NOT stand between user and the functionality. The image dimensions should be Just Shown(TM), without any additional steps required from the user to enable the functionality (other than possibly checking "Image dimensions" in the filetype properties Information tab; btw. there is currently NO "Image dimensions" checkbox in the filetype properties Information tab).
I request reopening.
I do not have strigi indexing enabled, but I can see the width and height of png/jpg images in dolphin (both in /home directory and in for example /usr/share and removable media).
OK I will start with fresh ~/.kde4 and if it works then I will report another bug about 4.4 config disabling a 4.5 feature.
Starting 4.4.95 with fresh ~/.kde4 did not help. Reverted to 4.4.5. I uphold my request to reopen this bug.
Well, it turns out that the problem is with some particular .jpg images. Filed bug 246854 for this because it's a different issue (a bug in the implementation rather than failure to implement).
Withdrawing reopen request.
*** Bug 207069 has been marked as a duplicate of this bug. ***
This problem is still here.
No tool tips in Dolphin4 nor in Konqueror on xubuntu 16.4
We can not upgrade to 16.4 :-/
Oh, my... It has been a year from my last post and whole seven years since bug report. It's a shame. Real shame!
*** Bug 237841 has been marked as a duplicate of this bug. ***