zcy
/
solvespace
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
solvespace/res/CMakeLists.txt

298 lines
11 KiB
CMake
Raw Normal View History

Implement a resource system. Currently, icons, fonts, etc are converted to C structures at compile time and are hardcoded to the binary. This presents several problems: * Cross-compilation is complicated. Right now, it is necessary to be able to run executables for the target platform; this happens to work with wine-binfmt installed, but is rather ugly. * Icons can only have one resolution. On OS X, modern software is expected to take advantage of high-DPI ("Retina") screens and use so-called @2x assets when ran in high-DPI mode. * Localization is complicated. Win32 and OS X provide built-in support for loading the resource appropriate for the user's locale. * Embedding strings can only be done as raw strings, using C++'s R"(...)" literals. This precludes embedding sizable strings, e.g. JavaScript libraries as used in Three.js export, and makes git history less useful. Not embedding the libraries means we have to rely on external CDNs, which requires an Internet connection and adds a glaring point of failure. * Linux distribution guidelines are violated. All architecture- independent data, especially large data such as fonts, is expected to be in /usr/share, not in the binary. * Customization is impossible without recompilation. Minor modifications like adding a few missing vector font characters or adjusting localization require a complete development environment, which is unreasonable to expect from users of a mechanical CAD. As such, this commit adds a resource system that bundles (and sometimes builds) resources with the executable. Where they go is platform-dependent: * on Win32: into resources of the executable, which allows us to keep distributing one file; * on OS X: into the app bundle; * on other *nix: into /usr/share/solvespace/ or ../res/ (relative to the executable path), the latter allowing us to run freshly built executables without installation. It also subsides the platform-specific resources that are in src/. The resource system is not yet used for anything; this will be added in later commits.
2016-04-21 15:54:18 +00:00
# First, set up registration functions for the kinds of resources we handle.
set(resource_root ${CMAKE_CURRENT_SOURCE_DIR}/)
set(resource_list)
if(WIN32)
Cocoa, Win32: embed version info into distributable application. This shows up in crash dumps, etc, and helps track them back to a git commit.
2016-06-02 02:18:29 +00:00
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/win32/versioninfo.rc.in
${CMAKE_CURRENT_BINARY_DIR}/win32/versioninfo.rc)
Implement a resource system. Currently, icons, fonts, etc are converted to C structures at compile time and are hardcoded to the binary. This presents several problems: * Cross-compilation is complicated. Right now, it is necessary to be able to run executables for the target platform; this happens to work with wine-binfmt installed, but is rather ugly. * Icons can only have one resolution. On OS X, modern software is expected to take advantage of high-DPI ("Retina") screens and use so-called @2x assets when ran in high-DPI mode. * Localization is complicated. Win32 and OS X provide built-in support for loading the resource appropriate for the user's locale. * Embedding strings can only be done as raw strings, using C++'s R"(...)" literals. This precludes embedding sizable strings, e.g. JavaScript libraries as used in Three.js export, and makes git history less useful. Not embedding the libraries means we have to rely on external CDNs, which requires an Internet connection and adds a glaring point of failure. * Linux distribution guidelines are violated. All architecture- independent data, especially large data such as fonts, is expected to be in /usr/share, not in the binary. * Customization is impossible without recompilation. Minor modifications like adding a few missing vector font characters or adjusting localization require a complete development environment, which is unreasonable to expect from users of a mechanical CAD. As such, this commit adds a resource system that bundles (and sometimes builds) resources with the executable. Where they go is platform-dependent: * on Win32: into resources of the executable, which allows us to keep distributing one file; * on OS X: into the app bundle; * on other *nix: into /usr/share/solvespace/ or ../res/ (relative to the executable path), the latter allowing us to run freshly built executables without installation. It also subsides the platform-specific resources that are in src/. The resource system is not yet used for anything; this will be added in later commits.
2016-04-21 15:54:18 +00:00
set(rc_file ${CMAKE_CURRENT_BINARY_DIR}/resources.rc)
Win32: fix inclusion of manifest, to get back visual styles. This commit fixes four issues: * Instead of WRITE,APPEND, resource.rc was generated using WRITE,WRITE, which erased #include <windows.h> and prevented any symbolic definitions (like RT_MANIFEST) from working. This silently included them using a string type instead, which did nothing. * WINVER is bumped to Win7, since that's what we target now. * Index of RT_MANIFEST is changed to 2, since that's what it has to be when ISOLATION_AWARE_ENABLED is defined. * Platform is not restricted to X86 in manifest, since there is no point in doing so.
2016-12-04 20:16:05 +00:00
file(WRITE ${rc_file} "// Autogenerated; do not edit\n")
file(APPEND ${rc_file} "#include <windows.h>\n")
file(APPEND ${rc_file} "#include \"${CMAKE_CURRENT_BINARY_DIR}/win32/versioninfo.rc\"\n")
Implement a resource system. Currently, icons, fonts, etc are converted to C structures at compile time and are hardcoded to the binary. This presents several problems: * Cross-compilation is complicated. Right now, it is necessary to be able to run executables for the target platform; this happens to work with wine-binfmt installed, but is rather ugly. * Icons can only have one resolution. On OS X, modern software is expected to take advantage of high-DPI ("Retina") screens and use so-called @2x assets when ran in high-DPI mode. * Localization is complicated. Win32 and OS X provide built-in support for loading the resource appropriate for the user's locale. * Embedding strings can only be done as raw strings, using C++'s R"(...)" literals. This precludes embedding sizable strings, e.g. JavaScript libraries as used in Three.js export, and makes git history less useful. Not embedding the libraries means we have to rely on external CDNs, which requires an Internet connection and adds a glaring point of failure. * Linux distribution guidelines are violated. All architecture- independent data, especially large data such as fonts, is expected to be in /usr/share, not in the binary. * Customization is impossible without recompilation. Minor modifications like adding a few missing vector font characters or adjusting localization require a complete development environment, which is unreasonable to expect from users of a mechanical CAD. As such, this commit adds a resource system that bundles (and sometimes builds) resources with the executable. Where they go is platform-dependent: * on Win32: into resources of the executable, which allows us to keep distributing one file; * on OS X: into the app bundle; * on other *nix: into /usr/share/solvespace/ or ../res/ (relative to the executable path), the latter allowing us to run freshly built executables without installation. It also subsides the platform-specific resources that are in src/. The resource system is not yet used for anything; this will be added in later commits.
2016-04-21 15:54:18 +00:00
function(add_resource name)
set(source ${CMAKE_CURRENT_SOURCE_DIR}/${name})
CMake: correctly define and use the add_resource function.
2016-05-18 11:22:07 +00:00
if(${ARGC} GREATER 1)
set(id ${ARGV1})
else()
Implement a resource system. Currently, icons, fonts, etc are converted to C structures at compile time and are hardcoded to the binary. This presents several problems: * Cross-compilation is complicated. Right now, it is necessary to be able to run executables for the target platform; this happens to work with wine-binfmt installed, but is rather ugly. * Icons can only have one resolution. On OS X, modern software is expected to take advantage of high-DPI ("Retina") screens and use so-called @2x assets when ran in high-DPI mode. * Localization is complicated. Win32 and OS X provide built-in support for loading the resource appropriate for the user's locale. * Embedding strings can only be done as raw strings, using C++'s R"(...)" literals. This precludes embedding sizable strings, e.g. JavaScript libraries as used in Three.js export, and makes git history less useful. Not embedding the libraries means we have to rely on external CDNs, which requires an Internet connection and adds a glaring point of failure. * Linux distribution guidelines are violated. All architecture- independent data, especially large data such as fonts, is expected to be in /usr/share, not in the binary. * Customization is impossible without recompilation. Minor modifications like adding a few missing vector font characters or adjusting localization require a complete development environment, which is unreasonable to expect from users of a mechanical CAD. As such, this commit adds a resource system that bundles (and sometimes builds) resources with the executable. Where they go is platform-dependent: * on Win32: into resources of the executable, which allows us to keep distributing one file; * on OS X: into the app bundle; * on other *nix: into /usr/share/solvespace/ or ../res/ (relative to the executable path), the latter allowing us to run freshly built executables without installation. It also subsides the platform-specific resources that are in src/. The resource system is not yet used for anything; this will be added in later commits.
2016-04-21 15:54:18 +00:00
string(REPLACE ${resource_root} "" id ${source})
endif()
CMake: correctly define and use the add_resource function.
2016-05-18 11:22:07 +00:00
if(${ARGC} GREATER 2)
set(type ${ARGV2})
else()
Implement a resource system. Currently, icons, fonts, etc are converted to C structures at compile time and are hardcoded to the binary. This presents several problems: * Cross-compilation is complicated. Right now, it is necessary to be able to run executables for the target platform; this happens to work with wine-binfmt installed, but is rather ugly. * Icons can only have one resolution. On OS X, modern software is expected to take advantage of high-DPI ("Retina") screens and use so-called @2x assets when ran in high-DPI mode. * Localization is complicated. Win32 and OS X provide built-in support for loading the resource appropriate for the user's locale. * Embedding strings can only be done as raw strings, using C++'s R"(...)" literals. This precludes embedding sizable strings, e.g. JavaScript libraries as used in Three.js export, and makes git history less useful. Not embedding the libraries means we have to rely on external CDNs, which requires an Internet connection and adds a glaring point of failure. * Linux distribution guidelines are violated. All architecture- independent data, especially large data such as fonts, is expected to be in /usr/share, not in the binary. * Customization is impossible without recompilation. Minor modifications like adding a few missing vector font characters or adjusting localization require a complete development environment, which is unreasonable to expect from users of a mechanical CAD. As such, this commit adds a resource system that bundles (and sometimes builds) resources with the executable. Where they go is platform-dependent: * on Win32: into resources of the executable, which allows us to keep distributing one file; * on OS X: into the app bundle; * on other *nix: into /usr/share/solvespace/ or ../res/ (relative to the executable path), the latter allowing us to run freshly built executables without installation. It also subsides the platform-specific resources that are in src/. The resource system is not yet used for anything; this will be added in later commits.
2016-04-21 15:54:18 +00:00
set(type RCDATA)
endif()
file(SHA512 "${source}" hash)
file(APPEND ${rc_file} "${id} ${type} \"${source}\" // ${hash}\n")
# CMake doesn't track file dependencies across directories, so we force
# a reconfigure (which changes the RC file because of the hash above)
# every time a resource is changed.
set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS "${source}")
endfunction()
elseif(APPLE)
Add apple arm64 support
2021-02-08 00:07:21 +00:00
set(app_resource_dir ${CMAKE_BINARY_DIR}/Resources)
Use the same code for loading resources in all executables. All of our executables need resources; e.g. the vector font is a resource and it is necessary for generation. Before this commit, the GUI executable loaded the resources in a nice way, and everything else did it in a very ad-hoc, fragile way. After this commit, all executables are placed in <build>/bin and follow the same algorithm: * On Windows, resources are compiled and linked into every executable. * On Linux, resources are copied into <build>/res (which is tried first) and <prefix>/share/solvespace (which is tried second). * On macOS, resources are copied into <build>/res (which is tried first) and <build>/bin/solvespace.app/Contents/Resources (which is tried second). In practice this means that we can add as many executables as we want without duplicating lots of code. In addition, on macOS, we can place supplementary executables into the bundle, and they can use resources from the bundle transparently.
2016-11-28 04:16:18 +00:00
set(cli_resource_dir ${CMAKE_BINARY_DIR}/res)
Implement a resource system. Currently, icons, fonts, etc are converted to C structures at compile time and are hardcoded to the binary. This presents several problems: * Cross-compilation is complicated. Right now, it is necessary to be able to run executables for the target platform; this happens to work with wine-binfmt installed, but is rather ugly. * Icons can only have one resolution. On OS X, modern software is expected to take advantage of high-DPI ("Retina") screens and use so-called @2x assets when ran in high-DPI mode. * Localization is complicated. Win32 and OS X provide built-in support for loading the resource appropriate for the user's locale. * Embedding strings can only be done as raw strings, using C++'s R"(...)" literals. This precludes embedding sizable strings, e.g. JavaScript libraries as used in Three.js export, and makes git history less useful. Not embedding the libraries means we have to rely on external CDNs, which requires an Internet connection and adds a glaring point of failure. * Linux distribution guidelines are violated. All architecture- independent data, especially large data such as fonts, is expected to be in /usr/share, not in the binary. * Customization is impossible without recompilation. Minor modifications like adding a few missing vector font characters or adjusting localization require a complete development environment, which is unreasonable to expect from users of a mechanical CAD. As such, this commit adds a resource system that bundles (and sometimes builds) resources with the executable. Where they go is platform-dependent: * on Win32: into resources of the executable, which allows us to keep distributing one file; * on OS X: into the app bundle; * on other *nix: into /usr/share/solvespace/ or ../res/ (relative to the executable path), the latter allowing us to run freshly built executables without installation. It also subsides the platform-specific resources that are in src/. The resource system is not yet used for anything; this will be added in later commits.
2016-04-21 15:54:18 +00:00
function(add_resource name)
set(source ${CMAKE_CURRENT_SOURCE_DIR}/${name})
Use the same code for loading resources in all executables. All of our executables need resources; e.g. the vector font is a resource and it is necessary for generation. Before this commit, the GUI executable loaded the resources in a nice way, and everything else did it in a very ad-hoc, fragile way. After this commit, all executables are placed in <build>/bin and follow the same algorithm: * On Windows, resources are compiled and linked into every executable. * On Linux, resources are copied into <build>/res (which is tried first) and <prefix>/share/solvespace (which is tried second). * On macOS, resources are copied into <build>/res (which is tried first) and <build>/bin/solvespace.app/Contents/Resources (which is tried second). In practice this means that we can add as many executables as we want without duplicating lots of code. In addition, on macOS, we can place supplementary executables into the bundle, and they can use resources from the bundle transparently.
2016-11-28 04:16:18 +00:00
set(target_app ${app_resource_dir}/${name})
set(target_cli ${cli_resource_dir}/${name})
set(resource_list "${resource_list};${target_app};${target_cli}" PARENT_SCOPE)
Implement a resource system. Currently, icons, fonts, etc are converted to C structures at compile time and are hardcoded to the binary. This presents several problems: * Cross-compilation is complicated. Right now, it is necessary to be able to run executables for the target platform; this happens to work with wine-binfmt installed, but is rather ugly. * Icons can only have one resolution. On OS X, modern software is expected to take advantage of high-DPI ("Retina") screens and use so-called @2x assets when ran in high-DPI mode. * Localization is complicated. Win32 and OS X provide built-in support for loading the resource appropriate for the user's locale. * Embedding strings can only be done as raw strings, using C++'s R"(...)" literals. This precludes embedding sizable strings, e.g. JavaScript libraries as used in Three.js export, and makes git history less useful. Not embedding the libraries means we have to rely on external CDNs, which requires an Internet connection and adds a glaring point of failure. * Linux distribution guidelines are violated. All architecture- independent data, especially large data such as fonts, is expected to be in /usr/share, not in the binary. * Customization is impossible without recompilation. Minor modifications like adding a few missing vector font characters or adjusting localization require a complete development environment, which is unreasonable to expect from users of a mechanical CAD. As such, this commit adds a resource system that bundles (and sometimes builds) resources with the executable. Where they go is platform-dependent: * on Win32: into resources of the executable, which allows us to keep distributing one file; * on OS X: into the app bundle; * on other *nix: into /usr/share/solvespace/ or ../res/ (relative to the executable path), the latter allowing us to run freshly built executables without installation. It also subsides the platform-specific resources that are in src/. The resource system is not yet used for anything; this will be added in later commits.
2016-04-21 15:54:18 +00:00
Use the same code for loading resources in all executables. All of our executables need resources; e.g. the vector font is a resource and it is necessary for generation. Before this commit, the GUI executable loaded the resources in a nice way, and everything else did it in a very ad-hoc, fragile way. After this commit, all executables are placed in <build>/bin and follow the same algorithm: * On Windows, resources are compiled and linked into every executable. * On Linux, resources are copied into <build>/res (which is tried first) and <prefix>/share/solvespace (which is tried second). * On macOS, resources are copied into <build>/res (which is tried first) and <build>/bin/solvespace.app/Contents/Resources (which is tried second). In practice this means that we can add as many executables as we want without duplicating lots of code. In addition, on macOS, we can place supplementary executables into the bundle, and they can use resources from the bundle transparently.
2016-11-28 04:16:18 +00:00
get_filename_component(target_app_dir ${target_app} DIRECTORY)
get_filename_component(target_cli_dir ${target_cli} DIRECTORY)
Implement a resource system. Currently, icons, fonts, etc are converted to C structures at compile time and are hardcoded to the binary. This presents several problems: * Cross-compilation is complicated. Right now, it is necessary to be able to run executables for the target platform; this happens to work with wine-binfmt installed, but is rather ugly. * Icons can only have one resolution. On OS X, modern software is expected to take advantage of high-DPI ("Retina") screens and use so-called @2x assets when ran in high-DPI mode. * Localization is complicated. Win32 and OS X provide built-in support for loading the resource appropriate for the user's locale. * Embedding strings can only be done as raw strings, using C++'s R"(...)" literals. This precludes embedding sizable strings, e.g. JavaScript libraries as used in Three.js export, and makes git history less useful. Not embedding the libraries means we have to rely on external CDNs, which requires an Internet connection and adds a glaring point of failure. * Linux distribution guidelines are violated. All architecture- independent data, especially large data such as fonts, is expected to be in /usr/share, not in the binary. * Customization is impossible without recompilation. Minor modifications like adding a few missing vector font characters or adjusting localization require a complete development environment, which is unreasonable to expect from users of a mechanical CAD. As such, this commit adds a resource system that bundles (and sometimes builds) resources with the executable. Where they go is platform-dependent: * on Win32: into resources of the executable, which allows us to keep distributing one file; * on OS X: into the app bundle; * on other *nix: into /usr/share/solvespace/ or ../res/ (relative to the executable path), the latter allowing us to run freshly built executables without installation. It also subsides the platform-specific resources that are in src/. The resource system is not yet used for anything; this will be added in later commits.
2016-04-21 15:54:18 +00:00
add_custom_command(
Use the same code for loading resources in all executables. All of our executables need resources; e.g. the vector font is a resource and it is necessary for generation. Before this commit, the GUI executable loaded the resources in a nice way, and everything else did it in a very ad-hoc, fragile way. After this commit, all executables are placed in <build>/bin and follow the same algorithm: * On Windows, resources are compiled and linked into every executable. * On Linux, resources are copied into <build>/res (which is tried first) and <prefix>/share/solvespace (which is tried second). * On macOS, resources are copied into <build>/res (which is tried first) and <build>/bin/solvespace.app/Contents/Resources (which is tried second). In practice this means that we can add as many executables as we want without duplicating lots of code. In addition, on macOS, we can place supplementary executables into the bundle, and they can use resources from the bundle transparently.
2016-11-28 04:16:18 +00:00
OUTPUT ${target_app} ${target_cli}
COMMAND ${CMAKE_COMMAND} -E make_directory ${target_app_dir}
COMMAND ${CMAKE_COMMAND} -E copy ${source} ${target_app}
COMMAND ${CMAKE_COMMAND} -E make_directory ${target_cli_dir}
COMMAND ${CMAKE_COMMAND} -E copy ${source} ${target_cli}
Implement a resource system. Currently, icons, fonts, etc are converted to C structures at compile time and are hardcoded to the binary. This presents several problems: * Cross-compilation is complicated. Right now, it is necessary to be able to run executables for the target platform; this happens to work with wine-binfmt installed, but is rather ugly. * Icons can only have one resolution. On OS X, modern software is expected to take advantage of high-DPI ("Retina") screens and use so-called @2x assets when ran in high-DPI mode. * Localization is complicated. Win32 and OS X provide built-in support for loading the resource appropriate for the user's locale. * Embedding strings can only be done as raw strings, using C++'s R"(...)" literals. This precludes embedding sizable strings, e.g. JavaScript libraries as used in Three.js export, and makes git history less useful. Not embedding the libraries means we have to rely on external CDNs, which requires an Internet connection and adds a glaring point of failure. * Linux distribution guidelines are violated. All architecture- independent data, especially large data such as fonts, is expected to be in /usr/share, not in the binary. * Customization is impossible without recompilation. Minor modifications like adding a few missing vector font characters or adjusting localization require a complete development environment, which is unreasonable to expect from users of a mechanical CAD. As such, this commit adds a resource system that bundles (and sometimes builds) resources with the executable. Where they go is platform-dependent: * on Win32: into resources of the executable, which allows us to keep distributing one file; * on OS X: into the app bundle; * on other *nix: into /usr/share/solvespace/ or ../res/ (relative to the executable path), the latter allowing us to run freshly built executables without installation. It also subsides the platform-specific resources that are in src/. The resource system is not yet used for anything; this will be added in later commits.
2016-04-21 15:54:18 +00:00
COMMENT "Copying resource ${name}"
DEPENDS ${source}
VERBATIM)
endfunction()
function(add_xib name)
set(source ${CMAKE_CURRENT_SOURCE_DIR}/${name})
get_filename_component(basename ${name} NAME_WE)
set(target ${app_resource_dir}/${basename}.nib)
set(resource_list "${resource_list};${target}" PARENT_SCOPE)
add_custom_command(
OUTPUT ${target}
COMMAND ${CMAKE_COMMAND} -E make_directory ${app_resource_dir}
COMMAND ibtool --errors --warnings --notices --output-format human-readable-text
--compile ${target} ${source}
COMMENT "Building Interface Builder file ${name}"
DEPENDS ${source}
VERBATIM)
endfunction()
function(add_iconset name)
set(source ${CMAKE_CURRENT_SOURCE_DIR}/${name})
get_filename_component(basename ${name} NAME_WE)
set(target ${app_resource_dir}/${basename}.icns)
set(resource_list "${resource_list};${target}" PARENT_SCOPE)
add_custom_command(
OUTPUT ${target}
COMMAND ${CMAKE_COMMAND} -E make_directory ${app_resource_dir}
COMMAND iconutil -c icns -o ${target} ${source}
COMMENT "Building icon set ${name}"
DEPENDS ${source}
VERBATIM)
endfunction()
else() # Unix
include(GNUInstallDirs)
set(app_resource_dir ${CMAKE_BINARY_DIR}/res)
function(add_resource name)
set(source ${CMAKE_CURRENT_SOURCE_DIR}/${name})
set(target ${app_resource_dir}/${name})
set(resource_list "${resource_list};${target}" PARENT_SCOPE)
get_filename_component(target_dir ${target} DIRECTORY)
add_custom_command(
OUTPUT ${target}
COMMAND ${CMAKE_COMMAND} -E make_directory ${target_dir}
COMMAND ${CMAKE_COMMAND} -E copy ${source} ${target}
COMMENT "Copying resource ${name}"
DEPENDS ${source}
VERBATIM)
get_filename_component(name_dir ${name} DIRECTORY)
install(FILES ${source}
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/solvespace/${name_dir})
endfunction()
endif()
Move icons to res/icons/; remove png2c. This commit integrates icons in the resource system so that they can be loaded (or reloaded, without restarting) in @2x mode, which will be added in a future commit. png2c is no longer necessary. png2c used to perform the following transformation: if(r + g + b < 11) r = g = b = 11; This is now achieved by switching the icons to RGBA mode and adding alpha channel with the following imagemagick invocation, which is equivalent to the transformation above: for i in *.png; do convert -fuzz 4% -channel rgba -matte \ -fill "rgba(255,255,255,0)" -opaque black \ $i $i done The Debian package solvespace now includes /usr/share/solvespace; this should be split out into solvespace-data later.
2016-04-22 13:35:22 +00:00
function(add_resources)
foreach(name ${ARGN})
add_resource(${name})
set(resource_list "${resource_list}" PARENT_SCOPE)
endforeach()
endfunction()
Implement a resource system. Currently, icons, fonts, etc are converted to C structures at compile time and are hardcoded to the binary. This presents several problems: * Cross-compilation is complicated. Right now, it is necessary to be able to run executables for the target platform; this happens to work with wine-binfmt installed, but is rather ugly. * Icons can only have one resolution. On OS X, modern software is expected to take advantage of high-DPI ("Retina") screens and use so-called @2x assets when ran in high-DPI mode. * Localization is complicated. Win32 and OS X provide built-in support for loading the resource appropriate for the user's locale. * Embedding strings can only be done as raw strings, using C++'s R"(...)" literals. This precludes embedding sizable strings, e.g. JavaScript libraries as used in Three.js export, and makes git history less useful. Not embedding the libraries means we have to rely on external CDNs, which requires an Internet connection and adds a glaring point of failure. * Linux distribution guidelines are violated. All architecture- independent data, especially large data such as fonts, is expected to be in /usr/share, not in the binary. * Customization is impossible without recompilation. Minor modifications like adding a few missing vector font characters or adjusting localization require a complete development environment, which is unreasonable to expect from users of a mechanical CAD. As such, this commit adds a resource system that bundles (and sometimes builds) resources with the executable. Where they go is platform-dependent: * on Win32: into resources of the executable, which allows us to keep distributing one file; * on OS X: into the app bundle; * on other *nix: into /usr/share/solvespace/ or ../res/ (relative to the executable path), the latter allowing us to run freshly built executables without installation. It also subsides the platform-specific resources that are in src/. The resource system is not yet used for anything; this will be added in later commits.
2016-04-21 15:54:18 +00:00
# Second, register all resources.
Win32: move resources to res/.
2016-04-21 16:59:13 +00:00
if(WIN32)
Win32: fix inclusion of manifest, to get back visual styles. This commit fixes four issues: * Instead of WRITE,APPEND, resource.rc was generated using WRITE,WRITE, which erased #include <windows.h> and prevented any symbolic definitions (like RT_MANIFEST) from working. This silently included them using a string type instead, which did nothing. * WINVER is bumped to Win7, since that's what we target now. * Index of RT_MANIFEST is changed to 2, since that's what it has to be when ISOLATION_AWARE_ENABLED is defined. * Platform is not restricted to X86 in manifest, since there is no point in doing so.
2016-12-04 20:16:05 +00:00
add_resource(win32/icon.ico 4000 ICON)
Implement a platform abstraction for windows. This commit removes a large amount of code partially duplicated between the text and the graphics windows, and opens the path to having more than one model window on screen at any given time, as well as simplifies platform work. This commit also adds complete support for High-DPI device pixel ratio. It adds support for font scale factor (a fractional factor on top of integral device pixel ratio) on the platform side, but not on the application side. This commit also adds error checking to all Windows API calls (within the abstracted code) and fixes a significant number of misuses and non-future-proof uses of Windows API. This commit also makes uses of Windows API idiomatic, e.g. using the built-in vertical scroll bar, native tooltips, control subclassing instead of hooks in the global dispatch loop, and so on. It reinstates tooltip support and removes menu-related hacks.
2018-07-12 19:29:44 +00:00
add_resource(win32/manifest.xml 1 RT_MANIFEST)
freedesktop: move resources to res/.
2016-04-21 17:15:38 +00:00
elseif(APPLE)
OS X: move resources to res/.
2016-04-21 17:36:20 +00:00
add_iconset (cocoa/AppIcon.iconset)
add_xib (cocoa/MainMenu.xib)
add_xib (cocoa/SaveFormatAccessory.xib)
freedesktop: move resources to res/.
2016-04-21 17:15:38 +00:00
else()
GTK: set application icon.
2016-05-18 17:23:14 +00:00
add_resource(freedesktop/solvespace-48x48.png)
Linux: add Flatpak integration. To test it, use: $ ./pkg/flatpak/build.sh $ flatpak install ./pkg/flatpak/solvespace.flatpak $ flatpak run com.solvespace.SolveSpace
2019-05-11 15:36:54 +00:00
if(FLATPAK)
configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/freedesktop/solvespace-flatpak.desktop.in
${CMAKE_CURRENT_BINARY_DIR}/freedesktop/solvespace-flatpak.desktop)
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/freedesktop/solvespace-flatpak.desktop
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/applications
RENAME com.solvespace.SolveSpace.desktop)
install(FILES freedesktop/solvespace-flatpak-mime.xml
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/mime/packages
RENAME com.solvespace.SolveSpace-slvs.xml)
Freedesktop: add scalable SVG icon.
2019-06-14 17:20:14 +00:00
install(FILES freedesktop/solvespace-scalable.svg
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/icons/hicolor/scalable/apps
RENAME com.solvespace.SolveSpace.svg)
install(FILES freedesktop/solvespace-scalable.svg
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/icons/hicolor/scalable/mimetypes
RENAME com.solvespace.SolveSpace.svg)
Linux: add Flatpak integration. To test it, use: $ ./pkg/flatpak/build.sh $ flatpak install ./pkg/flatpak/solvespace.flatpak $ flatpak run com.solvespace.SolveSpace
2019-05-11 15:36:54 +00:00
foreach(SIZE 16x16 24x24 32x32 48x48)
install(FILES freedesktop/solvespace-${SIZE}.png
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/icons/hicolor/${SIZE}/apps
RENAME com.solvespace.SolveSpace.png)
install(FILES freedesktop/solvespace-${SIZE}.png
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/icons/hicolor/${SIZE}/mimetypes
RENAME com.solvespace.SolveSpace.png)
endforeach()
Linux: add support for building snap packages.
2019-09-11 10:12:53 +00:00
elseif(SNAP)
install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/freedesktop/solvespace-snap.desktop
DESTINATION /
RENAME solvespace.desktop)
# snapd does not support registering new mime types
install(FILES freedesktop/solvespace-scalable.svg
DESTINATION /meta/icons/hicolor/scalable/apps
RENAME snap.solvespace.svg)
foreach(SIZE 16x16 24x24 32x32 48x48)
install(FILES freedesktop/solvespace-${SIZE}.png
DESTINATION /meta/icons/hicolor/${SIZE}/apps
RENAME snap.solvespace.png)
endforeach()
Linux: add Flatpak integration. To test it, use: $ ./pkg/flatpak/build.sh $ flatpak install ./pkg/flatpak/solvespace.flatpak $ flatpak run com.solvespace.SolveSpace
2019-05-11 15:36:54 +00:00
else()
configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/freedesktop/solvespace.desktop.in
${CMAKE_CURRENT_BINARY_DIR}/freedesktop/solvespace.desktop)
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/freedesktop/solvespace.desktop
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/applications)
install(FILES freedesktop/solvespace-mime.xml
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/mime/packages
RENAME solvespace-slvs.xml)
Freedesktop: add scalable SVG icon.
2019-06-14 17:20:14 +00:00
install(FILES freedesktop/solvespace-scalable.svg
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/icons/hicolor/scalable/apps
RENAME solvespace.svg)
install(FILES freedesktop/solvespace-scalable.svg
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/icons/hicolor/scalable/mimetypes
RENAME application.x-solvespace.svg)
Linux: add Flatpak integration. To test it, use: $ ./pkg/flatpak/build.sh $ flatpak install ./pkg/flatpak/solvespace.flatpak $ flatpak run com.solvespace.SolveSpace
2019-05-11 15:36:54 +00:00
foreach(SIZE 16x16 24x24 32x32 48x48)
install(FILES freedesktop/solvespace-${SIZE}.png
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/icons/hicolor/${SIZE}/apps
RENAME solvespace.png)
install(FILES freedesktop/solvespace-${SIZE}.png
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/icons/hicolor/${SIZE}/mimetypes
RENAME application.x-solvespace.png)
endforeach()
foreach(SIZE 16x16 24x24 32x32 48x48)
install(FILES freedesktop/solvespace-${SIZE}.xpm
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/pixmaps)
endforeach()
endif()
Win32: move resources to res/.
2016-04-21 16:59:13 +00:00
endif()
Move icons to res/icons/; remove png2c. This commit integrates icons in the resource system so that they can be loaded (or reloaded, without restarting) in @2x mode, which will be added in a future commit. png2c is no longer necessary. png2c used to perform the following transformation: if(r + g + b < 11) r = g = b = 11; This is now achieved by switching the icons to RGBA mode and adding alpha channel with the following imagemagick invocation, which is equivalent to the transformation above: for i in *.png; do convert -fuzz 4% -channel rgba -matte \ -fill "rgba(255,255,255,0)" -opaque black \ $i $i done The Debian package solvespace now includes /usr/share/solvespace; this should be split out into solvespace-data later.
2016-04-22 13:35:22 +00:00
add_resources(
banner.txt
icons/graphics-window/angle.png
icons/graphics-window/arc.png
icons/graphics-window/assemble.png
icons/graphics-window/bezier.png
icons/graphics-window/circle.png
icons/graphics-window/construction.png
icons/graphics-window/equal.png
icons/graphics-window/extrude.png
Add toolbar icons for Revolve and Helix created by jkrei0 in issue #857. (#878)
2021-01-09 17:27:27 +00:00
icons/graphics-window/helix.png
Move icons to res/icons/; remove png2c. This commit integrates icons in the resource system so that they can be loaded (or reloaded, without restarting) in @2x mode, which will be added in a future commit. png2c is no longer necessary. png2c used to perform the following transformation: if(r + g + b < 11) r = g = b = 11; This is now achieved by switching the icons to RGBA mode and adding alpha channel with the following imagemagick invocation, which is equivalent to the transformation above: for i in *.png; do convert -fuzz 4% -channel rgba -matte \ -fill "rgba(255,255,255,0)" -opaque black \ $i $i done The Debian package solvespace now includes /usr/share/solvespace; this should be split out into solvespace-data later.
2016-04-22 13:35:22 +00:00
icons/graphics-window/horiz.png
Implement an image request.
2016-11-29 16:49:20 +00:00
icons/graphics-window/image.png
Move icons to res/icons/; remove png2c. This commit integrates icons in the resource system so that they can be loaded (or reloaded, without restarting) in @2x mode, which will be added in a future commit. png2c is no longer necessary. png2c used to perform the following transformation: if(r + g + b < 11) r = g = b = 11; This is now achieved by switching the icons to RGBA mode and adding alpha channel with the following imagemagick invocation, which is equivalent to the transformation above: for i in *.png; do convert -fuzz 4% -channel rgba -matte \ -fill "rgba(255,255,255,0)" -opaque black \ $i $i done The Debian package solvespace now includes /usr/share/solvespace; this should be split out into solvespace-data later.
2016-04-22 13:35:22 +00:00
icons/graphics-window/in3d.png
icons/graphics-window/lathe.png
icons/graphics-window/length.png
icons/graphics-window/line.png
icons/graphics-window/ontoworkplane.png
icons/graphics-window/other-supp.png
icons/graphics-window/parallel.png
icons/graphics-window/perpendicular.png
icons/graphics-window/pointonx.png
icons/graphics-window/point.png
icons/graphics-window/rectangle.png
icons/graphics-window/ref.png
Add toolbar icons for Revolve and Helix created by jkrei0 in issue #857. (#878)
2021-01-09 17:27:27 +00:00
icons/graphics-window/revolve.png
Move icons to res/icons/; remove png2c. This commit integrates icons in the resource system so that they can be loaded (or reloaded, without restarting) in @2x mode, which will be added in a future commit. png2c is no longer necessary. png2c used to perform the following transformation: if(r + g + b < 11) r = g = b = 11; This is now achieved by switching the icons to RGBA mode and adding alpha channel with the following imagemagick invocation, which is equivalent to the transformation above: for i in *.png; do convert -fuzz 4% -channel rgba -matte \ -fill "rgba(255,255,255,0)" -opaque black \ $i $i done The Debian package solvespace now includes /usr/share/solvespace; this should be split out into solvespace-data later.
2016-04-22 13:35:22 +00:00
icons/graphics-window/same-orientation.png
icons/graphics-window/sketch-in-3d.png
icons/graphics-window/sketch-in-plane.png
icons/graphics-window/step-rotate.png
icons/graphics-window/step-translate.png
icons/graphics-window/symmetric.png
icons/graphics-window/tangent-arc.png
icons/graphics-window/text.png
icons/graphics-window/trim.png
icons/graphics-window/vert.png
icons/text-window/constraint.png
Add a button to hide construction entities. Also, mark not just curves, but also points and normals derived from construction requests as construction. Also, don't always mark arc center point as construction just to exclude it from chord tolerance bounding box calculation; instead, special-case it there.
2019-05-23 16:06:24 +00:00
icons/text-window/construction.png
Move icons to res/icons/; remove png2c. This commit integrates icons in the resource system so that they can be loaded (or reloaded, without restarting) in @2x mode, which will be added in a future commit. png2c is no longer necessary. png2c used to perform the following transformation: if(r + g + b < 11) r = g = b = 11; This is now achieved by switching the icons to RGBA mode and adding alpha channel with the following imagemagick invocation, which is equivalent to the transformation above: for i in *.png; do convert -fuzz 4% -channel rgba -matte \ -fill "rgba(255,255,255,0)" -opaque black \ $i $i done The Debian package solvespace now includes /usr/share/solvespace; this should be split out into solvespace-data later.
2016-04-22 13:35:22 +00:00
icons/text-window/edges.png
icons/text-window/faces.png
Make "Show/hide hidden lines" a tri-state button instead. The states are: * Draw all lines (on top of shaded mesh). * Draw occluded (by shaded mesh) lines as stippled. * Do not draw occluded (by shaded mesh) lines. As usual, the export output follows the screen output.
2016-08-13 09:02:12 +00:00
icons/text-window/occluded-visible.png
icons/text-window/occluded-stippled.png
icons/text-window/occluded-invisible.png
Move icons to res/icons/; remove png2c. This commit integrates icons in the resource system so that they can be loaded (or reloaded, without restarting) in @2x mode, which will be added in a future commit. png2c is no longer necessary. png2c used to perform the following transformation: if(r + g + b < 11) r = g = b = 11; This is now achieved by switching the icons to RGBA mode and adding alpha channel with the following imagemagick invocation, which is equivalent to the transformation above: for i in *.png; do convert -fuzz 4% -channel rgba -matte \ -fill "rgba(255,255,255,0)" -opaque black \ $i $i done The Debian package solvespace now includes /usr/share/solvespace; this should be split out into solvespace-data later.
2016-04-22 13:35:22 +00:00
icons/text-window/mesh.png
icons/text-window/normal.png
icons/text-window/outlines.png
icons/text-window/point.png
icons/text-window/shaded.png
Move bitmap font to res/fonts/; remove unifont2c. This commit integrates the bitmap font in the resource system, so that cross-compilation would be easier. The font handling code was carefully written to do glyph parsing lazily; in practice this means that after this commit, startup is less than 25ms slower, most of it spent in inflate(). This should also result in faster rendering, since there is no rampant plane switching anymore; instead, all characters that are actually used are stashed into same one texture.
2016-04-23 04:37:42 +00:00
icons/text-window/workplane.png
Implement a gettext .po file parser.
2017-01-04 15:39:27 +00:00
locales.txt
I18n: add de-DE locale.
2018-07-20 04:40:09 +00:00
locales/de_DE.po
Implement a gettext .po file parser.
2017-01-04 15:39:27 +00:00
locales/en_US.po
I18n: add fr_FR locale.
2018-07-14 18:21:03 +00:00
locales/fr_FR.po
Fix typo: ua-UA → uk-UA.
2017-01-07 16:37:23 +00:00
locales/uk_UA.po
Add Turkish translation by mhalil (Mustafa Halil).
2021-03-20 16:09:34 +00:00
locales/tr_TR.po
I18n: add a ru_RU translation.
2017-04-18 15:33:11 +00:00
locales/ru_RU.po
Chinese translation added.
2020-09-28 05:15:34 +00:00
locales/zh_CN.po
Move bitmap font to res/fonts/; remove unifont2c. This commit integrates the bitmap font in the resource system, so that cross-compilation would be easier. The font handling code was carefully written to do glyph parsing lazily; in practice this means that after this commit, startup is less than 25ms slower, most of it spent in inflate(). This should also result in faster rendering, since there is no rampant plane switching anymore; instead, all characters that are actually used are stashed into same one texture.
2016-04-23 04:37:42 +00:00
fonts/unifont.hex.gz
fonts/private/0-check-false.png
fonts/private/1-check-true.png
fonts/private/2-radio-false.png
fonts/private/3-radio-true.png
fonts/private/4-stipple-dot.png
fonts/private/5-stipple-dash-long.png
fonts/private/6-stipple-dash.png
Move vector font to res/fonts/; remove lff2c. This commit integrates the vector font in the resource system, so that cross-compilation would be easier and a custom font could be used without recompilation. The font handling code was carefully written to lazily load glyphs; as possible; in practice this means that startup is less than 15ms slower after this commit, most of it spent in inflate(). This also reduces executable size and makes compilation of glhelper.cpp much faster.
2016-04-24 22:35:23 +00:00
fonts/private/7-stipple-zigzag.png
Three.js: put all resources into res/threejs/ and embed on export. This means that our exported viewer is independent of internet connection as well as any CDNs that will eventually die.
2016-05-18 11:44:32 +00:00
fonts/unicode.lff.gz
Add a built-in Bitstream Vera Sans Roman font. Before this commit, the default font chosen for TTF text is Arial (chosen by the basename of arial.ttf), which isn't present on most Linux systems, and cannot be redistributed. After this commit, it is replaced with Bitstream Vera Sans, which can be. Existing files are not affected. The font name in the TTF file was artificially modified to add the (built-in) suffix, which will need to be done if more built-in fonts are added.
2018-07-12 18:58:44 +00:00
fonts/BitstreamVeraSans-Roman-builtin.ttf
Implement an OpenGL 2 renderer. There are two main reasons to desire an OpenGL 2 renderer: 1. Compatibility. The compatibility profile, ironically, does not offer a lot of compatibility, and our OpenGL 1 renderer will not run on Android, iOS, or WebGL. 2. Performance. The immediate mode does not scale, and in fact becomes very slow with only a moderate amount of lines on screen, and only a somewhat large amount of triangles. This commit implements a basic OpenGL 2 renderer that uses only features from the (OpenGL 3.2) core profile. It is not yet faster than the OpenGL 1 renderer, primarily because it uses a lot of small draw calls. This commit uses OpenGL 2 on Linux and Mac OS X directly (i.e. links to the GL symbols from version 2+); on Windows this is impossible with the default drivers, so for now OpenGL 1 is still used there.
2016-06-30 15:54:35 +00:00
shaders/imesh.frag
shaders/imesh.vert
shaders/imesh_point.frag
shaders/imesh_point.vert
shaders/imesh_tex.frag
shaders/imesh_texa.frag
shaders/imesh_tex.vert
shaders/mesh.frag
shaders/mesh.vert
shaders/mesh_fill.frag
shaders/mesh_fill.vert
shaders/edge.frag
shaders/edge.vert
shaders/outline.vert
Update to THREE.js revision 111 as found in Debian Testing Required some small JavaScript changes to replace deprecated usage.
2021-01-21 21:25:09 +00:00
threejs/three-r111.min.js.gz
Three.js: put all resources into res/threejs/ and embed on export. This means that our exported viewer is independent of internet connection as well as any CDNs that will eventually die.
2016-05-18 11:44:32 +00:00
threejs/hammer-2.0.8.js.gz
threejs/SolveSpaceControls.js)
Implement a resource system. Currently, icons, fonts, etc are converted to C structures at compile time and are hardcoded to the binary. This presents several problems: * Cross-compilation is complicated. Right now, it is necessary to be able to run executables for the target platform; this happens to work with wine-binfmt installed, but is rather ugly. * Icons can only have one resolution. On OS X, modern software is expected to take advantage of high-DPI ("Retina") screens and use so-called @2x assets when ran in high-DPI mode. * Localization is complicated. Win32 and OS X provide built-in support for loading the resource appropriate for the user's locale. * Embedding strings can only be done as raw strings, using C++'s R"(...)" literals. This precludes embedding sizable strings, e.g. JavaScript libraries as used in Three.js export, and makes git history less useful. Not embedding the libraries means we have to rely on external CDNs, which requires an Internet connection and adds a glaring point of failure. * Linux distribution guidelines are violated. All architecture- independent data, especially large data such as fonts, is expected to be in /usr/share, not in the binary. * Customization is impossible without recompilation. Minor modifications like adding a few missing vector font characters or adjusting localization require a complete development environment, which is unreasonable to expect from users of a mechanical CAD. As such, this commit adds a resource system that bundles (and sometimes builds) resources with the executable. Where they go is platform-dependent: * on Win32: into resources of the executable, which allows us to keep distributing one file; * on OS X: into the app bundle; * on other *nix: into /usr/share/solvespace/ or ../res/ (relative to the executable path), the latter allowing us to run freshly built executables without installation. It also subsides the platform-specific resources that are in src/. The resource system is not yet used for anything; this will be added in later commits.
2016-04-21 15:54:18 +00:00
# Third, distribute the resources.
add_custom_target(resources
DEPENDS ${resource_list})
if(WIN32)
set_property(TARGET resources PROPERTY EXTRA_SOURCES ${rc_file})
endif()