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.

Eclipse, Git, SSH2, Einträge in der ~/.ssh/config, Bug bei Ciphers mit Domain-Angabe

Wenn man mit Eclipse (Oxygen2, Neon3) Git-Repositories auf Remote-Servern versorgen will, macht man das natürlich über SSH. Ich hatte in einem früheren Blogbeitrag schon mal auf einen Artikel

https://stribika.github.io/2015/01/04/secure-secure-shell.html

hingewiesen, in dem verschiedene Härtungsmaßnahmen aufgezeigt werden. Natürlich verwendet man dabei auch eine Public Key Authentication, wobei der öffentliche RSA-Schlüssel in hinreichender Länge (> 2048 Bit) auf dem Server implementiert wird. Er ist dort wie üblich beim entsprechenden externen User in die Datei “~/.ssh/authorized_keys” einzukopieren.

Unter Eclipse ist dann in jedem Fall noch Folgendes erforderlich: Unter dem Menüpunkt

Window >> Preferences >> General >> Network Connections >> SSH2

trägt man im Fensterchen zum “General”-Tab das Verzeichnis ein, in dem man seine privaten Keys aufbewahrt – und listet zudem die von Eclipse zu verwendenden Keys für die verschiedenen Git- bzw. SSH-Server auf. Das sieht dann etwa so aus:

Ohne diese Einträge funktioniert eine key-basierte SSH-Authentifizierung unter Eclipse nicht. Das gilt nicht nur für Git sondern auch für andere Arten von SSH-Verbindungen etwa unter den “Remote Systems”-Modulen, für SFTP- und für SSH-Shell-Zugriffe. Die korrespondierende Git-Push-Konfiguration für SSH kann dann etwa wie folgt aussehen:

“55511” sei dabei der gewählte SSH-Port, unter dem der Server erreichbar sein soll. Der Leser muss an dieser Stelle natürlich die für ihn geletenden Einträge vorzunehmen.

Auf einem typischen OpenSSH-Server unter Linux lassen sich die Vorgaben des oben genannten Artikels zu Einträgen in der SSH-Konfigurationsdatei “/etc/ssh/sshd_config” problemlos umsetzen. Etwas anders sieht es aber auf dem OpenSSH-Client-System aus. Dort würde man gerne zumindest folgende empfohlenen Härtungseinträge in der Datei “~/.ssh/config” unterbringen:

Korrekte Einträge in der OpenSSH “~/.ssh/config”-Datei, die aber unter Eclipse nicht funktionieren:

  
Host myserv.myhosteddomain.net
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr,aes256-cbc

Nutzt man die Zeile für “Ciphers” in der angegebenen Form, so funktioniert dies zwar für eine native SSH-Verbindung von der Kommandozeile eines Terminalfensters aus; Eclipse reagiert jedoch traurigerweise mit einer Exception “….. java.lang.NullPointerException“.

Ursache dafür ist eine falsche Behandlung von Domain-Angaben in den Cipher-Verfahren durch die zuständigen Eclipse-Module. Interessanterweise funktionieren aber die Domain-Angaben hinter den KEX-Verfahren!

Folgende Variante funktioniert mit den SSH-Modulen von Eclipse:

Funktionierende SSH-config-Datei für Eclipse:

  
Host myserv.myhosteddomain.net
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
# The following does not 
work in Eclipse 
# Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr,aes192-cbc
# This works, however: 
Ciphers aes256-cbc,aes256-ctr 

Es ist irgendwie traurig, dass Eclipse sich in puncto SSH und Cipher-Angaben fehlerhaft verhält; denn man steht nun vor einer (geringfügigen) Einschränkung der Sicherheit. 256Bit basierte AES-Verfahren sollten im Moment allerdings noch ausreichen.

Ich hoffe, das hilft dem einen oder anderen, der auf die oben genannte Exception stößt. Zu hoffen bleibt auch, dass die Eclipse-Entwickler solche Bugs baldmöglichst beseitigen.