XYplorer Beta Club

I know the proccess should be as light as possible, but some UI improvements could be of use to for most users, so I think it's worth a little bit ot process 8·D

admin wrote:Adding to nas8e9's post: Custom Copy/Move is a relatively young feature. I'm collecting ideas for the next version of it (I already have a long list). There will be improvements.

Great News! I'll be waiting for them! (I've already said it but, again, this is a very great soft! I'm liking it more as I'm using it!)

lwalker wrote:I know the proccess should be as light as possible, but some UI improvements could be of use to for most users, so I think it's worth a little bit ot process 8·D

The problem is that XYcopy.exe (when Background processing is enabled) is called for every file operation. Even with Windows caching some of the I/O overhead, it causes slight delays between key/mouse press and execution, and thus UX friction, as complained about here.

Again, no quibble with some of the functionality you requested.

admin: Custom Copy/Move is a relatively young feature. I'm collecting ideas for the next version of it (I already have a long list). There will be improvements.

Custom Move/Copy is great. I know this next request will probably have to wait until you add customizable mouse (and mouse key combination) shortcuts, but I would find the following feature very very helpful:

Ability to temporarily do a regular copy/move as needed on particular files, when custom move/copy is otherwise globally enabled -- and in particular, to be able to do this by a customizable mouse/key combination. For example, I always have custom move/copy enabled, but for small informational text files which accompany my larger data files, I'd like to be able to bypass the confirmation and just do a regular move/copy by simply holding down Ctrl-Alt (for move) or Ctrl-Shift (for copy) while dragging the file with the mouse.

Jerry wrote:Ability to temporarily do a regular copy/move as needed on particular files, when custom move/copy is otherwise globally enabled -- and in particular, to be able to do this by a customizable mouse/key combination. For example, I always have custom move/copy enabled, but for small informational text files which accompany my larger data files, I'd like to be able to bypass the confirmation and just do a regular move/copy by simply holding down Ctrl-Alt (for move) or Ctrl-Shift (for copy) while dragging the file with the mouse.

As a workaround, there are separate button for Use Custom Copy as well as Enable Background Processing. Both their context menu's offer further control over the options.

As a workaround, there are separate button for Use Custom Copy as well as Enable Background Processing. Both their context menu's offer further control over the options.

Yes, and that's what I do now. But I often forget to toggle the custom mode back on. Ideally, in addition to a way to temporarily do a non-custom copy/move, I would also like to temporarily be able to do a foreground copy/move, when background processing is otherwise enabled -- again via some mouse/key combination. In my case, I would want to temporarily do a non-custom, foreground copy/move with the same mouse/key combination.

Jerry wrote:

As a workaround, there are separate button for Use Custom Copy as well as Enable Background Processing. Both their context menu's offer further control over the options.

Yes, and that's what I do now. But I often forget to toggle the custom mode back on. Ideally, in addition to a way to temporarily do a non-custom copy/move, I would also like to temporarily be able to do a foreground copy/move, when background processing is otherwise enabled -- again via some mouse/key combination. In my case, I would want to temporarily do a non-custom, foreground copy/move with the same mouse/key combination.

Just curious: I also read your previous post and I'm not clear on why you don't want to use Custom Copy and/or background processing. Is it just to avoid the verification overhead?

Just curious: I also read your previous post and I'm not clear on why you don't want to use Custom Copy and/or background processing. Is it just to avoid the verification overhead?

The main reason for turning off Custom Copy/Move in these cases is that I don't want to be dealing so frequently with the final confirmation popups, and because they are small text files, the verification really isn't so critical (or at least I wouldn't think so). For background processing, there the problem is that I'll often have a long-running background move going on while doing other work which includes these small text file moves, causing them to get queued behind the long running move. It's particular to my workflow, but I like to see these text moves get removed from their source locations right away. Often, I forget that their moves got queued and I end up moving them again.

Jerry wrote:

Just curious: I also read your previous post and I'm not clear on why you don't want to use Custom Copy and/or background processing. Is it just to avoid the verification overhead?

The main reason for turning off Custom Copy/Move in these cases is that I don't want to be dealing so frequently with the final confirmation popups, and because they are small text files, the verification really isn't so critical (or at least I wouldn't think so). For background processing, there the problem is that I'll often have a long-running background move going on while doing other work which includes these small text file moves, causing them to get queued behind the long running move. It's particular to my workflow, but I like to see these text moves get removed from their source locations right away. Often, I forget that their moves got queued and I end up moving them again.

What about a rule based on size: Use Custom Copy only on files > (...) bytes.

admin wrote:What about a rule based on size: Use Custom Copy only on files > (...) bytes.

As I understood it, he'd additionally want those small files to be copied/moved immediately, i.e. in parallel.

admin: What about a rule based on size: Use Custom Copy only on files > (...) bytes.
nas8e9: As I understood it, he'd additionally want those small files to be copied/moved immediately, i.e. in parallel.

Yes, that's right. I had earlier in the thread asked for a size threshold but then realized that this second proposal hits 2 birds and is also more generally useful to others and less of a kludge.

Jerry wrote:

admin: What about a rule based on size: Use Custom Copy only on files > (...) bytes.
nas8e9: As I understood it, he'd additionally want those small files to be copied/moved immediately, i.e. in parallel.

Yes, that's right. I had earlier in the thread asked for a size threshold but then realized that this second proposal hits 2 birds and is also more generally useful to others and less of a kludge.

OK, one could do Use foreground shell copy for jobs < (...) bytes.

While I see the elegance of the mouse key combination, at the same time it's unpractical: users easily forget about these tricks.

OK, one could do Use foreground shell copy for jobs < (...) bytes.

Well, that will certainly work for me and I'd be grateful. But I can easily see other people wanting a quick temporary override for any size file. Even I would want to do that now and then. And it really is more of a specific kludge -- not that I would want to persuade you out of it if you don't do the mouse-binding.

While I see the elegance of the mouse key combination, at the same time it's unpractical: users easily forget about these tricks.

Until they ask in the forum and you or somebody else generously remind them. I only just recently discovered that Ctrl-Shift-Wheel changes the line spacing, but that way of doing it is quite practical and quite appropriate. I urge you to reconsider this one, but I guess others will have to weigh in.

What about instead, having Shift-Alt pressed during a mouse dragged copy/move first produce a popup menu (when mouse button is released) that allows you to choose whether to do this override or continue as-is? At least, that would be somewhat less hidden and helpful to any user who accidentally did this shortcut. It could also serve the other way around -- letting you do a custom copy/move and/or background processing if you don't otherwise have that globally enabled.

Not simple enough IMO. It feels simple to you because you are right there now mentally, but a different user, a different time, and this becomes a burden rather than a solution.

I suggest something a little more clumsy but idiot proof: optionally pop a dialog right before the action:
Use foreground shell copy/move for this file operation? Yes/no/cancel.

admin wrote:Not simple enough IMO. It feels simple to you because you are right there now mentally, but a different user, a different time, and this becomes a burden rather than a solution.

Don't quite see why it would be a burden to a different user unless they wanted to use that binding for something else (assuming custom mouse-bindings are implemented). I grant the point about it being another one of those hidden things that people would have to learn about later. But I doubt anyone asking about it would soon forget it, since is seems a practical and appropriate auxiliary action, no less so than Shift pressed during Ctrl-Wheel changes the line spacing. (All of this pertains to my very last suggestion, Shift-Alt to produce the override menu.)

I suggest something a little more clumsy but idiot proof: optionally pop a dialog right before the action:
Use foreground shell copy/move for this file operation? Yes/no/cancel.

I guess I can live with that, though it does entail having to answer the dialog on all the occasions when I don't want to override (which are more common) -- and that does seems more clumsy to me. But at least, I deal with the dialog in the beginning and not after the operation. I suppose this dialog would take precedence over the dialog from Extended/Confirm drag and drop, if one also had that enabled (which I don't)?

Jerry wrote:

admin wrote:Not simple enough IMO. It feels simple to you because you are right there now mentally, but a different user, a different time, and this becomes a burden rather than a solution.

Don't quite see why it would be a burden to a different user unless they wanted to use that binding for something else (assuming custom mouse-bindings are implemented). I grant the point about it being another one of those hidden things that people would have to learn about later. But I doubt anyone asking about it would soon forget it, since is seems a practical and appropriate auxiliary action, no less so than Shift pressed during Ctrl-Wheel changes the line spacing. (All of this pertains to my very last suggestion, Shift-Alt to produce the override menu.)

I suggest something a little more clumsy but idiot proof: optionally pop a dialog right before the action:
Use foreground shell copy/move for this file operation? Yes/no/cancel.

I guess I can live with that, though it does entail having to answer the dialog on all the occasions when I don't want to override (which are more common) -- and that does seems more clumsy to me. But at least, I deal with the dialog in the beginning and not after the operation. I suppose this dialog would take precedence over the dialog from Extended/Confirm drag and drop, if one also had that enabled (which I don't)?

I have to think about that. Later.