lxqt / libqtxdg Goto Github PK

Build fails because it can not find Qt5X11Extras package even though lxqt is being built with qt4.

Building: libqtxdg using externally specified options: -DCMAKE_BUILD_TYPE=debug -DCMAKE_INSTALL_PREFIX=/storage/src/lxqt-build  

-- Building with Qt 4.8.6
-- qtxdg: writing pkgconfig file /storage/src/lxqt/libqtxdg/build/qtxdg.pc
-- 
-- For building tests use -DBUILD_TESTS=Yes option.
-- 
-- Configuring done
-- Generating done
-- Build files have been written to: /storage/src/lxqt/libqtxdg/build
Scanning dependencies of target qtxdg
[  3%] [  7%] [ 10%] [ 14%] [ 17%] [ 21%] [ 25%] [ 28%] Building CXX object CMakeFiles/qtxdg.dir/xdgaction.cpp.o
Building CXX object CMakeFiles/qtxdg.dir/xdgdesktopfile.cpp.o                                                                                                          
Building CXX object CMakeFiles/qtxdg.dir/xdgmenu.cpp.o                                                                                                                 
Building CXX object CMakeFiles/qtxdg.dir/xdgmenureader.cpp.o                                                                                                           
Building CXX object CMakeFiles/qtxdg.dir/xdgicon.cpp.o                                                                                                                 
Building CXX object CMakeFiles/qtxdg.dir/xdgmenuapplinkprocessor.cpp.o                                                                                                 
Building CXX object CMakeFiles/qtxdg.dir/xdgdirs.cpp.o                                                                                                                 
Building CXX object CMakeFiles/qtxdg.dir/xdgmenulayoutprocessor.cpp.o                                                                                                  
[ 32%] Building CXX object CMakeFiles/qtxdg.dir/xdgmenurules.cpp.o                                                                                                     
[ 35%] Building CXX object CMakeFiles/qtxdg.dir/xdgmenuwidget.cpp.o                                                                                                    
[ 39%] Building CXX object CMakeFiles/qtxdg.dir/xmlhelper.cpp.o                                                                                                        
[ 42%] Building CXX object CMakeFiles/qtxdg.dir/xdgautostart.cpp.o                                                                                                     
[ 46%] Building CXX object CMakeFiles/qtxdg.dir/qiconfix/qiconloader_qt4.cpp.o                                                                                         
[ 50%] Building CXX object CMakeFiles/qtxdg.dir/xdgmimetype.cpp.o                                                                                                      
[ 53%] Building CXX object CMakeFiles/qtxdg.dir/moc_xdgaction.cxx.o                                                                                                    
[ 57%] Building CXX object CMakeFiles/qtxdg.dir/moc_xdgmenuapplinkprocessor.cxx.o                                                                                      
[ 60%] Building CXX object CMakeFiles/qtxdg.dir/moc_xdgmenu.cxx.o                                                                                                      
[ 64%] Building CXX object CMakeFiles/qtxdg.dir/moc_xdgmenu_p.cxx.o                                                                                                    
[ 67%] Building CXX object CMakeFiles/qtxdg.dir/moc_xdgmenureader.cxx.o                                                                                                
[ 71%] Building CXX object CMakeFiles/qtxdg.dir/moc_xdgmenurules.cxx.o                                                                                                 
[ 75%] Building CXX object CMakeFiles/qtxdg.dir/moc_xdgmenuwidget.cxx.o                                                                                                
Linking CXX shared library libqtxdg.so
[100%] Built target qtxdg
[100%] Built target qtxdg
Install the project...
-- Install configuration: "debug"
-- Installing: /storage/src/lxqt-build/lib/x86_64-linux-gnu/libqtxdg.so.1.0.0
-- Up-to-date: /storage/src/lxqt-build/lib/x86_64-linux-gnu/libqtxdg.so.1
-- Up-to-date: /storage/src/lxqt-build/lib/x86_64-linux-gnu/libqtxdg.so
-- Up-to-date: /storage/src/lxqt-build/include/qtxdg/xdgaction.h
-- Up-to-date: /storage/src/lxqt-build/include/qtxdg/xdgdesktopfile.h
-- Up-to-date: /storage/src/lxqt-build/include/qtxdg/xdgdirs.h
-- Up-to-date: /storage/src/lxqt-build/include/qtxdg/xdgicon.h
-- Up-to-date: /storage/src/lxqt-build/include/qtxdg/xdgmenu.h
-- Up-to-date: /storage/src/lxqt-build/include/qtxdg/xdgmenuwidget.h
-- Up-to-date: /storage/src/lxqt-build/include/qtxdg/xmlhelper.h
-- Up-to-date: /storage/src/lxqt-build/include/qtxdg/xdgautostart.h
-- Up-to-date: /storage/src/lxqt-build/include/qtxdg/xdgmacros.h
-- Up-to-date: /storage/src/lxqt-build/include/qtxdg/xdgmimetype.h
-- Installing: /storage/src/lxqt-build/share/cmake/qtxdg/qtxdg-config.cmake
-- Up-to-date: /storage/src/lxqt-build/share/cmake/qtxdg/qtxdg_use.cmake
-- Installing: /storage/src/lxqt-build/include/qtxdg/XdgAction
-- Installing: /storage/src/lxqt-build/include/qtxdg/XdgDesktopFile
-- Installing: /storage/src/lxqt-build/include/qtxdg/XdgDirs
-- Installing: /storage/src/lxqt-build/include/qtxdg/XdgIcon
-- Installing: /storage/src/lxqt-build/include/qtxdg/XdgMenu
-- Installing: /storage/src/lxqt-build/include/qtxdg/XdgMenuWidget
-- Installing: /storage/src/lxqt-build/include/qtxdg/XmlHelper
-- Installing: /storage/src/lxqt-build/include/qtxdg/XdgAutoStart
-- Installing: /storage/src/lxqt-build/include/qtxdg/XdgMimeType
-- Installing: /storage/src/lxqt-build/lib/x86_64-linux-gnu/pkgconfig/qtxdg.pc


Building: liblxqt using externally specified options: -DCMAKE_BUILD_TYPE=debug -DCMAKE_INSTALL_PREFIX=/storage/src/lxqt-build  

CMake Error at CMakeLists.txt:130 (find_package):
By not providing "FindQt5X11Extras.cmake" in CMAKE_MODULE_PATH this project
has asked CMake to find a package configuration file provided by
"Qt5X11Extras", but CMake did not find one.

Could not find a package configuration file provided by "Qt5X11Extras" with
any of the following names:

    Qt5X11ExtrasConfig.cmake
    qt5x11extras-config.cmake

Add the installation prefix of "Qt5X11Extras" to CMAKE_PREFIX_PATH or set
"Qt5X11Extras_DIR" to a directory containing one of the above files.  If
"Qt5X11Extras" provides a separate development package or SDK, be sure it
has been installed.


-- Configuring incomplete, errors occurred!
See also "/storage/src/lxqt/liblxqt/build/CMakeFiles/CMakeOutput.log".

Hi,
the issue is visible in pcmanfm-qt, but I assume file type detection is handled by libqtxdg from libfm-qt ? Let me know if this issue should be filed somewhere else.

Expected Behavior

unknown .bin files should show up as "application/octet-stream"

Current Behavior

Most .bin files are wrongly identified as "Sega CD disc image" files.

Possible Solution

I've erased and re-written this section many times, I'm not sure there's an easy solution anymore.

It seems if type detection is only glob-based, then this can't be fixed : the sega formats are the only ones with a "*.bin" glob. When testing with different implementations ( mimeinfo, file (1) ), type detection works as expected only if the tool checks the magic value, see tests below. But checking the magic for every file in a directory may cause excessive I/O in the context of pcmanfm-qt ? I'd like to hear dev's opinions on this.

Steps to Reproduce (for bugs)

1. Find or create a bogus .bin file , e.g.
   echo -e "\x00" > test.bin
2. Verify the mimetype with different implementations :

### 'file' uses its own magic database
$ file --brief --mime-type test.bin
application/octet-stream

### mimeinfo uses the system-wide shared MIME-info database, but returns a different type depending on whether the extension is ignored or the magic is verified:

$ mimetype --brief --debug test.bin
> Checking inode type
> Checking globs for basename 'test.bin'
> Checking for extension '.bin'
application/x-sega-cd-rom

$ mimetype --brief --magic-only --debug test.bin
> Checking all magic rules
> File exists, trying default method
> First 10 bytes of the file contain control chars
application/octet-stream

3. with pcmanfm-qt, browse to the directory containing test.bin : the Type column has "Sega CD disc image" which is wrong. Right-click on file -> Properties : the MIME type says "application/x-sega-cd-rom".

Context

see above

System Information

• Distribution & Version: Artix / Arch linux rolling
• Kernel: 4.14.88
• libfm-qt 0.13.1.308 ec51711
• Qt Version: 5.12
• lxqt-build-tools Version: 0.5.0.17-5a489c1
• libqtxdg Version: 3.2.0.17-1a52e5c

After Qt 5.14.2 came to Arch, I saw crashes in screengrab. The cause was in libqtxdg. Recompilation of libqtxdg solved the problem.

Usually, there should be no need to recompile fundamental LXQt components when the third version number of Qt changes. This was an exception.

I close this issue immediately after opening it; just wanted to make distro package maintainers know about it.

P.S. I have the latest git LXQt but think that the latest release (which is very old, BTW) should be affected too.

Consider an icon theme whose icons are all SVG and whose index contains these keys:

...
[places/16]
Size=16
Context=Places
Type=Fixed

[places/22]
Size=22
Context=Places
Type=Fixed

[places/scalable]
Size=96
Context=Places
Type=Scalable
MinSize=16
MaxSize=512
...

With this arrangement, KDE correctly shows the folder icon from places/scalable for folders ≥ 32px while LXQt gets the folder icon from places/16 for all sizes ≥ 32px.

Custom category marks get ignored. For instance, Yumex and Yumex-DNF are expected to be grouped into Administration menu but they show in Settings menu.
Downstream: https://bugzilla.redhat.com/show_bug.cgi?id=1217565

Here's a sample:

$ cat /usr/share/applications/yumex-dnf.desktop 
[Desktop Entry]
Name=Yum Extender (DNF)
Comment=Install, update and remove applications
Categories=System;Settings;X-Red-Hat-Base;X-Fedora;
Icon=yumex-dnf
Exec=/usr/bin/yumex-dnf
Type=Application
Terminal=false
Encoding=UTF-8
GenericName=Software Installer

$ grep Red-Hat /etc/xdg/menus/* 2>/dev/null
/etc/xdg/menus/applications.menu:        <Not><Category>X-Red-Hat-ServerConfig</Category></Not>
/etc/xdg/menus/documentation.menu:      <Category>X-Red-Hat-Base</Category>
/etc/xdg/menus/server-settings.menu:      <Category>X-Red-Hat-Base</Category>
/etc/xdg/menus/server-settings.menu:      <Category>X-Red-Hat-ServerConfig</Category>
/etc/xdg/menus/server-settings.menu:        <Not><Category>X-Red-Hat-Base-Only</Category></Not>
/etc/xdg/menus/server-settings.menu:        <Not><Category>X-Red-Hat-Base</Category></Not>
/etc/xdg/menus/server-settings.menu:        <Category>X-Red-Hat-ServerConfig</Category>
/etc/xdg/menus/system-settings.menu:      <Not><Category>X-Red-Hat-ServerConfig</Category></Not>

-DUSE_QTMIMETYPES=OFF is not in README

I haven't touched Qt 4 support yet because libmagic should be dropped along with it and that requires a lot of messing about to get all of it. @luis-pereira see if you can get that one when you get some time.

Our icon handling is poor with non-digit scale factors.

Expected Behavior

Icons should look sharp with non-digit scale factors too.

Current Behavior

Icons may not look sharp with non-digit scale factors. For example, this is with QT_SCALE_FACTOR=1.5 (see the quit icon):

Possible Solution

KDE had this problem before but they fixed it in Plasma 5.15.0 (or a previous version). So, it should be fixable with Qt 5.12, at least.

Context

Non-digit scale factors are useful with HDPI. With some screens, a scale factor of 2 would be too big.

System Information

Latest LXQt.

Background:
While testing the performance implications of #116 I found three issues solved by commits 48e957b, 44cc641 and bea1939. This issues don't have any relation with #116. #125 contains the same fixes but applied to master.

The comparison will be made between #125 and #126.

Testing hardware:
4GB RAM, Intel(R) Pentium(R) Dual CPU T3400 @ 2.16GHz, Hitachi Travelstar 5K500.B 5400 rpm SATA 2.6, 3.0 Gb/s.

Testing Software:
Linux 4.10.8-1-ARCH
Openbox, with one QTerminal window.

Testing conditions:
Theme used: Tangerine
No gtk-update-icon-cache cache present.
Run 12 times the tst-loadicon-perf script. Disk caches are flushed.

Results:


#125: 342 ms, standard deviation: 5.7049 ms
#126: 976.92 ms, standard deviation: 5.4682 ms

In this setup the fallback branch brings an 2.8 increase in load time. On a very fast machine it's not a issue, but in a weaker one it can be an issue. LXQt targets specially less power full machines.

p.s. On an side note I found that the gtk cache was actually increasing the load time. Will investigate what's happening.

As described in http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html#guidelines

There is an unconditional 'break' within a loop. This is really suspicious :)

It inserts.returns non existent files.

Screengrab has a module for it. More specifically, see it here. We should add that to libqtxdg and use it in our screengrab fork.

1.) Compile qtxdg with local qt (not the one in /usr, but /opt/Qt5.12.2)
2.) link to local qtxdg
/usr/bin/ld: /usr/lib64/libQt5XdgIconLoader.so.3: undefined reference to QIconLoader::instance()@Qt_5.12.1_PRIVATE_API
Why does linking to local install qtxdg (Qt5.12.2), try to load the system xdgiconloader library instead of the local one?

Before latest 2 commits I had icons for WINE apps in "Оther" submenu. Now they are gone.
Example:

/home/ilya/.local/share/applications/wine/Programs/Buka/Герои Меча и Магии III Дыхание Смерти/Герои III Дыхание смерти.desktop

[Desktop Entry]
Name=Герои III Дыхание смерти
Exec=env WINEPREFIX="/home/ilya/.wine" wine C:\windows\command\start.exe /Unix /home/ilya/.wine/dosdevices/c:/users/Public/Start\ Menu/Programs/Buka/Герои\ Меча\ и\ Магии\ III\ Дыхание\ Смерти/Герои\ III\ Дыхание\ смерти.lnk
Type=Application
StartupNotify=true
Path=/home/ilya/.wine/dosdevices/z:/D/Games/HoMM3
Icon=2B9B_Heroes3.0

And icon in

/home/ilya/.local/share/icons/hicolor/16x16/apps/2B9B_Heroes3.0.png

Moving lxqt/lxqt#48 here.

http://standards.freedesktop.org/mime-apps-spec/mime-apps-spec-latest.html

Values extending the format should start with "X-" and we can't handle them.

We need to stop using defaults.list - mimeapps.list is the correct file to check for, afaik.

Though now I'm having second thoughts... Can someone check?

Packagers should be aware of it. How should it be advertised ? Put it in the Release Notes ?

We need to clarify the license of all files to make this library into Debian. Please help to add license header for the following files:

desktopenvironment_p.cpp: No copyright UNKNOWN
test/qtxdg_test.cpp: No copyright UNKNOWN
test/qtxdg_test.h: No copyright UNKNOWN
xdgdesktopfile_p.h: No copyright UNKNOWN

Feature request: it would be cool if XdgDesktopFile had support for actions

See https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s10.html

When linking QtGui and libqtxdg statically to an app, QIconCacheGtkReader and PixmapEntry::pixmap with the ones from qiconloader.cpp

Expected Behavior

libqtxdg should work with static link

Current Behavior

https://github.com/ilya-fedin/tdesktop/runs/645416587?check_suite_focus=true

Possible Solution

Maybe, hide them under namespace? 🤔

Steps to Reproduce (for bugs)

1. Link an app statcally with QtGui and XDGIconLoader at the same time

Context

I tried to link tdesktop static binary with lxqt-qtplugin to allow it to get lxqt system settings (fonts, icon theme, etc), but it requires xdgiconloader from libqtxdg, that has this issue :(

System Information

I hope, this is unrelated (but you have a link to the GH action job) :)

The use of QProcess::startDetached() in XdgDesktopFile::startDetached() makes pkexec exit with "Refusing to render service to dead parents." due to double forking. http://cgit.freedesktop.org/polkit/tree/src/programs/pkexec.c#n730

References:
https://issues.openmandriva.org/show_bug.cgi?id=1128#c3

When using cmake:

CMake Warning at qtxdg/CMakeLists.txt:68 (add_library):
  Cannot generate a safe runtime search path for target Qt5Xdg because files
  in some directories may conflict with libraries in implicit directories:

    runtime library [libQt5Widgets.so.5] in /usr/lib64 may be hidden by files in:
      /home/styling/Qt/5.6/gcc_64/lib
    runtime library [libQt5Xml.so.5] in /usr/lib64 may be hidden by files in:
      /home/styling/Qt/5.6/gcc_64/lib
    runtime library [libQt5Gui.so.5] in /usr/lib64 may be hidden by files in:
      /home/styling/Qt/5.6/gcc_64/lib
    runtime library [libQt5Core.so.5] in /usr/lib64 may be hidden by files in:
      /home/styling/Qt/5.6/gcc_64/lib

  Some of these libraries may not be found correctly.

Then with make

[  3%] Building CXX object xdgiconloader/CMakeFiles/Qt5XdgIconLoader.dir/xdgiconloader.cpp.o
In file included from /home/styling/repositories/libqtxdg/xdgiconloader/xdgiconloader.cpp:34:0:
/home/styling/repositories/libqtxdg/xdgiconloader/xdgiconloader_p.h:56:29: fatal error: private/qicon_p.h: No such file or directory
compilation terminated.
xdgiconloader/CMakeFiles/Qt5XdgIconLoader.dir/build.make:62: recipe for target 'xdgiconloader/CMakeFiles/Qt5XdgIconLoader.dir/xdgiconloader.cpp.o' failed
make[2]: *** [xdgiconloader/CMakeFiles/Qt5XdgIconLoader.dir/xdgiconloader.cpp.o] Error 1
CMakeFiles/Makefile2:117: recipe for target 'xdgiconloader/CMakeFiles/Qt5XdgIconLoader.dir/all' failed
make[1]: *** [xdgiconloader/CMakeFiles/Qt5XdgIconLoader.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2

I couldn't figure out what to do about it.

The Qt version in /home was installed for other projects via:
https://wiki.qt.io/Install_Qt_5_on_openSUSE

I'm on openSUSE Tumbleweed.

tried to switch over to qtmimetypes now libqtxdg fails at linking stage..
maybe a cmake configuration typo somewhere??

ing CXX object CMakeFiles/qtxdg.dir/moc_xdgmenurules.cxx.o
[100%] Building CXX object CMakeFiles/qtxdg.dir/moc_xdgmenuwidget.cxx.o
Linking CXX shared library libqtxdg.so
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lQtCore
collect2: error: ld returned 1 exit status
make[2]: *** [libqtxdg.so.1.0.0] Error 1
make[1]: *** [CMakeFiles/qtxdg.dir/all] Error 2
make: *** [all] Error 2

Obviously I have qtcore installed and all other qt programs (including lxqt!) find it without any issue

if i build with USE_QTMIMETYPES=OFF it will link fine

I currently have qtmimetypes installed:
libqtxdg success the build with -DUSE_QTMIMETYPES=OFF

drwxr-xr-x root/root         0 2014-09-20 00:08 install/
-rw-r--r-- root/root       346 2014-09-20 00:08 install/doinst.sh
-rw-r--r-- root/root       341 2014-09-20 00:08 install/slack-desc
drwxr-xr-x root/root         0 2014-09-20 00:08 usr/
drwxr-xr-x root/root         0 2014-09-19 23:49 usr/include/
drwxr-xr-x root/root         0 2014-09-20 00:08 usr/include/QtMimeTypes/
-rw-r--r-- root/root        23 2014-09-03 02:54 usr/include/QtMimeTypes/QMimeType
-rw-r--r-- root/root      3554 2014-09-03 02:54 usr/include/QtMimeTypes/qmimetype.h
-rw-r--r-- root/root      3467 2014-09-03 02:54 usr/include/QtMimeTypes/qmimedatabase.h
-rw-r--r-- root/root       985 2014-09-03 02:54 usr/include/QtMimeTypes/qmime_global.h
-rw-r--r-- root/root        27 2014-09-03 02:54 usr/include/QtMimeTypes/QMimeDatabase
drwxr-xr-x root/root         0 2014-09-20 00:08 usr/lib/
drwxr-xr-x root/root         0 2014-09-20 00:08 usr/lib/pkgconfig/
-rw-r--r-- root/root       643 2014-09-20 00:08 usr/lib/pkgconfig/QtMimeTypes.pc
-rwxr-xr-x root/root    457592 2014-09-20 00:08 usr/lib/libQtMimeTypes.so.1.0.1
drwxr-xr-x root/root         0 2014-09-20 00:08 usr/doc/
drwxr-xr-x root/root         0 2014-09-20 00:08 usr/doc/qtmimetypes-0.0.0/
-rw-r--r-- root/root     26434 2014-09-20 00:08 usr/doc/qtmimetypes-0.0.0/LICENSE.LGPL

Here is my error log:

 return ((int*)(&Q_WS_QWS))[argc];
#else
  (void)argc;
  return 0;
#endif
}

Determining if the Q_WS_MAC exist failed with the following output:
Change Dir: /tmp/SBo/libqtxdg/build/CMakeFiles/CMakeTmp

Run Build Command:/usr/bin/gmake "cmTryCompileExec3379417551/fast"
/usr/bin/gmake -f CMakeFiles/cmTryCompileExec3379417551.dir/build.make CMakeFiles/cmTryCompileExec3379417551.dir/build
gmake[1]: Entering directory `/tmp/SBo/libqtxdg/build/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report /tmp/SBo/libqtxdg/build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building CXX object CMakeFiles/cmTryCompileExec3379417551.dir/CheckSymbolExists.cxx.o
/usr/bin/c++    -O2 -fPIC  -I/usr/lib64/qt/include    -o CMakeFiles/cmTryCompileExec3379417551.dir/CheckSymbolExists.cxx.o -c /tmp/SBo/libqtxdg/build/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx
/tmp/SBo/libqtxdg/build/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx: In function �^�^�int main(int, char**)�^�^�:
/tmp/SBo/libqtxdg/build/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx:8:19: error: �^�^�Q_WS_MAC�^�^� was not declared in this scope
   return ((int*)(&Q_WS_MAC))[argc];
                   ^
gmake[1]: *** [CMakeFiles/cmTryCompileExec3379417551.dir/CheckSymbolExists.cxx.o] Error 1
gmake[1]: Leaving directory `/tmp/SBo/libqtxdg/build/CMakeFiles/CMakeTmp'
gmake: *** [cmTryCompileExec3379417551/fast] Error 2

File /tmp/SBo/libqtxdg/build/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx:
/* */
#include <QtCore/qglobal.h>

int main(int argc, char** argv)
{
  (void)argv;
#ifndef Q_WS_MAC
  return ((int*)(&Q_WS_MAC))[argc];
#else
  (void)argc;
  return 0;
#endif
}

lxqt-config-powermanagement.desktop.in Has line Icon=preferences-system-power-management
and I see icon in source code folder. But lxqt-config-powermanagement.desktop in menu has no icon.

P.S. First screen is from pcmanfm-qt

Based on part of #6

Reference lxqt/lxqt-panel@e68d738

Please help do bump soversion in libqtxdg because 0.5.2 and 0.5.3 are not compatible.

We are currently trying to create debian packages for LXQt. To do so, we need libqtxdg 0.5.3. However, debian already has libqtxdg 0.5.2 for Razor-qt, and we don't want to break Razor-qt when integrating LXQt. The problem is, libqtxdg 0.5.2 and 0.5.3 have incompatible API changed (0.5.2 API is in here, while 0.5.3 API is in here), so we can not just upgrade libqtxdg to 0.5.3, cause it will definitely break Razor-qt, which is something we need to avoid.

Since 0.5.2 and 0.5.3 are incompatible, we suggest to bump soversion of libqtxdg so that 0.5.2 and 0.5.3 are coinstallable for debian, and other distribution. In this way, we can do a smoother transition for Razor-qt and LXQt.

When I run Hawaii and XDG_DATA_DIRS is empty I don't see the menu.
I believe that libqtxdg should assume a default as said by the specification [1].
Setting XDG_DATA_DIRS make it work.

[1] = http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

Moving Razor-qt bug from: Razor-qt/razor-qt#520

Assigning to @pvanek. If this isn't relevant anymore, just close.

The problem:
QIcon can only has one icon name. When the icon does not exist in the current theme, it simply breaks.
The qtxdg library provides a method to improve this:
QIcon XdgIcon::fromTheme(const QStringList& iconNames, const QIcon& fallback)
However, this find the fallback icon on QIcon creation only. When the icon theme changes, the previously stored icon name might become invalid in the new theme.

The proposed solution:
Storing the list of all icon names in XdgIconLoaderEngine.
Then when creating a new QIcon via XdgIcon::fromTheme(), create a XdgIconLoaderEngine with a list of possible icon names, and then create QIcon using the ctor that accepts an icon engine instead.
QIcon::QIcon(QIconEngine* engine)

After theme change, clear the pixmap cache used by QIcon so all pixmaps need to be re-generated.
When a pixmap needs to be generated again, we have the full icon name list in the icon engine ,so we can pick the most suitable icon name from the list for the current theme.

@luis-pereira What do you think?
The selection of the most suitable icon name from the list is done when generating the pixmap for the first time rather than when creating the QIcon object. The other parts remain the same and require no changes.

I am not sure, if this is the right place to post this issue.
If not, please tell me what the right package is to report this issue.

When opening a magnet link from the browser, a new browser window is opened instead of my default application set by xdg-mime.

After some investigation I noticed that the following command gives me the same result.

xdg-open magnet:asdfjasdljffdsaadsf

After some debugging I noticed that there are two versions of xdg-open on my system.

/usr/bin/xdg-open
/usr/lib64/lxqt-xdg-tools/xdg-open

By using the command below I found out that the last one is set as default.

which xdg-open

Unfortunately this version doesn't work for magnet links (and maybe more). The version in /usr/bin works correct.

Does anybody know what the reason is for this copy of xdg-open?

I noticed with a diff that there are quite some differences.
Isn't it better to stick to the original (and maintained) version of xdg-open?

If the answer to the last question is 'no', would you mind to fix the magnet link issue?

Cheers,
Arthur.

Attempting to launch a program crashes the panel and whole session, if:

1. There is already a running (but frozen / hanging / crashed) instance
2. In the desktop file it is marked as DBus Activatable

How to reproduce:

1. Use lxqt
2. Open terminal
3. Run e.g gnome-maps (or a program which has DBusActivatable=true in its desktop file)
4. Hit ctrl + z
5. Try to open gnome-maps from lxqt-panel-menu
6. Everything freezes
   (Recent DBusActivatable version required of course)

Changing the value in the desktop file from
DBusActivatable=true
to
DBusActivatable=false

PS: if the program is dbus activatable and just has a slow startup the ui freezes until it starts

confirms this is the issue (the session and panel do not freeze with DBusActivatable=false)

$ xdg-mime query default inode/directory
nautilus-folder-handler.desktop

I assume the correct result for now would be pcmanfm.desktop

A tool to allow executing from the command line.

WIP

When an lxqt application calls

XdgIcon::fromTheme(const QString& iconName, const QIcon& fallback)

with a relative path, this will redirect to

new QIcon(new QtXdg::QIconLoaderEngineFixed(name));

As QIconLoader::setThemeName(...) does not get called, m_userTheme is not set. Therefore, the class is looking for system themes in systemThemeName(). As that function is broken (in my case, Qt 5.4.1), the class will fall back to fallbackTheme() which always yields "hicolor" for me.

As all of this is happening in the qiconloader.cpp and this file seems to be copied from Qt, I guess that my Qt version could be responsible for this issue.

I could resolve this issue by changing the systemThemeName() function like that:

static inline QString systemThemeName()
{
    if (const QPlatformTheme *theme = QGuiApplicationPrivate::platformTheme()) {
        const QVariant themeHint = theme->themeHint(QPlatformTheme::SystemIconThemeName);
        bool isEmpty = themeHint.toString().isEmpty(); // In my case, themeHint is always just an empty string: ""
        if (themeHint.isValid() && !isEmpty)
            return themeHint.toString();
    }
    return QIcon::themeName();
}

Finally, I am wondering why this file, which is explicitly not part of the Qt API, was copied to libqtxdg. Isn't that inherently leading to problems with future Qt versions? Could someone explain to me why we need that file and what it does for us? Why can't we just use QIcon::setThemeName(themeName) and QIcon::themeName()?

As @paulolieuthier stated here. It's always returning true.
Makes lxqt/lxqt-panel#365 not needed.

and every method that accepts more than one icon (excluding fallback).
Rationale: lxqt/lxqt-panel@f032936

Get and set XDG user dirs variables in config file

• 0d80985

https://mediacru.sh/8ucES5_q6k4W.jpg

Fixes an FTBFS in the Qt4 build

• bd9510f

https://mediacru.sh/KTUD2kWr1Iky.jpg - icons missed

https://mediacru.sh/0SWYFa7RBuXi.jpg

Attempts to install into "/usr/lib64/qt5/plugins/iconengines/libQt5XdgIconPlugin.so" even though CMAKE_INSTALL_PREFIX is set to "~/usr". In the same build libQt5XdgIconLoader.so installs correctly into "~/usr/lib64/libQt5XdgIconLoader.so".

Expected Behavior

Install into "~/usr/lib64/libQt5XdgIconPlugin.so".

Current Behavior

Attempts to install into "/usr/lib64/qt5/plugins/iconengines/libQt5XdgIconPlugin.so".

Possible Solution

Update lxqt/libqtxdg/src/xdgiconloader/plugin/CMakeLists.txt to account for CMAKE_INSTALL_PREFIX. I am attempting to do this myself and will update the issue if I can get it working (I am new to CMAKE).

Steps to Reproduce (for bugs)

1. mkdir build
2. cd build
3. cmake -DCMAKE_BUILD_TYPE=debug -DCMAKE_INSTALL_PREFIX=/home/rwilliamson/usr ..
4. make
5. make install

CMake Error at src/xdgiconloader/plugin/cmake_install.cmake:55 (file):
file INSTALL cannot copy file
"/home/rwilliamson/build/lxqt/libqtxdg/build/src/xdgiconloader/plugin/libQt5XdgIconPlugin.so"
to "/usr/lib64/qt5/plugins/iconengines/libQt5XdgIconPlugin.so".

Context

Building without installing into main system.

System Information

Fedora LXQT 30. Using Toolbox.
Qt 5.12.5 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 9.2.1 20190827 (Red Hat 9.2.1-1)) on "xcb"
OS: Fedora 30 (Container Image) [linux version 5.3.6-200.fc30.x86_64]

• Distribution & Version: Head from git.
• Kernel: Linux 5.3.6-200.fc30.x86_64 x86_64
• Qt Version: 5.12.5
• cmake Version: 3.14.5
• lxqt-build-tools Version: Head from git.
• Package version: N/A

Hi,

I am not sure if this is a real bug and neither I am sure if this is the library responsible for it, but while debugging another issue on my system regarding xdg-open, I noticed that the variable XDG_CURRENT_DESKTOP is set to Razor (by executing the 'env' command).

Shouldn't this become something like XDG_CURRENT_DESKTOP=Lxqt ?

Cheers,
Arthur.

I'm not sure if this is the right section.

Magnet links opened from inside the browser don't open Transmission Qt. I put this inside '/usr/share/applications/mimeinfo.cache':

[MIME Cache]
x-scheme-handler/magnet=transmission-qt.desktop;

And this inside '/usr/local/share/applications/defaults.list':

[Default Applications]
x-scheme-handler/magnet=transmission-qt.desktop;

It's important to notice that 'transmission-qt.desktop' exists and it's pointing to the right exec command. Also, Transmission Qt is working fine and it downloads magnets link if you paste inside it manually

The icon lookup algorithm works by always looking up filenames in directories (stat). The goal here is implement a caching mechanism to reduce the number of required stat's lookup an icon.

I already started doing it 😄