From: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: [ISSUE] [CLOSED] qt5ct, problems with qt5ct.sh
Date: Mon, 03 Jul 2023 04:07:20 +0200 [thread overview]
Message-ID: <20230703020720.zWjj1j1lEx0GN6lWONBk4OGk8mFvpig4u50RhJXtlLE@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-42891@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 1280 bytes --]
Closed issue by furryfixer on void-packages repository
https://github.com/void-linux/void-packages/issues/42891
Description:
Presumably applies to qt6 as well. I would like to further the discussion touched on in ** ##40619** about the desirability of including or activating **"/etc/profile.d/qt5ct.sh**" when installing the qt5ct package. What brought this to my attention was the failure of icon themes in Plasma5 when started from the user's command line, as opposed to using a login manager. Having forgotten about my prior installation of qt5ct, it took some time to decipher the problem.
Most login/display managers will reliably set $XDG_CURRENT_DESKTOP, but it will not be set with startx, or startplasma-wayland when a logged-in user starts directly from a tty. In the latter case, qt5ct.sh will set QT_QPA_PLATFORMTHEME=qt5ct, even though the user is starting KDE Plasma. This problem will also affect users of LXQT, who also may prefer not setting the theme to qt5ct.
Admittedly, starting Plasma or LXQT without a login manager is an uncommon use case, which is why I am ambivalent about removing qt5ct.sh. I would just suggest that the pros/cons should be weighed vs. the alternative of asking the user to set QT_QPA_PLATFORMTHEME on their own.
prev parent reply other threads:[~2023-07-03 2:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-20 20:00 [ISSUE] " furryfixer
2023-03-20 20:07 ` classabbyamp
2023-03-20 20:21 ` furryfixer
2023-06-19 1:59 ` github-actions
2023-07-03 2:07 ` github-actions [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230703020720.zWjj1j1lEx0GN6lWONBk4OGk8mFvpig4u50RhJXtlLE@z \
--to=ml@inbox.vuxu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).