Presently, revisions 5.1_p16-r10, 5.2_p26-r3 and bash-5.3_alpha-r2
refrain from declaring the genfun_set_win_title function at all in the
case that the tty belongs to sshd(8). This is to avoid cluttering the
shell's operating environment in situations where the decision is made
not to append 'genfun_set_win_title' to the PROMPT_COMMANDS array.
One might ask why it should not always be appended to the array. The
explanation for this is that Gentoo Linux does not exist in a vacuum;
not all operating systems default to initialising bash in such a way
that it can be assumed that the title will be set at each prompt (or at
all). Where SSH is involved, the server has no knowledge whatsoever of
the particulars of the client OS or its operating environment. This
would previously give rise to the following scenario.
1. User runs ssh(1) from non-Gentoo to connect to sshd(8) on Gentoo
2. The remote shell alters the window title
3. The user eventually exits the remote shell.
4. The window title is never restored to its prior value
Put simply, there is no way for the remote side to know what the
existing window title is, much less guarantee that it be restored on the
client side.
All that being said - and rather unsurprisingly - some Gentoo users will
care nothing for these considerations or are simply operating in a
homogenous environment where they are not an immediate concern. Try to
accommodate the wishes of such users more effectively by declaring the
function unconditionally. Consequently, they will have the option of
restoring Gentoo's historical behaviour in a somewhat straightforward
manner. That is, by setting PROMPT_COMMAND in ~/.bashrc or in an
/etc/bash/bashrc.d/ drop-in to the effect of the following.
PROMPT_COMMAND=(genfun_set_win_title)
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Bug: https://bugs.gentoo.org/934309
Signed-off-by: Sam James <sam@gentoo.org>
Notes:
* 12.4 RC1 was released the same day but may as well just use the snapshot,
the same thing anyway.
* This has the fix for bug #933423 but given 12.4 will be here soon,
not keywording this one.
Bug: https://bugs.gentoo.org/933423
Signed-off-by: Sam James <sam@gentoo.org>
Welcome Qt 6!
With this, the 'minimal' USE-flag is changed to 'window-manager', and
instead of Openbox, it will pull in KWin.
Openbox has not been in active development for a decade or two, and
no fixes seem to be getting in either. LXQt upstream also does not
recommend using it due to the same reason(s).
Additionally, LXQt upstream is probably not going to port 'obconf-qt'
to Qt 6, and as such, it has been removed from this meta ebuild as
well.
KWin works well with LXQt, and it's behind a USE-flag so anyone
can still continue using Openbox or anything else they like (or not
install this meta package in the first place).
Other lighter-on-the-dependencies window managers do exist, but they
tend to come with their own panels and such, making things awkward.
Not pulling any window manager by default may leave users confused,
however, so pulling in /something/ seems like a good thing to do.
Also, the Oxygen icon set has been changed to Breeze, per upstream
defaults.
Further, some USE-flags have gone enabled by default.
Signed-off-by: Jimi Huotari <chiitoo@gentoo.org>