Notices

Lanterne and Orecchiette are quite obvious if you ask me. I am not sure Pierogi - I did not even know it was a pasta shape until now, I thought the icon was a slice of a lemon - but I got used to it.

I'd say leave the icons be. Looking at my (Windows) desktop, only 8 out of 24 icons have anything to do with the functionality of the thing they represent (Recycle Bin, This PC, Calculator - all MS, plus Firefox, Firebird, Putty, ImgBurn, Audacity). 4 more are somehow related to the name (CodeBlocks, Qt Creator, Wireshark, Skype). Copernicus' pasta icons fall into this category. The rest are complete fabrications (Adobe Reader, Hugin, HexEdit, Inkscape. LibreOffice, WinSCP, Nokia Suite...).

Epic thread. Good to see that devs are still active for N900 apps.

I myself moved to a GS4 a little while ago. I have to admit, it is a much better phone. I do miss the openness of having a full linux phone, but I don't miss all of the fun quirks when it came to the actual phone part.

That being said, the N900 is still an epic little computer! I'm trying to bring some life back into mine and have been working on a personal project to create a hacked-up jukebox type device connected to a stereo with a web based UI.

So far, I've managed to get the following working pretty well:

• Mounting NAS and syncing music to device nightly via script
• Running MPD on device (works with MPD remote apps in Android, using desktop MPD clients or over SSH, but not geeky enough.)
• Running lighttpd and php on device (surprisingly well performing!)
• running old PHP MPD remote apps in lighttpd which can play music and manage the queue*
• DNS masq from music.net on my router to the PHP file on N900 ip.

*I've still got some work to do on the PHP UI. It can pull playlists and the full song list from the MPD DB, but for whatever reason, it doesn't have the artist>album>song hierarchy. Also, no way to put the play queue into random mode or move songs up/down. Might be something the original PHP dev never implemented. I'm pretty sure I can figure this out with some effort. And I'm likely going to have to as I can't find any modern PHP MPD clients or any with active development.

So where does pierogi come into this?

Well, right now, I need to turn my stereo on/off and adjust volume with the low tech original remote. That doesn't satisfy my inner nerd in the slightest. In my use case, I'm never actually touching my N900. It just sits on top of the stereo and plays music when the web UI tells it to.

Conveniently, the stereo 'tower' is inside of a glass cabinet. If I point the N900 just right with the door closed, the reflection on the glass works and I can control it with pierogi.

The problem in my case of course is that I don't want to touch the N900 (ever). I read through some of the history on this thread and through your documentation. Did you ever get a CLI running? What I would like to do is take advantage of all the protocol work that you did and call pierogi buttons from bash scripts from PHP. I'd add some PHP code and introduce buttons in my web UI for power and volume.

I've looked through your source, but I can't wrap my head around how the protocols actually work (Kaseikyo using the PanasonicAudio2 keyset; working flawless on Panasonic SA-AK40). Way too complicated for my current skill.

I was thinking that as more and more people need a non-phone use for their N900, that adding a CLI to pierogi could turn it into an IR blaster of sorts for the bash script happy like me. You could even write a PHP web ui in theory giving people whole home IR blaster capability.

Unfortunately, my C++ foo is limited to reading it and getting the gist. I've never written anything so adding a CLI to your app is out of my current capabilities.

If you are not interested in a CLI at the moment, perhaps you might be willing to share some info on constructing the command array[s] based on the protocol above? I'm assuming that if I modprobe the lirc0 device and echo a proper array to it that it would actually transmit?

I can easily create and destroy the device, just have no idea how to 'make it go' in bash.

Lastly, really well done on this app! Not only is it really well designed and implemented, but your commitment to the app and the users is truly amazing and impressive.

No, I still have no CLI for Pierogi as yet. My problem has always been "how does the user specify the keyset and key they want to use"?

The LIRC server gets away with this by only loading a single keyset config file at a time, and letting the user match keyname strings against what is written in that file. Unfortunately, Pierogi has something like 700 keysets now, with more than 200 possible keys to be defined within each keyset (not including the many commands that I haven't yet matched up to a key). So, exposing all that information to the user, and doing so in a way that doesn't break their scripts every time I come out with an update, is something of a challenge.

(But yeah, you might want to check out using LIRC -- if you're only interested in controlling a single device, the LIRC already does everything you want, and you can control it completely from the command line.)

That said, I've been picking away at the half-broken Pierogi macro system for the last few days... A macro is really just an automated script telling Pierogi which keys to press; there's no reason you couldn't just specify a macro on the command line. That would allow me to hide all the ugly details where the macro is specified. I'll see if I can't get something working...

Ah, well, most of the code involved in one of Pierogi's "protocols" involves setting up a "device" value and a "command" value into a particular sequence (sometimes with a few extra numbers thrown in), which then gets converted to binary values. This lets me store just the actual command values as a keyset.

The LIRC doesn't bother with this, and its config files store the entire string of numbers that get converted to binary, without bothering to try to figure out what part is a device value or a command value or whatever. Easier to wrap your head around what is actually being sent that way, if you prefer...

Indeed! The infrared device driver has gotta be one of the simplest devices ever created. Fun to play with...

EDIT: Well, maybe not a bare array; I suppose you'll still need to make some kind of function call to properly communicate with it. It's still one of the simplest device drivers out there, though.

Thanks! But, I shall let you in on a little secret: the primary user of Pierogi is me! All you folks out there using it and telling me what does and does not work, are merely allowing me to perfect a single device that can CONTROL EVERYTHING AND TAKE OVER THE WORLD!!! Bwa ha ha ha ha!!!

Ahem. Anyway, I'm glad you're enjoying the app.

Yeah, I see now how a CLI would be difficult especially regarding how to standardize so things don't break when you edit keysets. Thanks for the clarification on the protocols. It makes more sense now.

I'll look into LIRC for my purpose. Should be just what I need to accomplish my (odd) goal.

That being said, have you considered porting pierogi to android? The IR remote apps in the play store all suck the big one.

I would _love_ to do that! I really should try again... The last time I tried (last year), it turned out that, while I could easily port the Pierogi code to Android, the IR hardware could only be reached by using device drivers provided by the manufacturers. I contacted one manufacturer (HTC), and they were more than happy to give me everything I needed to get it up and running on their devices -- once I had signed the appropriate NDA. Unfortunately, said NDA required that no code using the device driver (or, really, their entire SDK) could be open-source.

This is a problem for me, as not only is Pierogi currently distributed under an open-source license, it was originally based partly on the LIRC (although that really isn't the case any more), and more importantly relies upon keyset data provided publicly on sites like "hifi-remotes.com". I don't think there's any way I could realistically convert it into a closed-source app at this point.

Maybe things have gotten better on the device driver front. I should take another look...

EDIT: Well, heck! It looks like main-line Android now has an API for infrared. I'll have to download it and take a look. (Anybody out there have an Android device with IR who would be willing to test? I don't personally own any Android devices myself...)

I would be happy to test. I have a GS4 running kit kat which at very least 'works' (blinks the ir led; seen via camera; apps are too crappy to test further) with the crappy IR apps in the play store. Would be great to have a working IR app that doesn't pop up an ad every 2 seconds and limit the usage to barely anything even though it's ad supported.

Though I'm having a fairly rare free time spurt which doesn't happen often so I might not be the most responsive tester in the world, but I'll do what I can.

Good call on LIRC btw. I have it sending the proper ir commands by script and getting php to call my scripts should be trivial. Problem is that I can only call irsend with root permissions and I'm struggling to find out where in the program chain the permissions issue is. Don't really want to give my lighttpd user root permissions....

Thanks for the helpful suggestion there.

Macros! I've finally started to clean up Pierogi's macro mechanism. I've realized that there were two major design issues holding me back; first, I was too caught up in the notion of making macros into "user-defined buttons". Ultimately, macros work by doing exactly what the user does -- selecting and sending commands to the IR port. You just can't have the user and a macro controlling Pierogi at the same time. So now, while a macro is running, a modal dialog box will pop up, showing what the macro is doing, but also blocking the UI; if the user closes the dialog box, he or she will regain access to the UI, but the macro will be aborted. Very simple, very clean.

The other issue was attempting to create, edit, and save macros completely from within Pierogi itself. This allowed me to hide some of the internal ugliness from the user, but ultimately it's just way, way too complex of a UI for me to maintain. So, I have instead moved to storing macros in an XML file. I admit that writing and loading these files will be a burden on the user, but it can't be as much of a burden as trying to negotiate the previous macro editor UI.

Ok, so Pierogi 1.1.32, with a first attempt at this new macro system, is now working its way up into extras-devel.

To get the bad news out of the way: if you've been using the existing macro mechanism, this is going to break your macros. I apologize, but the existing system was just such a mess, that I didn't think I could easily find some way to transition to the new system.

The good news is that the new system should be working just as well as the old one. (I've more or less just repackaged the existing macro functionality.) So, you should be able to do as much with the new system as with the old one.

As mentioned, macros are now defined in an XML file. I haven't put a whole lot of effort into defining the file format yet (I don't even have a DTD for it), but I've got a little bit of documentation set up describing how to create this XML file.

The previous "User" panel has been renamed "Macros", and has a new button allowing you to load an XML file. Along with the previous six user-defined buttons, it also has a combo box allowing you to access any macro from the file.

Another side-effect of this new macro system is that it allows you to access the entire set of keys defined within Pierogi (which you can now find listed in the above-mentioned documentation). This means that, for example, you now have access to some of the commands that I've been too nervous to place into the main user interface. So, if you want to access the service menu of a TV (which I have defined for some LG, Samsung, and Sanyo keysets), the following XML file will do the trick for you:

The nice thing about using XML is that it should be much easier for me to extend the macro functionality. Timers, loops, conditionals, pretty much anything should be fair game...

As always, please be prepared for a lot of bugs. (Especially with the entirely new XML parser! Also, the keyboard controls are currently broken, but I think they were broken before...)

P.S., new Pierogi website!

Qt does indeed live up to the hype; it took me some hair-pulling to set up an Android environment for the first time, but once that was done, it's surprisingly easy to port an app over... (Although I obviously need to do a lot of work to support a portrait layout. Maybe I could port that layout back and finally make Sixwheeledbeast happy. )

Pierogi running in an Android emulator (and this is Qt Widgets, not QML!):

Ok, so I have been playing with the new macro update.
While it takes a bit more typing, it seems easier after a while.

A few comments...

All the links in app go to the old website so I had to come to TMO to find the link to the macro docs.

Having trouble getting the pause command to work, you have no examples to copy in the docs.

The logical guess, IMO

Throws up parsing errors in application and with an XML validator.
So I have get to work that out.

Also it would be nice if we could hide the XML file away from MyDocs, I hate settings files missing up documents folders. Open file will only allow user accessible locations. Ideally I would locate it in /home/user/.pierogi for example.

Oops, sorry, I really do need to clean up the documentation. (I keep putting that off...)

Also, I honestly do intend to finally try and get a extras-worthy version of 1.1 prepared once the documentation is updated.

Sorry about that! Yeah, the current syntax is:

I was thinking that other attributes, such as "millisecond" or "minute", might be convenient in other situations. (Pausing by minute, along with a loop, would be enough to implement an intervalometer. I really need to get some more work done on adding more macro features...)

Hmm. That sounds quite logical; and, it's yet another strike against the Qt "getOpenFileName" dialog. I'm going to have to come up with some custom dialog of my own, I guess... Thanks!