From: Eli Schwartz <eschwartz@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] profiles: desktop: Add "wayland" to make.defaults
Date: Sat, 14 Sep 2024 22:42:16 -0400 [thread overview]
Message-ID: <943f3418-0d7b-4e35-8d59-d33dee8d63d7@gentoo.org> (raw)
In-Reply-To: <4923407.GXAFRqVoOG@tuxbrain.fritz.box>
[-- Attachment #1.1: Type: text/plain, Size: 1985 bytes --]
On 9/14/24 6:23 AM, Andreas Sturmlechner wrote:
> 1) overall small impact on binary size, no runtime implications for X users
> 2) desktop profile definition is "minimal" USE flags, not necessarily "legacy"
> 3) plenty of "minimal" gui-wm/* exist, so X WMs can't claim that space
> 4) KWin is not just used with Plasma, but also as LXQt default, and both
> Plasma as well as Gnome have plenty of desktop profile users for some reason
> (mostly no-multilib of course ...)
I suppose it is technically "minimal" to have either one or the other
but not both...
Which one deserves to be the "minimal default"? That is a harder
question to answer. But at least selectively there's a reason to have
various packages such as toolkits default to X support for ABI reasons
(this argument can of course be made for wayland too) and there's a
surprising amount of software out there that is X11-specific from the
days when it was less common to use generic toolkits such as Gtk / Qt,
which I guess leads us to: xwayland.
Anyway, I'll just add -wayland to make.conf to stem the flood, I
suppose. My DE is hardly "minimal" but it is certainly X-only.
Perhaps what we really need is an easier way to handle custom user
profiles via mixins, so that e.g. people who use lxqt don't have to beg
for a dedicated official profile.
> 5) deduplication++
At least this could be handled by making a
profiles/targets/desktop/wayland and having both plasma and gnome parent
themselves to that?
It's not really much of an argument, even if it is only added on to 4
other arguments, to talk about deduplication as a reason to modify
end-user experiences. The arguments for end-user experiences should
relate to solving end-user problems, which is what points 1-4 argue
based on. Internal implementation details should remain internal
implementation details, and it seems we do (happily) have the technology
to make them stay that way.
--
Eli Schwartz
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
prev parent reply other threads:[~2024-09-15 2:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-14 10:23 [gentoo-dev] profiles: desktop: Add "wayland" to make.defaults Andreas Sturmlechner
2024-09-14 10:29 ` Ionen Wolkens
2024-09-15 2:42 ` Eli Schwartz [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=943f3418-0d7b-4e35-8d59-d33dee8d63d7@gentoo.org \
--to=eschwartz@gentoo.org \
--cc=gentoo-dev@lists.gentoo.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