Open coderobe opened 4 years ago
i'm not sure i like the second better to be honest ...
@evilsocket it gets worse the bigger the browser window is
yes and the same applies for your type of zooming, which is pixelated by default ...
The pixelated
attribute uses nearest-neighbor resampling, so this is exactly how it looks on the device itself, just larger
yes i understand how it works, i'm arguing wether or not that's an improvement ... we're discussing this on the Slack and i'm not the only one preferring the original type of zoom
Hm, interesting. Maybe we can make it configurable?
yes a configuration option to add custom css to the web ui would be better :D
Hm, just spitballing, but what would be nice would be several simple defaults to pick (i.e. smooth, nearest-neighbor) for the image scaling and also a custom css box, just to offer easy options to pick instead of requiring the user to write css for the low-hanging fruit
That is an overcomplication of a feature that is supposed to be simple just because you don't like the default zoom effect.
Wouldn't it be a cool solution to just serve a small js file from the pwnagotchi which renders the complete ui as html? The devices used to open the webui are quite powerful, so there should be no reason to not use client-side rendering from an (json) api.
I also saw some issues when I tested the lcd hat which generates images, that are quite small and don't really work in a browser
i understand the small lcd screens usecase, but apart from that this seems like another overcomplication to me
true... then probably at lease render a high-res image with a configurable width? This would also solve the blurry images issue. You could then configure your pwnagotchi to e.g. always render a 1080px image if you are on a fullhd mobile phone in portrait mode (just thinking aloud...). I'd reckon that most users will always use the same device for webui
what i was thinking is to refactor the webui logic as one of the displays, so that the layout can be customized like for a phisical one
I like that approach - the Web UI becomes another display with access to the same state machine as the epaper display class, so can do its own thing.
yep
just had another thought into this. how costly is the creation of an image? If it's not that hard, you could also go one step further and generate let's say 4 images (768px, 1080px. 1366px, 1920px) and use an image srcset to let the browser decide which image to take. This way you would not even have to care about the targeted device as user.
after loading the AI, generating a single image (and rotating it when necessary) is the most CPU and I/O intensive task, so I'd say no :D
we need a better PiZ :D
I am using the default 2.13 waveshare V2 epaper display and the seconds started to get cut off once the my uptime hit 3 digits, i can take a picture of my display showing this if needed, since it was a similar issue to this ticket i thought it would be better to add it then open a new ticket
@deveth0 "Wouldn't it be a cool solution to just serve a small js file from the pwnagotchi which renders the complete ui as html? The devices used to open the webui are quite powerful, so there should be no reason to not use client-side rendering from an (json) api."
If it helps at all, I just finished an initial version of a Pwnagotchi API plug-in for some of my monitoring kit. I just needed a JSON response so I could drop the details into a dashboard, but I added a URL to retrieve an HTML page which queries the API and uses the JSON to render the page. That may suit your particular use-case. https://github.com/dipsylala/pwnagotchi-state-api/
the easiest solution as i said is just to refactor the webui as an indipendent type of display that can have any customizable layout ... let's not overcomplicate things :)
well since it's basically done already ... :P
reverted as PR #596 was just too broken
The Web UI uses the browser default for scaling the pwnagotchi UI, which may blur the image.
Steps to reproduce the behavior:
It is supposed to look like this: