Version: (using KDE Devel) Installed from: Compiled sources OS: Linux The file tooltips of trashed files do not always work. GIF images are displayed correctly when positioning the mouse over an image inside the trash, but text files are not. It seems that previews in file tooltips are only displayed if the file has an extension (.gif, .txt, ...). I have activated "Previews & Meta Data" for the trash protocol, but that does not seem to change the above behaviour. The normal meta infos in the tooltips for trashed files are no longer shown. All I can see is "Date of Deletion" and "Original Path", but the file-type specific ones are missing (like "Lines" for text files). Please add the real filename to the "Meta Info" tab in the trash properties dialog. I would like to know where my file really is stored.
CVS commit by faure: Fix mimetype detection for trashed files. CCMAIL: 90380@bugs.kde.org M +7 -4 kio_trash.cpp 1.34 --- kdebase/kioslave/trash/kio_trash.cpp #1.33:1.34 @@ -25,4 +25,6 @@ #include <klocale.h> #include <klargefile.h> +#include <kcmdlineargs.h> +#include <kmimetype.h> #include <kprocess.h> @@ -30,4 +32,6 @@ #include <qdatastream.h> #include <qtextstream.h> +#include <qfile.h> +#include <qeventloop.h> #include <time.h> @@ -37,8 +41,4 @@ #include <sys/stat.h> #include <stdlib.h> -#include <kcmdlineargs.h> -#include <qfile.h> -#include <kmimetype.h> -#include <qeventloop.h> static const KCmdLineOptions options[] = @@ -399,4 +399,7 @@ bool TrashProtocol::createUDSEntry( cons if ( !url.isEmpty() ) addAtom( entry, KIO::UDS_URL, 0, url ); + + KMimeType::Ptr mt = KMimeType::findByPath( physicalPath, buff.st_mode ); + addAtom( entry, KIO::UDS_MIME_TYPE, 0, mt->name() ); addAtom( entry, KIO::UDS_ACCESS, access ); addAtom( entry, KIO::UDS_SIZE, buff.st_size );
On Tuesday 28 September 2004 11:00, Thomas McGuire wrote: > The file tooltips of trashed files do not always work. > It seems that previews in file tooltips are only displayed if the file has an extension (.gif, .txt, ...). Mimetype information was missing in kio_trash - fixed. > The normal meta infos in the tooltips for trashed files are no longer shown. > All I can see is "Date of Deletion" and "Original Path", but the file-type specific ones are missing (like "Lines" for text files). Hmm, that's tricky. I implemented the support for showing that information as a KFileMetaInfo, i.e. a preview plugin. Only one plugin is used for a given file, so you get "trash info" and no "text file info". I'm not closing the bug then - there is a potentially valid request here: changing KFileMetaInfo to display *both* the trash-protocol metainfo and the normal mimetype-related metainfo. A bit more work than I had planned today on this issue :) > Please add the real filename to the "Meta Info" tab in the trash properties dialog. I would like to know where my file really is stored. This is really internal information, I'm completely against showing it. If people start messing with the trash's internal, bugs will appear: you shouldn't remove $trashdir/files/foo.txt without removing $trashdir/info/foo.txt.trashinfo as well... In any case the way the trash is organized can be read in the new freedesktop standard that this implementation implements: http://www.ramendik.ru/docs/trashspec.html
On Tuesday 05 October 2004 09:00, David Faure wrote: > ------- Additional Comments From faure kde org 2004-10-05 11:00 > ------- > > On Tuesday 28 September 2004 11:00, Thomas McGuire wrote: > > The file tooltips of trashed files do not always work. > > It seems that previews in file tooltips are only displayed if the > > file has an extension (.gif, .txt, ...). > > Mimetype information was missing in kio_trash - fixed. Thanks. > > The normal meta infos in the tooltips for trashed files are no longer > > shown. All I can see is "Date of Deletion" and "Original Path", but > > the file-type specific ones are missing (like "Lines" for text > > files). > > Hmm, that's tricky. I implemented the support for showing that > information as a KFileMetaInfo, i.e. a preview plugin. Only one plugin > is used for a given file, so you get "trash info" and no "text file > info". > > I'm not closing the bug then - there is a potentially valid request > here: changing KFileMetaInfo to display *both* the trash-protocol > metainfo and the normal mimetype-related metainfo. A bit more work than > I had planned today on this issue :) If this is implemented anytime, it should of course work for all protocols which were selected in the "Preview & Meta Info" config dialog. But I understand this is complicated and would require deeper changes in the kio libary. Anyway, it is not really important. > > > Please add the real filename to the "Meta Info" tab in the trash > > properties dialog. I would like to know where my file really is > > stored. > > This is really internal information, I'm completely against showing it. > If people start messing with the trash's internal, bugs will appear: > you shouldn't remove $trashdir/files/foo.txt without removing > $trashdir/info/foo.txt.trashinfo as well... OK, you are right. I hadn't thought of that. > In any case the way the trash is organized can be read in the new > freedesktop standard that this implementation implements: > http://www.ramendik.ru/docs/trashspec.html
On Tuesday 05 October 2004 13:45, Thomas McGuire wrote: > If this is implemented anytime, it should of course work for all protocols > which were selected in the "Preview & Meta Info" config dialog. But I > understand this is complicated and would require deeper changes in the > kio libary. Anyway, it is not really important. Well, "trash:" is the only protocol that specifies protocol-specific meta info at the moment. I added support for it in the kio library for this very purpose. So this is about changing that kio code, indeed, but it won't affect anything else.
Is this still an issue with KDE Frameworks 5.45 or greater?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!