Version: (using Devel) Installed from: Compiled sources Bug reported by a mandriva user : Description of problem: Since today/yesterday when you select file size view in konqueror it is no longer possible to delete that file (there is an offer to open it with the correct app), copy, cut or move it . File size view is incredebly handy for finding wasted diskspace and cleaning up disks, not being able to delete files/directories is a major loss of function Version-Release number of selected component (if applicable): kde 4.2 RC1 How reproducible: 100% Steps to Reproduce: 1.install konq-plugins 2.start konqueror in a directory 3.select file size view 4.right click a file and notice not option to delete, move to trash, cut, move etc nor any other file manipulation
This feature was present in kde3.5 and very useful, please add it back again.
still no fix in 4.3 :(
*** Bug 202006 has been marked as a duplicate of this bug. ***
Having a quick peek at this now, but KActions and .rc files are a bit of a black art to me :)
Ok, I have working "Move To Trash" (thankyou, Dolphin! :)). I have no idea what changed between KDE3 and KDE4 that let this all work before, but it should be quite easy to fix. I'll attach a patch sometime tomorrow.
Wow great, it would be really great if all the other file manipulation options where there too
@aapgorilla: "Wow great, it would be really great if all the other file manipulation options where there too" Of course - the Move To Trash thing is just a proof-of-concept - I'll make sure to add all of the other actions when I attach the patch :)
Created attachment 37973 [details] File management actions for KDE4 FSView (first attempt) @Josef: Could you review this for me? :)
Ah, thanks for doing this! I tried to revive the actions at end of July (after seeing this bug report, but obviously made no comment). At that time, I fixed some drawing bugs. But I had no time to work into KDE4 KPart details, so it did not work out. Anyway, it looks OK from a rough view. If it works, and is taken from Dolphin, it should be fine. Just one thing, regarding the treemap.cpp change: TreeMapWidget is more or less a copy from the one in KCachegrind, and I want to keep them in sync. And there, it makes not much sense to clear the selection on Escape. Can this behaviour moved out into the FSView specific subclass of TreeMapView? And you are right with your FIXME comment: there is a bug in clearSelection(). It should be changed to: ... bool TreeMapWidget::clearSelection(TreeMapItem* parent) { ... TreeMapItem* changed = diff(old, _selection).commonParent(); if (changed) { + _tmpSelection = _selection; changed->redraw();
@josef: "Can this behaviour moved out into the FSView specific subclass of TreeMapView?" That's a bit tricky - I'll need protected access to TreeMapWidget's "_pressed" (or an accessor), I think. What do you suggest? "And you are right with your FIXME comment: there is a bug in clearSelection()." Ah, good to know - I'll add that in a later revision :)
> That's a bit tricky - I'll need protected access to TreeMapWidget's > "_pressed" (or an accessor), I think. What do you suggest? Just make _pressed protected, and override keyPressEvent(), calling TreeMapWidget::keyPressEvent() for all unhandled events. As treemap.cpp is a copy in FSView, we do not have to care about any kind of API compatiblity - it would be different if TreeMap is part of kdelibs. However, I want to make sure that I can keep treemap.cpp in FSView and KCachegrind exactly the same (also for bug compatibility ;-)
Created attachment 37990 [details] Revised patch Cool; that's nice and easy, then :) Updated patch attached - now with K&R(TM) bracing style!
Looks fine! Can you commit it to trunk? One final remark: the only real change needed in "treemap.h" is the move of _pressed from private to protected: keyPressEvent() is already declared virtual in QWidget, no need to explicitly tell this to the compiler for every subclass.
SVN commit 1043045 by sstjames: Borrow some code from Dolphin to make FSView file management operations (Move To Trash, Delete, etc) work in KDE4. Deselect All on pressing ESC. Minor redrawing bugfix to TreeMapWidget::clearSelection(...). CCMAIL:peter.penz@gmx.at BUG:180579 M +14 -0 fsview.cpp M +3 -0 fsview.h M +78 -16 fsview_part.cpp M +2 -1 fsview_part.h M +1 -0 treemap.cpp M +3 -2 treemap.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1043045
Ok. After trying out for real now, here are some issues: I get Object::connect: No such slot FSViewPart::slotEditMimeType() Object::connect: (sender name: 'editMimeType') Object::connect: No such slot FSViewPart::slotProperties() Object::connect: (sender name: 'properties') when running konqueror in the terminal, selecting fsview part. When selecting an item (eg. with Ctrl+LMB), the menu items "Edit/Edit File Type" and "Edit/Properties" are enabled but do not work. However, the "Properties" item from the context menu *does* work. Strange. It would be nice to adhere to the konqueror configuration "File Management/General/Context Menu/Show Delete command". I suppose you should ask Peter Penz about reviewing this stuff. Anyway, thanks so far!
@josef: I guess it's trickier than I thought, as always ;) Thanks for the reports: I'll see if I can have a look over the next week. Can you expand on what you mean by: "It would be nice to adhere to the konqueror configuration 'File Management/General/Context Menu/Show Delete command'" ?
> Can you expand on what you mean by: > "It would be nice to adhere to the konqueror configuration > 'File Management/General/Context Menu/Show Delete command'" This is a configuration option for konqueror, when selecting "Settings/Configure Konqueror". As the delete action is dangerous (there is no undo), the default is to not show it in the context menu. With above configuration, you can add it to the context menu if you want. I just noticed that "Delete" appears in the context menu of the FSView part even if this option is off. The other file management views do it right. However, even there, "Delete" can be found in the "Edit" menu, which is wrong IMHO. Anyway, the delete action still should always be available via its shortcut "Shift+Delete*.
I just tested with KDE 4.4.0 ppas on Kubuntu-9.10 and there are still no file manipulation options. Reopen, please?
Hmm... the fsviewpart is in the extragears packages in the KDE SVN (e.g. in trunk/extragear/base/konq-plugins/fsview), and not below the "trunk/KDE/" directory. So I wonder whether fsview actually was part of the KDE 4.4.0 release? Perhaps Kubuntu still uses older version from "extragear" ? Here on OpenSuse11.2, the KDE 4.4.0 packages from the KDE:/KDE4:/Factory:/Desktop/openSUSE_11.2 repository of the build services still has the 4.3.1 version of the RPM package "konqueror-plugins" which contains fsview. Can you check out the last revision from SVN (see http://websvn.kde.org/trunk/extragear/base/konq-plugins/fsview/), which still happens to be (apart from automatic scripty changes) revision 1043045 from 3 months ago by sstjames, and compile this yourself?
I just tested the KDE 4.4.1 ppas on Kubuntu-9.10 and there are still no file manipulation options. I also tried compiling fsview from the latest svn but cmake failed with the following output: ---------------------------- root@ronny-desktop:/tmp/fsview# cmake . -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake Error at tests/CMakeLists.txt:18 (kde4_add_executable): Unknown CMake command "kde4_add_executable". CMake Warning (dev) in CMakeLists.txt: No cmake_minimum_required command is present. A line of code such as cmake_minimum_required(VERSION 2.8) should be added at the top of the file. The version specified may be lower if you wish to support older CMake versions for this project. For more information run "cmake --help-policy CMP0000". This warning is for project developers. Use -Wno-dev to suppress it. -- Configuring incomplete, errors occurred! ---------------------------- Any hint/help how to compile fsview myself?
Just a comment: when compiling from SVN, you have to run cmake from the parent directory of fsview (trunk/extragear/base/konq-plugins). Regarding the missing actions: currently no idea what's going on. Last time I checked, it somehow worked, see comment #14 above :-( Will have to recheck... (Simon?).
@Josef: I don't know if extragear is part of the Kubuntu PPA's, so let's see if Ronny has any luck after he's compiled them :) @Ronny: Once you've compiled fsview, remember to call kbuildsycoca4 If you still don't have any luck, try closing all konqueror instances (including hidden, preloaded ones) and re-try. If you still don't have any luck, uninstall the konq-plugins that were installed with via your package manager. If you *still* don't have any luck - then we'll have to spend some time figuring out why :)
Thank you for the hints. After checking out trunk/extragear/base/konq-plugins and executing: $ cmake . $ make $ sed -i 's|CMAKE_INSTALL_PREFIX.*|CMAKE_INSTALL_PREFIX=/usr|' CMakeCache.txt $ sudo make install $ kbuildsycoca4 $ konqueror I have a file system view with file manipulation options. So, whats next? Should I file a distribution specific bug report at Kubuntu?
@Ronny: Excellent! I'm not sure how Kubuntu's PPA system works, but it seems that the bug should be filed with whoever created the PPA you are using.
I just tested Kubuntu 10.4 Beta1 and the file manipulation options are there. So it was a bug in the 4.4.1 ppas for Kubuntu 9.10. No need to file another bug report. Closing, please? :-)
@Ronny: That's good news! I'm going to leave this open for now as Josef has listed some regressions in https://bugs.kde.org/show_bug.cgi?id=180579#c15, but I don't know when/ if I'll have time to fix them :/
(In reply to comment #26) > @Ronny: > > That's good news! I'm going to leave this open for now as Josef has listed some > regressions in https://bugs.kde.org/show_bug.cgi?id=180579#c15, but I don't > know when/ if I'll have time to fix them :/ I do not get the signal/slot connection errors mentioned in comment #15 ; so is it safe to assume this issue is resolved and close this ticket ?
See comment #27.
Hm. With fsview from Kubuntu 12.10, in package konq-plugins (4:4.9.2-0ubuntu4) I still get the same errors as in #15. But if others do not see that, this is either my configuration or a packaging problem. Thus, closing.
(In reply to comment #29) > Hm. With fsview from Kubuntu 12.10, in package konq-plugins > (4:4.9.2-0ubuntu4) I still > get the same errors as in #15. But if others do not see that, this is either > my configuration > or a packaging problem. > > Thus, closing. Actually, I can certainly reproduce the issues now. I dunno why I was not able to do so before ; so lets leave this open until the issue can be resolved. Would you or anyone else be able to test a patch if I provide one ?
(In reply to comment #30) > Would you or anyone else be able to test a patch if I provide one ? Sure.
Created attachment 75391 [details] proposed patch completely untested patch to address the issues described in comment #15.
Looks good. The problems from #15 are fixed, and the menu items for editing the mime type and showing properties of a selected file work. Just a minor thing: I get a "QWidget::insertAction: Attempt to insert null action" warning whenever I open a context menu on an item in the fsview. Not sure where this comes from. But everything seems to work. Can you commit?
(In reply to comment #33) > Looks good. The problems from #15 are fixed, and the menu items for editing > the mime type and showing properties of a selected file work. > > Just a minor thing: > I get a "QWidget::insertAction: Attempt to insert null action" warning > whenever I open a context menu on an item in the fsview. Not sure where this > comes from. Oh I saw that too, but forgot to fix it. Will take care of it. > But everything seems to work. Can you commit? Yes.
Created attachment 75397 [details] proposed patch v2 OK. This is the final patch. Now the delete and move to tash menu items should work much in the same manner as they do in the Dolphinpart. If you can, please check if deleting/move to trash work as expected from both the context (right click) as well as the Edit menus.
Git commit d8d0e423c475147782a1ab67e047579777c213b5 by Dawit Alemayehu. Committed on 22/11/2012 at 17:10. Pushed by adawit into branch 'master'. Fixed regressions that prevented file manipulation from working properly. FIXED-IN: 4.9.4 M +50 -16 konq-plugins/fsview/fsview_part.cpp M +1 -0 konq-plugins/fsview/fsview_part.h http://commits.kde.org/kde-baseapps/d8d0e423c475147782a1ab67e047579777c213b5