Drag&drop behaviour and file panel modes/filters about filer HOT 26 CLOSED

Table messed up. No edit in web+... Another try:

Drag'n'dropping a file/folder/symlink:

File panel filters:

from filer.

Nice table. :)

For drag&drop, the current behavior doesn't resolve SymLink files. I have added it in PR #113.

I don't think we should alter the current behavior of drag & drop a folder for Size. It doesn't make sense to fill "0 bytes".

I will work on the file panel part next.

from filer.

With drag&drop:

• for Test Type, we should not use the MIME of the target because it's the only way for the user to drag&drop a SymLink MIME type.

• for Action Shell Command, we probably should use the full path of the SymLink file instead of that of the target. The reason for the user to have the symbolic link in the first place is to type a shorter command and/or set up a link to a variable target.

from filer.

I have updated #113 accordingly.

from filer.

I don't think we should alter the current behavior of drag & drop a folder for Size. It doesn't make sense to fill "0 bytes".

Yeah, well, I dunno... of course it doesn't really make sense to drag&drop a folder in the first place. But at least the user has some feedback: the value changes to the dropped object, which for a folder is correctly "0". So the behaviour stays consistent and the user doesn't wonder if he dropped the object correctly or whatever happened...

• for Test Type, we should not use the MIME of the target because it's the only way for the user to drag&drop a SymLink MIME type.

Yeah, I've thought about that a bit. Maybe I'm unusual, because I have a few symlinks to WIP documents on the desktop. When testing Filer, I just grabbed e.g. a link to a WonderBrush image and expected to have its MIME inserted, instead of the symlink MIME.
Not sure which behaviour is more common/expected... Checking if a new file/folder is a symlink may be not a very common use case. Also, people still can enter the MIME type manually...
I leave it up to you. Maybe we get some feedback from other users and can adjust in the future...

• for Action Shell Command, we probably should use the full path of the SymLink file instead of that of the target. The reason for the user to have the symbolic link in the first place is to type a shorter command and/or set up a link to a variable target.

I agree. That's why for "Shell" there's "Path and name of the symlink" in the table. :)

Shall I merge the PR as is, or are you adding more changes?

from filer.

But at least the user has some feedback: the value changes to the dropped object, which for a folder is correctly "0". So the behaviour stays consistent and the user doesn't wonder if he dropped the object correctly or whatever happened...

For other OS's like Windows and Mac, a zero-size folder means that the folder is empty. Also, I think it's common to do nothing if an invalid item is drag&drop'ed. (WheresMyMouse does nothing if a non-RGB object is drag&drop'ed.)

Also, people still can enter the MIME type manually...
I leave it up to you.

I will use the SymLink MIME type then. I think most users don't want to memorize and type the MIME types. Is there a way in Tracker to click on the SymLink file to get to the folder of the target? Then the user would be able to drag&drop the target to get its MIME type.

I agree. That's why for "Shell" there's "Path and name of the symlink" in the table. :)

Sorry. I misread it. :(

Shall I merge the PR as is, or are you adding more changes?

We should use the target of a symlink file for Action "Add to archive" drag&drop. (The target can be a folder or a file.) I will update the current PR.

from filer.

Done with updating PR #113 again. Also, I refactored the relevant code in ActionView and TestView in preparation for changing the File Panel part of this issue.

from filer.

But at least the user has some feedback: the value changes to the dropped object, ...
For other OS's like Windows and Mac, a zero-size folder means that the folder is empty. Also, I think it's common to do nothing if an invalid item is drag&drop'ed. (WheresMyMouse does nothing if a non-RGB object is drag&drop'ed.)

Maybe you're right... I wonder if there's anything to be done to signal back that the drop was unsucessful. Maybe in the future, Haiku will show an animation of the object flying back to it's starting position when it receives an error.
Just in case you'd like to investigate, SendReply() seems to be the right direction. Not sure on the "what" of the reply though... There's a Drag&Drop section in the BeBook, but I don't see a hint on that.

I will use the SymLink MIME type then. I think most users don't want to memorize and type the MIME types. Is there a way in Tracker to click on the SymLink file to get to the folder of the target?

Yes, the "Open Target Folder" Tracker addon (OPT+ALT+O).

Merging your changes. Thanks!

from filer.

I have summarized the behavior of the merged #113 below. The last column with a "+" indicates the differences from your table.

from filer.

Now I see you meant "Path of parent folder of file" by "Path of file" in your tables. I use the term "path" to mean the (absolute) path including the (leaf) name of a file/folder/symlink, so the "Location | File " rows in our Test tables have the same meaning.

Anyway, below is the Action table:

from filer.

Maybe in the future, Haiku will show an animation of the object flying back to it's starting position when it receives an error.

That'd be nice. Also, pressing Esc doesn't cancel the drag in progress. I just tried dragging a folder in Tracker, and because Esc did nothing, I had to drop it on the window title of Tracker to cancel it. No feedback, either.

from filer.

I was wondering if we should take the MIME type of the target as you preferred, but after realizing that Filer would have to handle bad links, I think taking the SymLink MIME type is simpler. The user can easily navigate to the folder of the target if the MIME type of the target is needed.

from filer.

I want to confirm the spec for the File Panel part before changing the code. Here is what I think it should be:

from filer.

from filer.

That'd be nice. Also, pressing Esc doesn't cancel the drag in progress. I just tried dragging a folder in Tracker, and because Esc did nothing, I had to drop it on the window title of Tracker to cancel it. No feedback, either.
Yes. There are a few subtle animations etc. that would do Tracker/app_server good... Unfortunately, as you can attest, at least Tracker's code is a bit complicated and app_server something few people a comfortable touching.

from filer.

I want to confirm the spec for the File Panel part before changing the code. Here is what I think it should be:

Test | Filter shows | can choose folder? (double-click to open folder)
Location | folders (and symlink to folders) | yes

I think "Location" should not just show folders, but just show everything. When the user picks a file, its path (parent folder) is taken.

from filer.

Shouldn't that be "Folders and ZIP archives (and all non-typed)"?

from filer.

I think "Location" should not just show folders, but just show everything. When the user picks a file, its path (parent folder) is taken.

With drag & drop, I tried to allow as many types of objects as possible because I can't restrict what the user will drag. For example, although dragging a file while a folder/location is expected doesn't make sense, I still take the location of the file instead of simply rejecting the operation.

However, with file panel, I can control (to some extent) what the user can select by playing with the filter. If a folder/location is expected, I will only show folders. Had the files also been shown, choosing a file would effectively choose the current directory, which can be accomplished by clicking on the Choose button without selecting the file. One less click.

from filer.

Shouldn't that be "Folders and ZIP archives (and all non-typed)"?

Yes, but the user wouldn't be able to reuse an existing file name, say, "nonZipFile" and create a zip file named "nonZipFile.zip". (The zip command appends the .zip suffix to the given file name if the suffix is absent.)

from filer.

I only showed zip files (including symlink to zip files) for archives and text files (including symlink to text files) for commands after all. Please play with PR #114 to see how you like it.

from filer.

There is no change to the test table. The action table is as follows:

from filer.

I wonder why generic files should be shown for archives and commands.

from filer.

However, with file panel, I can control (to some extent) what the user can select by playing with the filter. If a folder/location is expected, I will only show folders. Had the files also been shown, choosing a file would effectively choose the current directory, which can be accomplished by clicking on the Choose button without selecting the file. One less click.

You're right. I forgot you already fixed Haiku's file panel to pick the current folder when nothing is selected.

I wonder why generic files should be shown for archives and commands.

We decided on that, because of foreign filesystems that only show non-typed files, IIRC.

I played a bit with your PR and everything's working very nice now. Thanks!
Will merge...

from filer.

We decided on that, because of foreign filesystems that only show non-typed files, IIRC.

I didn't forget. That's why my question. Is there any chance Haiku would recognize these non-typed files as archive/text files. In my Action table above, I forgot to list "symlink to generic files" for both Archive and Shell rows. It seems there is too much "noise" that won't be useful for the user at all.

from filer.

We decided on that, because of foreign filesystems that only show non-typed files, IIRC.

I didn't forget. That's why my question. Is there any chance Haiku would recognize these non-typed files as archive/text files.

I don't think so. Maybe future Haiku/fs-driver will sniff for MIME types, but for now we're save with keeping non-typed files in our file panels.

In my Action table above, I forgot to list "symlink to generic files" for both Archive and Shell rows. It seems there is too much "noise" that won't be useful for the user at all.

Not sure I quite get what you mean. Seems to be fine, Archive and Shell panels show generic files and symlinked generic files. All OK, I think.
I'll me merging this #115. You can continue to tweak, if you think it's necessary... :)

from filer.

I have pushed a new PR (#116), which better shows what I meant. I figured if you have a zip/script file from a file system foreign to Haiku, you can't add Haiku files to the zip or run the script in Haiku. If that's not the case, please disregard the PR.

I won't make any more changes to Filer before the release. I won't have time anyway as school already started this week.

from filer.