MS has done very nice job to migrate *.rc to *.xaml, which is XML based.
Although there has been hickup with the .NET ( and still has ), MS successfully migrated from Win32/MFC to .NET framework. There can be good & bad things to migrate to .NET, but .NET framework provides modern programming paradigm and easy of programming.
For WPF, they decided to use XML format to describe their resources, which was done by the resource editor in *.rc format. Actually this kind of idea was tried first by Mozilla with XUL. As far as I remember the motivation was :
- Separation of GUI design and programming : Designers have difficulty in using development tools. Designing couldn’t be done independently from programming. Using XML for describing resource can solve this problem.
- Submitting resource file to “text” only version control system
- Ease of writing parsers and editors
In addition to providing methodology to describe resources, it also provides resolution independency by using vectors instead of bitmamp, new rendering engine, and so on.
Everybody take it for granted to learn whole new API/framework for this fresh new framework.
Now, let’s consider Objective-C/Cocoa case for Mac.
Very silently, Apple started to use XIB instead of NIB. NIB can be used still, but XIB is created if you don’t set to use NIB from Xcode 3.x.x. What is nice about XIB is that the resource file can be uploaded to version control system easily, and can be compared to other version of same file with diff tools easily. How? Yeah.. XIB is also in XML format.
Apple provides resolution independency and other cool stuff but it is not tided with the XMLness of XIB. For Mac, XIB is largely for GUI rather than drawing, picture effect and so on.
Actually I like this approach more. The motivation of incorporating XML for resource editing was twisted by MS because WPF provides others like vector based rendering and so on. It doesn’t need to be related to XML. For WPF, I guess MS introduced new technology, new approach while they are presenting XML based resource editing, and packaged under the WPF moniker. However, Apple classified responsibility of each and every technology more well.
However, XIB doesn’t provide theming. I believe it is very do-able to implement theming with XIB/Cocoa. Maybe Apple people are considering that now, but maybe not. Actually they tried “Appearance Manger” back then in the era of System 8, and they found out that providing different look can confuse users.
Also, XIB doesn’t provide localization by replacing values set by keys. When you make an XIB/NIB file localizable, it makes separate directory per a language and put XIB/NIB file under that directory. So, if you have English, Japanese and German interface, three directories will be created and each directory contain XIB/NIB file for the languages. What I mean here is to have one XIB/NIB file and controllers, for example, can have their “name” key set to have “$localizedText” value, and that “$localizedText” is to be replaced by each language.
Wouldn’t this be very convenient? Actually in the last Cocoa Heads meeting, Mr. Talbot, Terrence mentioned about such thing. ( He is very nice person. ) However, I think there can be one glitch in doing so.
For example, let’s say you put a button on a window and set its text to “Good bye”. It is 8 characters wide + margin.
Let’s say you want to put German text for German interface. Then it will be “Aufwiedersehen”. (Hmm.. Aufwiedersehen is direct translation of “See you later” ) Anyway, what I mean is that the width for a widget will be different when it is localized in other language. So, you will need to resize widgets.
So, Apple had good reason to make separate XIB/NIB file instead of replacing some special identifiers with localized text.
However, GNUStep started to use XML based resource description technology, and it is called “Renaissance”. It uses the “replacement” technique for localized GUI. ( localizable string attributes )
To see how it works, try visiting it web site and using it.
Renaissance is also XML based. It seems to be more like WPF as far as its XMLness is concerned but it is not there yet.
Among these three approaches, I think Apple’s approach is the best so far. Editing resource is a lot easier with XIB. With WPF resource editor, it is sometimes difficult to select a widget or put a new widget inside of an existing widget. (Especially when width is automatic – for example, Grid layout ) The order of keys are different when you use the property side panel. Sometimes, one key appears in front of others, and sometimes others appear before the key which appeared first before. There are some glitches.
For data binding, it is not clear which one is better. XIB/NIB is really easy to use, once you know how it works. It is very intuitive, but sometimes you can’t figure out how to set the binding properties. However, with WPF, although it is very manual and somewhat more tedious to set data for binding, it is very clear to understand what is happening. Once you get used to, you will like Apple’s approach, but in other cases, you can like MS’ approach more.
CHANGED : NO, after trying binding data source manually, MS approach seems to be more advanced and better. Although many tutorial sites explain it by showing XAML files, you can bind data to widgets using a mouse. However, there seems to be still difficulty in binding non-widget data like the ones shown in “Getting Started with WPF“.
Oh.. one great advantage of XIB/Cocoa approach. You don’t need to learn new set of API/framework. Nothing is changed. Your existing codes work with the new XIB file. XIB is for resource editing, not for programming. This is very different from that of WPF.