Store data to the user's folder

[GoogleCodeExporter]

The settings and skins should be moved to the %APPDATA% folder so that they
can be edited without admin privileges and that different users can have
different settings.

Original issue reported on code.google.com by kimmo.pekkola on 14 Feb 2009 at 8:56

[GoogleCodeExporter]

I almost agree with you.
But I have at least one of worries about compatibility with a traditional skins.
A rare case, if there is any settings relevant to 'Rainmeter.EXE', the skin 
will not
work any longer.

Original comment by kenz0.sa...@gmail.com on 15 Feb 2009 at 3:35

[GoogleCodeExporter]

I vote against this.

I use Rainmeter portably off of a flash drive. Saving settings out of the app's
directory breaks portability. Maybe you could tell users to copy Rainmeter to 
their
profile folders if they wish to use it in a multi-user setup.

Original comment by JMHarris...@gmail.com on 8 Mar 2009 at 7:51

[GoogleCodeExporter]

The new system would be used for new installations only. If the rainmeter.ini 
file
can be found from the program folder it will be used always so everything would 
work
as before. You could also make a new installation portable just by creating an 
empty
rainmeter.ini file to the program folder.

The reason for this change is that Windows Vista doesn't allow programs to make
changes to the program folder anymore. It will transfer the files automatically 
to
the virtual store which most people cannot find and it might even lead to a 
situation
where there are two versions of the rainmeter.ini file in the user's system.

Original comment by kimmo.pekkola on 10 Mar 2009 at 4:50

[GoogleCodeExporter]

I see. Good job then. Thanks so much Rainy.

Original comment by JMHarris...@gmail.com on 10 Mar 2009 at 8:22

[GoogleCodeExporter]

Perhaps Rainmeter could look for its config/skins/plugins in both places: in the
program's directory under %ProgramFiles%, or under %AppData%. Then the 
installer can
be modified to install these files under %AppData% (or %ProgramData%, but that 
may be
Vista-specific) instead of %ProgramFiles%.

Original comment by rcs...@gmail.com on 17 Mar 2009 at 8:34

[GoogleCodeExporter]

Original comment by brian.to...@gmail.com on 16 Apr 2009 at 6:28

[GoogleCodeExporter]

Thx a lot 4ur nice sharing Bro'...
Btw would u mind to teach me how to change the black/white letters+sign to 
Red/Yellow?
Wishing u all d'best & have a nice day.

Original comment by del...@gmail.com on 20 Apr 2009 at 1:50

[GoogleCodeExporter]

This is really going to have to be addressed soon. As more folks move to Windows
Seven this is going to rear its ugly head more and more often.  As I said in the
forums, the only reason this hasn't killed Rainmeter so far is that 50% of the 
kind
of people that use Rainmeter turn off UAC, and the other 50% are still on XP.

What it comes down to is:

Vista and Windows Seven have instituted a new security measure called User 
Account
Control (UAC) which seeks to protect the system from tampering by external
applications (virus, malware etc.) One of the things UAC does is protect the 
"Program
Files" folder from being written to by applications after they are installed.  
The
application can be installed, with the user agreeing to the installation via a 
UAC
prompt, but then the program is protected from modification unless done by a 
human.
(uninstalling, deleting, editing, renaming etc. - all can be done, but will 
generate
a UAC prompt) The entire "Program Files" folder is in effect off limits unless 
the
user turns off UAC.

Program are expected to keep files which they need to write to in:

C:\Users\username\AppData\Local\appname

or

C:\Users\username\AppData\Remote\appname

************
NOTE: This was also true in XP, with the folder name

C:\Documents and Settings\username\Applicaton Data\appname

however this was not enforced in any way in XP, and was ignored by many if not 
most
application authors.
************

The effect of this is that if people run Windows Vista or Seven as configured 
out of
the box (with UAC on) then Rainmeter is unable to save any settings to the
rainmeter.ini file and although the application will run, it won't load any 
skins or
save any of the changes the application wants to make to rainmeter.ini (position
settings, active skins, etc.)  You can load a skin via the context menu, but 
the next
time you stop and start Rainmeter it has "forgotten" anything you did.

The next major version of Rainmeter should be made to obey these rules for
applications, or we are going to see increasing numbers of folks with issues as 
more
and more people move to Windows Seven. (either by upgrading or when they buy a 
new PC)

Original comment by jsmor...@gmail.com on 4 May 2009 at 1:32

[GoogleCodeExporter]

Off the top of my head, I would think this approach might work:

1) There should be a rainmeter.ini setting (changeable by the user) to point to 
where
the "data" for the application is. This by default should be
"%APPDATA%\Local\Rainmeter", but for those (like the guy here) who want to run a
"portable" version could remove this line and it would then default to the 
current
directory the app was run from.

Something like DataFolder="%APPDATA%\Local\Rainmeter"

2) The context menu and the app itself would need to be made aware of and obey 
the
setting in "DataFolder="

Original comment by jsmor...@gmail.com on 4 May 2009 at 1:47

[GoogleCodeExporter]

Re: Comment 9.
The problem is, ranimeter.ini should be in "%APPDATA%\Local\Rainmeter", so in 
order
to locate rainmeter.ini, Rainmeter would need to read rainmeter.ini
It's kind of like a chicken-and-egg problem.

No, the location of the "data" files is %LOCALAPPDATA%\Rainmeter; Rainmeter 
should
use SHGetFolderPath(0, CSIDL_LOCALAPPDATA,....) to fetch the path of 
%LOCALAPPDATA%
and append "Rainmeter". 
The ProgramFiles\Rainmeter location should be used for backwards compatibility. 
The
question is, which place should new Rainmeter check first (old Rainmeter checks 
in
ProgramFiles only).

If it checks LocalAppdata and then ProgramFiles, then after an upgrade the new
Rainmeter will ignore the existing settings, unless the installer migrates
rainmeter.ini to LocalAppdata.

If it checks ProgramFiles and then LocalAppdata, then an upgrade will 
automagically
use the existing settings. The installer should still be aware of this 
situation and
not write a rainmeter.ini to LocalAppdata, to avoid confusing the user ("I'm 
editing
the ini and nothing happens"). 

In my opinion, the first variant is more desirable, because it will move 
Rainmeter
towards Vista-compliance.

Then there's the problem with the skins, which are all modifiable and should go 
under
LocalAppdata. The installer should perform the migration (taking care not to
overwrite the user's customizations).

Original comment by rcs...@gmail.com on 5 May 2009 at 11:16

[GoogleCodeExporter]

#10

I agree...

Original comment by jsmor...@gmail.com on 5 May 2009 at 6:33

[GoogleCodeExporter]

Of course then there is the issue that %APPDATA% is by default "hidden" in
Vista/Seven.  So the average user is either going to have to depend on skin 
authors
to create some kind of install package which puts things in the right place, or 
there
needs to be a "skin import" capability in Rainmeter (I lean toward 2, as 1 is
unlikely).  For the power user, they can of course unhide %APPDATA% and do as 
they
like, but there needs to be some facility for the average user.

Original comment by jsmor...@gmail.com on 5 May 2009 at 8:01

[GoogleCodeExporter]

An "open skins" folder would be some what effective in off setting the hidden 
file.

Of course this will then crossover with issue #52; updating the context menu.

To address the issue of working several installer to appease the XP, Vista 32 & 
64,
and the 7.

I would propose one installer with all the needed parts, with a built in 
directory to
appoint to where, depending on OS build the files need to go.

NSIS (Nullsoft Scriptable Install System)
http://nsis.sourceforge.net/Main_Page

With this installer, it looks as though it can be manipulated to install 
packages
where they need to go based on what you instruct the installer. In this case 
you can
instruct a series of commands for rainmeter package placement, based on 
selection of
xp/2000, Vista 32 or 64, and 7 32 or 64

Not to mention it can be GUI'ed up to the Rainmeter schema

If nothing else this would answer the above about separate installers.
Forget that; just one, with everything in it, and the installer with extra 
files can
be deleted after install, so size of the installer is not a consideration.

Nullsoft installer is also open-source (Freeware), and could potentially be 
used by
the skinners to create multi-platform installs.

Nullsoft is drop dead reliable, and I have switched over from a paid installer 
in
just the last couple of days.

For example of how stable Nullsoft installer is, I sight Winamp, which has used
Nullsoft Installer for years religiously.

Original comment by evmckay on 5 May 2009 at 8:33

[GoogleCodeExporter]

I believe Rainmeter checks it's own directory NOT ProgramFiles\Rainmeter\ so no
matter where it is run from it finds the ini in it's own directory. For Vista/7
compatibility all that is needed is to have it check LocalAppData\Rainmeter if 
it
does not find the ini in it's own directory.

The ini in it's own directory thing is what allows us to easily use Rainmeter 
portably.

Original comment by JMHarris...@gmail.com on 6 May 2009 at 1:10

[GoogleCodeExporter]

Ok.

Now I must ask the question; What is the differences in stall and access 
between the
32 bit and the 64 bit enviro?

I have notices that the untested downloads are all 32 bit.

Is there a way that the uncompressed installer (unpackaged by say 7zip), can be
manually installed, or is there a 64 bit "thing" that I am unaware of.

I have noticed in my limited use of Vista 64 that there is a Program files, and 
a
program files (x86).
Would it just be a matter of unpackaging and installing Rainmeter to the Program
Files (x86) folder?
Possibly even placing the necessary AppData files into that folder.

If so what are the other issues involved with doing so?

At this time the XP virtual machine for Windows 7 is a bomb, so I think that 
solution
is out in the immdeiate future, and I am unaware at this time if the Windows 7 
OS has
a Program Files (x86)

Original comment by evmckay on 6 May 2009 at 4:47

[GoogleCodeExporter]

This change was added in r86

Original comment by kenz0.sa...@gmail.com on 22 Jul 2009 at 10:09

• Changed state: Fixed