About a week ago, I uploaded the first completed beta version of PopTrayU up onto Sourceforge. I sent a link to Renier to test/comment, and he sent me back some comments about some bugs–mostly minor stuff to fix, like an incorrect link to the help file. But a couple are bigger/trickier issues.
In particular, one is the issues with storing user-editable files in Program Files under Vista/Win7… well, you can, but it can cause quirky issues, like “virtual”/duplicate files to be created depending on the security settings, and that can cause it to look like there’s bugs in the app when there isn’t. On the one hand, having everything in the app’s directory is nice because you can run it off a memory stick with no installing required, on the other…well, trying to cooperate better with the OS can be a boon and not confuse users… 😉
I’m still contemplating the best way to fix that. How should the app decide where the default ini file storage goes? Should it always be in the appdata/user folder? Should it look in the user folder and if that folder doesn’t exist, fall back to the app folder? Use a registry key to store where the config files are? Make the ini file only have one line that points to the location of the “real” config file.
This problem doesn’t stop at just an ini file though. (and as an aside I’m not going to get into the holy war about “outdated” ini files vs “non-portable” registry entries at the moment), For PopTrayU, files the user might be more interested in editing than an INI file (no need to edit that one manually) would be to install plugins, sounds, or the skin files. So ideally, that should be in a user writable folder without needing to use UAC dialogs or administrator permissions, so not in program files. Maybe I need to explore how other open source software that have similar support files (Miranda IM comes to mind) have dealt with changes to OS restrictions on newer versions of Windows.
The second bigger one is a bug more than a design issue. Use the SSL plugin to connect to Gmail, and bam, get an access violation memory error. I was actually able to reproduce this the first time I set up my gmail account and accessed it. But then I turned break on exceptions back on and restarted the app, and it wouldn’t reproduce anymore, and additional testing of using my gmail account since has not reproduced the issue. So this one is going to be tricky to fix because I’m not sure what causes it. I guess I’ll have to keep my eyes out for additional hints on what factors are necessary to reproduce the bug.
Today I got an email from a sourceforge user thanking me for continuing the development of PopTray and letting me know about an issue the user was having with custom sound notifications, an area I haven’t thoroughly tested (nor made changes to). You mean people are actually using and finding my app even though I haven’t done a lick of promotion (aside from creating it’s sourceforge page) yet? Awesome. I kind of purposely haven’t been promoting the site yet, as I’d rather have bugs trickle in than flood in, so I have time to look at them and fix them rather than just queuing piles of duplicate bugs. That’s why you do beta versions, right? You want enough exposure to find the bugs, but not so much that you’re overwhelmed with duplicated feedback.