These are chat archives for AvaloniaUI/Avalonia

26th
Sep 2017
Matthijs ter Woord
@mterwoord
Sep 26 2017 06:02
@jkoritzinsky For cosmos, we're also looking for forum engine, and we're looking for something that does email interface (and bonus points for nntp, but that's rare) as well
Matthijs ter Woord
@mterwoord
Sep 26 2017 07:16
i just asked who was doing that. Maybe we could keep each other informed?
Nikita Tsukanov
@kekekeks
Sep 26 2017 07:17
NNTP? Is fido still alive?
or was it some another network
I'm not a specialist in archeology
Matthijs ter Woord
@mterwoord
Sep 26 2017 07:19
well, we do want mail proxy (just not "hey, you've got a new message, click here") but similar to gihtub issues, where you can just rpely etc
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 11:18
Anyone knows why this error occurs and if it is my fault? https://ci.appveyor.com/project/AvaloniaUI/Avalonia/build/0.1.3898#L1593
Matthijs ter Woord
@mterwoord
Sep 26 2017 11:22
missing refernece?
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 11:31
Yeah
Haven't even touched that file
Or anything that could break that reference
Nikita Tsukanov
@kekekeks
Sep 26 2017 11:33
Avalonia.Diagnostics -> C:\projects\Avalonia\src\Avalonia.Diagnostics\bin\Release\netstandard2.0\Avalonia.Diagnostics.dll
Embedding\WinFormsAvaloniaControlHost.cs(34,25): error CS0234: The type or namespace name 'Controls' does not exist in the namespace 'Avalonia.Win32.Avalonia' (are you missing an assembly reference?) [C:\projects\Avalonia\src\Windows\Avalonia.Win32\Avalonia.Win32.csproj]
Avalonia.Win32.Avalonia
that's a really bad namespace to have
I'm not quite sure that platform-specific APIs should live in toplevels
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 11:35
@kekekeks I haven't touched that
Nikita Tsukanov
@kekekeks
Sep 26 2017 11:35
In case of the Dock icon you might want to hide it before creating any windows
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 11:35
Yeah not sure where to put it
Nikita Tsukanov
@kekekeks
Sep 26 2017 11:36
@grokys any idea where we should put platform-specific APIs?
In case of Dock
Nikita Tsukanov
@kekekeks
Sep 26 2017 11:41
We could add a property to Application class (something like ShowInOSXDock
and subscribe to it from MonoMac platform
and call it a day
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 11:43
Or solve it properly
There are more things that shouldn't be in TopLevel or WindowBase
Like status icons
for example
Matthijs ter Woord
@mterwoord
Sep 26 2017 11:44
status ioncs?
MonkAlex
@MonkAlex
Sep 26 2017 11:44
Taskbar, maybe?
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 11:46
Tray icon
Nikita Tsukanov
@kekekeks
Sep 26 2017 11:46

Or solve it properly

I'm not sure that we need all that infrastructure for just one property

Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 11:46
It's called status icon in gtk
Matthijs ter Woord
@mterwoord
Sep 26 2017 11:46
@kekekeks I do think there are more situations
like the progress/taskbarinfo on windows..
does that exist on more platforms?
Nikita Tsukanov
@kekekeks
Sep 26 2017 11:46
Yeah, but we don't support them yet and don't see the whole picture anyway
Matthijs ter Woord
@mterwoord
Sep 26 2017 11:47
not the point i'm making: i think there's more stuff that individual platforms might have but not others
Nikita Tsukanov
@kekekeks
Sep 26 2017 11:47
So we can't design the proper architecture right now anyway
Matthijs ter Woord
@mterwoord
Sep 26 2017 11:47
in that case i would say it shouldn't be on be classes/infra/toplevel
Nikita Tsukanov
@kekekeks
Sep 26 2017 11:48
status icon will be a different class
not a toplevel
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 11:49
But how do you access that class?
Nikita Tsukanov
@kekekeks
Sep 26 2017 11:49
Using new operator, I guess
Which will introduce a new method in IWindowingPlatform
StatusIcon is something completely independent from windows or popups
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 11:50
So is the dock icon
So are other things
Nikita Tsukanov
@kekekeks
Sep 26 2017 11:51
That's why I suggest to add a property to Application class for now
We don't have any API stability guarantees yet anyway
Especially in platform-specific area
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 11:52
For now turns into for ever
Nikita Tsukanov
@kekekeks
Sep 26 2017 11:53
That's not entirely true, we are rewriting "works good for now" stuff from time to time
Rendering subsystem had at least 2 major overhauls already
The problem with platform-specific API is that we'll have to rewrite it anyway
Since we won't be able to design a good API when we only think about one property
Matthijs ter Woord
@mterwoord
Sep 26 2017 11:55
@kekekeks rewriting is doable for internals, but at some point the public api will have users and ewven when you guys tell everybody no api garrantees, there will be a point where you say "well, changing this api doesn't pay off, becuase we have to spend lots of time on fixing it in my app"
Nikita Tsukanov
@kekekeks
Sep 26 2017 11:55
Point about having to redesign it anyway still stands
We currently don't see the whole picture
To be honest, for hiding dock icond I'd suggest to use MonoMac directly
And keep that feature not implemented in our codebase for now
We need to do a research first
Platform specific features that come to mind:
  • global menus (and in case of OSX it's split into application-wide and window-local)
  • statusicon menus (we can't just show our own popup in case of OSX and libappindicator on Linux)
  • progress in taskbar (on Ubuntu it's app-global, on Win32 it's window-specific)
  • desktop notifications (I'm sure we could figure something xplat there, but we still need to investigate)
Nikita Tsukanov
@kekekeks
Sep 26 2017 12:02
And the thing about using MonoMac directly is that it will always work and that API won't change
Or ship it in some external library to make it clear that this particular api is most likely to change. That will also allow to provide compatibility shim later
Nikita Tsukanov
@kekekeks
Sep 26 2017 12:11
Another option is to keep platform-specific stuff in backend assemblies and figure out an xplat-API later
That won't introduce compatibility issues
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 13:47
Hm
How is the text in buttons rendered compared to normal text?
As the text in buttons does not appear to bug out when changing colours, or at least not all buttons
Steven Kirk
@grokys
Sep 26 2017 14:11
yeah, not sure about plat-specific APIs. my original intention was that e.g. plat-specific window APIs would be found on the PlatformImpl, e.g. ((Win32.WindowImpl)window.PlatformImpl).TaskBarProgress.Value = 0.5
but I think @kekekeks didn't like that idea if i remember rightly
@JurjenBiewenga text in buttons is just rendered using TextBlocks
but anyway, I agree with @kekekeks when he says we probably shouldn't over-design the platform specific stuff right now because we'll probably just get it wrong!
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 14:19
@danwalmsley Could you try pr #1162 with your issue(#1092) as I can not get that xaml working
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 15:21
@grokys It's better than just throwing stuff in Application and then we at least have a place to put plat-specific functions that fit no where else
Nikita Tsukanov
@kekekeks
Sep 26 2017 15:24
I'd settle with Avalonia.MonoMac.MonoMacPlatform.ShowInDock static property for now
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 16:41
@kekekeks About the checking whether the alpha is 255 or not
I tried that
However it doesn't appear to change if the surface it is on has a different alpha
Steven Kirk
@grokys
Sep 26 2017 16:51
right yeah, there are 2 things here: global settings and window-specific settings
for global settings Avalonia.MonoMac.MonoMacPlatform.ShowInDock would make sense to me
but as @kekekeks says we'll probably get a better idea of where to put this stuff as we get more plat-specific settings
Nikita Tsukanov
@kekekeks
Sep 26 2017 17:13

if the surface it is on has a different alpha

Skia doesn't have a concept of opacity stack, so if current Paint has A = 255, it's being rendered to the target without opacity

With DeferredRenderer, however, the target might be a Layer, which might get blended with opacity later
So we need to somehow detect layer properties
@grokys any idea how we should organize that? Another concern is RenderTargetBitmap
Steven Kirk
@grokys
Sep 26 2017 17:16
yeah, i'm really not sure. i think D2D creates a new layer each time you push an opacity
(a D2D layer, which is separate from a deferred renderer layer)
Nikita Tsukanov
@kekekeks
Sep 26 2017 17:17
How does it render text then?
We don't see the artifacts with D2D backend
Steven Kirk
@grokys
Sep 26 2017 17:19
not sure what you mean - here's how d2d layers work https://msdn.microsoft.com/en-us/library/windows/desktop/dd756654(v=vs.85).aspx
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 17:19
Is the DeferredRenderer default?
Steven Kirk
@grokys
Sep 26 2017 17:19
deferred renderer is currently default for win32
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 17:19
Can I disable that?
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 17:24
Even with it disabled the paint color remains 255
Nikita Tsukanov
@kekekeks
Sep 26 2017 17:26
Are you checking paint or _paint
That code was ported from C++, so it's a bit messy
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 17:27
Paint
Which is a _paint clone
The opacity actually does change for the disabled buttons in the button page
But not during a transition
Nikita Tsukanov
@kekekeks
Sep 26 2017 17:28
You need to check the color after ApplyWrapperTo call
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 17:28
I am
Nikita Tsukanov
@kekekeks
Sep 26 2017 17:30
Could you check with debugger that foreground has A != 255?
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 17:32
Nop
Nikita Tsukanov
@kekekeks
Sep 26 2017 17:32
During the text drawing call happens the following
1) DrawingContextImpl cretes a new SkPaint object with proper Shader and Color and applies _currentOpacity (lines 160 and 163 here: https://github.com/JurjenBiewenga/Avalonia/blob/9e2bb106b48a9957c549a612a8c47e02746451a2/src/Skia/Avalonia.Skia/DrawingContextImpl.cs)
2) that SKPaint is then getting wrapped to a struct
3) Stuct is passed to FormattedTextImpl
Which clones it's own SkPaint that contains text rendering options
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 17:33
Feel free to try it yourself, it's not breaking for me
Nikita Tsukanov
@kekekeks
Sep 26 2017 17:33
and then copies Color and Shader from SkPaint obtained from the DrawingContextImpl
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 17:33
Except on the buttons page that has disabled buttons
That page looks OK to me
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 17:35
Breaking as in hitting a breakpoint
Not breaking as in not working
Nikita Tsukanov
@kekekeks
Sep 26 2017 17:36
Yeah, we don't have opacity anywhere else, I think
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 17:36
During the transition?
Nikita Tsukanov
@kekekeks
Sep 26 2017 17:36
Hm...
Let me try
Breakpoint with paint.Color.Alpha != 255 is getting triggered for me during transition
At least on Linux
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 17:38
Weird
Nikita Tsukanov
@kekekeks
Sep 26 2017 17:38
Need to wait several minutes to check on win32: solution loading time in VS is huge
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 17:39
Rider is better for me
Appears it's pretty laggy for me with a debugger attached
So it might just go from 255 to gone
added paint.LcdRenderText = paint.Color.Alpha == 255;
Seems to work fine
Nikita Tsukanov
@kekekeks
Sep 26 2017 17:40
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 17:40
Must've typo'd something last time then
Nikita Tsukanov
@kekekeks
Sep 26 2017 17:41
That's how I was debugging opacity not being applied to text at all last time
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 17:41
With deferred rendering it is broken though
Which I had on last time
Nikita Tsukanov
@kekekeks
Sep 26 2017 17:43
Deferred renderer uses layers for blending
That might be the issue here
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 17:44
Most likely yeah
I guess I can't get the alpha of the layer?
Nikita Tsukanov
@kekekeks
Sep 26 2017 17:44
We need to somehow detect that we are currently rendering to a blendable surface
@grokys
I guess we could check if we are rendering to RenderTargetBitmap on Skia
Since subpixel rendering is definetely not appliable when texture will get reused somewhere else
Steven Kirk
@grokys
Sep 26 2017 17:46
What do you mean by blendable surface?
Nikita Tsukanov
@kekekeks
Sep 26 2017 17:47
Something that can be rendered with opacity later
@JurjenBiewenga I'd suggest to add bool useSubPixelRendering to the Draw method, add SupportsSubPixelRendering property to DrawingContextImpl and set it tofalse for in BitmapImpl.BitmapDrawingContext's constructor
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 17:50
Shouldn't be named useLCDRendering?
As that is what we're disabling/enabling
Rather than subpixel rendering?
Nikita Tsukanov
@kekekeks
Sep 26 2017 17:52
Yep, something like that
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 17:52
Still broken
Nikita Tsukanov
@kekekeks
Sep 26 2017 17:53
Let me try to reproduce

That happen with

            AppBuilder.Configure<App>()
                .UsePlatformDetect().UseSkia()
                .Start<MainWindow>();

, right?

Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 17:54
I'm running dotnet core
Which uses skia by default
Nikita Tsukanov
@kekekeks
Sep 26 2017 17:57
Yep, can see it now
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 17:58
Back in a bit
Nikita Tsukanov
@kekekeks
Sep 26 2017 18:03
Mkay, I think, I've got it fixed
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 18:13
Sweet, what did you do?
Nikita Tsukanov
@kekekeks
Sep 26 2017 18:15
AvaloniaUI/Avalonia@ead7b3b
We need an overhaul for that code
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 18:16
That worked for you?
Nikita Tsukanov
@kekekeks
Sep 26 2017 18:16
yep
This code tries to replicate behavior from C++ code that was relying on copying constructor
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 18:19
JurjenBiewenga/Avalonia@dfa8d57
That's my code
Oh
I'm retarded
Nikita Tsukanov
@kekekeks
Sep 26 2017 18:20
lol
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 18:20
Yep
Forgot to remove paint.LcdRenderText = paint.Color.Alpha == 255;
Nikita Tsukanov
@kekekeks
Sep 26 2017 18:23
BTW, LcdRenderText works fine with actual opacity, it's just blending layers with text that's broken
So there were no need for paint.Color.Alpha == 255 check
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 20:06
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 20:12
SVG paths work now
Not perfectly yet apparently
Nikita Tsukanov
@kekekeks
Sep 26 2017 20:14
:+1:
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 20:17
Not quite sure what the is sue is yet though
Probably something in the mirror of the previous control point
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 20:45
Nikita Tsukanov
@kekekeks
Sep 26 2017 20:48
I guess we need some render tests for parsed paths
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 21:00
Yeah probably
Not quite sure how those work
Also a page for control catalog
Nikita Tsukanov
@kekekeks
Sep 26 2017 21:11
I think it's better to reuse one with Canvas
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 21:13
For the tests?
Nikita Tsukanov
@kekekeks
Sep 26 2017 21:15
catalog page
Jurjen Biewenga
@JurjenBiewenga
Sep 26 2017 22:08
Is there an easy way to run one test?
Nikita Tsukanov
@kekekeks
Sep 26 2017 22:13
That would be from Test Explorer tool window, I guess
Jeremy Koritzinsky
@jkoritzinsky
Sep 26 2017 23:13
We can add some parameters to the build/test scripts to make it easier to do from the command line