Brief summary:
I have a 'suite' of skins that work together as a 'sidebar' of info. I have set a 'trigger' to Fade them all out together, essentially clearing the desktop etc.
Putting Group=skinsuite in the [Rainmeter] section at the top of each skin works to identify all the skins as part of the group and therefore they get 'toggled' by the group action.... or used to...
Having created a couple new smaller additions to the suite recently, and of course constant updating of all the others I seem to have a problem where 3 of the skins won't 'toggle' with the others!
All of the skins are indeed identical in the area of being 'Grouped' as described above. All of the skins also are correct in the Rainmeter.ini, no oddities there... I have even manually edit the Rainmeter.ini to have all the suite skins identical to no avail.
I can 'force' the offending skins to adhere to the groupfade by putting the group assignment in the Rainmeter.ini... but why do some work and some don't as part of the actual skin ini?? As a suite it would of course be advantageous to have the group assignment in the skin... Rather than users having to hard code their Rainmeter.ini.
baffled...
It is currently May 1st, 2024, 10:16 am
FadeToggleGroup issue
-
- Posts: 51
- Joined: September 18th, 2010, 1:03 am
FadeToggleGroup issue
Last edited by fragrant.monkey on December 13th, 2012, 7:28 am, edited 1 time in total.
fragrant.monkey :: deviantArt: aka snuffleupagus | coding: ThemeSaver for RocketDock | musician: Madera Dulce
-
- Developer
- Posts: 1721
- Joined: July 25th, 2009, 4:47 am
Re: FadeToggleGroup issue
It would help to see the code for the offending skins, and the sections in Rainmeter.ini for good measure.
In my experience, the only thing that causes a "Group" option to fail is when it is overridden by an @include file. For example, if you have a skin like this:
then the group option in "Variables.inc" will override the group option in the skin.
In my experience, the only thing that causes a "Group" option to fail is when it is overridden by an @include file. For example, if you have a skin like this:
Code: Select all
[Rainmeter]
Group=TheRightGroup
[Variables]
@include=Variables.inc
Code: Select all
; Variables.inc
[Rainmeter]
Group=TheWrongGroup
-
- Posts: 51
- Joined: September 18th, 2010, 1:03 am
Re: FadeToggleGroup issue
Answering my own question...
I use Notepad++ as my editor, and after all sorts of manipulations to try and find the offending parts of my config or whatever.... I noticed that for some reason that Npp was set to encode text files as UTF-8. hmmmmm....
I converted the file to ANSI and VOILA!!!! the togglefadegroup action problem instantly worked as expected!!
Not that I really understand the variations in text encoding, but for the record, config files encoded in the following formats have the corresponding results:
Now that I have found the issue, a search of the forum brought up some related conversations:
http://rainmeter.net/forum/viewtopic.php?f=14&t=13532&p=77254&hilit=text+encoding#p77254
and
http://rainmeter.net/forum/viewtopic.php?f=5&t=11149&p=63638&hilit=text+encoding#p63638
I use Notepad++ as my editor, and after all sorts of manipulations to try and find the offending parts of my config or whatever.... I noticed that for some reason that Npp was set to encode text files as UTF-8. hmmmmm....
I converted the file to ANSI and VOILA!!!! the togglefadegroup action problem instantly worked as expected!!
Not that I really understand the variations in text encoding, but for the record, config files encoded in the following formats have the corresponding results:
- ANSI - OK
UTF-8 without BOM - OK
UTF-8 - togglefadegroup action doesn't work
UCS-2 Big Endian - config won't even load, no meters or measures recognized by Rainmeter
UCS-2 Little Endian - OK
Now that I have found the issue, a search of the forum brought up some related conversations:
http://rainmeter.net/forum/viewtopic.php?f=14&t=13532&p=77254&hilit=text+encoding#p77254
and
http://rainmeter.net/forum/viewtopic.php?f=5&t=11149&p=63638&hilit=text+encoding#p63638
fragrant.monkey :: deviantArt: aka snuffleupagus | coding: ThemeSaver for RocketDock | musician: Madera Dulce
-
- Developer
- Posts: 2872
- Joined: April 17th, 2009, 12:18 pm
File encodings
There is no such encoding as ANSI. It is simply a generic name representing the default character encoding (or code page) of your Windows system. If you live in Western Europe, your default character encoding is likely to be Windows-1252 (i.e. Latin). If you live in Russia, your default character encoding will probably be Windows-1251 (i.e. Cyrillic).
All the character sets represented by ANSI are thus dependent on the default encoding of your system. All these ANSI encodings, however, share a common subset: ASCII. If you use characters only in the ASCII subset (e.g. 0-9, a-z, A-Z), your skin will look the same everywhere. If you happen to use characters that are not in the ASCII subset (e.g. Ä or ü or º in Windows-1252), your skin will look different depending on where it is used. For example, if you use the degree symbol º available in the Windows-1252 encoding, it will show up as ŗ for a user in the Baltic region (Windows-1257).
To fix this hideous mess, Unicode was invented and with it came encodings such as UTF-8, UTF-16, and UTF-32. UCS-2 is an older encoding and has been superseded by UTF-16 (Notepad++ probably means UTF-16, but mistakenly uses the wrong name). UTF-32 is always 4 bytes per character, UTF-16 is at least 2 bytes per character, and UTF-8 is at least 1 byte per character. Additionally, UTF-16 and UTF-32 come in a few flavors (BE, LE, unmaked), which controls how the bytes are ordered. All of them can use the entire Unicode range regardless of the system character encoding.
Rainmeter only works with the system character encoding (i.e. ANSI) and UTF-16 LE (or UCS-2 LE). If you only use the ASCII subset, you're fine with ANSI. Otherwise you should use UTF-16 LE (especially if you plan on distributing your skin).
(You may be wondering why UTF-8 without BOM worked. It is because text files consisting of only ASCII characters are identical in UTF-8 w/o BOM and ANSI. If you use characters outside of ASCII, you will get unexpected results when using UTF-8 with Rainmeter.)
All the character sets represented by ANSI are thus dependent on the default encoding of your system. All these ANSI encodings, however, share a common subset: ASCII. If you use characters only in the ASCII subset (e.g. 0-9, a-z, A-Z), your skin will look the same everywhere. If you happen to use characters that are not in the ASCII subset (e.g. Ä or ü or º in Windows-1252), your skin will look different depending on where it is used. For example, if you use the degree symbol º available in the Windows-1252 encoding, it will show up as ŗ for a user in the Baltic region (Windows-1257).
To fix this hideous mess, Unicode was invented and with it came encodings such as UTF-8, UTF-16, and UTF-32. UCS-2 is an older encoding and has been superseded by UTF-16 (Notepad++ probably means UTF-16, but mistakenly uses the wrong name). UTF-32 is always 4 bytes per character, UTF-16 is at least 2 bytes per character, and UTF-8 is at least 1 byte per character. Additionally, UTF-16 and UTF-32 come in a few flavors (BE, LE, unmaked), which controls how the bytes are ordered. All of them can use the entire Unicode range regardless of the system character encoding.
Rainmeter only works with the system character encoding (i.e. ANSI) and UTF-16 LE (or UCS-2 LE). If you only use the ASCII subset, you're fine with ANSI. Otherwise you should use UTF-16 LE (especially if you plan on distributing your skin).
(You may be wondering why UTF-8 without BOM worked. It is because text files consisting of only ASCII characters are identical in UTF-8 w/o BOM and ANSI. If you use characters outside of ASCII, you will get unexpected results when using UTF-8 with Rainmeter.)
-
- Posts: 51
- Joined: September 18th, 2010, 1:03 am
Re: FadeToggleGroup issue
Thanks ever so much for the thorough explanaition poiru!
So, I would grok that utf-16 (ucs-2) would be the best choice for config files then. Both for possible extended character usage, as well as worldwide compatibility for any skins that are planned to be distributed.
But, I still ponder why the encoding type would work in every respect, except cause the togglefadegroup action to fail....
No non-ascii characters in use in the group 'name'...
Two of the skins did use a 'block' character as a graphic element text=■. This code actually resides in the variables.inc file, but even with this commented out, or the whole .inc file commented out, the skin still failed to 'fade'.
The third skin that didn't work is an audio player (nowplaying using iTunes). It contains no non-ascii characters at all. Perhaps usage of a plugin caused some weirdness in this encoding scheme?
I've confirmed that the .inc file itself was already encoded ucs-2 LE by testing that 'block' character.
weirdness...
Regardless, thanks again for the info. cheers!
So, I would grok that utf-16 (ucs-2) would be the best choice for config files then. Both for possible extended character usage, as well as worldwide compatibility for any skins that are planned to be distributed.
But, I still ponder why the encoding type would work in every respect, except cause the togglefadegroup action to fail....
No non-ascii characters in use in the group 'name'...
Two of the skins did use a 'block' character as a graphic element text=■. This code actually resides in the variables.inc file, but even with this commented out, or the whole .inc file commented out, the skin still failed to 'fade'.
The third skin that didn't work is an audio player (nowplaying using iTunes). It contains no non-ascii characters at all. Perhaps usage of a plugin caused some weirdness in this encoding scheme?
I've confirmed that the .inc file itself was already encoded ucs-2 LE by testing that 'block' character.
weirdness...
Regardless, thanks again for the info. cheers!
fragrant.monkey :: deviantArt: aka snuffleupagus | coding: ThemeSaver for RocketDock | musician: Madera Dulce
-
- Developer
- Posts: 2872
- Joined: April 17th, 2009, 12:18 pm
Re: FadeToggleGroup issue
Because of the UTF-8 BOM at the beginning of the file (i.e. "first line"). Since UTF-8 is not supported, Rainmeter treats the BOM bytes as characters. In your case, instead of [Rainmeter] as the first line, Rainmeter sees [Rainmeter]. This is not valid INI syntax and thus everything until the next valid section is skipped.fragrant.monkey wrote:But, I still ponder why the encoding type would work in every respect, except cause the togglefadegroup action to fail...
-
- Posts: 51
- Joined: September 18th, 2010, 1:03 am
Re: FadeToggleGroup issue
Wow... that makes total sense since the group assignment is in that first section...poiru wrote:In your case, instead of [Rainmeter] as the first line, Rainmeter sees [Rainmeter]. This is not valid INI syntax and thus everything until the next valid section is skipped.
Thanks again!
fragrant.monkey :: deviantArt: aka snuffleupagus | coding: ThemeSaver for RocketDock | musician: Madera Dulce