This is an org.qemu.Listener using the gdbus-codegen generated skeleton as
the parent type.
What will probably happen here, is that we create a MksPaintable which is
given to the listener to call internal API upon.
The paintable code will be a bit more complex than originally anticipated
in that we are going to need to do our own tessellation so that we get
damage regions which are not the whole widget. Very similar to what I did
in the GdkMacosTile for gdk/macos/.
MksScreenAttributes is an opaque type with setters so that we can
potentially extend it in the future without ABI issues.
Furthermore, this adds a configure API for both sync and async to
MksScreen.
Currently, I get NOT_SUPPORTED back from Qemu, but I think that's because
I'm not even past the bootloader/EFI stage for tests.
We want to use the vfunc of the class to implement devices coming from a
Qemu object on D-Bus, but we don't want to expose that in public API.
Instead, we can keep the object instance and class internal but still
expose the subclasses as public API. We have to do old-style class
definitions to do that, but worth the ability to keep public API limited
so that we can make changes later.
This uses the object manager object instead of the proxy directly to
create the MksScreen instances.
We might want to move the object initialization to MksDevice since it
is likely to be copied across a number of device types.
This changes things to use the object manager to discover the VM instance.
We'll have to add support for other wrappers to use object managers so that
they can be added to the devices list as they are seen.
Adds MksKeyboard and MksMouse types. Setup a MksScreenKind for the
MksScreen based on MksQemuConsole:type property. Currently the keyboard
and mouse are not wired up, but here for scoping out the properties.
This library doesn't do much yet. It contains the scaffolding and the
rough shape of what I think the API should be in mks-types.h. Some of the
types have some skeleton implementation as well to hid the D-Bus API
behind those types.
The next steps are to fill out the other wrapper objects and see what
properties we should expose from the underlying D-Bus proxies.
Along with that, will be a GtkWidget which can have a number of properties
set on it to specify the MksScreen, MksKeyboard, and MksMouse devices. It
may make sense to attach the session + screen to the widget, so that it can
adapt to keyboard and mouse changes though.
