@"Chefentwickler"

Ok, du hast also einen Screenshot meines aktuellen Projekts gesehen und er gefällt dir nicht. Es ist aber falsch, das auf Java zu schieben. Eine Sache, die du bezüglich Java immer im Hinterkopf haben solltest ist, dass es nicht "das" Aussehen von Java gibt. In Java kann man das Aussehen der GUI mit ganz wenigen Handgriffen relativ stark verändern. Man kann entsprechende Veränderungen sogar vom Nutzer zur Laufzeit machen lassen. Mit einem Klick könnten die Komponenten dann zum Beispiel so aussehen. Wobei es natürlich auch Look&Feels gibt, die noch stärker vom Metal-L&F abweichen.

Wenn du nicht das Aussehen der Komponenten meintest, sondern das Layout und den generellen Aufbau der GUI, dann liegt das auch nicht an Java, sondern an mir. Ich lasse die GUI in meinem Programm zu großen Teilen automatisch generieren und bisher hat mich das Aussehen nicht dermaßen interesiert, dass ich da besonders viel Arbeit hinein gesteckt hätte. Mir reicht es eigentlich, wenn ich das Programm durch die GUI halbwegs vernünftig bedienen kann und das kann ich mit der momentanen GUI.

Aber eines haben alle Java-GUIs gemein: Sie sind SAU LAHM!!!

Ja! Gib's ihm!

Und kein Look & Feel ist schön.

wursel schrieb:

Ja! Gib's ihm!

Und in dem anderen Thread sagst du

wursel schrieb:

Kopf hoch, Gregor! Lass dich von denen nicht entmutigen, ich glaub an dich!

Gregor, wie gehts eigentlich deiner (Ex)Freundin?

Korbinian

Hey Gregor,
woher bekommst du die sampledaten für solche Spielereien? Ich suche schon lang nach ein paar Samplebildern um ein paar Sachen zu testen, wollte schon fast mal in der Uni fragen (aber die arbeiten meist mit künstlichen Projektionen). Wär nett wenn du mir mal einen Tip geben würdest

hier

@Korbinian: Eine ganze Menge solche Volumen gibt es da: http://www.volvis.org/

Die liegen da allerdings in einem raw-Format vor. Die Werte der einzelnen Voxel sind also einfach aneinandergereiht in einer Datei abgespeichert. Das reicht natürlich nicht, um so ein Volumen zu laden. Du brauchst noch ein paar mehr Daten wie Höhe, Breite, Tiefe und so weiter. Diese Infos findest du auch auf der Seite. Ich schreibe mir die Dann immer in eine "raw.info"-Datei, die ich zum Laden nutze. Die sieht bei dem Hummer da zum Beispiel so aus:

description = CT scan of a lobster contained in a block of resin.
width = 301
height = 324
depth = 56
datatype = UNSIGNED_BYTE
x-scale = 1
y-scale = 1
z-scale = 1.4

Solche Info-Dateien sind auch mehr oder weniger üblich, aber AFAIK nicht standardisiert. ...zumindest habe ich nie eine formale Beschreibung dieses Formats gefunden. Denk dir also selbst was aus, wenn du da mehr Infos drin brauchst.

DrGreenthumb

Chefentwickler schrieb:

Aber eines haben alle Java-GUIs gemein: Sie sind SAU LAHM!!!

azureus ist java und hat ne GTK-Oberfläche, die ist nicht sau-lahm.

Aber eines haben alle Java-Swing-GUIs gemein: Sie sind SAU LAHM!!!

2 schrieb:

Aber eines haben alle Java-Swing-GUIs gemein: Sie sind SAU LAHM!!!

Ja? Weiß nicht. Kannst du da mal quantitative Angaben machen? Zum Beispiel durch nen Benchmark, in dem Swing mit anderen GUI-Toolkits verglichen wird?

Zumindest bei meinem Programm kann ich eindeutig sagen, dass das Problem nicht die Geschwindigkeit des GUI-Toolkits ist. Wenn man Datensätze darstellen will, die teilweise bis zu 170MB groß sind, dann kommen Performanceprobleme sicherlich nicht dadurch, dass irgendein Label doppelt so lange zum Zeichnen braucht als bei nem anderen Toolkit.

Ringding

QT ist außerdem auch saulahm...

Wenn wir schon beim bashen sind

Ringding schrieb:

QT ist außerdem auch saulahm...

Wenn wir schon beim bashen sind

QT ist aber cool

GUI-Systeme sind fast nie so lahm, dass ein kümmerlicher Mensch das sehen würde. Der Hauptpunkt ist hier immer die gefühlte Performance: Man drückt nen Knopf und es dauert ne Sekunde, bis das Ergebnis da ist. Das kann man durch rumblinkendes Klickibunti ganz erheblich verhindern.
Wenn ich in der Windows-Systemsteuerung bei den Darstellungsoptionen was verändere und auf OK drücke, bleibt der Button auch für eine Sekunde lang eingedrückt. Ich würde allerdings nicht vermuten, dass es so lange dauert, den Button wieder grafisch hochschnellen zu lassen.
In Eclipse wenn ich zum ersten mal nen Rechtsklick im Code-Editor mache, dauert es ne Sekunde bis das Menü da ist. Das liegt auch nicht am lahmen GUI, sondern daran, dass die entsprechenden Plugins zum ersten mal geladen werden (von der Platte!).

Fast alle Java-GUI-Programmierer sind schlecht.

Ringding

Optimizer schrieb:

GUI-Systeme sind fast nie so lahm, dass ein kümmerlicher Mensch das sehen würde.

In den meisten Fällen stimmt das. Aber beim Scrollen in Listen/Trees o.ä. ganz und gar nicht. Da macht es einen großen Unterschied, ob das Ding mit der Samplerate der Maus mitkommt oder ob nur 10-20 fps gezeichnet werden, wie es bei QT üblicherweise der Fall ist.

DrGreenthumb

Ringding schrieb:

QT ist außerdem auch saulahm...

unter windows?

Ringding

DrGreenthumb schrieb:

unter windows?

Ja.

Unter Linux ist alles saulahm (was mit GUIs zu tun hat, meine ich...).

Ringding schrieb:

DrGreenthumb schrieb:

unter windows?

Ja.

Unter Linux ist alles saulahm (was mit GUIs zu tun hat, meine ich...).

Troll oder ernst?

@&quot;Chefentwickler&quot;

@"Chefentwickler"