Version: (using KDE 4.0.3) Installed from: SuSE RPMs OS: Linux I was browsing thru random /tmp trash and found some images that make dolphin behave strangely. It seems when images are very wide and short (I had one that was 600x1), dolphin misbehaves in preview mode. Attached are screnshots from icon and details mode, and a sample image.
Created attachment 24265 [details] Example of image that causes buggy behavior
Created attachment 24266 [details] dolphin details mode screenshot
Created attachment 24267 [details] dolphin icon mode screenshot
Wow, this is a strange issue... I just verified it with the trunk version and there even an assertion gets triggered deep inside kdelibs. I'm sure it's just a very minor issue, but I'm surprised about the outcome :-)
This seems kinda fixed in icon mode (the thumbnail is a small square with a line inside instead of just a line), but in list mode now I get this crash (on recent kde4daily), with both dolphin and konqueror: Application: Dolphin (dolphin), signal SIGABRT [Thread debugging using libthread_db enabled] [New Thread 0xb5f49720 (LWP 4969)] [KCrash handler] #6 0xb7f11402 in __kernel_vsyscall () #7 0xb62e3085 in raise () from /lib/tls/i686/cmov/libc.so.6 #8 0xb62e4a01 in abort () from /lib/tls/i686/cmov/libc.so.6 #9 0xb7d5c895 in qt_message_output () from /home/kde4daily/install/qt-copy/lib/libQtCore.so.4 #10 0xb7d5c919 in qFatal () from /home/kde4daily/install/qt-copy/lib/libQtCore.so.4 #11 0xb7d5cd71 in qt_assert () from /home/kde4daily/install/qt-copy/lib/libQtCore.so.4 #12 0xb7666bff in KDirModel::setData (this=0x81f20e0, index=@0xbfcaebf4, value=@0xbfcaec14, role=1) at /home/kde4daily/src/kdelibs/kio/kio/kdirmodel.cpp:558 #13 0xb742afed in IconManager::replaceIcon (this=0x83c29a0, url=@0x83d0280, pixmap=@0x83d0288) at /home/kde4daily/src/kdebase/apps/dolphin/src/iconmanager.cpp:336 #14 0xb742b0ec in IconManager::dispatchPreviewQueue (this=0x83c29a0) at /home/kde4daily/src/kdebase/apps/dolphin/src/iconmanager.cpp:206 #15 0xb742bba4 in IconManager::qt_metacall (this=0x83c29a0, _c=QMetaObject::InvokeMetaMethod, _id=4, _a=0xbfcaed7c) at /home/kde4daily/build/kdebase/apps/dolphin/src/iconmanager.moc:79 #16 0xb7e70517 in QMetaObject::activate () from /home/kde4daily/install/qt-copy/lib/libQtCore.so.4 #17 0xb7e70999 in QMetaObject::activate () from /home/kde4daily/install/qt-copy/lib/libQtCore.so.4 #18 0xb7eb18dd in QTimer::timeout () from /home/kde4daily/install/qt-copy/lib/libQtCore.so.4 #19 0xb7e7ab18 in QTimer::timerEvent () from /home/kde4daily/install/qt-copy/lib/libQtCore.so.4 #20 0xb7e6e7ae in QObject::event () from /home/kde4daily/install/qt-copy/lib/libQtCore.so.4 #21 0xb69a181d in QApplicationPrivate::notify_helper () from /home/kde4daily/install/qt-copy/lib/libQtGui.so.4 #22 0xb69a1b03 in QApplication::notify () from /home/kde4daily/install/qt-copy/lib/libQtGui.so.4 #23 0xb797d7b7 in KApplication::notify (this=0xbfcaf51c, receiver=0x81fd640, event=0xbfcaf294) at /home/kde4daily/src/kdelibs/kdeui/kernel/kapplication.cpp:311 #24 0xb7e5b68a in QCoreApplication::notifyInternal () from /home/kde4daily/install/qt-copy/lib/libQtCore.so.4 #25 0xb7e5f1c9 in QCoreApplication::sendEvent () from /home/kde4daily/install/qt-copy/lib/libQtCore.so.4 #26 0xb7e8e0b5 in QTimerInfoList::activateTimers () from /home/kde4daily/install/qt-copy/lib/libQtCore.so.4 #27 0xb7e8b89c in timerSourceDispatch () from /home/kde4daily/install/qt-copy/lib/libQtCore.so.4 #28 0xb622fbf8 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #29 0xb6232e5e in ?? () from /usr/lib/libglib-2.0.so.0 #30 0x080c1e90 in ?? () #31 0x00000000 in ?? () #0 0xb7f11402 in __kernel_vsyscall ()
Just re-tried this with current trunk, and no crash, but there's a minor issue of the thumbnail in icon mode being just the square around the picture, instead of a rectangle with a line. Changing to minor, but if you think that the thumbnail is correct, feel free to close.
It seems fixed on current trunk. Dolphin doesn't crash and the preview icon is correctly dimensioned. There is another issue: the image "preview" is a small square, instead the image should be a thin line (the original image is a black line of this dimensions: 600x1 px).
Created attachment 29476 [details] Current trunk behaviour Here using: Qt: 4.4.3 KDE: 4.1.85 (KDE 4.1.85 (KDE 4.2 Beta2)) kdelibs svn rev. 899135 / kdebase svn rev. 899135 on ArchLinux x86_64 - Kernel 2.6.27.8 The preview in the icon mode is ok, but the preview in the Information panel isn't updated. (If you first hover into a normal image file, its preview is showed in the Information panel, if you then , hover the buggy file, the preview of the previous file remains(mixed with the buggy file info)). Or If you directly hover the buggy image, you can see the image of the folder in the Information panel (like this screenshot)
Created attachment 33207 [details] Current trunk behaviour In current trunk seems that it is almost fixed, but the thumbnail shown is very small, almost invisible, and doesn't change size when altering zoom levels.
I confirm what Ivo had wrote.
Hi, Please confirm that this issue is still present in that latest stable KDE version. Thanx, Mark
(In reply to comment #11) > Hi, > > Please confirm that this issue is still present in that latest stable KDE > version. > > Thanx, > Mark It's still present, but what happens changed again. In KDE 4.5.1, the thumbnail just isn't created, so if you put this image and then turn on preview mode, you still get the picture icon instead of a thumbnail. The same thing happens when you hover and look at the info panel, the picture doesn't show up.
Created attachment 51851 [details] KDE 4.5.1 behavior
What is the status of this bug? Does it still happen with a recent KDE version, such as 4.6.5 or 4.7.x? Please add a comment.
It is still reproducible with 4.7.2
Still a valid bug in 2020 with Plasma 5.18. At least I think it is the same bug: https://bugs.kde.org/show_bug.cgi?id=419566
Hi, kdelibs (version 4 and earlier) is no longer maintained since a few years. KDE Frameworks 5 or 6 might already have resolved this bug. If not, please re-open against the matching framework if feasible or against the application that shows the issue. We then can still dispatch it to the right Bugzilla product or component. Greetings Christoph Cullmann