These are chat archives for AvaloniaUI/Avalonia

5th
Jun 2017
danwalmsley
@danwalmsley
Jun 05 2017 14:22
@kekekeks @grokys if you get access violation exceptions with immediate crash and debugger exits, any idea how you would go about debugging that?
danwalmsley
@danwalmsley
Jun 05 2017 14:50
thanks @grokys
Nikita Tsukanov
@kekekeks
Jun 05 2017 16:26
@grokys Capturing mouse by direct call to MouseDevice was a bad idea
It should be done on ITopLevelImpl level
Steven Kirk
@grokys
Jun 05 2017 16:27
why is that?
Nikita Tsukanov
@kekekeks
Jun 05 2017 16:28
           UnmanagedMethods.SetCapture(CurrentWindow.Handle.Handle);
That's implementation from Win32 platform
With proper embedding to WPF
There is no CurrentWindow
Steven Kirk
@grokys
Jun 05 2017 16:29
ah ok.
Nikita Tsukanov
@kekekeks
Jun 05 2017 16:29
As I've already told, there is no guarantee that all toplevels will share the same windowing subsystem
Steven Kirk
@grokys
Jun 05 2017 16:29
well it shouldn't be difficult to change. it can be added to IInputRoot
yeah, this was all done way before embedding was even considered
Nikita Tsukanov
@kekekeks
Jun 05 2017 16:30
Same thing with with renderer factory, BTW
Renderer type should be decided in ITopLevelImpl
Steven Kirk
@grokys
Jun 05 2017 16:31
hmm, but then how would we enable the deferred renderer only for some backends as we currently do?
Nikita Tsukanov
@kekekeks
Jun 05 2017 16:31
different toplevels might support or not support deferred renderer even if they are implemented by the same windowing platform
Right now it's IWindowingPlatform that created renderer
Since it also our default toplevel factory
I don't see any issues with moving renderer creation to ITopLevelImpl
Steven Kirk
@grokys
Jun 05 2017 16:33
ok, that might make more sense then
Nikita Tsukanov
@kekekeks
Jun 05 2017 16:34
It looks like we are breaking compatibility with currently released version anyway
Let's merge #1010 then, I'll figure something about MonoMac backend distribution
Steven Kirk
@grokys
Jun 05 2017 16:36
ok. we can always release 0.6 early with the breaking changes if we want
Nikita Tsukanov
@kekekeks
Jun 05 2017 16:52
        public void InvalidateArrange()
        {
            if (IsArrangeValid)
            {
                Logger.Verbose(LogArea.Layout, this, "Invalidated arrange");

                IsArrangeValid = false;
                LayoutManager.Instance?.InvalidateArrange(this);
                InvalidateVisual();
            }
        }
InvalidateArrange for some reason does nothing
Nikita Tsukanov
@kekekeks
Jun 05 2017 16:58
Hm
Apparently, there is no proper way to integrate our controls to WPF's measure/arrange infrastructure
Since I can't hook InvalidateMeasure from toplevel
Nikita Tsukanov
@kekekeks
Jun 05 2017 17:04
For some reason DesiredSize for the view inside toplevel with {1100:700} size is {0,0}
After measure pass
I don't understand how layout system works
Nikita Tsukanov
@kekekeks
Jun 05 2017 17:15
Hm, my bad, got ITopLevelImpl.ClientSize implemented in a wrong way
Nikita Tsukanov
@kekekeks
Jun 05 2017 17:45
@grokys I've realized that I could create a separate mouse device instance
But
There is MouseDevice.Instance
Which might screw things up
Singletons and service locator are evil
sigh
Steven Kirk
@grokys
Jun 05 2017 17:47
yeah, well i never foresaw having to do any of this. how does WPF handle embedding when it only has singletons for everything?
Nikita Tsukanov
@kekekeks
Jun 05 2017 17:50
It doesn't
For winforms it creates a native window
Which doesn't really require all that stuff
Could we move IMouseDevice to IInputRoot?
Steven Kirk
@grokys
Jun 05 2017 17:52
Do you think it's time to just bite the bullet and make the top level a service locator?
Nikita Tsukanov
@kekekeks
Jun 05 2017 17:52
Ouch
It might be worth for 0.6, yes
Steven Kirk
@grokys
Jun 05 2017 17:57
when we do that we'll probably want to expose the devices as properties on the root interfaces too, so i think you can move the mouse device to IInputRoot anyway
Nikita Tsukanov
@kekekeks
Jun 05 2017 17:58
I'm not sure that IMouseDevice is a service
It should be returned by ITopLevelImpl, I think
Steven Kirk
@grokys
Jun 05 2017 18:00
thing is that sometimes you might want to get the mouse device without a window maybe?
Nikita Tsukanov
@kekekeks
Jun 05 2017 18:01
The thing is that with wayland
You can't
there is no global screen coordinates there
And wayland is the new display server for Linux
Steven Kirk
@grokys
Jun 05 2017 18:02
also thinking more about it, without a window for a message loop you won't be getting messages anyway
mouse input goes through the input manager which is tied to a window
Nikita Tsukanov
@kekekeks
Jun 05 2017 18:19
Mkay, how to get the input root?
I guess it's also the VisualRoot
But I'm not sure that casting value returned from GetVisualRoot is the right thing
Steven Kirk
@grokys
Jun 05 2017 18:22
at the moment casting the result returned by GetVisualRoot is the only way
the root is defined by the visual tree, so that's where getting the root is implemented
great, xamarin have broken the VS output window by spamming it with [Inspector] Error preparing project for inspection: System.NullReferenceException messages
Nikita Tsukanov
@kekekeks
Jun 05 2017 18:33
        public MouseDevice()
        {
            InputManager.Process
                .OfType<RawMouseEventArgs>()
                .Where(e => e.Device == this && !e.Handled)
                .Subscribe(ProcessRawEvent);
        }
I'm not sure what to do with that
Replace it with manual call from input manager, I guess
Nikita Tsukanov
@kekekeks
Jun 05 2017 21:25
@grokys I'm trying to move ILayoutManager to toplevel
But it seems that controls try to register themselves for layout pass before being attached to the visual tree
Steven Kirk
@grokys
Jun 05 2017 21:27
via InvalidateMeasure/InvalidateArrange?
yeah, i see it with TextBlock - it's because attaching to the logical tree invalidates the FormattedText (as that may affect inherited properties) and that invalidation calls InvalidateMeasure
Nikita Tsukanov
@kekekeks
Jun 05 2017 21:31
I'll add a call to layoutmanager from OnAttachedToVisualTree
if measure isn't valid
That should fix things, I guess
Steven Kirk
@grokys
Jun 05 2017 21:31
yep, that's what i was about to suggest
Nikita Tsukanov
@kekekeks
Jun 05 2017 21:41
Some item virtualization tests aren't passing now
Steven Kirk
@grokys
Jun 05 2017 21:42
if you commit to a branch i can take a look
Nikita Tsukanov
@kekekeks
Jun 05 2017 21:44
One is failing because TestScroller is a render root
hm
Steven Kirk
@grokys
Jun 05 2017 21:45
yes, the tests need their controls to be attached to a root, so the obvious way to do that was to make the test root a render root
Nikita Tsukanov
@kekekeks
Jun 05 2017 21:47
AvaloniaUI/Avalonia@4d7a129
Changing_VirtualizationMode_None_To_Simple_Should_Add_Correct_Number_Of_Controls
GetControlInDirection_Right_Should_Scroll_If_Partially_Visible
GetControlInDirection_Down_Should_Scroll_If_Partially_Visible
GetControlInDirection_Up_Should_Scroll_If_Partially_Visible_Item_Is_Currently_Shown
These 4 are failing
Steven Kirk
@grokys
Jun 05 2017 21:49
taking a look now
why do you need to be able to override LayoutManager for a toplevel?
Nikita Tsukanov
@kekekeks
Jun 05 2017 21:50
WPF integration
And embedding in general
I need to inform host UI toolkit about measure invalidation
And sync layout passes with it
Embedding is the most convenient way of moving to avalonia, so we need first class support for WPF integration
Nikita Tsukanov
@kekekeks
Jun 05 2017 21:56
BTW, layoutmanager-per-toplevel will allow us to be smarter during layout passes
skip visuals that have their parents in measure queue, for example
Steven Kirk
@grokys
Jun 05 2017 21:56
yeah, it's a good idea, was just wondering why you needed it now
Nikita Tsukanov
@kekekeks
Jun 05 2017 21:59
I have a project that needs to render tons of stuff. It was targeting WinXP, so we were stuck with WPF's renderer. Now we are finally moving to Win7 target, so I decided that it would be easier to move render-heavy parts to avalonia and use embedding
Since Avalonia have proven to be way faster than WPF with Direct2D backend
Steven Kirk
@grokys
Jun 05 2017 21:59
oh really?
Nikita Tsukanov
@kekekeks
Jun 05 2017 22:00
It looks like a better solution than reimplementing render code entirely
Steven Kirk
@grokys
Jun 05 2017 22:02
i've not seen that video before! is that using the immediate renderer? i wonder how it looks with the deferred renderer
Nikita Tsukanov
@kekekeks
Jun 05 2017 22:03
It's published in February, so I guess it uses immediate one
asgardaesir
@asgardaesir
Jun 05 2017 22:12
Hey guys, is it possible to raise key input events on a listbox control and select and scroll to the item that starts with the character entered with Avalonia? Does that functionality already exist?
Nikita Tsukanov
@kekekeks
Jun 05 2017 22:14
ScrollIntoView
PreviewKeyDown
Same as in WPF, actually
asgardaesir
@asgardaesir
Jun 05 2017 22:14
Ah cool
Nikita Tsukanov
@kekekeks
Jun 05 2017 22:21
@grokys so, any idea why virtualization tests are failing?
Steven Kirk
@grokys
Jun 05 2017 22:21
trying to work it out now
What should it use if there were no previous measure?
I've set Size(0, 0) as default and controlcatalog seems to be working
Steven Kirk
@grokys
Jun 05 2017 22:34
the idea is that the initial layout pass or the parent measure should set the PreviousMeasure
i think the problem is that the logic has changed which means controls get added to the remeasure/rearrange lists out of order
the layout manager will need to be changed to ensure it measures/arranges in the order of distance from root
Nikita Tsukanov
@kekekeks
Jun 05 2017 22:38
Why does it only affect virtualizer?
Do we have distance-from-root metric built-in?
It could be also maintained by OnAttachedToVisualTree
Nikita Tsukanov
@kekekeks
Jun 05 2017 22:47
Wait
@grokys _toMeasure and _toArrange are hashsets
They don't preserve order at all
So it doesn't matter if addition order have changed
Steven Kirk
@grokys
Jun 05 2017 22:48
oh yeah...
i need to investigate further then, it definitely looks like the virtual panel is getting measured before the items and that's causing the problem
Nikita Tsukanov
@kekekeks
Jun 05 2017 22:50
I thought that parent is expected to call measure on its children
Steven Kirk
@grokys
Jun 05 2017 22:50
it is yeah
i'm going to have to step through the before and after side by side i think
Nikita Tsukanov
@kekekeks
Jun 05 2017 22:53
@grokys try to start controlcatalog
For some reason TabStripItem's VisualParent is null during initial layout pass
I also don't quite understand why LayoutManager calls measure on control's parent
instead of control itself
Steven Kirk
@grokys
Jun 05 2017 22:57
yeah, it's all a vague memory to me at this point. but it seems that this is how the layout manager ensures that controls higher up in the visual tree are measured first
tbh, it all looks like a big hack to me right now
Nikita Tsukanov
@kekekeks
Jun 05 2017 22:57
BTW, does it even make sense to measure parentless controls from layoutmanager?
Steven Kirk
@grokys
Jun 05 2017 22:57
nope
this layout stuff needs a rewrite
Nikita Tsukanov
@kekekeks
Jun 05 2017 22:58
So layoutmanager needs to sort items in proper order before each pass
also it should ignore orphaned controls
Steven Kirk
@grokys
Jun 05 2017 22:59
yeah i think so - i'm going to try doing a quick rewrite i think
there's only 1 unit test ffs
bad grokys
to be fair this is some of the earliest code in there
Steven Kirk
@grokys
Jun 05 2017 23:05
actually it's not even that old - i rewrote it last january. i don't even have an excuse.
Nikita Tsukanov
@kekekeks
Jun 05 2017 23:25
What if we just call Measure on toplevel itself?
I wonder if it's the only valid thing to do, actually
Steven Kirk
@grokys
Jun 05 2017 23:27
if you can work around it by doing that for the moment, then sure
i'm too tired to work out what's happening here at the moment, sorry
i'll take another look tomorrow
Nikita Tsukanov
@kekekeks
Jun 05 2017 23:29
I'm trying to figure out what layout manager should do
i. e. how to propagate measure changes in the tree
Steven Kirk
@grokys
Jun 05 2017 23:31
in theory it's quite simple - it should measure/arrange the controls that have invalidated their measure/arrange, if the desired size changes the Layoutable.Measure then invalidates the parent measure
part of the problem is that a layout on e.g. a scrollviewer can cause scrollbars to be shown which changes the available size, which triggers a remeasure, which can cause scrollbars to be hidden etc
anyway, i need to go to bed, sorry :(