Website doesn't work well on phone

[irevoire]

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]

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]

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]

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]

@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]

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]

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]

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]

@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]

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]

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]

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. 😄

[lilydjwg]

It doesn't work well with my phone's onscreen keyboards, but with a physical keyboard (e.g. scrcpy -K) it works without issues. I guess it has conflicts with those composition events.

Also, while the input works in a desktop browser, the input method window isn't where it should be.

[Goju-Ryu]

I have found that the experimental interface from #536 works better although not perfectly on my phone. It can be found here: https://numbat.dev/editor.html

[lilydjwg]

The text of https://numbat.dev/editor.html is too big on my phone :-(
(It's very big on desktop as well but that's less a problem.)

[sharkdp]

Like I wrote in #550, any help on improving HTML/CSS/JS is very much appreciated.

[Goju-Ryu]

Like I wrote in #550, any help on improving HTML/CSS/JS is very much appreciated.

Do you have any preference in regard to the use of frameworks for it?

I have a little experience with frontend development in Vue, but not really with jquery so if I have time I might try to make something with it if you're not opposed to it.

[sharkdp]

Do you have any preference in regard to the use of frameworks for it?

No. If you think we definitely need a framework for this, please feel free to choose whatever you like best for this task.

[Goju-Ryu]

No. If you think we definitely need a framework for this, please feel free to choose whatever you like best for this task.

I don't think we definitely need it, it's just where I have the most experience. I will tinker with it a bit and see if I can figure something out to improve it. Then I can always make an alternative implementation with a framework if I don't like the results.