lxqt / lxqt-build-tools

Various packaging tools and scripts for LXQt applications

LXQt

LXQt is the next generation of LXDE, the Lightweight Desktop Environment. It is the product of the merge between Razor-qt and LXDE-Qt.

About this repository

This is a superproject which contains all LXQt components. After checking out this repo please do the following to initialize git submodules.

git submodule init
git submodule update --remote --rebase

Note: We require git >= 1.8.5

Contributing

If you are interested in helping or joining LXQt, please take a look at our CONTRIBUTING document

Translation

Translations can be done in LXQt-Weblate.

---

lxqt-build-tools's Issues

How to use it on Mac OS?

I have not found a way to use it on Mac. This prevents me from building qterminal

Expected Behavior

It is easy to find an installation guide for Mac

Current Behavior

I could not find it

Possible Solution

Someone writes it

Steps to Reproduce (for bugs)

1. Be noob
2. Download the repo
3. Enjoy

Syncing version to the same one as the rest of the lxqt-components? For next release perhaps

Hey guys,

This is mostly a suggestion; please feel free to ignore it.

Most current release is:

https://github.com/lxqt/lxqt-build-tools/releases/download/0.9.0/lxqt-build-tools-0.9.0.tar.xz

lxqt-config on the other hand uses this version:

https://github.com/lxqt/lxqt-config/releases/download/0.17.1/lxqt-config-0.17.1.tar.xz

Now ... it's minor but ... since most of the lxqt components use the same version right
now, such as 0.17.1, would it be possible to also bump up the version of the lxqt-build-tools
for the next release 0.18 series? I think it would help simplify understanding for the users
who compile from source at the least, but perhaps also package managers. That way we
can easily say "ok, we have lxqt 0.18.0 now, so this needs to be updated to 0.18.0 as
well", whereas with different versions, such as lxqt-build-tools and others, not using
the same, this is a bit more confusing.

It's trivial either way, but I wondered whether this would be useful for lxqt too.

XFCE did something similar, see garcon:

https://archive.xfce.org/src/xfce/garcon/?C=M;O=D

0.8/ 22-Dec-2020 23:12 -
4.16/ 15-Jan-2021 15:40

They bumped the 0.8. to 4.16 in 2021.

[FR] Documentation wiki for developers

I know this is a LXQt toolkit only but I think it would be nice to have, for both non LXQt
developers like me using them and possible new developers, a wiki open to some specific
collaborators.

Expected Behavior

Have a wiki for any developer using this toolkit as reference/reminder

Current Behavior

Not a bug.

Possible Solution

See Expected Behavior.

Steps to Reproduce (for bugs)

Context

I'm using this toolkit (partially) to translate some applications of mine.
I wasted some hours to recall the previous work I did on which is the correct way to use them
as developer and which features are not needed/seemingly useless for my needs.

I think also new developers would find useful to have a base guide before looking deep at the CMake code to be ready to go. Plus being a wiki is not required to be complete after publication.

System Information

Irrelevant.

Fix cmake version

3.6.2 was a not so good idea right now and should be changed to 3.1.0 to match the overall project

Problems with LXQtTranslateDesktop.cmake

I'm having errors with LXQtTranslateDesktop.cmake against cmake 3.19. It everywhere fails with the following error:

CMake Error at /usr/share/cmake/lxqt-build-tools/modules/LXQtTranslateDesktop.cmake:62 (string):
string sub-command REPLACE requires at least four arguments.
Call Stack (most recent call first):
some/CMakeLists.txt (lxqt_translate_desktop)

It is obviously a problem with lxqt_translate_desktop macro.

Steps to Reproduce (for bugs)

1. install lxqt-build-tools 0.8.0
2. install cmake 3.19
3. try compiling something from lxqt project

System Information

• Distribution & Version: ArchLinux
• Kernel: 5.10
• Qt Version: 5.15
• Package version: 0.8.0

cmake error Could NOT find GLIB with 0.11.0 when compiling libqtxdg-3.9.0 in Fedora Rawhide

Expected Behavior

I expect to be able to compile libqtxdg-3.9.0 with current lxqt-build-tools 0.11.0, so that I can update LXQt to 1.1.0 in Fedora.

Current Behavior

When building libqtxdg-3.9.0 RPM package, following errors happen

-- Checking for module 'glib-2.0'
--   Found glib-2.0, version 2.73.1
-- Checking for module 'gio-unix-2.0'
--   Found gio-unix-2.0, version 2.73.1
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find GLIB (missing: GLIB_GIO_UNIX_INCLUDE_DIR) (found suitable
  version "2.73.1", minimum required is "2.41.0")
Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake/lxqt-build-tools/find-modules/FindGLIB.cmake:113 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:26 (find_package)

Possible Solution

I don't have any idea how to fix this yet, but I feel it should be similar with this commit
62b77bb807aa2ac2

Steps to Reproduce (for bugs)

1. Build lxqt-build-tools 0.11.0 RPM package. The SRPM is already available here. Or you can fetch the binary RPM from koji
2. Build libqtxdg 3.9.0 with the lxqt-build-tools 0.11.0 in above steps

Context

I'm trying to update LXQt from 1.0.0 to 1.1.0 in Fedora. However I met this issue and don't really know what to do yet.

System Information

• Distribution & Version: Fedora Rawhide (future Fedora 37)
• Kernel: Not relevant
• Qt Version:
• Package version:

# rpm -qa | egrep "glib|qt"
qt5-srpm-macros-5.15.3-1.fc37.noarch
glibc-common-2.35.9000-28.fc37.x86_64
glibc-gconv-extra-2.35.9000-28.fc37.x86_64
glibc-minimal-langpack-2.35.9000-28.fc37.x86_64
glibc-2.35.9000-28.fc37.x86_64
glib2-2.73.1-2.fc37.x86_64
glibc-headers-x86-2.35.9000-28.fc37.noarch
glibc-devel-2.35.9000-28.fc37.x86_64
qt-settings-36.1-1.fc37.noarch
qt5-qtbase-common-5.15.4-4.fc37.noarch
qt5-qtbase-5.15.4-4.fc37.x86_64
qt5-qtbase-gui-5.15.4-4.fc37.x86_64
qt5-rpm-macros-5.15.4-1.fc37.noarch
qt5-qtbase-devel-5.15.4-4.fc37.x86_64
glib2-devel-2.73.1-2.fc37.x86_64
lxqt-build-tools-0.11.0-1.fc37.noarch
qt5-qttools-common-5.15.4-1.fc37.noarch
qt5-qttools-libs-designer-5.15.4-1.fc37.x86_64
qt5-qttools-libs-designercomponents-5.15.4-1.fc37.x86_64
qt5-qttools-libs-help-5.15.4-1.fc37.x86_64
qt5-designer-5.15.4-1.fc37.x86_64
qt5-linguist-5.15.4-1.fc37.x86_64
qt5-qttools-5.15.4-1.fc37.x86_64
qt5-qtsvg-5.15.4-1.fc37.x86_64
qt5-qtdeclarative-5.15.4-1.fc37.x86_64
qt5-doctools-5.15.4-1.fc37.x86_64
qt5-qttools-devel-5.15.4-1.fc37.x86_64
qt5-qtbase-private-devel-5.15.4-4.fc37.x86_64
qt5-qtsvg-devel-5.15.4-1.fc37.x86_64

LXQT_ETC_XDG_DIR definition seems ignored on command line

In my picom-conf fork I'm still using the original compton-conf' lxqt-build-tools setup for translations.
I added a Github Actions workflow to test builds and produce artifacts for download, but when I look into the produced archive, I get a strange path instead /etc/xdg/autostart, where it should install the .desktop file, I guess this because I have a custom Qt install because the version in the GHA Ubuntu image is too old for the project, which uses lxqt-build-tools 0.8.0, which in turns requires Qt 5.15 and the Ubuntu 20.04 image has 5.12.
At this point I saw that LXQT_ETC_XDG_DIR is set in cmake/FindInstallConfigPath.cmake and that it can be also set manually.
I tried locally on my Archlinux system, but it seems that it gets ignored for some reason I don't understand, so what I am doing wrong?

Expected Behavior

LXQT_ETC_XDG_DIR should use the manual setting when defined from CMake command line.

Current Behavior

It still resolve as /etc/xdg/.

Possible Solution

No idea, I don't see any issue in the build tools script.

Steps to Reproduce (for bugs)

1. Test it with an application using lxqt-build-tools, in my case picom-conf
2. Run CMake to configure, build and install the files, I did as following:

cmake -DCMAKE_INSTALL_PREFIX="/usr" -DCMAKE_BUILD_TYPE="Release" -DLXQT_ETC_XDG_DIR="/abcd" -B buildtest
cmake --build buildtest --config Release
DESTDIR="$(pwd)/installtest" cmake --build buildtest --target install

Context

See description.

System Information

• Distribution & Version: Archlinux
• Kernel: 5.14.16-arch1-1
• Qt Version: 5.15.2
• Package version: 0.10.0

GLIB is not found

Trying to build libqtxdg, I get this error:

CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find GLIB (missing: GLIB_GIO_UNIX_INCLUDE_DIR) (found suitable
  version "2.74.0", minimum required is "2.41.0")

However, lib64glib2.0_0-2.74.0-1.mga9.x86_64 is installed
Here is the content of /usr/include/gio-unix-2.0/gio/
gdesktopappinfo.h gfiledescriptorbased.h gunixfdmessage.h gunixinputstream.h gunixmounts.h gunixoutputstream.h

Expected Behavior

GLIB should be found

Current Behavior

GLIB is not found

Possible Solution

Check another file than gunixfdlist.h

System Information

• Distribution & Version: Mageia cauldron
• Package version: lxqt-build-tools-0.11.0

Use lxqt_translate_desktop' TRANSLATION_DIR from a cmake module instead CMakeLists.txt

lxqt_translate_desktop macro accepts a TRANSLATION_DIR as relative path.
Is it possible, as the topic above, to call lxqt_translate_desktop from a module,
say ${CMAKE_CURRENT_SOURCE_DIR}/cmake/module.cmake?
the absolute translation dir path would be ${CMAKE_CURRENT_SOURCE_DIR}/resources/translations,
from the module the relative path is ../resources/translations,
but either way don't work, so I am doing something wrong.

Expected Behavior

It would be nice if it would work also with an absolute path.

Current Behavior

it seems to work only as relative path to the main CMakeLists.txt

Possible Solution

Steps to Reproduce (for bugs)

I should provide a MCVE for this, but should be clear, just want to know if it's possible with current code.

Context

I wrote a QtAppResources.cmake module to automate creation and installation steps for all the translations / desktop / app icon and appstream xml metainfo file. I miss only the addition of translations in the desktop file.
This module is not meant (yet?) to be installed, it's enough to keep in the project for now, added to CMAKE_MODULE_PATH.

System Information

• Distribution & Version: Archlinux
• Kernel: 6.3.9-arch1-1
• Qt Version: 5.15.10
• Package version: lxqt-build-tools-git 0.13.0-1 (built at 2023/06/30)

lxqt-desktop.desktop file installed in wrong location

Expected Behavior

I am installing pcmanfm-qt from the source code.
I'm not sure where the file lxqt-desktop.desktop should be installed.
But I guess it should be in the directory passed with CMAKE_INSTALL_PREFIX.

Current Behavior

The file lxqt-desktop.desktop file is installed in a wrong location.

Possible Solution

Try to install lxqt-desktop.desktop in the directory passed with CMAKE_INSTALL_PREFIX.

Steps to Reproduce (for bugs)

First attempt with Qt 5.15.2 installed in a user directory:

cmake -DCMAKE_INSTALL_PREFIX=/home/julien/pcmanfm-qt-install ..
...
make install
...
-- Installing: /space/julien/pcmanfm-qt/install/Qt-5.15.2/etc/xdg/autostart/lxqt-desktop.desktop

/space/julien/pcmanfm-qt/install/Qt-5.15.2 is my Qt installation.
Why is the file lxqt-desktop.desktop installed with my Qt installation?

Another attempt with Qt 5.12.8 from the Ubuntu installation:

cmake -DCMAKE_INSTALL_PREFIX=/space/julien/pcmanfm-qt/test5.12/install ..
...
make install
...
-- Installing: /etc/xdg/autostart/lxqt-desktop.desktop
CMake Error at autostart/cmake_install.cmake:49 (file):
  file INSTALL cannot copy file
  "/space/julien/pcmanfm-qt/test5.12/pcmanfm-qt-1.0.0/build/autostart/lxqt-desktop.desktop"
  to "/etc/xdg/autostart/lxqt-desktop.desktop": Permission denied.
Call Stack (most recent call first):
  cmake_install.cmake:47 (include)

Why is the file lxqt-desktop.desktop installed in /etc? I requested pcmanfm-qt to be installed in a user directory.

System Information

• PcManFm-qt version: 1.0.0
• Distribution & Version: Kubuntu 20.04
• Qt Version: 5.15.2 / 5.12.8
• liblxqt Version: 1.0.0

Bump minimum version requirements

Required minimum versions are far outdated (0.14.)
A draft is here:
https://github.com/lxqt/lxqt-build-tools/blob/update_min_requirements/README.md

`LXQtTranslateDesktop.cmake` doesn't support yet the freedesktop reverse DNS files naming convention

From the version 1.2 of the freedesktop' desktop entry specification, a File naming section was added, to define a convention by using a reversed DNS form. This is also used by AppStream and implemented on some software. Until now I personally tested it only with AppImage, but still using it for my applications.

Unfortunately LXQtTranslateDesktop.cmake doesn't support this, but just gave for grant that the first part of the filename is the name of the translation to process.

Expected Behavior

The module should find a way to extract the correct part of the filename to build the final YAML filename to pass to LXQtTranslateDesktopYaml.pl to be processed and so inserted in the resulting desktop file.

Current Behavior

Said above, it extract the first "token" of the name, e.g.:
lx-image.desktop => lx-image

Possible Solution

Possibly by just prepend the country code to .desktop.yaml
(appname_it.desktop.yaml and tld.domain.appname_it.desktop.yaml).
See here, though not much elegant changes.

Steps to Reproduce (for bugs)

# lx-image.desktop:
get_filename_component(_inFile   ${_inFile} ABSOLUTE) # /path/to/lx-image.desktop.in
get_filename_component(_fileName ${_inFile} NAME_WE)  # lx-image
get_filename_component(_fileExt  ${_inFile} EXT)      # .desktop after the next line

on line 74 the result is passed to the perl script with a ${_fileName}[_.]*${_fileExt}.yaml,
e.g.: lx-image_it.desktop.yaml

The same process using org.mydomain.myappname.desktop.in results in a org_it.mydomain.myappname.desktop.yaml instead of org.mydomain.myappname_it.desktop.yaml

Context

See above.

System Information

Irrelevant.

Please don't release an alternative version

I just tried to install the current development version of the package and noticed that LBT is going to be installed twice with a v2 version alternative; please don't do that!
In the old version there was support for both qt4 and 5, why add a "2" when the tools are already versioned?
Just implement 2 versions (5 and 6 or 6 and 7) in the same package as before.
This was to me so annoying to use that I gave up trying to contribute some fixes or help an user in the Matrix chat for a simple change.