SWT Bug Triage

If you are a GTK/SWT developer and want to be involved in SWT Triage,
Then you should read:

It is also useful to subscribe to the swt-platform email in bugzilla.
This way you’ll get emails for new SWT bugs and comment update on un-assigned bugs.
To do this, go to bugzilla, -> Preferences -> Email preferences
-> “Add users to my watch list” , add: platform-swt-inbox@eclipse.org
The only trouble is that you’ll get emails for all platforms (Windows/Mac/Linux) and you’ll have to create some filters for sorting things out. But in general I found that it’s good to be ‘aware’ of the issues that happen on windows/mac, as those sometimes occur on Linux also, or a bug labeled as ‘windows’ often impacts linux swt also.



How to compile various gtk3 versions and run eclipse Apps with those (for SWT Widget testing)


When developing SWT widgets, we need to test them on various GTK versions to ensure backwards compatibility.

There are some tricks and perks involved.

Get Gtk sources

  • Go to the gtk git repo and pull the code: https://git.gnome.org/browse/gtk+/
    (I recommend the https version: https://git.gnome.org/browse/gtk+)
    (if you don’t know how to use eclipse’s EGit, read this)
  • Check out the versions that you’re interested in (e.g 2.24, 3.10, 3.4, 3.8)
    These are found in major Linux distributions (e.g ubuntu 12..).
  • For the time being, check out the newest gtk version (e.g 3.10 at the time of writing).
    (It’s easier to build a newer version than an older one)
  • Open Terminal, go to your checked out gtk branch.
    Run the following commands:

    ./configure --enable-x11-backend --enable-wayland-backend
  • The first time you run the commands, you might run into errors telling you you’re missing something on your system. Inspect autogen.sh to see what it runs and then install the utilities with yum.
  • Now copy gtk to another place on your system. E.g ~/src/gtk2_24 This way you don’t have to recompile this business every time.
  • Now you can build the other versions and similarly copy them to ~/src/gtk*_*
  • NOTE ON gtk3.4 (and maybe older) The Wayland configuration makes certain things look more correct. But sometimes it makes building older versions (like gtk3.4) near impossible due to missing dependencies. In this case, run the configure without these:
     ./autogen.sh ./configure make 

Configure Eclipse to use the gtk you compiled

  • Edit your run-configuration of the code snippet that you want to run.
  • Navigate to “Environmental Variables”
  • Click on “Add”, type in:
    path: #your_compiled_gtk      //e.g /home/lufimtse/src/gtk3_10/gtk/.libs
  • Name your configuration (I reccomend appending gtk version, e.g “ControlExample (g3-10)”)
  • It should look something like this:
    Eclipse env var
  • Now run the configuration and you should see your application rendered in gtk*.*.
    You may note that it won’t have any styling:
    java app in compiled gtk
  • The lack of styling is due to the fact that there is no theaming.
    Now sometimes you might want the compiled gtk to use your system theame to see impact of themes on looks.
    To do so, do as above except run the configuration as following:

    ./configure --prefix=/usr --sysconfdir=/etc --enable-broadway-backend --enable-x11-backend --disable-wayland-backend

    In the interest of comparison: (left native look, right bare look)
    native vs bare

  • Lastly, in your source code, you might want to verify that you’re running the compiled gtk and not your own. Use this line of code:
    System.out.println("GTK Version: " + OS.gtk_major_version() + "." + OS.gtk_minor_version() + "." + OS.gtk_micro_version());