Archive: Aero plug-in


Aero plug-in
http://nsis.sourceforge.net/mediawik.../a/ad/Aero.png

Enables Windows Aero glass effect on NSIS (outer) UI.

http://nsis.sf.net/File:Aero.zip

Edit: Worth noting this plug-in does nothing on < Vista or when DWM composition (glass) is disabled on installer init. The plug-in handles theme changes once it has been loaded (i.e. reverts to original UI if glass is disabled).

Stu


Looks very nice indeed, thanks for sharing!


hah, funny I will try it!


nice plug-in, thank you very much!


I made a plugin similar to this a while back but I never got around to posting it since I could not find a documented value to use for the text glow size. Did you just make one up or what?

I guess I don't have to complete my version now, thanks Afrow =)


Just used 10. You can actually get the glow size from the current theme using another API so I may change it.

I've had a report of the button text being transparent on one or two machines which doesn't seem to happen on any of mine so I might need to fix that soon. When you use the branding text with glow, it has to paint a black brush where the aero is but that results in the button text being transparent too (looks awful) and therefore I've had to do some simple button drawing myself (using WM_PAINTCLIENT). To fix the button text at the moment I'm just using WM_PAINTCLIENT onto the current DC's HBRUSH (this seems to work fine for me - but I don't really know why lol). However, I may have to use double buffering (BeginBufferedPaint) with a portion with full opacity (BufferedPaintSetAlpha) to fix properly. Will post new version today probably. Other option is owner draw the buttons but I want to avoid that. I'd rather let Windows do it for me (WM_PAINTCLIENT).

Stu


New version uploaded which uses the glow size for the current theme and fixes the button text transparency bug on some systems.

FYI to get the glow size (12 by default) you use GetThemeInt with TMT_TEXTGLOWSIZE. The theme I used is "CompositedWindow::Window".

Probably worth mentioning also that if you use /nobranding then because the plug-in does not need to draw any glow text, it doesn't need to use a black brush for the aero (I use magic pink instead with SetLayeredWindowAttributes/LWA_COLORKEY). As a result, the buttons are untouched and therefore you get the proper button glow fade in/out on mouse in/out. Owner-drawn or WM_PAINT handled buttons lose this fade in/out unfortunately and there's nothing one can do about it. Even .NET apps loses this effect if you set UseCompatibleTextRendering=true for buttons. The missing effect is not noticeable though (unless you're me lol) so branding text is on by default :).

Stu


Is SetLayeredWindowAttributes + DwmExtendFrameIntoClientArea a valid thing to do? IIRC SetLayeredWindowAttributes had problems with the DWM in the early Vista days.


You are using "CompositedWindow::Window" when loading and "Window" in WM_THEMECHANGED, this can't be correct can it?


Also, you are hard-coding a 2px change in what I assume is some sort of button border hack? What about alternative Visual Styles?


Originally posted by Anders
Is SetLayeredWindowAttributes + DwmExtendFrameIntoClientArea a valid thing to do? IIRC SetLayeredWindowAttributes had problems with the DWM in the early Vista days.


You are using "CompositedWindow::Window" when loading and "Window" in WM_THEMECHANGED, this can't be correct can it?


Also, you are hard-coding a 2px change in what I assume is some sort of button border hack? What about alternative Visual Styles?
1. I've tested on Vista and it seems to work OK. Maybe I shouldn't bother though and just go with the black brush method. Both methods are written about by Microsoft developers though IIRC.

2. Well spotted. Will fix.

3. Yes. I'm having to set the inner part of the button to opaque to fix the black->transparent button text. I originally used 4px but 2px seems to be the minimum. I never thought of other themes. Not sure if there is a better way to do this without having to draw the button myself. Any ideas?

Stu

In my plugin I use one of the theme api's to calculate the size of the button IIRC

Also, you are destroying windows you don't own, this is not OK IMHO (In my Aero plugin I hide them and if aero is turned off, I display them again, 100% original layout in classic theme...)

As a final note; I don't really think "_WndProc_" is the best prop name to use, it is a bit generic, I'm using "NSIS:P:Aero", feel free to using something similar (or the same, both plugins should not be used at the same time anyway)


So is that how your plug-in does the buttons too or does it owner-draw them?

Stu


Originally posted by Afrow UK
So is that how your plug-in does the buttons too or does it owner-draw them?
I use subclassing and WM_PRINT?CLIENT? like you do, but I use one of the GetThemeBackgroundSomething functions to calculate the area to mask off for the round corners.

I was going to look into adding the animation back but got bored and stopped working on the plugin...

Is it GetThemeBackgroundRegion? How would that be used with BufferedPaintSetAlpha which requires a RECT?

Stu


I'm thinking it was GetThemeBackgroundContentRect

But you should be able to get a RECT from HRGN also...

Or you can use the HRGN to mask off the HDC...


So far so good although I've just remembered why I had to destroy those controls instead of hiding them (at least for MUI). MUI hides/shows them itself when you enter/leave the welcome/finish pages. How did you overcome this or did you not notice this problem?

Stu


I probably re-hide them on every page change...


In response to WM_NOTIFY_OUTER_NEXT? It seems that the show function gets called after that notification and so my attempts fail. Calling the old window procedure first also doesn't seem to work. I guess one option, which would also avoid any potential flickering of the controls being shown/hidden, would be to move them off the UI on plug-in load while saving their original positions...

Stu


here's what happens when defining MUI_BGCOLOR (mind the background of those buttons)


I'll look into it thanks.

Stu


New plug-in version (.2) uploaded. Still waiting for Yathosho to check his button issue is fixed though (but I can't seem to reproduce so perhaps it is fixed).

Fair number of changes/fixes:

1.0.0.2 - 4th May 2011
* Fixed typo Window -> CompositedWindow::Window in WM_THEMECHANGED
(thanks Anders).
* Now uses theme text colour for branding text (but still original
font).
* Improved fall-back drawing if DWM composition is disabled (all drawing
then handled by Windows/NSIS).
* Now re-shows old branding text and horizontal ruler when DWM
composition is disabled.
* Plug-in now loads even if DWM composition is disabled, but could be
enabled.
* Now only handles WM_CTLCOLORBTN for the Back, Next and Cancel buttons.
* Now uses GetThemeBackgroundContentRect to determine the button area
to draw opaque.
Stu

Edit: Oh and I changed the button property names to _StuAeroWndProc_ :)

Feedback for others:
http://www.ijeffio.com/nsis/Aero%20plug-in.jpg

Chinese charactor didn't display when using this plug-in.


@jiake: Did you use Unicode NSIS?
I assume ANSI NSIS cannot display them correctly.


I have not used the plugin yet, for I am still using Windows XP.
The problem was found by other person, he lets me to feedback.


Currently using MultiByteToWideChar in the ANSI plug-in (DrawThemeTextEx is Unicode only) so this is likely the problem. I will change the code to avoid it when I have time (i.e. call GetWindowTextW).

Stu


New version uploaded which should fix your Chinese characters bug (I hope).

1.0.0.3 - 19th May 2011
* Now always uses GetWindowTextW for the branding text (as DrawThemeTextEx is Unicode only).
Stu

New version:

* Fixed transparent button text in some situations for Next/Back/Cancel buttons.
http://nsis.sourceforge.net/File:Aero.zip

Stu

no longer got that problem with the latest build


Originally posted by Afrow UK
* Fixed transparent button text in some situations for Next/Back/Cancel buttons.
did anybody say transparency?

@Yathosho: MUI2 contains two dialogs: outer [which is transparent] and inner dialog [that grey area]
There is probably som problem with inner dialog transparency...


I'm not sure what you are trying to do but you can't mix Aero with Windows controls without owner drawing them. I had to draw the navigation buttons myself to fix the transparency issue (and it still wasn't perfect until the last release). The problem is that the transparency key is black (and it has to be) and so all black objects (text etc.) will be rendered transparent.

Stu


Originally posted by Afrow UK
I'm not sure what you are trying to do but you can't mix Aero with Windows controls without owner drawing them. I had to draw the navigation buttons myself to fix the transparency issue (and it still wasn't perfect until the last release). The problem is that the transparency key is black (and it has to be) and so all black objects (text etc.) will be rendered transparent.

Stu
this made the difference, not the colors
#old code
ShowWindow $HWNDPARENT 2
BringToFront
Aero::Apply ;causes infrequent crashes

#new code
Aero::Apply ;causes infrequent crashes
ShowWindow $HWNDPARENT 2
BringToFront

Just noticed this plug-in. Great stuff. Thanks for sharing :)


I haven't experienced any crashes. Please can you post a script which reproduces the problem.

Edit: and what is the minimize and bring to front for?

Stu


Branding text on WelcomeFinish page
First of all I would like to give you a big :up: for the great work you have made with this plugin.

And my question :) is ...
The branding text is displayed on WelcomeFinish page when Aero is activated; when Aero is deactivated, the branding text is hidden. I'm used to not have this branding text on the first and last page. Did you intend to have this branding text displayed while Aero is activated or it's a bug? Is there a way to not have it displayed on first&last page?

Thanks
Isawen


At the moment the branding text is either drawn or it isn't. It's not a static text control, it is simply drawn where the original static text used to be. Because of this, MUI does not hide/show it. I will fix it when I have time.

Stu


Originally posted by Afrow UK
Edit: and what is the minimize and bring to front for?

Stu
I'm guessing this fixes some kind of drawing bug...

1.0.0.5 - 9th July 2011
* Branding text now hidden when branding text static text control is hidden.
Stu

Is there any chance to have the branding text centered in "classic" UI?

http://img804.imageshack.us/img804/1...0711221736.png


Possibly but keep in mind there's a hidden Back button there so even if I do centre it it won't be centred in between Cancel and Close. The original branding text isn't centred IIRC it just happens to fit nicely for classic UI (when you have all 3 buttons).

Edit: It is in fact but still only centred between the 3 buttons.

Stu


Originally posted by Afrow UK
Possibly but keep in mind there's a hidden Back button there so even if I do centre it it won't be centred in between Cancel and Close. The original branding text isn't centred IIRC it just happens to fit nicely for classic UI (when you have all 3 buttons).

Edit: It is in fact but still only centred between the 3 buttons.

Stu
Yup, I know it's centered between the three buttons and still wouldn't be perfectly centered with only two buttons visible. Anyway, I think it looks better than glued to the left button. Also moving the buttons down by a few pixels wouldn't hurt (if possible).

Thanks :)

Archive: Aero plug-in


1.0.0.6 - 12th July 2011
* Fixed branding text not re-showing on DWM disable and re-enable.
* Centred branding text for classic UI.
* Nudged buttons down by 3 pixels for classic UI.
Night :)

Stu

Originally posted by Afrow UK
Night :)

Stu
Great :up:

not sure if it's just me (again?), but the glow effect on the left border seems cut off.


That's odd I don't get that. Are you using a modified UI? It uses the same left coordinate that the original branding text is which is 5 dialog units from the left according to Resource Hacker (modern.exe).

Stu


nope, using mui2. no special windows theme or alternate shell either, i tested the win7 standard theme as well. get the same when compiling Examples\makensis.nsi with added aero plugin.


Is that the latest plug-in version? You shouldn't have any branding text on the welcome/finish pages.

Stu


Just a side note:

With a none standard DPI setting (i.e. other than "96 dpi" aka "100%"), there is a strange border with Aero plug-in enabled.


Originally posted by Afrow UK
Is that the latest plug-in version? You shouldn't have any branding text on the welcome/finish pages.

Stu
true, i didn't use the latest version. i recompiled and there's no branding on the welcome page. can't say if anything else changed as i'm logged in via RDP (no aero!), will do so when i get home.

the branding text is no longer cut off when using the latest version!


Branding text overlapped by the Back button
Stu, if you set a big text for the branding text you should see that it's overlapped by the Back button.


I just started experimenting with this plugin. It looks good, but I found one oddity. If a link is added to the finish page, the text color of the link changes to black with a black line below and a black block to the right.
http://www.sierrahelp.com/Temp/Aero.png


This is known bug - it is the same thing which Checkbox/Radiobuttons suffer too.
I use XPStyle off to remove this behaviour, but maybe Stu will know what to change in sources to remove it completely.


MUI2? This isn't the same as checkboxes/radiobuttons. Static texts should not have this problem, although a link may do (which is a static text with added effects) but that depends on the code behind it.

Stu


Strange. No such problem here:
http://img443.imageshack.us/img443/1...l1build76n.png


Yeah that's why I think he might be using MUI1.

Stu


It is MUI2. I am using MUI_FINISHPAGE_LINK and MUI_FINISHPAGE_LINK_LOCATION for the finish page link.


Me too... :confused:


I just tried adding the MUI_FINISHPAGE_LINK and MUI_FINISHPAGE_LINK_LOCATION to the "Aero ModernUI.nsi" example included with the plug in and got the same results. I had the logging build of NSIS, so to be sure that it was not something odd with it, I compiled the script with the normal ANSI NSIS 2.46 and still got the same results with both my script and the example with the finish page link added. My machine is Win7 x64 Pro, if that might make any difference.


I always use Unicode NSIS, if that matters.


I have been putting off installing Unicode NSIS. Perhaps I'll give it a try to see if it fixes it.


I am using non Unicode NSIS and I do not have the problem (Windows 7 Professional x64). Please can you write a minimal script that reproduces the problem.

Stu


have you set custom colors for any element in your script? i had similiar problems when using a custom header background color, though i think the problem disappeared in a later version


Unicode did not help. It happens even with the included example if I add a finish page link:

!include MUI2.nsh

OutFile TestModernUI.exe
RequestExecutionLevel user

!define MUI_CUSTOMFUNCTION_GUIINIT onGUIInit
!insertmacro MUI_PAGE_WELCOME
!insertmacro MUI_PAGE_LICENSE ModernUI.nsi
!insertmacro MUI_PAGE_INSTFILES
!define MUI_FINISHPAGE_LINK "Click here to find more New Sierra Game Installers"
!define MUI_FINISHPAGE_LINK_LOCATION "http://www.sierrahelp.com/Patches-Updates/NewSierraInstallers.html"
!insertmacro MUI_PAGE_FINISH

!insertmacro MUI_LANGUAGE English

Function onGUIInit

Aero::Apply

FunctionEnd

Section
SectionEnd
I am not using any custom themes on my system.

Looks fine for me :(.

Stu


I'm not sure what's happened to my post. How many more of my posts have to be approved before I can just post?


Collector9999: Which exact version of windows is this? Win7 SP0 x86? Could you create an extra label and set the color on it (and maybe transparent background) and see what happens?

Afrow: Is it possible that you are doing a black FillRect or not restoring a HDC or something like that? The problem could be in the link control also of course, a dev needs to reproduce the issue before we can board the blame train :)


My PC is Win7 x64 Pro SP1. I am not sure what you mean with the extra label.


OK, I figured out what you meant, but I am not sure how to set a transparent background. It also has the black at the side of the new link.


When the Aero plugins is enabled it will not let me change the color of the link. It is always black. I can change the color of an extra link, even though it also has the same black block.


I had a number of people test a build of the above script compiled with a clean installation of NSIS with only the Aero plugin added and they got the same result. So the issue is not with how my system displays it nor in any customizations of NSIS.


Sorry for the multiple posts, but I have solved the problem. I got the plugin from the Wiki but I had an earlier build. Updating it to the latest fixed it.


Hi. Is it intended to work also with UMUI?
http://imageshack.us/photo/my-images/94/umuiaero.jpg/


I have not tested it with UMUI nor do I use it so no.

Stu


Have You seen screenshot? IS it somehow fixable or not?

If not, is that easy to move from UMUI to MUI2?


Yes I saw the screenshot. The plug-in only supports the official MUI, MUI2 and classic UIs, which do not use any skinning. It would not be possible to get UMUI to work with aero because of the skinning. It should be fairly easy to convert the script to MUI2; just look at the MUI2 example scripts.

Stu


Originally posted by Afrow UK
Yes I saw the screenshot. The plug-in only supports the official MUI, MUI2 and classic UIs, which do not use any skinning. It would not be possible to get UMUI to work with aero because of the skinning. It should be fairly easy to convert the script to MUI2; just look at the MUI2 example scripts.

Stu
Ok thanks!

New version:

1.0.0.7 - 26th April 2012
* Implemented a new button drawing method to fix white text flicker (/btnold switch reverts to the old method).
* Now disables Aero if the theme data cannot be loaded on theme change.
Explanations of the old and new button drawing methods and their pros and cons are in the readme.

Stu

Afrow,

With this new plugin, the option /nobranding makes the UI draw no button at all. Alternatively using /nobranding /btnold uses older library to draw I guess.


Originally posted by GaNi
Afrow,

With this new plugin, the option /nobranding makes the UI draw no button at all. Alternatively using /nobranding /btnold uses older library to draw I guess.
Edit: Installer crashes

Bad news for people that like the Aero plug-in:
http://www.wired.com/gadgetlab/2012/...-in-windows-8/

It seems that Microsoft currently tires to cripple the "classical" Desktop as much as possible in order to make "Metro" appear less annoying/limited. The result will be an OS that has a "Touchscreen" interface, which is completely unusable and infeasible for anything but Tablet computers, combined with a totally crippled Desktop, which isn't more than a emergency fall-back feature. I would be fine to consider Windows 8 a pure Tablet-OS, but my biggest fear is that the epic fail of Windows 8 that we'll see on the Desktop market (we'll see how well it goes on the "Mobile" market) will give a great boost to Mac OS X. Might also be chance for Linux to gain some popularity though...

:rolleyes:


Archive: Aero plug-in


/ot this will drop win8 finally to death on desktops. win7 is supportet till 2020 - 8 years to go now.


Originally posted by GaNi
Afrow,

With this new plugin, the option /nobranding makes the UI draw no button at all. Alternatively using /nobranding /btnold uses older library to draw I guess.
Fixed.

1.0.0.8 - 27th May 2012
* Fixed buttons not being drawn and crash when using /nobranding.
Stu

Originally posted by LoRd_MuldeR
Bad news for people that like the Aero plug-in:
http://www.wired.com/gadgetlab/2012/...-in-windows-8/

It seems that Microsoft currently tires to cripple the "classical" Desktop as much as possible in order to make "Metro" appear less annoying/limited. The result will be an OS that has a "Touchscreen" interface, which is completely unusable and infeasible for anything but Tablet computers, combined with a totally crippled Desktop, which isn't more than a emergency fall-back feature. I would be fine to consider Windows 8 a pure Tablet-OS, but my biggest fear is that the epic fail of Windows 8 that we'll see on the Desktop market (we'll see how well it goes on the "Mobile" market) will give a great boost to Mac OS X. Might also be chance for Linux to gain some popularity though...

:rolleyes:
This release would be a total fail as Vista. I guess, very few people would upgrade to windows 8.

@Affrow,
Thanks!

Afrow UK,

today I rebuilt one of my installers in order to update some of the files included. The installer is using the "inetc" plug-in and I noticed that the text in the "Cancel" button (while downloading) had disappeared! Since the installer script had not been modified, I was quite surprised. My next thought was about the plug-in versions. So I extracted the plug-in DLL's from the "old" working binary of the installer. I discovered that I was still building with the very same "inetc.dll" (latest version available) but had updated the "aero.dll" in the meantime! And indeed, switching back to the older "aero.dll" resolved the issue. So I believe this might be a bug in your "aero" plug-in :confused:

Aero.DLL version 2012-03-10:
http://img14.imageshack.us/img14/8890/aerodllold.png

Aero.DLL version 2012-05-27:
http://img42.imageshack.us/img42/3456/aerodllnew.png

Really only change is the Aero.DLL. I'm using Unicode NSIS (v2.46.5) , in case that matters.

Any thoughts?

Thanks and keep up the good work,
MuldeR


This occurs because the Aero plug-in draws the Cancel button text itself. The inetc plug-in reads the Cancel button text to use it for its own Cancel button but gets an empty string. Just add /canceltext $(^CancelBtn) to the inetc plug-in call.

Stu


Thank you for the reply.

So I now have to set all texts for "inetc" manually. Fair enough. Still I wonder why the (slightly) older version didn't need such workaround.

Something must have changed between those two versions that "broke" it...

Regards,
MuldeR


You don't have to set all the texts, just the Cancel text. And giving it $(^CancelBtn) is what it would be set to anyway, so I don't see that as an issue? Yes, the way the rendering was done has changed (the old method didn't work well on Windows 8).

Stu


Originally posted by Afrow UK
You don't have to set all the texts, just the Cancel text. And giving it $(^CancelBtn) is what it would be set to anyway, so I don't see that as an issue?
Yeah, not a big deal - once you have figured out what to do. Still it would be preferable if no such workaround was needed. Couldn't other random things "break" in other plug-in's?

Originally posted by Afrow UK
Yes, the way the rendering was done has changed (the old method didn't work well on Windows 8).
If Windows 8 is the (only) reason for the changed behavior, wouldn't it be easier to simply add a version check and completely disable/skip the Aero plug-in on Windows 8? I mean, in Windows 8 they have replaced the "Aero" UI with something that looks like the emulation of a computer from the 1980's. So I don't think the Aero plug-in has much of an effect on that system anyway. Or am I wrong?

This issue is specific to inetc because Takhir decided to use the existing button text rather than hard code a string. There could be other plug-ins but none that I can think of (except perhaps NSISdl).

Windows 8 doesn't have transparency but still has Aero glass (DWM Composition) so yes the plug-in does make the installer look very different. Also it was not just a fix for Windows 8 - it is a general improvement which reduces text flicker on Windows Vista/7 as well.

You can still use the old text rendering if you want to (see the readme).

Stu


Originally posted by Afrow UK
You can still use the old text rendering if you want to (see the readme).
I had missed that option. Thank you for pointing me at that :)

Originally posted by LoRd_MuldeR
I had missed that option. Thank you for pointing me at that :)
For some reason /btnold for Aero::Apply didn't have any effect on my problem, so I'll just use /CANCELTEXT with inetc.

At RTL lang
Aero::Apply and BrandingText At RTL lang ?(farsi)
before Aero adding
http://uploadpic.org/storage/2011/th...Whkt2NIWoE.jpg
After Aero Adding
http://uploadpic.org/storage/2011/th...Eyf3xdeir9.jpg

Hide Branding under cancel and next bt
dose not work with BrandingText TRIMLEFT, /TRIMRIGHT or /TRIMCENTER (farsi)

with option /nobarding just removes BrandingText


There is no support for RTL languages at the moment. I will have to look at it when I have time - I have other priorities at the moment I'm afraid.

Stu


بسیارممنون Thank you:)


New version:

1.0.0.9 - 2nd February 2013
* Fixed button and branding text rendering for right-to-left languages.
* Fixed bug which could cause a crash due to a variable not being initialized to NULL (only when Aero could not be enabled).
* Fixed Aero not being applied on classic UI installers with RTL languages.
http://nsis.sourceforge.net/File:Aero.zip

Stu

Thank you for the update!

<nitpicking> Seems like you forgot to update the version info. </nitpicking>


Fixed.

Stu


thank u so much (to fix it for RTL Lan)