Failures opening files provided as app arguments are not reflected in the UI

[mqudsi]

Describe the bug

If an attempt to open a (supported or unsupported) file via f3d by double-clicking on the file path or otherwise opening using the window manager facilities to open the path with f3d fails, the f3d ui loads normally but with a blank canvas and no errors are shown. The error is only posted to stderr, but if f3d was launched via the window manager instead of from the terminal, stderr is hidden and the user is unaware that any error took place.

To Reproduce
Steps to reproduce the behavior:

1. Instead of opening the file using f3d --dry-run example.glb, open an unsupported file by using your window manager's facilities for opening a file with a specific gui application
2. Observe that f3d opens but no file is loaded and no error is shown

Expected behavior

Any errors attempting to open a file at startup via command line arguments should result in a blocking dialog, a message box, or some other error display mechanism that reflects the error in the GUI (in addition to the error being printed to stderr). f3d should not assume that stderr is visible, or that even if stderr is visible that the user is monitoring it for output.

System Information:

• OS: Ubuntu 23.04
• GPU and GPU driver: N/A

F3D Information
Paste the content of f3d --version:

f3d 1.3.1

F3D - A fast and minimalist 3D viewer
Version: 1.3.1.
Build date: 2022-11-06 13:17:51.
Build system: Linux.
Compiler: GNU 12.2.0.
External rendering module: OFF.
Raytracing module: OFF.
Exodus module: ON.
OpenCASCADE module: 7.6.3 (full support).
Assimp module: 5.2.4.
Alembic module: OFF.
VTK version: 9.1.0 (build 0).
Copyright (C) 2019-2021 Kitware SAS.
Copyright (C) 2021-2022 Michael Migliore, Mathieu Westphal.
License BSD-3-Clause.
By Michael Migliore, Mathieu Westphal and Joachim Pouderoux.

Additional context

In this example and for reproduction purposes, I have recommended opening an unsupported file type with the window manager. However, this issue was actually encountered trying to open a supported file type but from a mount type that is not supported for unknown reasons, so it is not as contrived as it seems.

An HN comment suggests that this functionality is blocking on the feature to add a log output dialog to f3d. I want to argue against this from two different perspectives:

• A log output is not required in order to show simple, fatal errors taking actions (such as loading a file)
• A log output even if implemented does not take the place of showing a blocking dialog in the main app conveying the critical/fatal error information to the user. A log dialog should be treated a source of supplemental information but should not be considered part of the core UX feedback loop. For definitive (not asynchronous, not deferred, not supplemental, not incidental) actions, an error acting out on the user's command should be considered a fatal process requiring blocking UI feedback to the user.

[mwestphal]

f3d should not assume that stderr is visible, or that even if stderr is visible that the user is monitoring it for output.

We (the maintainers) definitely agree. Is is planned to be implemented it in the context of integrating imGui in F3D, but this is a lot of work.

Related issue: #29