| [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #1086
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 3 - Moderate, e.g. unable to compile the software |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Core Library |
Summary: | FLTK's file chooser not displaying error messages from scandir() |
Version: | 1.1-current |
Created By: | greg.ercolano |
Assigned To: | AlbrechtS |
Fix Version: | 1.4.0 |
Fix Commit: | 54425030774eb04b29c749ffa85d224c8bbfcc34 |
Update Notification: | |
Trouble Report Files:
Trouble Report Comments:
|
#1 | greg.ercolano 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. | |
|
#2 | greg.ercolano 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. | |
|
#3 | AlbrechtS 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)? | |
|
#4 | greg.ercolano 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:
mkdir /tmp/junkdir 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. | |
|
#5 | greg.ercolano 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. | |
|
#6 | fabien 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. | |
|
#7 | AlbrechtS 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.
Todo:
- 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?
See also: https://github.com/Albrecht-S/fltk/commit/6b4135563b5917f03f9e6e3ba0f1ab2d563b01a6
Feel free to pull from this repo and continue working (instead of applying the patch). New Git world... ;-) | |
|
#8 | AlbrechtS 03:15 Feb 17, 2019 |
| FTR so it doesn't get lost: see discussion in fltk.coredev [1], particularly Greg's post [2]:
"... 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.
[1] https://groups.google.com/d/msg/fltkcoredev/YBb7Ei3c0XA/KO_sGXUsAwAJ [2] https://groups.google.com/d/msg/fltkcoredev/YBb7Ei3c0XA/ExYwSWA-AwAJ | |
|
#9 | AlbrechtS 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: https://github.com/fltk/fltk/pull/99 | |
|
#10 | AlbrechtS 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'.
https://github.com/fltk/fltk/pull/99 https://github.com/fltk/fltk/pull/103 | |
|
#11 | AlbrechtS 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.
Closed. | |
[ Return to Bugs & Features ]
|
| |