3 ms·

I can't speak for the alternatives you suggest, but I feel you're being overly unfair on this project. Even if it wasn't at all practical, it's still an interes

I can't speak for the alternatives you suggest, but I feel you're being overly unfair on this project. Even if it wasn't at all practical, it's still an interesting demonstration of the approach. Plus, it sounds like the author finds it useful, and I'm sure there are relevant use-cases. Maybe you could explain the "run a browser in a framebuffer" technique for those of us unfamiliar with it. Zooming (not panning) is essentially as easy as scrolling, and I'm looking forward to a day where it's utilised more since it's such a natural motion. I can image a desktop (relevant!) that presents a huge 'canvas', allows you to zoom in and out of the filesystem, navigate the web at different levels, etc. There's definitely potential in interface design; what annoys you about zoom? I agree it shouldn't be a primary action that one would have to carry out very frequently.

Fnoord 9y ago
I'm just expressing how I don't see it useful (I'm curious to hear use cases though). That doesn't mean I want nobody in the world to find it useful. That's up to each and every one of us. Heck, perhaps it can be improved, who knows. These projects I mentioned have already (partly) tackled the latency issues. RDP and NX suffers far less from latency issues than X11 and VNC. As for framebuffer, see [1] [2] for examples. Although now that I'm looking into it perhaps my friend was using Links2 and not a Mozilla offspring. I remember he also used lynx/w3m/dillo. As you can see from the example, one could just run MPlayer locally back in those days, with a framebuffer on a local tty. Apparently YouTube works as well [3]. DirectFB links seem dead though, and it seems MPlayer website is also down [4]. Zooming appears a natural motion on mobile devices because it allows one to see more content which is hidden due to physical reasons (a trade-off). Do you really find that useful on todays large monitors? Laptops even? Instead, it appears that for desktop devices scrolling provides adequate user experience. Zooming was added ages ago in Xorg, allowing a compositing window manager to utilise. Has it been used a lot besides the obvious accessibility feature? The only reason it is usable in this specific use case is the low amount of pixels (low pixel density). But I am curious to all these use cases you got in mind for zooming. [1] https://en.wikipedia.org/wiki/DirectFB https://en.wikipedia.org/wiki/DirectFB [2] https://en.wikipedia.org/wiki/Linux_framebuffer https://en.wikipedia.org/wiki/Linux_framebuffer [3] https://github.com/notro/fbtft/wiki/Framebuffer-use https://github.com/notro/fbtft/wiki/Framebuffer-use [4] https://www.mplayerhq.hu/DOCS/HTML/en/fbdev.html https://www.mplayerhq.hu/DOCS/HTML/en/fbdev.html
- Piskvorrr 9y ago
  I have a use case! I travel with my smartphone (and leave my desktop at home), but I receive links to huge files via document sharing sites (gigabytes and up - not the medium I would choose, but the choice isn't mine: the clients like those, for some strange reason). The links expire quickly, are not downloadable through console browsers (JS/images/CAPTCHAs), and I might not even have enough space and/or bandwidth to download them locally, to the smartphone. Up to now, I've had to resort to weird hacks such as "X+ssh forwarding a remote xpra session from the desktop, with a browser window in it", which sort-of-worked, but was painfully slow. This is a different approach, one that seems workable. Zooming is necessary due to the smallish smartphone display, "latency issues tackled by RDP" is mostly wishful thinking (okay, it's gone from "unusably bad" to "just bearably bad").
  - Fnoord 9y ago
    Right so, if the previous options of running UI apps remotely don't work, you'd need a web browser with JPEG, PNG, JS and Linux framebuffer support. Dillo and Lynx are quick. Dillo last release was 2 years ago. Lynx is in active development. They don't have JS support though. Links has support for JPEG/PNG and Linux framebuffer but somewhere in '00s they removed JS support (it was an unmaintained port of spidermonkey). ELinks port which also supported all 4 features is dead. There's surf and uzbl. I don't know the latter much, former is used with keyboard shortcuts only. AFAIK these don't use the Linux framebuffer. Dooble is a lightweight web browser, but no Linux framebuffer support. I question wanting JS 24/7 locally. You can also just not load all these JS nonsense and have a quicker experience (with NoScript or uMatrix). Same with loading all images. You could use a proxy to downsize JPEG pictures as well. The very first Opera versions on mobile phones did the same thing. They didn't even serve HTML! They spoke a different language with the browser. I'm not sure if Vivaldi (formerly Opera) still employs this feature. But you need to remember there's a market for this in upcoming economies where mobile bandwidth is scarce. Sources used [1] [2] [1] https://en.wikipedia.org/wiki/Comparison_of_web_browsers https://en.wikipedia.org/wiki/Comparison_of_web_browsers [2] https://en.wikipedia.org/wiki/List_of_web_browsers_for_Unix_and_Unix-like_operating_systems https://en.wikipedia.org/wiki/List_of_web_browsers_for_Unix_...

Fnoord 9y ago

I'm just expressing how I don't see it useful (I'm curious to hear use cases though). That doesn't mean I want nobody in the world to find it useful. That's up to each and every one of us. Heck, perhaps it can be improved, who knows. These projects I mentioned have already (partly) tackled the latency issues. RDP and NX suffers far less from latency issues than X11 and VNC. As for framebuffer, see [1] [2] for examples. Although now that I'm looking into it perhaps my friend was using Links2 and not a Mozilla offspring. I remember he also used lynx/w3m/dillo. As you can see from the example, one could just run MPlayer locally back in those days, with a framebuffer on a local tty. Apparently YouTube works as well [3]. DirectFB links seem dead though, and it seems MPlayer website is also down [4]. Zooming appears a natural motion on mobile devices because it allows one to see more content which is hidden due to physical reasons (a trade-off). Do you really find that useful on todays large monitors? Laptops even? Instead, it appears that for desktop devices scrolling provides adequate user experience. Zooming was added ages ago in Xorg, allowing a compositing window manager to utilise. Has it been used a lot besides the obvious accessibility feature? The only reason it is usable in this specific use case is the low amount of pixels (low pixel density). But I am curious to all these use cases you got in mind for zooming. [1] https://en.wikipedia.org/wiki/DirectFB https://en.wikipedia.org/wiki/DirectFB [2] https://en.wikipedia.org/wiki/Linux_framebuffer https://en.wikipedia.org/wiki/Linux_framebuffer [3] https://github.com/notro/fbtft/wiki/Framebuffer-use https://github.com/notro/fbtft/wiki/Framebuffer-use [4] https://www.mplayerhq.hu/DOCS/HTML/en/fbdev.html https://www.mplayerhq.hu/DOCS/HTML/en/fbdev.html

Piskvorrr 9y ago
I have a use case! I travel with my smartphone (and leave my desktop at home), but I receive links to huge files via document sharing sites (gigabytes and up - not the medium I would choose, but the choice isn't mine: the clients like those, for some strange reason). The links expire quickly, are not downloadable through console browsers (JS/images/CAPTCHAs), and I might not even have enough space and/or bandwidth to download them locally, to the smartphone. Up to now, I've had to resort to weird hacks such as "X+ssh forwarding a remote xpra session from the desktop, with a browser window in it", which sort-of-worked, but was painfully slow. This is a different approach, one that seems workable. Zooming is necessary due to the smallish smartphone display, "latency issues tackled by RDP" is mostly wishful thinking (okay, it's gone from "unusably bad" to "just bearably bad").
- Fnoord 9y ago
  Right so, if the previous options of running UI apps remotely don't work, you'd need a web browser with JPEG, PNG, JS and Linux framebuffer support. Dillo and Lynx are quick. Dillo last release was 2 years ago. Lynx is in active development. They don't have JS support though. Links has support for JPEG/PNG and Linux framebuffer but somewhere in '00s they removed JS support (it was an unmaintained port of spidermonkey). ELinks port which also supported all 4 features is dead. There's surf and uzbl. I don't know the latter much, former is used with keyboard shortcuts only. AFAIK these don't use the Linux framebuffer. Dooble is a lightweight web browser, but no Linux framebuffer support. I question wanting JS 24/7 locally. You can also just not load all these JS nonsense and have a quicker experience (with NoScript or uMatrix). Same with loading all images. You could use a proxy to downsize JPEG pictures as well. The very first Opera versions on mobile phones did the same thing. They didn't even serve HTML! They spoke a different language with the browser. I'm not sure if Vivaldi (formerly Opera) still employs this feature. But you need to remember there's a market for this in upcoming economies where mobile bandwidth is scarce. Sources used [1] [2] [1] https://en.wikipedia.org/wiki/Comparison_of_web_browsers https://en.wikipedia.org/wiki/Comparison_of_web_browsers [2] https://en.wikipedia.org/wiki/List_of_web_browsers_for_Unix_and_Unix-like_operating_systems https://en.wikipedia.org/wiki/List_of_web_browsers_for_Unix_...