enzo1982/smooth

The smooth Class Library

smooth's Issues

Bug: REVISION variable not up to date in Makefile-options

This is kind-of the same issue like in BoCA: enzo1982/BoCA#8

In https://github.com/enzo1982/smooth/blob/master/Makefile-options, the REVISION is set to 0, although the latest shipped version is 0.9.6.

This is probably not an issue for most people, but it leads to incorrect file names for libraries which is a (small) problem for people packaging smooth (I am doing this for macports).

I think it should be set to 7, assuming the upcoming version is 0.9.7.

GetApplicationDirectory() code is not up-to-date with modern FreeBSD

Currently, GetApplicationDirectory() works by calling procstat -b <pid> and getting the third field of the line matching the <pid>. The problem is that modern FreeBSD versions return four fields:

% procstat -b $$
  PID COMM                OSREL PATH
42096 tcsh              1300132 /bin/tcsh

So print $3 should really be print $4. Another thing is that filtering the PID line could be avoided if procstat is called with -h (suppress header) switch.

Ideally, however, is not to spawn and chain any processes and read their output with popen(), but ask the system with sysctl() call for the KERN_PROC_PATHNAME as described here.

Compile fails, shows up with file not found error

I tried compiling this from the source code, but I can't compile it because whenever I try to run the make command, I get this error:
g++ -I"/home/cadendurden/smooth/classes/backends/xlib"/../../../include -fvisibility=hidden -fPIC -pthread -DSMOOTH_DLL -c backendxlib.cpp -o backendxlib.o
backendxlib.cpp:11:10: fatal error: gtk/gtk.h: No such file or directory
11 | #include <gtk/gtk.h>
| ^~~~~~~~~~~

System Specs If Needed:
System Name: Dell Latitude D630
RAM: 2GB DDR2
WiFi Card: Broadcom BCM4311
Operating System: Debian Sid (Originally Debian 12 Bookworm)

Build fails with current libcpuid

smooth v0.8.74.0-pre3 and libcpuid 0.4.0 on openSUSE Tumbleweed.
smooth_conflicting_declaration.txt

Wayland support

Wayland support would be really nice, since I'm using a Wayland compositor half the time, which currently runs all Xwayland apps at a fixed scale of 1.0, regardless of the scale factor of the current display.

As a result of the current design, it ignores the GDK_SCALE environment variable I try to pass a value of 1 to, and scales the app to 2.0 according to the factor of my primary display, resulting in the app being too large on both displays.

I am using Arch Linux, and running wayfire-git, self built with several patches which would not affect this particular bug.

Build failure against Glib 2.68.3

Builds fine against Glib version 2.66.8, but fails against 2.68.3 with the following errors:

In file included from fontcairo.cpp:20:
In file included from /usr/local/include/pango-1.0/pango/pangocairo.h:25:
In file included from /usr/local/include/pango-1.0/pango/pango.h:25:
In file included from /usr/local/include/pango-1.0/pango/pango-attributes.h:25:
In file included from /usr/local/include/pango-1.0/pango/pango-font.h:25:
In file included from /usr/local/include/pango-1.0/pango/pango-coverage.h:25:
In file included from /usr/local/include/glib-2.0/glib-object.h:22:
In file included from /usr/local/include/glib-2.0/gobject/gbinding.h:28:
In file included from /usr/local/include/glib-2.0/glib.h:32:
In file included from /usr/local/include/glib-2.0/glib/gasyncqueue.h:32:
In file included from /usr/local/include/glib-2.0/glib/gthread.h:32:
In file included from /usr/local/include/glib-2.0/glib/gatomic.h:31:
/usr/include/c++/v1/type_traits:517:57: error: reference to 'std' is ambiguous
/usr/include/c++/v1/type_traits:517:81: error: use of template template parameter '_Templ' requires template arguments
using _IsValidExpansion _LIBCPP_NODEBUG_TYPE = decltype(std::__sfinae_test_impl<_Templ, _Args...>(0));
...
/usr/include/c++/v1/type_traits:1404:27: error: '_Tp' does not refer to a value
decltype(_VSTD::__declval<_Tp>(0))
...
/usr/include/c++/v1/type_traits:2563:66: error: '_Tp1' does not refer to a value
        typename __is_destructible_apply<decltype(_VSTD::declval<_Tp1&>().~_Tp1(
))>::type