Main Area and Open Discussion > General Software Discussion

Directory Opus 10

<< < (25/31) > >>

cthorpe:
If you need four panes simply to have targets to drop files into when sorting them, why not use the folder tree views?  You can lock the each tree to show whatever folder you want, and then you can drag and drop whatever you want from either pane.

Horizontal




Vertical

clean:
"and then you can drag and drop whatever you want from either pane"

OMG !

No, thank you, cthorpe, I see you try to be helpful, and I know I mix up two things here: More than just two panes, AND keyboard functionality. But then, I explain in detail why drag and drop is to be avoided, and then this (I'm sure our posts crossed by some seconds, which explains this)...

But on a more serious level, your solution isn't that practical even for drag and drop afficionados, since, as said, this "moving around files" is NOT done from one source to several target, but from "anywhere in the lot to anywhere in the lot", and that's why, e.g., tabs ain't a solution either, even with (missing!) commands like "move selection to tab 1/2/3..." - it's, as said, all about "natural working", picking this file here, moving it there, then picking another another one and moving that around. With tree views, instead of folder views, that's not possible. Thus, thanks, but no, thanks. No, it's up to these developers to have some second thoughts about what they make us miss: 2 panes only, as in Norton Commander of the Ancient Age, that's almost incredible, in view of what could easily be done instead.

cthorpe:
So you want to have a graphical interface to use keyboard shortcuts?  Why the insistence on more than 2 panes if you aren't going to utilize them in any real way?

If you want to input keyboard commands to move files into your sorting system, then create scripts in the program of your choice to do so.

Heck, you can even create the scripts inside of DO and call them via key sequences.

You clearly have a ridged set of requirements for how you are going to work with your files.  Why would you expect a file manager to understand your system and work with it, when your system is yours alone?

And if you want to move from "anywhere in the lot" to "anywhere in the lot," how many panes do you need?  At some point you are going to have to manipulate the panes to show where you want to move the files.  Once again, why demand more panes when you will just have to find the correct destination?

These developers are just too lazy to implement some 80 lines of rather simple code: It's insulting. (We're not speaking of cloning and hoisting, let alone multiple tree re-arrangements in outliners (cf. Bonsai): there, you'd need real good programming capabilities for. We're speaking of core functionality and of implementation taking 2 hours of these developers' time, make it 4 incl. debugging. Njet. Not for 100 bucks apiece. And then, as tomos says, and as others have said before, DO seems to have got some probs with images, anyway.)
--- End quote ---

80 lines of simple code?

This thread is many, many times that number of lines, and I still don't think we are all clear about what we are even arguing about.

tomos away:
tomos, I'm sorry there's been a misunderstanding.-clean (February 08, 2013, 06:16 PM)
--- End quote ---

sorry to you too clean! I probably read your post too quickly
Tom (tomos)

(ps the 'away' tag is from forgetting my password when not on my own pc - & then only having saved the 'away' account in lastpass. Have to fix that...)

Shades:
Although the NTFS file-system is fast, reliable, journalled, etc., it is also limited with the one source - one destination scenario. The Amiga home computer did this better. Likely there were more yesteryear operating systems capable of this, but I only have first hand experience with the Amiga, so I'll keep referencing to that.

Whenever you give windows the command to copy/move files by keyboard or mouse, Windows passes the job to the filesystem to do the actual work. No amount of code is going to fix that. Or GPSoftware should write their own file-system. And that is not likely going to happen or even be allowed by Microsoft. Although there might be options with multi-threading nowadays, that still means a huge revision of the existing codebase.

All I want to say is that it is most definitely not a simple case of 80 lines of code to conquer this limitation. I think that GPSoftware is doing a great job with the imposed limits that exist in the Windows operating system. Then again, you could consider me a DOpus fanboy.

Each and any Operating System has limits designed into it, there will always be someone smart to find some tricks to be as efficiently as possible with the given limits, but in the end of the day, the limits are what they are and the only solution left to the user is to work around them.

Navigation

[0] Message Index

[#] Next page

[*] Previous page