I'm Miles, also see: http://github.com/mil
My nick is mla on IRC.
I handled the multikey in a dedicated script late this night. I would be happy to have your review on this. I am very proud, it works very well ! It also support holding presses :D The script https://git.sr.ht/~mil/sxmo-utils/tree/swmo/item/scripts/core/sxmo_multikey.sh
Cool - yeah I tend to reach for C possibly too quickly - if it works in sh why not. I tested out a bit the powerbutton single/double tap for terminal/keyboard, and that works well. Vol down hold for kill I was having a bit of problems with but maybe my hardware buttons not sure.
Hello, do you plan to replace the X11 completely and if so, in the 1.6 release?
The default for 1.6 will probably be Wayland, the way things are developing currently. But we are definitely NOT dropping X11 support. You can still run SXMO with X11+dwm+dmenu+st+svkbd , also in the future.
I think it was mentioned somewhere the idea of maintaining compatibility with X too, and having two pmbootstrap options / UIs which sounds like a reasonable way to approach this. So you'll be able to install on pmbootstrap either:
Sounds like nice progress.
Having never used Wayland on my own successfully and having some other projects running currently, unfortunately I can't be much help here. But I support this effort and would like to help perhaps in some minor ways. Ideally we'd make sxmo-utils done in a X/Wayland both compatible way which it sounds like there's already work ongoing on. I'd say switching to bemenu in Sxmo (X) could also help things (since bemenu is cross-compatible).
I do wonder if there's something like xbindkeys or sxhkd for Wayland? I'd be happy to take a stab at building multikey (double/triple tap) functionality out in a Wayland compatible keybinding daemon. I'd have some learning to do but happy to take this on. In a keybinding daemon is probably the right place to do it as that parallels with lisgd (e.g. in having separate daemons rather then building into WM). I kind of doubt sway would take an upstream multikey patch.
I don't think we should just cut multikey functionality. That's my favorite feature of Sxmo, or if we do I don't think itd be Sxmo as I thought of it. I know there are other people that rely on this functionality too.
Pushed a minor update for pending sxmo-utils 1.5.0 to not set SXMO_SCREEN_LOCK_OFF=1 by default in xinit_template.
Figure this is better default as that's what we reference in docs and was old functionality default too.
~anjan you're more familiar with new lock logic so please comment if there's a reason not to default this (e.g. I assume setting in xinit_template previously was a typo - lmk if not).
Fix of regression where double tapping voldown doesn't rotate all clients: https://lists.sr.ht/~mil/sxmo-devel/%3C20210729005205.26979-1-m%40milesalan.com%3E https://lists.sr.ht/~mil/sxmo-devel/%3C20210729005251.27225-1-m%40milesalan.com%3E
-nocursor on X / from xdm is the biggest blocker on this.
I don't have too much experience but I remember testing unclutter originally and it was fairly unreliable in contrast to X -nocursor. But more testing would be needed here. Thanks for suggesting ~marderbot.
That said, aesthetically I'd be happy to just knock out the -nocursor altogether and have the cursor shown (that was how it was in Sxmo 0.1). I think the cursor is actually helpful to show where you last clicked. But i'm sure I'm in the minority in wanting the cursor back :)
I'm skeptical of switching to pipewire, if someone want's to take up the work and can demonstrate it works reliably.. ok but ALSA + dmix + dsnoop is a nice reliable solution. That said I don't use bluetooth.
Done, reverted back to the old reliable & fast idiotbox way https://lists.sr.ht/~mil/sxmo-devel/%3C20210610004718.11772-1-m%40milesalan.com%3E
I don't think we need to overcomplicate it idiotbox works - ytdl hardly does. I'd rather things work reliably then be slow or not work / add hooks / catch cases.
Eh i'm not sure, i do kinda like the quirkiness of the weather script, that said for sure Europe would be nice. Wttr is basically a 1-line curl thing.
One idea would be to integrate dmenu as a dock window that sits above svkbd rather then being an arbitrary floating window, overlaying the background windows via the center patch as is done currently. E.g. dmenu instead could automatically adjust WM space as svkbd does currently and pop up right above svkbd if svkbd is also visible at the time (or just dock to the bottom alone if not). I had a POC on this at one point but it may require some further refactoring on the dwm dock patch, but would be quite doable with minor changes on dwm side.
The other idea is "fullscreen" sans svkbd per your example ~fjc , Though I would say the top bar shouldn't be covered. The downside is that you loose the context of the window itself whereas with a dock-patch style you still can see the input window aside.