Sorry, this is going to be a rant…

Some distributions like Ubuntu tend to have their own bugtracker for all packages and people will report bugs there (in this example This is not a bad thing in general as it might be possible to generate better debugging info if you know the exact binary package.

This requires bugs to be added upstream though because no developer will ever have a look in downstream bug trackers. For core packages of a distribution that has the manpower to do this that should be OK and as those packages might be patched in some way it might be useful to report bugs downstream and decide manually if and how to report them upstream.

However for packages where there is nobody to review the downstream bugs I would really prefer if the downstream bug-tracker will just forward the bug to the upstream bug-tracker (probably doing some internal duplicate filtering in between).  I am more happily getting some incomplete bug reports than missing  the interesting ones because they never reach the upstream tracker.

So, launchpad developers: Do you think that’s doable. There are so many great options in launchpad that I think adding this one shouldn’t be too difficult. By accident I stumbled across some very interesting reports in launchpad and I would have loved to have these reports upstream.


Re: Anjuta UI work

5. April 2010

Today, I finally took the time to fix the optical trash from the embedded tab change I did some time ago:

Anjuta with correct tab buttons

Voilà, tabs look like they should now. Actually this wasn’t that easy to implement and requires a custom GtkContainer widget which is a bit painful to write. There might be some possible improvements in using the correct border/shadow for the notebook but I haven’t figured out a better way until now.

This post is a spin off from the recent foundation-list discussion regarding the future direction of GNOME. It was pointed out that GNOME might not be a very attractive platform for new developers. The reasons was among others that there is nothing like a standard way of developing GNOME applications. Of course, everybody is somehow using automake and autoconf and some editor and bugzilla but not more than that.

Compared to windows, about any new developer will stumble over Visual Studio. On Mac, it is the same with XCode. For these tools there is tons of documentation, tutorial and books available and they are actively promoted with the platform.

For GNOME 3.0 we should also start having something like this. This doesn’t mean than present developers have to change their development model but they should be aware that their personal model might not be suitable for new developers especially those with no Linux/free software experience. As such, we should promote the tools we have to make life of new developers easier and ensure that they work with the workflow of a specific project.

In a perfect world, I would announce a hackfest here now, but I won’t 😉 But I would encourage people to help  anyway. I have setup a wiki page to collect ideas. The major points are in my opinion:

  • Write good tutorials how to build GNOME applications without touching command-line
  • Setup a website (maybe on hosting all the information for getting started with GNOME development

Everybody is invited to contribute!

GNOME-Track on LinuxTag

1. March 2010

We have been offered the chance to run a GNOME-Track on LinuxTag 2010 (June 9th to 12th) in Berlin. As we would love to do that we still need 2-3 talks. So if you are located in Germany or want to come to LinuxTag and have something interesting to say about GNOME, please either contact Vincent or me so we can add you to the list. For now we only need a title and a short discription of your talk. It’s possible to do talks in german or in english at your option.

We would especially encourage some of the zeitgeist/gnome-activity-journal developers to do a talk as we know that some of them live in Germany.

The deadline for submission is today! Don’t blame me for that, we really would have liked to get this out earlier…

Let’s make this a rocking event for promoting GNOME!

For my fellow Vala hackers…

23. February 2010

Symbol Manager with Vala symbols …I proudly present support for Vala symbols in the Anjuta Symbol Manager. This will mean you can browser and search your project symbols like you can in C and JavaScript. This will either work with the automake backend of the project manager for automake >= 1.11 with Vala support or at your option with the new directory backend for automake < 1.11 or custom Makefile rules.

Credits go to Abderrahim Kitouni (former GSoC student) for writing the vala parser for ctags. We hope to add full Vala support including autocompletion and probably debugging before 3.0.

In related news, Anjuta 2.29.91 “Vala la révolution” was released with many stability fixes today. Give it some testing. Naba already did an awesome job in filing bugs for a lot of small but annoying issues. Follow his example 😉

Javascript support in anjuta

21. December 2009

Finally, after far too long time I found time today to merge Maxim’s great Javascript support patches from GSoC 2009 into master. You find screenshots and more information on his blog.

Thanks a lot for your work Maxim!

P.S.: Remember that scipting is for loosers while C is for real (wo)men 😉

The great people from gedit/gtksourceview finally implemented a new completion engine for GtkSourceView which allows us to drop lot of ugly custom code in Anjuta. But it also has some cool features:

  • Combine auto-completions from different sources (called “providers”)
  • Add auto-completions in an asynchronous way
  • Support to add extra information to the auto-completions

For now, Anjuta uses only the first two but it’s really planned to add API Help for symbols.

Despite having a more stable and tested code and a nicer UI that means that he will never be disturbed while typing because the editor is searching for auto-completions to appear. Instead all this now happens in background and it really feels fast. This also gives us a possibility to add macros/snippets directly into the auto-completion framework. Screenshot:


There are also some other interesting things coming soon:

  • a better engine for C++ (auto-completion of class-members, etc.)
  • GSoc JavaScript plugin which needs to be merged
  • a new bison/flex based automake parser as project-manager backend (probably won’t be finished until 3.0)
  • a completely rewritten git UI

GtkNotebook action widgets

9. November 2009

Remember the good old days when bug nummers started with 1xxxxx? Well, now we have one bug less in this area, GtkNotebook finally supports widgets in the tabs area:

GtkNotebook with action widgets

GtkNotebook with action widgets

(Note that the buttons here are just examples and this was done mainly for testing purposes).

Why could this be useful:

  • Firefox-style “Add tab”-buttons
  • Saving space when dealing with notebooks that have a constant (and low) page number
  • probably much more

There is nothing in the HIG yet of course and you should use it with care. I hope it’s useful though.

Credits go to Carlos Garnacho for the original patch and to Mathias Clasen for reviewing my patch and adding GtkBuilder support. Also thanks to Openismus for letting me finish this!

FedEx woke me up today…

22. September 2009

…and brought the new Google Summer of Code Shirt:
New GSoc T-Shirt

The main feature of the T-Shirt is being not black and actually really looking kind of non-geeky which makes it possible to wear it outside geek areas.

Anjuta UI work

12. June 2009

Based on the awesome work from Joel Holdsworth making it possible to add custom widgets to the dock item grips, I finally patched anjuta to use this ability. This can save quite a bunch of pixels:

Anjuta with new buttons in grip feature

Anjuta with new buttons in grip feature

Old pixel-wasting version

Old pixel-wasting version

There may be still some style issues especially for the message window tabs. Suggestions welcome!