| |
| |
On 8/15/20 2:38 AM Greg Ercolano wrote:
Error
Unable to follow the link "bin/help_dialog.app/Contents/MacOS/../Resources/help_dialog.html" - No such file or directory.
Well, this is still some macOS specific code that assumes that the
support file (in this case 'help_dialog.html') is in the bundle's
Resources folder, but we don't do this anymore since the redesign of the
test/demo app and introduction of the data/ directory.
I'm not sure what to suggest to fix this.
Could cmake add a special mac build step that on creation of the app,
also creates the help_dialog.app/Contents/Resources subdir and copies
the html file into it?
Been there, done that, didn't work (in parts), removed that recently.
The point is that we'd need to copy *all* support files into the bundle
dirs *and* into the new data/ dir for other platforms.
Since Resources I think is how Apple suggests packaging files
that an app depends on (along with icons, language files, config files, etc)
I expect we should try to preserve this for the demo.
test/demo and others are meant to test FLTK widgets and more. They are
not primarily examples to show the *user* how things can be done.
Maybe we could add something like this in the examples/ folder?
Although we could fix the issue on macOS by packaging all support files
in their respective bundles this wouldn't solve the issue for any other
platform
For the other platforms, I suppose we could just have a data subdir
and the executable's code could use, pseudocode:
htmlfile = directory(argv[0]) + "/data/help_dialog.html"
..with the directory hierarchy being:
<build>/bin/help_dialog.exe
<build>/bin/data/help_dialog.html
And if we wanted to standardize this across all platforms, then
there wouldn't need to be #ifdef's in the code.
Been there, done that. Works on all platforms including macOS.
This was my recent redesign of the CMake build of our test programs to
make test/demo.cxx work with CMake on all platforms with less #ifdef's
in the code. Sounds familiar???
Works on all platforms including macOS - when running the executables
from the demo app which uses appropriate commandline arguments.
There's only a minor difference: the 'data' subdir is not *inside* the
'bin' directory but at the same level. Truncated tree view below:
├── bin
│ ├── examples subdir with examples/* apps, if enabled
│ │ ├── browser-simple
│ │ └── ···
│ ├── fltk-config (script)
│ ├── fluid (executable)
│ └── hello + all the other test executables ...
├── data
│ ├── browser.cxx
│ ├── demo.menu
│ ├── editor.cxx
│ ├── help_dialog.html
│ ├── images
│ │ ├── FL200.png
│ │ ├── Fl_Value_Input.png
│ │ ├── Fl_Value_Output.png
│ │ └── tiny.png
│ ├── rgb.txt
│ └── valuators.fl
...
The data/images folder is required for help_dialog. I had to change
help_dialog.cxx to make this work for both autoconf/make which runs
fltk/test/help_dialog and for CMake which runs build/bin/help_dialog
e.g. on Linux or for instance build/bin/Debug/help_dialog.exe when using
VS or Xcode. It's more complicated than one would believe at a first
glance...
It does NOT work though on *any* platform if you run the
executable/wrapper/bundle w/o a commandline argument. Making this work
would require much more work in *all* test programs that need to read an
input file (like browser, editor, colbrowser, fluid(!), etc.) with macOS
platform (bundle) specific code which makes the test programs more
complicated than necessary.
Thing is it /might/ be good that at least one app shows the
"Apple way", which means creating the Resources subdir and copying
the file into it.
I agree, but IMHO this should be an example program in the examples
folder. We do have (limited) support for putting file into macOS bundles
in our CMake macro 'CREATE_EXAMPLE', but this is hard to understand for
new users. It would probably be better to do this with a single app in
its own folder (or subfolder in examples) that shows the "Apple way" to
build a bundle and the equivalent application in a cross-platform way.
This could be the topic of a separate tutorial "how to build a macOS
bundle" or something like that.
PS: if I interpret the macOS bundle "Resources" folder correctly (just
by its name) it should hold resources required to run the program rather
than files the program would "open to read and work with". Therefore I
wouldn't consider 'help_dialog.html' and the images to be *resources*.
OTOH I would consider 'demo.menu' a resource of demo.cxx/.app - although
you can also open another menu file with the demo app. Preference files
you want to bundle with your app might be another good example of
"resources". -- But that's kinda nitpicking, just to make clear what I
would consider resources and what not. But I may be totally wrong.
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/4bd2f01b-bce0-dd99-1bfc-0f1b93c89b33%40online.de.
[ Direct Link to Message ] | |
|
| |
