Re: [Vala] Issues will vala and pulse vapi
- From: Aaron Paden <aaronbpaden gmail com>
- To: Al Thomas <astavale yahoo co uk>
- Cc: "vala-list gnome org" <vala-list gnome org>, "pulseaudio-discuss lists freedesktop org" <pulseaudio-discuss lists freedesktop org>
- Subject: Re: [Vala] Issues will vala and pulse vapi
- Date: Sat, 21 Nov 2015 20:48:16 -0600
On Sat, Nov 21, 2015 at 6:33 AM, Al Thomas <astavale yahoo co uk> wrote:
This looks complex so I can only give a few pointers.
Does the code actually compile or are you getting an error about an
unresolved symbol?
Right, the code compiles, but the linker fails because of the
unresolved symbols. I didn't think of this before, but the minimal
example is pretty simple:
void main() {
PulseAudio.SourceInfo info;
}
You can solve this by declaring info unowned. Clearly the issue is
that vala is managing SourceInfo when it shouldn't be managed, but I
wasn't sure how to actually fix this given how the API is actually
used. Ideally, the vapi itself should indicate that the struct is
unmanaged, but I'm not sure how to do that as of yet.
From an object oriented design point of view your SinkSoureList
class is doing too much. Initialisation should be done elsewhere
and I think it is unusual to have GLib.MainLoop within a class.
Some refactoring would be helpful here to see the problem more
Well I've taken a few classes but I'm definitely at the level of a
hobbyist, so I have lots of gaps in my understanding of best
practices. SinkSourceList's purpose is simply to hold a list of pulse
sources/sinks regardless of what the rest of the application is or
isn't doing. It allows you to pass a MainContext to the constructor,
an only creates a MainLoop if MainContext is null. For example, you
might use SinkSourceList to write a one off utility like pactl list
short sources. In that case, the application logic really doesn't need
a mainloop, and the mainloop becomes an implementation detail of pulse
that can be abstracted away.
That was my reasoning, anyway. Could be completely faulty, and I'd
love to be corrected if I've obviously doing something incorrect.
Your callback that adds the SourceInfo to the ArrayList is a closure.
That is the enclosing context is passed as part of the callback. It
doesn't look as though PulseAudio uses that. It would be better to
define the callback as a method in the SourceInfo class then pass
the callback as this.my_callback, e.g.
https://wiki.gnome.org/Projects/Vala/PulseAudioSamples
For an explanation of callbacks with and without context see:
https://wiki.gnome.org/Projects/Vala/LegacyBindings#Delegates
If you end up digging deep into the VAPI this may also help:
http://lists.freedesktop.org/archives/pulseaudio-discuss/2011-March/009383.html
For a list of CCode attributes see:
https://wiki.gnome.org/Projects/Vala/Manual/Attributes#CCode_Attribute
If you are not familiar with Vala structs take a look at:
https://wiki.gnome.org/Projects/Vala/Tutorial#Structs
and also "boxing" structs in collections:
http://stackoverflow.com/questions/14096999/vala-interface-generics-compiler-error
Although you have "boxed" the struct in your code.
Hope that helps a little,
Thanks for the links! I'll look through them. One of these will
probably have what I'm looking for.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]