Thanks! Sorry for missing this earlier on Github. Merged now!

--

Maarten van Gompel (proycon)
https://proycon.anaproy.nl

On 23-01-26 01:15, Willow Barraco wrote:
> Little reminder why I choosed a blinking purple instead of a simple
> purple. It doesnt monopolize the led. Good luck when you have green
> + purple at the same time.

I agree that this was a good idea to convey more information.

Is the blinking such a CPU hog?

-- 

Maarten van Gompel

Good idea to tackle this, but I'm not so keen on having multiple
sxmo_status add/del calls or to 'split off' style/color
components/tokens. It's a bit messy and prone to lead to errors regarding
missing begin/end tags.

I'd rather see each sxmo_status component being a full template (with
placeholders for style and colour), which are, as late as possible,
converted or stripped for whatever appropriate rendering backend.

-- 

Maarten van Gompel (proycon)

Thanks! This patch has been applied now.

--

Maarten van Gompel (proycon)
https://proycon.anaproy.nl

Thanks! This patch has been applied now.

--

Maarten van Gompel (proycon)
https://proycon.anaproy.nl

---
 configs/default_hooks/sxmo_hook_contextmenu.sh | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/configs/default_hooks/sxmo_hook_contextmenu.sh b/configs/default_hooks/sxmo_hook_contextmenu.sh
index a7da7af..828049f 100755
--- a/configs/default_hooks/sxmo_hook_contextmenu.sh
+++ b/configs/default_hooks/sxmo_hook_contextmenu.sh
@@ -171,6 +171,19 @@ case "$WMCLASS" in
 		"
 		WINNAME=Sxiv
 		;;
+	*imv*)
+		# imv
[message trimmed]

In sway, tools like feh didn't have their context menu pop up because
the app wasn't identified properly (empty app_id).

---
 scripts/core/sxmo_wm.sh | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/scripts/core/sxmo_wm.sh b/scripts/core/sxmo_wm.sh
index f4a1e52..3673467 100755
--- a/scripts/core/sxmo_wm.sh
+++ b/scripts/core/sxmo_wm.sh
@@ -113,13 +113,23 @@ xorgfocusedwindow() {
 }
 
[message trimmed]

On 22-11-08 04:20, Anjandev Momi wrote:
> Im concerned about feature-creep in sxmo-utils and I recommend we
> try to separate voice control functionality as much as possible from sxmo-utils.
> That is, the voice control functionality should be in a separate git repo,
> separate package, and the functionality/code should be removable by the user
> (with sxmo still functioning properly). If you have any concerns about
> this idea, we can discuss. I want this feature hehe.

I agree yes! We might even want to split up sxmo-utils itself at some point, for more modularity. (sxmo-modem?, sxmo-bluetooth?, sxmo-audio?)

-- 

Maarten van Gompel

Hi all!

I've got an exciting new feature for Sxmo. I recently found Numen
(https://git.sr.ht/~geb/numen), a voice control system by John Gebbie,
which is built on top of vosk-api (which is in turn built on top of
Kaldi). Please check the demo video I made:

    https://diode.zone/w/dYo8QcVVFFpzS7PwddFPMV

I think Numen fits very well with what we have, our philosophy in
general, and it opens up extra accessibility, especially for those like
me who've never liked working on a virtual keyboard.

Patches for sxmo will follow later. PostmarketOS users who can't wait

On 22-11-03 06:48, Hartman, Peter wrote:
> Ha! I left that there hoping it'd annoy someone enough to implement it 
> ;)

I took the easy way out ;) I did try for a few minutes but gave up as
I'm not sure how portable it'd be across devices.

-- 

Maarten van Gompel