~arsen

Serbia

https://www.aarsen.me/

Developer

~arsen/public-inbox

Last active 9 months ago

~arsen/alsa_rnnoise

Last active 10 months ago
View more

Recent activity

[PATCH basu 2/2] meson: convert audit option to feature object 25 days ago

From Arsen Arsenović to ~emersion/public-inbox

features are more idiomatic and ubiquitous
---
 meson.build       | 11 ++---------
 meson_options.txt |  2 +-
 2 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/meson.build b/meson.build
index 357b346..1f29690 100644
--- a/meson.build
+++ b/meson.build
@@ -235,15 +235,8 @@ libcap = dependency('libcap', required: get_option('libcap'))
have_libcap = libcap.found()
conf.set10('HAVE_LIBCAP', have_libcap)

[message trimmed]

[PATCH basu 1/2] meson: add libcap option 25 days ago

From Arsen Arsenović to ~emersion/public-inbox

it's better to provide the user with this choice instead of
unconditionally magically depending on it
---
Good afternoon!

I'm packaging Basu for Gentoo for use with xdg-desktop-portal-wlr, and I
noticed these two quirks in the build system. These required
patching/workarounds according to Gentoo policies, and are a general QoL
improvement, which I think is worth upstreaming.

Thank you in advance

 meson.build       | 2 +-
 meson_options.txt | 3 +++
[message trimmed]

[PATCH git.sr.ht] refs: show the accurate annotated tag time 2 months ago

From Arsen Arsenović to ~sircmpwn/sr.ht-dev

After this patch, the ref and refs pages will show the time based on the
tagger line of tags for annotated tags.
---
I'd possibly make some changes here, notably, add a prefix such as "tagged on"
and "committed on" depending on the kind of tag, to make it clear what time was
specified, but it'd be a larger visual change in the UI so I'd rather ask about
that first.

For an example, see: https://git.sr.ht/~sircmpwn/getopt/refs/v1.0.0

 gitsrht/app.py              |  3 ++-
 gitsrht/git.py              | 11 +++++++----
 gitsrht/templates/ref.html  |  2 +-
 gitsrht/templates/refs.html |  4 +++-
[message trimmed]

[PATCH v2] email 8 months ago

From Arsen Arsenović to ~sircmpwn/email-test-drive

---

 arsen | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 arsen

diff --git a/arsen b/arsen
new file mode 100644
index 0000000..66cb3d4
--- /dev/null
+++ b/arsen
@@ -0,0 +1 @@
I have successfully used git send-email!
--
[message trimmed]

[PATCH] email 8 months ago

From Arsen Arsenović to ~sircmpwn/email-test-drive

---
 arsen | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 arsen

diff --git a/arsen b/arsen
new file mode 100644
index 0000000..6d0ecfd
--- /dev/null
+++ b/arsen
@@ -0,0 +1 @@
I'm about to try git send-email
-- 
2.26.2
[message trimmed]

Re: electron alternatives: wayland-like widget toolkits/GUI frameworks 9 months ago

From Arsen Arsenović to ~sircmpwn/public-inbox

> 1. Has anyone created a realistic alternative to HTML/CSS--maybe a
> binary DOM that has a reasonable API for manipulation? I supposed it'd
> also need some sort of rendering engine
No, and there's no real need for one. Existing GUI frameworks (none of which are
small enough, but they work well enough) already are very mutable from APIs;
such a DOM would be no improvement, in fact, the only reason DOM manipulation
is so needed in the Electron world is because HTML is *not* a UI language, and
it shows; it's a markup language unfit for program UIs.
In that regard, Qt is not terrible, it produces good GUIs, even though it acts
like a bit of a virus in any codebase, and sadly exposes a C++ API instead of a
C one.

> 2. Has anyone created a Wayland-like protocol for #1 so that you may
> create an app that communicates through a socket to manipulate the DOM

Re: Suggestion for added email client to useplaintext.email 9 months ago

From Arsen Arsenović to ~sircmpwn/public-inbox

> This just looks like mutt.
Yes, it's just a setup script for neomutt.

PS: I've replied instead of group-replied, by muscle memory, sorry about that.
Reposting on the mailing list.

-- 
Arsen Arsenović

Re: A small defense of the X protocol (not implementation!) in response to Anti-Wayland-horseshit 9 months ago

From Arsen Arsenović to ~sircmpwn/public-inbox

> > no special protocol
> > XEmbed
> 
> Pick one.
> 
> https://specifications.freedesktop.org/xembed-spec/xembed-spec-latest.html
> 
> In any case, it is supported on Wayland via xdg-foreign:
> 
> https://github.com/wayland-project/wayland-protocols/blob/master/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml
This is a bit different; technically, I'm pretty sure any window can be
reparented into an XEmbed program (such as tabbed) and behave as expected, no
client code required. But this is a very nice protocol.

A small defense of the X protocol (not implementation!) in response to Anti-Wayland-horseshit 9 months ago

From Arsen Arsenović to ~sircmpwn/public-inbox

Hey!

I'm writing this in response to "I'm tired of this anti-Wayland horseshit", to
bring up one thing that X still has over Wayland:

Due to Xs many years of existence, and due to how it's windows are organized
and how events are handled, tooling already exists with no special protocol
support to automate some tasks, or to do things like XEmbed (think xdotool or
tabbed, both of which are quite useful). I don't think either of these examples
exist currently within the Wayland protocol(s).

I understand that the Wayland protocol is little outside event and window
content exchange, with supplementary protocols to do stuff like take
screenshots or inhibit suspends, and that room would have to be made with a few