Test programs that open files don't use platform specific code.
They don't open files from macOS bundles.
Support files must either be in the current working directory or
given on the command line.
On macOS this requires a full path when using bundles.
LDFLAGS often contains "-L*" flags as provided outside the build to tell the linker where to search for libraries. If these are included -before- the ones used for internal linkage as found in LINKSHARED, and FLTK is already installed on the system, then the already-installed FLTK libraries will be found before those internal to the build. Moving the LDFLAGS after LINKSHARED generally solves this issue. Worst case the move won't hurt linking since all of the flags are still included in the link command.
Now bundle wrapper scripts are created in the particular build folder,
i.e. in subdir 'Debug', 'Release' etc. in multi config builds (Xcode).
To do this, the scripts are now copied whenever the target is built
and not during the configuration phase.
To do: "install" wrapper scripts.
Fl_File_Chooser's "Add Favorite" function wasn't including the
Alt-N shortcut when initially added. Now just calls update_favorites()
to rebuild the menu with proper shortcut numbering.
When Mike proposed Fl_File_Chooser, he included a list of features
in the voting contest: https://www.fltk.org/contest.php
Seemed like a good idea to include these in the widget's docs.
Allows and preserves unix style paths if user specifies them,
otherwise uses Windows style. This allows end users to use either
style path and get behavior they expect in cross-platform environments.
Addresses problems raised by issue #122
- dasharray_ can never be NULL unless if memory allocation failed
previously
- if dasharray_ was NULL, the previous strcmp() would have crashed
anyway (but it can't be NULL, see above)
These unused typedefs are not used anywhere and should not be defined
at all.
Remove typedef 'Fl_String' as decided in fltk.coredev.
Remove typedef 'Fl_CString' as well for the same reason.
- create subdir test/images
- copy images used by test/help_dialog to this subdir
- fix image URL's in test/help_dialog.html accordingly
CMake: copy the entire test/images folder to the <build>/data folder
This enables the demo test/help_dialog.cxx to find its images.
Resources like demo.menu and help_dialog.html are no longer read
from the bundle directory on macOS. They are read from the build
folder build/data or in case of classic autoconf/make builds from
the source directory. We don't need to copy the files into the
bundle folder, they are copied to the build/data folder on all
platforms anyway.
Albrecht:
- move fl_chdir(data_path) up before fl_getcwd() prints it
- add statements to open the argument (i.e. file) with data_path
- update comments, remove obsolete code
Greg:
- on Mac we need absolute path for child filename parameters
This is an attempt to unify the code for all build systems (CMake,
autotools with make), platforms (operating systems) and toolchains
(make + gcc/clang, Visual Studio IDE, Xcode ...) to avoid duplicate
code and clarify the differences for future devs and to simplify
maintenance.
The goal is to minimize the platform specific code.
Much of the new code are comments to describe the different situations.
The main program does now all the "hard work" to construct the paths
necessary to access the other applications and data files.
Use macOS specific code to determine the application path (app_path)
in main() instead of function dobut(), when test apps are activated.
Remove obsolete comments and dead code.
Tested on Windows and Linux with both autotools/configure/make
and CMake with make (Linux + MinGW), Visual Studio.
- move target (demo) specific code from macro to CMakeLists.txt
- refactor macOS specific code for a cleaner structure
- improve documentation
Note: CMake ignores platform specific code like creating bundles on
other platforms, hence the entire code could be simplified (less
conditional code)
A previous commit c66caf5dce
"Simpler implementation of Fl_Cocoa_Window_Driver::resize()"
made that Fl_Window::resize() was no longer called by FLTK when a
window is moved. This prevented the undocumented practice of
re-implementing the virtual function Fl_Window::resize() and use it
as a way to get a notification that a window was moved.
Albrecht Schlosser