Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Website doesn't work well on phone #218

Open
irevoire opened this issue Oct 29, 2023 · 11 comments
Open

Website doesn't work well on phone #218

irevoire opened this issue Oct 29, 2023 · 11 comments

Comments

@irevoire
Copy link
Contributor

Hey, it's really hard to use the website on my iPhone.
Basically, everytime I write a letter it scrolls and I can't see what I'm writting
https://github.com/sharkdp/numbat/assets/7032172/431b8e88-08a6-4f7e-9c23-7826f19b1704

Second thing is I can't fix my typos. I basically can't move the cursor at all.

I had the same issues with insect.sh btw

@giomf
Copy link

giomf commented Nov 2, 2023

Have similar issues on my Android phone.
When I hit space after a unit, it evaluates the line I just wrote.

Works fine without units.

@sharkdp
Copy link
Owner

sharkdp commented Nov 2, 2023

I was afraid that this would be the case ☹️

It sort of works on Firefox for Android — which is the only browser I tested. But even there, it is very far from being fun to work with.

Any help in improving this situation would be very much appreciated. Maybe it can be fixed with a few CSS changes, but my CSS "skills" are not enough to work on this myself.

I could also imagine that it is easier to improve the situation by switching to another terminal-in-the-browser library, such as http://xtermjs.org/?

@sharkdp sharkdp changed the title Website doesn't works well on phone Website doesn't work well on phone Nov 24, 2023
@sharkdp
Copy link
Owner

sharkdp commented Feb 21, 2024

Just as a side remark.. I am working on a mobile version. I think it makes sense to have a mobile-oriented user interface that does not focus on typing in the same way that the current desktop-oriented interface does with its readline-like interface (which relies on the existence of arrow keys, Ctrl-R, etc).

Sneak peek:

@bsidhom
Copy link

bsidhom commented Feb 22, 2024

@sharkdp Do you have a preview branch with this mobile UI by any chance? I'd love to test it out (especially with the new offline PWA stuff). 🙂

@bsidhom
Copy link

bsidhom commented Feb 23, 2024

As a quick workaround, I tried the suggestions here and listening to resize and orientationchange events on the window. Unfortunately, the new meta attributes are not supported on iOS Safari (though I'm not sure that would fix the issue anyway). Resize events do seem to fire when the virtual keyboard pops up, but window.innerSize has not updated by this point. Instead, the inner size changes after you start typing, but no event is fired at that point. I guess we could use a mutation listener or something to capture it, but this is pretty tricky to get right. The better solution does seem to be to use a mobile-oriented UI. I'm trying to figure out if jQuery Terminal has any features to overcome this but haven't found anything yet.

@bsidhom
Copy link

bsidhom commented Feb 23, 2024

Apparently this seems to be a well-known issue with jQuery Terminal. Interestingly, there's an example page in that issue which seems to include a fix. I'm trying to figure out how it works, as I haven't found the source code yet.

Also related: apparently the author of jQuery Terminal is switching focus to https://github.com/pure-terminal/pure-terminal, which does not have the jQuery dependency. Not sure if it would address this issue or how easy it would be to switch to that. This may not make much sense in any case if the longer term plan is to switch to a real terminal emulator.

@bsidhom
Copy link

bsidhom commented Feb 23, 2024

Here's the canonical jQuery Terminal issue with the fix. Not sure when it'll actually be merged or if it requires any library changes.

@sharkdp
Copy link
Owner

sharkdp commented Feb 25, 2024

@sharkdp Do you have a preview branch with this mobile UI by any chance? I'd love to test it out (especially with the new offline PWA stuff). 🙂

So the screenshot I was showing is from a completely separate project where I built a mobile Numbat app with tauri. It uses web technologies for the frontend, but has a native backend (aarch64 on my smart phone), as opposed to the WASM backend that the web version uses. To be completely honest, I'm not yet sure if I am going to release it as open source. I was playing with the idea of releasing that as a ("open core") payed app for Android/iOS. I do not enjoy frontend work, so I thought the idea of (potentially, eventually) getting payed for it might be a motivation boost. But it's probably a ridiculous idea anyway, so feel free to talk me out of it 😄.

@sharkdp
Copy link
Owner

sharkdp commented Feb 25, 2024

Also related: apparently the author of jQuery Terminal is switching focus to https://github.com/pure-terminal/pure-terminal, which does not have the jQuery dependency. Not sure if it would address this issue or how easy it would be to switch to that.

Interesting! Adapting the JavaScript code to a new terminal emulator should be fairly quick, even if the API has completely changed. I'm not sure how long it would take to re-do the CSS things I did years ago to make the terminal look... a bit more modern.

@bsidhom
Copy link

bsidhom commented Feb 26, 2024

Also related: apparently the author of jQuery Terminal is switching focus to https://github.com/pure-terminal/pure-terminal, which does not have the jQuery dependency. Not sure if it would address this issue or how easy it would be to switch to that.

Interesting! Adapting the JavaScript code to a new terminal emulator should be fairly quick, even if the API has completely changed. I'm not sure how long it would take to re-do the CSS things I did years ago to make the terminal look... a bit more modern.

To be clear, I'm not sure whether that new emulator would actually fix the mobile scrolling/display issues. I'm all for modernizing it though. :) I'm starting to think that xterm.js makes more sense for keyboard-oriented inputs in any case.

@bsidhom
Copy link

bsidhom commented Feb 26, 2024

Full disclosure: I'm not a frontend developer, but I do have some recent experience with doing basic stuff in some personal projects.

Are you using Tauri proper or Dioxus? If you hate web development already, Tauri makes that even more complicated because you're integrating standard web UI stuff with complex interop. Dioxus is a bit more Rust-friendly, as it ships with a custom rsx! macro (similar to JSX/TSX used in React). This is pretty quick to get started with if you're familiar with the React way of doing things.

To be completely honest, I'm not yet sure if I am going to release it as open source. I was playing with the idea of releasing that as a ("open core") payed app for Android/iOS. I do not enjoy frontend work, so I thought the idea of (potentially, eventually) getting payed for it might be a motivation boost. But it's probably a ridiculous idea anyway, so feel free to talk me out of it 😄.

I don't want to talk you out of that if it's something you're serious about. I would probably even buy the app just to support the effort, especially if it's a great mobile experience. 😀

On the other hand, OSS definitely appeals to me and I would love to have as much of this as possible open. That makes it easier for other contributors to help and also makes it more extensible and embeddable. The idea of a PWA in particular really appeals to me because it opens the potential to automatically get support for new platforms that don't exist yet and allows a fully unified code base for all platforms. (Plus I'm allergic to app stores and their distribution policies in general. 😂)

If I were to do a web version of Numbat from scratch (or at least a fully reworked version), I would probably use Lit both because I'm familiar with it and it's more open, extensible, and embeddable than React. (React components do not play nicely with the rest of the web (unlike custom components, which are a web standard that Lit plugs into). I also have a strong preference for Lit due to its security measures, particularly in its HTML templating system. Anyway, the reason that I bring this up is because I was thinking of experimenting with a new mobile UI myself. In any case, I think that should proceed in parallel with whatever you're doing, as I don't know if mine will pan out.

If you did want to go the route of creating a private app, it would be nice to keep any WASM/web-specific plugin points and extensions in the open in order to make development of new UIs faster. I already spent some time thinking about APIs that might make this nicer, such as fuzzy querying for type, function, and variable names (for auto-complete), extension points (such as hosting WASM UDFs, which could also work in CLI and provide sandboxing for third-party plugins; CLI could even expose WASI for "real" work), a pluggable configuration system to allow configs/modules to be stored in an FS-agnostic way (e.g., to be used with the origin-private FS or FS Access API or IndexedDB on the web, on local disk for the CLI).

It's pretty pie-in-the-sky for me right now because I don't know how difficult much of this would be to implement or really how much I would want it once I had a working mobile app. It's mostly just driven by my desire to have a tool like this at my fingertips at all times through my phone. I've had a pipe dream of shipping GNU Units as a WASM web app for a while, but couldn't figure out how to make the experience nice. Numbat is already a great deal of the way there and has a better type system to boot. 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants