xffm issues
edscott wilson garcia
edscott at imp.mx
Sat Aug 16 15:55:42 CEST 2003
Hi Danny,
On Sat, 2003-08-16 at 02:29, Danny wrote:
> >
> > The menu is to change the sort method, and resorts only if the sort
> > method has changed. What you want is to click on the "refresh" item
> > which is the first menu entry. That will resort and find anything new
>
> Hehe what shortcut does it have ? (Where can I look so I don't bug you
> with these kind of questions? ;))
>
ctrl-Z. Almost all shortcuts are listed alongside the menu item in the
main menu.
> > that has been missed without changing the sort method. The selected sort
> > method can be different for different folders on the same level, but
> > subfolders inherit sort method from parent (until you change it with the
> > popup menu, of course).
> >
> > >
> > > 4) what is the keyboard shortcut for "rename" ?
> >
> > Rename, ctrl-R
>
> Why is the keyboard shortcut not listed in the Popup Menu beside
> File>Rename (to the right of "Rename") ? ;)
Shortcuts are listed in the main menu for all buttons. No need to
duplicate them in the popup. They should also be in the docs.
>
> > > What about
> > > re-implementing shortcut-by-pressing-key-in-popup in the future;)
> >
> > I don't understand what you mean :-(
>
> The functions which do that are gtk_menu_set_accel_path, _group, I
> believe ... Like, one can set the keyboard shortcut of a menu item by
> hovering over the item and pressing the keys to be used in future for
> this item.
>
> But now that I know it's Ctrl+R, this isn't that important anymore ;)
> I just kept trying to assign the popup menu item a key since there was
> none listed to the right of the item... But since there is a shortcut,
> alright ;)
But you can't assign the accelerator to 2 different actions, so that the
action which really occurs is the one in the main menu, hence the
listing of the shortcut in the menu. Only the cut,copy and paste have
the shortcut listed in both because they are stock buttons.
> > name is missing. Something like:
> >
> > "mv /lost+found/xxx /dtt/dtt001.zip"
> >
> > I wonder how that can be done in the dnd cut+paste environment...
>
> Well, if the file stayed selected, it would be spotted more easily by
> the user and he will drag it then ? :) Two-step action is fine, but
> since the "current file mark"(lol) is forgotten...
You still have to select it again by clicking on it to start the drag,
so the number of clicks is the same. And you should be able to spot the
file easily since it will be placed on top of all other files in the
folder and will not be sorted with the rest until requested. That's why
they are placed at the top. If you want to find some paper quickly, you
leave it on top of all others on the table.
>
> > >
> > > 6) when dragging a folder, the view does not scroll when I reach the
> > > borders - f. e. if I want to drop it into a folder which is not
> > > currently in the visible area (I bet this is gtk issue)
> >
> > Yes. This is the second time it is noticed. AFAICT, it is a bit
> > complicated to implement so it has been postponed to 4.2 so that it will
> > not introduce bugs for 4.0. Make sure it's in the Wiki TODO so we won't
> > forget.
> >
> > >
> > > 7) when marking multiple files, and then using the mouse to drag the
> > > selection, the selection gets reset to 1 file... I suppose this is a gtk
> > > issue, but anyways... aaargh annoying;)
> >
> > gtk issue, yes, but easy to overcome once you get the hang of it. You
> > can begin the drag as soon as the selection is finished without raising
> > the button. If you forget, you can always ctrl click on the last item
> > twice and begin to drag before you release the second ctrl-click.
>
> Okie, will do it like that, then ^^
>
> > >
> > > 8) when moving a directory, and the file permissions of any subdirectory
> > > disallows moving/writing-to-directory-list (u-w), then the move is
> > > incomplete as some files remain at the source. If I then drag the
> > > remaining files to the same destination, it asks about overwriting
> > > folders / deleting stuff instead of just updating the already existant
> > > folders.
> >
> > On purpose. If a directory with the same name is found, it does not know
> > why it is there and it will ask you if you want to move it to the trash
> > or delete by overwriting. It's just a safeguard against mistakes.
>
> Ok then :)
>
> Though a mode "automatically overwrite if newer [or equal]" would be
> cool, for updating folders... though I didn't think that through yet...
>
> (nooo, I don't mean to clobber the replace/delete dialog, but add a
> option to xffm itself for "automatically overwrite files by newer
> eeeverywhere" yes/no)
>
Sounds good. And fairly easy too. It could probably be added as a
"hidden" option and in 4.2 become unhidden (since it would requiere
translations).
> >
> > >
> > > Also, what about automatically doing chmod u+w for moved folders and
> > > subfolders ? (perhaps remembering which and resetting them to the
> > > original state after the move)
> >
> > Moved and copied folders and files should have the same mode as the
> > originals. If it is not working this way, it would be a bug. Files
> > should even get the same modification date as the originals to
> > distinguish that the content is the same.
>
> Yes, but thats not what I mean.
> What I mean is that:
>
> /home/dannym/blah1 directory, r--------
> /home/dannym/blah1/file1 5 bytes, rw-------
> /home/dannym/blah1/blah2 directory, r--------
> /home/dannym/blah1/blah2/a 1000 byte, rw-------
>
> use xffm to move "file1" and "blah2" somewhere else -> *boom* permission
> denied (for removal of the said files from the source directory, and
> from removal of "a" from the "blah2" directory).
>
> To prevent that from happening, what about automatically doing:
>
> saved_state.push(mode("/home/dannym/blah1"))
> saved_state.push(mode("/home/dannym/blah1/blah2"))
>
> chmod("/home/dannym/blah1", "u+rw")
> chmod("/home/dannym/blah1/blah2", "u+rw")
>
> *** move files ***
> mv(....)
> mv(....)
> mv(....)
>
> for s in saved_state: chmod(convert_to_destination(s.name), s.mode)
>
> If you get the idea ;)
A couple problems with this approach. 1) What if the volume is write
protected? (as a cd or a ufs or ntfs mount in linux). 2) If a directory
has a read-only status, it should be respected because the status is
there for a reason. If there is no reason for write protection, then it
should be changed, permanently. What is needed is a specific "chmod"
function, capable of doing "chmod -R u+w" or "chmod o-x" or whatever on
the selected files. This in turn requires a dialog and translations,
which leaves it pending for 4.2.
>
> Then the move would work even though some directories have "r--", which
> happens all the time when I copy something from CD, maybe a
> misconfiguration from my side though. (about 1/3 the files I "rescued"
> had these directory-no-write permissions here O_O)
>
> It also would help for the case of disabled directory user-read, but I
> can't think of any real-world case where that would happen :)
>
>
> >
> > >
> > > 9) not having the size of the contents of each folder, I managed to fill
> > > up my backup partition all the time because I just didn't know on a whim
> > > what size the folders were... (yes I know about the "calculate size"
> > > menu item)
> >
> > Having to do a "du -s" on each folder would slow xffm down, even more
> > than all the gtk2 overhead has already.
>
> Yes, doing it *all the time* would... But a "I want to know what big
> bunches of stuff are in *this* specific directory" ? (yes, still slow,
> but it would be faster than me going to the terminal and doing the same,
> since I'm slow ;))
>
> Then again, maybe this is better implemented in a seperate program...
> dunno...
The "disk usage ctrl-Y" will give you number of files and filesize for
this purpose. It takes longer than plain "du -s" because it opens a
pretty dialog to show progress. The result is displayed in the xffm
status line.
regards
Edscott
>
> > >
> > > 10) there is a "scp before rsync" option which implies that scp is
> > > supported, but how to connect to a host via scp using xffm ? :)
> >
> > Say you open xffm on box 1. Then you ssh to box 2 and open xffm on box 2
> > but on the same display. Now you have two instances of xffm running on
> > different machines. If you drag and drop from one to the other, copying
> > will be done by the receiving box by either:
> >
> > scp-before-rsync rsh-before-ssh
> > yes yes ---> rcp
> > no yes ---> rsync --rsh=rsh
> > yes no ---> scp
> > no no ---> rsync --rsh=ssh
> >
>
> Hehehe that's cool ! :)
> *tries*
>
> > The reason for flexibility is that depending on the platform and
> > configuration of the boxes one method might work better than another.
> > Definitely YMMV with each method.
> >
> > regards
> >
> > Edscott
>
> cheers,
> Danny
>
>
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> http://moongroup.com/mailman/listinfo/xfce4-dev
More information about the Xfce4-dev
mailing list