RMIR v3.0 Major new release!

[mathdon]

@lbschenkel
Please try development build RMIR v3.0.2 that I have posted to the RMIR Development folder on SourceForge. This should fix the corruption of Shift-button44 when included in a controlled or real-time macro. This issue was not specific to that button, it would happen to the shifted form of any button with keycode > 0x3F (the 44 in the name is the hex keycode of the button).

You mentioned other weird happenings with v3.0.1 for that remote. If they are still happening, please try to describe them, or better still, post a setup they happen with or give me a way to reproduce them like you did with the corruption issue.

[lbschenkel]

@lbschenkel
Please try development build RMIR v3.0.2 that I have posted to the RMIR Development folder on SourceForge. This should fix the corruption of Shift-button44 when included in a controlled or real-time macro. This issue was not specific to that button, it would happen to the shifted form of any button with keycode > 0x3F (the 44 in the name is the hex keycode of the button).

You mentioned other weird happenings with v3.0.1 for that remote. If they are still happening, please try to describe them, or better still, post a setup they happen with or give me a way to reproduce them like you did with the corruption issue.

Thanks! Regarding the other things, it was late at night and after the upload I noticed that a number of buttons (triggering macros) weren't working. All the issues might boil down to this same macro corruption (because I just noticed with this button, but didn't review all other macros), or maybe there's some other regression as well. I will try out this new version and let you know if there's anything else that is not working.

[mathdon]

RMIR v3.0.3 is now officially released. This is the first release since v3.0.1 as v3.0.2 was for development purposes only. This build fixes a number of obscure bugs that affected particular remotes in specific circumstances. This includes all bugs that I am aware of that have been reported by users since the release of v3.0.1. If I have missed anything or you find any further bugs then please report them in this thread.

[davecs]

Come up with a slight problem. It hasn't really affected me that much before, because I've not got near the limit of memory. Having sent off for the stuff to build the Arduino interface, and (hopefully) fixed my old 8910, I've been thinking about preparing an RMIR file, and things are much tighter.

Well, in gtk+ mode in Linux, the colours at the bottom (on my computer at least) are barely visible as you can see from the attached image. Can they be improved? When starting RMIR, the text in the boxes is black, but as soon as I open an rmir file, it changes to what you see in my upload:

http://www.hifi-remote.com/forums/dload ... e_id=26759

I am trying to vary the GTK+ colours via the KDE Control Centre, but nothing makes any difference. Is there anything that can be done in the next release?

[HamburgerHelper1]

In RMIR have you tried any of the other themes under options-Look and Feel ?

[davecs]

In RMIR have you tried any of the other themes under options-Look and Feel ?

I have. It is possible to see those numbers clearly at the bottom in the other three, but the windows really look out of place. In Nimbus and CDE/Motif I lose gridlines too. I can't push "Metal" slightly off the side or top/bottom of the screen. GTK+ looks far more as if it belongs there, except for that one little problem with the colours. So if it's possible I'd like the colours to have more contrast in that mode.

[The Robman]

Here's the image...



And for anyone wondering what GTK means, as I was, it's short for GIMP Toolkit. And GIMP in an acronym for "General Image Manipulation Program".
https://wiki.archlinux.org/title/GTK

[davecs]

Here's the image...

And for anyone wondering what GTK means, as I was, it's short for GIMP Toolkit. And GIMP in an acronym for "General Image Manipulation Program".
https://wiki.archlinux.org/title/GTK

It actually stands for GNU Image Manipulation Program. And, in turn, GNU stands for GNU's not Unix. Ridiculous? In the early days of Linux, they used to give programs stupid names with recursive first words. Surviving examples:

LAME = Lame Ain't an MP3 Encoder. (although it is!)

WINE = Wine Is Not an Emulator (it's used to run some Windows programs inside Linux — I used to use it to run ir.exe before rmir under Java came along).

KDE = KDE Desktop Environment. Though some say that the K stands for Kool.

[mathdon]

GTK+ looks far more as if it belongs there, except for that one little problem with the colours. So if it's possible I'd like the colours to have more contrast in that mode.

I can add a new Option, to change the colour of the text on progress bars. Indeed, to set the text colour separately for text within the coloured and uncoloured background within the bar. I would propose to give each of these a choice between Blue (the current value), Black and White. This should deal with all contrast issues. In your case I think Black for both would work. I have tested this on Ubuntu. You will have to check whether it works on your Linux. I hope to post it as a development version today or tomorrow.

I think you may have developed your .rmir file by starting from File > New in RMIR. Do please read the warning notice that is displayed when you select this option. Setups developed from this may not work, as many remotes have settings such as anti-piracy that are not within the control of RMIR. By all means try it but do not expect it to work. You should always start with a downloaded setup, preferably from a factory reset if you are starting again from scratch.

[The Robman]

It actually stands for GNU Image Manipulation Program. And, in turn, GNU stands for GNU's not Unix.

Ah, I see. I guess I had quoted the phrase that came up in a Google search, which was quoting the Wiki article, but it was originally called "General Image Manipulation Program" before becoming "GNU Manipulation Program".

https://en.wikipedia.org/wiki/GIMP#History

And if the "G" in GNU stands for "GNU", I'm wondering where the "G" itself came from, because any letter would work, right? Like if it was XNU meaning XNU not Unix. But I see it was named after the song "The Gnu".

[davecs]

Ah, I see. I guess I had quoted the phrase that came up in a Google search, which was quoting the Wiki article, but it was originally called "General Image Manipulation Program" before becoming "GNU Manipulation Program".

https://en.wikipedia.org/wiki/GIMP#History

And if the "G" in GNU stands for "GNU", I'm wondering where the "G" itself came from, because any letter would work, right? Like if it was XNU meaning XNU not Unix. But I see it was named after the song "The Gnu".

All I can say is that the pioneers of Free Software either had a weird sense of humour or were just plain weird. Like many acronyms, they make the initials up then decide what it stands for later.

Linux, functionally, impersonates Unix but the code is rewritten from the ground up as Unix is copyrighted. So when they re-wrote a load of the code they had to deny that it was Unix by another name. So I guess they were sitting there thinking... something's not Unix. If we make it a GNU, we've got a silly song, a nice logo. Then we can say it stands for GNU's Not Unix. Back in the day, they still had to use the Unix kernel to run the GNU code they had written, then someone came up with Minix. That was free to use, but not open-source. Linus Torvalds rewrote the Minix kernel from the ground up and called it Linus' Minix, or Linux for short. The GNU project then had an opensource kernel.

Great work, but some lousy humour!

[davecs]

I can add a new Option, to change the colour of the text on progress bars. Indeed, to set the text colour separately for text within the coloured and uncoloured background within the bar. I would propose to give each of these a choice between Blue (the current value), Black and White. This should deal with all contrast issues. In your case I think Black for both would work. I have tested this on Ubuntu. You will have to check whether it works on your Linux. I hope to post it as a development version today or tomorrow.

That would be absolutely brilliant!

I think you may have developed your .rmir file by starting from File > New in RMIR. Do please read the warning notice that is displayed when you select this option. Setups developed from this may not work, as many remotes have settings such as anti-piracy that are not within the control of RMIR. By all means try it but do not expect it to work. You should always start with a downloaded setup, preferably from a factory reset if you are starting again from scratch.

I tend to use that for planning purposes. For example, I can't download what I have in my URC-8910 from years ago until the Arduino Nano and the Dupont wires arrive, but I can experiment with some ideas in the meantime. I've already learned what sort of things will over-run the memory.

[The Robman]

If you're doing this for the URC-8910 I think you're safe creating the file using RMIR, the remote memory was much simpler back then.

[davecs]

If you're doing this for the URC-8910 I think you're safe creating the file using RMIR, the remote memory was much simpler back then.

I will also see if my two ancient URC-7562s work. The instructions with the extender are for ir.exe and don't work with RMIR, and I don't have any saved files from them. I hope that the EEPROMs in the remotes still hold the data I uploaded, many years ago, and that I can strip out all the old devices and leave the extender still there. If I can do that, I will upload the resulting rmir file to the files section.

P.S. There are some spammy files in the URC-7560/2 section...

[mathdon]

@davecs

I have implemented the ability to set the text colours on progress bars and it works fine in Windows. Unfortuately it does not work in Linux with the Look and Feel set to GTK+. I found that Linux documentation says that it is up to the Look and Feel as to whether it implements such settings, and GTK+ appears not to do so. However, I find that Metal works fine in Linux and the settings work as they should in it. Initially I had your problem about moving the display off the side of the screen, but I found I could grab the bottom right corner and re-size it as I wanted, after which it would move normally. You could also try editing the RMBounds entry in your RemoteMaster.properties file in the installation folder, if you really can't get the RMIR display to re-size.

I haven't posted v3.0.4 with this facility yet, as I thought I would wait for your reaction to this news. I am not a Linux expert, as you know, so I thought you might have some suggestions I could try.