Version: (using KDE 4.1.0) Installed from: Unlisted Binary Package The following columns are missing in Konqueror 4 as compared to 3: Mime type URL (admittedly this one is kind of useless) Link destination Access time Creation time I really want "link destination" back.
I really expect: owner, creation / access times, mimetype. Making it easy to add custom columns is the right way to go. Shell extensions?
Wow, cool! Thank you! I see many of the specific requested options in KDE 4.1.80 on windows (I'm still downloading the suse livecd) I Don't know what he meant by link destination. Title / artist / genera / other MP3 and media info. md5sum regular expression match (at work we routinely have to deal with sequenced files, and the sequences are often in wierd spots, being able to sort alphabetically on the matched string is something that could be very helpfull. Also, I know this is a seporate issue, but I can't move the columns by dragging to arrange them.
I'd like image-related columns like width, height, EXIF/ITPC created date, EXIF/ITPC/XMP/Comment description, bit-depth. Again this could all be done through a plug-in, as it seems to have been done in KDE3.
probably need to add another bug for these 2 related items: 1. The selection status should be it's own column, as should icon. (Icon, filename, and selection should not share a column!.. just getting the selection to it's own column would shut me up) 2. We need to be able to rearrange / drag the columns into different orders.. it appears the the most important columns are available though now
"Link Destination" will be back in 4.5, see bug 211690.
Should we change the summary to: More Meta-Data Display capababilities? Ideally, we should be able to have a column for anything ascertained from the file. Soprano NEPOMUK and Strigi could be of help.. How would we store and deal with changes of the meta data derived from reading the file?
I think we should be really careful about this, if such a feature is implemented. In particular, Konqueror should never invoke any of the code needed to draw extra metadata from files *unless* such metadata is needed in the current display. So, one could disable all of the extra metadata reading by just not showing those columns, and they should be off by default. Things like my 'link destination' request are safe(r) because they're read using simple, well-documented system calls, but I think any metadata reading beyond that should be implemented very carefully and be invoked on an as-needed basis. Why do we need this? Because adding all kinds of file-specific ways to draw metadata adds all kinds of extra places for bugs to show up, and bugs lead to security holes. There was one a while ago where a .jpg file could cause arbitrary code execution in Windows Explorer, even when the particular property that set off the bug wasn't part of the current view mode. So, just browsing to a directory containing such a JPEG launched code. We don't want to open up avenues for that to happen in Konqueror. (Yes, I'm aware that Konqueror already has lots of preview and thumbnailing capabilities that do "deep" file reading, but I thought this bore mentioning.) ~Felix. (In reply to comment #6) > Should we change the summary to: > > More Meta-Data Display capababilities? > > Ideally, we should be able to have a column for anything ascertained from the > file. > > Soprano NEPOMUK and Strigi could be of help.. > > How would we store and deal with changes of the meta data derived from reading > the file?