Per the docs at
https://cmake.org/cmake/help/latest/command/add_library.html, we should
use `MODULE` rather than `SHARED` for the Lua libraries.
This mostly affects macOS, where the libraries are compiled as MH_DYLIB
(`.dylib`) rather than MH_BUNDLE (`.so`).
- Separate cairo-xlib.h Lua bindings from cairo.h
- This allows cairo.h to be used from Lua on Wayland without X11 as requirement.
- Add pango dependency for Wayland (adds pangocairo).
- Make graphics related bindings depend on BUILD_GUI.
- Remove BUILD_GUI guard around options in platform checks.
- Keeping only checks that **directly contain module requirements**
A way of creating surfaces in Lua that uses Shm allocated buffers should
be added in future. This commit only cleans up build options to avoid weird
errors.
Signed-off-by: Tin Švagelj <tin.svagelj@live.com>
In some cases you are already working with a cairo_t and know
your destination image size, this adds an API that allows you
to handle these cases more easily. Along with now being able to
draw images with an alpha level. It also leaves the original API
unchanged.
Unfortunately we can't use logging.h directly from conky as its
in C++ and lua bindings only have access to a C compiler.
Instead we now have a very simple C implementation of logging.h to
use within the bindings.
This change also adds NULL checks to catch some extra invalid
states
Previously if the source image was a different to the displayed
image the alpha channel was incorrect, as it wasn't scaled leading
to a series of artifacts.
Copied in the mesh pattern related functions from the upstream
cairo.h file, also updated cairo_status_t and cairo_pattern_type_t
to include an updated list as both have mesh related values
Fixes #912
Adds the function for cairo_surface_create_for_rectangle copied
from the cairo header files. Personally I use this to ensure that
Items can't draw outside there designated area.
* chore: Fix imlib2 Lua bindings
The API changed in a backward-incompatible way around 1.10 of imlib2
(though it's not clear which version broke it).
This resolves #1404.
This adds 2 missing functions: cairo_surface_set_device_scale and
cairo_surface_get_device_scale, and also requires cario 1.14 or newer.
This addresses the comments in #1083.
We need an interface to be able to create/destroy/set/get the
RsvgRectangle and RsvgDimensionData structs via Lua, which were missing
or incomplete.
Documentation was also missing, which has been updated.
* First commit!
* Import to git
* Droping down CMake requirement
* Corrected installation of libraries
* Adding travis build
* Updated cmake macros
* Fixed find package
* Updated travis hook
* Updated travis hook
* Patch to support Lua 5.3.
* Fix Lua header include directives in tolua++.h
Use angle bracket rather than double quotes when including Lua headers in the tolua++ header. This fixes a problem on systems that default to a Lua version newer than 5.1 and install the tolua++ header to the same directory as newer Lua headers.
As there are (usually) no Lua headers in the same directory when building tolua++ itself, the preprocessor will look to the include directories passed to the compiler, one of which would be the Lua 5.1 include directory, and tolua++ will build with those (correct) headers. Then the tolua++ header is usually installed in the default include directory, alongside the newer Lua headers, which you wouldn't expect to cause any trouble.
But it does cause trouble when trying to build other programs that include the tolua++ header, because now the preprocessor does find Lua headers in the same directory as the tolua++ header, which are the newer (incorrect) headers. Now the program will either fail to compile, because it doesn't support the newer headers, or fail to link with the tolua++ shared object because they were compiled against different Lua headers.
Using angle brackets instead of double quotes in the include directives will fix the problem, because then the preprocessor will look to the include directories passed to the compiler first.
See http://www.cegui.org.uk/forum/viewtopic.php?f=10&t=7195
* Remove email notifications.
* Update travis build.
* Build shared and static libs.
* Patch toluapp to support Lua 5.3.
With this change, support for Lua 5.1 is dropped.
This resolve #116.
* Add some comments to clarify the toluapp handling.
* Add minor sonar fix.
* Require at least glib-2.36 (from 03/2013) to remove deprecated g_type_init()
* Fix empty continuation line in Dockerfile
* Require at least libmicrohttpd 0.9.25 (from 09/2012) to replace deprecated MHD_create_response_from_data()
* fix versioncheck libmicrohttpd
* Missing char for null-terminator in print_v6addrs()
* safe_asprintf to fix /proc/subdir bufferoverflows
There is no max length of /proc/subdir, increasing the value of /proc/sys/kernel/pid_max is one way this can happen
* Fix conversion constant c++ string to variable char array
* Fix strncpy using unrelated MPD_BUFFER_MAX_LENGTH
* Use strncpy instead of strcpy in eve.cc
* Use strncpy instead of strcpy in libmpdclient.cc
* move safe_asprintf back and use ostreams in proc.cc to make sonarcloud happy
One problem is, that tolua/lua does not handle plain data pointers
properly. Therefore something like
local surface = cairo_image_surface_create_for_data(
imlib_image_get_data_for_reading_only(), ..
will fail using the lua bindings. Hence this wrapper, which adds
a function which be used to draw an imlib image to a cairo surface.
This also addresses another issue, drawing images with a transparent
background (e.g. gifs or pngs) to the cairo surface properly. Apparently
the image format of imlib is incompatible to cairos which uses
pre-multiplied data. This is also explained in the cairo documentation.
A fix for this issue is to blend the image with another alpha mask to
get the correct values. The code and explanation for this was taken from
http://lists.cairographics.org/archives/cairo/2008-March/013492.html
Executive Summary: This wrapper function can load (transparent) images
(e.g. gif or png) from a file by using imlib and draw them on a cairo
surface.
