-
Notifications
You must be signed in to change notification settings - Fork 312
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
Making an advanced UIInputText
#1318
Comments
I know you have requested copy and paste before in pyglet/pyglet#593. However, supporting copy and paste inside arcade or pyglet is a project on its own. There are multiple reasons that pyglet only detects copy and paste related events without handling them:
We have two choices for implementing copy and paste, and either will get complicated because both require handling the concept of different types of paste data. For example, what happens when a user tries to paste into a text box when there is image data in the clipboard? Does that trigger an exception? Option 1: Write our own bindingThis could be put in pyglet itself. In general, binding Win32 C APIs in ctypes is tedious but effective if you know exactly what you want to achieve. I've done it before. However, there are multiple additional complications in addition to the ones I've already mentioned. First, there appear to be at least two different ways of handling copy and paste in Windows. Second, Win32's OLE model introduces multiple layers of additional complexity such as clients, servers, and compound documents. Option 2: Use an external dependencyThere are multiple potential issues here. In addition to having to make sure all our target platforms are supported, we also get into some of the same issues mentioned for writing our own binding. Also, there's licensing. |
I used |
If we don't want external dependencies, we could make something that only keeps the copy and pasted text within the application. We could just create a list during initialization, then add copied and pasted text to it. The downside of this is that it can be exported to other applications. |
I've looked at many other GUI toolkits, like
tkinter
,PyQt5
, and some other libraries, and I noticed they each have two separate input widgets: a text entry and an advanced one. I was thinking if we could implement something like that in Arcade. We should call it something likeUIText
orUIAdvancedText
.tkinter
provides aText
widget, which handles formatting in specific tags, which have names, start, and end attributes. TheText
widget also can insert images and other widgets. AndPyQt5
has aTextEdit
widget which allows easy formatting for creating text editors.An advanced text entry in Arcade would support rich text formatting, complete with shortcuts like Control-b for bold, easy functions for adding images, copy and paste support, select all support, and much more.
Pyglet does provide formatted documents that are pretty easy to use. You create text, and you can add styles to it in different ranges with specified formatting. We could even add
insert
anddelete
functions, which accept ranges and text, to make it easy for users to delete text. Like many GUI toolkits, the basic text entry is only singleline, but the multiline text widget supports all of these formats.I've been working on something like this in my own Arcade GUI toolkit I'm planning to largely distribute, but I'm getting glyph errors when I use formatted documents in the
IncrementalTextLayout
. Because inpyglet
, documents can be attached to layouts, we can just make the document formatted like apyglet.text.document.FormattedDocument
.Adding keyboard shortcuts and methods for formatting shouldn't be too hard. Below is some of the code I've used for my own toolkit. It's intended to be used programmatically. (BTW I'm using a custom documentation format)
This widget could be really helpful in making rich text user descriptions, notes, and more.
UPDATE: Currently I'm experiencing issues with glyph management; pyglet thinks some glyphs are empty sometimes, and the selected background color is messed up so the selected text and its background color are completely transparent. There is another bug where two areas are supposedly selected, but one is with the correct background and the other one is without.
Another system we would have to add is a system that would check for overlapping styles, and then append them to the style stack. For example, if a range of text was made bold by the user, then italic sometime later on, then a system would have to be made so that the bold is added to the range. It could just check the added styles there, then format the style dictionary to have the included style.
The text was updated successfully, but these errors were encountered: