Q1 skins

76 posts, 0 answers
  1. Rick
    Rick avatar
    49 posts
    Member since:
    Oct 2008

    Posted 18 Mar 2009 Link to this post

    I do understand people are having problems, but I'm not sure I understand why they're MASSIVE problems.

    I don't intend on upgrading any of my clients with updated Telerik controls, unless its necessary. If its necessary, my time will be chargeable. I won't upgrade a client's version of anything unless I have to, because upgrades inevitably take time to install.

    Sure, I have to recreate 3 custom skins for the project I'm currently working on, but that shouldn't take me too long.

    Other than that I don't see what the problem is? The Telerik controls can't sit still and stop evolving (the amount of requested additions and updates ensures that). I knew very well the new Q1 controls would cause me a little work so I scheduled the upgrade for when my client was out the country.

    Couldn't it be that in some cases the controls haven't been used in the best way, and that has lead to their poor upgradeability? Overriding CSS classes rather than creating your own skins, for a start. I realise the Telerik documents suggest this in places, but its something I've never taken a liking to.
  2. Bill
    Bill avatar
    94 posts
    Member since:
    Aug 2006

    Posted 18 Mar 2009 Link to this post

    If we need Telerik to modify our skins, do we send them to one place or do I send the "panelbar" skin to the panelbar group, "tab" skins to the tab group, etc? Do I zip up all my skins and send them or place a support ticket for each one?
    -------
    Q: I have implemented a custom skin for one or more Telerik controls, and now with the Q1 release it stopped working because some controls had their CSS classes names' changed and/or because the control rendering was changed. Who wil fix things for me?
    A: Telerik will. As mentioned in the original blog post, published three weeks before the release - in case that you are not able to convert the custom skins, please send them over in a runnable project. Shortly, we will send you back an update version that looks the same, but can be used with the new Q1 2009 release.
    --------
    The skin builder may help in the future, that will be nice to have. I would love to be able to make "buttons" like the ones on this page! I LOVE these buttons! ;o)

    Thanks
  3. Steve Y
    Steve Y avatar
    115 posts
    Member since:
    Sep 2008

    Posted 18 Mar 2009 Link to this post

    Rick.

    I agree with you that these changes haven't induced 'massive' problems. At least, not for me. Perhaps for others it's different...

    There are definite inconveniences to upgrade given the css has changed for most of the complex controls. I've been using a combination of Office2007, Outlook, and the Default skins. I liked the fact that they were of different sizes as I could use the Default skin for my main navigation Menu. The Outlook tabstrip for tabs within my pages (they were smaller and so the size worked for me) and then I used Office2007 for my grids and input controls.

    Now the sizes are standardized I have had to change my approach. Instead of just tweeking the grid skin, I have moved to my own skin. It took me about 4 hours to get that running. Then I made changes to the new TabStrip Outlook skin to make it look like the old one. There's 3 hours to learn it and get the changes made. But now I have my own skin for that too. As a side note, I really dislike the border color changes to the Outlook tabstrip, but hey, I made my own with the old colors so...

    Then I noticed that the new Office2007 datepicker/calendar was too big for my needs. So I created a new skin for that. There's 2 more hours. But I like the new look of the office calendar so it was worth it to get it slimmed down a tad so it would fit onto my site look & feel.

    Finally, I noticed that a change had been made to the size of RadTextBox controls - they are now 4px smaller than the old ones. This was a pain because the change has not been propogated into asp textboxes modified by radinputmanager. Given I have hundreds of textboxes, with a good mixture of Radtextbox and radinputmanager textboxes, I had to add 4px to all my radtextbox declarations to get everything to align again. So. 30 minutes on that process.

    All told. I spent about a day getting my application looking like I wanted it (i.e. back to pretty much what I had). But now I have a couple of my own skins which I think is better than having one-off tweeks to standard skins. The calendar looks better, and I have a good idea of the underlying css structure of the controls and, unless changes are made by Telerik to the structure again, I should be in good shape to ride out any other skin changes that may ben made in the future. This is a positive I think.

    I must say that I do like the new default skin. To me it looks very professional, especially the changes to the menu control. I would like to see another two like it, one with a medium gray and one with a darker one (not like black, but almost the inverse of the current default skin).

    Now there are a couple things that I'm slightly unhappy with.

    1. I think the new Office2007 skin for the grid is a step backwards. My view is that it's very flat looking. I doesn't look as much like an office 2007 skin. I think the older smaller 'lighter glass type' header was much more aesthetically pleasing. The highlighted drop down buttons in the header are distracting to me and the row highlighting colors were better in my opinion.  But. I have my own skin which looks the way I want it so I guess it's moot.

    2. Now that all skins for a given control are of consistent size, it makes it harder to get a site that has a contrast of sizes of menu items for example. High level menu - big. Low level or submenu  - smaller. But, I guess I'll just have to make my own skins with the sizes I want now. At least that's relatively simple.

    I going through this process though, I have some observations which would make my life easier if they were provided within the conttrol.

    1. I would like to be able to declaritively change the size of some things. An example would be the Outlook TadStrip tab sizes. I would like to be able to change the height of a tab (so that the text would stay centered vertically). I would also like to change the width of a tab. Unfortunately, there is significant padding which is added to the size of the text. I would like to be able to say in my tabstrip declaration padding="2px" and have that propogate down to the control. This would then save me from having to make my own skin, plus it would, I belive, give folks some flexibility in how these controls look within their application.

    2. I found with the calendar control that you can, in fact, change the width of it and the day box rendering would get thinner or wider depending on the size you specified. However, I would like to see the height for each  day box change based on the width to be, perhaps, square. Within the css it's set at a fixed height - so you have to make your own skin and change that too.

    3. Is it possible to change the height of the headers etc for the grid declaritively? I haven't tried, but if not, allowing a developer to vary the height of the command row, header row, footer row, filter row simply and declaritively (and without having to resort to templates) would perhaps give us the flexibility we need to buld an application which has the look and feel we need without having to get into skin development and template management.

    All of this is relatively minor in the grand scheme of things. I would prefer not to have to rework my application, but some rework is understandable. I think you have a good set of controls and your support is excellent. All in all, there have not been too many speed bumps along the way for me.

    Regards, Steve
  4. Tim
    Tim avatar
    79 posts
    Member since:
    Feb 2008

    Posted 20 Mar 2009 Link to this post

    Just adding my 2cents. 

    Ditto to a lot being said, but it was a pill we "had" to take to get to the next step.  Knowing that, I reserved time for the update and just dealt with it.  Additionally, Telerik support has been great, providing responses and fixes to all my issues within 24 hours.  Thank you.

    Sadly, the update did eat up my week, but worse than that it became a distraction.  It reopened a bunch of

    • "I think this color is better",
    • "I like an extra space here",
    • "I feel the other icon was better"... 

    They are all opinions, not to be discarded, but can not be debated as there is no right answer. Opinions are not FACT

    What is a FACT is

    • that Microsoft Vista default looks like THIS ...
    • that Microsoft Office2007 looks like THIS ...
    • that Microsoft Outlook looks like THIS ...
    • that Microsoft SharePoint (hint) looks like THIS ...

     

    As soon as your Microsoft skins start being tweaked with Telerik opinions it opens a door for everyone to give you their opinion.  It is an unwinnable game as many of us already know.

    On a personal note.  My opinion is favorable to the changes, and we dealt with what we did not like.

     

     

     

  5. Bill
    Bill avatar
    94 posts
    Member since:
    Aug 2006

    Posted 20 Mar 2009 Link to this post

    I agree that "Opinions are not FACT", but the fact remains, if you consider a product an upgrade, then you would not expect the product to break your appliation. Or, if a new product is introduced, it would be nice if the "upgrade" steps included what problems to expect (e.g. breaking the custom skins) and how to avoid them.
    I have been using Telerik since its introduction. From single controls, multiple dll's to everything rolled into one, so I have been thru many changes, (for the better I may add). I agree that their support is the best of any company I have worked with, and have supported and encouaged many developers to use their controls. They have the best of breed, and I will continue to use and promote them, however, in summary, I believe that we ask them to take into consideration a roadmap that will provide a smooth transition in the future.
  6. Chris
    Chris avatar
    20 posts
    Member since:
    Sep 2007

    Posted 20 Mar 2009 Link to this post

    And in true Telerik fashion, this has been fixed for all controls and all previous skins.  However, with this "solution" it appears that you're disabling all of the new skins.  Doesn't seem like it's much of a solution to me
  7. Tervel
    Admin
    Tervel avatar
    1337 posts

    Posted 20 Mar 2009 Link to this post

    Hi everyone,

    I just posted a blog post based on information from this forum thread. From the post you can download a skin converter tool that I wrote, as well as try a slightly limited web-based version (in case you only skinned a couple of products).
    The blog post is here:
    http://blogs.telerik.com/blogs/09-03-20/Using_pre-Q1_2009_skins_with_Q1_2009.aspx


    Sincerely yours,
    Tervel Peykov, MCSD
    ASP.NET Team Leader
    Telerik
  8. Brian Stanek
    Brian Stanek avatar
    15 posts
    Member since:
    Jan 2008

    Posted 23 Mar 2009 Link to this post

    I have just downloaded the converted skins.  We have an application that is using both the old Vista and Outlook skins.  We are using the Direct Registration Method of applying the skins.

    We have created a directory called Skins which includes the following directories

    Common
    Outlook
    Vista

    Also within this directory are all of the base control stylesheets.

    On our master page we added the following css references for each css file that was included:

    <

    link runat="server" href="~/Skins/Chart.css" rel="stylesheet" type="text/css" />
    ...

     

    <

    link runat="server" href="~/Skins/Outlook/Window.Outlook.css" rel="stylesheet" type="text/css" />

    When the application loads the following javascript error is produced: 'styleSheet' is null or not an object.  

     

  9. PureCode
    PureCode avatar
    97 posts
    Member since:
    Jul 2006

    Posted 23 Mar 2009 Link to this post

    Interesting.

    I was (by far) one of the most vocal people in the original blog post regarding these skin modifications.

    However, when we plugged the Q1 release into our framework, the problems were minimal and, indeed, we got a MUCH more consistent look for the generated pages (which equal to about 95% of ALL pages the framework uses, for our largest customer, that's tens of thousands of pages). Bit of tweaking here and there within the variety of custom rendering engines and all was well. Biggest issues were in the admin area (bit over 50% auto-generated pages there) where we had to redo a fair amount of static pages, but nothing terribly hard (I had some interns do it).

    The skins are not THAT different i think, at least, I haven't really noticed any major differences. I have to give the side-note that we have heavily tweaked just about all controls, some so far that they barely resemble Telerik controls (or those of two of their competitors), the combo box we don't even use, as it is the most horrendous pile of **** (excuse the (censored) French) ever made by Telerik. Of course, our 'own' combo box does use the Telerik skinning engine (insert lengthy rant about Telerik making SkinRegistrar and such internal here, nothing that Reflection doesn't fix thankfully) and looks good in most of the skins.

    I do agree that most (some are alright) of the embedded skins are total eye-sores though. Take 'Forest' as an example, or 'Sunset', those nuke my eyes out of my skull. I do like the Office 2007 and Outlook skins even if they are VERY similar. The Vista skin, well, the color contrast (RadMenu vs RadPanelBar for example) is ridiculous, where the menu looks quite nice, the panelbar is MUCH 'brighter' and a totally different hue, resulting in conflicting colors between the two, in my opinion at least. The black skin, is WAY too black, good way to nuke an LCD screen there (I can visibly see the refreshing of the screen (or something going on anyway) with that skin, and that is with an 120hz LCD panel, it also 'emphasizes' the back light of the LCD, resulting in lighter colors on the sides and top/bottom, real bad for the actual LCD panel within the monitor).

    With 14 or so custom skins developed over the last few years, we had to either send all of them to Telerik and wait, or simply write a converter, we did the latter. Took very little time to do by the two interns who wrote the converter. Later we developed a skin creation tool (crude, but works) in a few days time, and re-wrote the converter to convert competitor skins to Telerik (and vice versa) and integrated that into the creation tool. Instead of four days to make (and more time-consuming, debugging) a skin, it now takes four hours for my graphics guys. We now have some 48 skins (in-house made, converted competitor skins (even if we can't really use those of course, the converter became the 'study project' for the two involved interns, so cross-product suite conversion was a nice one for them), etc) that work great with the Q1 release.

    As for 'CSS hacks', well, you can't really get around those if you want to support as many browsers as possible with somewhat more advanced features of your product. Hell, we have to support platforms that don't HAVE browsers, we literally translate the resulting pages to something these platforms (some so ancient, i was barely born, and i am rapidly approaching the big 4-0) can read, understand and display on-the-fly, including (most) of the advanced features (think things like animated drop downs/menus/etc), some platforms don't understand anything but text (and even THAT is limited) though, but that's another story.

    The hard-coding of fonts, yes, this is a pain, we 'extend' (override is a better word, this is javascript we're talking about) a lot of Telerik javascript to get around that, as well as much tweaking within the controls themselves, but in the end it was pretty easy to do. Telerik is not the only one who does that though, I believe that most product suites we've looked at (and two of the three we picked for development, Telerik included) use some form of hard-coded fonts. Telerik needs more consistency with this in my opinion, and a built-in way to override the fonts (without having to use CSS classes with boat-loads of !important usage, which tends to break other controls) would be very nice.

    Personally, one of my pet-peeves with the embedded skins is the lack of 'arrows' for some of the skins on the PanelBar and other 'trivial' things like that.

    I'd love to see some changes in the way we can interact with the skins as developers, take said PanelBar, almost every bit of skinning can be overridden with other CSS classes in the designer (for the PanelBar items), EXCEPT for the hover css, making most of the other overridable bits totally useless. It is madness to be able to change look/behavior by making simple CSS classes for all the bits they let you override, and then having to use javascript to override the hover css. In the end we were forced to do yet more 'tweaking' of the embedded javascript by 'extending' Telerik javascript functions as well as several control code-behind bits to add the hover CSS changing ability to the PanelBar items. This falls in the same category as the RadDockZone not throwing an 'initialize' client-side event (or any client-side events for that matter), that too we added by 'extending' the javascript as well as the control (the combo box we replaced entirely though, that 'thing' can't be tweaked to do what a 'normal' combo box should be doing, it's quicker to dive into the Telerik assembly, use Reflection to get to the important bits (which are practically all internal, shame on you Telerik) and re-create it from there).

    I am, however, VERY happy with the consistent sizing of the skins in the Q1 release as well as the somewhat more 'intuitive' CSS, killed a number of our headaches.

    Backward-compatibility, well, there are pros and cons there, i don't need product-suites like Telerik produces to turn into bloatware after a few years though, it just results in being 'unable to see the trees through the forest' and allows people to produce some real bad code by using 'obsolete' functionality, the .NET framework has enough of this already.

    While it certainly isn't perfect (case in point, the layout issues with splitters where one pixel falls outside of the screen on the right side, even if one can work around that) it IS a step forward, and it was pretty hilarious to see our entire framework blow up like a bomb when Q1 was plugged into it (the downside of such extensive 'tweaking' of third party products), but that happens whenever one of the three product-suites gets an update, one of the things we're fixing right now. It is, in the end, always better to develop everything yourself, but that is WAY too costly for most smaller businesses. So, we'll just have to cope, as long as it doesn't influence my bottom line too much it is not a problem.

    As a last note, I believe that the biggest issue here is the lack of the style designer, and before a few days ago, the lack of a converter is what hit most people with this change in the skinning engine. Being dependent on someone else to get your customized skins converted is a major pain in the sit-meat. Having to (almost literally) write your skins in Notepad, is something that i can not describe in 'clean terms' and has been a major issue for some time with Telerik and one of the other two product-suites we use. Now that we've unified all that into a single application (it's not pretty, but it works), this has become MUCH easier.

    Why is it taking so long to develop this style creator Telerik? I fully expected it with the Q1 release, not the Q2 release. Two junior developers and two interns needed just a few days (in total, cheap, man-hours) for ours (add maybe another day or two for a pretty interface, which we don't really need, so didn't do) and that one supports three major product suites.

    Regards,

    Mike
  10. Tervel
    Admin
    Tervel avatar
    1337 posts

    Posted 24 Mar 2009 Link to this post

    Hi all,

    @PureCode: The provided feedback is quite valuable and we will comment on it shortly.

    @Brian Stanek: The problem you are experiencing is most likely related to two factors combined:
    1. You are using RadFormDecorator on your page
    2. And you have imported too many CSS files. IE has a limit of 32 CSS files as explained here:
    http://social.msdn.microsoft.com/Forums/en-US/iewebdevelopment/thread/ad1b6e88-bbfa-4cc4-9e95-3889b82a7c1d/

    The error occurs because RadFormDecorator tries to create dynamically one more stylesheet, which fails, because of the limitation.

    The best thing to do would be to reexamine your CSS links and eliminate links to controls that are not acutally used on the page. Another option would be to simply combine several CSS files into one (for example, you might try adding the base and the skin-specific CSS files together).


    Sincerely yours,
    Tervel
    the Telerik team

    Check out Telerik Trainer , the state of the art learning tool for Telerik products.
  11. Kim
    Kim avatar
    9 posts
    Member since:
    Aug 2008

    Posted 24 Mar 2009 Link to this post

    PLEASE make WebBlue 2008 a priority.  We cannot use the 2009 version either, too many changes - and most not for the better.
  12. JOSE MANUEL PÉREZ RAMÍREZ
    JOSE MANUEL PÉREZ RAMÍREZ avatar
    22 posts
    Member since:
    Jan 2008

    Posted 25 Mar 2009 Link to this post

    me tooo and sunset
  13. JOSE MANUEL PÉREZ RAMÍREZ
    JOSE MANUEL PÉREZ RAMÍREZ avatar
    22 posts
    Member since:
    Jan 2008

    Posted 25 Mar 2009 Link to this post

    time is money!!. 
    i have a big web application. converts to 2009 version is around 2000€. if you not allow some solution i will be end with telerik control and use other. all year your bad changes cost some money to my enterprise. 
    think about it
  14. Alex Gyoshev
    Admin
    Alex Gyoshev avatar
    2508 posts

    Posted 25 Mar 2009 Link to this post

    @Kim & Jose:
    Please refer to the following forum thread: 2008.Q3 skins are now compatible with 2009.Q1.

    @PureCode:
    Hello Mike,

    This is the feedback we need! Thank you very, very much.

    Now, regarding each item on the list:
    • RadComboBox - I assume that you don't like the rendering?
    • SkinRegistrar - You could inherit from the public RadWebControl/RadDataBoundControl/RadControl, for example, and you won't need the SkinRegistrar. I admit that there are some rather "hacky" parts of it, and making it public would make them more resistant to changes - therefore, leaving them this way, even if we could do better.
    • RadMenu + RadPanelBar / Vista - please take a look at the attached screenshot - would you like us to change the hue this way? It's a change, again, but it will not break anyone, and we would consider it "safe".
    • Font overrides - I assume this is in the context of the question raised by Buffer - We moved the skin declarations to the skins, due to his request. I assume we could get more flexible in this direction - do you think that it is appropriate to inherit the font family from the page? It was initially requested, but we are afraid that many customers rely on the font... but we could be wrong.
    • Visual Style Builder - well, here your criticism gets a bit harsh... Why is it not included in the Q1 release? Well, during the quarter, we redirected all resources to polish the skins and test them thouroughly. Since we promised this would be the last of these bad breaking changes, we wanted to make the skins and make sure they perform well in all common scenarios. Furthermore, the skins are used as base skins for the ones you can make through the VSB, and if we didn't polish them to the extreme, it would cause all inherited skins to break, too.
      Having said that, we're already working towards the promised CTP of the style builder. Why this takes so long? Well, we want it to be a great, and usable, product. Your feedback will be highly appreciated once the first bits are released. Also, it seems that you have a lot of expertise in the skin conversion - and if you would like to share it with us and the community, your contribution will be rewarded.

    Best wishes,
    Alex
    the Telerik team

    Check out Telerik Trainer , the state of the art learning tool for Telerik products.
  15. JOSE MANUEL PÉREZ RAMÍREZ
    JOSE MANUEL PÉREZ RAMÍREZ avatar
    22 posts
    Member since:
    Jan 2008

    Posted 25 Mar 2009 Link to this post

    not possible 2008.Q3 skins are now compatible with 2009.Q1.
    because:
    i cant first soluction --> i use 3 or 4 skins at page
    RadPanelBar--> Gray (in principal webform i use sunset)
    RadGrid--> WebBlue
    Menu--> Sunset
    i cant set in webconfig 3 themes
    i cant second soluction--> i have 125 pages with 3-12 radcontrols (ex: 125*7=875 modification and 125 add links to css resources)
    two persons five days-->time is money
    i think you must offer new compatible versions. sw Architects, programmers buy radcontrols to make easy Not to have difficults.

  16. Tim
    Tim avatar
    79 posts
    Member since:
    Feb 2008

    Posted 25 Mar 2009 Link to this post

    Sorry to interject into the Vista RadMenu Hue change proposal, but can the Vista hue just simply match ... say Microsoft Vista? 

  17. Alex Gyoshev
    Admin
    Alex Gyoshev avatar
    2508 posts

    Posted 25 Mar 2009 Link to this post

    Hello Tim,

    Well, it's the first thing that comes to mind, heh :-)

    The idea behind the proposal was that the integration between the menu and the PanelBar, as pointed out by PureCode, looks weird (due to the hue difference). So, here's the trade-off, either
    • leave the Vista skin as-is; won't integrate good with the PanelBar and will look exactly as in the OS
    • change the Vista skin to the proposed color; will integrate, won't be the same as the OS

    All the best,
    Alex
    the Telerik team

    Check out Telerik Trainer , the state of the art learning tool for Telerik products.
  18. Steve LaForge
    Steve LaForge avatar
    61 posts
    Member since:
    Feb 2005

    Posted 25 Mar 2009 Link to this post

    I love the capabilities that the Telerik controls provide, and I have most usually been very happy with their support.  However, this is one area where I have complained before.  Just once I would like to be able to upgrade from one release to the next without having to modify my skins.  And I really have very few and would have even fewer, but Telerik has backed me into the corner of having to create some at times because SkinX in Q2 doesn't match SkinX in Q3, but yet I need some of the software fixes in Q3. 

    My personal opinion is that once a skin is added for distribution, it's basic look and feel should never change unless it is to fix a specific bug.  If they want to change an existing skin, then give it a modified name.  Finally, as they have done in the past, if they are about to drop support for one, then identify it as obsolete, but in any case you should always support it "as is" for at least 2 more releases so that the user community has time to choose from another or to redesign.

     

    I do appreciate that you made the 2008.Q3 skins available again but as has been pointed out, going back and manually updating multiple applications with numerous pages is a problem.  I understand Tervel's point about the need to move forward.  As developers, we've all faced those choices before.  Telerik just needs to lessen the pain that we currently experience every time they have an update.

  19. Levi
    Levi avatar
    134 posts
    Member since:
    Jul 2008

    Posted 25 Mar 2009 Link to this post

    Alex,

    Best advice for Vista skin. Change it back to "Exactly" has it was before. If that is not possible consider this:
    - Using bright blue for column headers is a "really bad" idea. The bright blue in Vista is meant to represent a hover or selected state. It is very confusing to users when all the column headers look selected by default. If you read the Vista design guidelines you will see what i'm referring to. From a usability standpoint most of the new skins are just confusing. The selected vs. non-selected states are not very clear at all. The vista panel bar is another example of this. There is no reason to ruin the great grid column headers you had before for busy and unclear changes made in 2009.

    - Believe when i say you have ruined the vista skins and making small hue changes will not fix the problem.
  20. PureCode
    PureCode avatar
    97 posts
    Member since:
    Jul 2006

    Posted 25 Mar 2009 Link to this post

    Hi Alex,

    Apologies for the harsh sounding comments on your skin creation tool efforts. I assure you it wasn't meant to sound that way.

    As you did, step-by-step:

    RadComboBox

    It is not so much the 'rendering' as it is the functionality, or rather, the way the functionality is executed (which ends up with rendering issues, but alas). There are numerous issues here but to keep it short and to the point, we've always had issues with offsets within the drop down (if i remember correctly, you guys insert a 20px or 40px or so padding/margin on the right side, which screws up a lot of things for us) and because of that it ends up rendering the hover quite oddly, we were never able to really fix or even work around that. There is also the issue of not being able to specify a font size to be used, or getting it to stick, not entirely sure. I'll go through the development diaries of the developers who dealt with this and compose a list for you guys (endless information on most of your controls in those).

    SkinRegistrar

    We do inherit from your base controls for the most part, but there are exceptions. For example, we needed a 'group panel' of sorts that cleanly fits in with your skinning. We tried this by inheriting RadWebControl, but that turned out to be a LOT of work. In the end, we (more-or-less) decided to take your RadDock control and transform it into the 'group panel', instead of deriving from RadDock (which would insert that 40kb raddock.js script we don't need in this case as well as a lot of CSS we don't need) we had to build the control pretty much from scratch.

    RadWebControl and its peers all incorporate your core.js, and while it will only be included once, such a 'group panel' doesn't need any javascript, and in the case it is all by itself on a page (due to the sheer amount of automatically generated pages in our framework, this is not outside the realm of possibility) it was decided to create a 'RadCustomControl' which derives from WebControl, IControlResolver and ISkinnableControl. Because of ISkinnableControl we had to reflect into the SkinRegistrar in order to get access to GetDesignTimeStyleSheet, GetEmbeddedSkinNames and GetRuntimeSkin. Code-wise, not too bad to do, albeit that we, of course, had to put in quite a bit of code for ISkinnableControl. It's not the prettiest but it does the job.

    I admit that I am not entirely sure if I am entirely correct here (typing from memory), since I wasn't a developer on that side of the framework project, I tend to stick with the 'hard stuff' such as simulation models, on-the-fly page/code generation, platform translation, compatibility, and, of course, running the business.

    Looking at the SkinRegistrar in Reflector, yes, it is a tad 'hacky', but that goes for a fair bit of your internal code (AJAX script registration being an example that comes to mind), which is not an issue, our framework couldn't possibly work without 'hacky parts'. Your competitors do pretty much the same, it is part of the nature of dotNET I guess.

    RadMenu + RadPanelBar / Vista

    I wasn't actually talking about a RadMenu integrated into a RadPanelBar item, but it is pretty much the same deal.

    Check this screen shot, within the red circle is a light blue RadPanelBar root item, the RadMenu and a RadToolBar (plus a splitter). For some reason, the colors of the RadMenu and the RadPanelBar root item right below it do not 'work' for me. The RadMenu is a nice, subdued color, as opposed to the RadPanelBar root item which just screams 'Here I am!' to me. The RadToolBar has the same issue (being much darker than the RadMenu) but somehow (either it being much darker, the opposite of the RadPanelBar, or the black outline around it) the RadToolBar makes enough of a difference for it not to conflict as much as the RadPanelBar but it still looks 'off' to me.

    As far as a 'fix' for this, I agree with other people in this lengthy topic, making it actually look like Vista, would be a great idea. Albeit that I am not sure if that addresses my personal issue with the conflicting color schemes used for the controls, we only have one machine with Vista on it, for testing, and I have barely touched it and it has been a long time since I tried Vista as my OS of choice to do my work on, so I am a bit rusty on what it actually looks like.

    Font Overrides

    Inheriting the font family from the page would break a LOT of websites/applications that use your product suite, and is bound to spawn a few more of these negative skin topics on your forum. It would be a bad idea to actually remove the font declarations from the skins in my opinion, Telerik has put the font declarations into the skins since at least Q1 2008, which is the oldest version I have on my PC.

    What we did was override your javascript on some of your controls to allow us to 'specify' a custom font that overrides the declared one, and expose that within your controls using an extention method, unfortunately, .NET 3.5 has no extention properties which would have made that a bit more user-friendly, we have to use the override from code (be it javascript or code-behind). For the most part, we simply override the javascript where the CSS with the font declaration is used, fetch the CSS class from the skin, and replace its contents with what we specify (or a different CSS class entirely if wanted, of any given name). A second work-around we did was to simply intercept the bits in your assembly (both js and code-behind) where the skin CSS is read/processed and make it ignore any font (or any other CSS for that matter) declarations, in that case, it inherits the page font.

    Perhaps the best way to go would be to allow the user to 'IgnoreEmbeddedSkinFonts' (to put it as a property name) in your controls? Wouldn't be too much work to change your javascript to actually do this I think.

    Visual Style Builder

    Once again, apologies if my criticism sounded a bit harsh.

    Thanks for the somewhat more thorough explanation on this, I can entirely understand that you needed to shift resources in order to get the base skins ready. I guess that this is the major difference between what we developed as opposed to your style builder, we don't use existing skins as base skins unless the artist explicitly load an existing skin in order to modify it into a new skin.

    Another major difference in the second part of your reply to this, we developed our tool as an in-house tool, so while it works quite well, it was NOT designed to be used by people who don't know it. It would be trivial to slap a nice UI onto it and make it somewhat more usable by the average user and this had crossed my mind (and was discussed in a meeting), but considering the resources Telerik is putting into your VSB, we deemed it 'unfair' to release our skin creation tool to the public. I am certain yours is much better than what we did (after all, it was made by junior developers and interns, the code is rather, well.. spaghetti, in places) and yours probably integrates into Visual Studio (another thing that is fairly trivial to do, but still), you guys also know a LOT more about the internals of your assemblies than we do, we may know how to generate a skin that works perfectly, but that doesn't mean that there couldn't be issues with the assembly itself when it consumes the skin, we haven't ran into any issues, but one never knows.

    If you guys are open to it, I would be willing to have my people spend a little more time on it, strip out the cross-product suite support, tidy up the code a little, slap a decent UI on it and release it open source. I, however, do not want Telerik feel 'double crossed', which is the main reason we didn't release it in the first place (there are a few more reasons, but those can be fixed), even though we are aware of the demand for such an application within your community. As much as I dislike wasting time (and as thus, money), I dislike screwing over businesses that we are 'friendly' with (a competitor, without hesitation, but that is normal within the industry we cater to) by making them feel like they wasted their time (and as thus, money) just as much. The only side-note here is that I and my company can not provide support for the resulting application (hence the 'open source' bit), that would get way too expensive.

    I guess that is the reply to your reply Alex, I do have two more questions.

    1. Would it be difficult for you guys to add some paging abilities to these forum threads? This one is massive and it is not exactly easy to read anymore.
    2. Is it in some way possible to change the e-mail address in my profile? I noticed it has one of my 'spam' e-mail addresses on there.

    Regards,

    Mike
  21. Levi
    Levi avatar
    134 posts
    Member since:
    Jul 2008

    Posted 25 Mar 2009 Link to this post

    Woah Telerik,

    Looks like your going to have to hire another person just to read these posts. :)


  22. PureCode
    PureCode avatar
    97 posts
    Member since:
    Jul 2006

    Posted 25 Mar 2009 Link to this post

    Hehe, yeah.. apart from a LOT of posting going on in this thread, I personally tend to get a little verbose with my replies, it is just too hard to explain something clearly without going into massive detail when you are writing text.

    What is one going to do right?

    Regards,

    Mike
  23. Alex Gyoshev
    Admin
    Alex Gyoshev avatar
    2508 posts

    Posted 30 Mar 2009 Link to this post

    Hello Mike,

    ... and whoa! No offense, but your answers really present a psychological stop - in terms of "it's hard to start writing an answer", heh. I'll try covering all the points that you mentioned - please excuse me if I happen to miss something.

    • RadComboBox and feedback on other controls - we're open for it. The 20px padding in the drop-down should be easily overridden for all comboboxes since the Q1 release - I've personally added the RadComboBoxDropDown CSS class (and yes, it's odd that it hasn't been there before)
    • SkinRegistrar - I assume that something like a RadCustomControl or RadLightweightControl, without the Core.js love, will prove useful in situations like the one you described. Basically, the user story would be "creating a custom control that supports skinning", right?
    • RadMenu + RadPanelBar / Vista - well, I guess people would be more angry if we change the hue now. The Vista skin is mostly the same as the controls in the OS, with a bit increased contrast in places, and made dimensionally equal to other controls. The WebMail demo isn't really the most common interface in Windows [Vista], and that's the reason for the clashing styles (e.g. the ToolBar is always 100% wide, instead of ending in the split pane).
    • Font Overrides - you're right, we've been using fonts for quite too long in order to change this now. The idea with the property is good, so we'll look deeper into that - thank you.
    • Visual Style Builder - thanks for the additional clarification. I don't think that it is necessary for you to release your application as open source (give the VSB a try!) - but after all, it's your decision to make. I (personally) just got curious about the cross-suite migration, since I assume that it is quite an achievement to make such ports. I guess the politeness in publishing such a tool is somewhat questionable... in terms of vendors, everybody gains the others' skins, and in terms of clients, everyone gets the freedom to preserve the look of their application when moving from one suite to the other... but on second thoght, the second statement looks silly, given the many differences in our rendering. Or is it?

    I've forwarded your request for the forum thread paging to the responsible team. It's not very common to have such long threads (apart from times of brutal breaking changes)...
    Regarding the e-mail address change, please open a support ticket with the substitute e-mail and it will be changed.
    Greetings,
    Alex
    the Telerik team

    Check out Telerik Trainer , the state of the art learning tool for Telerik products.
  24. Peter Zolja
    Peter Zolja avatar
    119 posts
    Member since:
    Dec 2007

    Posted 30 Mar 2009 Link to this post

    "... and whoa! No offense, but your answers really present a psychological stop - in terms of "it's hard to start writing an answer", heh. " -- Could you clarify what you meant with psychological stop? Thanks.
  25. Alex Gyoshev
    Admin
    Alex Gyoshev avatar
    2508 posts

    Posted 30 Mar 2009 Link to this post

    Hello Peter,

    Disregard it... it was a reference to the blank page syndrome, when answering to a big post.

    All the best,
    Alex
    the Telerik team

    Check out Telerik Trainer , the state of the art learning tool for Telerik products.
  26. PureCode
    PureCode avatar
    97 posts
    Member since:
    Jul 2006

    Posted 30 Mar 2009 Link to this post

    Hi Alex,

    Thanks for the reply. I understand the 'blank page syndrome', as I deal with it fairly often (our customers tend to ask REALLY hard questions at times, as do my developers). I am also 'infamous' for my ability to induce the syndrome in people, as i have said before, i prefer to be as verbose as possible in order to get the information across, it serves as a means of brainstorming for myself as well since it forces me to think about what I am writing, I often get new ideas by simply writing a huge e-mail or forum post. If you prefer me to the point and no further, just let me know, I can do that, if needed.

    Anyways, to reply to your reply, in the usual highly verbose manner.

    RadComboBox/Etc

    I am (personally) not a fan of having to override embedded CSS, as it tends to interfere with other controls on the page that rely on the same embedded CSS (in Teleriks case, that'd be the same controls as the one that needs the CSS overridden). However, I wasn't aware of the RadComboBoxDropDown class being added, it is great that it is finally there (and, indeed, long overdue).

    I do not want to 'spam' your forums with all of the information we have accumulated over the last few years (be it issues or oddities), but I'll see what I can do, most of the work would be to see if issues have already been fixed or not (we've been using the ASP.NET AJAX suite since the early betas). Time is always an issue, and we do have a project that needs to be finished soon, after that, I will have more time to research the development diaries and see what is relevant and what not. After I have compiled such a list, I'll either create a single post with a Word document attached or open a support ticket.

    SkinRegistrar/ScriptRegistrar

    We simply derive from the standard WebControl and add the ISkinnableControl, IControlResolver and, if needed, the IScriptControl, postback handling and data source handling. ISkinnableControl and IScriptControl require access to the SkinRegistrar and ScriptRegistrar which are internal to your assembly as well as a bunch of code (mostly based on what you use in your assembly) to implement them. Apart from the obvious use of Reflection to get access to the internal bits of your assembly, it is not that hard to create a 'RadCustomControl'.

    There was at least one control we extended (RadDockLayout being the one that comes to mind) that even within your assembly does not use RadWebControl or any of its peers. It derives from System.Web.UI.Control but does implement ISkinnableControl. Since RadDockLayout is more or less a 'nothing' control (it does no rendering), that is understandable. When we extended RadDock, we needed a way to apply 'global' properties to all of the RadDock controls contained within the RadDockLayout (think transparency for example), so we had to add scripting support to it. We derived a new control from RadDockLayout, and added IScriptControl. We wanted to keep the implementation as close as possible to your assembly as we could, so we implemented IScriptControl the same way you do, using Reflection to get to ScriptRegistrar (we access 'GetScriptManager', 'GetScriptDescriptors' and 'GetScriptReferences') and implementing IScriptControl in a similar fashion as you do using those. Apart from an issue where 'GetScriptDescriptors' in ScriptRegistrar throws an Ambiguous Match Exception (due to the two overloads you have for it, one wanting Control, the other WebControl), which was easily solved, pretty easy to accomplish. So, our RadDockLayoutEx control is exactly your RadDockLayout but with scripting support (including the EnableEmbeddedScripts property, the main reason for implementing it this way as far as I remember). Our RadDockLayoutEx mainly serves as a means to set 'global' (as in, within the layout control) properties for zones and docks as well as actually being a 'layout' control, having the ability to create a (table based, in our first experiments) layout within it from the designer.

    RadDock was the first of the Telerik controls that we extended massively (adding things like the removal of the border around a RadDockZone (including removing the spacing), allowing empty RadDockZones to collapse, add spacing between docks within RadDockZone, fix a few issues RadDock has with 100% width zones/docks (such as a 100% width RadDockZone overlapping its parent container by 10px), etc). I kept myself involved in that one since I wanted to know how easily each of the three suites we use could be extended, including the client-side code.

    I've actually had the idea of tossing our early experiments regarding RadDock extending onto the code library as it does add a lot of functionality and it may (it is 'experimental' code, and not optimal in most areas, but still) help some of your users understand how to extend your controls, including extending/overriding your embedded javascript (with properties from the server controls, client-side events, etc). Sadly, I can not release the actual extenders as we implemented them into our framework, but 'experimental' code is not a problem. I am just not sure how Telerik feels about us doing this since we do access 'internal' Telerik assembly code and tinker with embedded javascript. Perhaps you can answer the question regarding whether or not we can/should release such code?

    Anyways, to answer your question, creating a custom control that supports skinning is easy, simply derive from RadControl (albeit that this would, indeed, add the core.js to it). In order to get just the skinning, a new base control would be needed, we made one for our use which works nicely. It does require a substantial amount of code to implement IControlResolver, IControl, and ISkinnableControl, especially considering it requires a bit of Reflection to implement the latter. Our 'RadCustomControl' weighs in at about 253 lines of code (excluding Reflection code) but that is with at least 30% to 40% whitespace. Much of the code is practically the same as what you use for your base controls, without the need for core.js or any other javascript. The only issue was your EmbeddedSkin attribute since that too is internal to your assembly, and while I am not sure if my developers managed to use Reflection to expose the attribute for our custom controls at present, we couldn't do it back then for some reason I do not recall. We worked around it by telling the relevant method in SkinRegistrar that the custom control is 'RadGrid' instead of 'this.GetType()' back then.

    RadMenu + RadPanelBar / Vista

    It is not an issue for me to leave the skin as is, we can override any part of your embedded skin CSS with our extenders. I simply voiced my opinion on the color conflicts. Thanks for all the clarification regarding this though. It is clear that I am not the only one with 'opinions' regarding this skin, you may want to look into what other users say, as it seems to generate a fair amount of heat amongst them.

    Font Overrides

    It is impossible to make everybody happy in my experience. Such a propery would be a compromise between removing the font declarations within the CSS (breaking large amounts of existing applications) or simply keeping them (and getting much heat from your users). This is, in business, usually the best way to maximize the amount of happy people, simply give them the choice to do as they please. If they want the internal fonts, they can and if they don't want to use the internal fonts, they can. Taking 'the middle road' is not such a bad idea when these sort of situations pop up. In the end it comes down to you providing the ability to do so, and from there on, the users can do what they want (substitute the word 'users' with 'customers' where applicable).

    Visual Style Builder

    While the cross-suite support of our tool seems to be difficult, it is actually much easier than one may think. Due to the nature of ASP.NET and the way it 'forces' one to write controls, most of the skinning between suites is very similar, just in a different 'package'. While it is not a simple matter of taking one piece and transforming it into another piece for another suite, practically all the information one needs to take a skin from suite A and turn it into a skin for suite B is available within the skins (the little bits missing are pretty easy to fill in automatically). It does, however, take a fair amount of trial & error to get things exactly right. Font sizes, element sizes, padding, margins, etc are the hardest to 'port', since those differ between the suites. The developers on that little side-project designed a few formulas to calculate this side of the conversion process, and while it is not always spot on (although it usually is, surprisingly enough), it is close enough in those cases and requires very little manual tweaking.

    The way we went with this is to define the skin structure (more or less the content of the respective CSS, so, how each suite formulates the skins, which class does what, etc) within an XML file with a specific structure, by simply comparing the XML file we made for the source suite to the XML file we made for the destination suite, the converter knows exactly what goes where and even how to re-calculate sizings and such.

    At the same time, these XML files we made for each suite also determine how the skin creation side of our application produces the skin made for any of the currently supported suites. The actual skin creation is a generic system, it holds no 'relationship' to any given product suite and it is simply a bunch of objects internally. The 'magic' happens when the skin is saved, this is where the application takes the XML file we made for the destination suite, and translates the generic skin data used within the skin creator to whatever format the destination suite uses for its skins. This way we can create a single skin and export it to any and all supported product suites in one go. The generic skin creation system the tool uses is based upon another XML file that defines what can be created (control types), how it needs to do this, how it needs to present it and what properties are exposed for these (and a few other, more trivial, things), so, it is more or less an XML based database, since it also specifies which suites support what of the control types that it contains. The tool does give a preview of the control being designed for the selected suite(s), based on the XML files, being able to see the result for the three supported suites in one go (if all three are selected for preview), is definitely a very nice feature. The tool can also show a preview of ALL designed controls for the specified suite(s), so we can compare the look across each suite and deal with inconsistencies where needed.

    This entire 'system' was developed as a study project for a couple of interns, and we never had (and still don't have) the intention of actually releasing this tool. Internally, it is extremely handy to have, since we do use three different product-suites while developing our framework. Now we can make a single skin in a simple UI, and export it to all three suites in one go, previously we had to create three different skins, by hand. It is a big time (read, money) saver for us.

    The rendering aspect (which is extremely different between suites), is not of our concern since we simply generate files that are compatible, meaning that the rendering of the skins is left up to the suite. When it comes to this, the tool could potentially support skinning for any product out there that uses some sort of readable skin format (or at least a format we can figure out). Only things we have to do with the tool is create the XML definition file for a product and potentially make some additions to the XML file used by the generic skin designer if there are bits we don't have yet.

    I don't consider it 'ethical' to release this tool, even if we would just release the conversion side of things. There is no use in pissing off three vendors by making their skinning 'compatible' with their competitors products. It will only result in bad relationships between my company and the vendors. I haven't looked at the legal aspects of this, but I don't doubt there is some way these vendors could sue if we released the tool. For users, I can see some advantages to a tool like this, your example of being able to take your skins with you when switching suites being a big one. Since I rely on the support of these vendors (Telerik included) for the (1000x more important) development of our framework, I'll just keep this tool to myself. Only thing I may do is have a bit of market research done and see what the potential 'sales value' of this tool would be, but it is highly doubtful that it would be worth more in sales than our framework (and that is the understatement of year), still, never hurts to know what something is worth right?.


    Regards,

    Mike
  27. yceron
    yceron avatar
    21 posts
    Member since:
    Apr 2007

    Posted 30 Apr 2009 Link to this post

    It's been a month since the last post on this thread and still Telerik hasn't provided a solution.

    The provided hack is not a solution, it didn't work for me.
    While I do understand the reasons for the change, I do not understand how a components company breaks previous versions with a new release.

    As others have said, the new color combinations look horrible (why does the color green have to be in almost all of the skins?), some fonts you can't even read and some styles are COMPLETELY different than their previous versions.

    I just got out of a headache upgrading the Reporting controls, and now I'm in the middle of a nightmare upgrading the ASPNET Controls, and I'm only at my first application to update, more to follow. Going back to an older version is not an option, since IE8 support is really important.

    This last Q1 2009 update doesn't even seem to be a Telerik product. Telerik's products have always been high quality, support has always been great, but it looks like they stopped caring about their customers with this update, if they cared, they would've released an update already at least with the old themes with different names, working as intended in order to keep backward compatibility with their existing customer base.

    Please Telerik, provide us with a working and realistic (no one wants to update every single control on every single aspx page of every single application) solution to this problem.

  28. Vijay
    Vijay avatar
    5 posts
    Member since:
    Nov 2008

    Posted 09 Jun 2009 Link to this post

    Its amazing this is causing so much pain to your customers.
    Now I have to uninstall this release and go back to the old version.
    Its a disaster - whose bright idea was this ??

    Please tell me where  I can email the zipped copy of the project so that you guys can fix it for me ?
  29. Ivo
    Admin
    Ivo avatar
    689 posts

    Posted 11 Jun 2009 Link to this post

    Hi Vijay,

    We have provided all the skins as they were in the previous version (Q3 2008) and they can still be used with the latest version (Q1 2009) if customers decide they want to. Here are the full details in this forum thread.

    We have also released the Visual Style Builder tool which allows for very easy customization of colors or any other visual settings if you are not happy with the default skins.

    If you use a custom skin and have problems updating it to the latest version please do not hesitate to send us a support ticket and we will help you right away. Please attach in the ticket a working project with your skin as it was with the previous version and we will promptly upgrade it. We have also released an automatic tool that can do this for you. Please check this blogpost for details.

    Best wishes,
    Ivo
    the Telerik team

    Instantly find answers to your questions on the new Telerik Support Portal.
    Check out the tips for optimizing your support resource searches.
  30. Paul
    Paul avatar
    2 posts
    Member since:
    Jun 2008

    Posted 15 Jun 2009 Link to this post

    I've tried all the approaches suggested by Telerik, tedious as they are (changing EVERY SINGLE control to use the 'old' skins) but nothing works for me.

    It pains me to say it but we won't be renewing. We've loved Telerik since we started using them but the new release just breaks our whole application. We can't release the new skins to our customers, we'd be laughed out of the office.

    Time to start looking for alternatives.
Back to Top