Minor issues with xffm from Xfce 4.2 beta

[edscott wilson garcia]

El mié, 13-10-2004 a las 02:38, Gianluca Turconi escribió:
> edscott wilson garcia wrote:
> > El mar, 12-10-2004 a las 02:09, Gianluca Turconi escribió:
> > 
> > 
> >>>>b) what is the best way to create a symbolic link in two different
> >>>>directories by using the two panes view in xffm?
> >>>>I've tried to drag and drop it by holding down the Shift and/or Alt key,
> >>>>but the file is copied or moved.
> >>>
> >>>Drag and drop by holding down SHIFT-CTRL does the symlink. A button to
> >>>symlink the pasteboard contents has been suggested in the past, but is
> >>>not yet available.
> >>
> >>SHIFT-CTRL! I should have try them before asking...
> > 
> > BTW, I had forgotten to activate the paste-link button. This button is
> > now active in the current CVS. This will symlink what ever you have
> > cut/copied into the pasteboard into the desired location. The button is
> > underneath the normal paste button. 
> 
> Since we're talking about buttons, is there any way to let the 
> navigation buttons (home, next, previous, etc) to stay active when no 
> folder or file is selected?

Yes. Use only one treeview pane (hide the other with the buttons at the
top or move the pane divider). That way xffm will know at what treeview
you are looking at and will keep the the navigation buttons active.

> 
> I've put them in the toolbar on the left, but I have to click somewhere 
> in the panes to activate them otherwise they are grayed out.
> 
> Similarly, is there any way to make the box where you type file URI 
> permant. I'd like to have it always on because it's sometimes faster to 
> type the URI at once rather than clicking on the navigation buttons 
> (include "goto") or using bookmarks.

One keystroke away: just preceed the path you type with CTRL-downarrow,
that makes the goto input box appear and get focus without using the
mouse. You can check for other keyboard accelerators by looking at the
main menu and popup menu elements.

The space is shared by the toolbar and the entry is shared with the
rename/duplicate/open with and every other function which requires
input. So always showing is not an option. 

> 
> Then, I've found a behavior that seems a bug: when I right click on the 
> "recent" branch in xffm and then choose the "clear" item from the 
> context menu, the branch is closed, but not cleared.

ACK. I'll look into it.

> 
> Finally, there is something in xffm which I found strange. Let's say I 
> sent a file from my home directory to the wastebasket. Then I open the 
> *main* trashcan and right click on that file and finally I choose 
> "remove item from trash". According to the theory of the main and local 
> trashcan, the deleted file is now only in my home trashcan. However if I 
> right click on that file in the local trashcan, I'd expect another 
> "remove item from trash" option that would move the file to the original 
> location *outside* the local wastebasket. Instead, I have to move it 
> manually outside the trashcan and the local wastebasket will stay there 
> even if it is empty until I empty the main wastebasket.

Basic difference between 4.0 and 4.2 trash collection: 4.0 collected a
list of all files in wastebaskets. This proved to be too much. Therefore
4.2 only tabulates a list of the wastebaskets themselves.

If you need to eliminate a single wastebasket and all its contents, just
select it and press remove button (or delete key), either from trash or
folder branch. All undeletion needs to be done by looking into a
wastebasket, selecting something and pulling it out.  This is exactly
what you do when you pull something out of the wastebasket in your
office/bedroom/kitchen. Only you and God know what you want to do with a
recovered file, so xffm will not play God and leave it up to you.

The trash bin. Yes the big trash bin is not very good for undeleting
stuff. It is like going outside the office building, jumping into the
truck size garbage container and looking for the post-it note you threw
away yesterday. All this before the garbage truck comes along. This is
what MS-windows, gnome, kde expect you to do. Not very considerate.

Since the xffm trash bin is *not* meant for undeleting stuff (it's meant
for collecting and disposing of trash, just as in the office building
analogy), undeleting from anywhere other than wastebaskets is not
supported. Yes, you can go ahead and jump into the trash bin if like to.
Good luck if you do. ;-)

> 
> Im my opinion, it is better to remove automatically an empty local 
> wastebasket when the last item is removed from it, otherwise xffm will 
> create unnecessary trash all around the filesystem, just by leaving 
> "alive" those empty trashcan.

Since you have to undelete from wastebaskets, you should also delete the
wastebasket when empty. If you eliminate all wastebaskets with the trash
collection branch, wastebaskets are also removed. 

Yes, xffm has a different philosophy regarding trash.

> 
> [...]
> 
> > Thanks for the bug reports. If there is no default for the theme you are
> > modifying (only Rodent, hicolor and gnome have defaults) send it along
> > and it may be included in the release.
> 
> [...]
> 
> Well, I'd have learnt the syntax of the previous xffm mime files to add 
> OpenOffice.org icons, but now I've tried to duplicate the rodent mime 
> xml by naming it Lush.mime.xml and it seems I should manually do a lot 
> of work to sync it with the Lush icons. IMHO, it's simpler to use a 
> working mime editor... ;-) In fact, on my Fedora Core 2, even without a 
> defaults file for xffm when I select the Lush icons theme, only a pair 
> of icons are missing.

The syntax has changed. And xfmime-edit is working. What is broken is in
libxfcegui4/xfce4-modules, but that is now fixed. Just update your
libxfcegui4 from CVS and xfmime-edit will be in working condition (no
need to recompile xfmime-edit).

> 
> I was forgetting to ask for an enhancement. I know there is a features 
> freezing for the release of xfce 4.2, however there will be 4.4 too, 
> right? ;-P
> 

Hope so ;-)

> Well, my request would be to have a way to let the user know when he/she 
> is typing a wrong URI into "Goto" box. For example, rox-filer makes the 
> typed URI red if it doesn't exists in your file system. Again, konqueror 
> shows a list of similar existing URI in a dropdown list from which you 
> can choose the right one.
> 
> Instead if I mispell somenthing in xffm it may present only the list of 
> the previous typed URI without any warning about my mistake.
> 
> It's annoying to see xffm not to jump to the right location and to have 
> to retype the right URI, especially if it's a long one.

The suggestions in xffm dropdown are made from previously gone to paths
(only valid paths count). This is different from konqueror because xffm
is a treeview and you can move faster into the directory structure by
just expanding and doubleclicking on nested folders (or using arrows and
return). The goto autocompletion follows the same rules for goto as for
all other xffm autocompletions. The goal of xffm is to learn from the
user's behaviour, not just to suggest for suggestion's sake. BTW,
folders that are double clicked will also enter the goto history, so if
you double click often, you build up a reasonable good "goto" history. I
bet konqueror doesn't do that.


The red letters for invalid paths sounds like a good idea, but since
xffm can also "goto" remote smb servers (type //server_name) there is no
way to know whether this path is valid or not until the goto is given.
This would be inconsistent.

regards,

Edscott