Ticket created by ~baroque0 on ~mil/sxmo-tickets
It seems like it happened after latest pipewire update (3.77), on pmos edge. calls are unusable, with a strange twist. Steps to reproduce:
- place a call -> after a long while, notifcation "we failed to disable speaker." then we failed to enable speaker" -> an "Incall Menu" item is in sxmo menu, with what seems to be an outgoing (ghost) call.
- hit "hang up. -> "we failed to hangup the call"
-> a new call is placed to the requested number, and this time things work!
(variations of this scenario occur... very mysterious)
Comment by ~baroque0 on ~mil/sxmo-tickets
comment by hazardchem:
maybe have a template that is called at the start and end of a be/dmenu script? that way the wheel doesnt need to invented each time
maybe apart of sxmo_common?
Ticket created by ~baroque0 on ~mil/sxmo-tickets
i really appreciate phartman's patch that puts "close menu" on top of the network menu!
It was needed for me (to the extent that i was removing older wifi networks to shorten the menu..) but now we're in that weird situation:
in "networks", the "close menu" option is on top, while in all others it is at bottom... but for some other menus (config, apps, scripts) it can become the case that the list is too long, same problem etc..
how about that:
- every sxmo menu (except some exceptions like system menu of course) have "system menu" / "close menu" as their two first entries? It could be done in a generic way?
could also be "close menu" / "system menu" in that order... point be: 1/ these two elements should be in all menu, ideally along with a "back" option, but probably harder to implement 2/ having them at predictable spot would greatly simplify navigation (ie. always on top) 3/ putting them on top would give them equal visibility/accessbility in all cases...
on ~mil/sxmo-tickets
If anyone (~baroque0) wants to help creating SVG icons, see https://todo.sr.ht/~earboxer/statusbar to see what additional icons I wanted to add before sending my next iteration of the patch.
Ticket created by ~baroque0 on ~mil/sxmo-tickets
had twice, after upgrading to git head on Saturday, an incoming phonecall from an unknown number where instead of the number was displayed "--".
I cannot find trace of the actual number (.local/share/sxmo/modem/modemlog.tsv displays "--" as well as every call menu etc.).
Is there a quick/easy fix for that?
Comment by ~baroque0 on ~mil/sxmo-tickets
Also if ssh runs on non-standard port...
Comment by ~baroque0 on ~mil/mepo-tickets
Thanks for clarifying!
I don't know if it's a side-effect of the "roundtrip", but as you suggested on other ticket, i added
prefset_n distance_unit_tf_km_mi 1;
to .mepo/config and launched it again... and it didnt change a thing.i decided i would cat .mepo/config >> /home/user/share/mepo/savestate, as to try the "roundtrip" alright... and indeed it worked! ;)
so it still feels the savestate could leave a little bit of room to certain cases.... ;)
by all means, keep up the good work!!
Ticket created by ~baroque0 on ~mil/mepo-tickets
It happens that mepo uses some units that very few people in the world use, that are not even divisible neatly by 100!!!
steps to reproduce:
- define a pin
- move the view away from the pin
- read: "Dist: 2.96mi away"
joke aside, is there a way to swich mepo to use units that are almost universally used and that make sense? ;)
Comment by ~baroque0 on ~mil/mepo-tickets
This is now the ONLY feature i can think of that is missing in my day-to-day usecase with 0.5. as i don't use GPS nor calculate itineraries algorithmically, i always just "look at the map" and the estimation of distance in those cases is really essential.
Comment by ~baroque0 on ~mil/mepo-tickets
I think this would work, as it would be used on displays with very high DPI and such, where the local renderer will be doing the job of antialiasing and making more "pretty". It could be a global "scale" parameter of some sort..?