That's perhaps obvious, but where is the line which makes a given UI not a ribbon UI? To define that, one has to define exactly what a ribbon UI is. If MyUI doesn't comply with the Office UI license, is it then a UI which has to be licensed? After all, a normal button bar UI also doesn't comply with the ribbon license. The control I use is from a 3rd party vendor, not MS. However, as it's MyUI of MyApp, I use it as I see fit, it's my application and my work after all. If Microsoft notifies you that the Design Guidelines have been updated or that you are not complying with the Design Guidelines, you will make the necessary changes to comply as soon as you reasonably can, but no later than your next product release that is 6 months or more from the date you receive notice. Your Licensed UI must comply with the Design Guidelines.
#DEVEXPRESS LICENSE LICENSE#
One of the paragraphs in the license says: This might sound weird, but let's do a thought experiment.
#DEVEXPRESS LICENSE SOFTWARE#
Disclaimer: I'm in Europe, and we think a bit differently about imaginary property than for example in the USA (like software patents and the like). There are two things in this license which made me decide to not sign it and write this blog entry instead to warn you not to sign it as well. Let's keep the usefullness of a ribbon UI (which IMHO is heavily overrated) aside for now, let's focus on this 'license'. Now, there's a catch and you likely already know: Microsoft had the fancy idea that if you're going to use a ribbon UI, you have to sign a license with them. So, a nice fancy ribbon menu in an application is tempting, right? After all, at first, a ribbon-containing application looks better (although it doesn't have to be more productive/easier to use, that's another story) Almost every control package out there, WPF or winforms comes with a ribbon control.
The second question one will ask is: should we use a ribbon-like menu system? After all, it's well known that good-looking applications are often chosen over the uglier competition: Looks Sell. However, one can host a WPF control just fine in a winforms application, so re-using our already written winforms skeleton was a choice I didn't expect at first but which makes sense.
#DEVEXPRESS LICENSE WINDOWS#
One other thing which made me draw the above conclusion was that it in general sucks bigtime when you have a normal windows application with normal menus: the text is in general blurry (or at least blurry in a short period of time after a move/open) and to make the menus to look like normal menus like in VS.NET is a pain (it doesn't get close).īecause we will need a custom rendering system in this major version for some areas, we do need WPF. After a day or 2 of fiddling with the various WPF docking frameworks out there, there's one firm conclusion to be drawn: WPF isn't up to par with Winforms when it comes to serious applications which use a normal windows look and feel: automatic menu, buttonbar handling based on selected docked window for example, one of the cool features of many winforms control libraries, is one of those things which is hard to do in WPF (at least, it's not directly available/build in). One of the first questions one would ask these days when a new desktop application is started is: WPF or Winforms? The current version is build with Winforms all the way though it's tempting to go for WPF, as it's new, has nice performance and great looks (if you're able to cook up the styles). (more on that in a later article) and I arrived at the point where I wanted to see how my vision for the major version would work in a draft application, just to see how the various elements would work together visually.
In the past few months I've spend most of my time working on application support library code, language designs, algorithm design etc. NET General General Software Development Software Engineering Windows Forms WinFormsįor the next major version of a certain application I'm working on (gee, what might that be ) I'm researching some UI frameworks and techniques.