These are chat archives for AvaloniaUI/Avalonia

26th
Oct 2017
danwalmsley
@danwalmsley
Oct 26 2017 10:45
@grokys thanks man, should be able to test it shortly
Nikita Tsukanov
@kekekeks
Oct 26 2017 15:11
Mkay, I've spent several hours reading about the wayland protocol and libwayland-client
Good news: it's really friendly for language-bindings
Bad news: we need to actually generate those bindings for C#, the library is pretty much useless without them
Other good news: stuff that we need is currently considered to be "unstable" and lives in https://github.com/wayland-project/wayland-protocols/tree/master/unstable
So it will be a year or so before we can actually start writing a client
Nikita Tsukanov
@kekekeks
Oct 26 2017 15:19
There still would be limitations that we should reflect in our API
For example, popups must have a window and can be only shown as a reaction to a user event
@grokys
Jeremy Koritzinsky
@jkoritzinsky
Oct 26 2017 15:27
Once I get v1of SharpGenTools our I'm planning on adding support for making mappings for Linux based apis. So we could use that to generate the bindings
Nikita Tsukanov
@kekekeks
Oct 26 2017 15:28
@jkoritzinsky they are using custom marshaling
There is wl_proxy_marshal function that accepts a list of something like OLE Variant
struct wl_proxy * wl_proxy_marshal_array_constructor(struct wl_proxy *proxy, uint32_t opcode, union wl_argument *args, const struct wl_interface *interface)
And the actual client code should be generated from XML protocol definitions
Functions like wl_compositor_create_surface are declared as inline macro
in C library code
Another problem is protocols that are defined outside of the main wayland repo
the only thing we could rely on is those xml definitions
libwayland-client is basically a marshaller implementation
Steven Kirk
@grokys
Oct 26 2017 15:34
wow, rather you than me ;)
Nikita Tsukanov
@kekekeks
Oct 26 2017 15:34
That system isn't a big problem, it's just something that will take some time to create bindings for
The actual problem is the limitations of wayland itself
And xdg-shell protocol in particular
It's in human-readable format
And defines things that can be done with windows and popups
Steven Kirk
@grokys
Oct 26 2017 15:35
ok
Nikita Tsukanov
@kekekeks
Oct 26 2017 15:36
Ooops, outdated link
This seems to be the latest version
It seems to be the way of positioning popups
Basically popups can be only shown relative to some rect on the parent window
That conforms to PlacementTarget in WPF
But doesn't allow arbitrary popup positioning
Nikita Tsukanov
@kekekeks
Oct 26 2017 15:47
Lol
@grokys "Each toplevel has in its own root coordinate system"
I was right when I was suggesting to move everything to TopLevel level
Steven Kirk
@grokys
Oct 26 2017 15:49
popups can be only shown as a reaction to a user event
is that enforced by the API or is it advice?
Nikita Tsukanov
@kekekeks
Oct 26 2017 15:50
It's enforced, I think
Steven Kirk
@grokys
Oct 26 2017 15:50
so you can't make e.g. tooltips that popup after a delay?!
Nikita Tsukanov
@kekekeks
Oct 26 2017 15:50
You can
It's needed to provide a serial number of the event
That triggered the popup
The protocol itself is completely async
For move and resize-drag requests it uses the type of the event to decide the method of window move or resize
e. g. for touch events it can use something different
We can probably hide that from the user
By saving the last input event
At least that's what GTK does with gdk_window_begin_move_drag
But I'm not sure if that's the best solution
Steven Kirk
@grokys
Oct 26 2017 15:54
ok, if that's what GTK does then that sounds ok. i was wondering how GTK etc handled that
Nikita Tsukanov
@kekekeks
Oct 26 2017 15:56
The thing that has to be changed
is that popups should always have a parent
And a placement rect on the said parent
So popup positioning needs to be moved to platform implementation level
We can share that code across implementations for "normal" platforms
Steven Kirk
@grokys
Oct 26 2017 15:58
ok
Nikita Tsukanov
@kekekeks
Oct 26 2017 15:58
BTW
Windows can't be moved
on wayland
for some weird reason
I mean, moved by our code
Nikita Tsukanov
@kekekeks
Oct 26 2017 16:04
GTK and Qt seems to have move as a no-op
Ouch...
Explicit window size changes also seems to be not supported
I guess we can set min/max size constraints for popups
Steven Kirk
@grokys
Oct 26 2017 16:14
sounds like wayland isn't going to be easy...
Nikita Tsukanov
@kekekeks
Oct 26 2017 16:14
It's a good API in terms of renderting stuff to
But window manipulation, clipboard access, etc
are reinvented
and not in a good way
May be we actually can resize the wl_surface
But I'm not sure, need to do some experiments
But we need to make changes to popups and placement targets for GTK backend
They'll be broken otherwise
even with XWayland compatibility layer
I'll do some experiments with libwayland next year
But GTK backend needs to be fixed before our Beta release
Since Wayland is being used by default on Ubuntu 17.10
Jeremy Koritzinsky
@jkoritzinsky
Oct 26 2017 16:40
@kekekeks couldn't we generate the client from files like this: https://github.com/wayland-project/wayland/blob/master/src/wayland-client.h
It's in the wayland repo next to the XML files
That plus some manually written C# would work with SharpGen
Jeremy Koritzinsky
@jkoritzinsky
Oct 26 2017 16:47
Though the varargs of the marshalling functions does pose a bit of a problem...
Nikita Tsukanov
@kekekeks
Oct 26 2017 17:35
Documentation explicitly states that anything related to protocol is not the part of the ABI
BTW
Please don't use dllimport in your generator
Or at least allow to optionally use the way of library loading that we are currently using in our GTK3 backend
This is the list of symbols exported from libwayland-client.so.0
As you can see it's only display connection and RPC call marshaller
Actually, *_interface symbols aren't functions but variables
So we need a custom codegen infrastructure, unfortunately
Nikita Tsukanov
@kekekeks
Oct 26 2017 17:45
Well, at least rendering itself will be easy
No restrictions on threading whatsoever
Jeremy Koritzinsky
@jkoritzinsky
Oct 26 2017 17:50
I'll look at re-adding that feature for post v1. It was in SharpGen but unused so I had a feeling it may have been broken, so I removed that feature for the v1 release since SharpDX doesn't use it.
I've still got a lot of refactoring to do on SharpGen before I do the v1 release.
Nikita Tsukanov
@kekekeks
Oct 26 2017 17:54
Jeremy Koritzinsky
@jkoritzinsky
Oct 26 2017 17:56
It might freak out on the varargs. I'm not sure about those. Everything else should work.
I've had to build the test suite up from nothing so I don't have lots of tests for non-COM-based libraries
Nikita Tsukanov
@kekekeks
Oct 26 2017 17:57
We can ignore varargs
there are overloads that accept arrays
Jeremy Koritzinsky
@jkoritzinsky
Oct 26 2017 17:57
That would work much better
Nikita Tsukanov
@kekekeks
Oct 26 2017 18:03
Their shared memory model is meh
It's memory-mapped file backed
Nikita Tsukanov
@kekekeks
Oct 26 2017 18:15
Mkay, now I don't get it. According to examples here it's possible to have a custom window size
Just wow
That makes our screen information support quite useless
Nikita Tsukanov
@kekekeks
Oct 26 2017 18:37
I wonder how docking can even work
Since it requires to create temporary windows for tool panels