SWT on GTK 3 - Eclipse starts !!

So another major milestone is hit. One can start eclipse on top of GTK 3.x - not everything works as expected but here is the screenshot.

SWT on GTK 3 can be shown !!!

If we keep the pace I might get used to blogging more often.
A picture is worth a thousand words so here it is:

Not much to see but it's the first ever screenshot of SWT on GTK3. Not much more can be done for now and the label was supposed to be centered (source) but still we are finally at the stage where we can start showing things.
Big thanks goes to Silenio who bite the bullet to disable/workaround things so we can start running the code instead of targetting perfection with the compiler.

SWT on GTK 3 status 2012-10-23

That was amazing week - 29 compile errors were fixed! On the other side my metric is broken - I have been counting only errors in os.c while there are a bunch of others hiding in os_structs.c too. Anyway, at least for what we were counting there are 31 more errors left and they are a prerequisite for even trying to build os_structs so we continue working on them.
So what was fixed last week:
* 2 gdk_colormap_* functions are dynamic now as they are removed in Gtk 3
* 3 drawable/pixmap functions are no longer used in Gtk 3 codepaths
* 14 errors - GdkRegion/cairo_region swap landed in
* 9 gtk_style_get_*_gc  are ignored - used only in the unfinished Theme api
* gtk_widget_size_request - time will tell whether this was the correct call.

Additionally a number of other fixes for the structs landed too but I do not keep track of numbers there as I compile them in my blind_convert branch so the numbers are flawed by the dummy fixes done for unfinished things in os.c.
And now the good news - one can successfully compile my branch in question and try to run an empty shell example - nothing will show but it would not crash either, which was the state for long time preventing me from making this branch public. Don't count to much on this branch  - it's known to be broken and serves only as a test bed before things go into master.

SWT on GTK 3 status 2012-10-16

Another week - 15 down!  60 more problems expect us before trying to run on top of GTK 3.
The problems fixed this week are:
* 5 gtk-paint* functions  replaced by the new gtk-render* functions
* GdkDragContext, GtkSelectionData and GtkTargetPair structs are no longer used directly but via accessor methods
* GdkGCValues, GdkImage and GdkVisual structs sizeof is no longer needed
* gtk_cell_renderer_get_size replaced by gtk_cell_renderer_get_preferred_size

Let's see what will next week bring us!

SWT on GTK 3 status 2012-10-09

SWT doesn't run on top of GTK 3 (latest and greatest ) but work is ongoing. Last week was a really productive one getting us to the state of less than a hundred compile errors (well, some are warnings actually). Not only that but we are down to 75 as of today. A number of others are pending reviews in bugzilla giving us hope that speed should not decrease.

Here is the list of all the GTK problems we have identified for now. Be fast and pick one (check the tracker bug first), open a bug and block the tracker so we know someone is working on the issue. There is still time to add your name to Thanks list. If you want to help out checkout swt from git and  when building natives instead of the plain `sh ./build.sh` do `GTK_VERSION=3.0 sh ./build.sh` the list of errors is what's still pending. Nothing else but code counts as help for now! There should be semi-regular updates on the state from now on.

Big thanks to SWT project members for making me a committer to speed up the work and to my teammate Anatoly Spektor for his hard work on the topic in the last months.

A jealous view at Gnome Stack (from Eclipse developer)

Criticizing Gnome looks like the most popular sport this year in tech land so here are few reasons why many developers are probably jealous to Gnome developers or at least why I am.

Reason 1: GnomeGoals

Haven't you dreamed of having consistent codebase in your project? What about consistency through out most projects that come from the open source foundation hosting your project? I definitely wish this was the case in Eclipse.org land. Even if Gnome developers haven't achieved it everywhere they did it in many areas. Remember that even collecting and structuring the data is something that most other projects haven't tried to do!!!

Reason 2: Forward looking developers

No "if it ain't broke, don't fix it" mantra. The difference here is outstanding - even if the problem is damn hard Gnome developers work hard to get it fixed ASAP, in many Eclipse projects we wait for the problem to hit us hard and try fixing it at a time when it's way harder to do it thanks to many depending on the broken behaviour and the relevant no longer part of the community. Others (like the maven guys) take it to the other extreme - make stable releases depending on alpha software. If you want a proof - run mvn and watch for plexus-container-default 1.0 (alpha-8, alpha-9, alpha-9-stable-1!... alpha 30) coming your way. Many of the projects initiated to fix long standing problems have their hard first steps and left bad taste in some early adopters but most of them end up becoming de-facto standards.

Reason 3: Get things done(aka real Community)

You can see core developers going and adopting various other applications to their latest change in some underlying library. And there is also the opposite direction - developer spots a problem in one application and tries to fix it in the underlying library so it doesn't pops up in other places. This behaviour is what we heavily miss in Eclipse land.

• How many of us use internal/non-api packages and don't help the other project to properly define an api?
• How many of us has copied code from another eclipse.org project and let it stagnate there?
• How many of us actively removed deprecated stuff (commands vs. actions, etc.) ?
• How many of us started using underlying libraries stuff instead of our home-grown classes?
• How many of us has tried to fix the problem in the underlying platform bundle when we spot one (swt anyone?)?

I know everything is not perfect in Gnome land and  my statements are pointing the good parts only but that's what we have to point  out, right? Instead of pointing failures (they are always obvious), people need to point out what others are doing better than them so we can all improve. 

Whatever people might say about Gnome - as a developer I can only say that they are on the right path and sooner or later the technical excellence will pay off.

P.S. I'm a years long KDE user but I seriously consider moving to Gnome 3.6 as it fixes one of my last concerns (notifications) and Gnome Shell really really has the best work-flow for my taste.

Eclipse and gtk-doc

If you are a Linux developer you already are aware of the beauty that some devel packages provide - their gtk-doc generated documentation. Or maybe you have been using it's online variant (e.g. cairo manual). Or you might have used Devhelp to search and read the documentation coming from your locally installed devel packages.

Now if you are using Eclipse for your development the very same documentation is integrated into Eclipse Help Center together with all the other documentations available there, you can read it there. 

Or you might want to have it opened side-by-side while coding.

Pick your style and enjoy! Hopefully this brings the documentation closer to more developers. We all know how hard it is for everyone to read documentation so the easier to read it the better for everyone :).

It is already available from Linux Tools nightly update site and will be part of our 1.0 release in June.

P.S. This was written by Jeff Johnston almost entirely, I just had the privilege to do the final touches and announce it.