Version: (using KDE KDE 3.1.3) Installed from: Debian testing/unstable Packages OS: Linux In the Konqueror file manager, when using the 'copy to' and 'move to' commands in the context menu for files, I would like to be able to move files to the parent directory, rather than having to start from root or home when specifying a location.
*** Bug 71874 has been marked as a duplicate of this bug. ***
It is also useful when menu takes all the screen, and you want to get back, of cource you can press ESC but it is not obviuos
In the file : kdeaddons/konq-plugins/kuick/kdirmenu.cpp line 108, change : if ( fileName == dot || fileName == dotdot ) continue; by : if ( fileName == dot) continue; and it's should work fine. (but I don't try this ;-) ...) Axel
Thanks, Axel. I've done that small deletion and installed the new kdeaddons (v 3.3.2). It works very nicely. I really don't see that any more change is needed, although I suppose that some people would claim one needs to call the parent directory something like "up one" instead of ".." (I'd disagree strongly: ".." is very concise and takes only a minute bit of learning, and is good to know anyway for older apps and for shell). So, PLEASE, maintainer, would you insert this tiny change so that kde needn't be modified every time it's installed or upgraded by someone who wants to be able to move up as well as down! Nathaniel
I made some personal prefernce changes to kuick. I didn't want my wife seeing the root menu in "copy to" and "move to" so I added block comments to that section in kmetamenu.cpp . It confused the hell out of her. There's no real point in having it sense users can't write to 99% of the system. To make it more user friendly I added the following line to kdirmenu.cpp: if ( fileName == dot ) #changed from: if (fileName ==dot | fileName == dot dot ) continue; if ( fileName == dotdot ) fileName="Up One"; #added to change ".." to "Up One"
I'm trying to modify the kdirmenu.cpp file to determine if the current listed directory is root. If it is then don't show the parent directory. What's the if statement I use to determine this? I tried `if ( path == "/" )` but that didn't work. I'm still a very amateur programmer.
I suppose I agree that for most systems only /home (which can be accessed through .. from ~ if ever .. gets in to the list!) or /tmp (which could have its own menu item if needed, instead of having / [Root]) are writable by users. I think that replacing the `..' directory with some sort of name -- but still keeping it at the top of the list -- is a good idea, but I suggest either "Parent Directory" (no hope, since now we have to call them folders in KDE and `parent' is probably deemed too confusing) OR use the word "Up" or "Parent" along with an up arrow -- this would fit very nicely with konqueror's "Up" button. Re: Carl's second posting; getcwd(3) is a C function that returns (the absolute pathname of) the current directory of the program's process as a string. You could then compare this with "/" in your check. See "man 3 getcwd". But I only know C -- not the ++ variant, so I'm perhaps missing something else you should do ...
So if I'm not mistaken I could change if ( fileName == dot ) continue; if ( fileName == dotdot ) fileName="Up One"; To: if ( getcwd(3) == "/" ) if (fileName == dot | fileName == dotdot) continue; else { if ( fileName == dot ) continue; if ( fileName == dotdot ) fileName="Up One"; } So that way when the root list is being shown the 'Up One' won't show, right? Also, I know I should post a bug for this, and this is not a forum, but I was wondering why my `Contact` list is empty even though I have contacts added in Kontact.
getcwd won't work - the konqueror process' working directory does not change to the directory it is currently showing. I'd have expected path == "/" to work, investigating it now.
Created attachment 10598 [details] patch to show parent dir except when at / Does this do what you want? I'm not sure whether including relative locations from absolute dirs is a great idea, as you can just go there from /, but it might be handy in the Current Folder dirmenu. To apply: "patch -p0 < kuick.patch", when in kdeaddons/konq-plugins/kuick
OK, thanks a lot Will, you've set me on the right track. Since I removed the root menu entry I want my users confined to the /home directory (not because I'm mean, I just don't want to confuse my wife). Modifying your patch has done that with the code below. Now what I want to do is to change "Previous" to "Other Users" when the current user's home directory is being listed. I suppose that would require a way of changing "/home" to "/home/someUserString". I also want to change the icon of "Previous" to an up arrow and the "Other Users" to show a user icon. Any ideas?? static const QString& dot = KGlobal::staticQString( "." ); static const QString& dotdot = KGlobal::staticQString( ".." ); static const QString& slash = KGlobal::staticQString( "/home" ); for ( QFileInfoListIterator it( *dirList ); *it; ++it ) { QString fileName = (*it)->fileName(); if ( fileName == dot || fileName == dotdot ) if ( fileName == dot || ( fileName == dotdot && path == slash ) ) continue; else fileName="Previous";
Created attachment 10605 [details] proposed patch I think you still want to have "Parent Folder" ( "previous" to me sounds like a move Back in the history) in the home dir, so that the user can navigate anywhere else in the filesystem and dump something there, when Root is disabled and the other users' homes all have 750 perms, and not have to Browse. What about hiding Home Folder when the view is in the home folder? Proposed patch: When / is writeable, show Root Folder otherwise, show Other User (I am not sure about this, it seems like clutter) When /etc is writeable, show System Configuration When not in $HOME, show Home Folder Show Current Folder All folders include Parent Folder using "up" icon. Contact menu no longer active when no Kopete Contacts have Address Book Link set.
The proposed patch sounds great. Avoiding showing the parent when already in root (/) was something I hadn't thought of and is certainly sensible. I thought Carl's suggestion of "other users" was just a request for help with his own situation, rather than a proposal that it should be like this in KDE for everyone (am I right?). I certainly don't think any "other users" idea would be good for the normal case, since I've never yet met a system (work, home) where other users' homes are writable. People generally use shared space outside ~/ for such shared writing. It would indeed be clutter, and the inclusion of a "Parent" option does as you say pretty much obviate the need for it anyway. "Other users" would also confuse me if I saw it without all the background from this list! I don't see a lot of point in "system configuration" -- many many times less than in "Parent" -- but as it will seldom be writable (unless running as root or on a strange system) there's no harm in this idea for most users. So: When / is writeable, show Root Folder When not in $HOME, show Home Folder Show Current Folder All folders include Parent Folder using "up" icon. This would be delightful to see in the next release!! Thanks.
Wow, these are really good ideas guys. Thanks so much Nathan for the code. I'm trying to rid KDE of everything that shows the root system. I just want my wife to see what's in her home directory. Kind of like mac. That's the reason, among others, that ANYONE can use a mac. I like a lot of the functionality of KDE better than mac though, that's why I use it. Even as the admin I never write to any part of the system other than my home directory (except for /usr/src/packages/) with KDE. I use the command line for everything else. It would be nice to see KDE move in that direction to be more user friendly so ANYONE can use it without confusion and having to learn the linux OS (which usually varies from distro to distro). After the this is done, the only thing we have to tackle is software installation.
Sorry, I got the name wrong above. I meant to thank Will for the code. Though thanks Nathan for the great ideas as well.
Will, I just applied you patch. This is definately what should be in the next release of KDE. Great Work!!
Is it easy for '/' to appear when a subdirectory is writable? I have various partitions and occasional external devices writable in /mnt, and the prospect of accessing it via '~ .. .. mnt' seems somewhat unpleasant (almost as much as browsing for it). Another thought (I've not tested the patch yet) is whether accessing a subdirectory then parent will do the same as pressing escape or bring up a new menu on top (and vice versa). It sounds like it may be more trouble than it's worth though.
1)It's not easy - you would have to start at /, look for a writable subdir, /mnt won't be writable, so you'd have to check all of /'s subdirs and then all of their children - all of which between the user right clicking and the menu appearing. A better idea might be to show the media:/ ioslave, which is where your removable devices should appear on a modern distro. This would need some rewriting, though - the menu generating code is not ioslave aware, although the actual copy/move to code is. 2) There is no loop detection. I could imagine it being a bit surprising to users. Apart from being a bit untidy, is there any disadvantage to it? The shell doesn't stop me doing cd ../will/bits/../../../will either.
1) Directories directly within `/' on linux systems, that can (sometimes) be written to by users are several: /home/<own> , /{mnt,media}/* , /tmp Some systems have even more if shared network filesystems are mounted on e.g. /scratch or the like. Other systems that run kde may use /mnt directly as a mount point or have /cdrom /floppy and so on. So I think it's a) indeed hard to check reliably for which (sub)subdirectories of / are writable b) perhaps rather confusing when some systems have the option and some don't c) useful to have / available since it would be tedious to have to find /mnt and /media and /cdrom and /random_net_location and /big_disk by hopping up the tree! 2) elegant though loop detection would be, I agree it would be confusing to have a part of the tree of menus disappear when it sees itself to be redundant! I really think that with the already proposed addition of a "parent" option with up-arrow, and the removal of the kopete extension except when kopete is actually configured, the copy/move system will be fine.
1) Given that the media:/ ioslave should give access to /mnt/*, /media/*, /floppy, etc, I suggest including that in the top level menu. NFS mounts in /scratch, new disks on /bigdisk, etc, are so variable that the user can browse to those once, then rely on them being in the recently used dirs entry.
Well, We could add a menu called Media that lists everything in media:/ . Of course we could always make the "Copy to" and "Move to" menus configurable. We could add the ability to add and remove entries. Just add it to the kcontrol module. Currently for the sake of user-friendliness I think the posted patch is the best way to go.
There are other folder which can be writeable for the users like: /mnt/windows partition /mnt/floppy /mnt/smb etc. please check whether the user has got write permission, if it's they then allow user to copy/move to a folder. having Devices:/ or media:/ as in "copy to" and "move to" submenu will also help.
I was thinking. I would like to see the media:/ kioslave listed but I'm afraid that it would clutter the menu up. So, what if it's only shown if something is listed in media:/ . What I mean is, if a CD is inserted or thumb drive or SMB mount, then you will see the Media listed. What do you think?
Ouch, I thought kuick couldn't get worse usability wise. I veto adding any sort of '..' to the menus. For KDE4 we will provide something with less usability issues. Currently you are always able to select the folder from your hierachy.
> Ouch, I thought kuick couldn't get worse usability wise. I veto adding any > sort of '..' to the menus. Why? What on earth is bad about this? What users are you thinking of? (I'm assuming the "any sort of" includes options such as "up", "<uparrow>", "parent" etc., too). Actually, in my day to day use of KDE, I often enjoy the "move/copy to" menu, but the am annoyed by the lack of .. I sometimes remember to change this before compiling a new KDE version, and then I really enjoy it, though I still find it silly and annoying that the move/copy options are chosen first (the two right-click menu options) instead of at the destination (I have a separate suggestion for this). So, what is the problem with "usability?". Please don't go for `theory', let alone that which the Gnome people cite when they say how well their desktop is designed for HCI etc. -- it's nothing special! KDE had (and largely still has) very good usability, at least for people mildly familiar with the underlying system and commands. KDE currently seems to have a problem that it is being focused on people not familiar with computers and being 'scared' of anything like a double dot or up-arrow. E.g., silly permissions selection drop-menus instead of the old 3x3 grid, of the lack of a terminal as a default taskbar icon. This is stupid -- as has often been argued, without any defence that I've come across, it's possible for distributions to make changes they find useful for their users, but the people who get vanilla KDE are pretty likely to be those with the know-how at least to cope with double-dots and normal unix permissions, and to want a shell easily to hand.
I created 'kuick' to quickly move and copy files. So this was a developer driven feature and my primary usecase was to copy/move a set of selected files easily. One of the biggest drawbacks of this implementation is the lack of undo for the copy/move operations. And bad things did happen... e.g. people confusing 'paste' with 'move to' and their homedir was gone. Don't worry this feature will be in KDE4 but done differently and implemented directly in the filemanager.