Monday, November 5, 2012

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.


Thursday, October 25, 2012

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.

Tuesday, October 23, 2012

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.

Tuesday, October 16, 2012

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!

Tuesday, October 9, 2012

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.

Wednesday, August 29, 2012

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.

Friday, April 20, 2012

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.

Friday, February 24, 2012

RPM + OSGi automation: Step 1 completed

Recent RPM versions include the concept of dependency generators. This opens the door for a number of automations and simplifications for people using RPM as their distribution format. 

In Fedora we stepped in and worked on making Java land fell less of an alien in Linux distributions. 

Not every OSGi feature is considered because some of them don't match with the goals of distributing a single project. Everything is based on the Bundle-SymbolicName and Require-Bundle headers (for now). 

  • Bundle-SymbolicName header is used for generating a virtual provide for the rpm the bundle is part of in the format Provides: osgi(bundle-symbolicName) = bundle-version . This is done for every OSGi bundle in the RPM so the number of these provides will be the same as the number of bundles in it. This provides generation was enabled early in the Fedora 17 development phase and will be available for use in the soon to be released Fedora 17. How will this improve the packager's life one may ask?  - Do you know which package e.g. javax.servlet bundle is in? You don't have to anymore. Put Requires: osgi(javax.servlet) in your spec file is all you need. Or you can use yum to query for it `repoquery --whatprovides "osgi(javax.servlet)"`
  • Require-Bundle headers are used for auto generating requires so people don't end up with dependencies not being installed. The format used is pretty much the same Requires: osgi(bundle-symbolicName). Few things needs mentioning here - optional requires are discarded because RPM(in Fedora) doesn't have the concept of soft-requires and versions are not added to the requires for a reason that will be explained later. The requires generator have just been enabled in Rawhide(future Fedora 18) and up to now it's showing no major problems with a pretty huge test case - the Eclipse SDK.
 Import/Export-Package is a huge part of the OSGi specification and even the recommended way for specifying dependencies. Here I'll explain why it doesn't make sense for RPM packages without questioning it's general usability, it just doesn't fit our workflow.
  • having provides/requires for every package import/export is way too verbose and will polute the rpm metadata that much to make it hurt every user with unneeded time to download metadata
  • we don't want multiple providers for the same package - we want  a single, stable and well tested provider. 
This is big enough difference to even make me think of Step 2 where Import-Package headers are used at build time to map them to Require-Bundle. This will not be an easy task but it is possible because at build time we know which bundle exports the needed package. 
Now to not having versions in requires. First of all there is no easy mapping between OSGi version ranges and RPM. OSGi recommends using version ranges while in RPM it's considered a really bad practice to use anything else but setting the lowest version supported. Second, we usually have only one package that provides given osgi bundle. Third , more than one OSGi bundles are usually grouped in a single RPM. All of the above combined makes the requires generated satisfying 90 % or even more of the cases and for the rest one can still add the requires manually (like we do now).
This isn't by any mean a complete solution it covers only the most common case but still it will prevent a number of problems like Eclipse failing to provision because of missing requires for some plugin and etc. Once the current automation makes its way through the whole distribution work on the next integration step can continue because there would be less time spend on simple but timeconsuming things.