Notices

Ah, I have had lots of trouble with Grundig. I love their hardware, but they've used dozens of different (and often obscure) IR protocols in their products.

Well, at least that makes things a bit easier! The Grundig TV Keyset 2 is based on the classic RC5 protocol; I'll look around and see if I can find more Grundig-related RC5 configurations.

BTW, could you test out the "Philips TV Keyset 1" on your TV? Philips created RC5, and many manufacturers will simply use their keyset configuration directly. It might work for your Grundig...

Quick request:

Any chance you could promote one of the more recent versions down to extras-testing, and eventually extras? I see it's been sitting on 1.0.0 in extras and extras-testing for a while, and while I don't use pierogi extensively, it seems to me like the -devel versions have been pretty stable/safe for a long while now, while containing many useful improvements over 1.0.0.

I know it's a pain to keep up with that stuff (esp. prodding people to honestly up/down vote each version in extras-testing, then checking back every once in a while to see if it got enough votes yet), but there's definitely value that we as a community could extract if we kept trying to properly promote stuff down to 'extras'.

Ok, yeah, I do need to get moving on this. I've been nervous about all the major changes I've been making to the UI, hoping to get a little more feedback about them. (And yeah, I keep wanting to add more tweaks too...) Let me try to consolidate what I've got, and finally update the documentation.

Now that I think about it, here's one question I have about the current system: once you've pushed an app up to Extras, there's no real way to perform maintenance on it. That is, I very much like the idea of having a "stable" code branch and a "development" code branch. For example, once I pushed 1.0.0 up to Extras-testing, I went ahead and started tweaking the UI in version 1.1. However, there's no reason I couldn't back-port new keysets into the 1.0 branch (and I still have the 1.0 code sitting on my computer here); however, I see no (easy) way to maintain two different codesets within the Extras mechanism.

Ultimately, you've either got to push up a nearly perfect app to Extras-testing, or hold off on making any major changes to the app in Extras-devel until you're fairly sure you won't need to push up any fixes. I've been following the first path, and have been leery of pushing up my code until it's in a fairly stable state...

Awesome! That totally did it!!! The Philips Keyset is working

Thank you so much!!!!!!!!!!!!!!

Thanks! I'll go ahead and add the Philips keyset to the list of Grundig keysets as well, then.

Just out of interest, how many genuine keysets are there in Pierogi?
Without duplicates, that is? At least to the nearest order of magnitude

That is an interesting question! I don't really keep count, myself; let me take a quick look...

Ok, as of today, there are 680 named keysets. Of these, there are only a few outright duplicates (such as the Grundig TV Keyset 5 I just added). (I had expected that there would be a lot of manufacturers simply copying existing keysets, but that doesn't seem to be the case.)

There are, however, quite a large amount of keysets that only differ from each other by a few commands. For these, I've been delegating one keyset as the root, and having the rest only store their differences from the root. I've labeled the branch keyset names with a letter, so they'd be "Keyset 1a", "1b", and so forth. I'm counting 173 of these right now; so, in essence, there should be roughly 500 truly unique keysets in Pierogi at this point...

Well, on the devices I have which are constantly on Extras-devel, I've found the UI perfectly fine. I don't really have anything stand out in my mind as particularly bad/unintuitive about it. Well, that Automated Keyset Search or whatever - it's a bit unclear just from looking at it how it's supposed to work. But I suspect if I just started fiddling with it, I'd figure it out pretty quickly.

I have a couple of other ideas for how you can enable pushing keyset updates without having to update the entire app:

1. Separate it out into two packages, "pierogi" for the actual executable, conffiles, etc, and "pierogi-data" (nice, general naming that I see Debian packages use all the time) or "pierogi-keysets" or something more explicit like that, for the actual keyset data. Then pierogi can list pierogi-data in it's "Depends" field. That way, when you've got a keyset update, you can upload and promote it through independently of the code-base. Since keysets are probably a lot easier to verify as not-broken than a non-trivial program is, this allows you to decouple the promotion of keyset updates from the promotion of the program, while still keeping it within the packaging system.

2. You could have pierogi automatically check for keyset updates and download new keysets. The biggest advantage it has over the repos is that you can get keyset updates out even faster. The biggest (dis)advantage (depending on what aspect of this point you feel is more significant), this removes the "community-votes-on-it" check from the keyset data. The biggest technical disadvantage is that now you're maintaining it on some other server outside of the repos (which has two implications: 1, availability is now dependent on a third party besides community-maintained infrastructure; 2, it's outside the package management system, which means that if a good reason ever came up, I couldn't make a package depend on a specific version or later of your keyset files.)

[edit]Another advantage to point 1 is that it requires no additional complexity in the pierogi code: pierogi doesn't have to suddenly gain a whole slew of networking, version checking, downloading/unpacking/etc code, which number 2 would require. Admittedly, you could just shell script all of that, thereby offloading most of the complexity, but it's still more than nothing - I imagine the keysets are currently in their own separate files already, and not hard-coded into the code, hence my assumption that just having it as two separate packages would add no complexity. But if they are hard-coded into the binary right now, then I would argue it would be must better from a design perspective to split them off regardless of what you did with the packaging for the repos, so that complexity is justified and ought to be in there anyway.[/edit]

Well, I think the first path is more or less the correct one, but I wouldn't necessarily be so cautious/strict about what goes to testing. I think the idea is, you push things from -devel to testing as soon as you think it's ready for extras. Which to me would mean, as soon as I subjectively think it doesn't have any new bugs/problems, or that any problems it does have are outweighed by the improvements. But once I was fairly certain I didn't break anything with it, I'd go and push it down into testing.

For aircrack-ng, for example, I would usually capture some packets, maybe crack a single WEP network with it, but then I'd figure "well, it installs/uninstalls/reinstalls fine, and the likelihood of stuff having broken isn't too big since the code is mostly good, so I'll just push it into testing and other people who use it will yell at me or downvote it if there's a problem."

As a maintainer, I expect -devel to be my playground/scratch-space, -testing to be where versions I thought were good enough for general consumption to go, and extras to be where version "the public" considered worthy would go. I trust that if I put a flawed version into -testing, it will either get caught and stopped early on, or if a problem does get through, that the fix will likely be promoted through fairly quickly.

So in short, I think your extras-testing criteria needs to be that it's "nearly-perfect" - you just need to think it's "probably not more broken than it was".

Thank you! I'm really not a UI guy, and so I've always been nervous that what works for me may be completely off for the public at large. (Which is why I always want to at least get the documentation straight before pushing anything up...)

Ah, well, that's the thing -- in Pierogi, the keysets are part of the actual executable. Looking at, say, an average LIRC config file, you might think that a keyset is a large, complicated beast; but the LIRC is protocol-agnostic, and does nothing but count raw IR pulses. Once you understand the protocol that a device is using, all you're left with is at most a few dozen integers -- one for each button on the given remote. I really saw no reason not to enter these directly into the code...

Ah, well, the problems with the QtIrreco app kind of steered me away from this path. Actually, I really am not a fan of most modern remote-control apps, even if all they are doing is downloading advertisements; I really think a simple tool like this should be fully independent, and work without needing to access the net for anything.

But yeah, I am looking at this concept for other projects...

For most projects, I would agree; however, given that IR keysets are tiny static sets of integers (as the devices being controlled generally do not support modifications to their controls), I still believe that in this case there's no downside to simply adding them directly to the code.

Hmm. Alright, well, they do say that "perfect is the enemy of good". Let me get the documentation into a relatively good shape, and push up what I've got...

some usability improvements might be considerd
swiping left right could change tabs as lying on bed one would not need to look the ph to toggle tabs as that way its more like a actual remote
hardware volume keys as an option to actually control the volume of tv or change channels of hifi sattop whatever
camera butt half press to mute full press to power down when sleepy
fullscreen option as many times i found myself to quit pierogi when using blindly
if implemented hw buttons should work regardless of screen lock not like lanternes camera button toggle which goes dead when screen lock kicks in
all in all fear less just look at every android version ui changes or look at win 8s slight ui changes comparedto xp 7 people coudnt care more ..
pasta products are awsome i just want to enjoy them nore.