~aren


#625 Horizontal Scrolling a month ago

Comment by ~aren on ~mil/sxmo-tickets

What you described with librewolf rendering a window that's too wide (likely sway gave it the correct dimensions, but it ignored them because it doesn't know how to render that small) sounds like the issue here. Short of patching sway to scale windows instead of cropping them when that happens, there's not much we can do.

REPORTED RESOLVED NOT_OUR_BUG

#580 Disable screen lock upon absent of deviceprofile a month ago

Comment by ~aren on ~mil/sxmo-tickets

We've added logic that binds to all power/volume devices if they aren't specified in the deviceprofile, so this shouldn't be an issue anymore.

See 25c1827b device agnostic bindings for volume and power

REPORTED RESOLVED FIXED

#570 Documentation Overhaul a month ago

Comment by ~aren on ~mil/sxmo-tickets

We (mostly ~proycon) have rewritten the docs using scdoc, and they're now included in the sxmo-utils repo. I think this covers what was discussed in this issue, so I'm marking it as implemented.

REPORTED RESOLVED IMPLEMENTED

#525 Suppport for CHUWI UBook a month ago

Comment by ~aren on ~mil/sxmo-tickets

Is this still an issue? I think we've added a "desktop" deviceprofile that should cover x86 devices since this issue was created.

#617 lisgd should use libinput so user doesnt need permission for /dev/touchscreen a month ago

Comment by ~aren on ~mil/sxmo-tickets

Lisgd already uses libinput. The only way to not need permissions would be to request events from the wayland compositor / x server.

If we were to go through the wyaland compositor, we could also coordinate when lisgd is handling an event, so apps don't handle it. This would be done via the wl_touch.cancel event.

To my knowledge, there aren't any wayland protocols that would allow for external programs to handle touch gestures, so we would need to write our own and get compositors to support it.

#621 i3: sxmo-dmenu loosing focus after closing a month ago

Comment by ~aren on ~mil/sxmo-tickets

REPORTED RESOLVED CLOSED

#622 wofi doesn't return a failure code if it's killed 2 months ago

good-first-issue added by ~aren on ~mil/sxmo-tickets

#622 wofi doesn't return a failure code if it's killed 2 months ago

bug added by ~aren on ~mil/sxmo-tickets

#622 wofi doesn't return a failure code if it's killed 2 months ago

Ticket created by ~aren on ~mil/sxmo-tickets

Some of our menus handle no choice with something like this: choice="$(sxmo_dmenu.sh)" || exit, which requires sxmo_dmenu.sh to exit with a non-zero code if it's cancelled (killed). Because wofi returns 0 in this case menus that rely on that don't work properly.

This can be reproduced by using the up-to-top-edge gesture to close the networks menu. This will result in a notification "Enabling connection failure" and the menu reopening.

There's a few different ways we could go about fixing this, I'm not yet sure which one is best:

  • upstream a fix to wofi that exits with a non-zero code for dmenu compatibility
  • return 1 from sxmo_dmenu.sh if wofi returns no text
  • go through all our menus and ensure they all check for an empty string instead of a non-zero exit

#609 Keyboard not opening via gesture 2 months ago

Comment by ~aren on ~mil/sxmo-tickets

REPORTED RESOLVED CLOSED