November 2006 - Posts

Cross Platform Widgets

In my last instalment of my Mac Diaries I described my first experiences with developing cross platform between the Apple Mac and the PC, and in ending I mentioned the CocoaSharp, the Mono initiative which promises to make many of the nice native Mac OS X widgets accessible to .NET developers.  I said I would consider implementing a dedicated Mac GUI with this platform if I can't achieve a satisfactory user experience through standard Windows Forms on Mono.

I have spent two days trying to find out a bit more about CocoaSharp, and have decided that it is definitely not a library I will be using in a production project anytime soon.  Despite encountering several mentions of the Mono team adopting it in preference to Gtk# for the Mac side of things, this project is not receiving yet enough attention to be credible.  I also looked at MonoDevelop during this time, but to say that the build and install process on the Mac is not for the feint hearted is a gross understatement!

What I gathered to be the official web site is empty, except for a very short project description, and two links.  One of the links refers back to the main Mono site and offers some relief to those unfortunate enough to first follow the other link to the CocoaSharp Wiki.  This wiki is atrocious, and not just for lack of content.  It is badly organised, offers confusing and duplicated topical links, and has several broken links.  Although the team appeals for contributions in the home paragraph, I don't think enough people even are aware of the project, never mind willing to volunteer for documentation contributions.

The only real contribution I can see on the wiki is that of Tim Davis, who offered a few meaningful tutorials and examples.  This man was kind enough to leave a contact email address, and respond to my queries about anomalous differences between my current installation of CocoaSharp and the content on the wiki.  He has also been kind enough to mail me more current example projects that no longer exhibit these anomalies.  I will be posting his updated examples here soon, but if anyone would like I could mail them to you.

During a long Google session I discovered the world of wxWidgets though its .NET port, wx.NET.  The wxWidgets library is a popular cross platform GUI toolkit that can be used on most operating systems, in C++, Python, Perl, or C#.  One of the differences between this and other cross-platform toolkits is that at the implementation level, it uses the native controls of each specific platform to achieve a look and feel familiar to users.

wx.NET is a C# wrapper for the main wxWidgets library, and although active development on this project has ceased, the last version includes a Perl script to generate C# wrappers by parsing the wxWidgets C++ header files.  It also includes the TowxNET tool, for converting wxGlade or XRC files to C# or even VB.NET.   Very good UI designer support for the toolkit is available through the wxDevC++ IDE, which although requiring some C++ coding from people like me who aren't very used to it, provides a solid design and coding experience.

However, I still have one major challenge to continuing this port, and that is to include a fancy WYSIWYG HTML editor on several forms.  Every HTML editor I have found for MS Windows Forms uses some aspect of the Internet Explorer COM component, and I simply haven't found any such editors for wxWidgets or Mono Windows Forms.  Although Mono has a WebBrowser project, which attempts to mimic the Windows version by using the Mozilla browser component, it looks stalled due to technical difficulties or lack of interest and no response is forthcoming from the project owner.

Getting to Know Mono
I have just run my first semi-functional C# application on a Mac, using the Mono framework.  Some time ago I was briefed to determine if we could port my client's existing Windows application to the Mac, and it has been an interesting introduction to this flavour of cross-platform development.  The application executes a database query and displays the results in a grid through data binding, and is compiled on my Windows XP machine using Visual Studio 2003, then simply copied over to the Mac and run using a simple command line.  Kudos to the Mono team for this impressive achievement.

Getting just this far has not, however, been all wine and roses, and there are still some issues for concern.  My first test application was a simple MDI style text editor designed to test certain aspects of.NET and in particular the Windows Forms libraries.  The simple MainMenu control didn't operate properly on the Mac, not dropping down the File menu to display its menu items.  This is not a show stopper, as the application I am supposed to port doesn't use this control, but there are a few other nigglies that might become usability issues later on.  Mono WinForms applications run under X11, and I think this may have something to do with why, on my application window, the little red close button is disabled, and the window resize handle at the bottom right is plain missing.  Reinstalling Mac OS X Tiger (10.4.2), X11, and Mono didn't solve these problems, but it did reveal a surprising defect in the Mac OS X install.  It wouldn't continue until I had provided basic user information, such as name, address etc. but this screen assumed I was in the US and presented a only list of US states from which to choose, and it insisted on a five digit zip code.  Do Apple know they have customers elsewhere in the world?

I also learned a bit about another cool interoperability initiative called CocoaSharp, which is a port of the native Apple GUI library, Cocoa, to Mono.  If I don't achieve much success using a standard WinForms GUI on the Mac, we will be looking at implementing a dedicated Mac GUI using CocoaSharp.  This library uses the same NIB files used by native Cocoa, which can be designed using proper Mac GUI widgets, in the XCode Interface Builder, resulting in a more genuine Mac OS experience for our users.  The big drawback here is having to play ping-pong with code and NIB files, coding on PC's and building UI's on the Mac.  There is a Mono development IDE available, called MonoDevelop, so I could always move to coding on the Mac, but I'm hoping that if I have to do this, I can find something that will allow me to build Cocoa NIB files on my PC.

Mango Republic

The launch of new airline Mango has generated quite a bit of news recently.  Most of this has covered the dismal performance of their internet site and call centre.  Jumping in selling tickets at as low as R200 for a Jo’burg to Cape Town flight and not expecting high volumes of site hits and telephone calls can hardly be considered  very competent  management.  Nonetheless, I will definitely be trying them out, and hope they can offer a wholly better deal, if not just price, than their rivals in ineptness, kulula.kak, who also had a mention in the same article this morning.

Gidon Novick, chief executive of kulula, considers reasonable prices for local flights a ‘treat’.  He says, “Forgive me if I brag but we introduced low fare air travel into this country over 5 years ago and in that time have doubled the size of the market, have treated over 5 million fans to low fares.”[1]  After reading this, and experiencing the puerile drivel spewed forth by kulula cabin crews in their horribly misguided attempts to entertain , I am convinced that this airline regards their customers as little children that should be grateful for their ‘treats’.

Office 2007 First Impressions

MS Office 2007 B2TR only has three colour themes, and the first one I tried was Black.  I’m very partial to black in aesthetics, and the default Blue was just way too blue.  I may have been preoccupied by several re-installs, but I entertain the notion that before the Technical Refresh I only had these two options; Silver wasn’t there when I looked.

My initial impression of, “Oooh, this looks schweet!’ was nipped short by an uncouth interruption by Outlook.  This suddenly, after an almost protracted skirmish with the incumbent  Outlook 2003, gave up the machine and, with the aid of JohnEdwardsUILib, presented a message box proclaiming only “MAPI32.DLL”. 

How fondly I remember those early moments.  At some point the new Outlook bled to death and its Response and Options faculties were spilled on the ground.  Even Google could not council, as only I was Chosen.  A quick survey of multitudes of Beta users worldwide played a key role in reinforcing my assertion and I was indeed alone.

Many searches and practical decision reinforcements delivered me to a Microsoft Knowledge Base article about problems with Terminal Server and Outlook 2007, which has nothing in the world to do with my problem except the funniest thing happened on the way another re-install;  I followed the instructions to enter a new product key, and It was good.  And It was even activated.

I have yet to identify anything new in Office 2007 truly of value, but I think these guys have done some homework on the UI if not the install.  My first opinions of Office 2007 are good, and I will definitely be giving the suite another chance now that its settled in a bit.