https://bugs.winehq.org/show_bug.cgi?id=42645
Bug ID: 42645 Summary: File dialog usability Product: Wine Version: 1.9.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: shell32 Assignee: wine-bugs@winehq.org Reporter: freddi34@yahoo.de Distribution: ---
When working with project files across different programs (e.g. Linux/OS X program and Windows program through Wine), users usually have to access the same locations and files. Quick file access and navigation is essential for productivity. If Wine's goal is not to be a bottom-of-the-drawer academic project, but actually useful, 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.
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) - droppable for native paths (drag&drop a folder from a native file manager, this is commonly supported in e.g. GTK) - persistent list of recently openend locations in this WINEPREFIX
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 - (native file dialogs)
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.
https://bugs.winehq.org/show_bug.cgi?id=42645
freddi34@yahoo.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |comdlg32
--- Comment #2 from freddi34@yahoo.de --- Thank you very much for your reply.
I searched through the source code and identified that dlls/comdlg32/filedlg.c and the accompanying files are related to this.
- editable address
This is only present with "newer" dialogs that we don't fully implement.
Is there ongoing work to implement these or is this something not feasible/blocked for the foreseeable future?
- 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.
The file list (shell browser) in a GTK file dialog is droppable so that you can drag and drop a file/folder from another application and make the file dialog navigate to this folder, where you can then select a file. This is faster then navigating with many clicks through the file system tree. However I just noticed this is only between GTK applications and not a more common pattern (QT file dialogs are not droppable and Windows would move a a dropped file into the folder that is already opened in the file dialog). So this suggestion is maybe not optimal.
- list of recently openend locations in this WINEPREFIX
Some bits of that are implemented I think, but probably not everything needed.
Is the ShellBrowser able to display icons/filenames for a given list of files even if these are not in a "real" directory? Then we need to find out if and where Wine keeps track of recent files and how to push them into the ShellBrowser. Some Windows file dialogs have a side panel with bookmarks etc. but I think the I think the least-invasive solution is to have a "Recent Files" toolbar button next to the "Desktop" button.
https://bugs.winehq.org/show_bug.cgi?id=42645
krasserspam@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |krasserspam@gmail.com
--- Comment #3 from krasserspam@gmail.com --- Any updates on this? I find it particularly annoying that the file dialog doesn't remember the last "state" (the folder in which the user selected before). Should I open a separate issue for that?
https://bugs.winehq.org/show_bug.cgi?id=42645
doiyhah7q@relay.firefox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |doiyhah7q@relay.firefox.com
-
wine-bugs＠winehq.org -
WineHQ Bugzilla