From: Thien-Thi Nguyen <email@example.com> To: firstname.lastname@example.org Cc: email@example.com Subject: RPX 1.4 available Date: Tue, 14 Dec 2021 07:24:40 -0500 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) [-- Attachment #1: Type: text/plain, Size: 2812 bytes --] release notes: Finally safe to try out in good company! README excerpt: This is rpx, a port of ratpoison to Guile Scheme. Although initially intended as a proof-of-concept exercise to plumb ttn's ignorance of X11, Scheme, and good taste, the result has proven to be useful as well. Despite rpx veneration of ratpoison look, feel, and internal design, there have been some unavoidable concessions to some of the more hairy parts of Xlib (the reimplementation of which is shared somewhat uneasily by rpx and ttn-do). These are listed in the manual. NEWS for 1.4 (2021-12-14): - better EWMH compliance - bugfix: RPX properly polite on startup Previously, RPX would barge ahead and set window properties left and right, relying on the X server to signal error to let it know that another window manager was running. This method is not only unreliable, it's not compliant w/ the Extended Window Manager Hints spec. Worse, the result is RPX competing ingloriously w/ the running window manager. Uncouth! Now, RPX checks the ‘_NET_SUPPORTING_WM_CHECK’ (et al) properties and quits (successfully) if it appears another window manager is running. By the same token, if there is no other window manager running, RPX declares its intention to take on window manager responsibilities by setting those properties, etc. The upshot is that you should be able to invoke RPX while, say, Xfwm4 is running, and it will DTRT and defer to Xfwm4. - bugfix: subproc windows verified to be same-host Previously, RPX assumed PID info derived from a client window to be from the same host (as RPX), and thus might attempt to close a window on a process w/ that PID that would ultimately fail. Now, RPX verifies the host via the ‘WM_CLIENT_MACHINE’ property. NB: This bugfix has not been extensively tested; please report any difficulties you might encounter w/ other-hosted clients. - bootstrap/maintenance tools upgraded: Guile-BAUX 20211208.0839.a5245e7 GNU gnulib 2021-12-10 21:54:54 GNU Autoconf 2.71 GNU Automake 1.16.5 GNU texinfo 6.8 as before: (none) tarball, etc, in dir: https://www.gnuvola.org/software/rpx/ tip jar: https://www.gnuvola.org/patronage/ -- Thien-Thi Nguyen ----------------------------------------------- (defun responsep (query) ; (2021) Software Libero (pcase (context query) ; = Dissenso Etico (`(technical ,ml) (correctp ml)) ...)) 748E A0E8 1CB8 A748 9BFA --------------------------------------- 6CE4 6703 2224 4C80 7502 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 219 bytes --]
reply other threads:[~2021-12-14 12:24 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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 List information: https://www.gnu.org/software/guile/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: RPX 1.4 available' \ /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
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 read-only IMAP folder(s) and NNTP newsgroup(s).