I will be at Microsoft on Thursday and Friday, and only have meetings on Thursday afternoon.
I would love to meet other hackers. If you want to meet, discuss, talk, drop me an email: email@example.com
People at the office became LOLcat fans by reading every day i can has cheezburger a few months ago. It was harmless entertainment.
But recently I have discovered that LOLspeak has started to creep into our codebase.
What other naming conventions should we adopt?
Michael struck back by bringing fruits and vegetables today. To which Aaron replied "I hope those fruits rot".
Today the machine was refilled:
This has brought finally an end to the empire of speculation from this rapacious market meddler. With at least 12 new twix bars injected into the local office economy we should enjoy a smooth sailing for the rest of the week.
Update: Some sources inform me that Aaron was trying to create an artificial scarcity in the office by buying the remaining 12 twixes, he hit a glitch in the machine, he got two bars for the price of one.
This is not bodding well for the local Twix aficionados:
Update 2: Capitalism knows no limits:
Update 3: To add insult to injury, he is now selling individual Twix bars for 70 cents each, or a full pack for 1 dollar.
Update 4: We will be picketing Aaron's office at 4pm this afternoon:
I love the LinuxHater's Blog. This is a must-read RSS feed.
It is funny in a way that xkcd is funny to Unixers. Whoever is writing that blog has extensive experience on Linux and enviable writing skills.
A first class grilling/roasting of Linux and the Linux community. It should help keep things in perspective.
Some good starting points:
The entire OpenOffice suite is built on top of a component technology called UNO (which is inspired by COM, but heavily extended). Pretty much all of the functionality in OpenOffice is exposed through some UNO interface, and although the native interface is built on top of C++ many bridges have been created over the years that expose UNO to a variety of languages, runtimes and object brokers.
A few years ago, Sun implemented a .NET bridge for UNO. This bridge allowed .NET developers to script, extend and reuse open office as a library from C# or any other .NET language.
A couple of years ago, Michael Meeks and the OpenOffice community ported the bridge to work with Mono which allows developers to create OpenOffice based solutions using any of the Mono programming languages (C#, Boo, IronPython, IronRuby, F#, VB, Nemerle and so on).
But even if the engine existed, it was not properly installed in the system and getting a C#-based OpenOffice solution required lots of Unix skills, the kind of skills that would likely be in short supply by those interested in OpenOffice automation. We fixed this in this last development cycle, so now a Novell OpenOffice installation will have everything you need.
Michael Hutchinson, one of our MonoDevelop hackers has put together the missing pieces to simplify the process. He has created the solution templates necessary to create these solutions, and packaged them as a Mono.Addin for exiting MonoDevelop users.
To build OpenOffice solutions, you need to install the OpenOffice addin for MonoDevelop. To do this, follow these steps.
Activate the Add-in Manager
Select the OpenOffice Automation Samples
Complete the installation for the Mono.Addin, once you are done, create a new Solution:
You can skip this step, and get back here later, but you might want to select "Unix integration":
Take advantage of code-completion:
This is what the default sample looks like, you can use this as a foundation for your program. Since this is a COM-based API, it is not an API that is easy to discover with code-completion popups, so we figured it was best to ship full working samples:
Build and run your application by hitting F5:
Your OpenOffice solution in all of its glory, this is from the samples that we distribute as part of the templates:
Sadly, the OOo API exposed by UNO does not look or feel very .NET-ish at all. It is a COM-based API and is not very discoverable. Code-completion will sadly not be of much help without the samples.
Additionally, the conventions used in the code are not very .NETish, so it will feel a little bit odd.
There are a few options here, we could either massage the .NET exposed API into something more .NET-friendly, or we could create a wrapper around the UNO API for most common usage scenarios. We are not sure what would be best.
We believe using a Cecil-based tool-massager we could rewrite the cli_types.dll library to get a more .NET-ish API:
This still leaves the issue of interface identity to be solved where an underlying object that always implements IA, IB and IC interfaces is usually only exposed as one of those interfaces, and you must do an explicit cast to the other interfaces to access the other features.
Thanks to the Michaels for all the hard work.
Another beautiful desktop application, this one by David Siegel. I have become a fan of it in the last few months since David started working on it:
Gnome-Do is another very polished application, one that shows a lot of love and care for taking care of the small details. David just released a new version a couple of days ago.
Gnome-Do is inspired by Quicksilver from MacOS and like Banshee, it uses Mono.Addins extensively to make the application more useful:
Go to David's page for more details and screenshots on all the new features (Skype, Flickr, Twitter, IM, Google Calendar integration; community plugins, configuration and more).
Congratulations to the Banshee team for this release!
This is one of the finest applications built with Mono, Gtk#, GStreamer, Mono.Addins, DBus#, C# and Boo. The Banshee developers have worked very hard in creating a very polished UI and have paid a lot of attention to the smallest details to provide an enjoyable user experience.
This really should be considered Banshee 2.0 as SLED shipped two years ago with Banshee 0.10, which was already a stable product.
Since that first public release, a lot of work went into improving the user experience by making Banshee faster and cope better with large libraries. This required new custom Gtk# widgets (these are reusable widgets, with a model-view-controller system, and part of the Banshee Core) as well as rethinking the way that storage was handled by pushing as much work as possible to the SQLite layer and never loading all the data in memory.
The full list of the features will give you a better idea of what this player can do.
This is an architectural overview of Banshee's Core:
Banshee is split up in various components, but most importantly the core does very little work. Pretty much all of the functionality for the media player is implemented as Mono.Addins. Mono.Addins provides services that allow users to install new extensions for Banshee to add new features to the core.
To make it simpler to develop plugins we will be shipping MonoDevelop and VisualStudio templates to get developers started on creating new plugins for Banshee.
For example, Alan McGovern, the creator of MonoTorrent a bittorrent library for Mono and .NET extended the Podcast functionality in Banshee to download your podcasts using Bittorrent (this extension is not part of the 1.0 release).
In the next couple of weeks we will package Banshee for Windows to expand the reach of Banshee to more users. And as part of this distribution we will also distribute templates for Visual Studio developers to create their own extensions.
Congratulations to Joachim, David and the rest of the team at Unity3D for getting this working.
Sample widget from the article.
I recently made the switch to Ubuntu and I am quite delighted with it. I develop mainly on .Net and my dependence on some Windows tools was the sticky point that made me wait this long. This is now not really an issue, thanks to the great work of the Mono and MonoDevelop teams, and the related libraries like Gtk#, Cairo and Pango.
Mono brings the .Net platform to Linux and MonoDevelop offers a good alternative to Visual Studio, making the development of GUI applications on Gtk desktop almost painless.
I wrote a cooperation tool that I use on a daily basis and my first goal after the switch was to port it over with Mono and Gtk#. After a few adjustments caused by the fundamental differences between Windows.Forms and Gtk#, I have to admit that the port of the application was a lot easier that I initially thought; I replaced the UI controls by widgets, set the various forms to use the Gtk# layout, and that is pretty much it. The rest of the non UI code worked as expected with an overall good performance.
An area that gave me the most difficulty was the usage of custom controls with a behavior that is different from the base Gtk components. This is the focus of this article.
Daniel has announced his "Holly Widgets" for Gtk#. A collection of useful Gkt# widgets. The widgets also support MonoDevelop/Stetic integration.
The code is available from http://code.google.com/p/holly-gtk-widgets.
Date and time picker.
Regular expression validating entries.
IP address entry.
Combo box with file system navigation.
Simplified API wrappers:
A simple combobox.
A simple list (avoids TreeView binding, and supports Measure/Draw on a per-item basis).
Simplified tree view API.
Combo box with tree view.
Daniel also has nice samples and documentation for all of his new widgets.