Bug 100801

On Friday 04 March 2005 12:15, Wilbert Berendsen wrote:
> It would be nice if the popup tooltip and/or properties dialog showed the original location (e.g. Original location: /home/website/my_stuff/)

I'm surprised by this report. For me the tooltip *does* show the Original location....

Created attachment 9967 [details]
screenshot

This screenshot shows my tooltip :-) this is kde 3.4.0 rc 1 from gentoo.

OK, found the problem: trash protocol had previews turned of by default :-)

Turning previews on also gives me the original location (including filename).

It would be nice, however, if the original location could also be shown when previews were turned off.

Created attachment 11392 [details]
Patch to enable trash meta info

Here's a patch to enable the trash protocol meta info display even if previews
are turned off.  It does so in the "Meta info" tab of the file properties, and
also in the tooltip if enabled.

As David Faure points out in bug 90380, the trash protocol is the only one at
present that provides protocol-specific meta info.  So checking against the
protocol name ought to work here, but maybe it should be a protocol property
that can be tested with KProtocolInfo?

On Friday 10 June 2005 13:29, Jonathan Marten wrote:
> Here's a patch to enable the trash protocol meta info display even if previews
> are turned off.  It does so in the "Meta info" tab of the file properties, and
> also in the tooltip if enabled.


I disagree with this approach, it goes against the user's preferences.
The KControl module (File Manager / Previews & metadata) says 
"Allow previews, ..., and retrieval of meta-data on protocols:" ...

If this is enabled by default for file:/, why not allow it by default for trash:/ ?
Something like this (untested)

--- kdebase/kcontrol/konq/previews.cpp        (revision 421677)
+++ kdebase/kcontrol/konq/previews.cpp        (working copy)
@@ -164,7 +164,7 @@

     for ( ; it.current() ; ++it ) {
         QString protocol( it.current()->text() );
-        if ( ( protocol == "file" ) && ( !group.hasKey ( protocol ) ) )
+        if ( ( protocol == "file" || protocol == "trash" ) && ( !group.hasKey ( protocol ) ) )
           // file should be enabled in case is not defined because if not so
           // than preview's lost when size is changed from default one
           it.current()->setOn( true );

Setting the default to on will achieve that, but the full implications of changing this kcontrol setting are not obvious.  I set the option for "trash" off myself when the protocol-specific preview options were implemented (a few KDE releases ago) - after all, there seemed to be little point displaying preview images in the wastebin.  Unfortunately, having done that, the useful information about trashed files is not available - and worse, there is no indication of why it is not or what setting needs to be changed to get it back.  Paradoxically, the trash metainfo *is* shown in the 2 last columns in "Detailed List View", even if previews are turned off!

IMHO the trash protocol metadata is not merely a user convenience such as an image preview - it is fundamental to their use of the trash system and so should be available even if they don't want previews.  As far as I can tell there isn't a significant overhead in producing this information - granted that the plugin gets loaded, but it doesn't read the file contents and KFileMetaInfo is called with the default "Fastest" option.

OK I see your point. However...

> IMHO the trash protocol metadata is not merely a user convenience such as an image preview 

I'm not comparing it to previews, but to other metadata, like the size of an image, the ID3 tags of an mp3, etc.
All this meta-information about files is what appears in tooltips and properties, and I see no reason why it
should be disabled by default for trash: if it's enabled for file:...

Your kmetaprops.cpp patch (2nd hunk) makes all metadata available for trashed files, not just the original location, right?
For images you get the image size, for plain text you get a count of words and lines, etc. right?
That's what I'm unhappy about: the patch simply forces the enabling what is disabled in kcontrol,
except for previews [which can already be turned on/off in konqueror's GUI].

The fact is that metadata *is* configurable in kcontrol, not just previews. That's the source
of our problem; your patch ignores that configuration, which others will certainly see as a bug.

What might be a better solution would be to somehow activate the protocol-specific
metainfo without activating the mimetype-based metainfo if it's not enabled in kcontrol,
but I'm not sure how to easily do that.

(about kfileitem: why not patch metaInfo() itself?)

> As far as I can tell there isn't a significant overhead in producing this information

For the trash plugin I agree; but enabling metadata (one way or another) means
all plugins are used, including the one that counts the words in plain text files etc.

> I'm not comparing it to previews, but to other metadata, like the size of an
> image, the ID3 tags of an mp3, etc.
> All this meta-information about files is what appears in tooltips and
> properties, and I see no reason why it
> should be disabled by default for trash: if it's enabled for file:... 

Good point on that, but... you say in bug 90380 that only one metainfo plugin will ever be used for any file, so here only the protocol-specific info (trash metadata) will be shown and never the file-specific info (mimetype metadata).  So enabling the previews+metadata option for trash doesn't do the same as other protocols anyway: it enables showing image previews in the iconview, but the trash metadata in the properties dialogue!  There seems to be no way to show the mimetype metadata for a file in trash, apart from "Info List View".

> Your kmetaprops.cpp patch (2nd hunk) makes all metadata available for
> trashed files, not just the original location, right?
> For images you get the image size, for plain text you get a count of words
> and lines, etc. right?
> That's what I'm unhappy about: the patch simply forces the enabling what is
> disabled in kcontrol,
> except for previews [which can already be turned on/off in konqueror's GUI].

No, it doesn't seem to enable the file metadata (see above).  Possibly unintended, but unless you are intending to do that big rewrite of KFileMetaInfo to display both sets of metainfo then the patched behaviour has the intended effect.

> For the trash plugin I agree; but enabling metadata (one way or another)
> means all plugins are used, including the one that counts the words in plain
> text files etc. 

Doesn't seem to do that here (with the patch): turn off previews for trash, right-click a text file, choose "Properties" -> nothing opens or accesses the file contents.  Same for tooltip and "Detailed List View".

bug #186376 is related to this

Still an issue in KDE Frameworks 5.45 and Dolphin 18.04; Dolphin tooltips don't show original path, even when previews are on.

The tooltip is shown by dolphin, and dolphin can already show the original path (e.g. by switching to the detailed view and adding the "Path" column to the view). It seems the tooltip is only shown if you dolphin with baloo support, as the tooltip uses Baloo::FileMetaDataWidget, so that's where the issue can be fixed.

For showing the physical location for items in the trash:/ see https://invent.kde.org/frameworks/kio/-/merge_requests/513

Extra fields, such as deletion time and original location, are now shown in the Information column and Tooltip provided through Baloo FileMeatadatWidget: https://invent.kde.org/libraries/baloo-widgets/-/merge_requests/11

Fixed by that!