moc remote via socket

Submitted by foobla on Sat, 2008-01-12 11:35

Forums:

Because i like to create a remote control for moc i've begun to extract all protocol information from the moc code and reassembled it behind a simple C-interface. For example (this works so far):

struct client *cl = cl_init();
cl_connect(cl);

cl_do_pause(cl);
sleep(1);
cl_do_unpause(cl);

cl_close(cl);
cl_free(cl);
printf("ALL OK done\n");
return 0;

But then i've read from Damian Pietras that he think thats not a good idea (in the WindowMaker Topic).
On the other hand its not possible to get the Playlist via the commandline (as far as i know) and i think that its is much easier to implement the interface without calling `mocp` e.g. in a KDA plasma Widget (my main effort).

daper

Sat, 2008-01-12 14:18

Nice idea, this job is on the TODO list. I must warn you that the protocol isn't easy and clean. It's also not documented, but I guess you already know that :).

If you need help, explanation or something like that, feel free to ask me by email.

Client side protocol implementation and logic is in interface.c file. Probably the bigger problem with using it is that it's asynchronous, so you must do thinks like in wait_for_data() instead of just reading from socket and expecting result for command you've just sent.

--
Damian Pietras - MOC developer

foobla

Thu, 2008-01-17 15:25

Now i'm able to Pause/Unpause from a gtk UI.

You can have a look on scary pieces of sourcecode, use svn checkout from:

http://xapek.org/svn/yvesf/src/moc_remote

Currently i'm using pthread_mutex_t to workaround the problem of asynchronous communication. Please note that the code is not well tested and i'm a unexperienced C Programmer.

daper

Sat, 2008-01-19 13:52

Thanks for the code :)

I can see you've decided to use a separate thread to handle communication with MOC server, so you need this mutex. I don't know GTK but if there isn't some other way to handle X events than using the gtk_main() function it seems to be the only way.

If you stay with the thread you could avoid using usleep() by using select in this place to wait for transmission from MOC socket or from a pipe which could be used to notify the thread that some other thread wants to use the socket. Similar solution is used in io_curl.c in curl_read_internal() to interrupt connection with a stream server from another thread.

Good luck with coding!

--
Damian Pietras - MOC developer

adrong

Thu, 2008-01-31 00:11

Just thought I'd drop a note to say that I'm playing around with this code using MinGW and wxDevC++ (wxWidgets). I'm still working on getting the code to fully cooperate with MinGW but I've made fair progress.

foobla

Thu, 2008-01-31 11:29

Hello adrong,
i've moved the code to
http://xapek.org/svn/common/moc-remote
the location under svn/common/ is anonymous read-writeable. That means you can commit your changes or publish your code, if you like to.
foobla

adrong

Fri, 2008-02-01 04:14

Hey! Thanks! I just checked it out.

...unfortunately, I've come to the following conclusion: MinGW does not believe in Unix sockets and all my experience with programming sockets is under Linux. Also, the pthreads libraries I found for windows leave a little to be desired (e.g. the = operator isn't overloaded for pthread_t) I think I'll keep at it, though I believe I'll have to basically start from scratch.

MairAW

Thu, 2008-03-13 22:16

is this similar to my hack to control moc via a little applet? I wrote as much code as I needed to make it do what I wanted: see

http://maircrosoft.com/moc.html

It's probably ugly stuff with no guarantees, but if it's of use to anyone ...

m

heavytull

Thu, 2020-02-13 14:10

Today, is there any widget to control moc for xfce or kde?

tomaszg

Fri, 2020-02-14 08:18

See e.g. here: http://moc.daper.net/node/578. There are also some scripts to pop out notifications.