Tag Archives: gnome

Montreal: lets improve the GNOME development story

Hello,

me and more people from Codethink are going to be in Montreal to propose what we think can be the solution to improve the build and the development story of GNOME OS : Baserock

The project is still in early stage of development, so the idea at Montreal is to have tech discussions to work out how baserock can best help on the deployment of GNOME OS.

Take a look to the overview Baserock page for more info.

Thanks to Codethink to sponsor our travel here, and also all the other sponsors to make this event possible:

Stay tunned!

GNOME 3 is here!

I’m happy, GNOME 3.0 is out!

I still remember when in 2009 I heard about a plan to make the next GNOME version.
I wanted to contribute and I met some great people that guide me on the best way to help in the effort, so I started to work in the Streamlining of the Platform part, trying to remove all the deprecated stuff. Also I started to work with the Bugsquad team, on GnomeGoals and then in GTK+3.

And now GNOME 3.0 is finally here! :) Thanks to all the people that made this release possible! You all rock!

If you are in Manchester, come to MadLab this Sunday at 14:00 for the GNOME 3 Launch Party!

And, of course:

I am GNOME

GnomeGoals Status Report

I’d like to share the status of some GnomeGoals, as some of them have been recently completed:

RemoveGnomeOpenGnomeHelp: completed!

DropLibsexy: completed!

RemoveLibGladeUseGtkBuilder: only remaining: sound-juicer. Updated automatical stats can be found at Frédéric Péters’ 299 report [1]

CleanupGTKIncludes: mostly complete. Remaining: gnome-disk-utility . Also, It’s needed to check gtk-sharp, gnome-desktop-sharp and some GNOME external dependencies.

CorrectDesktopFiles: mostly completed. I’ve been filling some bugs and I think this GnomeGoal is complete now. Anyway, please, check your module an update the wiki page. Updated automatical stats can be found here.

UseGseal: In progress. Some modules was already ported to use accessor functions instead direct access to prepare to GTK+3 transition. The GTK+ api to make the port is mostly complete now, but there still are some corner cases. Please, start porting you module ASAP and fille bugs agains GTK+ if you need some new api.

AddGObjectIntrospectionSupport: In progress. You can take a look to the modules marked as ‘done’ to help you to add introspection support inside your module. Updated automatical stats can be found at Frédéric Péters’ 299 report [1]

RemoveDeprecatedSymbols/Glib: Mostly complete. Anyway take a look on this as some new symbols can be deprecated in each cycle. Updated automatical stats can be found at Frédéric Péters’ 299 report [1]

RemoveDeprecatedSymbols/GTK+: Mostly complete. Anyway take a look on this as some new symbols can be deprecated in each cycle. Updated automatical stats can be found at Frédéric Péters’ 299 report [1]

As you can see, the status of the GnomeGoals is pretty good so congrats everyone!! :)

[1] http://www.gnome.org/~fpeters/reports/299.html

Help improve Glib/GTK+ documentation

Update: Before start working in a module, check that It’s not already deprecated (like CList or CTree): these modules will be removed in GTK+3 so the doc migration is not needed

One of the tasks to improve the GTK+/Glib docs maintenance is to convert the documentation from templates (*.sgml) files into source-comments. This is a easy tasks that everybody can do.

All the process is documented here: [1]

Here a step-by-step example to help new contributors ;)

  1. Download GTK+ and gtk-doc source code:

    cd ~/git
    git clone git://git.gnome.org/gtk-doc
    git clone git://git.gnome.org/gtk+

  2. Execute gtk-doc script to convert the documentation

    cd gtk+/docs/reference/gtk
    ~/git/gtk-doc/tools/migratetmpl.pl –module=gtk

    This creates a “src” directory containing “*.c” files with all the comments.

  3. Copy and paste them to the right place.

    The section docs are best placed in the *.c file. Put them below the copyright header and the main includes (if there is no *.c file use the appropriate *.h file).
    All other comment blocks should be put directly above the definition of the symbol.

    For example, for GtkAccelGroup, we’d move the comments from gtk+/docs/reference/gtk/src/gtkaccelgroup.c to gtk+/gtkaccelgroup.c and gtk+/gtkaccelgroup.h

  4. Remove the template file:

    git rm docs/reference/gtk/tmpl/gtkaccelgroup.sgml

  5. Check that the documentation is correctly generated with:

    ./autogen –enable-gtk-doc
    make

    then go with a browser to docs/reference/gtk/html

  6. Send a patch to bugzilla and make it block 599599 for GTK+ or 589775 for Glib documentation.
  7. Update the wiki page [1] to avoid duplicate work

When adding the source code comment, its a good opportunity to review it a bit. Have a look on spelling and style. Is it really giving a helpful explanation what the function does, etc. Also improve cross references. The gtk-doc syntax of the comments is described in the gtk-doc manual [2].

You can take a look to the gtkwidget.h [3] and gtkwidget.c [4] code as an example.

[1] http://live.gnome.org/GTK+/TaskAPIDocMigration

[2] http://library.gnome.org/devel/gtk-doc-manual/unstable/documenting_syntax.html.en

[3] http://git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.h

[4] http://git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.c

Help cleaning GNOME Bugzilla

Do you want to help cleaning GNOME Bugzilla?

Are you afraid because you are a newbie? Or you don’t know where to start?

In a recent Bugsquad meeting [1], a new initiative was propossed: the BugsquadGoals [2] .

This is the objective: Setting small concrete goals to clean some kind of bugs from the database.

For example: Search for bugs about a crash without the correct value in severity field (critical). Also, set the keyword STACKTRACE if the bug has a decent Stacktrace with line numbers and symbols.

You have more info and the bugzilla queries in the BugsquadGoals page [2]. Also, any suggestion for other queries are always welcomed.

If you have any problem or you want to request some Bugzilla permissions, we are in #bugs irc channel on irc.gnome.org.

See you there!

[1] http://live.gnome.org/Bugsquad/Meetings/20091009

[2] http://live.gnome.org/Bugsquad/BugsquadGoals

2009: My GNOME year

2009 was a great year: I started to contribute to GNOME this year for the first time.

I’ve worked in Gnome 3 cleanup tasks, bugsquad, GnomeGoals and finally I’ve done some GTK+ patches.

After reading Andre Annual GNOME Bugzilla statistics for 2009, I’ve recollected some of my statistics since my first bug report in 2009-04-26 (255 days ago): [1]

  • 201 Bugs reported (4th position)
  • 300 patches (2th position)

Although some of the patches are quite trivial, I think that they are good numbers for a newbie like me ;)

But the best thing was meet great people in the GNOME community; Thank you to all the people that help me this year, was great work with you ;)

Looking forward to 2010!

[1] https://bugzilla.gnome.org/page.cgi?id=weekly-bug-summary.html;days=255

Adapt your module to GNOME3 / GTK+3

Hello all!

I’ve been working in GNOME3 “cleaning” tasks for some time and I’d like to share this mini-guide to make your library/application GNOME3 / GTK+3-compilant. The process is quite easy:

GNOME 3:

Don’t use deprecated libraries:

GTK+ 3:

When you finish, use GNOME_MAINTAINER_MODE_DEFINES macro ( included in gnome-common ) in your configure.ac files, so you will be notified when you use a new deprecated symbol.

Also, take a look to the awesome Frederic Peters graphs to track the status of your module: http://www.gnome.org/~fpeters/299.html