gettext ?!

23. October 2006

While trying to add import and export of .po files in glom I try to understand how libgettext-po handles erros. In gettext-po.h:


/* Signal a problem of the given severity.
MESSAGE and/or FILENAME + LINENO indicate where the problem occurred.
If FILENAME is NULL, FILENAME and LINENO and COLUMN should be ignored.
If LINENO is (size_t)(-1), LINENO and COLUMN should be ignored.
If COLUMN is (size_t)(-1), it should be ignored.
MESSAGE_TEXT is the problem description (if MULTILINE_P is true,
multiple lines of text, each terminated with a newline, otherwise
usually a single line).
Must not return if SEVERITY is PO_SEVERITY_FATAL_ERROR. */
void (*xerror) (int severity,
po_message_t message,
const char *filename, size_t lineno, size_t column,
int multiline_p, const char *message_text);

This is a callback passed to po_write_file which is called on failure. Hmm, so this method is required not to return if “SEVERITY is PO_SEVERITY_FATAL_ERROR”. How could I do this? Of course I could call exit() but that not really good. An application should usually not die if an error occours. FATAL error occours for example, if the file is not writeable.

The only solution that came into my mind yet was to start another thread that would simply exit if something goes wrong but that is really ugly. Anyone here with better ideas? Maybe I just miss the point.

LibTpz and C++

20. October 2006

I am able to write that in the moment because I am hacking on the glom po import/export feature and g++ is just that damn slow that I takes ages to build glom on my Pentium M 1.73 (which is usually not really slow and has great beryl effects now).

Anyway, I have some api suggestions for libtpz (for ThreePointZero). There also is a Project at gna for it now:


Interface TpzIter
{
next();
prev();

get();

equal();
}

Interface TpzList
{
prepend();
append();
remove();

foreach();
copy();

get_length();

Iter* begin(); // first item
Iter* end(); // after last item
}


I have some initial code here but it needs some polishment to be added to svn. I still would like to derive GInterfaces but I doubt that this is possible in C. The design is very close to what the C++ STL provides.

Some might say now, what the advantage over GList* is so here are two points:
– GList* is used for the whole list and for an individual item – that is confusing
– [Edit: Removed]*

So there is another more important point: You can hide your list implementation. In fact, you do not have to use a “list” at all, you could have a tree, an array or any other data structure that you can wrap on that interface. This way, you can also add optimations that are not possible with GList*.

Of course there is a perfomance impact but I think that is not that major that we should not try it. Maybe someone wants to create benchmarks later.

Another thing: Dear Lazyweb, how can I configure beryl to maximize a window like metacity when I double-click on the title bar?

*[EDIT]
This point was not very good but it is still here:
– Writing loops is more intuitive, instead of

/*GList* node = list;
while (node)
{
/* do something */
node = g_list_next(node);
}*/

[EDIT] Some pointed out (correctly) that it is better to write
GList* node;
for (node = list; node != NULL; node = node->next)
{
/* do something */
}

you can use
TpzIter* iter;
for (iter = tpz_list_begin(list); !tpz_iter_equal(iter, tpz_list_end(list)); tpz_iter_next(iter))
{
/* do something */
}

“API stable”

13. October 2006

Of course it is very nice to keep a platform stable over a period of time. But if we want to do that, we should do it correctly. And for me API stability means, that all widgets behave the same they behaved in the stable release before, even if the behaviour was a bit wrong in the previous release.

So Gtk+ 2.10 introduces this bug because the behaviour of GtkAboutDialog changed. I guess the behaviour was not correct before but that really doesn’t matter.

I just imagine how many bugs an application written for Gnome 2.0 and Gtk+ 2.0 will have today if it had not been changed since.

So please do not argue that there is not need for 3.0 because we don’t need API changes…

BTW, thanks much to Don Scorgie for helping so much fixing this help bug.

libanjutamm arrives slowly

7. October 2006

In the little time I was not motivated to continue learning for my math exam on Monday I mostly finished libanjutamm. It is a bit of a hack anywhere but it is possible to get a plugin loaded in anjuta though implementing interfaces does not work yet. There is even a reference documentation!

Take a look at the Sourceview SVN if you want.

Anjuta Bounties

3. October 2006

There are now some bounties offered on the anjuta website. Feel free to take some them if you want to improve anjuta and earn some money. Thanks to donors to Anjuta Fund, notably Adam Dingle who would
be giving a significant amount of donation.

Of course everyone is also invited to fix others this. Check Bugzilla for open issues.

Last night, I discussed with Philip about gnome’s api and it’s future.

As you can read in his blogs, there are some problems with wrapping the C API to modern programming languages:

  1. Lists (double-linked and single-linked)
  2. Trees
  3. etc.

For libanjutamm to become a really good wrapper, I would have to copy lots of code from tinymail which is not really a good idea. I was thinking about creating a libtreepointzero which does implement lists, trees and possibly some other stuff in a way that modern programming languages can you it. Philip already wrote most of the stuff for tinymail so the biggest advantage would be that it can be used by other applications.

If there are other people interested in this library, it would be important to have language bindings in a very early stage to be able to change the API in favor of having better language bindings.

This will also give me a nice point to demand a changed gnome 3.0 api.

BTW, Prashanth Mohan, what strange university are you at?

What about Gnome 3.0?

25. September 2006

Why and when?
To me, Gnome 3.0 (or ThreePointZero) looks like a phantom. There are several thoughts filed about it in the wiki but it’s completly unclear when work on 3.0 will be started and what will be the real goals. Nobody knows if 3.0 will come after 2.18, 2.20 or 2.22.
I personally think that Gnome 3.0 should come after 2.18 because the platform is mostly cleaned up and it’s really time for a break!

How I would like to see 3.0

  • Platform: Developers hate platform changes! So little changes here would be great. There are a few things which need integration for example GUniqueApp, a gnome-vfs replacement and of course all the deprecated stuff will disappear. A little API clean-up here and there would be good but I do not think that the changes should be that big as from 1.4 to 2.0.
    Imporant for 3.0 is that people get more aware that for usual Desktop applications it’s much easier to use Python, C# or C++ instead of C and that (Gnome == C) != TRUE. That would also mean that really all needed libraries are covered by the language bindings.
  • Desktop: Most agreement seems to be in using a more document-oriented approach. This does not mean to force the user to use this approach but it should be made easier. There is this very cool gimmie project which might replace the panel somehow.
  • Integration: It would be really cool if the user would not know wether an application he uses was made for XFCE, Gnome or KDE. It should simply work and look like any other application on the Desktop. FreeDesktop.org has come a long way but for 3.0 we would have the possibility to throw much incompatible ballast away. Of course this is an not a Gnome-only problem.

These are just my thoughts and don’t give to much about them because I am not a gnome core developer and I may even have missed lots of things that are already planned for 3.0.

BTW (and for me not to miss the link), Maintainer looks really cool!

Why DRM is not a solution!

22. September 2006

This is a reply to Rodney Dawes’ post on DRM:

Why DRM cannot work
DRM wants to make people able to hear their music or view their videos without seeing or accessing data. While it is no problem to encrypt data in a save way, it has to be unencrypted if the user wants to do anything useful with it. If it is unencrypted* the user is able to do anything with it that he wants and that’s not what the music industry wants. Houston, we have a problem.

* in the player, the hardware, in the air, wherever

Of course you can try to make it extremly difficult for the user to break your system but this leads to the crappy implementations you see all the time.

Why DRM is obsolete
There is a much better technique as DRM, that is signing the sold music/videos with a secret, unremovable key. This can be done to mp3 for example. Now, the user can do with it’s data whatever he wants but once he does something what law does not permit, the right owner knows who is to judge.

The only music shop where I buy only music using exactly this signing technology which was developed at the Frauenhofer Institut (where mp3 was developed, too). And therefore it is the only webshop where you can listen to legal music on Linux without doing any crap.

Yet anther Glom bug!

8. September 2006

Today, I made a patch for Bug #349358. The patch itself is quite trivial but I took me some time to find out why all this happens.

In the meantime im trying to fill my brain with stuff related to production engineering for my exam on monday. There are just 300 pages left I have to learn by rote, so it might become a very funny weekend.

Hello Planet Gnome!

7. September 2006

So I am finally here! For those who do not know me, I am a maintainer of Anjuta and work for Murray Cumming’s company Openismus on several GTK/GNOME related things.

Today, I created a new patch for #346896. I have to thank Dodji for his tips and apoligize that it was not at all a gtksourceviewmm problem. I have attached a screenshot for those who need some bling!