Sendertabelle verschmiert seit Anfang dieses Projekts

[dragos]

Hallo Leute

Das Programm soll einen Bug beseitigen, es handelt sich um die Sendertabelle unter Linux mit LXDE-GUI.

Unter LXDE hat der Window-Manager einen Bug, nämlich alle Komponenten die in einem JScrollPane eingebettet sind werden beim Rechts-Scrollen verschmiert. Ein Beispiel ist im unterem Bild geschieldert. Selbst bei den von mir entwickelten Java-Programmen habe ich diesen Bug unter LXDE immer beseitigen müssen. Ich weiß nicht wie viele Linux mit LXDE benutzen, vielleicht bin ich der einzige, aber der Bug existiert bei allen Java-Programmen.

Wenn gewünscht kann ich helfen, es handelt sich um ein paar Zeilen die man einfügen soll.

TV-Browser unter LXDE mit verschmierter Sendertabelle

beispiel.png (198.6 KiB) 8221 mal betrachtet

[v6ph1]

Wenn gewünscht kann ich helfen, es handelt sich um ein paar Zeilen die man einfügen soll.

Das wäre ganz nett.

Der Quellcode liegt übrigens unter https://svn.code.sf.net/p/tvbrowser/cod ... tvbrowser/
Dazu am besten gleich ein patch-File erstellen, das würde uns viel Arbeit abnehmen.

mfg
v6ph1

[ds10]

Tritt das bei allen verfügbaren Themas auf oder nur beim verwendeten Motif LookAndFeel?

Ich sehe eigentlich keinen Sinn darin TV-Browser anzupassen, wenn der Fehler bei Java liegt.

[ Post made via Android ]

[dragos]

Tritt das bei allen verfügbaren Themas auf oder nur beim verwendeten Motif LookAndFeel?

Ich sehe eigentlich keinen Sinn darin TV-Browser anzupassen, wenn der Fehler bei Java liegt.

Es tritt unter LXDE bei allen Java-Programmen, unabhängig von Themas auf.

Man muss noch den AdjustementListener bei jedem JScrollPane implementieren, dann geht es.

Beispiel:

Code: Alles auswählen

AdjustmentListener fixLXDEScrollBug = new AdjustmentListener() {

			@Override
			public void adjustmentValueChanged(AdjustmentEvent e) {
				((Component)e.getSource()).getParent().repaint();
			}
			
		};
		
		scrollPane.getHorizontalScrollBar().addAdjustmentListener(fixLXDEScrollBug);

[ds10]

Einen solchen Workaround möchte ich nicht einbauen. Der Fehler hat ursächlich behandelt zu werden, sei es bei Java oder LXDE.

[ Post made via Android ]

[dragos]

Einen solchen Workaround möchte ich nicht einbauen. Der Fehler hat ursächlich behandelt zu werden, sei es bei Java oder LXDE.

Nun ja, die Entscheidung liegt nicht bei mir, natürlich... Aber... wenn die Ursache Java selbst ist, wer passt sich dann an? Der Entwickler an die Programmiersprache, oder umgekehrt?

Es ist erwähnenswert, dass Java nicht gleich Java ist. Bei bestimmten Linux-Flavours wird Oracle-Java nicht mehr in Repositories angeboten (siehe Debian, Ubuntu, usw), stattdessen kann man sich OpenJava (bzw OpenJDK) herunterladen. Dabei gibt es bestimmte Feinheiten die man beachten muss.
Also auch bei Java musste sich leider herausstellen, dass man sich auf dünnem Eis bewegt (soviel zum Thema "plattformunabhängige Programmierung"). Die Foren sind diesbezüglich voller Beiträge zum Thema "OpenJava vs Java".

Ich weiß nicht wo der Fehler genau liegt, was ich aber mit Sicherheit weiß ist, dass auch bei der WinAPI-Programmierung (Windows Application Programming Interface - die niedrigste Stufe für Windowsprogrammierung) der Fall ähnlich ist.
Also Windows, bzw. Windows-GDI überlässt beim Scrollen absichtlich die freie Wahl dem Programmierer, und es ist seine Aufgabe / Entscheidung, ob der Bereich repaintet werden soll oder nicht, auch bei Double-Buffering. Wenn er den Bereich nicht repaintet, dann sieht man ein ähnliches Bild wie oben.

Ein anderes Beispiel wäre der Aufruf der Methode:

Code: Alles auswählen

setUndecorated( true )

Lässt man das Program unter Windows laufen, sieht man ein schönes blaues Fenster mit Titelleiste, Menüs und Systemknöpfen. Tut man dasselbe unter MacOS, sieht man keine Titelleiste, keine Menüs und auch keine Knöpfe. Auf Wunsch kann ich es auch beweisen.

Wenn es aber um Kompatibilität geht, dann soll man die Linux-Welt berücksichtigen. Und sie ist ziemlich groß und bunt. Sonst zwingt man bestimmte Nutzerkategorien andere GUIs zu benutzen, weil ein Workaround mit "repaint" nicht erwünscht ist.

Schade...

[ds10]

Nun ja, die Entscheidung liegt nicht bei mir, natürlich... Aber... wenn die Ursache Java selbst ist, wer passt sich dann an? Der Entwickler an die Programmiersprache, oder umgekehrt?

Du hast doch selbst geschrieben, dass der Fehler im WindowManager von LXDE liegt. Also sind die LXDE-Entwickler in der Pflicht diesen Fehler zu beseitigen, falls der denn bei LXDE liegen sollte. Alles andere ist Schwachsinn. Man muss sich nur mal überlegen, welchen Overhead es produziert für jedes Scrollpane einen AdjustmentListener zu setzen und das bei allen Java-Programmen. Es ist falsch die Wirkung eines Fehlers zu bekämpfen anstatt die Ursache.

Dabei ist es auch komplett belanglos, was die Windows-API macht oder vom Programmierer verlangt.

Ein anderes Beispiel wäre der Aufruf der Methode:

Code: Alles auswählen

setUndecorated( true )

Lässt man das Program unter Windows laufen, sieht man ein schönes blaues Fenster mit Titelleiste, Menüs und Systemknöpfen.

Nein sieht man nicht (sowohl unter Windows XP als auch unter Windows 8 ), würde man die sehen, dann hätte Java einen Fehler, denn diese Methode dient ja gerade dazu die entsprechenden Informationen auszublenden. Würde es nicht funktionieren, dann würden auch bei TV-Browser ein Haufen Fenster eine Dekoration haben, die aber keine zeigen.

Wenn es aber um Kompatibilität geht, dann soll man die Linux-Welt berücksichtigen.

Die wird berücksichtigt, schließlich befinde ich mich selbst auf einem Linux.

Ich habe mir einfach mal den Spaß gemacht und Lubuntu in einer VM gestartet und da verschmiert überhaupt nichts. Weder beim Scrollen nach rechts, links, oben oder unten auf dem Lubuntu-Login, LXDE-Login oder dem Openbox-Login. Also scheint es ja zumindest noch ein paar mehr Anforderungen zu geben (z.B. die verwendete Grafikkarte/Treiber), damit der Bug auftritt, denn ich kann ihn nicht einmal reproduzieren.

[dragos]

ds10,

hier ein kleines Beispiel von setUndecorated. Diese Blackbox sieht sowohl unter Linux, als auch unter Windows gleich aus. Nur unter MacOS gab es Probleme, zumindest letztes Jahr, da man auf Mac die Titelleiste nicht sehen konnte. Hoffentlich hat sich einiges inzwischen geändert. Ich weiß nur was ich für Kopfschmerzen letztes Jahr deswegen kriegte.

Es ist mir schon klar welchen Overhead man produziert wenn man einen Listener einsetzt. Als Beispiel kannst du das Gitter auf dem Bild betrachten. Seine Klasse implementiert die Methode "paintComponent".

Und ja, du hast vollkommen Recht, es gibt einen Unterschied zwischen Behandeln und Heilen, da stimme ich dir voll zu. Aber was ich meinte, war nämlich genau diese Inkompatibilität. Man will doch Kompatibilität auf allen Plattformen erzielen.

Wenn ich gewusst hätte, dass du den Test in einer VM durchführst, hätte ich dich darum gebeten Debian Wheezy + LXDE zu installieren, weil das nämlich mein Problem ist. Wobei die VM auch nicht so glaubwürdig ist, weil sie Generic-Treiber anbietet (zumindest VMWare).
Wie gesagt - ich weiß nicht genau wo der Fehler liegt, aber mit Sicherheit liegt es entweder an JRE, oder am LXDE. Es wäre zu tragisch wenn es an Debian selbst (DEBIAN - Der Gott aller Derivate!!!) liegen würde.

Jedenfalls werde ich mir morgen Mühe geben, TV-Browser mit anderen Treibern zu testen, dann melde ich mich wieder. Wenn es an den Treibern liegt, dann ist es schlimm...

P.S. Ich habe vergessen zu erwähnen: Eclipse läuft ironischerweise tadellos!

[ds10]

Dass es auf Macs zu Inkompatibilitäten kommt, kann schon sein, die VM hat bis vor kurzen Apple selbst programmiert und jetzt macht es Oracle, wer weiß schon ob die das alles korrekt implementiert haben. Für dein Beispiel verwendest du aber bewusst nicht die Standarddekoration, sondern schaltest diese ja mit setUndecorated(true) ab und lässt stattdessen auf dem JRootPane die Alternative zeichnen. Und ich würde einfach mal vermuten, dass die alternative Dekoration von Java selbst gezeichnet wird, die Standarddekoration aber vom Betriebssystem.

Da Eclipse SWT verwendet, ist es auch nicht verwunderlich, dass sich Eclipse anders verhält als in Swing geschriebene Applikationen.

[ds10]

So nach zwei weiteren Tests (einmal LXDE auf meinem System und einmal LXDE auf Debian in der Oracle VM VirtualBox) kann ich den Fehler immer noch nicht nachvollziehen. Es gibt einfach kein Verschmieren, das deutet immer deutlicher auf ein Problem mit der Grafikkarte oder deren Treiber hin.

[dragos]

NVIDIA-Treiber gelöscht, hier das Ergebnis mit dem x-server-Treiber. Ich werde auch mit dem Laptop versuchen, es wird aber eine Weile dauern. Wenn du willst kann ich auch eine kleine Aufnahme machen.

[ds10]

Wenn du willst kann ich auch eine kleine Aufnahme machen.

Ja, das wäre mal recht interessant.

[dragos]

Debian Wheezy - clean Install auf dem Laptop: NVIDIA GeForce 9500M GS 512 MB, mit OpenJava 6

[ds10]

Das stützt ja die These, dass es an der Grafikkarte liegt, du hast in beiden Fällen NVIDIA und ich habe hier Intel-Grafik.

[dragos]

Aber auf 2 verschiedenen Systemen (Desktop und Laptop mit 2 verschiedenen NVIDIA-Graphikkarten), mit und ohne NVIDIA-Treibern tritt derselbe Fehler auf. Auf dem Laptop habe ich Debian extra installiert, um zu sehen ob es klappt. Leider nicht...