EclipseCon Europe 2016

EclipseCon Europe this year was a really nice event (as always). Here is my brief report from it. I would not cover talks I went to in details as one should be able to watch them online eventually
First of all we had the first Eclipse Platform summit (at least that I know of) with 15-20 attendees. There is the perception that Platform started to improve in terms of new features and openness to the community but there are certain parts that are not there yet so actions are needed there. Biggest pain point expressed was blocking UI and there was some interest towards reducing the dialogs and/or making them non-blocking. Willingness to merge projects was raised but it's not a viable short term solution although it might be good as long term goal. Notifications both in terms of system wide and in-workbench came few times and prototyping SWT support is something we should find time for during Oxygen timeframe. Also Platform is supposed to lead by example and help projects on top of it to adhere to best practices was agreed on but this would require significant time investment in order to get the codebase and UX to that state.

VSCode keynote - quite interesting especially with the mentioning of some debugging protocol they have (similar to the language server). Once language servers and Eclipse intergration catch up going to standardize the debugging should make adding new language support way more straightforward.
I had the honor to present "Full CSS styling for SWT and Eclipse" talk - around 20 people in the room (the room wasn't much bigger). It was well received with few comments at the end that people were sceptical in the beginning but it looked promising to them at the end (a noteworthy person changed his opinion from "crazy idea" to "interesting idea"). The idea of using SWT/GTK on Win32 was received way better than I expected - with one guy joined the bug to build himself and hopefully help with further work. It really pleased my ear to hear from few people (that I didn't knew before that) during the conference that they moved towards Linux due to the way better experience they had on GTK/Linux than on Win32.

It was a pleasure to see so many Red Hatters and here about the contributions done by the company in almost every talk I went to or participated including a special place for that in the members meeting. Let's hope that next year our contributions will be even bigger but many other companies would have done their part too.

Runtime CSS styling for SWT

In the previous post it was explained how one can do global styling of SWT components in your application via CSS prior.
But that's only the surface, all these capabilities can be used for runtime styling of individual component.  NOTE: Eclipse Oxygen I20160906-0800 or newer on GTK3 required.
Styling individual component that way is even simpler than the traditional SWT API especially if you consider that to achieve some of the capabilities exposed one has to do custom drawing with all its verbosity and potential problems.
Enough words - the magic is in Widget.setData(String, Object) method and the secret key org.eclipse.swt.internal.gtk.css . All you have to do is call yourWidget.setData("org.eclipse.swt.internal.gtk.css", yourCSS);  with proper GTK 3.20+ CSS (note: this is labeled as API by GTK guys thus old versions are not accepted).
The amount of properties supported is pretty wide and ever growing. At least for my limited CSS knowledge most of the things I tried just worked.
Time for screencasts:

• Button styling via SnippetButton  

• Label styling via SnippetLabel

 I'm really enthusiastic about the future, hopefully you will be too after watching the videos and trying it yourself !

Advanced and fast CSS styling for SWT

The strongest (or the weakest - depends of your angle) part of SWT is its deep system integration. But this means you get the Look'n'Feel of your system UI toolkit and any deviation from it (e.g. e4 theme engine) is either too limited or too slow or both.
On the other side if the underlying UI toolkit provides really advanced and declarative styling capabilities (like GTK+ does) making use of them from SWT is not hard at all. And we already start to use it extensively (to adjust tabs sizes, provide key bindings for tree expand/collapse) and usage will only increase over time. Best part of it is that it really works at the GTK level thus there is almost no performance penalty for sane operation (going wild with gradients and etc. will have a penalty of course) . Actually it's providing a custom GTK theme for you application allowing GTK to do all its caching and other optimizations . Something one can never achieve with custom drawing
But this would never be enough - there are just too many different themes used, everyone has his own personal preferences about amount of white space around widgets and etc. So best thing we can do from SWT side is provide sane defaults for everyone and open the door for the heavy opinionated people to tweak their Eclipse UI as much as GTK+ allows them.
Support for that is in master already. Download latest Oxygen nightly build (N20160829-2000 or newer), create your own css file (GTK+ docs explain things pretty well) and edit your eclipse.ini file to point to it by adding a line like -Dorg.eclipse.swt.internal.gtk.cssFile=/path/to/my.css in the -vmargs section and enjoy.
As a small example I created a really visually distinguishing style like:

button  {
    border-width: 1px;
    border-radius: 30px;

    background-image: -gtk-gradient (linear,
             left top,
             left bottom,
             color-stop(0.0,rgba(34,97,170,1)),
             color-stop(0.50,rgba(56,145,218,1)),
             color-stop(0.51,rgba(34,131,216,1)),
             color-stop(1.00,rgba(134,191,234,1)));
}
button:hover {
  box-shadow: inset 0 0 0 5px #3071A9;
}

to achieve this funky colors and hover effect.

This is just dummy example but at least there is the ability to tweak and make Eclipse match your personal preferences.

NOTE: The ability to point to your css file is only exposed on systems having GTK+ version 3.20 or newer as this is the first GTK version that has specified and thus stabilized the syntax to a state exposable to users.
NOTE 2: If there is anyone with experience in Win32 and/or Cocoa UI toolkits knowing if they provide such capabilities and how they can be exposed  please contact me as it would be nice to have such feature exposed for every SWT user not just for those on GTK. In order for this to happen we need people with deep knowledge and vested interest in these other UI toolkits.

Eclipse Fedorapackager 0.5.0 release

After a bit more than 2 years it was high time to do new release to adapt to current Fedora and Eclipse releases. Most of the changes in this release were towards cleaning and simplifying the codebase hoping for faster releases but there are some important feature changes like:

• Fedorapackager requires Java 8 now.
• Allow users to clone multiple projects at once.
• Fix changelog parsing for Bodhi
• Make use of /etc/rpkg/fedpkg.conf
• Modified Fedora Packager Koji properties page
• Reduce logging noise.
• Enable rpmlint and rpm natures by default.
• Tagging is no longer used with Git.
• Shorter menu labels.
• Fixed JsonNull error when pushing bodhi update
• Eval NVRs when Bodhi updating
• Eval the name to not fail on sclized packages.
• Bodhi authenticate when pushing review fix.
• Bodhi dialog cleanup.
• Make perspective switch remember previous choice.
• Let the console name has the package (srpm) name in it.
• Remove expectation of the existance of an ssh key.

Updated packages are available in Rawhide and Fedora 21 updates-testing.

Last month (May) in Red Hat Eclipse

May is not the most exciting month in terms of Eclipse development - it's all about final touches, release procedures and handing these bits to the users. With the previous said it might actually be the most exciting from users point of view.
The team spent a lot of time on getting things from Luna release train built and available in Fedora Rawhide (future Fedora 21 release) - Platform, CDT, Linux Tools, Mylyn and their dependencies are available to Rawhide users now.

Here is the detailed report:
P2

• P2 - Use runnable repo to collect metadata (commit)
• P2 - Propose improvements to fragments generation (review)

SWT

• Review, approve, push stabilizing patches (bugs 1, 2, 3, 4, 5)

CDT

• CDT Standalone debugger - this major new feature is finally merged into master for Luna (commit)
• Fixed using deprecated extensions in Autotools support (commit)

PTP Remote

• Drop circular dependency with CDT (commit)

Linux Tools

• GCov coverage bars change to green/red (review)
• GCov add compile/link flags automatically (review)
• SystemTap - many cleanups, remote operations improvement, context sensitive UI elements and user guide improvements (git log)

Test and celebrate with us the soon to be available Luna release train.

Last month (April) in Red Hat Eclipse

This is post is heavily inspired by Last month (April) in Red Hat KDE . Great idea which I dare to copy almost entirely ;)

So here is the Red Hat Eclipse one (limited to eclipse.org projects work):

Equinox

• add build support for GTK/Linux/PPC64LE launchers (commits 1, 2)
• remove build support for motif launchers (commit)
• simplified launchers maven build (commit)

SWT

• add build support for GTK/Linux/PPC64LE fragment (commits 1, 2)
• fix FontDialog crash with GTK 3.10 (commit)
• fix PrintDialog crash with GTK 3.10 (commits 1, 2, 3, 4, 5)
• fix Combo inheriting font from parent (commit)
• fix Widget.setFont using wrong widget handle (commit)
• fix Button background problems in jface forms (commit)
• fix List height calculation  (commit)
• further progress on Webkit2 support
  • solved deadlock issue by decoupling the synchronicity by executing the JavaScript asynchronously
  • added support for creating unique dbus addresses for each instance of the extension
  • created a function to find resources (mimicking the library loading search in SWT) to load the webkit extension
  • fixed a crash in the WebKit2 port when visiting gmail.com (frames without document object)
  • back ported API for passing information to WebKit extensions during initialization
  • found a workaround for the missing GDBusNodeInfo struct definition in older glib versions

CDT

• support remote Autotools projects (commit)
• fix Autotools projects to support user defined make (commit) 
• GDBStandaloneDebugger have seen final touches to make it a proper product. Details.

Linux Tools

• API/Javadoc cleanup in preparaton for 3.0 release (many commits)
• Libhover ported to not use swing.html for parsing (commit)
• Libhover supports gtk-doc 1.20 generated docs (commit)
• GCov opens full featured editor from CDT instead of its own(commits 1,2)
• SystemTap plugin have seen polishing changes to get smoother experience (commits)

Brought to you by: Jeff Johnston, Roland Grunberg, Sami Wagiaalla, Andrew Ferrazzutti and Alexander Kurtakov.

You can find us on #eclipse-linux and #fedora-java channels on Freenode IRC.

That's the Red Hat Way.

Thoughts on Eclipse platform

Many people complain about how the Eclipse platform is not helping building a community but there are some other thoughts that I can't get rid of.

People want to drive "big" changes from the beginning but in reality it doesn't work that way in no FOSS project - one has to start with small things, not so small, slightly bigger, big, bigger, huge, etc. People that are dedicated go through the process and gain the ability to change so much for the reason that there is not that many other people working on the platform.

Is this perfect - NO, not at all. How can it change? There is only a single way I see - more people start contributing - but not contributing the next big thing - help us revive the platform. Things like:

• improve test suite - no big change can happen if the committer is not at least partly sure that nothing bad happens. That's a huge opportunity for people wanting to join as it doesn't require that much deep knowledge from the beginning. E.g. in SWT it was a test infrastructure work (~100 commits) just to modernize to the state where there is one test suite for all platforms with all the quirks in it to make it possible to run from maven build in a sane way. And tests can be run from the maven build run but still fail!!!
• bug triaging - Yes, having 1142(at the time of writing) open bugs for SWT/GTK only is not helping me see new problems. Verifying bugs, producing snippets that make it easier to reproduce, patches that fix it or simply closing the bug cause it has been fixed long ago. This is really valuable help as it is huge time drain. Reports that are vague or too big don't get that much attention as the current amount of people is already having problems driving the next release!!!
• cleanup the codebase - Making use of new features available for years, standardizing on given idioms, removing deprecated. All these boring things that make it easier to not be afraid of change, to jump into the project easily, to verify things easily, etc.
• improve the build system - Huge task and huge time drain for potential contributors. If the build takes so much longer than needed even without running the tests in it, how can someone easily verify a change. Yes, I mean building the whole platform and running all tests to verify that you're not breaking something few layers above you.

If/when we get the things above done - jumping into the problem space would be way easier and there would be enough people with experience in it already so we don't get to this state again.

With so many Eclipse users and people unhappy with the current state of affairs maybe it's time to try different approach. Is this the right one? No idea. Will it work? No idea either, but there is only one way to know it - let's try.

This is plea to the people that haven't been involved into Eclipse and wondered whether they can help improve - Yes, you can.

P.S. These are my own thoughts and doesn't represent a statement from any of the Eclipse groups I'm member of.