nixo
/
tuhi
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
tuhi/meson.build

157 lines
5.3 KiB
Meson
Raw Normal View History

Drop TuhiGui, make it into Tuhi Drop the user-visible separation, make everything just Tuhi. Directory structure remains largely separate (tuhi vs tuhigui) except for the po files which are in the top-level directory because convention. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2019-07-17 13:10:36 +02:00
project('tuhi',
Add a GUI for Tuhi This is a quickly hacked-together versions with some bits in detail, others just sketched in. Credit goes to Piper where much of the basic structure has been taken from, and tuhi-kete where the DBus bindings were taken from. Current functionality allows to register a new device and save drawings from an existing device. Missing is the bit where we can download drawings from a newly registered device. Several buttons are present but not hooked up yet, several UI pieces are unpolished. This UI is designed to work with one device only right now. If you have two devices, you'll have to manually remove them from Tuhi and add one or the other through this tool. The UI is minimal. If you start it and Tuhi doesn't have a device yet, it will immediately go into search mode and start registering the device. If you have a device, it'll just display the data. The data Tuhi exports is downloaded immediately and converted to SVG files, stored in $XDG_DATA_HOME/tuhigui/<timestamp>.svg. Downloading a file through the GUI merely copies that file into the target path. No support for rotation at this point, but could and should be added (there's a button already!)
2019-07-10 01:51:41 +02:00
version: '0.1',
license: 'GPLv2',
meson_version: '>= 0.48.0')
# The tag date of the project_version(), update when the version bumps.
version_date='2019-07-10'
# Dependencies
dependency('python3', required: true)
dependency('pygobject-3.0', required: true)
prefix = get_option('prefix')
datadir = join_paths(prefix, get_option('datadir'))
localedir = join_paths(prefix, get_option('localedir'))
pkgdatadir = join_paths(datadir, meson.project_name())
bindir = join_paths(prefix, get_option('bindir'))
podir = join_paths(meson.source_root(), 'po')
Add the flatpak files
2019-07-11 04:11:55 +02:00
desktopdir = join_paths(datadir, 'applications')
meson.build: de-duplicate the icondir defines Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2019-08-21 07:20:35 +02:00
icondir = join_paths(datadir, 'icons', 'hicolor')
icondir_scalable = join_paths(icondir, 'scalable', 'apps')
icondir_symbolic = join_paths(icondir, 'symbolic', 'apps')
Add the flatpak files
2019-07-11 04:11:55 +02:00
metainfodir = join_paths(datadir, 'metainfo')
Add the tuhi.in startup script As a <builddir>/tuhi and <builddir>/tuhi.devel version. The latter runs in-tree, the former is the one to be installed. This is this type of script for a number of reasons. The quickest integration would be to just use multiprocessing and call into the python module instead of running other generated scripts. But that doesn't work, GLib doesn't like that much (the GTK UI crashes). See https://jameswestby.net/weblog/tech/14-caution-python-multiprocessing-and-glib-dont-mix.html Another option would be to have a single thread because with GObjects we don't need to care, right? Except that we do because the DBus bindings use sync calls and that hangs when we have the server in the same process in a single thread. Fixing the bindings is a bit more involved. So meanwhile, let's just go for a script that executes the right targets as separate processes and let the kernel take care of 'threading', that's what it's there for after all.
2019-07-18 03:48:05 +02:00
libexecdir = join_paths(get_option('prefix'), get_option('libexecdir'), 'tuhi')
Add a GUI for Tuhi This is a quickly hacked-together versions with some bits in detail, others just sketched in. Credit goes to Piper where much of the basic structure has been taken from, and tuhi-kete where the DBus bindings were taken from. Current functionality allows to register a new device and save drawings from an existing device. Missing is the bit where we can download drawings from a newly registered device. Several buttons are present but not hooked up yet, several UI pieces are unpolished. This UI is designed to work with one device only right now. If you have two devices, you'll have to manually remove them from Tuhi and add one or the other through this tool. The UI is minimal. If you start it and Tuhi doesn't have a device yet, it will immediately go into search mode and start registering the device. If you have a device, it'll just display the data. The data Tuhi exports is downloaded immediately and converted to SVG files, stored in $XDG_DATA_HOME/tuhigui/<timestamp>.svg. Downloading a file through the GUI merely copies that file into the target path. No support for rotation at this point, but could and should be added (there's a button already!)
2019-07-10 01:51:41 +02:00
i18n = import('i18n')
subdir('po')
Merge tuhigui/data to just data/ Step one in making the tuihgui a submodule of tuhi Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2019-08-13 03:08:44 +02:00
subdir('data')
Add a GUI for Tuhi This is a quickly hacked-together versions with some bits in detail, others just sketched in. Credit goes to Piper where much of the basic structure has been taken from, and tuhi-kete where the DBus bindings were taken from. Current functionality allows to register a new device and save drawings from an existing device. Missing is the bit where we can download drawings from a newly registered device. Several buttons are present but not hooked up yet, several UI pieces are unpolished. This UI is designed to work with one device only right now. If you have two devices, you'll have to manually remove them from Tuhi and add one or the other through this tool. The UI is minimal. If you start it and Tuhi doesn't have a device yet, it will immediately go into search mode and start registering the device. If you have a device, it'll just display the data. The data Tuhi exports is downloaded immediately and converted to SVG files, stored in $XDG_DATA_HOME/tuhigui/<timestamp>.svg. Downloading a file through the GUI merely copies that file into the target path. No support for rotation at this point, but could and should be added (there's a button already!)
2019-07-10 01:51:41 +02:00
# Find the directory to install our Python code
pymod = import('python')
py3 = pymod.find_installation()
python_dir = py3.get_install_dir()
meson.build: install the server with meson as well
2019-07-18 03:54:03 +02:00
install_subdir('tuhi',
install_dir: python_dir,
exclude_directories: '__pycache__')
Add a GUI for Tuhi This is a quickly hacked-together versions with some bits in detail, others just sketched in. Credit goes to Piper where much of the basic structure has been taken from, and tuhi-kete where the DBus bindings were taken from. Current functionality allows to register a new device and save drawings from an existing device. Missing is the bit where we can download drawings from a newly registered device. Several buttons are present but not hooked up yet, several UI pieces are unpolished. This UI is designed to work with one device only right now. If you have two devices, you'll have to manually remove them from Tuhi and add one or the other through this tool. The UI is minimal. If you start it and Tuhi doesn't have a device yet, it will immediately go into search mode and start registering the device. If you have a device, it'll just display the data. The data Tuhi exports is downloaded immediately and converted to SVG files, stored in $XDG_DATA_HOME/tuhigui/<timestamp>.svg. Downloading a file through the GUI merely copies that file into the target path. No support for rotation at this point, but could and should be added (there's a button already!)
2019-07-10 01:51:41 +02:00
Add the tuhi.in startup script As a <builddir>/tuhi and <builddir>/tuhi.devel version. The latter runs in-tree, the former is the one to be installed. This is this type of script for a number of reasons. The quickest integration would be to just use multiprocessing and call into the python module instead of running other generated scripts. But that doesn't work, GLib doesn't like that much (the GTK UI crashes). See https://jameswestby.net/weblog/tech/14-caution-python-multiprocessing-and-glib-dont-mix.html Another option would be to have a single thread because with GObjects we don't need to care, right? Except that we do because the DBus bindings use sync calls and that hangs when we have the server in the same process in a single thread. Fixing the bindings is a bit more involved. So meanwhile, let's just go for a script that executes the right targets as separate processes and let the kernel take care of 'threading', that's what it's there for after all.
2019-07-18 03:48:05 +02:00
# We have three startup scripts:
# - tuhi: starts server and GUI
# - tuhi-gui: starts the GUI only
# - tuhi-server: starts the server only
#
# tuhi-server can run as-is, we don't need meson for it. But for the other
# two we build a {name}.devel version that uses the in-tree files.
# For that we need to replace a few paths, in the installed versions we just
# use the normal dirs.
#
config_tuhi = configuration_data()
flake8 fixes
2019-08-13 04:53:26 +02:00
config_tuhi.set('libexecdir', libexecdir)
Add the tuhi.in startup script As a <builddir>/tuhi and <builddir>/tuhi.devel version. The latter runs in-tree, the former is the one to be installed. This is this type of script for a number of reasons. The quickest integration would be to just use multiprocessing and call into the python module instead of running other generated scripts. But that doesn't work, GLib doesn't like that much (the GTK UI crashes). See https://jameswestby.net/weblog/tech/14-caution-python-multiprocessing-and-glib-dont-mix.html Another option would be to have a single thread because with GObjects we don't need to care, right? Except that we do because the DBus bindings use sync calls and that hangs when we have the server in the same process in a single thread. Fixing the bindings is a bit more involved. So meanwhile, let's just go for a script that executes the right targets as separate processes and let the kernel take care of 'threading', that's what it's there for after all.
2019-07-18 03:48:05 +02:00
config_tuhi.set('devel', '')
config_tuhi_devel = configuration_data()
flake8 fixes
2019-08-13 04:53:26 +02:00
config_tuhi_devel.set('libexecdir', '')
Add the tuhi.in startup script As a <builddir>/tuhi and <builddir>/tuhi.devel version. The latter runs in-tree, the former is the one to be installed. This is this type of script for a number of reasons. The quickest integration would be to just use multiprocessing and call into the python module instead of running other generated scripts. But that doesn't work, GLib doesn't like that much (the GTK UI crashes). See https://jameswestby.net/weblog/tech/14-caution-python-multiprocessing-and-glib-dont-mix.html Another option would be to have a single thread because with GObjects we don't need to care, right? Except that we do because the DBus bindings use sync calls and that hangs when we have the server in the same process in a single thread. Fixing the bindings is a bit more involved. So meanwhile, let's just go for a script that executes the right targets as separate processes and let the kernel take care of 'threading', that's what it's there for after all.
2019-07-18 03:48:05 +02:00
config_tuhi_devel.set('devel', '''
tuhi_gui = '@1@/tuhi-gui.devel'
tuhi_server = '@0@/tuhi-server.py'
print('Running from source tree, using local files')
'''.format(meson.source_root(), meson.build_root()))
Add a GUI for Tuhi This is a quickly hacked-together versions with some bits in detail, others just sketched in. Credit goes to Piper where much of the basic structure has been taken from, and tuhi-kete where the DBus bindings were taken from. Current functionality allows to register a new device and save drawings from an existing device. Missing is the bit where we can download drawings from a newly registered device. Several buttons are present but not hooked up yet, several UI pieces are unpolished. This UI is designed to work with one device only right now. If you have two devices, you'll have to manually remove them from Tuhi and add one or the other through this tool. The UI is minimal. If you start it and Tuhi doesn't have a device yet, it will immediately go into search mode and start registering the device. If you have a device, it'll just display the data. The data Tuhi exports is downloaded immediately and converted to SVG files, stored in $XDG_DATA_HOME/tuhigui/<timestamp>.svg. Downloading a file through the GUI merely copies that file into the target path. No support for rotation at this point, but could and should be added (there's a button already!)
2019-07-10 01:51:41 +02:00
config_tuhigui = configuration_data()
config_tuhigui.set('pkgdatadir', pkgdatadir)
config_tuhigui.set('localedir', localedir)
config_tuhigui.set('devel', '')
config_tuhigui_devel = config_tuhigui
Merge tuhigui/data to just data/ Step one in making the tuihgui a submodule of tuhi Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2019-08-13 03:08:44 +02:00
config_tuhigui_devel.set('pkgdatadir', join_paths(meson.build_root(), 'data'))
Add a GUI for Tuhi This is a quickly hacked-together versions with some bits in detail, others just sketched in. Credit goes to Piper where much of the basic structure has been taken from, and tuhi-kete where the DBus bindings were taken from. Current functionality allows to register a new device and save drawings from an existing device. Missing is the bit where we can download drawings from a newly registered device. Several buttons are present but not hooked up yet, several UI pieces are unpolished. This UI is designed to work with one device only right now. If you have two devices, you'll have to manually remove them from Tuhi and add one or the other through this tool. The UI is minimal. If you start it and Tuhi doesn't have a device yet, it will immediately go into search mode and start registering the device. If you have a device, it'll just display the data. The data Tuhi exports is downloaded immediately and converted to SVG files, stored in $XDG_DATA_HOME/tuhigui/<timestamp>.svg. Downloading a file through the GUI merely copies that file into the target path. No support for rotation at this point, but could and should be added (there's a button already!)
2019-07-10 01:51:41 +02:00
config_tuhigui_devel.set('localedir', join_paths(meson.build_root(), 'po'))
config_tuhigui_devel.set('devel', '''
sys.path.insert(1, '@0@')
print('Running from source tree, using local files')
Add the tuhi.in startup script As a <builddir>/tuhi and <builddir>/tuhi.devel version. The latter runs in-tree, the former is the one to be installed. This is this type of script for a number of reasons. The quickest integration would be to just use multiprocessing and call into the python module instead of running other generated scripts. But that doesn't work, GLib doesn't like that much (the GTK UI crashes). See https://jameswestby.net/weblog/tech/14-caution-python-multiprocessing-and-glib-dont-mix.html Another option would be to have a single thread because with GObjects we don't need to care, right? Except that we do because the DBus bindings use sync calls and that hangs when we have the server in the same process in a single thread. Fixing the bindings is a bit more involved. So meanwhile, let's just go for a script that executes the right targets as separate processes and let the kernel take care of 'threading', that's what it's there for after all.
2019-07-18 03:48:05 +02:00
'''.format(meson.source_root(), meson.build_root()))
configure_file(input: 'tuhi.in',
output: 'tuhi',
configuration: config_tuhi,
install_dir: bindir)
configure_file(input: 'tuhi.in',
output: 'tuhi.devel',
configuration: config_tuhi_devel)
Add a GUI for Tuhi This is a quickly hacked-together versions with some bits in detail, others just sketched in. Credit goes to Piper where much of the basic structure has been taken from, and tuhi-kete where the DBus bindings were taken from. Current functionality allows to register a new device and save drawings from an existing device. Missing is the bit where we can download drawings from a newly registered device. Several buttons are present but not hooked up yet, several UI pieces are unpolished. This UI is designed to work with one device only right now. If you have two devices, you'll have to manually remove them from Tuhi and add one or the other through this tool. The UI is minimal. If you start it and Tuhi doesn't have a device yet, it will immediately go into search mode and start registering the device. If you have a device, it'll just display the data. The data Tuhi exports is downloaded immediately and converted to SVG files, stored in $XDG_DATA_HOME/tuhigui/<timestamp>.svg. Downloading a file through the GUI merely copies that file into the target path. No support for rotation at this point, but could and should be added (there's a button already!)
2019-07-10 01:51:41 +02:00
Rename the tuhigui script to tuhi-gui Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2019-07-18 03:05:58 +02:00
configure_file(input: 'tuhi-gui.in',
output: 'tuhi-gui',
Add a GUI for Tuhi This is a quickly hacked-together versions with some bits in detail, others just sketched in. Credit goes to Piper where much of the basic structure has been taken from, and tuhi-kete where the DBus bindings were taken from. Current functionality allows to register a new device and save drawings from an existing device. Missing is the bit where we can download drawings from a newly registered device. Several buttons are present but not hooked up yet, several UI pieces are unpolished. This UI is designed to work with one device only right now. If you have two devices, you'll have to manually remove them from Tuhi and add one or the other through this tool. The UI is minimal. If you start it and Tuhi doesn't have a device yet, it will immediately go into search mode and start registering the device. If you have a device, it'll just display the data. The data Tuhi exports is downloaded immediately and converted to SVG files, stored in $XDG_DATA_HOME/tuhigui/<timestamp>.svg. Downloading a file through the GUI merely copies that file into the target path. No support for rotation at this point, but could and should be added (there's a button already!)
2019-07-10 01:51:41 +02:00
configuration: config_tuhigui,
Add the tuhi.in startup script As a <builddir>/tuhi and <builddir>/tuhi.devel version. The latter runs in-tree, the former is the one to be installed. This is this type of script for a number of reasons. The quickest integration would be to just use multiprocessing and call into the python module instead of running other generated scripts. But that doesn't work, GLib doesn't like that much (the GTK UI crashes). See https://jameswestby.net/weblog/tech/14-caution-python-multiprocessing-and-glib-dont-mix.html Another option would be to have a single thread because with GObjects we don't need to care, right? Except that we do because the DBus bindings use sync calls and that hangs when we have the server in the same process in a single thread. Fixing the bindings is a bit more involved. So meanwhile, let's just go for a script that executes the right targets as separate processes and let the kernel take care of 'threading', that's what it's there for after all.
2019-07-18 03:48:05 +02:00
install_dir: libexecdir)
Add a GUI for Tuhi This is a quickly hacked-together versions with some bits in detail, others just sketched in. Credit goes to Piper where much of the basic structure has been taken from, and tuhi-kete where the DBus bindings were taken from. Current functionality allows to register a new device and save drawings from an existing device. Missing is the bit where we can download drawings from a newly registered device. Several buttons are present but not hooked up yet, several UI pieces are unpolished. This UI is designed to work with one device only right now. If you have two devices, you'll have to manually remove them from Tuhi and add one or the other through this tool. The UI is minimal. If you start it and Tuhi doesn't have a device yet, it will immediately go into search mode and start registering the device. If you have a device, it'll just display the data. The data Tuhi exports is downloaded immediately and converted to SVG files, stored in $XDG_DATA_HOME/tuhigui/<timestamp>.svg. Downloading a file through the GUI merely copies that file into the target path. No support for rotation at this point, but could and should be added (there's a button already!)
2019-07-10 01:51:41 +02:00
Rename the tuhigui script to tuhi-gui Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2019-07-18 03:05:58 +02:00
configure_file(input: 'tuhi-gui.in',
output: 'tuhi-gui.devel',
Add a GUI for Tuhi This is a quickly hacked-together versions with some bits in detail, others just sketched in. Credit goes to Piper where much of the basic structure has been taken from, and tuhi-kete where the DBus bindings were taken from. Current functionality allows to register a new device and save drawings from an existing device. Missing is the bit where we can download drawings from a newly registered device. Several buttons are present but not hooked up yet, several UI pieces are unpolished. This UI is designed to work with one device only right now. If you have two devices, you'll have to manually remove them from Tuhi and add one or the other through this tool. The UI is minimal. If you start it and Tuhi doesn't have a device yet, it will immediately go into search mode and start registering the device. If you have a device, it'll just display the data. The data Tuhi exports is downloaded immediately and converted to SVG files, stored in $XDG_DATA_HOME/tuhigui/<timestamp>.svg. Downloading a file through the GUI merely copies that file into the target path. No support for rotation at this point, but could and should be added (there's a button already!)
2019-07-10 01:51:41 +02:00
configuration: config_tuhigui_devel)
meson.build: install the server with meson as well
2019-07-18 03:54:03 +02:00
configure_file(input: 'tuhi-server.py',
output: 'tuhi-server',
copy: true,
Add the tuhi.in startup script As a <builddir>/tuhi and <builddir>/tuhi.devel version. The latter runs in-tree, the former is the one to be installed. This is this type of script for a number of reasons. The quickest integration would be to just use multiprocessing and call into the python module instead of running other generated scripts. But that doesn't work, GLib doesn't like that much (the GTK UI crashes). See https://jameswestby.net/weblog/tech/14-caution-python-multiprocessing-and-glib-dont-mix.html Another option would be to have a single thread because with GObjects we don't need to care, right? Except that we do because the DBus bindings use sync calls and that hangs when we have the server in the same process in a single thread. Fixing the bindings is a bit more involved. So meanwhile, let's just go for a script that executes the right targets as separate processes and let the kernel take care of 'threading', that's what it's there for after all.
2019-07-18 03:48:05 +02:00
install_dir: libexecdir)
meson.build: install the server with meson as well
2019-07-18 03:54:03 +02:00
Add a GUI for Tuhi This is a quickly hacked-together versions with some bits in detail, others just sketched in. Credit goes to Piper where much of the basic structure has been taken from, and tuhi-kete where the DBus bindings were taken from. Current functionality allows to register a new device and save drawings from an existing device. Missing is the bit where we can download drawings from a newly registered device. Several buttons are present but not hooked up yet, several UI pieces are unpolished. This UI is designed to work with one device only right now. If you have two devices, you'll have to manually remove them from Tuhi and add one or the other through this tool. The UI is minimal. If you start it and Tuhi doesn't have a device yet, it will immediately go into search mode and start registering the device. If you have a device, it'll just display the data. The data Tuhi exports is downloaded immediately and converted to SVG files, stored in $XDG_DATA_HOME/tuhigui/<timestamp>.svg. Downloading a file through the GUI merely copies that file into the target path. No support for rotation at this point, but could and should be added (there's a button already!)
2019-07-10 01:51:41 +02:00
meson.add_install_script('meson_install.sh')
Merge tuhigui/data to just data/ Step one in making the tuihgui a submodule of tuhi Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2019-08-13 03:08:44 +02:00
desktop_file = i18n.merge_file(input: 'data/org.freedesktop.Tuhi.desktop.in',
Drop TuhiGui, make it into Tuhi Drop the user-visible separation, make everything just Tuhi. Directory structure remains largely separate (tuhi vs tuhigui) except for the po files which are in the top-level directory because convention. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2019-07-17 13:10:36 +02:00
output: 'org.freedesktop.Tuhi.desktop',
Add the flatpak files
2019-07-11 04:11:55 +02:00
type: 'desktop',
po_dir: podir,
install: true,
install_dir: desktopdir)
conf = configuration_data()
conf.set('version', meson.project_version())
Drop TuhiGui, make it into Tuhi Drop the user-visible separation, make everything just Tuhi. Directory structure remains largely separate (tuhi vs tuhigui) except for the po files which are in the top-level directory because convention. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2019-07-17 13:10:36 +02:00
conf.set('url', 'https://github.com/tuhiproject/tuhi')
Add the flatpak files
2019-07-11 04:11:55 +02:00
conf.set('version_date', version_date)
Merge tuhigui/data to just data/ Step one in making the tuihgui a submodule of tuhi Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2019-08-13 03:08:44 +02:00
appdata_intl = configure_file(input: 'data/org.freedesktop.Tuhi.appdata.xml.in.in',
Drop TuhiGui, make it into Tuhi Drop the user-visible separation, make everything just Tuhi. Directory structure remains largely separate (tuhi vs tuhigui) except for the po files which are in the top-level directory because convention. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2019-07-17 13:10:36 +02:00
output: 'org.freedesktop.Tuhi.appdata.xml.in',
Add the flatpak files
2019-07-11 04:11:55 +02:00
configuration: conf)
appdata = i18n.merge_file(input: appdata_intl,
Drop TuhiGui, make it into Tuhi Drop the user-visible separation, make everything just Tuhi. Directory structure remains largely separate (tuhi vs tuhigui) except for the po files which are in the top-level directory because convention. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2019-07-17 13:10:36 +02:00
output: 'org.freedesktop.Tuhi.appdata.xml',
Add the flatpak files
2019-07-11 04:11:55 +02:00
type: 'xml',
po_dir: podir,
install: true,
install_dir: metainfodir)
Merge tuhigui/data to just data/ Step one in making the tuihgui a submodule of tuhi Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2019-08-13 03:08:44 +02:00
install_data('data/org.freedesktop.Tuhi.svg', install_dir: icondir)
Add a GUI for Tuhi This is a quickly hacked-together versions with some bits in detail, others just sketched in. Credit goes to Piper where much of the basic structure has been taken from, and tuhi-kete where the DBus bindings were taken from. Current functionality allows to register a new device and save drawings from an existing device. Missing is the bit where we can download drawings from a newly registered device. Several buttons are present but not hooked up yet, several UI pieces are unpolished. This UI is designed to work with one device only right now. If you have two devices, you'll have to manually remove them from Tuhi and add one or the other through this tool. The UI is minimal. If you start it and Tuhi doesn't have a device yet, it will immediately go into search mode and start registering the device. If you have a device, it'll just display the data. The data Tuhi exports is downloaded immediately and converted to SVG files, stored in $XDG_DATA_HOME/tuhigui/<timestamp>.svg. Downloading a file through the GUI merely copies that file into the target path. No support for rotation at this point, but could and should be added (there's a button already!)
2019-07-10 01:51:41 +02:00
flake8 = find_program('flake8-3', required: false)
if flake8.found()
test('flake8', flake8,
args: ['--ignore=E501,W504',
Merge tuhigui into tuhi.gui Let's make this a submodule of tuhi so we can share some code. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2019-08-13 03:10:53 +02:00
join_paths(meson.source_root(), 'tuhi'),
join_paths(meson.source_root(), 'tuhi', 'gui')])
test: add unit-testing for the various protocol messages This only tests for the success cases, but at least we know that path is executed. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2019-08-13 06:31:31 +02:00
# the tests need different flake exclusions
test('flake8-tests', flake8,
args: ['--ignore=E501,W504,F403,F405',
join_paths(meson.source_root(), 'test/')])
Add a GUI for Tuhi This is a quickly hacked-together versions with some bits in detail, others just sketched in. Credit goes to Piper where much of the basic structure has been taken from, and tuhi-kete where the DBus bindings were taken from. Current functionality allows to register a new device and save drawings from an existing device. Missing is the bit where we can download drawings from a newly registered device. Several buttons are present but not hooked up yet, several UI pieces are unpolished. This UI is designed to work with one device only right now. If you have two devices, you'll have to manually remove them from Tuhi and add one or the other through this tool. The UI is minimal. If you start it and Tuhi doesn't have a device yet, it will immediately go into search mode and start registering the device. If you have a device, it'll just display the data. The data Tuhi exports is downloaded immediately and converted to SVG files, stored in $XDG_DATA_HOME/tuhigui/<timestamp>.svg. Downloading a file through the GUI merely copies that file into the target path. No support for rotation at this point, but could and should be added (there's a button already!)
2019-07-10 01:51:41 +02:00
endif
Add the flatpak files
2019-07-11 04:11:55 +02:00
desktop_validate = find_program('desktop-file-validate', required: false)
if desktop_validate.found()
test('desktop-file-validate', desktop_validate, args: [desktop_file])
endif
appstream_util = find_program('appstream-util', required: false)
if appstream_util.found()
test('appstream-util validate-relax', appstream_util,
args: ['validate-relax', appdata])
endif
Add a flatpak wrapper to start Tuhi on demand No-one but Arch packages Tuhi at the moment, so let's assume it's not running/installed, install it and start it up together with TuhiGui and voila, everything just works as it should be.
2019-07-16 14:10:09 +02:00
test: add unit-testing for the various protocol messages This only tests for the success cases, but at least we know that path is executed. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2019-08-13 06:31:31 +02:00
pytest = find_program('pytest-3', required: false)
if pytest.found()
test('unittest', pytest,
args: [join_paths(meson.source_root(), 'test')])
endif
Add a flatpak wrapper to start Tuhi on demand No-one but Arch packages Tuhi at the moment, so let's assume it's not running/installed, install it and start it up together with TuhiGui and voila, everything just works as it should be.
2019-07-16 14:10:09 +02:00
# A wrapper to start tuhi at the same time as tuhigui, used by the flatpak
configure_file(input: 'tools/tuhi-gui-flatpak.py',
output: 'tuhi-gui-flatpak.py',
copy: true)