Discussion:
GridLayout mit unterschiedlicher Zeilenhoehe
(zu alt für eine Antwort)
Patrik Nagel
2005-09-09 13:13:10 UTC
Permalink
Hallo zusammen!

Ich habe innerhalb eines BorderLayout geschalchtelte GridLayouts
erstellt. Leider füllen dann z.B. TextFelder oder Buttons den "maximal"
verügbaren Platz innerhalb ihrer Zelle im GridLayout.
Das Gitterraster soll erhalten bleiben, aber die einzelnen Komponenten
innerhalb des Gitters in einer gewünschten Groesse angezeigt werden.
Wie kann ich das realiseren??

Vielen Dank
Patrik
Helmut Leininger
2005-09-09 14:39:54 UTC
Permalink
Post by Patrik Nagel
Hallo zusammen!
Ich habe innerhalb eines BorderLayout geschalchtelte GridLayouts
erstellt. Leider füllen dann z.B. TextFelder oder Buttons den "maximal"
verügbaren Platz innerhalb ihrer Zelle im GridLayout.
Das Gitterraster soll erhalten bleiben, aber die einzelnen Komponenten
innerhalb des Gitters in einer gewünschten Groesse angezeigt werden.
Wie kann ich das realiseren??
Vielen Dank
Patrik
Vielleicht mit GridBagConstraints padding (ipadx, ipady) oder insets?
Patrik Nagel
2005-09-09 15:03:02 UTC
Permalink
Post by Helmut Leininger
Vielleicht mit GridBagConstraints padding (ipadx, ipady) oder insets?
Aha, das Stichwort heisst also *GridBagLayout*. War in meinen Unterlagen
nicht aufgeführt...werd's mir gleich anschauen.

Vielen Dank
Patrik
Stephan Friedrichs
2005-09-09 14:59:55 UTC
Permalink
Post by Patrik Nagel
Hallo zusammen!
Moin!
Post by Patrik Nagel
Ich habe innerhalb eines BorderLayout geschalchtelte GridLayouts
erstellt. Leider füllen dann z.B. TextFelder oder Buttons den "maximal"
verügbaren Platz innerhalb ihrer Zelle im GridLayout.
Das Gitterraster soll erhalten bleiben, aber die einzelnen Komponenten
innerhalb des Gitters in einer gewünschten Groesse angezeigt werden.
Wie kann ich das realiseren??
AFAIK füllen die Komponenten bei GridLayout ihre Zellen _immer_ komplett
aus. Probier doch mal GridBagLayout aus, damit kann man eigentlich alles
erschlagen.
Post by Patrik Nagel
Vielen Dank
Patrik
HTH - Stephan
--
A: Because it breaks the logical sequence of discussion.
Q: Why is top posting bad?
--
If a private response to this posting is necessary,
please respond to SFriedrichs [at] t-online [dot] de,
as this postings 'From' is solely used for spam protection.
Paul Schwann
2005-09-09 15:45:06 UTC
Permalink
Post by Stephan Friedrichs
AFAIK füllen die Komponenten bei GridLayout ihre Zellen _immer_
komplett aus. Probier doch mal GridBagLayout aus, damit kann man
eigentlich alles erschlagen.
Nein, dass bestimmen die Contraints, welche für jede Komponente gesetzt
werden. Mit dem Parameter "fill" kann z.B. bestimmt werden, ob die
Komponente sich gar nicht, nur in X, nur in Y oder in beide Richtungen
(innerhalb ihres Grids) ausdehnt.
Welche Position innerhalb des Grids (bei nicht vollständiger
Ausfüllung) eingenommen wird, bestimmt dann der Parameter "anchor".
Dokumentation lesen bildet, gerade bei diesem Monstrum...

Paul
Stephan Friedrichs
2005-09-09 16:28:00 UTC
Permalink
Post by Paul Schwann
Post by Stephan Friedrichs
AFAIK füllen die Komponenten bei GridLayout ihre Zellen _immer_
^^^^^^^^^^
Post by Paul Schwann
Post by Stephan Friedrichs
komplett aus. Probier doch mal GridBagLayout aus, damit kann man
^^^^^^^^^^^^^
Post by Paul Schwann
Post by Stephan Friedrichs
eigentlich alles erschlagen.
Nein, dass bestimmen die Contraints, welche für jede Komponente gesetzt
werden. Mit dem Parameter "fill" kann z.B. bestimmt werden, ob die
Komponente sich gar nicht, nur in X, nur in Y oder in beide Richtungen
(innerhalb ihres Grids) ausdehnt.
Deswegen gab ich doch den Tipp Grid_Bag_Layout statt GridLayout.
Post by Paul Schwann
Welche Position innerhalb des Grids (bei nicht vollständiger Ausfüllung)
eingenommen wird, bestimmt dann der Parameter "anchor". Dokumentation
lesen bildet, gerade bei diesem Monstrum...
Moment, Missverständnis! Redest du jetzt von GridLayout oder von
Grid_Bag_Layout? Also AFAIK meinte der OP GridLayout und ich verwies auf
GridBagLayout, weil es flexibler ist.

GridLayout
-> keine Constraints
-> sture Tabelle
-> alles gleich groß
-> alle Zellen gefüllt (bis auf hgap und vgap)

GridBagLayout
-> GridBagConstraints mit x, y, fill, anchor, uvm.
-> flexibel
-> komplex

oder?
Post by Paul Schwann
Paul
MFG - Stephan
--
A: Because it breaks the logical sequence of discussion.
Q: Why is top posting bad?
--
If a private response to this posting is necessary,
please respond to SFriedrichs [at] t-online [dot] de,
as this postings 'From' is solely used for spam protection.
Paul Schwann
2005-09-09 16:37:26 UTC
Permalink
Hast ja recht! Beim GridLayout (ohne Bag ;-) ist zwar alles einfacher,
aber auch wesentlich weniger flexibel...

Paul
Karsten Lentzsch
2005-09-09 17:56:02 UTC
Permalink
Post by Patrik Nagel
Ich habe innerhalb eines BorderLayout geschalchtelte GridLayouts
erstellt. Leider füllen dann z.B. TextFelder oder Buttons den "maximal"
verügbaren Platz innerhalb ihrer Zelle im GridLayout.
Das Gitterraster soll erhalten bleiben, aber die einzelnen Komponenten
innerhalb des Gitters in einer gewünschten Groesse angezeigt werden.
Wie kann ich das realiseren??
Das geht nicht mit dem GridLayout.
GridBagLayout (GBL) kann schon mehr, aber viele Entwickler
empfinden ihn als kompliziert zu lernen und zu programmieren.
Außerdem ist GBL ein eher schwacher Layout-Manager; etliche
essentielle Layout-Aufgaben kann er nicht lösen.

Ich biete einen Layout-Manager und dazu ein Layout-System,
das Einfaches einfach macht und Kniffliges möglich,
gute Gestaltung leicht und schlechte schwierig. Es ist
kostenlos, quelloffen und auf produktniveau gepflegt:
http://www.jgoodies.com/freeware/forms/index.html

Eine Demo, die löst, was das GBL nicht kann, ist hier:
http://www.jgoodies.com/freeware/formsdemo/index.html

Gruß aus Kiel,
Karsten Lentzsch
Patrik Nagel
2005-09-10 08:43:02 UTC
Permalink
Post by Karsten Lentzsch
http://www.jgoodies.com/freeware/formsdemo/index.html
Vielen Dank für den Hinweis. Weil dies mein *erstes* Java-Projekt ist,
werde ich das GUI "von Hand" implementieren. Ist denke ich für einen
Newbie eine gute Übung...

Schönes Weekend
Patrik
Stefan Ram
2005-09-10 10:40:09 UTC
Permalink
Post by Karsten Lentzsch
http://www.jgoodies.com/freeware/formsdemo/index.html
Die Demo beginnt mit einem License-Assistenten. Dessen unterer
Teil mit Tastflächen wird auf einem Bildschirm mit 1024x768
Bildpunkten unter dem Betriebssystem "Microsoft® Windows 98"
anscheinend in einigen Fällen von der unteren Vorgangsleiste
verdeckt.

Dann steht da nur auf einer riesigen aber weitgehend
ungenutzten Fläche "Welcome to The JGoodies Forms Demo" und
man wundert sich, warum es nicht weitergeht. - Die Tastfläche
[Next >] sieht man nämlich (zum größten Teil) nicht.
Stefan Ram
2005-09-10 10:46:11 UTC
Permalink
Die Demo beginnt mit einem License-Assistenten. Dessen unterer
Teil mit Tastflächen wird auf einem Bildschirm mit 640x480
Bildpunkten unter dem Betriebssystem "Microsoft® Windows 98"
anscheinend in einigen Fällen von der unteren Vorgangsleiste
verdeckt.

Dann steht da nur auf einer riesigen aber weitgehend
ungenutzten Fläche "Welcome to The JGoodies Forms Demo" und
man wundert sich, warum es nicht weitergeht. - Die Tastfläche
[Next >] sieht man nämlich (zum größten Teil) nicht.
Stefan Ram
2005-09-10 11:24:40 UTC
Permalink
Post by Stefan Ram
Die Demo beginnt mit einem License-Assistenten. Dessen unterer
Teil mit Tastflächen wird auf einem Bildschirm mit 640x480
Bildpunkten unter dem Betriebssystem "Microsoft® Windows 98"
anscheinend in einigen Fällen von der unteren Vorgangsleiste
verdeckt.
Und wo ich gerade dabei bin: Wenn die Anzeige unter demselben
Betriebssystem nur 256 Farben hat, erscheint der
Startbildschirm mit der Fortschrittsanzeige, der zuallererst
kommt, ganz in schwarz (man kann nichts lesen und sieht kein
Bild). Nur der Fortschrittsbalken selber ist in Schwarz-Weiß
sichtbar.
Stefan Ram
2005-09-10 11:25:50 UTC
Permalink
Post by Stefan Ram
Und wo ich gerade dabei bin: Wenn die Anzeige unter demselben
Betriebssystem nur 256 Farben hat, erscheint der
Startbildschirm mit der Fortschrittsanzeige, der zuallererst
kommt, ganz in schwarz (man kann nichts lesen und sieht kein
Bild). Nur der Fortschrittsbalken selber ist in Schwarz-Weiß
sichtbar.
... und das Windows-Icon (Programmsymbol) ist dann nur
eine strukturlose weiße Fläche.
Frank Buss
2005-09-10 11:33:14 UTC
Permalink
Post by Stefan Ram
Die Demo beginnt mit einem License-Assistenten. Dessen unterer
Teil mit Tastflächen wird auf einem Bildschirm mit 640x480
Bildpunkten unter dem Betriebssystem "Microsoft® Windows 98"
anscheinend in einigen Fällen von der unteren Vorgangsleiste
verdeckt.
naja, auf museumsreifen Computern und Bildschirmauflösungen wirst du mit
Java sowieso kein Spaß haben :-)
--
Frank Buß, ***@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Stefan Ram
2005-09-10 12:01:03 UTC
Permalink
Post by Frank Buss
naja, auf museumsreifen Computern und Bildschirmauflösungen
wirst du mit Java sowieso kein Spaß haben :-)
Ich habe tatsächlich auch auf solchen Computern Spaß mit Java.
(Natürlich macht es im allgemeinen mehr Spaß, Java-Programm zu
schreiben als sie dann zu benutzen.)

Tatsächlich sind fast alle von mir verwendeten
Windowsprogramme unter 640x480 Punkten mit 256 Farben noch
erkennbar und bedienbar -- auch noch Programme, die in den
letzten Jahren neu entstanden sind. Die meisten Hersteller
achten immer noch darauf, daß die Erkennbarkeit und
Bedienbarkeit dann gewahrt bleibt, selbst wenn dabei natürlich
etwas Übersichtlichkeit verloren gehen kann oder Ausschnitte
auf dem Bildschirm manchmal verschoben werden müssen (etwa
Texte, die nicht mehr als ganzes in ein Fenster passen).

Programmsymbole werden in .ico-Dateien wohl auch in
verschiedenen Auflösungen (und Farbtiefen) abgelegt.
Timo Stamm
2005-09-10 15:30:36 UTC
Permalink
Post by Frank Buss
Post by Stefan Ram
Die Demo beginnt mit einem License-Assistenten. Dessen unterer
Teil mit Tastflächen wird auf einem Bildschirm mit 640x480
Bildpunkten unter dem Betriebssystem "Microsoft® Windows 98"
anscheinend in einigen Fällen von der unteren Vorgangsleiste
verdeckt.
naja, auf museumsreifen Computern und Bildschirmauflösungen wirst du mit
Java sowieso kein Spaß haben :-)
80x24 mit 1 bit Farbtiefe reicht!
Paul Ebermann
2005-09-10 19:23:40 UTC
Permalink
Post by Timo Stamm
Post by Frank Buss
naja, auf museumsreifen Computern und Bildschirmauflösungen wirst du mit
Java sowieso kein Spaß haben :-)
80x24 mit 1 bit Farbtiefe reicht!
Naja, das ist ja geschummelt, wenn du noch unterschiedlich
geformte "Pixel" (aka Buchstaben) zulässt.

Wenn du es richtig machst (also nur weiße und schwarze Kästchen),
ist das nicht ganz so nutzbar (naja, drei Zeilen Text bekommt man
damit schon hin).


Paul
--
Die Homepage von de.comp.lang.java: http://www.dclj.de
Pauls Package-Sammlung: http://purl.org/NET/ePaul/#pps
Timo Stamm
2005-09-11 05:55:06 UTC
Permalink
Post by Paul Ebermann
Post by Timo Stamm
Post by Frank Buss
naja, auf museumsreifen Computern und Bildschirmauflösungen wirst du mit
Java sowieso kein Spaß haben :-)
80x24 mit 1 bit Farbtiefe reicht!
Naja, das ist ja geschummelt, wenn du noch unterschiedlich
geformte "Pixel" (aka Buchstaben) zulässt.
Wie gut dass ich nicht von Pixeln gesprochen habe :)

Karsten Lentzsch
2005-09-10 11:53:07 UTC
Permalink
Post by Stefan Ram
Die Demo beginnt mit einem License-Assistenten. Dessen unterer
Teil mit Tastflächen wird auf einem Bildschirm mit 640x480
Bildpunkten unter dem Betriebssystem "Microsoft® Windows 98"
anscheinend in einigen Fällen von der unteren Vorgangsleiste
verdeckt.
[...]
Vielen Dank für die freundlichen Hinweise.
Diese und andere Einschränkungen sind mir bekannt.

Ich wäge ab, wieviel Kraft ich für Plattformen
und Umgebungen verwende. Und schon 1999 habe ich
mich bei meinem JDiskReport entschieden, nicht mehr
für 640x480 und für geringe Farbtiefen zu gestalten.

Besten Gruß aus Kiel,
Karsten
Peter Büttner
2005-09-10 13:34:31 UTC
Permalink
Post by Karsten Lentzsch
Post by Stefan Ram
Die Demo beginnt mit einem License-Assistenten. Dessen unterer
Teil mit Tastflächen wird auf einem Bildschirm mit 640x480
Bildpunkten unter dem Betriebssystem "Microsoft® Windows 98"
anscheinend in einigen Fällen von der unteren Vorgangsleiste
verdeckt.
[...]
Vielen Dank für die freundlichen Hinweise.
Diese und andere Einschränkungen sind mir bekannt.
Ich wäge ab, wieviel Kraft ich für Plattformen
und Umgebungen verwende. Und schon 1999 habe ich
mich bei meinem JDiskReport entschieden, nicht mehr
für 640x480 und für geringe Farbtiefen zu gestalten.
Je nach Ziel eine vernünftige Entscheidung. Gerade für 256 oder gar
16 Farben ist unangenehm (und die sind auch recht unüblich geworden)

Mit aufkommen von mobilen Geräten (die inzwischen allerdings meist
auch 16k+ Farben haben) könnte man bei mancher Software mal dran
denken das es inzwischen wieder komplexer wurde.
Ich habe mal bischen für Palm programmiert, als die noch 160² Pixel
in 1 bit 'Farbe' hatten: 'einfache Welt' :-)


Die Bildschirmgröße ist mit FormLayout ja unerheblich, das geht
fast von selbst:-) (Man kann je nach Zielgruppe dran denken sein
Panel in eine scrollpane zu packen)

Wobei bei der Schirmgröße heutzutage wohl eher eine Diversifikation
gegenüber früher herrscht. 800x600 findet man bei einigen Einfachgeräte
usern noch, andere arbeiten auf 3000x1000+ multibildschirmumgebungen,
und alle Bereiche dazwischen. Da wurde es z.B. nun wichtig eine
Messagebox nicht auf dem ersten sondern dem richtigen Monitor
aufzumachen (Ok, unter *nix ist sowas schon lange üblich)




Grüße
Peter
--
Shell&Jar : Individual icons for jars
jMineSweeper : extended
www.PeterBuettner.de
Loading...