These are chat archives for AvaloniaUI/Avalonia

5th
Nov 2018
Benedikt Schroeder
@Gillibald
Nov 05 2018 15:07
Does anyone know where the cursor is set for the TextBox when you mouse over some text? Currently this doesn't seem to work properly when you set TextAlignment to Center or Right.
To get the right coordinates we have to call HitTestTextPosition(0) and HitTestTextPosition(-1) or HitTestTextPosition(Text.Length - 1)
Btw does anyone know why HitTestTextPosition(-1) should return the last position in the text layout instead of the first?
Benedikt Schroeder
@Gillibald
Nov 05 2018 15:12
It would make much more sense if HitTestTextPosition(-1) was returning the top left corner and the size of the whole text but maybe thats just some definition how the directwrite textlayout works.
Nikita Tsukanov
@kekekeks
Nov 05 2018 17:15
@/all this will be a huge breaking change (OnTextInput event removal) so I'd like to hear your thoughts on AvaloniaUI/Avalonia#2076
Steven Kirk
@grokys
Nov 05 2018 17:42
@kekekeks can't say i understand the details 100% but just wanted to ask: does UWP handle this in some way?
Nikita Tsukanov
@kekekeks
Nov 05 2018 17:49
I don't see "generic" events for that in UWP
TextBox has some text-specific ones
TextCompositionStarted, TextCompositionChanged, TextCompositionEnded
They don't exist on a Control
Only on TextBox
I want people to be able to implement custom text input views
So I propose a mechanism for selecting a handler for text input system interaction
Steven Kirk
@grokys
Nov 05 2018 17:53
ok, so they've effectively special-cased TextBox? ugh
Nikita Tsukanov
@kekekeks
Nov 05 2018 17:53
I think we can provide backwards compatibility with OnTextInput event using reflection
And custom implementation of add/remove
on TextInput event
Tunneling/bubbling won't work obviously
Steven Kirk
@grokys
Nov 05 2018 17:54
ok, i need to carve out some time to look at the PR
Reflection-based compatibility layer will be enough for AvaloniaEdit, I think
PR isn't done yet, I've just written my thoughts about text input system design
Nikita Tsukanov
@kekekeks
Nov 05 2018 18:01
IME isn't really compatible with AccessText, BTW
Jeremy Koritzinsky
@jkoritzinsky
Nov 05 2018 18:10
@Gillibald you know we can't take anything from WPF.
Steven Kirk
@grokys
Nov 05 2018 18:18
oh yeah sorry, missed that it was an issue not a PR, d'oh
Benedikt Schroeder
@Gillibald
Nov 05 2018 18:26
I wonder why you think I would want to use that. Just wanted to let you know what service is used under wpf.
This shouldn't hurt anyone
Nikita Tsukanov
@kekekeks
Nov 05 2018 19:04
It's not yet integrated with any backend, but GTK will be the first candidate
Jeremy Koritzinsky
@jkoritzinsky
Nov 05 2018 19:35
We really just shouldn't be looking at WPF source if we can avoid it.
Steven Kirk
@grokys
Nov 05 2018 19:58
@Gillibald are there any public docs regarding how WPF handles it?
@kekekeks are you familiar with the WPF way of doing it? any idea what the pros/cons are?
rather than rush into a solution i think it'd be a good idea to look around at how it's done elsewhere
ahopper
@ahopper
Nov 05 2018 20:19
how would this work with capturing command keys higher up the visual tree when a textbox has focus (like f5 in a ide)?
Nikita Tsukanov
@kekekeks
Nov 05 2018 20:27
Input method won't handle most of the keys
Like F5
And will pass them back
It's just that we shouldn't handle events that are handled by the input method
And that's it
I have no idea what these properties mean
But we can't implement NSTextInputClient using events
See docs here
It requires us to implement several property getters
That require information from the internal state of the TextBox
So we can't use whatever UWP/WPF uses
Because it won't work on OSX
Steven Kirk
@grokys
Nov 05 2018 20:58
and that is hardcoded to textbox for UWP/WPF is i think what you're saying
i don't really feel like i know enough about this stuff to comment really
is there anyone else here who does?
Steven Kirk
@grokys
Nov 05 2018 21:21
I'm not against what you're proposing btw
Benedikt Schroeder
@Gillibald
Nov 05 2018 21:40
This solution should not intercept key events from a real keyboard so key press events should still work and that's how I would takle this. Having a service for text input enables more input variants like ink to text etc.
Wiesław Šoltés
@wieslawsoltes
Nov 05 2018 21:42
Submitted dark theme PR AvaloniaUI/Avalonia#2078
Andrey Kunchev
@donandren
Nov 05 2018 21:52
@wieslawsoltes nice great job
AvaloniaUI/AvaloniaVS#76 made visual studio extension somewhat usable again, if any body want to review/merge
Steven Kirk
@grokys
Nov 05 2018 22:00
Oh excellent @donandren ! Will take a look!
Andrey Kunchev
@donandren
Nov 05 2018 22:06
now if visual studio is updated to 15.8 there is no completion for avalonia xaml at all FYI, not related to avalonia 0.7 release, but to visual studio internal changes
Steven Kirk
@grokys
Nov 05 2018 22:07
yeah i just saw the issue you linked to in the code
@donandren do you think you could describe the changes you made in the PR description or in PR comments?
just to help me understand why some of the changes were needed
as there seem to be fixes for various different things
Andrey Kunchev
@donandren
Nov 05 2018 22:13
i added everything in the pr description and every commit has comment, i have 0 experience in writing vs extensions and not sure what's needed what not, but what's this pr it's working better than ever. 95% of the changes are packge.config -> PackageReference. will review quickly and add comment when i can now
Steven Kirk
@grokys
Nov 05 2018 22:18
thanks! it was things like ImplementPropertyChanged -> AddINotifyPropertyChangedInterface and the addition of ProjectProperties i wasn't sure about
Steven Kirk
@grokys
Nov 05 2018 22:25

This solution should not intercept key events from a real keyboard so key press events should still work and that's how I would takle this. Having a service for text input enables more input variants like ink to text etc.

@Gillibald could you explain this a little more? are you saying that @kekekeks solution seems better than WPF/UWPs?

Benedikt Schroeder
@Gillibald
Nov 05 2018 23:18
I don't think we need to change / remove the text input event. TextInputEvent should be handled if you want some input from a physical keyboard you can call that raw data and it is totally fine and sometimes needed to have that. If that event is fired you can be sure it comes from the keyboard. On top of that we should introduce some text service a control like TextBox can subscribe / listen to that handles more advanced input that can come from various sources not only limited to keyboard. If that service isn't present / needed you can always use the TextInputEvent. But I could be totally mistaken and missing something here.
Benedikt Schroeder
@Gillibald
Nov 05 2018 23:23
Not sure about the insides of WPF but it looked like they have a similar approach where a TextBox(TextEditor) is attached to that service if one is present on the system.