New TextBox & IME integration tracking issue (report new TextBox issues here!) #1652
Comments
|
Thank you, it's very impressive!
|
To be honest, I feel this is out of scope for text handling. What "submitting" or "commiting" means in regard to changes to state highly depends on the application and the control/inout type. You might think search boxes and go 'yeah that seems nice to have', but in reality the search might automatically "commit" after a debounce, or it's also committed by an icon next to it. It might require entirely different ways of "submitting" the input depending on devices and peripherals. I feel like a mostly unrelated, general feature for forms/submission of inputs would be a more appropriate answer for this than cramming a special cased key handler into text widgets. I would take a look at how the web does it; in the context of a In component-oriented web development (React etc.) you end up building forms out in a nestable manner, so that you can embed a full form as a nasted "control type" if you will, inside another form, or generally build complex controls for complex datastructures. What you need for this is a simple interface for a "form control", and a grouping/aggregation mechanism for change propagation and submission (both directions in the tree, so to speak). |
Good note, I'll add some proper API for this. It's tricky to get right, and needs a separate mechanism.
😢 I was hoping nobody would notice. Can look into improving this, I think I needed it as a
I think we're more or less on the same page. The problem here is that if the textbox has focus, then the textbox receives the return event, and it has to decide what to do with it. The user should be able to specify that they want to handle return themselves, but we don't want them to just handle the raw So all I mean here is that we need to have some way for the user to configure the textbox to communicate to the user when the user should handle an enter/return event. This will be a simple mechanism, probably just a notification, but I could also imagine a custom |
|
@jpochyla what edit actions were you actually interested in dispatching? If you have the ability to view and modify the text and the selection, is that enough? |
|
@cmyr I was emulating basic Emacs shortcuts - C-A, C-E, C-K, etc., together with some shift variants. That is cursor movement, selection, text editing. I was hoping it would be possible to re-use the internal |
This is particularly relevant for when the user double-clicks a word. Previously if the click fell on a word boundary we would not recognize that; now if the click falls on a word boundary we will treat that as the start of the new selection range. In addition, word select now selects *anything* between two word boundaries; we do not care if it is actually a word. As an example: if the user double clicks in whitespcae, we will select any contiguous whitespace. progress on #1652
|
I notice a new issue, if the Texbox is not big enough to print its content the cursor is drawn outside from the Texbox. |
|
@HoNile Can you provide a reproduction? Also would be good to know what platform you're on. :) |
This is particularly relevant for when the user double-clicks a word. Previously if the click fell on a word boundary we would not recognize that; now if the click falls on a word boundary we will treat that as the start of the new selection range. In addition, word select now selects *anything* between two word boundaries; we do not care if it is actually a word. As an example: if the user double clicks in whitespcae, we will select any contiguous whitespace. progress on #1652
|
@cmyr Yes of course I am on windows 10 and behind a reproduction code, just put the cursor at the end from a textbox and resize (horizontally) to a smaller size the windows. use std::sync::Arc;
use druid::widget::{Flex, SizedBox, TextBox};
use druid::{AppLauncher, Data, Lens, LocalizedString, Widget, WidgetExt, WindowDesc};
const WINDOW_TITLE: LocalizedString<AppState> = LocalizedString::new("Text Options");
#[derive(Clone, Data, Lens)]
struct AppState {
text: Arc<String>,
}
pub fn main() {
let main_window = WindowDesc::new(build_root_widget())
.title(WINDOW_TITLE)
.window_size((300.0, 200.0));
let initial_state = AppState {
text: "blabla".to_string().into(),
};
AppLauncher::with_window(main_window)
.launch(initial_state)
.expect("Failed to launch application");
}
fn build_root_widget() -> impl Widget<AppState> {
Flex::row()
.with_flex_child(TextBox::multiline().expand_width().lens(AppState::text), 1.0)
.with_flex_child(TextBox::new().expand_width().lens(AppState::text), 1.0)
.with_child(SizedBox::empty().fix_width(110.0))
}Edit: small clarification. |
|
Does the cursor stay outside of the textbox when you start typing again? I see this on macOS but it looks like a drawing artifact (the cursor doesn't blink, and it goes away when you next type) |
This is particularly relevant for when the user double-clicks a word. Previously if the click fell on a word boundary we would not recognize that; now if the click falls on a word boundary we will treat that as the start of the new selection range. In addition, word select now selects *anything* between two word boundaries; we do not care if it is actually a word. As an example: if the user double clicks in whitespcae, we will select any contiguous whitespace. progress on #1652
|
Yes the cursor stay outside when i type again, but the cursor doesn't blink when outside (unless I'm resizing the window). Edit: I can even have two cursors if while an outside cursor is drawn I go back to the start from the texbox with arrow key. Edit²: I can move the outside cursor from one character with arrow key on the single line textbox. |
This is particularly relevant for when the user double-clicks a word. Previously if the click fell on a word boundary we would not recognize that; now if the click falls on a word boundary we will treat that as the start of the new selection range. In addition, word select now selects *anything* between two word boundaries; we do not care if it is actually a word. As an example: if the user double clicks in whitespcae, we will select any contiguous whitespace. progress on #1652
|
Wow, these latest developments are all very intriguing! 🍿 Hope this is the right place to report... I'm getting a Druid panic every time I've changed the contents of a thread 'main' panicked at 'called in this function in The last commit that worked for me was Any thoughts or suggestions would be most welcome. Thanks! |
|
Are you calling (this was previously only required when adding new widgets, but I think now we might need to always call it, in case a textbox was removed? 🤔) |
|
Funnily enough, this was one place I wasn't! Thanks for the catch... However, after adding the call to |
|
okay cool, just wanted to rule that out, I'll look into this a bit more. Is this on macOS? |
|
Thank you! This is on Windows 10. |
|
I notice a new issue, the IME's window position is not on the TextBox. |
|
@runiq IME isn't implemented on windows or linux yet, but the changes in this patch will change behaviour on linux and windows; in particular some keys are not going to be handled correctly, so testing and reporting of those problems would definitely be helpful! |
This is particularly relevant for when the user double-clicks a word. Previously if the click fell on a word boundary we would not recognize that; now if the click falls on a word boundary we will treat that as the start of the new selection range. In addition, word select now selects *anything* between two word boundaries; we do not care if it is actually a word. As an example: if the user double clicks in whitespcae, we will select any contiguous whitespace. progress on linebender#1652
- closes linebender#1125 - progress on linebender#1652
The textbox will now receive copy/cut/paste/undo/redo/select-all without a menu being present. Several of these (select-all, undo/redo) do not currently have implementations, but we will at least get the commands. - progress on linebender#1652 - closes linebender#1030
Observation on macOS with the
|
|
@kud1ing thanks, yea, select-all isn't implemented yet, and nor are undo/redo. |
|
@cmyr Thanks. Is much missing? The
|
|
textbox inner show context_menu, the mouse cursor style should change Cursor::Arrow，but now it's style is Cursor::IBeam |
|
It seems like #1425 continues to reproduce in a new window. Take a look at this example. Pasting some text and typing anything crashes the window. use druid::{widget::*, *};
#[derive(Data, Lens, Clone)]
struct State {
s: String,
}
pub fn main() {
let main = Button::new("launch").on_click(launch);
AppLauncher::with_window(WindowDesc::new(main))
.use_simple_logger()
.launch(())
.unwrap();
}
fn launch(ctx: &mut EventCtx, data: &mut (), env: &Env) {
ctx.new_sub_window(
WindowConfig::default(),
build_another(),
State { s: "".to_owned() },
env.clone(),
);
}
fn build_another() -> impl Widget<State> {
Flex::column().with_child(TextBox::new().with_placeholder("text").lens(State::s))
} |
|
I'm not able to trivially reproduce this on macOS? it's very possible I'm overlooking something. I'd also discourage using |
I'm on Linux + Wayland, so it might be platform specific. Here's a little clip of me copying and pasting :
I guess you can call it a modal. Will take a look anyway. Thanks. |
|
Regarding Ctrl/Cmd+A, see also #1854 |
|
I've been working on a todo app using druid and have generally been enjoying the experience, but recently ran into a serialization bug (fixed here: #1871) which required me to use main. Sadly I pretty immediately ran into a panic that I think is related to the new textbox. Unfortunately my app is a little convoluted, but basically I create a simple todo item with a textbox which edits the name of the todo using a lens. When the controller hears a key down for the return key, the todo item progresses to a new state, and the textbox is swapped out for a rawlabel. I'm not sure, but I think this causes a crash. I haven't dug in enough to determine what causes the crash but its on line https://github.com/linebender/druid/blob/master/druid/src/window.rs#L554 I'd really like to keep working on my app and exploring how far I can take it, but at this point I'm blocked between the serialization issue and this panic. Any tips or ideas for how to investigate this further would be appreciated. |
|
After some thinking, I decided to add a branch to my fork which introduces my PR fix to the current release (not containing the ime textbox changes) and am in a working state again. If time allows, I will try to create a minimal repro of the panic I ran into to help out here though. |
|
I am here to report a new issue for TextBox. It is a very minor issue, but it seems like (on the current master branch at least) TextBox's |
|
Not sure if this is the same as one of the issues mentionned here, but I get a panic when a textbox gets deleted with a keypress. Minimal repro: use druid::{widget::*, AppDelegate, *};
pub struct Closer;
impl<T: Data, W: Widget<T>> Controller<T, W> for Closer {
fn event(&mut self, child: &mut W, ctx: &mut druid::EventCtx, event: &druid::Event, data: &mut T, env: &druid::Env) {
match event {
Event::KeyDown(evt) if evt.key == druid::keyboard_types::Key::Escape => ctx.submit_command(CLOSE),
_ => child.event(ctx, event, data, env),
}
}
}
pub fn main() {
let main = Flex::column()
.with_child(
Button::<Option<String>>::new("show textbox").on_click(|_, data: &mut _, _| {
*data = Some(String::new());
}),
)
.with_child(Maybe::new(
|| TextBox::new().controller(Closer),
|| SizedBox::empty(),
));
AppLauncher::with_window(WindowDesc::new(main))
.delegate(Delegate)
.launch(None)
.unwrap();
}
const CLOSE: Selector = Selector::new("close");
struct Delegate;
impl AppDelegate<Option<String>> for Delegate {
fn command(&mut self, _ctx: &mut DelegateCtx, _target: Target, cmd: &Command, data: &mut Option<String>, _env: &Env) -> Handled {
if cmd.is(CLOSE) {
*data = None;
}
Handled::No
}
}The panic is a |
|
A bit late to the party, but what about a different foreground color for selected text? Light themes could really benefit from this, otherwise you have to use a pretty light selection background color. Also might want to draw the inactive style when the entire window loses focus. |
When #1636 lands, how druid handles text will change fundamentally, and there are almost certainly some issues that we will encounter as we start using the new implementation.
This issue is intended as a tracking/discussion issue for various problems with the new text work.
polish
There are a number of outstanding fixups I would like to land:
druid::textmodule, centralizing all text-related types hereInsetsin the envfeatures
Larger related projects it might be nice to do while we're in here
Actions.bugs
- [ ] IME composing region is drawn incorrectly sometimescan't reproduce- [ ] line height calculations are incorrect for some scripts (japanese)out of scope for this workThe text was updated successfully, but these errors were encountered: