[ Return to Bugs & Features | Roadmap 1.1 ]
|Status:||1 - Closed w/Resolution|
|Priority:||3 - Moderate, e.g. unable to compile the software|
|Scope:||3 - Applies to all machines and operating systems|
|Summary:||FLTK's file chooser not displaying error messages from scandir()|
Trouble Report Files:
Trouble Report Comments:
23:12 Nov 18, 2005
|FLTK's file chooser needs to report errors from underlying functions such as scandir(). |
When trying to browse a directory that can't be viewed (due to lack of access permissions, or other), an empty browser is shown, instead of the error message.
In one case, the user was trying to browse a 64 bit remote file system from a 32 bit linux box, and the scandir() function was returning the useful error:
Value too large for defined data type
..but the error was not displayed.
It would be best if the scandir() function [and other system calls the browser uses] would report errors back to the user.
23:14 Nov 18, 2005
|Followup: Bill's older file browser would show such errors in the browser area where directory listings are normally displayed, which I think is a good solution. |
Definitely I would advise against posting a dialog, as the user is already in a dialog, and the potential for several instances to occur during typing and completion would be really bad.
08:31 Feb 12, 2019
|I "found" this ancient STR having been unnoticed because the "Application:" field was empty. |
I assigned "FLTK Library" but now we have an open STR for FLTK 1.1 which is somewhat strange.
Can anybody (maybe Greg, the OP) tell if this is still relevant (in 1.4, of course) or if we should close this STR with software version "1.1-current" (i.e. as-is)?
09:08 Feb 12, 2019
|Apparently the problem still exists as I see it with 1.4.x: |
1) Create an empty dir with no permission access:
touch /tmp/junkdir/a /tmp/junkdir/b
chmod 0 /tmp/junkdir
2) As a non-root user, run test/file_chooser and browse
to /tmp, and then double click on 'junkdir'.
Select Show: All Files (*)
3) An empty window is shown for /tmp/junkdir/
as if it was empty.
10:20 Feb 12, 2019
|Attaching image comparing Old, 1.4 chooser, and 1.4 Native (FNFC). |
IMHO the older chooser is best; shows the error in the window where
the files would appear, so it's clear the dir has an error.
I dislike the separate error dialog for many reasons:
o It breaks the user's workflow/focus when browsing large trees
that may potentially have many such errors.. an extra
drag/click/drag to get back to browsing
o After clicking away the dialog, you're left with a browser
window that is empty, when it could be still showing the error
When working at a large company, it's not unusual to browse deep
directory trees, often encountering dead directory links, or dirs
you either don't have permission to, or are unmounted while searching
for the file you're looking for.
Encountering dirs with lots of errors is not something most
home users run into much, but it happens at large companies a lot.
11:29 Feb 12, 2019
|When fixing this, we should consider adding a status bar; instead of using the file/folder view content for error messaging purpose but it seems to contradict the the single responsibility design principle for the view content. ||
10:13 Feb 16, 2019
|Attached is a proof of concept for FLTK 1.4.0: proof-of-concept_v0.diff. |
I followed the idea to add an invisible box that overlays the file browser to show an error message when appropriate. Commit message:
--- snip ---
Add error message to file chooser (POC, STR 1086)
This commit adds a dynamic error display box with a constant string
("No files found ...") if a directory scan yields no files or maybe
an error status -1. The latter is NOT implemented.
This is only a proof of concept. The invisible errorBox is shown and
hidden dynamically as requested and its label can be filled with an
arbitrary error message.
- check if resizing works as expected
- get error status / message and display it
The latter may be system dependent, in driver code.
--- snip ---
Note: I don't intend to work further on this issue. Maybe someone else can do the system specific error message stuff - or we can use it as-is with minor tweaks?
Feel free to pull from this repo and continue working (instead of applying the patch). New Git world... ;-)
03:15 Feb 17, 2019
|FTR so it doesn't get lost: see discussion in fltk.coredev , particularly Greg's post : |
"... wouldn't it be easier to just splash an error message over
the viewer? e.g. a hidden Fl_Box that appears only when an error
occurs? Would save on screen real estate, and would put the error
where the user's eyes are during browsing.
In the old browser example, I'd probably have made the error message
a dark red instead of just slightly gray, to prevent it from being
mistaken as a filename."
My proof of concept uses the hidden box and the text in red color.
15:17 Jul 09, 2020
|Note: I created a Pull Request (PR #99) with a current version of patch "proof-of-concept_v0.diff". |
I suggest to continue discussion on GitHub:
05:09 Jul 14, 2020
|See also the follow-up PR #103 on GitHub with the (hopefully) final branch 'issue-99a' which is intended to be merged into 'master'. |
14:37 Jul 14, 2020
|Fixed in Git repository. |
The solution was a coordinated work of Greg and me, see the discussion in GitHub PR's #99 and #103 mentioned above.
This STR was fixed with the merge commit 54425030774eb04b29c749ffa85d224c8bbfcc34 which included several commits in the final working branch (issue-99a : deleted).
Error messages in international languages can be presented in the file chooser window.
[ Return to Bugs & Features ]