This is my second post about user interfaces available for the .NET, which I will probably call the "CLR" from here on out, since its easier on my fingers. The first part is here, be good to it.
As a special note, GTK#, the toolkit I'll be talking about, just recently had a new release. I'm going to be discussing an older version because I have not really had a chance to explore this version in depth.
Now we're going to discuss...
GTK#
A binding to the graphical user interface called GTK+, GTK# is easily a step above the rest when it comes to API quality and expressiveness, when you consider the alternatives. On the pecking order, GTK# comes in closely behind WinFX, and way, way ahead of S.W.F and wx.NET. I'm going to ignore GTK+ entirely, and write this blog post as if GTK# was the whole kettle.
GTK# uses a container based layout system, which is basically a fancy way of saying that you drop down a container, tell it how you want it to layout your controls, then start flinging those controls like spaghetti onto an artist's canvas. Although this sounds pretty haphazard in theory, its possible to make a beautiful and usable user experience using GTK#.
GTK# uses an xml-based serialization format, called Glade, that enables an abstraction between user interface design and wiring up the controls to the data-driven back-end. Unfortunately there are very few graphical designers that support GTK# and Glade, and so inevitably you have to rely on The One True Glade Designer. Its got an awful user interface and should not be used to judge the abilities of GTK#, because it falls short. Very, very, very short. Midget short.
There's plenty of base controls, in particular the powerful TreeView that allows for different styles of data visualization. However, there is a distinct lack of convience when dealing with GTK#: although virtually nothing is impossible due to the robust way GTK# is built, some of the most commonly repeated idioms do not have any convient shortcuts, which means that for even some of the simpliest scenarios--like simple listboxes filled with text--require an inordinate amount of effort given the task you want to accomplish. It would be nice if GTK# shipped with a lot of prefabbed controls for the most common user interface idioms, but that does not seem to be the kind of development paradigm they're going for.
GTK# is crossplatform in theory, but the platforms with the strongest support are really just various Linux distributions and of course Microsoft Windows. It can run under Mac OSX, but I have been told that it is not a pleasant experience by some. Not having a Mac, I can't really say anything more. I myself have successfully gotten GTK# programs to run on Windows and Ubuntu without recompiling.
There's a lot of things that seem to be amiss if you touch on GTK# after having done WPF development for awhile; most notably, you can't arbitrarily place a control inside of a control: you'll have to "paint" it by hand yourself, and, as far as I know -- I haven't done anything beyond *drawing* the controls -- wire up the events as the parent control receives them. It is nothing brutal, but the time spent custom painting controls could be better spent doing something--anything--else. Most toolkits suffer this flaw, so if you have no experience with WinFX, then custom drawing is standard. Other things WPF developers will find lacking is "styling" and the magic of the, uh, what'chu'call'it, DataContext, I think, but that's about it.
All in all, its a pretty good toolkit if you need to write an application targeting Mono and any of the platforms it supports. I think if a lot more effort was put into making the API more agile then it could see itself being on common footing with WinFX. It compares quite nicely at its current state, however, so don't dismiss it outright. ;)
Score: 7/10
Sunday, January 22, 2006
Monday, January 16, 2006
GUI frameworks available for .NET: WinFX
I thought I would do a little blogging on the user interfaces bindings currently exposed to .NET, and how I feel about them, their APIs, and their documentation: basically the stuff you need to know to work with the APIs, and the APIs themself. They're in no particular order, but I'll give them a rating from 1-10 based on how fluid it be, yo.
Each blog will focus on just one user interface framework. Let's get it started.
Windows Presentation Framework (WPF)
When you first look at the API, it is mindblowing -- there is shit everywhere, and the inheritance and interface definitions are off the chain. For a moment it seems like one big cluster fuck, but this is one of those situations where examining the API without using it is a Bad Thing To Do. After a few hours working with it, I began to realize the reason there were so many interfaces and inheritances trees was to keep things simple. You only implement what you need, nothing more. This is a startling contrast to most of the UIs that have .NET bindings (including Win32 itself), where there is generally a huge base class with lots of overriable methods and properties. At first glance it seems like a sweet deal, but then you run into "ok, what is the absolutely minimum number of virtual method/properties I have to override?"
I really began to appreciate the design when I started to do more complex stuff. I needed a "Icon List" control, which is basically a panel that holds a bunch of icons, with optional text beneath each icon. There's no such convience control in WPF, so I realized I had to make one by hand. It only took minutes to get the basic functionality in: the main panel, to hold all the icons, was a WrapPanel. Each of the "icon" elements was basically a Canvas with an image on it. The best part was when I realized I wanted to add "tagging," support, all I had to due was plop a text box down, anchored to the bottom of the Canvas... and I was "done" so to speak.
"Styling" controls is really easy, and in fact one of the things I really like about the WPF. One style can apply to any kind of UIElement, really, which are the building blocks of user interface controls. So you can apply the same style to a radiobutton and a textbox and achieve the same result. Really cleans things up quite a bit.
The fact that any UIElement can be placed inside of another UIElement becomes invaluable after spending a few days with it. It makes compositing controls a real killer feature. This is to be expected, though, since WinFX is a "next gen" API and isn't carrying the baggage of backwards compatibility, so it has no other choice but to be better than the current toolkits or die trying.
There's other goodies I haven't had time to jump into, like DataContext, a really sweet way of data-binding. Basically this is how you tell UIElements to interpret your class/structure. Then all you have to do is supply your object and things work like magic.
Still, there are some serious downsides: documentation, for one, is pretty much nonexistant. The API is in constant flux as well, since every CTP makes a few dozen breaking changes. I would not ship software targeting any given CTP of WPF right now, but software that doesn't have an "offical" release until sometime next year is a good canditate, in my opinion. I know that I'm using WPF right now to develop something.
Score: 9/10
Each blog will focus on just one user interface framework. Let's get it started.
Windows Presentation Framework (WPF)
When you first look at the API, it is mindblowing -- there is shit everywhere, and the inheritance and interface definitions are off the chain. For a moment it seems like one big cluster fuck, but this is one of those situations where examining the API without using it is a Bad Thing To Do. After a few hours working with it, I began to realize the reason there were so many interfaces and inheritances trees was to keep things simple. You only implement what you need, nothing more. This is a startling contrast to most of the UIs that have .NET bindings (including Win32 itself), where there is generally a huge base class with lots of overriable methods and properties. At first glance it seems like a sweet deal, but then you run into "ok, what is the absolutely minimum number of virtual method/properties I have to override?"
I really began to appreciate the design when I started to do more complex stuff. I needed a "Icon List" control, which is basically a panel that holds a bunch of icons, with optional text beneath each icon. There's no such convience control in WPF, so I realized I had to make one by hand. It only took minutes to get the basic functionality in: the main panel, to hold all the icons, was a WrapPanel. Each of the "icon" elements was basically a Canvas with an image on it. The best part was when I realized I wanted to add "tagging," support, all I had to due was plop a text box down, anchored to the bottom of the Canvas... and I was "done" so to speak.
"Styling" controls is really easy, and in fact one of the things I really like about the WPF. One style can apply to any kind of UIElement, really, which are the building blocks of user interface controls. So you can apply the same style to a radiobutton and a textbox and achieve the same result. Really cleans things up quite a bit.
The fact that any UIElement can be placed inside of another UIElement becomes invaluable after spending a few days with it. It makes compositing controls a real killer feature. This is to be expected, though, since WinFX is a "next gen" API and isn't carrying the baggage of backwards compatibility, so it has no other choice but to be better than the current toolkits or die trying.
There's other goodies I haven't had time to jump into, like DataContext, a really sweet way of data-binding. Basically this is how you tell UIElements to interpret your class/structure. Then all you have to do is supply your object and things work like magic.
Still, there are some serious downsides: documentation, for one, is pretty much nonexistant. The API is in constant flux as well, since every CTP makes a few dozen breaking changes. I would not ship software targeting any given CTP of WPF right now, but software that doesn't have an "offical" release until sometime next year is a good canditate, in my opinion. I know that I'm using WPF right now to develop something.
Score: 9/10
Friday, January 13, 2006
Back in the game again.
I'll be available for some work-for-hire starting today. I know C#, Boo, and if I must -- I mean really if I must, Java. I like to charge a flat rate for the work I do, and there'll be no problems as long as you don't suddenly up and make a major change to the requirements.
Thursday, January 05, 2006
Opera > Firefox?
I just read a blogger article linked from OSNews -- a site whose link quality is slowly degrading. However, it does provide little gems like this one:
Popular Technology.net: Opera is Faster, More Secure and More Compliant than Firefox
Now, I'll be the first to say that Opera is a very good web-browser, but this guy does more harm than good to its community. You notice right in the beginning that something wayward this way comes, with the fucked up metric of using vulnerability count as a blanket way to consider how secure a software product is. In reality, I think most of us would take ten (10) javascript vulnerabilities that with infinitely looping javascript prompts over 1 (one) 0-day exploit like this one.
Unfortunately, the article only gets worse from there, and ends on the less-than-subtle note of him/her/it arbitrarily declaring Opera the best browser. What pains me the most is that some potential Opera users are going to read that blog entry before they try the browser itself and immediately be put off by the attitude of smug superiority justified by a random link and a short pithy two-three sentance paragraph.
Personally Opera has a lot going for it, but until we're able to write extensions for it -- there are some that exist for Firefox like Scrapbook, and Location Navigator, that I cannot live without -- I'll be sticking with Firefox on point, with Opera covering the flank until it gets a bit more experience in the field.
For people who don't like customizing the browser (quite a number of people), Opera is on it like white on rice, since the "out of the box" experience everyone always oozes on and on about is much better than Firefox's.
Popular Technology.net: Opera is Faster, More Secure and More Compliant than Firefox
Now, I'll be the first to say that Opera is a very good web-browser, but this guy does more harm than good to its community. You notice right in the beginning that something wayward this way comes, with the fucked up metric of using vulnerability count as a blanket way to consider how secure a software product is. In reality, I think most of us would take ten (10) javascript vulnerabilities that with infinitely looping javascript prompts over 1 (one) 0-day exploit like this one.
Unfortunately, the article only gets worse from there, and ends on the less-than-subtle note of him/her/it arbitrarily declaring Opera the best browser. What pains me the most is that some potential Opera users are going to read that blog entry before they try the browser itself and immediately be put off by the attitude of smug superiority justified by a random link and a short pithy two-three sentance paragraph.
Personally Opera has a lot going for it, but until we're able to write extensions for it -- there are some that exist for Firefox like Scrapbook, and Location Navigator, that I cannot live without -- I'll be sticking with Firefox on point, with Opera covering the flank until it gets a bit more experience in the field.
For people who don't like customizing the browser (quite a number of people), Opera is on it like white on rice, since the "out of the box" experience everyone always oozes on and on about is much better than Firefox's.
Subscribe to:
Posts (Atom)