From Fernando Ramos to ~mil/sxmo-devel
--- scripts/core/sxmo_appmenu.sh | 1 + scripts/core/sxmo_common.sh | 2 ++ 2 files changed, 3 insertions(+) diff --git a/scripts/core/sxmo_appmenu.sh b/scripts/core/sxmo_appmenu.sh index 4b7d1b5..e16ea6b 100755 --- a/scripts/core/sxmo_appmenu.sh +++ b/scripts/core/sxmo_appmenu.sh @@ -100,6 +100,7 @@ programchoicesinit() { $(command -v newsboat >/dev/null && echo "$icon_rss Newsboat ^ 0 ^ sxmo_terminal.sh newsboat") $(command -v nnn >/dev/null && echo "$icon_dir Nnn ^ 0 ^ sxmo_terminal.sh nnn") $(command -v pidgin >/dev/null && echo "$icon_msg Pidgin ^ 0 ^ pidgin") $(command -v pure-maps >/dev/null && echo "$icon_map Pure-Maps ^ 0 ^ pure-maps") [message trimmed]
From Fernando to ~mil/sxmo-devel
> I would not want a popup in response to a swipe gesture to make a window > go away. But that is exactly what some applications might decide to do when receiving a "SIGTERM". The only difference between directly sending a SIGTERM and using the WM_DELETE_WINDOW event is that you are using a different callback (one that is more likely to have been registered by the underlying toolkit the application is linked against) *and* that you don't have to figure out the process ID (from the several that the application might have created, such as in the case of Firefox).
From Fernando Ramos to ~mil/sxmo-devel
---
It turns out "xdotool killwindow" simply calls "XKillClient()", as you can see
on xdotool's repo ("https://github1s.com/jordansissel/xdotool") here:
"cmd_windowkill.c:40" --> "xdo.c:1845".
This doesn't give the application inside the window any chance to do anything
which, in the case of Firefox, causes the "restore session" message to pop-up
the next time it runs (but, for some reason, not always).
I found out that using "xdotool key shift+alt+c" also closes the window while
giving the application an opportunity to gracefully shut down (this happens
because wdm sends the WM_DELETE_WINDOW message before killing the X window).
WARNING: While this new command is "nicer", it also does *not* immediately close
[message trimmed]
From Fernando Ramos to ~sircmpwn/sr.ht-discuss
Once an artifact/release binary has been uploaded/attached to a tag (ex: v0.7), you cannot upload another file with the same name even if using a different tag (ex: v0.8). Use case: The resulting binary of my project is called "whatever.exe" and I would like to be able to use the same name for the different releases I make (instead of having to use "whatever_0.1.exe", "whatever_0.2.exe", etc...)
From Fernando Ramos to ~martijnbraam/public-inbox
--- I don't know if you are interested in this kind of patches, but I think others interested in contributing to the project might find it useful. In any case, please feel free to ignore this patch if you consider this type of documentation does not belong here :) Thanks! README.md | 302 ++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 294 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index 5420b1b..8c83829 100644 [message trimmed]
From Fernando Ramos to ~martijnbraam/public-inbox
--- .builds/alpine.yml | 2 ++ .builds/arch.yml | 2 ++ 2 files changed, 4 insertions(+) diff --git a/.builds/alpine.yml b/.builds/alpine.yml index 5c59054..2b7a0f6 100644 --- a/.builds/alpine.yml +++ b/.builds/alpine.yml @@ -1,4 +1,6 @@ image: alpine/edge sources: - https://git.sr.ht/~martijnbraam/megapixels packages: [message trimmed]
From Fernando Ramos to ~martijnbraam/public-inbox
--- main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/main.c b/main.c index 20f0895..1de0a40 100644 --- a/main.c +++ b/main.c @@ -1398,7 +1398,7 @@ find_config(char *conffile) } // If all else fails, fall back to /etc/megapixels.ini conffile = "/etc/megapixels.ini"; sprintf(conffile, "/etc/megapixels.ini"); [message trimmed]