The second beta of slimKEYS 1.1.3 is now available for download. With this last beta before the release, I urgently need Vista testers. If you look at the list of changes, you can see a few pending or new Vista features.
slimVOLUME
Two main things have changed with the slimVOLUME plug-in. First, the window display was redone completely, to use a true transparent window. The previous version copied an image of what was underneath the volume window, and drew on that image. Less than beautiful when you happened to Alt-Tab while the volume was still displayed or when the content was changing (ex: watching a video or movie). If you play games not in full screen mode, this new display will also work correctly. The "label style" is not implemented yet, so you'll get TV-like bars in both settings.
The second big change is the use of the new Vista API for changing the main volume control. The previous version did not work on Vista, since all it did was change the volume of the sounds slimKEYS played... which is none! This needs to be tested more thoroughly by Vista users. For example, there is one known issue: if you change the output device, for example by plugging-in your USB headset, slimVOLUME won't notice, and will continue to change the previous device's volume. That will be fixed in the official release, I'm just waiting for some final information.
So, mandate #1: Test slimVOLUME on Vista.
slimSIZE
If you are using slimSIZE on Vista, you already know it cannot move windows that belong to either isolated or elevated applications. Maybe you did not know what was the reason it could not move all windows. Now you know! This a Vista security feature. Applications like Internet Explorer 7, run in a special isolated mode, which prevents it from accessing all Windows features, and as a side effect, prevents other applications from accessing the IE7 process as much as they'd like. Other example, if you are a Visual Studio .NET 2005 user under Vista, you must be running it as administrator. Such applications and their windows cannot be the target of window APIs either.
Fortunately, this Vista security feature can be "safely" circumvented. The recipe isn't obvious, but it works (except*). If your application embeds a specially crafted manifest that includes a "uiAccess=true" entry, is digitally signed, and runs from the "Program Files" folder, it can target windows that belong to isolated or elevated processes. If it does not run from the "Program Files" folder, it can still target isolated applications, but not elevated ones.
(*): With Microsoft, it could not be that easy. This miracle recipe is giving me one small headache: When slimKEYS is started from a StartUp shortcut (as it's the case almost 100% of the time), launching URLs takes an eternity when either FireFox or Opera is your default browser**. If launching other applications, those apps become sluggish and slow. At least, that's what I am experiencing on my machine. I made a small WinForms application with a similar manifest, strong name and digital signature, and a simple button that calls System.Diagnostics.Process.Start with an URL. If that application is started from a StartUp shortcut, clicking on the button takes 10 seconds for FireFox to open, and more than 2 minutes for Opera to open. But the same application, launched from the Windows Explorer, works perfectly, as does slimKEYS. If I remove the manifest, the problem also disappears (but you can't target isolated or elevated apps anymore).
I have posted on the MSDN forums and Microsoft newsgroups, but I am getting no answer. That's where more testers are required. If I can get more information about this, I'll be able to challenge MS better. If I get enough feedback, I may also choose to spend money on opening an MS support case. For the moment, I officially can't since I'm using an OEM license of Vista, and I'm not an MSDN subscriber.
Mandate #2: Tell me if slimSEARCH or slimLAUNCH.Delicious are slow to open web pages.
Mandate #3: Tell me if applications open from slimLAUNCH look more sluggish or slower than usual, or if they happen to open web addresses themselves, cause the same problem as mandate #2.
(**): I'll give a free slimKEYS license to the first person who can explain within a week from now why there is no delay when Internet Explorer 7 is your default browser. I'll give the answer later.
slimLAUNCH
A limited implementation of verb support is now available in slimLAUNCH. If you browse for an application or document to open, and press Ctrl-Enter to open the extended launch options, you will see a new "Verb" field at the bottom. Default verbs for the selected application are available in the drop-down list, and you can type in the verb of your choice. For example, typing "runas" will open that application as administrator. The last verb is remembered, but only used when pressing Ctrl-Enter.
Mandate #4: Test a few verbs, test the "runas" verb, give comments about how this can be improved.
slimSMOKE
The rest of the changes are fixes or featurettes, except for the new slimSMOKE plug-in. I'm using that plug-in full-time now, and have been enjoining it a lot. But I'm still waiting for other users' feedback. This second beta can also highlight not only the active window, but also all top-level windows which belong to the same process. Here are a few screenshots of (a part of) my desktop with slimSMOKE active. You can see the active application much easily.
You think you could like this? Mandate #5: Test slimSMOKE and give me your impressions!