JP1 Remotes

[davecs]

[davecs]

I thought of something after I went to bed, I won't be able to test it until this afternoon UK time. If I'm right it may be possible to change other colours under KDE to contrast the text in the sliders. Not sure about the text itself though, that seems immutable and possibly being set by the program itself.
_________________
URC7560/URC7562, URC8910, URC7980, URC6440/OARUSB04G and URC3661

[davecs]

I tried another method of attempting to change the GTK colours under KDE. It didn't work.

What I've found is that, under KDE, I can't change the colour scheme at all. I've tried both MX-Linux and PCLinuxOS under KDE with the same result.

Under XFCE, which is a GTK-based desktop, all the colours do change according to the global colour scheme, except one: That cyan-coloured text in bars at the bottom. Is that being set within the program?

EDIT/UPDATE: The weirdest thing! Thanks to the magic of symlinks, no matter which partition I boot up, with different variations of Linux, they all address the same copy of RMIR. After experimenting with the other desktops, I returned to my favoured PCLinuxOS KDE, and ran RMIR to find that the Blue in the bars at the bottom had darkened a little, and now I can read the text! I can't understand how or why that is.
_________________
URC7560/URC7562, URC8910, URC7980, URC6440/OARUSB04G and URC3661

[WagonMaster]

I'm a little late to this (and I had to install Java on my Slackware 15.0 PC just now to run RMIR in order to be sure of what I'm saying), but I think I might have some helpful input...

When the "Gtk" look-and-feel option of RMIR is selected, it appears as though Gtk version 3 (not anything older) is in use. This means that the only way (AFAIK) for the user to control the appearance of certain UI elements is to use CSS. I crudely and temporarily tweaked my own Gtk3 CSS rules just now for RMIR and proved that the text in those progress bars did indeed show my selected CSS-file's color assignment.

I'm a rank amateur with CSS, but I've successfully tweaked it for my Gtk3 apps a few times over the years, so what you want is certainly possible. I'd try to explain more, but I'm very rusty and I think you'd find Internet Gtk3 CSS tutorials a quicker and better guide than I'd be!

Some tips about moving and/or re-sizing windows in Linux:

1. When a window is maximized in a given axis (horizontally, vertically, or both), the window manager might be fighting you if you try to move it even slightly off-screen in that axis. Shrinking the window in that axis then trying to move it off-screen might help, assuming I understand the problem you're seeing.
   
2. Typical Linux installations allow moving a window by holding the 'Alt' keyboard key and clicking with the primary mouse button (usually the left one) anywhere in the window (i.e. not just on the title bar).
   
3. Similarly, they allow re-sizing of a window by holding the 'Alt' keyboard key and clicking with the secondary mouse button (usually the right one) anywhere in the window (i.e. not just on the re-size handles or window edges, depending on your window manager).
   

Those tips can come in handy at any time, but especially when a window is off-screen.

I hope what I wrote might help but please forgive the intrusion if I've misunderstood any of this discussion.

If either of you need me to test something under Slackware Linux, feel free to ask.

Good luck!

[n8nagel]

[davecs]

[WagonMaster]

[mathdon]

@n8nagel

The issue you have raised has been fixed in the latest RMIR, so please try it and report back if you still have a problem with it.
_________________
Graham

[mathdon]

@davecs

I have been doing my own experimenting and have found that very confusingly, GTK+ mode interprets progressbar.setForeground(..) differently from other UI's. In other UI's this sets the colour of the bar that represents the percentage used. In GTK+ it sets the colour of the text on the bar, the same for the coloured and plain parts. The other colour settings for a progress bar appear to be ignored. So I think I can give you the ability to set a text colour that will be a contrast for both the coloured and plain parts of the bar, but if you change from GTK+ to another look-and-feel then that will be used as bar colour rather than the text colour,

The present value of this foreground colour is AQUAMARINE, which is set by RMIR and is the bar colour on other UI's. It is what you are getting as the text colour in GTK+. The bar colour in GTK+ is out of the control of RMIR. You get what you call a cyan colour, though your screenshot shows something that is paler than my interpretation of cyan and is why you get poor contrast with the aquamarine text. In Ubuntu with GTK+ I get a deep purple for the bar and the aquamarine text is actually a good contrast, which is why I haven't had your problem when using Ubuntu.

I have not yet experimented with removing all references to foreground colour from RMIR to see if that does leave the text defaults, which appear to be white on the coloured part of the bar and black on the plain part. If that works then I will make that an option, too.
_________________
Graham

[davecs]

I could probably live with the "Nimbus" look and feel, but for some reason, the gentle highlighting of alternate lines on General, Devices and Raw Data tabs is not present on the Key Moves, Macros and Special Functions tabs. It's using the system Window Decorations on my KDE Linux, so otherwise seems OK.
_________________
URC7560/URC7562, URC8910, URC7980, URC6440/OARUSB04G and URC3661

[davecs]

[mathdon]

I have now posted RMIR v3.0.4 in the RMIR Development folder for testing. There are no bug fixes in it as no bugs have been reported since the release of v3.0.3, the current official version. Instead, it adds three new features:

1. A Settings panel for XSight Touch/Color remotes that allows the Language and Region settings to be changed.
2. A Settings panel for XSight Lite/Plus remotes that allows the Language setting to be changed.
3. A new entry, Set Progress Bar Colors, on the Options menu to customise the colors of progress bars.

The new Options item is provided primarily to allow customization of progress bar colors in cases where the standard settings do not provide enough contrast for the text value to be read easily. This is primarily the case for look-and-feels that do not support all the setting facilities available in Java, such as the GTK+ look-and-feel in Linux. There is no guarantee that the options choices will be supported by such look-and-feels, but it is provided in the hope that it will help.
_________________
Graham

[mathdon]

@davecs

As you see, I have now posted RMIR v3.0.4 with the new Options entry for changing progress bar colours. I hope it is self-explanatory. It provides alternatives for three parameters, but in GTK+ mode only the third one has any effect. I think that if you set this to Black or Blue, it should give you the contrast you require. Please report back when you have tried it.
_________________
Graham

[davecs]

@mathdon

While I'm being a pain in the arse, here's some stuff about the Nimbus look and feel.

On the Key Moves, Macros and Special Functions tab, not only is there no gentle highlighting of the text on alternate rows, but the item clicked on disappears! (White on white). I couldn't tell you about the Fav/Scan and Protocols tabs because there is no info on them. (On the tabs with the alternate highlighting, the highlighted text does not disappear!!)

Also, the colour you attempted for the "progress bars" at the bottom as also reversed and become the text colour, which the bar itself shown in orange!

This is all in KDE desktop.
_________________
URC7560/URC7562, URC8910, URC7980, URC6440/OARUSB04G and URC3661

[davecs]