manuel wrote:In the current Reactos's explorer not display papers flying animation when the files are copied, i attach a screenshot, greetings. [ external image ]
The above posting snapped up something for me to suggest: The file progress dialog could be expanded to include more advanced features such as:
The ability to pause the file operation (button title: "Pause"/"Resume")
Show the current speed of the operation (e.g. 4MB/sec)
A graph showing how the speed changes over time (like the one found in Windows 8 and later, but does not have to clone its appearance)
Continue file operations even if they encounter an error (Excludes "disk full" and "permission denied" errors)
Option for not automatically closing the operation window (so the user can review what happened)
Multiple file operations in one window
For the above feature, either checkmarks for each operation with a "Select" button, or "Pause All" or "Cancel All" buttons for managing multiple operations at once.
By implementing two or more of these items, this makes ReactOS look like it backports the good features from newer software while retaining an elder but familiar look and feel, without forcing people to always go on a learning curve.
Last edited by WorldBlender on Thu Apr 23, 2015 1:31 am, edited 1 time in total.
Are interesting observations, but personally I dont like the windows 8 dialog to show the speed variations copying files, all other features would be interesting to be implemented, greetings.
I don't disagree that the file dialog isn't perfect or even ideal (and I wrote it). However:
The file dialog is created by SHFileOperation, which is not the most powerful function and lacks a lot of the features which would be required. The file dialog itself is implemented in BrowseUI's IProgressDialog which has a lot of limitations also (there's only 3 available locations for text, one of which is taken up by the time remaining indicator).
If we want a better file dialog and copy experience we'll have to move to IFileOperation and IOperationsProgressDialog, neither of which have started being implemented.
Ah, so we'll have to wait until IFileOperation and IOperationsProgressDialog are implemented before I see one of those features appear? I'm guessing that those two classes are also more flexible and extensible as well?
The file dialog is created by SHFileOperation, which is not the most powerful function and lacks a lot of the features which would be required. The file dialog itself is implemented in BrowseUI's IProgressDialog which has a lot of limitations also (there's only 3 available locations for text, one of which is taken up by the time remaining indicator).
Keep them and implement ReactOS specific ones additionally.
-uses Ubuntu+GNOME 3 GNU/Linux
-likes Free (as in freedom) and Open Source Detergents
-favors open source of Windows 10 under GPL2
WorldBlender wrote:Ah, so we'll have to wait until IFileOperation and IOperationsProgressDialog are implemented before I see one of those features appear? I'm guessing that those two classes are also more flexible and extensible as well?
That's correct. They're also probably not *that* hard to get something going with, as they seem to be better designed than SHFileOperation. If there's any volunteers I'm more than happy to give tips and help a bit.
I imagine what the purpose is maintain the compatibility of old copy/move/delete dialog but implement other more modern too, that is OK, but isn't work two or three times in the same?, i not know the source code of reactos, but by what I'm reading the same dialog box exists in SHFileOperation, BrowseUI and now also the IFileOperation and IOperationsProgressDialog functions are required if you require something more modern.
Not be better have the function SHFileOperation with optional parameters and the programs that use if not passing these parameters then these begin with default values, so compatibility with existing software, but if certain parameters are passed then it is possible activate new functions, BrowseUI should inherit this source to reduce source code and speed the development. is a suggestion because I know the source code of reactos, greetings.
The file dialog is created by SHFileOperation, which is not the most powerful function and lacks a lot of the features which would be required. The file dialog itself is implemented in BrowseUI's IProgressDialog which has a lot of limitations also (there's only 3 available locations for text, one of which is taken up by the time remaining indicator).
Keep them and implement ReactOS specific ones additionally.
He means we won't have ROS-specific APIs to do things.
Sure, a fork project might want to do something like that, and have its own way of doing things internally, but also have the "official" way of doing it too for the other software. But the problem is that things could get messy. Like how would the nonstandard functions know when to yield to the standard functions when the user decides to run a 3rd party app, and then pass the control back to the nonstandard stuff when it is done? I guess they could be written to coexist peacefully and share the same data structures, but even that sounds like it could invite bugs.
While anyone is free to experiment around with the above methods, we have to keep in mind that ROS is nowhere close to finished, and thus the best approach as this point would be the "KISS approach," meaning "Keep It Simple Silly" (this is a politer variation).
WorldBlender wrote:Ah, so we'll have to wait until IFileOperation and IOperationsProgressDialog are implemented before I see one of those features appear? I'm guessing that those two classes are also more flexible and extensible as well?
We are no Windows 6.0 aka Vista, we are 5.2 aka Win2003 SP1. Thus we have to stay API compatible completely unless we wanna risk to kill apps which already run.
ReactOS is still in alpha stage, meaning it is not feature-complete and is recommended only for evaluation and testing purposes.
If my post/reply offends or insults you, be sure that you know what sarcasm is...
Extensions will not break compatibility as long as we do not interfere with ABI and regular API's behavior. It is the programmers' fault if they use wrong way of feature detection. GNU did many extensions on Unix staying source, and to a limited extent, binary compatible.
-uses Ubuntu+GNOME 3 GNU/Linux
-likes Free (as in freedom) and Open Source Detergents
-favors open source of Windows 10 under GPL2