When at the right edge, resize options are limited – Custom resizer needed

[rugk]

As you re-size to the bottom/right, when the icon is at the right (i.e. you have no second screen to the right; you have no other buttons right next to it, window is maximized -> so you are already at the right border of your screen).

Solution: Put a/Move the resizer at the bottom-left edge of the window.

This is hard to do, because the re-size icon is actually from the textarea – that's the default browser thing. It's all built-in – also the actual re-sizing process is built-in and does not use any JS at all.
So all this stuff, would be needed to be built by hand. Or – likely – a nice library has to be found.

Ideal implementation:

• resizer should be configurable (left edge, right edge, or both, or none – while we are at it)

Edit (2019-05-25): Likely to be made in connection with #189

[ENT8R]

Maybe this is a possible solution/workaround?
https://stackoverflow.com/a/12541137/8575129

[rugk]

Well…

There are other side effects that you cannot override. The vertical scroll bar will appear on the left. The cursor will appear at the left at times (after typing in a directionally neutral character), even characters will appear on the right when typing only left-to-right characters intermixed with neutral characters – though directionally neutral characters first appear at the left (test with typing “abc (1) x” to see what I mean).

So this really does not look like a good workaround. 😃

[rugk]

Session-sync again does this as I want, but AFAIK they also just use some JS/self-made re-sizer for this.

Best would be if we had a nice (and possibly tiny!) lib for this, as I don't know whether making it oneself is trivial. Or maybe it is and we can drop some listeners to resize events (or actually, textarea changes), which could be a good thing – or not, because all the stuff resizing triggers is quite complex right now. (Thoughtful it is self-contained and should be independent on what actually triggers it, but sometimes timing and stuff matters, so this would need intensive testing.)

[rugk]

So I think this issue requires some remake of the whole re-sizing stuff. I hope I finally fixed #66, but resizing is still not really realizable.

So when we have a custom resizer, it may also – in contrast to the current way – not resize the textarea and QR code one by one, but just the whole body. Actually the content should be responsive enough to resize itself (it is a flexbox).

[rugk]

I'd suggest resizing the QR via mousewheel event instead of the textarea.

Okay, nice idea, but does not work on touch screens. Also I'd argue it's less intuitive as there is no visual indicator for this feature, but it can be an additional feature request. (actually, possibly rather with Ctrl+mouse wheel to emulate a "zooming" effect.
Trying that [as it's just a usual web page] that actually already "works" (note: that's a joke, it looks like this:)

Anyway would you mind to open a new issue for that?

probably just fit the content

Also a different suggestions, and one that may work for small text input, but fails if you have larger input. (Ctrl+A here and generate a QR code out of it 😉) Actually, seeing the input is not important for the user (they know it), the input field is just there to input new text, actually.
So I 'd say this is not useful.

[rugk]

You can add some dismissible info on the first launch.

That is a(n UX) workaround, i.e. it does not actually make it more intuitive. Thus I prefer a small resize icon, that's how users have used these things for ages and thus it is intuitive (= users are accustomed to it)

Also add pinch to zoom.

Okay, yeah, fair enough. Actually, resizing on touch interfaces by clicking the small button at the right bottom is indeed really hard.

It doesn't fail, you still need max-height

Okay, then. It's a gimmick then. Also note if the QR code get's bigger and you have more width, so it already usually has a decent sitze.
As said, I don't really care for that input field much, at leats not for it's output function. I really only need it for an input function.

Nah because it would make sense as a replacement for this, not as an additional thing. This circles back to the comment in the other thread: keep things simple, no need for 10 ways to do the same thing :D

No, no, no. First of all, it's not good we have things to do things differently. Especially as we have both advantages and disadvantages for touch devices here with each approach.

So then do I: #189

So it would be good, if we could have both.

It does a lot, but the UI is extremely minimal

Yeah, okay, if "a lot" is disabling and enabling an extension, nice. And my add-on does the same… okay, not a lot: display a QR code + input and things. And it's main UI is also simple. (It just has a lot of options, you can make use of.)
Anyway, this is off-topic.