Eclipse – too small icons on high dpi screens – workaround for KDE Plasma by scaling on X11 and Wayland

I have to work with Eclipse (version 4.32) again for a while. After two days of relatively intensive work, I am a bit frustrated. One reason is the small size of the icons – 16×16 px. Not only in the main icon taskbar. There are minuscule symbols elsewhere – e.g. in the bar on the left side of the editor section. Regarding e.g. the tiny symbol for code folding: You can almost not see the “+” or “-” symbols on a high resolution screen …

One can scale almost all font-sizes within Eclipse – but not such a basic thing as the icon/symbol size or the icon bar height.

I have three QHD screens (2560×1440) at my present workplace. At another site there are 2 4K screens. The following image can give you an impression for the QHD situation – if you have a QHD, UHD or 4K screen yourself and not zoomed the browser contents already. For screens with lower resolution see below.

Before you say this looks quite OK, check the following:

  • Open this post on a desktop screen in a window wider than 800 px.
  • Enforce normal content size size in your browser (no zoom! Ctrl-0).
  • Get a natural distance to your working QHD, UHD or 4K monitor (like 80+ cm). In case you have a QHD screen you get already the right impression.
  • Users who just have a monitor with a 1920×1200 resolution must in addition downscale their browser contents to around 80% (QHD) or 55% (UHD, 4K) to get the right impression of the problem. (After Ctrl-0)
  • Folks with QHD get the right 4K impression by scaling down to 66%. (After Ctrl-0)

While for QHD the working conditions may still appear to be OK, you get a real problem for UHD and 4K resolutions. The font-size may still be OK (after having adapted it). The unadaptable symbol sizes, however, are far too small. At least in my opinion. But even on my standard QHD screens I personally do not feel comfortable after a while.

In this post I want to share some workarounds. The methods described may be interesting for other GTK applications, too. Keep in mind that the images in this post may give you a wrong impression if you zoomed the browser contents. But later on, when I demonstrate the effect of some measures, only relative sizes of fonts and icons are of interest.

Continue reading

Eclipse IDE – how to limit the number of of CPU cores used on a Linux PC

In the very hot days which we experienced in Germany the last week my old ventilation cooled PC suffers a bit when all of my CPU cores get under full load. Temperatures up to 70&grad; Celsius despite an Alpenföhn ventilator are beyond my normal experience and tolerance. The culprit was Eclipse with PyDev.

I had installed the latest Eclipse version (4.32.0) some days before. And opened a new Python project based on a directory with tons of code for Machine Learning classes. As a default the PyDev validator started to check the code for problems. It does so by using all available CPU cores and threads in parallel. Yeah, Eclipse works highly parallelized with its underlying Java VM. As I had a lot of complex code the code analysis lasted for some minutes – putting an extreme load on my PC.

So, my question was: How can one limit the number of CPU cores/threads used by Eclipse?

For Linux the answer is surprisingly simple:

We can use the “taskset” command. E.g., if I wanted to use the first 4 CPU cores (or recognized threads) we would write on the command line:

taskset -c 0-3 ./eclipse & 

This works perfectly! The initial code analysis takes a bit longer – but the load on the PC got down. Happy coding!

 

Eclipse Photon 2018-09 für PHP – endlich gute Content Assist Performance

Ende August war ich auf die “R”-Version von Eclipse Photon umgestiegen. Der Start der IDE erwies sich zwar als elend langsam; aber immerhin erschien mir das Zusammenspiel mit GTK3 gegenüber Eclipse Oxygen deutlich verbessert. Auch eine Java10-Runtime-Umgebung ließ sich gut verwenden.

Etwas hat mich jedoch zunehmend bei der Arbeit behindert:
Bei großen PHP-Projekten erwies sich die Content-Assist-Funktion [CA] des PHP Editors als bodenlos langsam. Wenn man den Heap beobachtete, so wechselte der während des Wartens auf eine CA-Antwort ständig die Größe. Gegenüber den in Eclipse ablaufenden Hintergrundsprozessen (Neu-Indizierung vieler Files? Update diverser Oberflächenelemente? …) kam die CA-Funktionalität offenbar erst mit geringer Priorität zum Tragen. Das war völlig irregulär. Mal erhielt man eine Anwtort zu einer lokalen Variable sofort; mal musste man 5- 6 Sekunden warten. Die Meldung “Computing proposals ….” ging mir zunehmend auf den Zeiger. Wer will beim Tippen schon 5 Sek warten, bis der erste Vorschlag kommt? Leider hat keine der angebotenen Optionen unter “Preferences >> PHP >> Editor >> Content Assist” viel geholfen. Auch nicht zur “asynchron Code Completion”. Ich war kurz davor, wieder auf Oxygen zurück zu gehen.

Heute habe ich heute aber die neue “September-Version von Eclipse ( “eclipse-php-2018-09-linux-gtk-x86_64.tar.gz” ) installiert, Updates der “webkit2”-Bibliotheken unter Opensuse vorgenommen und auch die “~/.eclipse”-Eintragungen neu erstellen lassen.

Und siehe da: Die Performance der CA-Funktionalität im PHP-Editor ist nun wieder so wie in alten Zeiten. nach nun 6 Stunden Arbeit kann ich sagen: Das Programmieren mit PHP und Eclipse macht wieder Freude ….

Eclipse Photon unter KDE Plasma – Dark Scheme unter Opensuse Leap 15 nicht mit dem Default-GTK3-Design kombinieren

Eclipse Photon ist es wert, zumindest testweise installiert zu werden. Ich habe das neulich unter Opensuse Leap 15 und KDE Plasma getan. Im Vergleich zu Eclipse Oxygen finde ich das Zusammenspiel mit GTK3 unter KDE Plasma inzwischen relativ zufriedenstellend.

Was mich allerdings weniger begeistert, ist z.B. die verschlechterte Performance der Content Assist Funktionalität. (Nachtrag 26.09.2018: Gilt so nur für die “R”-Version, aber nicht mehr für die neue September-Version; tarball “eclipse-php-2018-09-linux-gtk-x86_64.tar.gz”). Auch der Start von Eclipse für PHP mit PDT ist z.Z. erstaunlich langsam; zumindest phasenweise wird dabei offenkundig nicht auf Multithreading gesetzt. Da bleibt wohl nur, auf Updates zu hoffen.

Es gibt aber auch optische Punkte, die beim Einsatz des GTK3-lastigen Eclipse Photon zumindest unter KDE Plasma nicht zufriedenstellend sind: Der eine betrifft die Skalierung der Icons in den Menüleisten – hier gibt es anscheinend grundlegende Probleme mit dem Zusammenspiel der aktuellen SWT-Komponenten mit KDE Plasma. Dazu wurden bereits mehrere Bug-Meldungen verfasst, deren Aussagen ich nur bestätigen kann: Eine GTK-Skalierung funktioniert unter KDE Plasma weder über Environment-Variablen, noch über Einstellungen in der eclipse.ini wie erwartet. Siehe etwa https://bugs.eclipse.org/bugs/show_bug.cgi?id=536542. Auch hier hilft nur Warten und Tee trinken.

Ein anderer wunder Punkt ist die Kombination des Dark Scheme mit SWT-gesteuerten Oberflächenelementen, wie sie etwa in vielen Eclipse Dialogen zum Tragen kommen. In meinem Alter halten die Augen nicht mehr so lange durch wie früher; muss man mehrere Stunden am Tag entwickeln, ist man froh über einen dunklen Bildschirm-Hintergrund. Also habe ich bei mir das Dark Scheme aktiviert.

Leider erwiesen sich dann Checkboxen und Radioboxen in einer Vielzahl von SWT-gesteuerten Dialogen unter Opensuse Leap 15 mit KDE Plasma als kaum erkennbar. Das betraf einerseits “Preference”-Dialoge, andererseits aber auch “Remote System”-Dialoge, u.a. für den Export von Files auf Remote-Systeme. Letzteres ist für die praktische Arbeit wirklich ein Dilemma:

Auf einem hochauflösenden 2K bis 4K-Schirm wird das zum Problem. Aus einiger Distanz lässt sich der Checkbox-Haken kaum erkennen. Vieles lässt sich über die Eclipse Preference-Seiten ja einstellen und korrigieren, aber gerade das nun mal nicht.

Dieses Problem lässt sich aber Gott sei Dank lösen. Man muss nur wissen, dass die Lösung nicht innerhalb von Eclipse sondern bei den Einstellungen für das GTK-Design unter Plasma zu suchen ist. Als GTK-Design hatte ich nach dem Upgrade auf Leap 15 bislang die Opensuse-Einstellung “Default” belassen. Das führt zu den dargestellten Problemen.

Unter KDE Plasma hilft es dann, das Dark Scheme von Eclipse mit dem “Breeze”-Design oder dem “Adwaita-Design” für GTK3-Anwendungen zu kombinieren. Die entsprechende Einstellungen nimmt man unter
“systemsettings5 >> Erscheinungsbild >> Anwendungs-Stil > > Gnome Anwendungs-Stil (GTK)”
vor.

Mit Breeze erhält man folgende Darstellung:

Adwaita liefert folgendes:

Breeze und Adwaita als GTK3-Designs (unter KDE Plasma) machen die Steuerungselemente in den Eclipse Dialogen also viel besser erkennbar! Ich hoffe, dem einen oder anderen, der Eclipse unter KDE mit dem Dark Scheme einsetzen und sich nicht die Augen verderben will.

Eclipse Oxygen3 – old bug blocks certain key combinations in editors – e.g. Ctrl+Right/Left for next or previous word

After changing to Eclipse Oxygen 3 for my PHP work I have spent an hour to find out out what was wrong with the keyboard actions for navigating through code. One of the key combinations one typically needs is “Ctrl >” and “Ctrl <” to jump from one word to the other – more precisely between some whitespace/letter-combinations which are interpreted as word separation borders.

Whenever I restarted or reopened Oxygen3 the already opened editors on files I had worked with during the last session did not show any reaction to such key combinations. However, when I closed the file and reopened them again with the structured PHP-editor the key combination did work. But after a restart of the workspace no reaction again. It really took me a while to find out that all this was due to the “welcome” screen, which I had not deactivated, yet, in the new installation. After knowing this, I even did find a corresponsing bug and stack overflow report.

https://stackoverflow.com/questions/18341928/eclipse-ctrlright-does-nothing

Just deeactivating the welcome screen did the trick. I find it very frustrating that this is really a rather old bug – and I could bet it cost a lot of people nerves and useless efforts.