On Sat, Nov 21, 2015 at 6:33 AM, Al Thomas <astavale at 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.
