One area where PopTray/PopTrayU is currently less than perfect when it comes to Vista/Win7 functionality is that it stores the poptray.ini file (and other files such as rules and whitelist) in the program files folder with the application. In Vista and above, writing to program files when you’re running normal user applications is a big no no. Those kinds of files are supposed to go in a per-user folder under the users/appdata folder to support multi-user environments, and protect users from malicious applications overwriting things they shouldn’t. It doesn’t make my job as a developer easier, but from a security perspective, it definitely helps cut down on certain opportunities for viruses and trojans to be destructive.
But that leaves me with a dilemma. The old design where everything was in the same folder, and the app doesn’t use the registry makes copying the app to a memory stick to use on other machines (say, internet cafe) with locked down machines pretty easy and doesn’t require an installer. Also makes side-by-side use with PopTray easy, since you can just plop poptrayu.exe in the PopTray folder and go.
But, with Vista/Win7, that model where everything goes in the app folder makes a lot of headaches for users who accidentally ended up with a virtual program files folder and can’t figure out why their changes aren’t “sticking” to poptray.ini or the plugins they are trying to install are suddenly “missing” and they have to approve all these UAC prompts to even install a plugin. Not the best of user experiences.
In order to support Vista/Win7 properly, the default storage location for those files needs to be appdata (aka a user-specific folder). I’ve been debating whether it would be best to keep things simple–now poptray.ini HAS to go in user/appdata/roaming/poptrayu/ unless they specify otherwise by using the command line options to specify the “ini folder”, or whether to come up with some more elaborate scheme such as falling back to the app directory if the user/appdata/roaming/poptrayu/ folder doesn’t exist.
Then, if I change the default storage location, there’s another ball of worms, as far as updating the installer to move/copy the ini file to the new storage location, whether it should import the ini file from poptray and/or poptrayu’s app folder if it’s there, etc.
So, please discuss in the comments, what you think the “right” behavior of the app should be. Do you actually use the use-case where having fall-back folders would be handy, or do you just run the installer and expect it’s going to magically put everything in the right place and you don’t care where it is so long as it works?
Hi Jessica,
First let me thank you for taking on the job of forking the Poptray project and provide some updates that many users have been asking for.
There are now actually up to 5 different locations that, at some point, you may want to support… appending “Poptray” to each of the following locations where applicable
1. User folder aka %APPDATA%
2. All Users folder aka %ALLUSERSPROFILE%
3. The program folder itself ( for example on a USB key etc )
4. A network shared folder
5. A cloud shared folder ( http://… )
The current method used in Poptray as it sits only supports up to 4 of those locations but I added the cloud since that is now also becoming used more and wanted to mention a possible future update.
During the installation process… have the installer ask the user where the files should be held and write it to another INI file in either %ProgramData% or the program file folder itself… This INI then can direct the program where to find the rest of the settings files etc.
Hope that gives you an idea or two for consideration…
That’s an interesting idea to support some format of cloud storage for the file. I’m not sure of all the logistics of how that would work, but if there was enough demand for such a feature, I’d consider looking into it.
I ended up deciding to do something very similar to what you suggested, a prompt in the installer to choose where to store the files. Though, I ended up deciding to store the value in the registry, since the installer already makes keys in the registry for uninstall info, and the ini files aren’t created until first run (which is actually better because then you don’t get files stuck with admin permissions). If the registry key doesn’t exist, it will just use the program folder like it’s always done, so it should work gracefully if a user copies their whole program folder to a usb stick and run it on a different machine without installing. And if a user specifies the command line parameters that will take precedence over the registry setting, so if someone really wanted a custom location, they can still do that just like they did in the past.
Hi Jessica,
I’ve been using Poptray for many years, and I’ve lost hope that it’s development will ever continue. Now I’m very happy and thankful for your Christmas decision to take up the project 🙂
Also, it is great that you have already fixed most annoying lapse in Poptray, as most of emails in my mailbox have a UTF-8 encoded subject.
It is great idea to keep writing a blog about you work – I’ve read all latest posts, which I found very interesting.
Keep up great job, and thank you for all your efforts.
—
Nikola, Croatia
Exact same problem. Been using the ini file for years.
Could I justclarify, have you stopped using the ini file, and all your settings are now stored in the registry, or are you just using the registry to locate the ini file and still storing your settings there.
Patrick
Patrick, to clarify, the registry is just used to locate the ini file, the rest of the settings are still saved in the ini file.
Thanks