~baroque0


#583 placing call with pipewire 3.77? 10 months ago

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)

#568 Unifying sxmo menus with "close" and "system" 1 year, 3 months ago

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?

#568 Unifying sxmo menus with "close" and "system" 1 year, 3 months ago

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...

#509 Zach's grand plan for ditching nerd fonts icons forever. 1 year, 5 months ago

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.

#554 regression incoming call menu for unknown number 1 year, 5 months ago

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?

#539 active SSH connection does not stop phone from sleeping if SSHing via IPv6 1 year, 7 months ago

Comment by ~baroque0 on ~mil/sxmo-tickets

Also if ssh runs on non-standard port...

#39 0.5 stuck with overlay help/debug 1 year, 10 months ago

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!!

#40 mepo using some rare exotic units as a default 1 year, 10 months ago

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? ;)

#30 Ability to show distance scale onscreen 1 year, 10 months ago

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.

#35 new scale on 0.4 displays too small 1 year, 10 months ago

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..?