ah yes i can explain why even when the ubuntu patch does remove the Client Side Decorations no Server Side Decorations are added, the EWMH and _MOTIF_WM_HINTS, to be more precise the MWM_DECOR_TITLE hint which when set requests the window manager to NOT add titlebars (Server Side Decorations) to a window be it because the window is of type dialog or some other reason like having Client Side Decorations, the ubuntu patch manages to disable the Client Side Decorations on gtk4 but fails to set the appropriate window hints to allow the window manager to decorate the window with a titlebar, if you got a configurable window manager that is a non issue as ya can simply set the window manager to ignore the title hint for gtk4 apps.

for example on greenjames suggestion of using a CSS hack to hide window buttons on gtk4 apps and then just add decorations through the window manager selectively ignoring the title hints of gtk4 apps.

some reference from the hand of awesome wm documentation:
https://awesomewm.org/doc/api/classes/c … o_titlebar

there was a talk a while ago about forking the systemd-boot outta the systemd source tree as egummy-boot for the whole reason that for it to work completely free of any systemd tree untility it just needs a shim, the reason for the fork being to ensure that it remains requiring only that one shim instead of relaying on other systmed "utilities"

edit: the link of the thread https://dev1galaxy.org/viewtopic.php?id=6095

in usual dev1 forum fashion the idea of a shim was discussed along the idea of maintaining a fork to ensure just the shim is needed but the proposal got no traction and nothing was done.

Is not just a decrease in competency, but also a problem of the "entry cost" for the knowledge and the knowledge not being passed along in an efficient manner, case in point is debian packaging, to anyone who wants to package some piece of software for use in debian (and derivates) the whole debian packaging process will seem like some sort arcane magic burdened by bureaucracy after reading the debian maintainer guide once...

redgreen925 do ya use a desktop environment like mate, xfce, kde, etc... or have a setup with a plain window manager and tools composed on top of it?

it could be that for all of use whom get the files piled up is because we are using plain window managers that do not purge their active dbus session address file upon session end (logoff, shutdown, reboot)

eh offtopic but not more offtopic than many of the other posts

https://felipec.wordpress.com/2024/04/0 … -insanity/

autohell truly is the piece of software that keeps on giving, because simple makefiles are poison i guess...

another option would be to cobble a script with yad for the gui (lighter for setups that already use yad) and on the inside all it does is run apt-get commands to show the information of the .deb and installs it with apt-get install <full/path/to/package.deb>

apt is a "work in progress" interactive tool, it has undocumented options (if you don't read the manual) since they may not be tested enough to have full documentation, for example for apt 2.9.6devuan1

       edit-sources (work-in-progress)
           edit-sources lets you edit your sources.list(5) files in your preferred text editor
           while also providing basic sanity checks.

       showsrc, depends, rdepends, policy (summarised in apt-cache(8))

       source, build-dep, download, changelog, clean, distclean, autoclean (summarised in apt-
       get(8))

SCRIPT USAGE AND DIFFERENCES FROM OTHER APT TOOLS
       The apt(8) commandline is designed as an end-user tool and it may change behavior between
       versions. While it tries not to break backward compatibility this is not guaranteed either
       if a change seems beneficial for interactive use.

       All features of apt(8) are available in dedicated APT tools like apt-get(8) and apt-cache(8)
       as well.  apt(8) just changes the default value of some options (see apt.conf(5) and
       specifically the Binary scope). So you should prefer using these commands (potentially with
       some additional options enabled) in your scripts as they keep backward compatibility as much
       as possible.

SEE ALSO
       apt-get(8), apt-cache(8), sources.list(5), apt.conf(5), apt-config(8), apt-patterns(7), The
       APT User's guide in /usr/share/doc/apt-doc/, apt_preferences(5), the APT Howto.

it is testing, usually devuan lags behind debian releases anywhere from weeks to months testing that stuff works and sometimes having to rebuild programs or even fork them to remove the hard dependencies on systemd, it is a "is ready when is ready" type of situation.

well, technically in the keybinds overrides you could do something like this:

     │ ! keybind overrides
     │ UXTerm*VT100.Translations: #override \
     │     Prior <KeyPress>:scroll-back(1,halfpage) \n\
     │     Next <KeyPress>:scroll-forw(1,halfpage) \n\
     │     Shift <KeyPress> Insert: insert-selection(CLIPBOARD) \
     │     Ctrl Shift <Key>V:    insert-selection(CLIPBOARD) \
     │     Ctrl Shift <Key>C:    copy-selection(CLIPBOARD) \

which would work and make the xterm buffer scroll up and down with just the next and prior key, but that is going to cause problems with the tui programs like vim that map functions to the next and prior keys, say in vim instead of scrolling in the vim buffer you'll scroll the xterm buffer which will also show terminal history... and that is without mentioning that you have to unmap the default xterm keybinds that add the half page scroll function cuz otherwise you just duplicated the same function without a keychord for a worse user experience...

    ! xterm default keybinds, see full list with man xterm
        Shift <KeyPress> Prior:scroll-back(1,halfpage) \n\
        Shift <KeyPress> Next:scroll-forw(1,halfpage) \n\

any specific feature that makes it a "worth installing right now" over waiting for it to be added onto either debian or devuan experimental for your daily driver? cuz for testing environments and providing feedback onto the project i do consider an install now if you can spare a "testing machine"

well, more shell slop crudely typed by my hands, this time a handful of scripts that aim to wrap neovim and a terminal emulator into a makeshift gnvim program to better integrate with GUI programs and desktop environments

https://github.com/eylles/xterm-nvim

will try to create a .deb package for it tho.

Anyway, more on topic, password management really has got me thinking for a while that there is not a real "good" generic way to do password management on a unix like environment, seeing all the threads about complains on password managers like keepass, local secre/password access stuff via gnome-keyring-daemon, and browser/mobile password management where the only good solution is bitwarden as you can host your own server and there are at least 3 implementations of the bitwarden server, not to mention the need for OTP codes and all the problems that the gnome-authenticator package had at one point being removed from testing and how difficult it was for the maintainers to package the newer version of the project after it was rewritten from scratch in rust because the rust model of managing it's own dependencies with cargo has a lot of friction with how packages are built in debian...

All that to say, i've been thinking of looking into writing a set of programs for addressing that madness:

• password-keyring-daemon: a daemon to replace the secret store functionality of the gnome-keyring-daemon,will however not provide d-bus functionality by default, all the actual storing of secrets and passwords would be done with pass as a pluggable backend, so whoever doesn't like pass can roll his own password manager and backend wrapper to be used with this daemon.

• password-keyring-daemon-dbus-plugin: an optional plugin for said daemon to add the d-bus functionality for those who need it, this would include the org.freedesktop.secrets portal interface.

• password-bw-imexporter: a plugin to import-export to/from bitwarden, would use a config file to set the bitwarden server and account credentials so users can still self host bitwarden, the idea is to allow the daemon to fetch the passwords csv, merge with the local password store through the backend and then get a merged csv from the backend to export onto the bitwarden server, this would be one of the pieces of this whole set with network access to sync the password stores.

• password-keyring-favicon-fetcher: just a "dumb" program to fetch the favicons, the second program of this set to have net code and would serve to prevent the need of net access in the other programs.

• password-keyring-authenticator-lib: a library to handle all the OTP stuff, not something that would directly be called by the daemon.

• password-keyring-authenticator: a gui program to manage OTP authentication, be it just copy the OTP code to clipboard or add a new authentication entry be it by qr code image or a token.

• password-keyring-manager-lib: a thin client library to retrieve passwords from the password-keyring daemon, to be used by a gui program.

• password-keyring-manager: a gui program to actually manage the locally stored passwords, if the favicon fetcher is present it will show favicons, if the bw-imexporter is present will sync the password store on start and upon changes.

consider those names as placeholders, and for the actual development i would probably use python to have a fast development cycle as besides the very core daemon none of the other programs are "performance critical" to NEED be written in C, and even then re-writing the daemon in C would be something to consider for the time when everything else is working good enouhg..

Tho i got no timeframe whatsoever to do any of this, nor it is for sure i will with my history of starting cobbling together daemons and other programs then taking forever to add basic features...