? ?
brad's life [entries|archive|friends|userinfo]
Brad Fitzpatrick

[ website | bradfitz.com ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

enty [Sep. 23rd, 2002|11:20 pm]
Brad Fitzpatrick
[Tags|, ]

Working on the UI for my MP3 stereo component.

Pieces involved:

Tiny C program to read the IR receiver.

Perl/Qt 3.0 for the UI... but QThread isn't available in the Perl bindings, and I can't seem to find a way to add a new item to wait on to the main loop's select, except a socket descriptor.

So, have a perl wrapper around Tiny C program that makes C program's output (IR codes received) available over a TCP socket.

Then I'll use a QSocket (hope it's implemented in Perl/Qt!) and a QSocketNotifier to give the Qt main loop an event when a new IR code is available.

If I get this working, then I'll clean it up, either moving to Perl 5.8 threads, or rewriting the C bit in Perl, or writing the Perl network wrapper in C. Or maybe I'll just get it working and be happy, even with 3 processes running to do it.

Qt is pretty cool ... the Perl bindings are a little non-Perl-like, but not bad. Learning the Qt API is taking the most time.

Update: QSocket appears to work. QSocketNofier doesn't. Grrr. Back to square one. Use a QTimer to regularly poll the socket to see if there's anything there? Lame. I guess this is what I get for using just-released bindings.

I could just do this all in C++ I guess. Feh.

[User Picture]From: mart
2002-09-24 09:25 am (UTC)

Why not replace your perl wrapper and C program with a perl module with a native code component written in C, which can then make use of a callback sub whenever there's something to read? Could also tie a filehandle to your clever IR module so that the perl code can just use simple I/O to read the input.

Native code component means only one process. tie makes it perl-like.

(Reply) (Thread)