https://bugs.winehq.org/show_bug.cgi?id=42645
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement Component|shell32 |-unknown
--- Comment #1 from Nikolay Sivov bunglehead@gmail.com --- (In reply to freddi34 from comment #0)
If Wine's goal is not to be a bottom-of-the-drawer academic project, but actually useful,
Don't do that. This is not your homepage.
it must sufficiently integrate with the non-Windows desktop that its users are using.
Example workflow:
A 1. Native file manager (e.g. Nautilus) is opened at /home/username/folder1 2. User wants to open file1.ext from this folder in a Wine program through the file open dialog.
B 1. User creates a file2.ext in a Wine program, opens the file save dialog and wants to save it in the same location (folder1). 2. File save dialog is opened at a path deep in the virtual C: drive (C:/Programs/Manufacturer/ProgramName/client/assets/.../...). The file save dialog's location may be controlled by the Windows application or where it was opened the last time.
Wine's file open/save dialog has significantly worse usability than any GTK/KDE/OS X file dialog or even Windows' own.
- It is more likely not opened where the user needs it (since working
cross-system)
- Navigation is only possible by one step up (green up arrow button) or by
going multiple steps up towards the file system root (scrollable dropdown) and then navigating step by step down in the native system's file tree.
- Double-click is cumbersome and leads repeatedly to accidental renamings or
wrong selections.
We have a policy of having a single issue per bug report, please split these to separate reports, if they haven't been reported earlier.
Wine's open/save dialogs should allow faster changing between commonly used locations. This should be supported through:
- editable address (would allow to paste a complete path and press enter)
This is only present with "newer" dialogs that we don't fully implement.
- droppable for native paths (drag&drop a folder from a native file manager,
this is commonly supported in e.g. GTK)
I can't comment on that.
- persistent list of recently openend locations in this WINEPREFIX
Some bits of that are implemented I think, but probably not everything needed.
While these are platform-agnostic, more comfort can be achieved by further integrating with the desktop (Gnome/KDE/OS X):
- integrate with the desktop's bookmarks through Free Desktop Standard
- integrate with the desktop's recent locations
If you know how this reflects on Windows common dialogs, please open a separate bug for that, if it does not work already.
- (native file dialogs)
That's unlikely to ever happen.