Handling Invalid UTF-8 in ZeroBUGS

Based on suggestions from users I have changed the way ZeroBUGS deals with invalid UTF8 code when loading source files. The GtkSourceView widget uses ustrings internally, and when passed single-byte strings will assume UTF-8 encoding and convert them.

In order to prevent accidents such as loading a binary file instead of a source file by the users, I had my UI reject outright any invalid UTF-8 text.

But it turns that sometimes this restriction is too strong, and I have added a dialog that asks before rejecting the file.

Wide Strings Debugger Support

This past weekend I worked on adding support for visualizing wide standard strings and QT strings in the ZeroBUGS debugger. For convenience, they can be displayed as if they where regular C strings.

This feature can be turned off and on from the Edit / Options menu. Under the Language tab, if the checkbox for Qt strings is unchecked, the inner structure of the object is shown. Otherwise Qt strings are displayed as regular strings. std::string and std::wstring instances are handled in a similar fashion.

Before implementing this feature, the values of the variables displayed by the debugger where being represented as C strings.

The solution for wide strings keeps the existing design: I read the Unicode strings from the target process' memory, then call wcsrtombs to UTF-8 encode them.

And Glib::ustring takes it from there:

GTK+ and GNOME chose to implement Unicode using UTF-8, and that's what is wrapped by Glib::ustring. It provides almost exactly the same interface as std::string, along with automatic conversions to and from std::string.

It is still a new feature and it needs more testing and possibly, ahem, some debugging but overall I am pleased with the results.

And if you have any feedback regarding what features should I work on next, please take the poll in the right hand side bar, or leave a comment. Or both. Merci.

Gnomes

Following my disgruntled post on Gnome and GtkSourceView last night protests broke in Europe (and even in France).

Seriously, some people may think that I am talking nonsense and they are entitled to their opinion.

But I am considering rewriting the UI for ZeroBUGS using KDE. I am sick of this game of ever shifting APIs. Say what you want about Windows, but the Win32 API stayed backwards compatible for as long as I can remember.

Those folks do not get it: when you break the API you generate more work for developers like me: I have to carefully track the changes, decide whether to stay with one library or change my code to the new API? is the end-user going to have all the dependencies easily resolved or do I need to ship additional shared libraries? Merde.

Ed: Max wrote a very intriguing comment about http://www.fltk.org/. Worth considering, thank you kindly, sir!

Gnome My Foot

I have not been paying much attention to the (old) Gnome versus KDE debate until yesterday (I just assumed that Linus is nit-picking and brushed it off).

But after installing OpenSUSE 10.3 I realized that the API for the gtksourceview component has changed. In the process, a part that is important to me (source markers) was dropped. It is not a show-stopper or enough reason for me to part with Gnome, because for the time being I have got some options, and the GtkSourceView team will reintroduce the dropped features by version 2.22.

But I understand now how people get upset over dropped features and interface changes.

As always, Linus was right.