Collapse input text module when the text is too big

[Rigerhit047]

Describe a related problem (optional)

I have been forced to put the input text module on the drawer, since when there is too much text on the link (like with an auth link, a redirection or a link with preferences) it will take all of the URLChecker window or a big part of it, depending on the URL size, therefore making it unsuitable to have it as a non-collapsable module, since it will make the experience worse having to scroll down a lot if it is in the top which is also its default position.

Describe your suggested feature

It should collapse after reaching a certain amount of characters, so that it doesn't take all of the screen or a big part of it, since it is not normally needed to see all of the link, and if you want to see it, the user would just tap it to view it in full, or use the Uri parts module.

So if a link has a certain amount of characters, it should collapse it until you enter edit mode. Like this:

Describe alternatives you've considered for your suggested feature

Other options would be to only collpase the link if it would take a set % of screen size, or when it has taken a certain amount of lines. Maybe introduced by the user itself if it is not easy to calculate.

There is also the minimalist route of just showing the domain highlighted and some paths like a PC browser, and show the rest of the link if you enter edit mode, although I do not know if that idea would be liked, but it would certainly make the input text more clean to look at and not hinder the rest of the modules.

Other details

No response

Acknowledgements

• [X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
• [X] I have written a short but informative title.
• [X] I will fill out all of the requested information in this form.

[TrianguloY]

It's made like that on purpose, because I consider that a long link should be reviewed before accessing it, even if it requires some scrolling.

But I can understand why it's not desired, and it should be easy to allow the user to configure a maximum number of lines to show for example (even if by default it will show all).

In edit mode though I think it would be best to show it in full, although having it in a smaller scrollable list could also be a solution (however a scrollable list inside another scrollable list may have some issues in some cases).

If you could edit the application code to be exactly like you want (no settings required) how would you do it?

[PabloOQ]

Some ideas I have thought of:

• In edit view, I think the scroll, while weird might be useful with these kind of URLs which are just obnoxiusly huge
• In read view, ellipses might do the job, BUT domain is always fully shown as this is the most dangerous part.

  ---

• Color coded, I know that there is the bold and italics, I have no problem with these, but maybe some find it hard to read.
• Now that I said color coded, maybe Pattern checker could talk back to the input module and instead, that is how it is color coded (background or letters), that way it can be easily customizable, for example it highlights http in yellow with the https pattern.

[Rigerhit047]

I agree that a long link should be reviewed, the problem is when you come across long links regularly, highlighting the possible case of links with preferences or redirections appended to them that a user comes across daily. I do agree with PabloOQ's ideas, but I would do it a bit differently:

• In read view, I would have all the link greyed out, and have only the domain in white/black, so it is highlighted for the user and it is easy to spot compared to using bold or italics, like PC browsers do.

• The idea of highlighting based on Pattern checker is VERY good, and I would implement it in the read view, so the Pattern checker would take priority for setting the color (maybe a darker variant if it is not the domain), although it would need changes that could possibly come with the planned advanced json editor, an user could input its color preferences to each of the patterns and maybe give it a variable to see if they should highlight the link or not, for universal patterns like the "Summarize This!" or "Proxy it with archive.org", so they aren't always highlighting the link when it's not needed.

And I would give it priority based on the order they are in, so that would make the non-ASCII and HTTP pattern have priority over the rest by default, another option is that instead of coloring the whole section, it would display an underline instead, that way there can be multiple underlines for each pattern so they are all visible, that could look a bit weird, though and that is probably not easy to implement either.

• Having that in consideration, in read view it would ALWAYS show the domain, period. If there is not an user variable for characters/lines, the cut-off to an ellipses should be around 2 or 3 lines of text, to keep tidy the rest of the app, and that can accomodate a lot of links without interrupting them, at least in a standard screen size. If the link is bigger than that, it will show an ellipses. If somehow the link goes to that limit without printing the whole domain, then it would just continue until the whole domain shows up (in the worst case scenario we could trim the start, too, but I do not think that is necessary). If there is a pattern recognized beyond the ellipses, it would color the ellipses to match the pattern, or if there are multiple, it would add a little exclamation sign (or just the exclamation mark by itself) next to them to inform the user there are more patterns recognized in the link.

• To add to that Pattern checker idea; I would do the same with the Uri parts module, let users to select a hex code to color each uri part, that way, they would have an easier time reading a full link, useful for a user to locate a query or path with a redirection url and have more of a visual indication for the user of the components of a URL.

• Now with edit mode, the link would show up fully, but to not have the same issue as before, it would show at least 4/5 (or user/screen defined) lines of text on a standard screen size of the link, and have a second scroll to navigate the big link without having it fill the whole interface, so it is easier for the end user, I would convert the module to a text box, so the user could see the scroll at the side, and it would make sense visually to have the edit mode in a text box.

• The edit view would not use the pattern colors when you are editing it, instead, when an user taps the link, instead of directly opening the keyboard and selecting the text, it would be like a "preview view" where it would be just edit view but without opening the keyboard and the text bar, and it would be scrollable to see all the found patterns and the link without forcing the user to close the keyboard after it is opened just for seeing the link, and then they would need to tap it again to actually enter edit view, where it would show the text as-is, then they would need to tap outside of the text box, which would need to be a bit shorter than the URLCheck window to not close the window by error, to exit edit mode and preview their new link, and tap again to have the link in read view so they could move in ease, make changes and seeing them without issue.

Even if the module doesn't turn color-coded, it would be useful to have it act like that. That way, it would make sense to the input text to be scrollable if it is in a text box, it would be easy to exit edit view. You cannot exit edit view currently without hidding the module with the banner or if the link changes when checking its status, unshortening it, or using the history module.

With those changes, the input text module would look clean with colors (or just with the gray and black/white) and be informative, will be able to view and manipulate the link without issues, and would allow the user to be able to customize the app further, if there are actually user variables for colors and text limits or at least for screen sizes.

[TrianguloY]

so many ideas 😵

I think for now it's best to start simple and just have the option to limit the number of displayed lines. Since a scrollable 'inside-view' seems to be mentioned a lot, that would probably be the best setup, both in normal and edit mode.

I really like the 'use color instead of bold for the domain' (or even better: both) because with the new 'visual' mode in the edit module the text is less saturated. I'll probably try to implement this...sometime.

As for using color in the visual module, even if that seems useful (and I'm sure it is) I would like to keep modules independent (as much as possible). In fact when I developed the pattern module for the first time, I tried to make it so that the 'invalid characters' pattern would show those invalid characters in the url. But the code to maintain inter-module communication is hard and becomes a mess pretty fast, so as I said I would like to avoid that if possible. Having a separate configuration in the text module just to highlight regex patterns with colors may be a nice idea though. It's true that you will need to 'duplicate' some patterns, but that would be far easier to implement (In fact it could be really easy...I need to think about it).

Anyway, that you so much for your opinion and ideas! Most probably I won't be able to implement most of them, sorry, but still they are interesting to think about, and I may add some of the easy ones. (also, as usual, prs are welcomed! but please try to keep them short :)

[Rigerhit047]

Haha, well, you did ask for how I'd do it, so that's that, but realistically I would just be happy if the module collapses where there it is due and only maybe the domain highlighting as a little extra.

You make a great point, it would really cause problems if the modules stop being, well, modularized, you really make a great point there, I forgot for a moment they were modules. Have a nice day :)

[TrianguloY]

I'll add the option to limit the number of lines in the view mode, no problem.

For the edit mode however, I had to replace it with a popup editor (to avoid triggering updates each time a character was entered, otherwise the automation was going crazy). Now, when you click the text, a new popup is opened with the full text (also, the keyboard open automatically). You have the options to accept or discard the changes.

This is a mockup (some things may change in the final version). I personally like this change, but I'm interested in your opinion about it:

https://github.com/user-attachments/assets/30bd2289-e2e6-4794-8702-73398aa9d34f

[Rigerhit047]

I think that is actually perfect! The editor in a popup does makes sense and find it a welcome change. I find the text limit to be juust right and the scrollbar does look really good, many thanks for doing it! :)

[TrianguloY]

Turns out that making a scrolling thing inside another scrolling thing in android is almost impossible (on android, the outer scrollview will 'eat' the touch events and the inner scrollview have no chance for reacting to them). There are hacks and workarounds, but I was unable to make them work no matter how much I tried. There is apparently a solution using an external library, but triplicating the app size just for this...I would like to avoid it.

If the outer scrollview is not scrollable (if the height is small) it will work as expected (more or less) but as soon as the outer scroll is long enough...it will just not work. On the video above I tested with a small dialog, that's why it was working (I also hardcoded the height, but I think I can solve that).

So, in order to avoid spending more time on this, I can either leave this feature for the future, or implement a simple maxLines setting that will cut the number of displayed lines, even though you won't be able to scroll to see them, you will need to click the view. What would you prefer?

Sorry for the bad news

Edit: I'll just skip this for now