Tuesday, June 24, 2014

LiClipse 1.0 released (Julia now supported)

LiClipse 1.0 has just been released.

It's now based on the latest Eclipse (4.4) and PyDev/other dependencies were also upgraded.

Support for the Julia Language: julialang.org was added in this release (so, 15 languages are now supported).

Also, the language support on LiClipse was improved so that a language can specify how to make a launch for it (see: http://brainwy.github.io/liclipse/launch.html for more details):

F9: Launches the currently opened editor using the executable specified in the language (and for those using PyDev, Shift+F9 will launch the editor in debug mode)
Ctrl+Shift+F9: Terminates the last launch and relaunches it
Ctrl+Alt+F9: Terminates all launches
Ctrl+F11: Relaunches the last launch

Also noteworthy is that when starting up LiClipse, when selecting the theme to use, an option to use the dark theme from Eclipse 4.4 is presented... I still prefer the one from LiClipse as it works better for me -- especially for those on windows -- but the option is there :)


  1. What is different in your dark theme? Could you provide patches for the Eclipse platform to improve our default dark theme?

    1. Hi Lars,

      Well, I could, but I don't think it's the proper solution.

      The things I've done are reported at: http://liclipse.blogspot.com.br/2014/05/eclipse-and-dark-theme-shortcomings.html, but I have to resort to doing things that I shouldn't have to do and which could be done much cleaner in SWT itself (for instance, I have to create custom painters to erase things that SWT did just to do it differently, whereas SWT should've done it right in the first place).

      So, the proper solution is *really* fixing SWT (and not hacking around it as I've done)... I'm not sure how e4 came to be, but to keep competitive, Eclipse really must attract at least someone part time to fix things such as those reported there (the scrollbar customization may be the hard thing there, but the others *should* not be difficult to implement -- but it still requires someone with time and someone with commit rights to do it).

  2. Awesome to hear that you did custom painters. So far I did not look into this. Could you point me to them in your code base?

    I completely agree that the right thing would be to fix SWT but as my C/C++ days are long behind me, I don't plan to contribute in this area.

    Commit rights should not be necessary with Gerrit in place for SWT, just time and skills to contribute.

    1. Actually, the things in SWT should be fixed in java code, not in C/C++... (yes, SWT is a thin wrapper on top of the OS handles, but it's mostly in java -- although a different one for each platform).

      As for the custom painters, it's in LiClipse (so, not directly EPL), so, I created a gist with just the related part in EPL: https://gist.github.com/fabioz/59b06c519f505d37fcfb so you can look at it and use it if you'd like, but really, that's not the proper way to fix it (the proper place is in org.eclipse.swt.widgets.Tree and org.eclipse.swt.widgets.Table -- look for 'SWT.PaintItem' in those files).

  3. > Actually, the things in SWT should be fixed in java code, not in C/C++.

    I think if you (or someone else) provides a patch for the table header styling and the scrollbar issue for the SWT the whole Eclipse community should cheer united in happiness. I personally will unfortunately most likely not find the time to contribute to more projects that currently.

    > https://gist.github.com/fabioz/59b06c519f505d37fcfb

    Awesome, thanks.

  4. Hi Lars,

    I'm currently quite full with PyDev and a new profiler I'm doing for Python (https://sw-brainwy.rhcloud.com/support/pydev-2014/), but I'll keep that as my top thing to contribute in the future (just don't know when that'll happen).