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:
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).
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.
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.
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.
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.
- 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.
- 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.