Podboat comes with newsboat, used to download and play podcasts with newsboat
---
 configs/default_hooks/sxmo_hook_apps.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/default_hooks/sxmo_hook_apps.sh b/configs/default_hooks/sxmo_hook_apps.sh
index 9e6925d..f76862a 100644
--- a/configs/default_hooks/sxmo_hook_apps.sh
+++ b/configs/default_hooks/sxmo_hook_apps.sh
@@ -80,6 +80,7 @@ write_line_app pidgin "$icon_msg Pidgin" "pidgin"
 write_line_app pulsemixer "$icon_mus Pulsemixer" "sxmo_terminal.sh pulsemixer"
 write_line_app pure-maps "$icon_map Pure-Maps" "pure-maps"
 write_line_app mepo "$icon_map mepo" "mepo"
+write_line_app podboat "$icon_rss Podboat" "sxmo_terminal.sh podboat"
[message trimmed]

Thanks! I have applied all four patches now. I'll also prepare a new
release because we probably want the customisable device node released
asap for other devices.

--

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

On 22-04-22 09:03, Peter John Hartman wrote:
> +icon_fai="令" # sim missing

This one isn't in the proper unicode private range and overlaps with the CJK ideograph, so I don't think we should use it.

--

Maarten van Gompel

Thanks! This patch has been applied now.

--

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

I'm still of the opinion that it's a configuration though, and when
setting up a new system you're likely to want to move contacts too. It's
primarily input for the system rather than output like the sms messages,
notifications, etc... (even though it can also be edited via the menus of
course)

--

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

Right, we talked about this before but it seems hadn't followed up on
it. Merged now. I agree a 1.8.3 backport with this may be a good idea.

--

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

Hi all,

As Sxmo is growing, the code at the heart of Sxmo, sxmo-utils has also grown
and comes from more and more contributors. sxmo-utils is currently
MIT-licensed, but we think this is no longer the most fitting option for
a project like ours and want to propose a move to a strong copyleft
license: the GNU General Public License v3 or possibly even the GNU Affero
General Public License v3.

Sxmo ties together a wide variety of tools, each have their own
open-source license and that is perfectly fine. This proposed change
would apply to sxmo-utils. Possibly we would also express that we as a
project have a preference for GPL when a new tool were to be developed
for our ecosystem, but this is of course always up to the invididual

On 22-02-10 05:11, Stacy Harper wrote:
> On some device we need to adapt the workflows (aka Pinenote but also desktops).
>
> We rethink how we use hooks. We drop the sxmo_hooks.sh and add this to PATH
> in this order :
>
> - $XDG_CONFIG_DIR/sxmo/hooks/pinephone-1.2pine64/
> - /usr/share/sxmo/default_hooks/pinephone-1.2pine64/
> - $XDG_CONFIG_DIR/sxmo/hooks/
> - /usr/share/sxmo/default_hooks/:

I'm not sure about adding them to $PATH and dropping sxmo_hooks.sh. I
see things in $PATH as tools that are primarily run from the command
line, often by the user directly. Most of our hooks are not meant to be

Thanks! I think the hook is a good idea, it gives some flexibility for people
who want to act upon rotations and update apps that have no native
support for detecting it (which would be the best of course, especially
on wayland where it's possible).

One small revision is needed though:

> +# The following parameters are provided:
> +# $1 = the current display manager/compositor

This is redundant, we already set $SXMO_WM which can be read from the
hook.

(Marked as needs revision)

Thanks for your proof of concept! This looks very promising.

> Gettext is quite intrusive, requires developpers to follow best-practice
> and may be anoying sometimes. That said I don't believe in-house solution
> can do better.

Agreed... gettext is probably the best way to go, despite it being
intrusive. There is also significant tooling for editing .po files,
including web-based environments as already mentioned in an earlier
reply.

I do wonder what the performance penalty is for this, a measurement
might be nice at some point. Obviously it takes
longer for the script to process because of all the eval_gettext calls