Loud ramblings of a Software Artisan

It all started with a sketch on paper (beware of my poor penmanship).

I was thinking how I can build a musical instrument in software. Nothing new here actually, there are even applications like VMPK that fit the bill. But this is also about learning as I have started to be interested in music software.

This is how Minuit is born. The name come from a mix of a play on word where, in French, Minuit is midnight and MIDI is midday. MIDI of course is the acronym Musical Instrument Digital Interface, which is the technology at the heart of computer aided music. Also minuit sounds a bit like minuet which is a dance of social origin.

I have several goals here:

1. learn about MIDI: The application can be controlled using MIDI.
2. learn about audio: Of course you have to output audio, so now is the best time to learn about it.
3. learn about music synthesis: for now I use existing software to do so. The first instrument was ripped off Qwertone, to produce a simple tone, and the second is just Rhodes toy piano using soundfonts.
4. learn about audio plugins: the best way to bring new instruments is to use existing plugins, and there is a large selection of them that are libre.

Of course, I will use Rust for that, and that means I will have to deal with the gaps found in the Rust ecosystem, notably by interfacing libraries that are meant to be used from C or C++.

I also had to create a custom widget for the piano input, and for this I basically rewrote in Rust a widget I found in libgtkmusic that were written in Vala. That allowed me to be refine my tutorial on subclassing Gtk widgets in rust.

To add to the learning, I decided to do everything in Builder instead of my usual Emacs + Terminal combo, and I have to say it is awesome! It is good to start using tools you are not used to (ch, ch, changes!).

In end the first working version look like this:

But I didn't stop here. After some weeks off doing other things, I resumed. I was wondering, since I have a soundfont player, if I could turn this into a generic soundfont player. So I got to this:

Then iterated on the idea, learning about banks and preset for soundfont, which is straight off MIDI, and made the UI look like this:

Non configurable instruments have a placeholder:

There is no release yet, but it is getting close to the MVP. I am still missing an icon.

My focus forward will be:

1. focus on user experience. Make this a versatile musical instrument, for which the technology is a mean not an end.
2. focus on versatility by bringing more tones. I'd like to avoid the free form plugins but rather integrated plugins into the app, however leveraging that plugin architecture whenever possible.
3. explore other ideas in the musical creativity.

The repository is hosted on GNOME gitlab.

No, AbiWord is not dead. The project has been very very slow moving due to very little contributions. But sometime a spark ignite things.

Martin needed to fix a major issue we had related to how AbiWord uses Gtk wrong

Then I took some time to perform two long overdue tasks:

1. Moving to git. We have had a complete mirror of the Subversion repository for a few years on Github. But now that GNOME moved to their own Gitlab, I felt that this was a more appropriate place for AbiWord. So we did. Thanks to Carlos Soriano, AbiWord is now hosted in GNOME World.

2. Making AbiWord available as a Flatpak. This would alleviate all the issues plagging us wher distribution never update the app, even on the stable branch. For a while I had a manifest to build it, all it needed were a few adjustments and reaching the hosting stage.. Thanks to the Flathub team, AbiWord 3.0.2+ is now available on Flathub. Check it out.

The next steps:

1. Release 3.0.3 (the current stable branch) and update the Flatpak.

2. Release 3.next (I think it will be 3.2) as the next stable branch. This one includes a large set of fixes that should fix lot of crash and memory corruptions.

3. Work on more incremental release. With Flatpak this will be easier.

4. Gtk4 port: we might hit some roadblock with that.

I have started something crazy a few weeks ago: porting my app from C++ to Rust.

I'll talk about it here, in several parts.

This is Part 1.

Context

Once upon a time I started to write a Free Software photography application for GNOME. That was around 10 years ago.

At the time I chose to use C++ and Gtkmm 2.x. C++ because it provide unprecedented interoperability with existing C code while offering a stronger type system, RAII and template which allow safer programing pattern without a large overhead at runtime. Absolutely no regrets on that.

Over the years, despite never having been released, the code base was updated to C++11 and Gtkm 3.x.

Meanwhile Rust was developed at Mozilla. And Rust provide safety and high performance, but doesn't have the same ease of interoperability with a C codebase - albeit still make it easy.

Why

Why am I porting to Rust?

• Rust is designed to be a safe language. In this day an age of 0day due to the use of C (and C++) and their unsafe practice, it is something important.
• I want the application to be multi-threaded (it already is in design), which is one of the design goal of Rust.
• I started writing other stand alone components in Rust.

The goal is to progressively rewrite the application in Rust, mostly translating the logic from C++ to Rust. It is not the first time I do that across languages. I'll go from the back to the front, the front being the UI written with Gtkmm.

Several steps.

Build system

There have already been a few posts about integrating Rust into an automake based build system, by Federico or by me. The gist of it is to make sure you build your library with Rust and link it to your application.

Building Rust code is trivial using cargo. There is no point using anything else.

Interfaces

When doing an ad-hoc conversion, the biggest problem is calling code write in one language from the other.

You can not call Rust methods or generic functions from C/C++, so you'll need to have some interface in place. Rust has made it relatively easy by using C calling convention and making easy to declare a function with mangling disabled.

Example:

#[no_mangle]
pub extern fn my_function(arg1: &Type1) -> RetType {

}

From C/C++ this would be something like:

extern "C" RetType my_function(const Type1* arg1);

Here we assume that RetType is a POD (Plain Old Datatype, like int, char, float), not a C++ class, nor a struct in Rust.

There is a tool called cbindgen that will generate C/C++ header from the Rust code. You can call it from the Rust build system to do that automatically. More on that later.

Calling C code from Rust is easy provided you have the proper interfaces. It is basically the reverse of the above.

But calling C++ methods on the other hand, you have to use bindgen.

Bindgen

Bindgen will generate from C/C++ header Rust modules to call C++ code.

The tool is pretty amazing to not say magical. Albeit there are some pitfalls.

For example a C++ class with a std::vector<> as a member will a problem if treated as opaque type. To be honest I am not sure if it would work as a non opaque type.

The use of boost might actually generate Rust code that doesn't compile.

Running the Rust test with cargo test will fail. I think it is Issue 1018.

There are a few things I recommend. Most notably, treat types as opaque whenever possible ; whitelist types and functions rather than blacklist. Your mileage may vary but this is what I got to work in my case.

Using these tools I managed to actually rewrite the large parts of the backend in Rust with equal functionality. Progressively more C++ code will be replaced.

I'll get into detail in a future post.

Once upon a time, I started geotagging my photos. For that I bought a GPS logger, an Holux M-1200E. The device works great with gpsbabel, and since my photography workflow was stuck on MacOS, I used Houdah GPS (which uses gpsbabel behind the scene, BTW). Also I have been working for too long on moving that workflow to Linux and GNOME. At one point I even started to write an app I called "Magellan" to do what that MacOS tool did, as a part of my other project, Niepce. I didn't really get motivated so it went nowhere. It was written in C++ like the rest of Niepce. The technology isn't the problem here.

Fast forward, my photography machine got upgraded to a more recent version of its operating system after the one I was using was abandonned by browser vendors, and it happens that in that upgrade, the GPS logger stopped working because MacOS 10.11 stopped providing the USB->Serial driver needed. I could install some random driver, but given how much trust I have, I decided to pass. On Linux, it still works.

I had already started rewriting Magellan in Rust using gtk-rs ; I did that as just another Rust learning project. This breakage came right as a good motivator to actually push the development of that application and make it work. And it does.

The name "Magellan" was already used for some GPS related product (not surprising), so my app became GPS Ami ("Ami" means "friend" in French).

The design

I basically reimplemented Houdah GPS, UI and such. It works OK, but I think it will act as a transitionary state. I have bigger plans.

Notably, I want to allow a better control of the device, like what bt747 can do - my logger is based on that chipset, and other automation feature so I can use GPS Ami from Niepce to download the tracks. I currently only tested with the device I have.

The implementation

As explained before GPS Ami is written in Rust and uses gtk-rs for the UI. I have to be honest, gtk-rs is not ready for prime-time, but it looks very promising and I'm very happy to be able to contribute as needed. Not surprising, but you should be ready to have to put your hands in it if you want to use it. I did just that: provided more APIs, filed some bugs, sometime fixing them. I also had to implement gudev-rs to be able to have gudev functionnality for device hotplug — to plug into the mainloop. This was a learning experience.

Rust tooling is a lot about generating a monolithic binary, without data files. This is not bad per see, but when you need data files like .ui from glade to load the UI in Gtk (albeit this not required on Gtk side, it is more convenient), you are a bit stuck. Fortunately there is the includestr!() macro in Rust which mean "load this file at compile time and put it in this string".

Another problem I had was installing the rest of the files, like the .desktop or icons, problem I solved by wrapping cargo into an automake build system.

On overall, I'm just calling gpsbabel from a UI to download file.

The future

So what should come into the future?

• polish the UI more, possibly tweaking it. This will probably require more gtk-rs work. IMHO there are a few show stopper for a first version.

• implement a driver for this GPS, in Rust so that the actual driver be written in memory safe language.

• see about adding more control feature: we should be able to read the GPS values like it is done in bt747.

• support other devices officially (I don't have any other though)

Help wanted

• I don't have an icon

• I only have one device to test with

A couple of weeks ago, I released gudev-rs, Rust wrappers for gudev. The goal was to be able to receive events from udev into a Gtk application written in Rust. I had a need for it, so I made it and shared it.

It is mostly auto-generated using gir-rs from the gtk-rs project. The license is MIT.

Source code

If you have problems, suggestion, patches, please feel free to submit them.

How to take a screenshot on an Android phone, a Google Nexus One in my case. I have to document it, because "home + power" like on an iPhone (or any iOS device) is far too complicated.

Warning: this post contain whole parts of ranting and sarcasm.

1. Configure your phone to allow USB debugging.
2. Install the Android SDK
3. Connect the phone over USB
4. Start ddms from the Android SDK
5. Select your phone.

Kaboom. It crashes.

01:42:04 E/ddms: Failed to execute runnable (java.lang.ArrayIndexOutOfBoundsException: -1)
org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.ArrayIndexOutOfBoundsException: -1)
	at org.eclipse.swt.SWT.error(Unknown Source)
	at org.eclipse.swt.SWT.error(Unknown Source)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Unknown Source)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Unknown Source)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)
	at com.android.ddms.UIThread.runUI(UIThread.java:517)
	at com.android.ddms.Main.main(Main.java:116)
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
	at org.eclipse.jface.viewers.AbstractTableViewer$VirtualManager.resolveElement(AbstractTableViewer.java:100)
	at org.eclipse.jface.viewers.AbstractTableViewer$1.handleEvent(AbstractTableViewer.java:70)
	at org.eclipse.swt.widgets.EventTable.sendEvent(Unknown Source)
	at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
	at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
	at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
	at org.eclipse.swt.widgets.Table.checkData(Unknown Source)
	at org.eclipse.swt.widgets.Table.cellDataProc(Unknown Source)
	at org.eclipse.swt.widgets.Display.cellDataProc(Unknown Source)
	at org.eclipse.swt.internal.gtk.OS._gtk_list_store_append(Native Method)
	at org.eclipse.swt.internal.gtk.OS.gtk_list_store_append(Unknown Source)
	at org.eclipse.swt.widgets.Table.setItemCount(Unknown Source)
	at org.eclipse.jface.viewers.TableViewer.doSetItemCount(TableViewer.java:217)
	at org.eclipse.jface.viewers.AbstractTableViewer.internalVirtualRefreshAll(AbstractTableViewer.java:661)
	at org.eclipse.jface.viewers.AbstractTableViewer.internalRefresh(AbstractTableViewer.java:635)
	at org.eclipse.jface.viewers.AbstractTableViewer.internalRefresh(AbstractTableViewer.java:620)
	at org.eclipse.jface.viewers.StructuredViewer$7.run(StructuredViewer.java:1430)
	at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1365)
	at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1328)
	at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1428)
	at org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer.java:537)
	at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1387)
	at com.android.ddmuilib.logcat.LogCatPanel$LogCatTableRefresherTask.run(LogCatPanel.java:1000)
	at org.eclipse.swt.widgets.RunnableLock.run(Unknown Source)
	... 5 more

En voila. You still haven't taken a screenshot.

And for the record, I'm aware that Android 4.0 can do it, but Google still hasn't provided an update for the Nexus One (their first flagship device) and is unlikely to do it. That's not really encouraging into buying a newer device.

Update: upgraded to platforn tools version 11 and still the same problem.

See part 1 if you haven't.

As of this week, some changes in b2g cause more breakage in the build process on Fedora. Plus some various bugs.

First, if when doing the make config-galaxy-s2 you get the following error:

cp: cannot create regular file `../../../vendor/samsung/c1-common/proprietary/etc/mdnie_tune_bypass_mode': No such file or directory

in the B2G directory, do a

mkdir ./glue/gonk/vendor/samsung/c1-common/proprietary/etc

and try again.

Also, make gonk will want to run a pre-build xulrunner in 32-bits

• freetype.i686
• fontconfig.i686
• alsa-lib.i686
• dbus-glib.i686
• pango.i686
• gtk2.i686
• libXt.i686

Ideally, the fix would be to actually get a 64-bits xulrunner instead. Patches welcomeâ„¢ I was told. On your copious-spare-timeâ„¢.

Since tomorrow I'll be in Montreal for LGM, today will be release day for Gnote 0.3.1 "Five-One-Four". Next week should be back to the regular schedule. This is a bugfix release, and it is available on GNOME FTP as usual.

The changes are:

Fixes:

• Missing header in src/addins/inserttimestamp/inserttimestampnoteaddin.cpp
• Don't crash when deleting a note (Closes #579839)
• Plugged various memory leaks.
• Cleared up a few Gtkmm warnings.
• Applet was trying to use an icon named "tomboy" (Closes #581226) (Robert Millan)
• .desktop file didn't have the version (Jonathon Jongsma)
• .desktop has improper XFCE category and should have OnlyShowIn entry for GNOME and XFCE (Closes #580481)
• Help didn't work in the Note windows. (Closes #581200)
• Notebook addin toolbar button was inconsistent. (Closes #581213)
• Delete notebook now works in the search dialog. (Closes #581222)
• Popup menus in the search dialog now appear.
• Output options at the end of configure and fail if D-Bus is enabled.

Translations:

• Added translations: - Japanese (ja)
• Updated translations: - Arabic (ar) - Catalan (ca) - French (fr) - Spanish (es)
• Fix format causing crashes. (Closes #580868)
• Fix a typo in the gconf schema description (Closes #581239)
• Fix small translatable strings (Closes #579197)

Wednesday is release day for Gnote. Version 0.3.0 is now available on GNOME FTP.

Here is the changelog:

New features:

• Applet support (Closes #578979).
• Print addon.
• Insert Time Stamp addon.
• Bugzilla addon.
• Implement addin preferences.

Fixes:

• Should now build if Gtk+ 2.16 is present but not Gtkmm 2.16.
• Should build with Gtk+ 2.12 and Gtkmm 2.12 (Closes #580250) (Robert Millan)
• Fix a typo in gnote.1 (Closes #580211) (Robert Millan)
• Desktop file reflect XFCE and bugzilla component. (Closes #580481) (Ritesh Khadgaray)
• Missing accelerators in link context menu (Closes #580443) (Mário Machado)
• Reference bugzilla component in server file (Closes #579198)

Translations:

• Short descriptions in shema must not end with a '.' (Closes #579337)
• Added translations: - British English (en_GB) - Czech (cs) - Portugese (pt) - Spanish (es) - Thai (th)
• Updated translations: - Arabic (ar) - German (de)

I just released Gnote 0.2.0. Here is the changelog:

New features

• Now support addins (Bug #578980): - Fixed Width
• Show addins in preferences.

Fixes:

• Can now close the template note opened when the Preferences dialog is open. (Close #579105)
• Check for Gtk+ 2.14 or later and include gtk/gtk.h in src/utils.cpp (Close #579240)
• Fix wrongly highlighted URLs and a crash when inserting in some situation. (Close #579225)
• Fix offsets on WikiWord (similar to bug #579225)
• Initialize gettext properly (Close #579520)
• Properly check for libxml2.
• Drag and drop of notes to a notebook (Close #579637)
• Fixed hang when changing the title of a note (Close #579362)
• The open state of notes is now saved properly.

Translations:

• Update comment to reflect format in strings. (Close #579209)
• Ensure the spelling of Gnote.
• Some strings shouldn't be translated. (Close #579197)
• Date format are non localizable. (Close #579207)
• Properly use plural forms (Close #579412)
• Remove markup from translatable strings (Close #579453)
• Added translations: - Swedish (sv) - Greek (el) - Arabic (ar) - Catalan (ca) - German (de) - French (fr)

Many thanks to the translation teams and the people who provided feedback.

The tarball can be downloaded fronm GNOME FTP

There is more to come: the addins (I had to rewrite an addin system based on Glib::Module, which I hope will be generic enough ; I'll see when I integrate it into Niepce), the synchronization (I have a branch locally that I need to test thoroughly, for which I also needed addin support), and what not.

In my attempts to fight my own boredom, as an unemployed hacker^[1], I took on myself to do something: porting Tomboy to C++. It is actually not that hard, just a lot of work to do manually because there is over a dozen of thousands of lines of code. This show me that the door is open to reimplementing Gtk# software (or parts) in C++ with not too many problems, making it easy to have them available for C applications.

Nonetheless there are still some challenges:

1. Garbage collection: I replaced this with a combination of Gtkmm memory management, std::tr1::shared_ptr<> and stack allocated object. Seems to be working so far. I could also be using a garbage collector, but it seems to be unecessary.
2. String and file path utilities: Boost has string algorithms and Boost.Filesystem
3. XML: while XML parsing is not a big issue with the various libraries available, APIs have enough difference to make it non-trivial. I also had to write a convenient wrapper of xmlTextWriter to make my life easier.
4. Add-ins: I don't have the support for generic addins as found in Mono. No big deal, I implemented a factory in a few lines with a couple of macros. Some core features are actually implemented as add-ins, so I had to do it. Dynamic loading shouldn't be too hard.
5. regex: some of these core feature use regulars expression. Not a big deal if it wasn't for apparently different syntax.

To help all of this, I have implemented a small library (in the same tree) called "sharp" aimed at helping port from Gtk#. In addition to boost, I also make an extensive use of Gtkmm and libxml++.

Of course the code is available. I have set up a repository on gitorious (Edit: Apr 1st 2016) — it is in GNOME git ; gitorious is dead.(/Edit) There is no tarball yet as I still need to iron a few major bugs. On over 13KLOC of code, there are to be some :-)

Over the last week I spent some time rewriting bits of the AbiWord Gtk+ code to build with GTK_DISABLE_DEPRECATED defined. It took longer than expected as I originally thought that it was no more than 4 dialogs, but I was wrong... It is like a can of worm. I also fixed a few bugs in the mean time.

• AbiWord: Martin finally removed gnome-print, based on Rob SoC Cairo-based graphic layer. I'll finish it off with configure. The best way to make sure it is gone. Now taking care of libgnomeui that was used for one single call that can be replaced by something from gnome-vfs or Gtk+ 2.14.
• Some questions on IRC about using Exempi. Looks like I really need to sit down and write some documentation. The grunt work is already done.
• Nice to see a team really taking care of the DVCS migration instead of debating on the mailing list. See GitMigration.
• Helped Vincent debug a crash with Nautilus caused by a conflicting extension (who shall remain nameless) who cause Nautilus to crash when plugging a USB device. "Conflicting extension", bad memories of 15 years ago. At least this we can fix when it is Free Software.
• A Linux based camera from Sony. I wonder how hackable it will be. Not holding my breath, I just want to be wrong on that.
• Palm announced a new Linux based handset. Yet another platform named WebOS, probably not open, and probably not compatible either, with a SDK on based on WebKit + JavaScript. Déjà Vu. Will they ever learn? I'm still surprised the company is still alive with all the mistake they did.
• The return of the Polaroid instant camera, but digital. Nothing to do with Linux or Free Software however.

No I won't be presenting a Gtk+ HelloWorld, but just the valgrind output of one. It actually does not matter what program.

==28869== Syscall param rt_sigaction(act->sa_mask) points to uninitialised byte(s)
==28869==    at 0x40007F2: (within /lib/ld-2.6.1.so)
==28869==    by 0x483A7A2: sigaction (in /lib/libpthread-2.6.1.so)
==28869==    by 0x5562321: google_breakpad::ExceptionHandler::SetupHandler(int) (in /usr/lib/gtk-2.0/modules/libgnomebreakpad.so)
==28869==    by 0x556242D: google_breakpad::ExceptionHandler::SetupHandler() (in /usr/lib/gtk-2.0/modules/libgnomebreakpad.so)
==28869==    by 0x55626D7: google_breakpad::ExceptionHandler::ExceptionHandler(std::string const&, bool (*)(void*), bool (*)(char const*, char const*, void*, bool), void*, bool) (in /usr/lib/gtk-2.0/modules/libgnomebreakpad.so)
==28869==    by 0x5561DE2: gtk_module_init (in /usr/lib/gtk-2.0/modules/libgnomebreakpad.so)
==28869==    by 0x41AB1EC: (within /usr/lib/libgtk-x11-2.0.so.0.1200.0)
==28869==    by 0x46472E9: g_cclosure_marshal_VOID__PARAM (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x463A918: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x464D9EC: (within /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x464F63E: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x464F988: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==  Address 0xbec4e5f4 is on thread 1's stack
==28869== 
==28869== Syscall param rt_sigaction(act->sa_mask) points to uninitialised byte(s)
==28869==    at 0x40007F2: (within /lib/ld-2.6.1.so)
==28869==    by 0x483A7A2: sigaction (in /lib/libpthread-2.6.1.so)
==28869==    by 0x5562321: google_breakpad::ExceptionHandler::SetupHandler(int) (in /usr/lib/gtk-2.0/modules/libgnomebreakpad.so)
==28869==    by 0x5562445: google_breakpad::ExceptionHandler::SetupHandler() (in /usr/lib/gtk-2.0/modules/libgnomebreakpad.so)
==28869==    by 0x55626D7: google_breakpad::ExceptionHandler::ExceptionHandler(std::string const&, bool (*)(void*), bool (*)(char const*, char const*, void*, bool), void*, bool) (in /usr/lib/gtk-2.0/modules/libgnomebreakpad.so)
==28869==    by 0x5561DE2: gtk_module_init (in /usr/lib/gtk-2.0/modules/libgnomebreakpad.so)
==28869==    by 0x41AB1EC: (within /usr/lib/libgtk-x11-2.0.so.0.1200.0)
==28869==    by 0x46472E9: g_cclosure_marshal_VOID__PARAM (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x463A918: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x464D9EC: (within /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x464F63E: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x464F988: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==  Address 0xbec4e5f4 is on thread 1's stack

Apparently this is a known bug.

Also when quitting, --leak-check=full is revealing:

==28869== 2,048 bytes in 1 blocks are definitely lost in loss record 143 of 184
==28869==    at 0x4022AD8: malloc (vg_replace_malloc.c:207)
==28869==    by 0x55623E5: google_breakpad::ExceptionHandler::SetupHandler() (in /usr/lib/gtk-2.0/modules/libgnomebreakpad.so)
==28869==    by 0x55626D7: google_breakpad::ExceptionHandler::ExceptionHandler(std::string const&, bool (*)(void*), bool (*)(char const*, char const*, void*, bool), void*, bool) (in /usr/lib/gtk-2.0/modules/libgnomebreakpad.so)
==28869==    by 0x5561DE2: gtk_module_init (in /usr/lib/gtk-2.0/modules/libgnomebreakpad.so)
==28869==    by 0x41AB1EC: (within /usr/lib/libgtk-x11-2.0.so.0.1200.0)
==28869==    by 0x46472E9: g_cclosure_marshal_VOID__PARAM (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x463A918: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x464D9EC: (within /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x464F63E: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x464F988: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x463ECC0: (within /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x463B68E: (within /usr/lib/libgobject-2.0.so.0.1400.1)

Hint: this is not in Gtk+.

Hint2: neither is it because it is written in C++

I have been using Gtkmm a lot for a personal project.

I discovered that you can pass boost::bind to Gtkmm signals (that use sigc), thanks to the magic of templates.

Something like that:

m_selection->signal_selected
    .connect(boost::bind(&LibraryMainView::on_selected,
        m_mainview, _1));

Why? Because I'm more familiar with Boost.Bind and for me it looks more flexible. Also because you can pass a shared_ptr<> to it, unlike with sigc::mem_fun.

Sometime you have to check for different versions of a packages with pkg-config because of new APIs. I had to query the lazyweb and I ended up finding something. Here is the configure.ac snippet I wrote:

GNOMEVFS_VER=0
PKG_CHECK_MODULES(GNOMEVFS, [gnome-vfs-2.0 >= 2.14],
[
  GNOMEVFS_VER=214
],
[
  PKG_CHECK_MODULES(GNOMEVFS, [gnome-vfs-2.0 >= 2.12])
  GNOMEVFS_VER=212
])
GNOMEVFS_CFLAGS="$GNOMEVFS_CFLAGS -DGNOMEVFS_VER=$GNOMEVFS_VER"

Something I haven't seen often is that PKG_CHECK_MODULES allow found and not found action blocks (yes this is in pkg-config main page). The default not found action is to fail. The above code works as follow: check the highest version you need, if not found check the one you can eventually go away with. Define a symbol with a numeric version and pass it to the modules CFLAGS.

Then in the code do:

#if GNOMEVFS_VER >= 214
...
#endif

Dear LazyWeb,

I'm looking for a proper documentation on how to add "books" to DevHelp. The current DevHelp documentation is inexistent, and said documentation isn't generated by gtk-doc.

Thanks

I just added Jan to Planet OOo. Jan recently joined our team at Novell and is working on the UI layout system that was started by Ricardo as part of the summer of code. Read back the history of is blog if you are really interested.

But what is this UI layout system about? It is about making VCL layout widgets as boxed containers instead of pixel sized container. This will allow dialogs to looks nicer on the different platforms (like with Gtk+), and be resizable dynamically (people doing localization will understand).

Welcom Jan.

I ran into a limitation of Glibmm while using std::for_each() with boost::bind() and Glib::RefPtr<>.

boost::bind() works well with any of the Boost.SmartPointer, or with raw pointers, but not with Glib::RefPtr<> as it lack the get_pointer() function.

I tried to do this:

Glib::RefPtr<Foo> foo;
std::vector<Bar> v;
/* ...initialize foo and v */
std::for_each(v.begin(), v.end(), 
	boost::bind( &Foo::do_something_with_bar, foo, _1 );

But it failed to compile as I was missing the function below.

namespace Glib {
/** Dereference Glib::RefPtr<> for use in boost::bind */
template< class T_CppObject >
T_CppObject *get_pointer(const Glib::RefPtr< T_CppObject >& p)
{
	return p.operator->();
}
};

Some explanations: the function is templated to work with any instance of Glib::RefPtr<>. It is in the the Glib namespace, and will be looked up naturally by the Koenig lookup which in principle allow looking the function up in the same namespace that the argument is in. It uses this ugly operator->() member call because there is no other way to get the raw pointer from the Glib::RefPtr<>, but this is an implementation detail.

Filed bug 495762. Adding it to Glibmm will not break the ABI as it is not a method, and it is a template function, hence instantiated locally. Maybe it could be maybe inline.

The above code is either under the same license governing Glibmm which is LGPLv2+.

Apple has never been Free Software friendly with their iPod. The whole business is based on the vendor and application lock-in of iTunes.

But this time it is apparently worse. Apparently Apple has decided that the database file for the song has to be validated with some cryptographic hash, or it appears to be. If the hash is not valid, the iPod refuse to playback any music (source). Read also BoingBoing's Cory Doctorow rant. This make gtkpod, Rhythmbox, Amarok and all these fabulous tools no longer working with the new devices.

How long before it get cracked? No idea. But one thing is sure. If you use Linux, don't buy an iPod. If you use OpenSolaris, don't buy an iPod. If you use BSD, don't buy an iPod. If you don't like this way of doing things, don't buy an iPod. I'm actually surprised that this didn't happen sooner, or maybe I'm like seeing too much evil or a giant conspiracy in what is an implementation detail...

Update: Lennart remind us some facts. I guess I might not be that wrong.

Random bits from Guadec:

• Thanks to Opened-Hand and Collabora for the free beer at the party last night at the Walkabout. Lot of fun have been had, still feeling it. Thanks to Becky and Sinead for the bar :-) I really need to post more pictures. Thanks for picking the tab, Rob!

• Swag: got 5 t-shirt. 3 from the conference, 2 from Collabora. Note to people giving away swag: maybe tinking about the other pieces of clothing? Why not giving away boxers, socks and pants?
• Robots controlled by Nokia 800 looks fun.

• Epiphany with WebKit! Fabulous. You rock guys! I need to scratch an itch and do that for liferea. I'm sure it will be easier than debug the GtkMozEmbed plugin.
• SD card in slot cause suspend to fail on my Z60t. Need to pokeage the bug tracker to report it.
• Online desktop keynote by Havoc and Bryan: not sure I get you guys. What I'd love to see is a free software solution that provide similar features that Apple's iDisk and "iSync service"^[1]. That way we would have the choice of providers to use and not rely on one unique.
• Jono and Haddess gave me unvoluntarily an application idea for the Nokia: using the Nokia as both a presentation remote control (over bluetooth) and a slide note cheat card (ie the slides notes on the Nokia screen).
• Wore my aKademy 2006 T-Shirt.
• The T-Shirt Edward was wearing last night is fun. Pure coincidence that this rant appeared on planet Debian?

• Didn't really hack anything.
• The most popular distribution seems to be Ubuntu. Like KUbuntu was at aKademy 2006.
• Monday, Marc did present AbiCollab. This feature is currently unique to the Linux version of AbiWord. Unfortunately Marc had to leave the conference earlier.

• J5, it is ONE laptop per child. Not two !

Nothing was lost in the browser and in the last years, Firefox has taken back some point in the browser market. So interestingly that after disbanding the team and not doing anything on IE for 5 years but plugging security holes, Microsoft decided to release IE 7, solely for XP SP2 and upward, in the hope to regain some market.

But this is not without counting on Safari.

Safari by itself made Microsoft not develop IE Mac anymore a by itself took a good chunk as the Mac market is somewhat growing a bit. The interesting part is that it is not based on Gecko, but on KHTML, turned into WebKit. Lars Knoll interview gives us a brief overview of the past and the future of KHTML and WebKit development, notably how Apple collaboration ended up working well and how KDE4 will have KHTML coming directly from Apple's repository^[1]. Now the WebKit for Windows is about to disturb the source: Apple's Windows port did land in the repository, and that port has apparently no relation with the non contribution from Adobe for WebKit + Cairo on Windows^[2]. I'm still unsure of the direct benefit of the port source code for Free Software, as it apparently use a mix between Windows native GDI and Apple own proprietary CoreGraphics (delivered as a non-free DLL^[3]), but nonetheless.

Now how will that still matter for Free Software?

It brings a standard compliant Free Software web rendering engine a broader audience, on that it is different from Gecko. Competition is good, and diversity is good. This engine is at the heart of KDE4, and is being brought to Gtk by the work put in by various contributors, including Alp's port to Maemo (Alp, you rock dude) making it valuable for GMAE and Gnome in general. Nobody will argue, Gnome is in dire need to something better than Gecko for its HTML needs: DevHelp, Yelp, Liferea, Evolution, etc would all benefit from it. All the enhancements made to the main engine, including support for new standards will directly serve the purpose of any Free Software using it.

Even more, being the browser inside the iPhone (and actually Apple's blessed development platform for the iPhone^[4]), this could leverage enough market share to make WebKit a major browser and have actually enough power to convince the Web 2.0 developers to ensure their development are compatible^[5] with it. And that is something noticeable. Remember when IE was the only browser tested and that developer didn't care to fix their mistake or standard conformance because anything else was too small for them?

Adobe, to be able to make their proprietary^[1] platform for application developement, using Flash, did use the Open Source WebKit (that same HTML engin that Apple use for Safari, that is based on KHTML). The paradox is that to have WebKit work on Windows, they used Cairo as a backend. The good news is that Cairo is likely to get better and that WebKit using Cairo is likely to help greatly a Gtk based version.

Changes are available for people to use.

The OpenMoko software platform has been released. OpenMoko is the the project initiated by FIC in Taiwan. Apparently the hardware is late, but they released the software still.

On the other hand, the Access Linux Platform has been released, and its openness looks much less appealing. ALP is the successor of PalmOS and is based on Linux.

They are both based on Gtk+ for their toolkit. That open more deployments for AbiWord.

Linux on phones is spreading.

• Installing GPE on a Motorola A780. But for now you lose the phone functionality.

• OpenMoko or the open source platform for cell-phone with a decent price. They claim to be exclusively open source. It is based on Linux and Gtk/X11 leveraging the OpenEmbedded platform. Some interesting point is that the phone module is separate and communicate with a serial connection.

Time to port AbiWord on GPE and OpenMoko? We already have a Maemo version.

So after my last post I investigated a bit.

First I have to say that C++ is NOT a problem. It is perfectly possible to provide API for C++-incompatible applications/developers. It does not matter what is the underlying language, even more when said language integrate very well with the existing C framework.

Dobey:

You clearly don't know about KHTML. KHTML4 as of today is in the WebKit repository, that same WebKit from Apple. It is called Unity and is the result of the cooperation of the WebKit developers at Apple and the KDE people.

On MacOS, for example, WebCore does not hard-depend on Qt, even less on KDE. Even if it were, I would still consider a Qt dependency less a problem than, for example, Mono or Python. GtkWebCore is dead, and there is actually Gtk support in WebKit. See for yourself. And that is where the future lies. The current status is "sort of work", ie you can display pages, but you miss forms and other things.

As of GtkHTML, it is not because it is used that it is a good solution. The lack of support for recent web standard is probably its biggest problem. And bringing that on par is probably more work than one might expect. The Web is a huge mess. Going towards fixing GtkHTML is probably doomed to failure. Wasn't GtkHTML originally a rewrite of KHTML in a non object oriented language? And clearly the easiest route is to finish the port of WebKit.

Gnome is in real need of an lighter but powerfull HTML widget. Could be used by Gaim (like Kopete and AdiumX do), could be used by Yelp (shrinking down the memory usage of Mozilla), by Liferea, Evolution, etc.

GtkHTML ? I pass.

GtkMozEmbbed ? Too big and complex.

Actually something based on KHTML/WebKit would be a killer. Even Adobe use it (thanks Aaron Seigo for the link). Can the lazyweb enlighten us on the status of GtkWebCore? The thing on sourceforge seems to be dead.

I wonder the feasibility of including KHTML4 in a Gtkmm application now that we have Qt/glib integration.

Ralph Thomas posted his patch for Gtk+ support in ASL 1.0.20. That means that Adobe Source Library, which originate from Photoshop, can now be used to develop Gtk application in C++. Note that this patch is the result of porting Mission Photo work to the latest ASL.

For some screenshots, go there

The Gnome destkop-devel mailinst list have had a huge flamewar^wdiscussion about including Tomboy in the desktop. But Tomboy is written in C# and thus require Mono to run. That led to an including Mono into Gnome debate, etc.

But now there is Jason who wants to port Tomboy in C++ using gtkmm. His motivation is purely fun and education (learning Gtkmm programming), but I find that a good idea, given that he wants to translate C# to C++. Why would that be a good idea? Because it would should whether or not the resource usage is better. Let's see how this experiment works, and I look definitely forward to the result.

And my take on that discussion: Gtk#, the Mono bindings Gnome deserve to be in the plaform binding given that they meet the requirements. But I don't think the Mono platform should be in the Gnome platform, hence any program in the platforme depend on Mono. Whatever amount of coolness is in these apps (I really like Tomboy and f-spot), I think that sometime decisions like this should be made.

Update: let me repeat. Jason's goal is educational.

Note: this only represent a personal view and does not represent the view of the AbiWord project.

I asked myself a question: shall we focus on one true Open Source platform, or shall will disperse the effort, trying to compete with the two other OS vendors, and waste lot of resources on that with more flexibility by maintaining AbiWord on Win32 (using Win32 APIs) and on MacOS X (using Cocoa)?

One of the "selling point" of AbiWord was that it was multiplatform, and unlike OpenOffice, it was using the native toolkit of each platform, ie Win32 on Windows, Gtk+ on UNIX and Cocoa on MacOS X. But this advantage is in fact being a real constrain, slowing us down in our developments. Writing a cross-platform UI is no picnic. It actually requires a lot of efforts and compromises, and these compromises are sometime really hard. For example there is still no support for SVG in AbiWord because one of the issues is printing them. To print them you need to provide these vectors to each and every printing backend, which is not an easy task: just rastering as a bitmap is not enough, so you need to have a SVG rendering in the native vector system (GDI on Windows, CoreGraphics on Cocoa, and so on). Another example is object embedding: we still don't do it, at least not in a standard way. Jean Brefort is doing some work with libgoffice to integrate the various GNOME-Office programs (mainly Gnumeric) to AbiWord, but the feature GNOME only. This is quite unfair to the other platforms, but it is still better than nothing. And this provide more credibility towards GNOME-Office, a project that only a fistfull hand of developers believe in. And AbiWord is depending more and more on GNOME technologies. Dom has started work to require libgsf for AbiWord, that create a glib dependency for all platform, depency already there for the OpenDocument filter.

Now lets go with the maintenance burden. So far the Gtk/GNOME version is the most complete and reliable. Why? Because it is the one where most of the developers put the work there, second being Windows. MacOS X is sort of lagging behind (I plead guilty for that), and Win32 still has issues.

It is time to pick a direction. Freedom has a price. We wanted to give users the freedom to use their platform of choice but today we pay the price as it slow us down to provide the best application possible, with the most complete feature set. With the Win32 and Cocoa ports of Gtk+, it might be viable to just use that toolkit on Windows and MacOS, sacrifying a bit of platform integration for a lot of features. A big tradeoff, but after all, users are happy with OpenOffice that do brings its own toolkit to provide features, so why not AbiWord?

The definite advantages I see are:

• easy SVG support, the dirty work being done with Cairo (actually that can be done now)
• object embedding with the rest of GNOME-Office. Jean Brefort has done some dirty work for that, but it is Gtk only. Since Gnumeric is Gtk-only it sort of make sense.
• platform equality

Shall we or shall we not? Proceding so would have us to require what Gtk+ requires. On Mac, it is MacOS X 10.4 (I was targetting 10.3 at that time, but who cares. I don't even run 10.4 anyway), while AbiWord currently targets 10.2. On Windows, I think it is Win98 and NT as a minimum, while AbiWord still works on Win95 (11 year old!).

This question hasn't been really discussed with the other developers.

The two biggest ISP in France providing broadband internet access via ADSL offers Linux based modem to their customers.

Free with the Freebox, for which I worked a few month, was the first to do that having a two-ended ADSL solution running Linux. Their Freebox modem and set-top box, that provides Internet access, VoIP and TV over DSL, and the DSLAM, the other end, that works over IP and Gigabit Ethernet (fiber optics) unlike what was on the market, at least in 2003, that are ATM based.

Now, France Telecom with the Livebox, provide a DSL Modem/router, with VoIP (yes, a telecom operator that compete with himself with VoIP services), TV (requires an external Ethernet connected decoder), wireless and other gizmos. This box, made by Inventel, runs Linux (the manufacturer advertise it as such).

But last news is more encouraging: Access Linux Platform by PalmSource. PalmSource has been acquired by a Japanse cell-phone company that wanted to go away from Symbian and WinCE with the plan to make PalmOS and Linux the base of their next generation OS. So they announced it. ALP has a Gtk based UI (they don't tell about X11, but apparently it uses X11) and use gstreamer, sqlite on top of a Linux 2.6.12 kernel. I wonder how much intersect with Nokia Maemo, but that would be their interest to team up to create a viable ecosystem of software. Maybe this time we could have AbiWord on PalmOS?

If you want to access your digital camera, you use a program that use libgphoto2. Now, with version 2.1.99 (upcoming 2.2) we even handle the camera that are mounted as a disk. It took us time to implement that because we didn't see the interest until we realized that people wanted to use their camera with a digital photo application, be it f-spot, gtkam, digikam, gthumb, and that the developer of said application shouldn't have to figure out the details. So now, we provide a single API for all the cameras that we know how to communicate with.

But what if you want to access your digital audio player (iPod, iRiver, Nomad Jukebox, etc)?

Some devices work as USB Mass Storage, like the small flash based players, hence do not require anything special driver.

For the iPods, there is libgpod that developers use to access the iPod private and proprietary database, there is ipod-sharp and its companion libipoddevice for those who write in C#, ipodslave of KDE developers (it is a kio-slave module) and gnupod, the Perl version.

For the Nomad Jukebox, there is libnjb, that implements the DPE protocol.

For the new iRiver and other MTP devices, there is experimental support in.... libgphoto2. Yes, you read correctly, a digital camera driver can be used. The MTP protocol is a variation of PTP (Picture Transfer Protocol, used for still image cameras), mostly pushed by Microsoft who provide a standard driver in the latest Windows XP updates. It is some sort of corruption of PTP and I think that the idea behind is to be able to control what files can put on the device, like implementing DRM. A bit like Apple does with iPod preventing iTunes users to download from the iPod the music, requiring that the music be on both the iPod and the computer, and having implemented a hackish crippling of iTunes to prevent loading some third-party plugins that allowed users to download the music off the iPod.

And I probably miss a lot.

How confusing is that ? Confusing for the developer that has to write at least four different version of code to access most of the device, and to the user that may not be able to use the application XyZ with the ACME player.

The solution it to create a library for digital audio player access the same way we have libgphoto2. One API for all the devices. That would involve a few changes in libgphoto2 to extract the PTP protocol, and give libgphoto2_port is own life, because the PTP implementation uses it. That would give the following architecture (admire the ASCII art):

libgphoto2 ---> ptp2camlib -> libptp2 <---- libaudioplayer
 \                   |            /           /    \
  \                  v           /           /      \
   \->      libgphoto2_port   <-/ <---------/        --> other drivers

gtkam 0.13.1 "It is still ex-Mas" has been released today.

Gtkam is a GTK frontend for libgphoto2.

This release brings various bug fixes. I really hope somebody would give this program more love.

Where is the source?

I'm so pissed off. Hallski just announced that andersca was doing for Imendio a port of Gtk on MacOS X.

What piss me off even more, is that earlier in the year, andersca ordered me to stop working on it because he wanted to start in a few month. I told him no, because each time someone a similar situation occur, the whole project stop; so obviously continuing was the only way to keep a pace, even slow and not waste time ever again. At GUADEC, I wanted to talk to him about that, we never did (he sort of escaped, etc). I did put the code in Gtk CVS because that was the only way to make sure other people could work on it, I never got any feedback. At what point it was said to me that andersca might take another project because he wanted to do that solo (I knew that developers had big ego). Since I never heard from him I assumed he did pick something else. And the announcement that he got commit access to WebKit just led me to think the same.

OK, I haven't worked on it since really, mostly because of lack of time or motivation or a combination of both and of because other priorities like an utterly broken AbiWord on MacOS X (it still is). But I must admit that this is a nice backstabbing and it is really appreciated to see that amongst the GNOME community, there are still people who feel like the need to do so. I personnaly really feel offended as I never hid anything about what I was doing, and what Imendio did behind my back just assume that what I was doing is crap (because they didn't feel like cooperating).

That said, I no longer will be working on that port, because I don't care anymore. Maybe I'll just concentrate on things people give a little bit of appreciation and gratitude, because on that, Imendio, andersca and Hallski showed to be at the complete opposite.

Oh and if you think I'm writing that just because I'm just angry, it is not. In fact I have been mumbling about it for weeks, but I promised my "source", who gave me the info to be honest with me, to STFU. I did.

Welcome Open Office, seriously. Welcome to what? Welcome to the world of native applications on MacOS X. I'm glad to see that you saw the light, that you realised that for your users, you had to get rid of X11 on MacOS X, because they deserve it.

When I started the AbiWord port on MacOS X back in 2001 (I bought that PowerBook G3/400 for that sole purpose), it was because I believed that the GTK based port of AbiWord runing on X11 wouldn't be a gift to our users. The experience showed that integration is really important. Freedesktop.org has been created in order to allow desktop interoperability between KDE and GNOME (and other X based free desktop software), because developer realised that runing an application designed for one desktop one another desktop was a much better user experience if it did integrate properly. That is also that same reason why some distributions insist on having a UI theme that is the same on both GTK and Qt, to make this difference even less obvious, to blends the frontiers.

I'm proud to see Sun finally realising that we all were in the right. And that announcement of abandoning X11 and going on with Cocoa is the right thing to do. Good luck for that, but at least you have some people paidmotivated to do it, unlike AbiWord. And do yourself a favor, don't use Java.

Update (2005/10/03): apparently I was mistaken. The Mac port is not sponsored by anyone. Even more "good luck".

Back from Ottawa and Desktop Developer Conference. I now have my head full of nice ideas for AbiWord, some crazy, some less:

Use UniConf for the preferences. This would be more a proof of concept and a toy to play with than a real feature for AbiWord. I don't see that very hard to do. Add that to my crazyness.

Write a Cairo backend for AbiWord. This is more sane, and somewhat a big work, but it is good crack. Here are the reasons:

Pro:

• one backend for Mac, Win and Gtk. Bug will be down to Cairo and not to each platform...
• SVG support will be way easier. We need SVG support.

Cons:

• Cairo maturity. But if nobody use it, who will test it ? AbiWord pioneered with XML for the file format.
• One more dependency, which seems to be a concern for win32 developers. Nothing that can't be solved.
• Performance. Again, that will give a real test case.

And I think I'll move my Gtk+-MacOS X work in gtk+-2.7 branch (I mean rebranch from there) to use Cairo as well. Now it makes sense.

Why do I prefer Firefox in GNOME ?

Not because of the "hype". Just because of bug 70575 and bug 153792 that both Galeon and Epiphany suffer from. Actually it is a Gtk+ "bug".

The other is that Epiphany bookmarks stuff I didn't ask, and given the limited bookmark management, it is annoying.

But on the laptop I still stick to Epiphany because I have passwords stored in it...

Since people are asking about GTK+ on Mac, here it is.

I branched CVS off 2.6.7.

cvs rtag -rGTK_2_6_7 gtk-2-6-macosx-branchpoint gtk+
cvs rtag -b -rgtk-2-6-branchpoint gtk-2-6-macosx gtk+

Why this version ? Because I currently don't feel like working on the moving code base that is 2.7, and that using a "bug free" version is probably safer. I'll merge back to 2.7 at some point.

Now, I'm getting all my changes merged into that branch. It leads to nothing that work.

I feel like completely demotivated by Apple and MacOS X. First they make barely possible to support older OS release with newer hardware. Then I realize that lot of core APIs are only available in newer OS release, like CoreGraphics. I'm not talking about new features, but APIs of existing things.

But then some people, including some Apple engineers, come and say "why do you want to support AbiWord on 10.2 while the current version is 10.4 ?".

• First I don't have 10.4 because I don't have that much money to throw into an OS upgrade. And despite having had that machine in February, I haven't had any discount offer to upgrade. Not really incentive.
• Second, I'm not alone, there are a lot of people that still use 10.2 or even before. I'd love to support 10.1, but technically it is not possible. 10.2 however is OK, API-wise. Then come the problem of building for 10.2. We have older fink, that work for the dependencies, but when you try to use the SDK for 10.2 as XCode allow, then you are out of luck as it fails (see bug 8971).
• Third, I don't want to sponsor the upgrade push made by Apple towards MacOS X.

Some Anynoymous Coward also proposed the "compatibility lab" from Apple. Sure thing, if he want to pay for the access and the trip, because the closest location is Cupertino, California, and one need be ADC Select of ADC Premier member to access, or to get an asset from someone else (see info page). Remember, AbiWord is run by volunteers. But that is slightly overkill as all I need is a machine to load 10.2. Someone else suggested PearPC, I must say I tried that, but it was no fast on my PIII 1GHz.

Perhaps should I just follow Ulrich Drepper advice and focus on Linux (and GNOME) instead of trying to satisfy a minority. Yes, for me MacOS X become a minority. Its users seems to not care at all about Free Software, and its developers are not into the philosophy as we haven't had any developer on AbiWord beside FJF and I (and I must note one simple patch I got once from someone else). With Apple not helping, because they consider you have to pay big bucks to be a developer, as the ADC Online does provide virtually nothing, it is not encouraging.

So now what shall I do ? Continue the 2 Mac centric project I'm working on: AbiWord and Gtk for MacOS X ? Pass on and focus on other GNOME centric code ? I don't know. Perhaps I'm just having a moment of grumpiness. I was happy to see Apple releasing WebCore, but the more I think, the more I suspect it to be a smoke screen to appease developers, as nothing towards providing help to support open source project has been done, at least in the case of AbiWord, and given the state of OpenOffice, they probably don't care (but since Sun is behind I can eventually get the reason).

I see some objections like "Apple ported FireFox to Intel". Sure thing, they needed a demo and a major application for that purpose, so they couldn't have a better candidate than a big open source application that runs on Mac. They could have selection AbiWord, but it is not that popular, and in fact I don't care. It is all smoke and mirrors.

And like my rant is not finished, there are some people that ask me to drop my work on the port of Gtk on MacOS X because they want to do it. I'm just about to commit what I have done in GNOME CVS for sharing... that's what I prefer.

I wanted to update and post new galleries, but F-Spot 0.0.12 is crashing. I upgraded Mono yesterday with my distribution, with a hope to get a more recent F-Spot. But I end up with no F-Spot at all... I get an obscure:

Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object
in <0x00000> <unknown method>
in (wrapper managed-to-native) System.Object:__icall_wrapper_mono_struct_delete_old (intptr,intptr)
in (wrapper managed-to-native) Gtk.StockManager:gtk_stock_lookup (string,Gtk.StockItem&)
in <0x00017> Gtk.StockManager:Lookup (System.String stock_id, Gtk.StockItem item)
in <0x0004b> GtkUtil:MakeToolbarButton (Gtk.Toolbar toolbar, System.String stock_id, System.EventHandler e)
in <0x00185> MainWindow:.ctor (.Db db)
in <0x0013d> Driver:Main (System.String args)

Filed bug 302853

I have implemented GdkDisplay on MacOS X. It is basically a wrapper around NSScreen class and NSApplication for a couple of things. It is probably not complete, like handling the clipboard.

Next will be GdkScreen, a wrapper the NSScren instances.

I also started to write some unit tests, so that with make check I can verify I'm not crashing, and that it works...

I started coding on Gtk MacOS X, and I investigated what they did in XDarwin the rootless XFree X server for MacOS X. I appears that they use Cocoa. So I decided that it my be a solution as I only need event and window management. The graphic layer will be Quartz directly.

Of course see screenshot on the side.

:-) Actually it is one of the "multimedia screen" I saw from outside on the street... crashed.

Today, part of my NDF, I started working on Gtk+ for MacOS X. So I had build a sane environment to get started.

Random caveats:

• Fink only has glib 2.4. So have to build glib and atk as well.
• On MacOS X, it is not LD_LIBRARY_PATH but DYLD_LIBRARY_PATH. Go figure why they do it differently on MacOS X, but this is a noticeable difference.
• Freetype2 package from Fink is broken as it put freetype-config somewhere in /sw/lib/freetype2/bin/freetype-config. And no I can't use freetype-config to find freetype-config path unlike someone suggested, as a joke, on #gtk. Playing with PATH helps. Bug 1179574
• CVS needs insane amount of disk space in /tmp. 70MB was not enough to import. I remove tetex as this machine is now head-less...

Here are the steps:

1. get all the dependencies to be build. glib, atk and pango with Freetype2 backend are done.
2. hack the configure to detect MacOS X. Almost done.
3. port gdk by writing and Carbon and CoreGraphics backend.
4. Have all the samples running.
5. Make it a Framework for nice MacOS X integration.
6. Write an ATSUI backend for Pango.
7. Move to gtk 2.8. This may happen sooner depending on the time line.

Sorry, there is no screenshot.

Some people wonder if I am a switcher. Hell no. I'm in fact and unswitcher, really. I have been use Linux as a workstation at work since march 1997, with a notable exception, and have switched my PowerComputing Mac clone to Linux, permanently, around 2001. My PowerBook G3 that I bought in September 2000, to port AbiWord has moved to Linux in February 2004, because I had access to an iMac to continue AbiWord development.

But what is that MacMini you have ? It is a workstation to maintain AbiWord on MacOS X. I only use it to compile test and use, and beside Project Builder and Terminal, the only other app running all the time is Camino, because it is just needed for Bugzilla. I'm not using Safari, because the bug I reported in 2003 to Apple hasn't been fixed... so it still doesn't work with bugzilla. Everything else including photo work, is done on the Linux machine. And when I need mail, I just use Thunderbird. Why ? Because I can't stand a mailer that can't thread. Apple Mail.app can't (they just do some "grouping") on 10.3.

The other thing that I miss is the Gtk based open source application I'm using, like Dia, Gimp, etc, for which I haven't found a free replacement. And my slide scanner is not supported om MacOS X either by the manufacturer... (it cost me 600 EUR at that time).

So yeah, even though I use MacOS X and do some development on MacOS X it is only for the sole purpose of reaching a wider audience with open source software. My daily personnal use of computer is still on Linux: browsing, e-mai, chat, photo, etc. And I'm not gonna switch back: my freedom is so important.

My latest blog about Gtk MacOS X leveraged some questions. I'll try to answer:

Q: Why don't you help GTK-Cocoa guy ?

A: I never said I wouldn't. I'll just investigate that code and see what is good and what can be done. At first sight, two problems. It is a reimplementation of the widget in Cocoa, and it is Gtk+ 1.2.

Q: Why don't you start with Gtk+ 2.8 that has a Cairo backend which has a Quartz back end ?

A: So what do I do with the event management ? AFAIK Cairo does only provide graphic layer. I'd prefer go Quartz straight, with ATSUI for the text.

Corrections:

I took a shortcut saying that Cocoa use Carbon. Sure it does, for menus and to have the same print and file dialogs. But they are both based on CoreFoundation (in fact Cocoa more like interact transparently with CoreFondation), CoreGraphics and ATSUI.

Now, stop talking, start coding.

So GimpShop has been released, it is a hack of Gimp to make it look alike Photoshop.

Too bad, it still require X11 on MacOS X.

I wish they spent more time doing really useful things like porting Gtk+ on MacOS X.

So I started looking at porting Gtk to MacOS X without requiring X11. Since I don't like reinventing the wheel, I'm looking at what has already been done.

• gtk-osx is a port of Gtk+ 1.2 done using Carbon, for Cinepaint.
• gtk-cocoa as posted in a comment. I didn't know that one, I'll look at it soon.

Now a bunch of Q&A:

Q: Why did you start with Gtk 1.2 ?

A: I didn't I just built gtk-osx which is Gtk+ 1.2. My goal is to port Gtk+ 2.6.

Q: Will you use Cocoa ?

A: I don't think. Several reasons:

• it is too high level
• I plan to reuse gtk-osx which is Carbon code, as it is a port of the old MacOS 8 mac-gtk

And Carbon is faster and much lower-level. Cocoa itself use Carbon.

Q: Will it run on MacOS 9 ?

A: No plan at all. This will be pure MacOS X.

Q: What about Quartz ?

A: I'll use as much as I can instead of QuickDraw, but Quartz lack lot of functionnalities to be exposed.

Q: When will it done ?

A: Don't know. I haven't started to code. And I have AbiWord to work on.

Q: Why do you do that ?

A: I want people to use Gimp on MacOS X, as well as Gnumeric, Evolution and Dia. In fact any of the fantastic Gtk apps we have.

I pulled a tarball of gtk-osx and did rebuild using Project Builder.

Here is the screenshot:

It is only gtk+ 1.2. It is a long way to the end.

LWN has an article about libgphoto2 and gtkam. It also talks about gThumb and Digikam.

Now that Qt has been released under GPL on Windows (link provided by glazblog (fr)), it runs freely on UNIX/X11, MacOS X and Windows. But where is Gtk ? Gtk-2.x runs on UNIX, on Windows, but still require X11 on MacOS X not making it really friendly. There is a port of Gtk+1.2 on MacOS X using Carbon done by the CinePaint team, but this is Gtk+1.2 while everything is currently using some 2.x version; and the project seems to be dormant.

I don't understand the lack of interest for this port by the MacOS X community. They are the first to whine about The Gimp being not well integrated with MacOS X, but porting Gtk+2.x to MacOS X without using X11 would probably resolve most of the issues. And it would also resolve the issue of lack of decent not overpriced and/or closed spreadsheet by allowing to port Gnumeric. This lack of interest is still visible with the lack of developers for AbiWord on MacOS X. When I had to stop developing it due to lack of hardware, nobody did anything until FJF took over. And it is not the lack of interest from people, it is just the lack of skilled MacOS X developers willing to work on Open Source projects.

Ximian/Novell hired Tor Lillqvist according to Nat's blog to help port Evolution to Windows. Some may wonder if it is a good idea. Tor has ported Gtk+ and The Gimp to Windows, and is still making sure all that work.

Since we already have AbiWord and Gnumeric running on Windows, that will brings more parts of Gnome-Office to run on Windows. And I'm pretty sure Gnumeric folks will be happy to put back the stripped out feature into the Windows port, like Bonobo.

When will someone sponsor a port of Gtk+ to MacOS X (without X11) ? There is already a Gtk+-1.2 port for MacOS X, but it does not seems to have evolved since July 2003. That codebase could be used as a start towords porting Gtk+-2.x. If only I had a MacOS X machine to do that now that AbiWord for MacOS X mostly run.

Since the begining, AbiWord has been written to be an cross-platform application, and ran on Windows and UN*X with Gtk. We have always advocated this, and when people did ask us "why Windows ?" in Open Source conference, we always ended up saying that it was part of the freedom of choice we wanted to offer. After all, AbiWord is Free Software.

The other argument was that it is easier to move apps that to move the whole desktop to Free Software, and that could help doing the first step, which would allow the second step. After all, OS and desktop environment are meant to run applications, not the opposite.

Recently Aaron J. Seigo, a KDE developer, pretended that Open Source apps will kill Open Source desktops.

Like Sean Parson, I don't agree with Aaron. Here is my point.

First an OS is a way to run applications. This is often what decide the choice of the OS. They won't use the OS if they don't have the application they need. Take apart the motivation of using Free Software exclusively and let consider the case of the user willing to switch if he can get a replacement for all his applications. Switching people to Free Software Operating System is not an easy task.

Starting by replacing application by versions that runs also on Free Software Operating Systems is probably the best way to proceed because not every applicaiton might have a replacement. This is more and more true with enterprise computing where they have custom apps designed with Windows in mind. So, replace IE by Firefox and OE by ThunderBird. Replace MS-Office by OpenOffice.org (this replacement are only based on current trend). Without changing the operating system and without finding replacement for some apps, you still have freed the desktop more than it was. These application wouldn't be running on Windows, nobody in the Enterprise IT would have even an argument to even think about migrating to it. Most of the time they are locked into Windows with other chains like these little apps they spend thousand if not millions of $ into.

Mark Carter explains why he use Windows XP, and all the applications as free software, telling he has eveything he need as Free Software to run on Windows, and that Linux lack support for hardware there is no spec for. This basically brings water to Aaron J. Seigo mill. But it also explains why it is still good, because Mark use Free Software, and it will be easier to make him switch once he get his problems with Linux solved.

So in fact it is important that Free Software applications runs on proprietary operating system. It does not dismiss the effort of the Free Software Operating System, au contraire. It brings them credibility by demonstrating theire interoperability.

Liferea is a nice Gtk based RSS feed reader. Before I was using Straw, but I complained that it was slowing down my machine and using too much RAM.

I feel somewhat satisfied by this one. I also allow to sort feeds hierarchically. And since it is written in C, I can eventually hack on it, unlike Straw for which I would have to learn Python.

AbiWord 2.2.1 has been released last week. Read the changelog or download it. Works on Linux (and the other UNIX), MacOS X, Windows and other platforms.

Why 2.2.1 and not 2.2 ? Because we released 2.2 and found a couple of bugs that required fixing.

We also got slashdotted with the announcement. Nothing serious, just visibility, and comments for never happy MacOS X users. Nevermind. The MacOS X version is finally available, thanks to FJF for the great work and for taking over this task.

Gnumeric got its 1.4 release too, and is now available on Windows. When will there be a X11 less version on MacOS X ? When someone ports Gtk+ 2...

L'actu par Mac4Ever (fr) made a call for developer to develop some completely useless software for MacOS X: a screen saver intended to be as a demo. Aren't there more urgent things to do like helping AbiWord native Cocoa port to be more polished or help porting gtk+ to MacOS X without X11 so that one can port Gnumeric that is IMHO a real jewel. Most of the time, the excuse to not take part of these projects in the MacOS community is because they like making shareware and need to pay the bill.

We, the AbiWord team, have been looking for a long time for help from developers in the Mac community, without much success.