June 30, 2004
§ ¶OneDotZero
As has been announced elsewhere, the long 1.0 push is finished. Miguel did a nice job of recognizing Gtk# developers in the Mono release notes, but I'd like to add my personal thanks for an amazing community effort to get us this far. Using a quick script on the toplevel ChangeLog shows 855 separate commits by 51 unique developers. Add to that another 16 commiters in the docs ChangeLog, plus the numerous folks who submitted docs via the webservice. You guys rock! Step back for a second and look at what we've made.
Okay, enough looking back.
1.0 draws a line in the sand, but we're going to confidently stride over it now and take Gtk# to the next level. In the short term, this means continuing to improve our docs. I don't see much point in binding newer API versions until we've documented the ones that we already have. We've made amazing progress in this area over the last two weeks. I'd like to see us get to 100% doc coverage in the Glib, Pango, Atk, Gdk, Gtk, and Glade namespaces, in addition to everything but the GnomePrint apis in the Gnome namespace before we start binding any new API versions.
The API freeze that we have in place now for 1.0 still allows us to fix broken API bindings. We are also going take advantage of the nice Assembly versioning and GAC functionality of mono to allow the addition of missing API related to the 2.2 Platform and convenience overloads for methods. This gives us a fair amount of flexibility to continue to improve the 2.2 bindings for a while, without breaking existing code developed against Gtk# 1.0. As an app developer, sticking with 2.2 should not disappoint you too much, since using newer API locks your app out of the still enormous Gnome 2.2 installed base.
One thing that has resulted from the big docs push of the past two weeks is a nice backlog of bug reports. The doc pass is also serving as an audit. It makes sense to me to finish this audit and fix whatever problems it identifies before we start thinking about Gtk# 2.0 and the Gnome2.6 platform library versions.
Please keep those docs and bug reports coming.
June 26, 2004
§ ¶Auto detect
Never thought I'd see this day...
My wife installed the drivers for her Canon SD24 digitial camera on her Win2k box, but the photo management software couldn't find a camera attached to the computer. After messing around trying to fix it for about a half hour, I unplugged the USB cable from the Win2K box, plugged it into my FC2 laptop, downloaded the pictures with gphoto2, and uploaded the pictures to one of her NT shares.
Now all we need is Project Utopia to take the manual gphoto2 step out of the process.
June 25, 2004
§ ¶Gecko docs
After rolling the RC1 tarball for Gtk# this morning, I realized I still hadn't added all the license blurbs to the source files. That took a big chunk of today. Much too big a chunk. It's done now, though, so I'll be getting fascist about new file adds from here forward, because I never want to have to do a mass update like that again.
Then Miguel asked me to turn some of my autodocification tools loose on Gecko#. First I had to convert all the old docs over to the new Gecko namespace from GtkMozEmbed. I think I got all the limited documentation that existed before copied over, but there are a lot of TBAs to go.
My sister is in town from Florida with her husband and my nephews. It'll be good to see them again this weekend.
June 24, 2004
§ ¶Doc frenzy
I've more or less run out of big bang doc hacks to fill in large chunks with scripting/reflection. The last day has seen the Gtk namespace TBA count drop to just over 4000. Pretty amazing progress. Thanks to the dozen or so hackers that piled onto the doc effort since yesterday's call to arms.
One question I've had several times is, "Where should I start?" For those who have written Gtk# apps, why not systematically go through your source files with a monodoc window open and check every class, property, event, and method access for documentation. This guarantees you are hitting API that you know how to use, since you are already using it. It also helps us document the high-runner important API first, leaving the stragglers in the corner cases. It also means that you have copy/paste access to good, working example code.
If you haven't written an app yet but are looking to get started with Gtk#, pick an existing app and do the same thing. There are several simple apps in the Gtk# sample directory. There's a substantial chunk of code in mono-cvs and mono-svn already too, in addition to Muine, Woodpusher, Blam!, Monodoc and others. MonoDevelop could probably keep several people busy for a week just stepping through the existing source code. The new GdlDock port is a nice candidate for getting some good subclassing docs going. If you didn't write the code and you want to use it for example code, please make sure the license allows copying it, and attribute its origin.
To avoid duplication, you could post a quick message to Gtk# list saying what app/source files you are doing. I'm excited about the momentum from the last day. Let's keep it going.
June 23, 2004
§ ¶That'll be 25 summaries, please.
My call for documentation seems not to have impressed too many folks. Thanks to all those who have taken the time to improve Gtk# by providing docs. However, unless something changes dramatically in the next week, we are going to ship Gtk# 1.0 with embarassingly incomplete documentation. There are currently over 5000 instances of the string "To be added" in the Gtk namespace alone, for example.
To those of you who have benefitted from Gtk# so far, I'm now dropping to my knees and begging you to stop writing application code for the next week, and write Gtk# docs instead. Many of you are the "I don't need no steenking docs" types when it comes to Gtk#, since most users at this point are frustrated C API users. However, I'd like you to consider how many times you've accessed the MSDN docs while learning to develop on mono and consider how important it will be for Gtk# to have good docs for our larger post-1.0 audience.
Gtk# is free software. As such, we most likely won't have the benefit of millions of dollars of revenues from it to hire a legion of technical writers to document it for its users. If you have saved time using Gtk# vs. using the C API, I ask that you consider donating back 10% of that time now by writing some docs for the project. You're still 90% ahead, right? If you find a bug or need an enhancement and don't know how to provide a patch for it, consider attaching a patch for 25 of those "To be added" documentation elements along with your bug report.
There are docs available for how to write docs. You can use the monodoc browser to edit the docs. There is a webservice running to accept submissions, or you can use monodoc to apply them to a local tree and submit directly if you have cvs permissions. The more people that contribute documentation, the faster it will get done, and the faster I can get back to fixing bugs, and supporting newer GNOME platforms.
Thanks in advance for your submissions.
June 18, 2004
§ ¶Frost bite
I posted a message about an adjustment to the API Freeze Policy for Gtk# 1.0.
Defining and maintaining an API stability guarantee for a language binding is different in some ways than for a traditional library. In a language binding, almost everything is API, once you've gotten down your binding mechanics. In a generated binding, this is even more the case, since you don't have the typical manual screwups that need bugfixing.
Hopefully with this new exception policy in place, we'll be able to continue to improve the usefulness of the 1.0 release without having to declare another API unstable release line targetting the GNOME 2.2 platform. I don't think having 1.0 sitting as an immutable object benefits anybody in the long run. The more timely we are able to improve the API completeness of the 1.0 line itself, the fewer workarounds we'll end up with out in user code.
June 16, 2004
§ ¶Dog Days
Summer may not officially start until Sunday, but...
Trying out pivot after Martin's glowing praise. It's not too bad of a conversion, although I messed with the stylesheet and templates considerably. I don't think it looks too horrible now, but I'm sure many of my css-skilled readers will disagree. ;-) I liked the clean, boring look of the default MT templates.
It's haaaawwwwt, ya'll.
June 15, 2004
§ ¶Time wasting
Here's a helpful page for anyone considering a move from MT to pivot. The export/import of my MT entries worked like a charm.