some keyboard shortcuts are not working
excalibur1234 opened this issue · 94 comments
some keyboard shortcuts, e.g. CTRL+C, CTRL+V, CTRL+X, DEL, do not work in pcmanfm-qt and lximage-qt, but they work in other apps (e.g. firefox, kwrite). these non-working keyboard shortcuts are also not shown in the menu as shown in the following screenshot:
other keyboard shorcuts like F2, F3, ALT+Return work flawlessly.
i have had this problem for quite a while now. please look at the last post in bug report #326 for reference. first, i thought it is a problem of qt5.6, but i have currently qt5.7 installed on my system and the problem persists. also, i have thought it is an issue of the lxqt 0.10 packages from the main arch linux repositories, but yesterday i have reinstalled my complete system including all the latest git versions of lxqt, but the problem is still there.
i am running a really light manjaro setup, which means it is possible i am missing a (basic) package, which is neither defined as dependency in arch linux official packages nor AUR (git) packages of lxqt.
does anybody have the same problem?
Running latest LXQt checkouts on Arch Linux I cannot confirm your findings. The problem is affecting PCManFM-Qt and LXImage-Qt hence exactly the two applications relying on libfm-qt. All in all this suggests there's some dependency issue at your side.
To track the problem down I'd suggest the following steps
- Remove each and every LXQt bit from the system in question. Thoroughly make sure that optional different ways to install are all considered. E. g. if you'd have installed both manually and using pre-built or AUR packages make sure that no remnants are left,
updatedb,locate, whatever. - Rebuild all LXQt components, e. g. by using AUR packages. Make sure that the order depicted here is respected. This is crucial.
- Create a new user profile and look whether you can reproduce your findings in this profile.
@excalibur1234
Your problem is very interesting to me because it seems impossible and yet it has happened to you.
The fact that those shortcuts don't show up on menus indicates that they don't exist as far as Qt is concerned. Please test this:
● Download the source of pcmanfm-qt from https://github.com/lxde/pcmanfm-qt → Clone or download → Download ZIP.
● Extract the ZIP file, go to the folder pcmanfm and open the file main-win.ui with Qt Designer (V5).
● Click on Preview... in the Form menu and see if the shortcuts are shown on menus.
@pmattern, can this be a translation issue? Have you tested German?
My tests were on a system with locale de_DE.UTF-8.
My tests were on a system with locale de_DE.UTF-8.
Good! So we're sure it isn't about translation.
In my computer its happening the same but with del button only. I don't know how to solve it. In the rest of the system/programs, the del button works.
Looking at image it seems that some KF5 plugin is there (I see those underscore so I guess its it).
And it probably spoils everything.
( if u could test and purge all KF5 packages :D, and send bug to KF5)
finally i have found the cause of this problem: the german locale.
for a long time, i have thought it might be my build of lxqt, which messed up my keyboard shortcuts. then, i thought it is a bug in qt.
yesterday, i have installed manjaro lxqt with an english locale and all keyboard shortcuts worked. when i switched the locale to german, they stopped working. this happened on stable lxqt 0.11 !
it does not matter, which keyboard layout is used, but which locale.
go to start menu --> preferences --> lxqt settings --> locale. there, switch the "region" to "deutschland - deutsch (de_DE)". then, log out and back in and the keyboard shortcuts will stop working!
here are 2 screenshots for prove: one with german locale, the other with english locale. all other settings are identical.
@excalibur1234
@pmattern has the german locale too. Most probably, the problem is fixed in the latest version but please don't close this issue until you're sure.
i have tested this on 4 machines:
- a virtualbox of manjaro lxqt installed in german with lxqt 0.11 stable.
- a virtualbox of manjaro lxqt installed in english with lxqt 0.11 stable.
- a virtualbox of manjaro xfce. i manually installed the "lxqt" metapackage with lxqt 0.11 stable.
- my real machine running the latest (=yesterdays) builds (from github) of lxqt.
in every case i could change the following setting to "united states (en_US)" / "deutschland - deutsch (de_DE)" and my keyboard shortcuts (not) worked:
start menu --> preferences --> lxqt settings --> locale. there, switch the "region".
i am now running in english locale and all keyboard shortcuts are working. finally, i have found a workaround! nevertheless, it would be nice to fix this issue.
nevertheless, it would be nice to fix this issue.
@excalibur1234, did you read my reply (#401 (comment))?
Guys, have u noticed that excalibur has underscores in menus in both german and english ?
Does anyone else has it ?
I already told this is some kf5 bs plugin, and Im 99% its screwing shortcuts.
Guys, have u noticed that excalibur has underscores in menus in both german and english ?
If underscore was the cause, it would affect English too.
@tsujan, yes i have read your reply.
maye we are misunderstanding each other.
i do not think this issue is fixed, but i found a workaround.
my reply states that the issue persists on the latest version of lxqt. @pmattern has confirmed earlier that he is running the german locale and does not have the issue. this was a reason why it took me so long to find a workaround: i never thought it could be the german locale.
@pmattern has recommended in his first post in this thread, to test on multiple systems with different kinds of lxqt packages. this is what i did (and described in my last post). i could reproduce the issue on multiple different systems (though inside of virtualbox) with differnt kinds of lxqt packages.
the only thing left i could test: boot windows7, install virtualbox, and installl manjaro lxqt inside virtualbox.
my base system is pretty minimal and i have not even all components of lxqt installed. inside virtualbox, i have only the lxqt metapackage from the manjaro/arch repositories installed. therefore, if a kf5 plugin is the cause of the issue, it has to be a package, which is installed by default with lxqt. in that case, @pmattern would have the same issue...
just check: env | grep QT
if u see any kde5/kf5
or QT_PLUGIN_PATH leads to some strange location unset it.
those 2 should be set:
QT_QPA_PLATFORMTHEME=lxqt
QT_PLATFORM_PLUGIN=lxqt
nothing strange:
Sorry! My mistake.
In the German translation, Del is translated into Entf and Ctrl into Strg. That should be correct because it works for @pmattern. Do you have a German keyboard layout?
it does not matter, which keyboard layout is used...
Weird! Because you said only CTRL and DEL had problem. I have no idea then.
yes, i am using english locale and german keyboard layout. everything works.
it also works, if i use an english keyboard layout.
i had the most problems with CTRL and DEL (mostly in pcmanfm-qt), but it was really strange:
- CTRL and DEL never worked in pcmandm-qt
- some keyboard shortcuts with CTRL did work in kwrite, featherpad, notepadqq. some did not.
- all keyboard shortcuts (which i use) with CTRL worked in qterminal.
overall, a really weird issue.
Meanwhile I realized the problem as depicted above exists in a KVM/QEMU virtual machine here as well while it still isn't reproducible running "bare metal". Funny enough both systems are set up the very same way. PCManFM-Qt 6cb0e9d on the former and 952edee on the latter which should hardly matter, though. /usr/share/pcmanfm-qt/translations/pcmanfm-qt_de.qm the same on both systems according to the hash sums, comes to no surprise as both commits of PCManFM-Qt should have used the same of lxqt-l10n according to its Git log.
Also, not only German is affected. E. g. running it_IT.UTF-8 keys Ctrl-{C,X,V} work as expected but Del doesn't and all this is reflected consistently by (not) displaying those keys in menu "Edit".
All shortcuts in question work as expected in other Qt applications like FeatherPad.
This may or may not be related to this issue but is worth mentioning. KDE has an old annoying bug that they call a "feature": by enforcing shortcut accelerators (which can be seen as underlies withAlt), KDE disables some app shortcuts. There are several discussions about it and disabling it on the Internet
Now, this may be pertinent if you somehow use a KDE component (other than kwin) under LXQt.
BTW, is this issue valid anymore?
i have just tested it on another computer with manjaro+lxqt+kwin installed.
this issue is still there.
@pmattern could partially reproduce this issue in QEMU.
i am still using the workaround i found: i select english as locale and all keyboard shortcuts work.
@excalibur1234 Is any KDE process running other than kwin's? I ask because I've seen that KDE apps sometimes start unneeded KDE processes (because of that, I never use KDE apps inside LXQt).
the following processes are running on my system (i excluded some obvious non-kde processes like lxqt, qterminal, sddm, and some personal stuff):
~ > ps -aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 203268 6972 ? Ss 12:42 0:01 /sbin/init
root 86 0.0 0.0 0 0 ? S 12:42 0:00 [oom_reaper]
root 87 0.0 0.0 0 0 ? S< 12:42 0:00 [writeback]
root 88 0.0 0.0 0 0 ? S 12:42 0:00 [kcompactd0]
root 89 0.0 0.0 0 0 ? SN 12:42 0:00 [ksmd]
root 90 0.0 0.0 0 0 ? SN 12:42 0:00 [khugepaged]
root 91 0.0 0.0 0 0 ? S< 12:42 0:00 [crypto]
root 92 0.0 0.0 0 0 ? S< 12:42 0:00 [kintegrityd]
root 93 0.0 0.0 0 0 ? S< 12:42 0:00 [kblockd]
root 94 0.0 0.0 0 0 ? S 12:42 0:00 [kworker/5:1]
root 95 0.0 0.0 0 0 ? S< 12:42 0:00 [edac-poller]
root 97 0.0 0.0 0 0 ? S< 12:42 0:00 [watchdogd]
root 100 0.0 0.0 0 0 ? S 12:42 0:00 [kswapd0]
root 114 0.0 0.0 0 0 ? S< 12:42 0:00 [kthrotld]
root 274 0.0 0.0 0 0 ? S< 12:42 0:00 [kworker/3:1H]
root 277 0.0 0.0 0 0 ? S< 12:42 0:00 [iprt-VBoxWQueue]
root 278 0.0 0.0 0 0 ? S< 12:42 0:00 [kworker/4:1H]
root 280 0.0 0.0 44716 4700 ? Ss 12:42 0:00 /usr/lib/systemd/systemd-udevd
polkitd 505 0.0 0.1 529004 17776 ? Ssl 12:42 0:02 /usr/lib/polkit-1/polkitd --no-debug
rtkit 599 0.0 0.0 181120 2700 ? SNsl 12:42 0:00 /usr/lib/rtkit/rtkit-daemon
root 640 0.0 0.0 437156 10824 ? Ssl 12:42 0:04 /usr/lib/udisks2/udisksd
root 701 0.0 0.0 313912 8672 ? Ssl 12:42 0:00 /usr/lib/upower/upowerd
excalib+ 12739 0.0 0.0 39944 4140 pts/1 R+ 23:14 0:00 ps -aux
excalib+ 12953 0.1 0.5 3072068 92248 ? Sl 20:15 0:11 kwin_x11
excalib+ 12960 0.0 0.1 378472 22372 ? Sl 20:15 0:00 /usr/bin/kglobalaccel5
excalib+ 12984 0.0 0.0 282348 6628 ? Ssl 20:15 0:00 /usr/lib/gvfs/gvfsd
excalib+ 12991 0.0 0.0 413488 7808 ? Sl 20:15 0:00 /usr/lib/gvfs/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes
excalib+ 12995 0.0 0.0 358512 6776 ? Sl 20:15 0:00 /usr/lib/gvfs/gvfsd-trash --spawner :1.7 /org/gtk/gvfs/exec_spaw/0
excalib+ 13012 0.0 0.0 357716 10588 ? Ssl 20:15 0:00 /usr/lib/gvfs/gvfs-udisks2-volume-monitor
excalib+ 13021 0.0 0.0 278860 6416 ? Ssl 20:15 0:00 /usr/lib/gvfs/gvfs-gphoto2-volume-monitor
excalib+ 13025 0.0 0.0 266492 5032 ? Ssl 20:15 0:00 /usr/lib/gvfs/gvfs-mtp-volume-monitor
excalib+ 13043 0.0 0.0 189788 5424 ? Ssl 20:15 0:00 /usr/lib/menu-cache/menu-cached /run/user/1000/menu-cached-:0
excalib+ 13060 0.0 0.3 683212 56456 ? Sl 20:15 0:00 /usr/bin/nm-applet
excalib+ 13079 0.0 0.0 36580 3396 ? S 20:15 0:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibil
excalib+ 15355 0.0 0.0 192980 5472 ? Ssl 20:23 0:00 /usr/lib/gvfs/gvfsd-metadata
i do not see any obvious kde processes, which look suspicious.
one more thing i can think about: when i installed "kwin", i also installed "systemsettings". there is a "shortcuts" setting in "systemsettings", but it is used to define web shortcuts and has nothing to do with keyboard shortcuts.
excalib+ 12960 0.0 0.1 378472 22372 ? Sl 20:15 0:00 /usr/bin/kglobalaccel5
@excalibur1234 What I'm suspicious about is what is sometimes called "automatic mnemonics" under KDE. The story is that, several months ago I started to work under KDE (to patch Dolphin). I was surprised to see that FeatherPad's shortcuts sometimes didn't work. After an hour of confusion, I saw similar issues on the Internet, all of which were caused by "automatic mnemonics".
Now, whether kglobalaccel5 is responsible or not, I don't know. When I run kwin under LXQt, I have it too but see no problem with shortcuts, as you don't see a problem with the English locale either.
Please see this just as a speculation -- although KDE's "automatic mnemonics" is not a speculation at all, as it caused me a headache until I found a workaround for it -- so don't count on it. The similarity between this and my experience under KDE made me tell you about it.
the only other thing I can think of is what I said at #401 (comment).
When I looked at the German translation at that time, Del and Ctrl were translated but F2, F3 or ALT+Return weren't.
kglobalaccel is a dependency of kxmlgui, which is a dependency of kbookmarks, which is a dependency of kio, which is a dependency of kdeclarative, which is a dependency of kscreenlocker, which is a dependency of kwin.
everybody, who uses kwin also has kglobalaccel installed and should have the same problems i have with non-english locale. this is not the case, but kglobalaccel could still contribute to the problem somehow. maybe, translations also play a role as @tsujan has mentioned.
can @pmattern reproduce this issue using kwin as window manager?
@excalibur1234 As for translation, if you recompile pcmanfm-qt without it (by removing lxqt_translate_ts(...) from pcmanfm-qt/pcmanfm/CMakeLists.txt, for example), you could check whether it's the cause.
Or an easier way for you could be using openbox for a few minutes to see if the problem is caused by kwin. Either way, one possibility might be ruled out.
i just did a test with manjaro+lxqt+openbox (no kwin or kglobalaccel installed) in virtualbox.
i could reproduce the exact issue i am having all this time: keyboard shortcuts are fine with english locale but are not shown as available with german locale.
this should rule out kwin as the source of the problem.
this should rule out kwin as the source of the problem.
Yes!
So, it only remains to compile pcmanfm-qt without translation (or with a German translation in which Del and Ctrl aren't translated -- but let's forget this for now). You don't need to install it. Just get the source, remove lxqt_translate_ts(...) from pcmanfm-qt-master/pcmanfm/CMakeLists.txt, open a terminal inside the source and:
mkdir build && cd build
cmake ..
make
Then, inside the same terminal, ./pcmanfm/pcmanfm-qt runs it provided that pcmanfm-qt is first stopped completely in LXQt Session Settings
compiling pcmanfm-qt without translations works: all keyboard shortcuts get displayed and work.
but i do not really find this result noteworthy, because it is the same as my workaround: i get a pcmanfm-qt with english locale and working keyboard shortcuts.
i did another test with building the latest git version of all lxqt components from the AUR as described in the wiki here: https://github.com/lxde/lxqt/wiki/Building-from-source
the result was the same: working keyboard shortcuts in english locale and non-working keyboard shortcuts in german locale.
btw, i could not build the latest git version with lxqt-l10n (because lxqt-l10n conflicts with almost all other lxqt packages).
@excalibur1234 If it also happens with LANGUAGE=de pcmanfm-qt but with an English locale, I could do further tests myself. Does it?
This is what I mean: in pcmanfm-qt_de.ts, Ctrl+N is translated into Strg+N -- and the same for other Ctrl shorrtcuts -- and Del is translated into Entf, while Alt+Return is translated into Alt+Return. But, for example, in pcmanfm-qt_ru.ts, Ctrl is always Ctrl and Del is always Del.
if i do LANGUAGE=de ./pcmanfm/pcmanfm-qt as described in your post above (pcmanfm-qt gets compiled without translations), i still get an english version of pcmanfm-qt. all keyboard shortcuts work in that version of pcmanfm-qt.
imho, this is not surprising.
if i do LANGUAGE=de pcmanfm-qt as you have suggested, the regularly installed version of pcmanfm-qt starts. of course, the keyboard shortcuts do not work in that version as it did all the times before in my tests.
That's good news because I might be able to test with English locale and hope that the issue will be reproducible.
EDIT: I first have to recompile pcmanfm-qt with translations.
Could you explain Strg instead of Ctrl in German and why there isn't such a change in some other languages I checked? (see my previous comment)
I know Strg is for Ctrl in German; I'm just suspicious about translating keyboard shortcuts, which is done in pcmanfm-qt_de.ts for Ctrl and Del.
on german keyboards the CTRL key is labeled STRG.
the DEL key is labeled ENTF.
the ALT key is labeled ALT.
the ESC key is labeled ESC.
i did some quick tests and here are the results:
- STRG key does not work (in any comination) with german locale
- ALT key does not work
- F2 (and other function keys) work as intended
most germans would probably be irritated, if "CTRL+C" is shown in pcmanfm-qt as keyboard shortcut for copying.
This is exactly what I can see in Qt Linguist's preview widget -- at last a way to reproduce it: Ctrl+N isn't shown in Qt Linguist's preview menu either but when I change its translation from Strg+N to Ctrl+N, it'll be shown. I have a Lenovo laptop with English keyboard but keyboard labels may not matter.
Therefore, my first guess is my last guess up to now: Maybe, keyboard shortcuts shouldn't be translated. Whether this is a bug in Qt or something that should be respected from start, I don't know.
However, a question remains unanswered: Why can't @agaida and @pmattern reproduce this? Are their keyboards different from yours? @pmattern isn't accessible but.... @agaida, is there anything special about your keyboard?
most germans would probably be irritated, if "CTRL+C" is shown in pcmanfm-qt as keyboard shortcut for copying.
This kind of irritation changes the matter ;) Now I think there may be something special about your keyboard, apart from its labels, or something wrong in your locale.
i have tested this with 3 different (standard german) keyboards: 2 standalone keyboards and 1 laptop keyboard.
the keyboard shortcuts did not work on any system.
apart from the laptop keyboard (these kinds of keyboards have always special function keys) the other keyboards are nothing special (like a gamer keyboard or something) at all.
i cannot tell you why besides of @pmattern nobody can reproduce this issue. this is also a mystery to me.
Wow! See this: notepadqq/notepadqq#167. This is exactly about the same problem and the solution is exactly what I said.... But let's not jump into conclusion
This problem is known to many. This is just another example for German: http://www.qtcentre.org/threads/62774-Translation-of-Shortcuts . We have to find a solution without annoying our good german users by showing them a Ctrl instead of Strg, etc.
My conclusion: This is a Qt bug. I saw some places where a similar bug was reported and closed but people were still annoyed by the same problem afterward.
@excalibur1234 You said that shorcuts work with QTerminal. That's because Ctrl -- among other thins ;) -- isn't translated there:
We have only 2 workarounds, IMO: (1) Removing shortcut translations or (2) making shortcuts "untranslatable" in Qt designer. The second method seems better to me.
Any opinion?
Before i get really confused - which shortcuts don't work in german - a list would be helpful. I promise not to laught about - but i really use the common shortcuts every day and had never read if there is Strg-C or Ctrl-C - it should work just out of the box and go out of my way.
Anmerkung: Verdammt noch mal, dat kann doch alles nich Warzenschwein. Ikke hab bisher nie darauf geachtet, wat an den Shortcuts steht und die einfach nur benutzt - funktionierte bei mir™ 1A.
@agaida Any shortcuts that are translated -- especially if they contain Ctrl. Please also read my recent comments!
And this is NOT specific to German. it may also happen with other languages (Hungarian, for example).
https://www.youtube.com/watch?v=PMwerN-luUY - i don't get it, please use simple words and write slowly ,,,
and before i forget - we should talk about the used versions of anything, like Qt, liblxqt and so on before we take any action.
Edit: I remember i see this issue times ago, but ...
@agaida So, it works for you. Yes, Qt version is important because the bugs I saw were for Qt ≤ 5.7. If @excalibur1234's Qt is 5.8 or greater, the question is: Why does it work for you and not for @excalibur1234 ?
@tsujan - good question, so i will leave debian for a few minutes and start archlinux
I remember i see this issue times ago
That might mean it's fixed but if so, it should have been fixed in Qt because we haven't done anything wrong in our apps.
ok, i'm in arch now - same version of LXQt, same xfwm4 - no shortcuts, it might be a Qt bug - damn, that likely means that i should build in debian against experimental Qt and mess up my desktop :D
i have had this problem with qt versions 5.7, 5.8, and 5.9 - as far as i can remember.
currently, i am using qt5.9.1.
i am glad to see that @agaida could reproduce this issue in arch linux. this means it is not only me.
you can imagine that i'm not so glad about :D
Ok, setting up a new snapshots repo, borrow the needed files from experimental and rebuild the whole LXQt the debian way against it will take some time.
you can imagine that i'm not so glad about :D
I'm not so happy either because I tried to simplify the problem but your test and @excalibur1234's Qt version made it more complicated ;)
if you make shortcuts untranslateable and pcmanfm-qt shows "CTRL+C" as keyboard shortcut for copying (with german locale), i do not care.
i think it is much more important to have working keyboard shortcuts.
@tsujan is right: CTRL works with keyboard shortcut for qterminal (with german locale).
@agaida: sooner or later (when debian switches to a broken qt version), you would encounter the same problem. better to fix it before that happens. having a broken CTRL+C and CTRL+V is not funny. but i can understand your point of view.
if you make shortcuts untranslateable and pcmanfm-qt shows "CTRL+C" as keyboard shortcut for copying (with german locale), i do not care.
Yes, that's the only good workaround that comes to my mind until the issue is fixed outside LXQt or a better workaround is found.
Ok, setting up a new snapshots repo, borrow the needed files from experimental and rebuild the whole LXQt the debian way against it will take some time.
@agaida I recommend you don't to that. It's a lot of work and may not only break your Debian but also provide no new info.
I didn't follow this discussion much... but just a try (when you're talking about translations)... did you check if you have the qt(base) translations installed?
In debian it is located in qttranslations5-l10n package.
@excalibur1234 - i don't think that you can understand my point of view - sorry, no offense. If it is really a Qt regression it should be solved before Qt 5.9.1 hit sid.
@palinek - thanks for the hint
@tsujan - nothing more work, thats one of the reasons for the pre-release - have someting right at hand what can be uploaded to experimental - there will be some changes needed in so-names, packaging, symbols etc. And i guess the other major distributions work the same way - test, what will break with a new Qt and a possible new LXQt first before they upload it to their main repos. So not much more work, only a little bit unexpected and not planned right now.
@palinek's suspicion seems very pertinent to me. It's qt5-translations in Arch based systems.
@palinek just solved the problem:
i installed "qt5-translations" package and recompiled pcmanfm-qt (git version). now, all keyboard shortcuts work (even with german locale).
so, the real problem is a missing dependency for pcmanfm-qt. @jleclanche, please add this dependency to the arch linux package of pcmanfm-qt !!!
Wow! We learned something here, thanks to @palinek! The bug was fixed a long time ago. Closing this.
But shouldn't localization require qt5-translations?
cool - so i guess @jleclanche, @pmattern and the other maintainers should add qt5-translations as dependency in their PKGBUILDs
EDIT: And before i forget - we should add this to the build dependency list in our wiki.
cool - so i guess @jleclanche, @pmattern and the other maintainers should add qt5-translations as dependency in their PKGBUILDs
Could we do this somehow in our sources if localization is enabled?
Ignore "if localization is enabled" in my sentence but this is an important dependency.
loc-packages are needed anyways - we translate desktop files in every case, only the things from lxqt-l10n are optional at build time. But i'm not that deep into arch packaging anymore.
only the things from lxqt-l10n are optional at build time.
I want to prevent this problem in my localized apps too. IMO, a dependency is needed in source somehow.
ok - starting arch again - and you are right - imho we should make sure that the build-tools throw this in
Looking forward to your solution to steal it ;)
:) - if we change it the change should be distribution agnostic imho, i'm on it
qt5-tools /usr/lib/cmake/Qt5LinguistTools/Qt5LinguistToolsConfig.cmake
so i guess depending on Qt5LinguistTools should be sufficient
so i guess depending on Qt5LinguistTools should be sufficient
I'd thought about that but nothing depends on qt5-translations, not even qt5-tools (or whatever they're called in Debian).
and it becomes even worse - qt5-translations is a run time dependency :D
I don't see anything dependent on qttranslations5-l10n on Debian either. If so, we couldn't do anything in the source; it'll be about packaging: Arch packages should be fixed -- I guess deb packages are OK; aren't they?
The only reason why I have qt5-translations is that Manajro decently notifies about translations and I installed all of them on seeing that notification after the very first login.
LANG=C aptitude why qttranslations5-l10n
i qterminal Depends libqt5core5a (>= 5.7.0)
i A libqt5core5a Recommends qttranslations5-l10n
Thats the definiton of Recommends - we are dead sure that you will need it, but the binaries run and throw no segfault (free translation of the policy) - i like to talk about Recommends as a kind of soft dependency and cry about the abuse of every single day.
LANG=C siduction-paste apt rdepends libqt5core5a: http://paste.siduction.org/20170724172534
and thanks to this bug another fugly bug in my debian packages is solved finally - some really clever people don't install recommends (super geeks that want to have their installation without bloat) - and write angry bugs about packages and missed functionality - and claim that some packages or desktop environments are not ready for stable - solved after over a year now, future libqtxdg in debian will depend on qttranslations5-l10n - recommends are sometimes to weak :D
some really clever people don't install recommends (super geeks that want to have their installation without bloat)
LOL! I was one of them when I used Debian but I don't see myself as a "super geek" -- just a user that wanted to keep track of everything ;) However, I never wrote an angry bug :D
if one develop a set of packages for a few years (before it appears in debian) and get an angry bug with the essence: "You are a moron, the packages are bloated and not ready for stable" it might be that the reporter is right - but if so the reporter should not forget packages that are only recommended but might be needed for the wished functionality - and yes, he was angry about missed shortcuts ;)
Really cool, finally solved this one :D
tsujan: after a while of calming down i added the translations as dependency to the lxqt metapackage, recommended it for lxqt-core, qtxdg and the translation packages. That should be enough. And if one really don't throw it in - not my problem anymore, it is not a dependency because pure english systems don't need it and it's miss in localized systems result only in missed funktionality. If there are any bugs filed one can poiint the users to the recommendations.
Fair enough.
recommended it for ... and the translation packages.
We we should mention this for packagers in the lxqt-l10n README...
+1
+1
Done in lxqt/lxqt-l10n-deprecated#242
@tsujan - fyi - borrowed the needed things from experimental (whole Qt 5.9.1, solid, kidletime, kwindowsystem) and have now a debian-like LXQt with 5.9.1 - and the best is: No visible regressions.
Good :) I used Experimental sometimes but only this or that piece.
with a little bit of knowledge reprepro can be misused in several ways - get a set of packages without installing from experimental directly and such things