The voice of the Mono Community. Table of contents
1.1 Mono 0.23 releasedMono 0.23 has been released. It is only a bug fix release. You can read the release notes here. 1.2 System.Web.Mail + UUEncondingPer Arneng added UUEncoding to System.Web.Mail for attachment encoding. So now both of the encoding techniques work for attachments UUEncode, Base64. Soon the mail API will be totally completed since there are only some minor parts left to fix. 1.3 XML Deserialization now in the CVSMiguel has applied Elan Feingold's XML Deserialization support patch to the CVS. Now objects serialized using XML format can be deserialized back. 1.4 CORBA support is closerKristopher Johnson has published his code for CORBA support. As you can read at his website: "Remoting.Corba is a personal project that aims to integrate CORBA/IIOP support into the .NET Remoting architecture. The goal is to allow .NET programmers to easily develop systems that interoperate with CORBA systems". 2. Meet the team. This week Alp TokerThe Mono team is integrated by contributors all around the world that are working really hard to get this project going further. In this section we will be meeting this people so we can know more about them and what they are doing. Alp Toker is a 6th former based in Highgate, North London, studying Maths, Physics and German. He has been working with Free Software in his spare time for several years, and got involved with development on Linux a few years ago when he wrote gPal, a small Gtk+ frontend for the PayPal online payment service. After releasing the first version, there were many requests for packages and thus began his involvement with Debian and GNOME. He is editor of the popular DebianPlanet site, and one of his projects today is the packaging of Mono for Debian. For I while, He was part of the GnomeMeeting developer team. This is where he learnt the dynamics of working with larger code bases and a distributed development team. At the FOSDEM 2002 conference, he had a lengthy discussion with Miguel de Icaza on the merits of Mono, after which he decided this was a project which could benefit him and vice versa. "My main desire was to have a truly free alternative to Java by the time he reached university. Mono, based on ECMA standards, promised to fulfil that goal. Now, a year on, it seems well on course to do so", Alp states. Most of his time is shared between studies, reading books with unfeasibly long titles and hacking code. At other times, you're likely to find him down at the local, or if it's a Saturday night, trekking through the City with mates. He craves trance music right now, though he'd be hard-pressed to name favourites; "any tune that doesn't involve "blastin' holes in gangstas" is fair game, really", says. Sometimes, he tries his hand at cooking, often with limited success. Having pretty much conquered elementary Chinese dishes like lemon chicken, egg fried rice and eggdrop soup, he's now looking towards Japanese and Turkish cuisine. "They say cooking impresses the girls, but I'm not sure mine would". Interview with AlpThis week we had a chance to meet Alp at #mono, let's see what he told us.MWN: You are the developer of maybe two of the best and very first mono based applications, Acacia (the new name for gsIRC) and Platano. Can you tell us a little bit about them? What moved you towards their development? Alp Toker: That's very flattering of you; I'd say they're definitely both works in progress at the moment. Platano media player is a fairly simple affair based on the GStreamer multimedia framework, now part of the GNOME platform. It was intended as a proof of concept for Gst#, the CLI binding for GStreamer, and still only plays simple video files. The development of Gst# wasn't as challenging as it might at first sound, be use it's mostly auto-generated by the fantastic Gtk# GAPI code parser and generator, which only needed a few modifications to cope with the new code-base. However, it's received a very positive response from the community, and it's interesting to note that a simple video hack (complete with cutesy banana logo) can woo people who wouldn't understand or be interested in a fantastic new optimisation in the runtime, or a complete Remoting implementation. It's all about reaching different target audiences. Acacia (formerly gsirc), an IRC client, is a slightly more complex application. Its development has been a rewarding experience as there's a lot of interest in Gtk+/GNOME 2 IRC clients, meaning there are always users eager to find bugs and provide suggestions as well as developers to provide patches. I'm getting the chance to do things the way I think they should be in an IRC client, and the ease of C# code means I can afford to spend more time in the "sugar" like custom widgets that make for a more complete user experience. Once again, it makes extensive use of existing technologies: Acacia uses Thresher, an excellent IRC library for .NET. It's interesting to note that the author released his (X11 licensed) code only with Microsoft's .NET implementation in mind, yet it runs today on Mono without modification. My main motivation in writing these programs was to test Mono and Gtk# with real-world applications. The most important form of testing by far is provided by unit tests, and Mono has a very comprehensive test suite, but sometimes bugs can slip past it and only trigger problems in real situations. Best of all, I've had the opportunity to get quite intimate with the inner workings of Gtk#, which I'm now doing API beautification for. Most recently, I committed a patch to the GAPI generator that eliminates the need for length parameters for strings, a piece of legacy from the C world that C# doesn't need to carry. MWN: And how do you feel about Mono as an experienced Linux developer? Do you think Gtk# can become a serious competitor to the classic GTK+/Gtk--? Alp Toker: Miguel once said, "There is a point in your life when you realize that you have written enough destructors, and have spent enough time tracking down a memory leak, and you have spend enough time tracking down memory corruption, and you have spent enough time using low-level insecure functions, and you have implemented way too many linked lists". This pretty much echoes my sentiments. I've worked with commercial and Free Software code for data analysis, kernel sources and Web applications, so I recognise that the diversity of programming languages is vital to the developer community. I still have love for the arcane delights of Perl and the structured, clean form of Python, but to me C# is a step-up for large desktop and Web applications. Whether Gtk# will hit it off with wider (read Windows) developer community is anyone's guess, but the Gtk# team is working hard to provide an API that is consistent and compatible with best practice on the .NET platform. Even certain core Gtk+ developers believe that C is not suitable for applications programming, but rather for lower-level systems and libraries, so there is definitely a market for higher-level languages and platforms that make life easier for developers and us. MWN: You said you beautifying Gtk# at the API. Taking in consideration that GTK+ was quite hard to use for primer and medium C programmers, how faithful will you be to GTK+. Do you think it could be better not to respect the GTK+ API and instead make something closer to Swing or Windows.Forms? Alp Toker: Swing and System.Windows.Forms both have their merits. Swing represents the culmination of much research and effort into providing an API that integrates with the Java object model. Similarly, SWF integrates tightly with the Windows environment, providing users as well as developers with an instantly recognisable interface. Gtk+ comes from a different heritage, mostly derived from older UNIX toolkits like Motif. That's not to say that the Gtk+ way of doing things is any less valid than the others, but it does sometimes need a different frame of thought that comes more easily to X11 developers. That said, the tweaks being done on Gtk# should make the API feel more familiar to Forms developers without alienating long-time Gtk+ developers. Gtk# is definitely progressive, but perhaps more evolutionary than revolutionary. MWN: One of the core points of implementing .NET is that we have a bunch of documentation provided by Microsoft and all the editorials that have focused their attention in .NET. But as Gtk# is not a .NET element what are the plans about it's documentation? Is it going to be Monodoc based or we can expect more training facilities? Alp Toker: There are two issues at hand here. First is the systematic documentation of Gtk# interfaces -- there's currently a massive effort under way to document the API from scratch, in the style of other .NET documentation. The idea is to leave behind any trace of legacy C terminology in favour of a fresh new set of documentation. The response has been so great that even undocumented areas of Gtk+ are now having their Gtk# counterparts documented. As API beautification continues, a new set of independent documentation for Gtk# will become ever more important. The other issue is tutorial-style documentation for newcomers. The Mono Handbook, spearheaded by Johannes Roith and Martin Willemoes Hansen not only provides introductions to the various technologies that comprise Mono, but also has a breathtaking compendium of carefully commented code snippets, categorised by namespace, that teach by example. More tutorials will undoubtedly start to appear on third party sites as Mono becomes more widely-distributed. Right now, Gtk+ 2 doesn't integrate into the Windows environment as well as it should. The Windows port of Gtk+ has a shallow look and feel that can leave a bad impression with Windows users. However, commercial applications from the likes of Macromedia and Adobe, as well as Mozilla have proved that it is possible to have a non-native toolkit that is sturdy and consistent with the Windows UI. Work is being done to provide a native-widget rendering theme engine for Gtk+. More customisations may be needed to provide even smaller tweaks, like ensuring that the contents of a scrolled widget are attached full-bleed to their respective scrollbar widgets. This is one of the tasks that I believe will get a lot of attention once the code Gtk# API has settled down. The Gtk+ approach still makes more sense for cross-platform development than often-discussed lowest common denominator approaches, when a toolkit provides only the functionality that's available on both platforms. With that addressed, there will be little technical reason not to go with Gtk# for cross-platform development. The stigma associated with using an API outside the bounds of the System namespace for fundamental UI functionality may be more difficult to overcome. MWN: Do you know if people at ICSharpCode is planning Gtk# support for CSharpDevelop? Alp Toker: I don't know much about what the SharpDevelop people are up to, except that they have an experimental Java-to-C# port of SWT used by the Eclipse IDE. This would provide a user interface based on Gtk+ when run on Linux, although if I understand correctly, it would be independent of Gtk#. I haven't heard of any plans to introduce a Gtk# UI designer for SharpDevelop. MWN: Is there anything else you want to say to the Mono community that will be reading this? Alp Toker: One of the most fascinating things about the Mono project is that it operates in a kind of common ground of platforms, acting as a hub for users and developers coming from vastly differing backgrounds and occupations. It might be a matter of discussing the merits of Mono with people who start an abusive thread on the mailing list out of spite or misinformation. At other times, it's as simple as not putting down someone who accidentally commits MS-DOS style linefeeds to CVS with their first commit. I couldn't have anticipated the maturity of the developer team in handling the varying opinions and approaches, which these people bring. Thanks also for your great work with Mono Weekly News, Jaime. 2. Mailing List ActivityThese days the mailing list has been quiet and despite some 'suspicious' drops, there were no trolls in the scene. Let's see the most important points discussed.
3. CVS ActivityCVS Statistics from March 7th to March 13th (both days included).Authors: Total 30 Total commits: 305
Miguel de Icaza, bug fixing, news contributor, style. Please visit us at the homepage of the Mono Project: http://www.go-mono.org If you want to consult old issues of the MWN. You can find the archives here. An Spanish translation is also available at the Mono Hispano site. |
