Eclipse Srollen, wo immer die Maus gerade ist ...

[kceenav]

Bei "NetBeans" ist mir als sehr praktisch aufgefallen:

Unabhängig davon, welches Unterfenster gerade den Focus hat, bewirkt Bildlauf per mittlerer Maustaste, dass die ScrollPane unter dem Mauszeiger bewegt wird (sofern vorhanden). In Elipse muss man immer erst in das gewünschte Fenster klicken (oder sonstwie den Focus dorthin verlagern), um srollen zu können. Kann man das womöglich ändern?

(Höchstwahrscheinlich nicht - aber wer nicht fragt ... )

 

[Wildcard]

Dann benutzt du wohl Windows? Bei Windows funktioniert das nunmal so (Netbeans ist Swing, daher verhält es sich anders als das OS). Gnome (Linux) hat zB das von dir gewünschte Verhalten (bei KDE weiß ich es gerade nicht, vermute aber das es auch dort so ist).

 

[kceenav]

Hallo,

ja, ich arbeite unter Windows XP. Aber es geht bei meiner Frage speziell um die Eclipse IDE. Und die ist doch wohl genauso in JAVA programmiert wie NetBeans, oder?

So oder so nehme ich an, dass sich das von mir als sehr viel praktischer empfundene Verhalten der NetBeans IDE überall realisieren lässt -- wenn die Entwickler nur wollen bzw. nicht 1000 andere Dinge für wichtiger halten.
(Womit sie vielleicht sogar recht haben ... Und vermutlich gibt's sogar Leute, die es so gut finden, wie es ist ... :noe

 

[musiKk]

Dann nochmal von jemandem anders: Unter Windows ist das normal. Wenn NetBeans das so handhabt, dann ist das eine Besonderheit. Unter Gnome (und ich vermute ebenfalls, dass es bei KDE auch möglich ist) scrollt jedes Element, welches unter der Mausposition ist - unabhänig vom Fokus. Unter Windows benötigt das Element den Fokus; man kann nicht einmal scrollen, wenn zwar das Fenster, aber darin ein Button den Fokus hat.

Du kannst aber mal versuchen, nach einem entsprechenden Programm zu googlen. Manches Verhalten, welches unter Window Managern unter Linux Standard ist, lässt sich nachrüsten (z. B. das von mir geliebte Alt+Mausklick zum Verschieben oder snappende Fenster).

 

[kceenav]

Okay, natürlich ist es gut zu wissen, dass es sich bei dem aus meiner Sicht unpraktischen Scroll-Verhalten um etwas Plattformtypisches handelt.

Nur -- Ist das ja nicht wirklich ein triftiger Grund, ein sinnvolles Feature bei einem in der Handhabung relativ komplexen Programm wie einer IDE wegzulassen. Und wie man sieht, haben die NetBeans-Leute sich über die Windows-Konvention hinweggesetzt. Wenn man das so nennen will. Dort ist das "sinnvollere" Verhalten von Haus aus aktiv, man muss es also nicht mal extra einstellen. (Was allerdings mit Rücksicht auf die Plattform-Konventionen vielleicht "korrekt" wäre.)

Die entscheidende Frage ist eigentlich, ob ich und etwaige anderer Nutzer, die wir das NetBeans-Verhalten zweckmäßiger finden, damit eine Minderheit darstellen oder nicht. Ich vermute stark, eine so kleine Minderheit wird's schon nicht sein, dass es abwegig wäre, an eine Konfigurationsmöglichkeit in Eclipse zu denken.

Aber, gebrauchen kann man Eclipse durchaus auch ohne dies.

 

[Antoras]

Und wie man sieht, haben die NetBeans-Leute sich über die Windows-Konvention hinweggesetzt.

Das waren nicht die Leute die NetBeans, sondern die, die Swing programmiert haben. Bei SWT, das auf der Windows-API aufsetzt, ist das nun mal anders.

Die GUI-Bauer von Eclipse haben da erst mal gar keine Möglichkeit das einfach so zu ändern. Ich kenn mich mit der Philosophie von SWT aber auch nicht aus. Vllt. soll SWT ja gerade das Verhalten des Window-Managers ohne Ausnahme besitzen.

 

[kceenav]

Das waren nicht die Leute die NetBeans, sondern die, die Swing programmiert haben. Bei SWT, das auf der Windows-API aufsetzt, ist das nun mal anders.

Ach so, das war es wohl, was mir schon die Vorredner sagen wollten.

Die GUI-Bauer von Eclipse haben da erst mal gar keine Möglichkeit das einfach so zu ändern. Ich kenn mich mit der Philosophie von SWT aber auch nicht aus. Vllt. soll SWT ja gerade das Verhalten des Window-Managers ohne Ausnahme besitzen.

Dass ich mich mit diesen Dingen auskenne, kann ich wahrlich auch nicht behaupten. Es würde mich aber schon sehr wundern, wenn man nicht auch auf der Basis des SWT das fragliche Verhalten so ändern könnte, wie ich mir das wünschen würde.

Es leuchtet mir aber einigermaßen ein, falls die Eclipse-Entwickler das aus Prinzip nicht gerne wollen, jedenfalls sofern es sich um einen letztlich nicht so wahnsinnig wichtigen Punkt handelt.

 

[Wildcard]

Das es in Netbeans funktioniert ist kein Netbeans Feature, sondern ein Bug in Swing, dass an dieser Stelle das Plattformverhalten nicht richtig emuliert. Eclipse verwendet SWT und damit native Widgets und somit verhält sich SWT automatisch korrekt anhand der Vorgaben des Window Managers des OS.

 

[kceenav]

Das es in Netbeans funktioniert ist kein Netbeans Feature, sondern ein Bug in Swing, dass an dieser Stelle das Plattformverhalten nicht richtig emuliert.

Das scheint mir aber nun ein ziemlich weit gefasstes Verständnis des Begriffs "Bug" zu sein ...

Wie auch immer -- Ich halte das Zusammenspiel von Mausposition und ScrollPane, wie es bei NetBeans (Swing..) vorliegt, dem (m.M.n. total umständlichen) "Plattformverhalten" unter Windows für ganz klar überlegen. Warum man bei so einem Punkt stur darauf pocht, dass diese Funktionsweise aber nunmal nicht sein dürfe, weil nicht "korrekt", ohne im Mindesten zu erwägen, was denn wohl das tatsächlich von den meisten Nutzern bevorzugte Verhalten wäre, ist mir ein Rätsel. (Womit ich nicht behaupten will, ich wüsste mit Sicherheit, was die meisten Nutzer in dieser Hinsicht bevorzugen ...)

 

[Wildcard]

Das scheint mir aber nun ein ziemlich weit gefasstes Verständnis des Begriffs "Bug" zu sein ...

Ist es nicht. Das System L'n'F hat die Aufgabe so auszusehen wie native Widgets und sich anzufühlen wie native Widgets (hence the name Look and Feel). Wenn es das nicht tut, ist es ein Bug, so einfach ist das.
Ich will gar nicht mit dir darüber streiten dass es besser ist zu scrollen was sich unter dem Mausrad befindet, das sehe ich genauso. Daher verwende ich auch Linux, denn die Linux Window Manager sind besser als das Windows äquivalent.
Das ändert an der Tatsache aber nichts, dass es sich nicht um ein Netbeans Feature, sondern einen Swing Bug handelt.

 

[Antoras]

Das es in Netbeans funktioniert ist kein Netbeans Feature, sondern ein Bug in Swing, dass an dieser Stelle das Plattformverhalten nicht richtig emuliert.

Hä? Swing soll sich doch plattformunabhängig verhalten - im Gegensatz zu SWT.

 

[Wildcard]

Hä? Swing soll sich doch plattformunabhängig verhalten - im Gegensatz zu SWT.

Das Cross Platform Look and Feel soll sich plattformunabhängig verhalten, das System Look and Feel soll das Verhalten der platform simulieren. In weiten Strecken funktioniert das auch wie zB Popup Trigger, welches Key Event löst einen Button Klick aus, wie werden Mnemomic angezeigt, wie sieht ein default button aus und welcher key triggert ihn, usw.
Wenn es sich beim Scrolling unter Windows allerdings nicht an die Vorgaben hält, ist das ein Bug.

 

[Antoras]

NetBeans benutzt doch standardmäßig das MetalLookAndFeel und nicht irgend ein plaffformspezifisches.
Aber hab es gerade getestet - beim WindowsLookAndFeel wird tatsächlich gescrollt wenn man mit der Maus drüber geht, also ein Bug.

 

[Wildcard]

Netbeans nutzt standardmäßig das System Look and Feel, nicht Metal

 

[Antoras]

Hm, ok. Bei der von mir genutzten Linux-Distri benutzt NetBeans Metal. Da haben die Paketbauer wohl wieder rumgespielt.

 

[Wildcard]

Hm, ok. Bei der von mir genutzten Linux-Distri benutzt NetBeans Metal. Da haben die Paketbauer wohl wieder rumgespielt.

KDE? Ein System Look and Feel gibt es nur für Gtk, nicht für KDE, daher wird dort Metal/Aqua als Default verwendet.

 

[Antoras]

Ich verwende eigentlich schon GTK, allerdings nicht mit Gnome, sondern als Aufsatz für meinen WindowManager.
Hab gerade in der netbeans.conf die Einstellung

--laf com.sun.java.swing.plaf.gtk.GTKLookAndFeel

bei

netbeans_default_options

gesetzt und jetzt benutzt auch NetBeans GTK.
Hab keine Ahnung warum das standardmäßig nicht verwendet wird. Ist mir aber eigentlich auch egal, da ich die IDE sowieso nie verwende.