I'm Miles, also see: http://milesalan.com
My nick is mla on IRC.
Fixed with a9a7ec99f93f005ff29282f275dfdaf49206aa04
Here's my thought: store the cursor of all paginated queries in a local state directory, then use that cursor if
--cursoris passed to the query.
example use case:sxmo-utils$ hut lists patchset list | grep proposed #32739 proposed ... 8 days ago #32576 proposed ...14 days ago #32518 proposed ...16 days ago #32492 proposed ...18 days ago #32398 proposed ...22 days ago #32303 proposed ...26 days ago sxmo-utils$ # I don't see the one that I want yet. sxmo-utils$ hut lists patchset list --cursor| grep proposed #31955 proposed ...a month ago sxmo-utils$ # Ah, there it is! sxmo-utils$ hut lists patchset show 31955 # ... continuing my workflow, unhindered by the limits.
Under the hood somewhere, there's a directory (ideally in memory, not disk) that stores files like
"patches.~mil.sxmo-utils.cursor"containing "gAAAAABIamACursorWWyIoW8V...". And those files get removed whenever there is no cursor (that is,
--cursorwon't do anything in that context)
Routes / connecting lines are quite slow to render and noticeably effect performance even with small routes.
For the cases when I'm using the pinephone keyboard typically what I do is just disable
fbp, e.g. ala
And then all f_scripts can be used either directly from the framebuffer or from an X session etc directly since fbp is only a soft dependency! I often do this for things like
f_networkseven from X which is sometimes more convenient then framebuffer especially if you're hooked up to a keyboard.
Note for rotation in framebuffer, you can run
Thanks for looking into & flagging this (!) it was indeed broken based on the commit you mentioned.
I've corrected this issue on tip & also tagged 0.4.2 to correct this as well as this is a blaring issue.
Implemented touch gestures within fbp itself as this is cleaner then having an extra touch-handling daemon
Ah i see, so is that at the max (or highest) zoom level? It's readable for me at max zoom level, but I suppose it is a bit small.
Perhaps we could have 'emulated' zoom levels beyond the max - wherein tiles are scaled up in size. The only thing is since the tiledata comes in from servers as raster PNG files scaling wouldn't be 'pretty' / may look pixelated which I'm not sure should be accessible as a default.
Ah so you can set the preference
prefset fontsize_ui 40;
Also you can use 3-finger rotate gesture or central menu item
Update Fontsizeto change as a one-off thing.
I agree it maybe a bit on the smaller side or too small by default on high DPI displays. I kind of wonder about making the fontsize somehow proportional to screensize (as on non HighDPI displays its plenty large).