Notices

I see, and I can completely understand why you'd do so: if it's just a few ints here and there, it's reasonable enough, since the overhead to add some text file parsing to load the keyset(s) would be pretty large.

Still, I would vote in favor of having separate keyset files, preferably in a human readable format. It would enable not only the packaging flexibility suggested above, but also would enable a lot of flexibility for the end-user: people could test/develop modified/new keysets, even on their N900s directly, without having to rebuild the app for every change.

If you're okay with the idea but just don't want to take the time to code it, I wouldn't mind taking a go at it, and then you can reject/approve my patch as you wish.

I agree completely, which is why I was much more in favor of alternative 1 than alternative 2 anyway. Besides things like IDS/IPS rulesets, which need to have as rapid of updates as possible, I am tempted to say distributing stuff through third party servers when it can be packaged instead is not the best route to go - I just figured I'd throw it in there for completeness.

That would be interesting; the real problem is that Qt was only starting to add gestures to their framework right as they were giving up on supporting the N900. All the low-level gesture code is there, but you can't just say "when the user swipes left, do this"; instead, you need to collect the user's movements, decide when a "swipe" has been performed, and then manually manipulate the screen to react to that. I've got a little app that changes the screen when the user swipes, but I don't yet have the code to make the window slide left or right to indicate that a potential swipe motion has been detected, so it's a little unintuitive.

Well, but I've already got the volume keys tied to changing between your favorite keysets. The other problem is that the volume keys are on the same side of the N900 as the IR LED, so you kind of have to put your fingers all the way around the device while it is pointing at the TV or whatever; very awkward.

That would be nice! Same problem, though; the buttons on that side of the device are just awkward to use.

The hardware keyboard would be good for both of these situations, though; as I recall, I had started using it for some of these tasks some time back (as Sixwheeledbeast had pointed out to me). I'll have to look and see what shape that code is in.

Hmm. That probably wouldn't be too hard to add. I don't think Pierogi benefits as much from full-screen mode as other apps would, but I could give it a try. (The big problem would probably be placing more controls onto the screen for accessing the options on the drop-down menu; but then, I've been wondering if folks would prefer having access to those options on the main screen rather than via the menu. I'll think about it...)

Yeah, as I recall in order to do that I needed to give an elevated status to the app, which for these little utilities, I'm really not all that enthusiastic about. I don't want to potentially drain your battery just because you left Pierogi or Lanterne running in the background...

But let me take another look.

Well, I do have reservations about this. For one, the original purpose of Pierogi was to create a little experiment of my own; I knew that many CIR control systems were similar to each other, and I wanted to see if I couldn't compress keysets together by creating families of similar controls. And, I went ahead and used the C++ class inheritance scheme to implement these families. As such, there are a lot of concepts built-in to the current Pierogi system that would be difficult to explain to the general public.

Second, Pierogi is way late to the game here. The N900 originally launched with an IR remote control mechanism that uses 100% human-readable keyset files; that is, the Linux Infrared Remote Control (or LIRC) project. (And the Irreco / QtIrreco project built a GUI shell around it.) So, you can today set up the LIRC server on your N900 and run your own config files on it. (Although, I do have to admit that calling LIRC config files "human-readable" is a bit of a stretch; the syntax they use is, honestly, pretty awful.)

However, let me make this counter-proposal: what about a two-tiered keyset mechanism? It shouldn't be hard to let Pierogi continue to support its internal set of keysets (following my rather obscure implementation mechanism), and then optionally read in a set of more standard external config files.

I think the only significant effort here would be to come up with a decent human-readable file format. The LIRC format is, well, just awful; moreover, as it only records individual pulses, it is fundamentally incompatible with the current Pierogi system. I'm using a protocol-based system now, so a config file would presumably involve naming the protocol to use, then (sometimes) a manufacturer ID, (usually) a device ID, and finally a sequence of key IDs. The key IDs will also need to be mapped to the internal Pierogi button list.

I've gotten a whole lot more experience writing recursive-descent XML parsers in the last year, which folks can probably see from my other pasta products, so I'd be happy to support an XML-based file format. But I could probably do something else too, if another type of format would be preferred.

Another update to Pierogi is now making its way up to the Extras-Devel repository. Other than the addition of a Grundig TV keyset, the main modification is an update to the documentation available from the drop-down menu. I'm not sure it makes for entertaining reading, but at least it now covers the main points of the Pierogi UI (other than the macro system, which I have simply left out).

As such, I'm going to go ahead and classify this update, 1.1.41, as a "release candidate". I'm going to continue to pound on it a bit myself for a day or so, and if no one else has any objections, I'll go ahead and submit this version to Extras-Testing. With luck, a much updated version of Pierogi will soon be available in the Extras repository.

I'll probably try to work through some of my other pasta products, and see if I can't shape them up into something that can be pushed into Extras...

Shouldn't the promotion go through the testing and voting process? Just asking

Just a quick thought: have you got the keyboard open when you're using the app? I've found that often the ir port is blocked by the n900's screen when that is the case.

Yes, I kind of thought that's what happens when one submits an app to the Extras-Testing repository. (Or am I missing a step? I'm pretty sure that's what I did to start the process before...) I'm planning on doing that tomorrow, if no other problems show up...

To be honest, I do not quite have all the details figured out. I have only one package and that is in Extras-Devel. I somehow always assumed you need to get enough votes first, before the promotion to Testing. You are much more experienced. I will just shut up.

Well, I've only done it once before (for Pierogi), and that was a very, very long time ago (as folks have been pointing out to me ). So I don't know if the process is still the same...

Propagating from devel to testing is purely based on developers decision (release candidate for testers/masses first).
There it should be tested and upvoted by at least 6 positive votes, then it will hit extras a few (quarantine) days later.