STR #1086

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Return to Bugs & Features | Roadmap 1.1 ]

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()
Created By:greg.ercolano
Assigned To:AlbrechtS
Fix Version:1.4.0
Fix Commit:54425030774eb04b29c749ffa85d224c8bbfcc34
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Name/Time/Date Filename/Size top right image
#1 greg.ercolano
07:22 Nov 19, 2005
#2 greg.ercolano
10:20 Feb 12, 2019
#3 AlbrechtS
10:13 Feb 16, 2019
bottom left image   bottom right image

Trouble Report Comments:

Name/Time/Date Text top right image
#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.


 - 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:

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.

#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:
#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'.
#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.

bottom left image   bottom right image

Return to Bugs & Features ]


Comments are owned by the poster. All other content is copyright 1998-2022 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.