TextInput: Fix readonly mode preventing using cursor keys, wrapping, and more

[tshirtman]

Maintainer merge checklist

• Title is descriptive/clear for inclusion in release notes.
• Applied a Component: xxx label.
• Applied the api-deprecation or api-break label.
• Applied the release-highlight label to be highlighted in release notes.
• Added to the milestone version it was merged into.
• Unittests are included in PR.
• Properly documented, including versionadded, versionchanged as needed.

[matham]

Since you're working on textinput, I noticed when testing rtl with harfbuzz that the cursor appears in the wrong side of the text (on the right, rather than left). Feel free to ignore this though if it's unrelated to your changes. This would probably become hard quickly, especially since you can have rtl and ltr in the same text. But I guess rn we assume it just has one direction!?

[tshirtman]

I'll see if i spot the issue, currently we assume one line has a direction, but it might be different from the lines before and after, and this assume that the provider can tell us the direction of a string of character (the base implementation always return 'rtl', and pango is the only core text provider to provide an alternative implementation, but maybe sdl2 could have its own override when harfbuzz is present.

[matham]

Harfbuzz doesn't seem to have an API for getting the direction of text, so only pango can currently provide it. We'd need fribidi to implement it ourselves.

[matham]

This is your revenge for the giant properties PR, isn't it 😅🤣

One thing I noticed, which is probably a old bug, but since you fixed wrapping you may want to look at it, but don't feel obligated:

• With a long line that wraps, if you place cursor at start of second line where it wraps and backspace, wrapping will break and it'll be a long line again
  • In the above situation, hitting home/end keys brings you to end of line but it's off screen, but right/left arrow does scroll to the right.

[matham]

Suggested change

	modifiers = set(modifiers) - {'capslock', 'numlock'}
	modifiers = set(modifiers)

[matham]

Suggested change

	modifiers == {'ctrl'}
	or _is_osx and modifiers == {'meta'}
	'ctrl' in modifiers and 'meta' not in modifiers
	or _is_osx and 'ctrl' not in modifiers and 'meta' in modifiers

I think this is safer because numlock/capslock may not be the only modifiers active, but we can't know what they would be. But I don't feel very strongly about this.

[tshirtman]

I think we still have issues with cursor management indeed, that i would like to fix, regarding cursor management, i've seen some when do_wrap is False, and i'll look for the one you mention when it's True.

It's not a revenge PR, it's just that you said the code wasn't clear, and i very much agreed, so i tried to improve the situation, a bit all over the place (yes, it is revenge).

I'm not sure i can consider this done yet, i've also seen some glitches when backspacing on long lines, that would need to be addressed, hopefully i'll find the cause.

Thanks for the suggestions, i'll look at what they mean :).

[matham]

Looks like all the tests are failing. Lemme know if you're at a point that needs review (it looks ok to me besides the set comments above, but I didn't test the recent changes).

[tshirtman]

I had missed a part of the commit and forgot to check if the tests were passing >_>

[matham]

I think the problem is that it is named func but both return triggered.

[tshirtman]

yeah, i was tired i guess, max recursion 😆

[tshirtman]

Ok, just the mouse test failing now.

[matham]

There's a few more things I noticed as I was playing with it, but you don't have to fix it in this PR if you don't feel like it, these have been there for a while probably.

1. Look at the top box as I change the window width:
   
2. With a long line that wraps, if you backspace before the first character on second line, the previous line stops wrapping.
3. With a line that wraps across multiple lines or multi-line text, if you use up-arrow, it doesn't keep its position horizontally based on the pixel number offset from left, but rather based on number of characters. So with non-uniform character font, it looks weird and is different than e.g. firefox.

[tshirtman]

There's a few more things I noticed as I was playing with it, but you don't have to fix it in this PR if you don't feel like it, these have been there for a while probably.

Yeah, this one is large enough :D

1. Look at the top box as I change the window width:
   ![image](https://user-images.githubusercontent.com/1644286/113986057-d11f6780-981a-11eb-8f2d-19adf6c76121.png)

2. With a long line that wraps, if you backspace before the first character on second line, the previous line stops wrapping.

Funnily enough, i was able to reproduce this once a few days ago, but not on subsequent attempts, will have to try again.

3. With a line that wraps across multiple lines or multi-line text, if you use up-arrow, it doesn't keep its position horizontally based on the pixel number offset from left, but rather based on number of characters. So with non-uniform character font, it looks weird and is different than e.g. firefox.

Nice catch, i guess we could use the get_cursor_from_xy at the new y pos and the old x pos and move to that new index, or maybe there is a way to only do one jump.

[tshirtman]

Merged, i hope i didn’t break anything, pretty sure that did more good than harm though :D, at least it should be a tad easier to fix bugs in places the code was clarified.

[Alspb]

There is a problem if do_wrap is False: long lines are represented as black rectangles.
E.g. TextInput('aaaaa'+'\n'+'b'*3000+'\n'+'ccccc') looks like:

The reason is that the same holds true for Label (and textinput lines are in fact Labels). But for Label it's not a big issue (don't see any reason for using such long lines), while for TextInput it seems to be significant.

[maltfield]

See also https://stackoverflow.com/questions/72927741/kivy-read-only-textinput-but-with-ability-to-select-all-ctrla

(adding here to make it easier to find for others on search engines)

How can I make a TextInput in a python GUI app built with kivy that's read-only, but where the user can still select all of the text with crtl+a?

Consider the following simplified example program with a TextInput containing over 9000 characters

import random

from kivy.app import App
from kivy.uix.boxlayout import BoxLayout
from kivy.uix.textinput import TextInput

class MyApp(App):

	def build(self):
		layout = BoxLayout()

		# generate some random ASCII content
		textinput_contents = ''.join( [chr( random.randint(32,127) ) for i in range(0,9001)] )

		# add the textinput
		self.textinput1 = TextInput(
		 text=textinput_contents,
		 readonly=True
		)
		layout.add_widget(self.textinput1)

		return layout

if __name__ == "__main__":
	MyApp().run()

I don't want the user to be able to edit the contents of the TextInput, but I do want them to be able to click around, select text, copy from it, etc. Unfortunaetly, in the above example, typing ctrl+a (for the Select All shortcut) does nothing.

However, if I omit the readonly attribute, then ctrl+a works again!

import random

from kivy.app import App
from kivy.uix.boxlayout import BoxLayout
from kivy.uix.textinput import TextInput

class MyApp(App):

	def build(self):
		layout = BoxLayout()

		# generate some random ASCII content
		textinput_contents = ''.join( [chr( random.randint(32,127) ) for i in range(0,9001)] )

		# add the textinput
		self.textinput1 = TextInput(
		 text=textinput_contents
		)
		layout.add_widget(self.textinput1)

		return layout

if __name__ == "__main__":
	MyApp().run()

How can I make the kivy TextInput read-only without disabling Select-All (ctrl+a)?