solvespace/src/resource.h

65 lines
2.0 KiB
C
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 23:54:18 +08:00
//-----------------------------------------------------------------------------
// Discovery and loading of our resources (icons, fonts, templates, etc).
//
// Copyright 2016 whitequark
//-----------------------------------------------------------------------------
#ifndef __RESOURCE_H
#define __RESOURCE_H
class Pixmap;
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 23:54:18 +08:00
// Only the following function is platform-specific.
// It returns a pointer to resource contents that is aligned to at least
// sizeof(void*) and has a global lifetime, or NULL if a resource with
// the specified name does not exist.
const void *LoadResource(const std::string &name, size_t *size);
std::string LoadString(const std::string &name);
std::string LoadStringFromGzip(const std::string &name);
Pixmap LoadPNG(const std::string &name);
class Pixmap {
public:
size_t width;
size_t height;
size_t stride;
bool hasAlpha;
std::unique_ptr<uint8_t[]> data;
static Pixmap FromPNG(const uint8_t *data, size_t size);
static Pixmap FromPNG(FILE *f);
bool IsEmpty() const { return width == 0 && height == 0; }
size_t GetBytesPerPixel() const { return hasAlpha ? 4 : 3; }
RgbaColor GetPixel(size_t x, size_t y) const;
void Clear();
};
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 23:54:18 +08:00
class BitmapFont {
public:
struct Glyph {
uint8_t advanceCells;
uint16_t position;
};
static const size_t TEXTURE_DIM = 1024;
std::string unifontData;
std::map<char32_t, Glyph> glyphs;
std::unique_ptr<uint8_t[]> texture;
uint16_t nextPosition;
static BitmapFont From(std::string &&unifontData);
bool IsEmpty() const { return unifontData.empty(); }
const Glyph &GetGlyph(char32_t codepoint);
bool LocateGlyph(char32_t codepoint, double *s0, double *t0, double *s1, double *t1,
size_t *advanceWidth, size_t *boundingHeight);
void AddGlyph(char32_t codepoint, const Pixmap &pixmap);
};
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 23:54:18 +08:00
#endif