As I wrote in the
following much commented post when the Q1 2009 beta was released - RadControls for ASP.NET AJAX did receive a major face-lift!
Despite the major improvements in a number of important areas, this change has caused turmoil as well (somewhat regrettably for both sides - customers and Telerik developers - involved).
After the release, two major requests came from customers: 1) to help them keep an "old-style" skin in their applications as they liked it more than the new version, as well as 2) help them update their existing custom skins.
I spent the last couple of days implementing a tool that can do just that. It is this very tool that was used to convert the 14 "old" skins and update them to work with the "new" release. These 14 skins are ready for you to download - and can be found here:
Download Q3 Skins - link 1
Download Updated Q3 Skins - link 2 (requires login)
I would like to throw in a couple of extras here as well:
1) The current version of the skin conversion tool (it is a simple web-based application that should be run locally) is available for download from here:
2) In case you only skinned a couple of products, I have prepared a web-based version of the tool, available at the following URL: http://converter.telerik.com/skinconverter/
Please note that the web-based version has a couple of limitations compared to the full-blown version above, but will work well in 95% of the scenarios and is a very fast option to try out.
As promised in the original blog post, and in various forum threads, in case you would like to keep using an existing older skin, and you face problems updating it (manually or using these tools) - send it over to us, and we will fix it for you. All you need to do is open a support ticket and send us a working application with the skin, the way it worked with earlier Telerik.Web.UI release.
I would also like to take one more chance and share some additional details about the reasoning behind the skin changes. Hopefully this information, which is not present in the original blog post will shed more light on the situation
The skin changes are aimed at increased
productivity for the developer, appeal for the end user, and greater
consistency across the products. These are not PR words. Here is
exactly how the new release (and the next one) delivers and eases both
your work and improve the user experience:
- Skin chooser control. This control,
released recently allows your users to change the look and feel of the
application in an instant (it is featured in both the QuickStart online demos and
the WebMail demo).
- RadFormDecorator - this
control, unique to Telerik, which styles browser controls and elements
has been further enhanced to provide smoother decoration and even more
decoration features. Adding it to the page will take care more or less
of everything that was not skinned - such as buttons, radiobuttons,
checkboxes, textareas, textboxes and page background (for selected
skins).
- Skin improvements (the 'problem' being
discussed here) - the changes made ensure consistent sizes and
consistent look of common elements across controls. This is a must if
end-users are to be given the option to change the skin of their
application.
- SkinBuilder application (under development, will be released next Q)
The SkinBuilder application was already mentioned in my blog post. Here
are two additional screenshots - the first one features a RadFormDecorator demo, and the second features the Web Mail demo application's main page.
Hopefully it is now becoming clearer how the RadSkinManager, RadFormDecorator, skin improvements and SkinBuilder
are coming together and form a greater vision. It is this vision that
has brought about the changes to the skins. Changes in the CSS naming
conventions were necessary for the unification of all products so that
in the future their skins can be made more easily or with a visual tool
(such as the StyleBuilder). Failing to do go through this process now -
at the time when the skins themselves were changed - would spell more
trouble in the future. Same argument applies to changing sizes of
certain control's inner elements - one could argue whether an older
skin looked better than its 'updated' counterpart, but one thing is
clear - prior to this release it was practically impossible to "just"
change the skin of the application. Different sizes in different skins
would cause all kinds of visual problems - such as broken layout and
lots of scrollbars. This won't be the case anymore - and the WebMail
demo is the proof. Furthermore, failing to address the issue on
cross-control UI consistency would prevent (or produce less than
optimal) results when building complex UI interfaces.
To summarize, the current enhancements and out-of-the-box improvements
are meant to further streamline the development process and allow you,
the developer, to produce great-looking skinnable applications with
minimum efforts - and certainly with less effort compared to now.