SWT Layout mit Sections aus Eclipse Forms

[dzim]

Tach,

ich hab da mal ne Frage zum Thema Layout mit Sections in Eclipse Forms.
Ich habe ein Programm, dass einen View zum Navigieren in Plugins bietet. Dieser View besteht im Prinzip nur aus dynamisch untereinander angeordneten Sections, deren Client-Area jeweils mit einem TreeViewer befüllt ist.
Nun ist es so, dass ich in jedem TreeViewer beim erstellen des jeweiligen Trees "viewer.setAutoExpandLevel(TreeViewer.ALL_LEVELS);" machen muss, ansonsten wird die Höhe der Section-Inhalte nicht richtig berechnet. Sprich, mache ich das nicht, wird nur eine Default-Höhe der Sections angenommen und wenn ich dann die Trees expandiere, bleibt die höhe der Client-Area der Sections gleich.
Ich verwende derzeit GridLayout(1, true) wobei das passiert, wie die angehängten Bilder darstellen sollen.

Bild 1: alle Plugins, eins geöffnet, nicht expandiert
Bild 2: das konkrete Beispiel-Plugin, expandiert --> Section Client hat selbe höhe wie in Bild 1
Bild 3: Bereits beim erstellen des Baum expandiert: Section hat volle Höhe des Trees

Ich dachte, dass ich es mit dem ColumnLayout umgehen könnte, aber das war falsch.
Gibt es
a) eine Möglichkeit, dass ähnlich wie beim Nebula PShelf, die Gesamthöhe des Views auf alle Sections verteilt wird? (Sprich: Klappe eine Section auf und sie hat der Client hat die maximal verfügbare Höhe)
oder
b) eine Möglichkeit, dass die Client-Höhe bei jedem expandieren/kollabieren eines Baum-Element immer so hoch ist, wie der gerade sichtbare Teil des Baums? von mir aus kann es ja scrollen.

Vielleicht sollte ich erwähnen, dass ich als Parent für die Sections ein ScrolledForm verwende - vielleicht hat das ja Einfluss.

Ich hoffe es ist verständlich geworden, was mein Problem ist.

Danke und Grüße,
Daniel

 

[Wildcard]

Ich habe vor einigen Monaten eine fast identische Komponente geschrieben.
Wenn ich mich richtig erinnere habe ich dazu das gute alte GridLayout verwendet und einen Expand Listener auf die Section gesetzt um das Parent Composite neu layouten zu lassen

 

[dzim]

Schön zu hören, das auch andere ähnliche Erfahrungen machen...
Das GridLayout verwende ich ja auch, also sollten die Grundvoraussetzungen ja ähnlich sein.

Ein ExpandListener auf die Sections würde mir allerdings recht wenig bringen (zumal die Höhe der Section korrekt neu berechnet wird, wenn man vorher den Tree im Section-Client verändert (ein paar Elemente auf-/zuklappt).
Ich dächte eher, dass man einen ITreeListener an den Viewer oder so hängen müsste. Klappt aber irgendwie mit dem layout forcieren noch nicht so, wie ich es gerne hätte (es passiert einfach nichts)

		viewer.addTreeListener(new ITreeViewerListener() {
			@Override
			public void treeExpanded(TreeExpansionEvent event) {
				composite.layout(true, true);
				composite.update();
				composite.pack(true);
				((Section) pluginItem)
						.layout(new Control[] { ((Section) pluginItem)
								.getClient() });
			}

			@Override
			public void treeCollapsed(TreeExpansionEvent event) {
				composite.layout(true, true);
				composite.update();
				composite.pack(true);
				((Section) pluginItem)
						.layout(new Control[] { ((Section) pluginItem)
								.getClient() });
			}
		});

Aber ich will ehrlich sein: Das forcieren von layouts gelingt mir immer nur mäßig, da ich nie so recht weiß, was ich neu layouten soll
den Parent des Views (FillLayout)
Das ScrolledForm, oder besser seinen Body? (GridLayout)
Die Section?
Das Composite, das als Client an die Section übergeben wurde? (GridLayout)
Den Tree auf dem Section-Client-Composite?

 

[Wildcard]

Du solltest dem aufeklappten Element GridData mit Fill und grab vertical verpassen, damit es den gesamten restlichen Platz einnimmt.
Beim forcierten layout sollte es reichen das top composite neu layouten zu lassen und dort die Variante mit boolean Parameter zu verwenden damit auch die Kinder neu gelayoutet werden.

 

[dzim]

Leider führte das nicht zum erhofften Ergebnis.
Beim ersten schließen eines Elements im Tree der Section passierte gar nichts. Als ich das selbe Element wieder aufklappte, würde die Section kleiner! Ein Teil des Inhalts des Trees war dann nur noch per scrollen zu erreichen.

 

[dzim]

Ach so: Ich hab die Section, auf FILL, FILL, true, true gestellt - dann wurde aber der Platz jeder Section immer "gerecht" aufgeteilt - das sa einfach doof aus.

hier mal kurz der Quellcode des Views (nicht über das super.createPartControl wundern - mein View extendet einen abstrakten View, weil ich da ein bisschen Arbeit auslagern konnte)

	@Override
	public void createPartControl(Composite parent) {

		parent.setLayout(new FillLayout(SWT.VERTICAL));

		ScrolledForm scrolledForm = formToolkit.createScrolledForm(parent);
		formToolkit.paintBordersFor(scrolledForm);
		formToolkit.decorateFormHeading(scrolledForm.getForm());
		scrolledForm.getBody().setLayout(new GridLayout(1, true));

		scrolledForm.setText(Messages
				.getString("FormsPluginNavigatorView.scrolledForm.Text")); //$NON-NLS-1$

		Image img = CoreIconProvider.getImageByIconName("fugue_plug.png", //$NON-NLS-1$
				true);
		scrolledForm.setImage(img);

		pluginNavigator = scrolledForm;

		super.createPartControl(parent);
	}

	@Override
	protected void createPluginNavigation(Object navigation,
			Task ssdToolRootTask) {

		for (Task pluginRootTask : ssdToolRootTask.getChildren()) {

			if (!pluginRootTask.isEnabled()) {
				continue;
			}

			Section section = formToolkit.createSection(
					((ScrolledForm) navigation).getBody(), Section.TWISTIE
							| Section.TITLE_BAR);
			section.setLayoutData(new GridData(SWT.FILL, SWT.TOP, true,
					false, 1, 1));
			formToolkit.paintBordersFor(section);
			section.setData(FORMS_ITEM_TASK, pluginRootTask);
			section.setText(pluginRootTask.getName());

			if (pluginRootTask.getDescription() != null
					&& !pluginRootTask.getDescription().isEmpty()) {
				Label label = formToolkit.createLabel(section,
						pluginRootTask.getDescription(), SWT.WRAP);
				section.setDescriptionControl(label);
			}

			Image image = null;

			if (pluginRootTask.getImage() != null) {

				image = pluginRootTask.getImage();

			} else if (pluginRootTask.getImageString() != null) {

				image = CoreIconProvider.getImageByIconName(
						pluginRootTask.getImageString(), true);

				if (image == null) {
					image = SSDToolPlugin.getImageDescriptor(
							pluginRootTask.getImageString()).createImage();
				}
			}

			if (image != null) {
				Label label = formToolkit.createLabel(section, "", SWT.NONE); //$NON-NLS-1$
				label.setImage(image);
				section.setTextClient(label);
			}

			createSinglePluginTree(section, pluginRootTask);

			section.addExpansionListener(new IExpansionListener() {
				@Override
				public void expansionStateChanging(ExpansionEvent e) {
				}

				@Override
				public void expansionStateChanged(ExpansionEvent e) {
				}
			});
		}
	}

	@Override
	protected void createSinglePluginTree(final Object pluginItem,
			final Task pluginRootTask) {

		final Composite composite = formToolkit.createComposite(
				((Section) pluginItem), SWT.NONE);
		composite.setLayout(new GridLayout(1, true));
		((Section) pluginItem).setClient(composite);

		final TreeViewer viewer = createTaskTree(composite, pluginRootTask);

		viewer.getTree().setLayoutData(
				new GridData(SWT.FILL, SWT.FILL, true, true, 1, 1));

		((Section) pluginItem).setData(FORMS_ITEM_VIEWER, viewer);
		viewer.setData(FORMS_ITEM_VIEWER, ((Section) pluginItem));

		viewer.addTreeListener(new ITreeViewerListener() {
			@Override
			public void treeExpanded(TreeExpansionEvent event) {
			}

			@Override
			public void treeCollapsed(TreeExpansionEvent event) {
			}
		});
	}

in der abstrakten Klasse wird die abstrakte Methode createPluginNavigation aufgerufen, die abstrakte Methode createSinglePluginTree muss ich selbst aufrufen (wie hier in der createPluginNavigation geschehen).
Ich hatte meine Updates des Layouts in der unteren Methode gemacht. Da es aber nicht ging, hab ich erst einmal wieder alle Änderungen zurückgezogen.

Sag mir mal bitte, welche Stelle du meinst, die ich anpassen sollte.

 

[Wildcard]

Ich komme hier so langsam durcheinander
Was ist jetzt genau dein Problem? Das sich die Sections beim auf- und zuklappen nicht korrekt verschieben, oder das die Sections sich nicht vergrößern wenn du den Baum weiter aufklappst?

Übrigens, die ganze Sache erinnert mich ein wenig an Riena Navigation... Vielleicht findest du dort eine schöne Lösung.
Riena/Navigation - Eclipsepedia

 

[dzim]

Ich hab's vermutet: Ich schaffe es immer wieder alle zu verwirren.

Was geht? - Wenn beim Start die Trees aufgeklappt werden, haben die Sections auch die Höhe des Trees.
Was geht nicht? - Wenn ich im Tree Elemente auf- und/oder zuklappe, wird nicht die Höhe der Section angepasst. Das bedeutet, ist der Tree am Anfang zusammengeklappt, bekommt die Section nicht die korrekte Höhe.

Wenn ich aber die Section nach einer Manipulation am Tree zu und wieder aufklappe, wird sie mit der korrekten Höhe dargestellt.

Sprich: Ich will, dass die Section sich beim verändern des Trees enstprechend der Höhe des Trees anpassen. Das ist mir bislang aber nicht gelungen.

Ich denke mal nicht, das ich Riena so einfach integrieren kann, dass der Rest der Applikation davon nicht betroffen wird, oder?
So oder so würde ich die Navigation programatisch aufbauen.

 

[Wildcard]

Ok, jetzt habe ich es verstanden. Dann wird es wirklich nur über einen expand listener funktionieren. Danach musst du dann die Component Hierarchie bis zum Container der Section hochklettern und layout aufrufen (wüsste zumindest nicht wie das sonst gehen soll...).

 

[dzim]

Prinzipiell dachte ich mir das auch, doch leider ist der Aufruf von

((ScrolledForm) pluginNavigator).getBody().layout(true, true);

Anscheinend nicht genug. Jedenfalls ist das Verhalten der Section/des Trees dann etwas komisch. Es passiert dann das, was ich bereits unter Post #5 beschrieben habe.
Ich vermute mal, dass ich wo noch vorher ein update() absetzen muss - wissen tu ich es aber nicht.

 

[Wildcard]

Ich glaube eher nicht das update hier eine Rolle spielt.
Nach dem was du in #5 beschreibst, würde ich eher vermuten, dass der Listener über das Expand informiert wird bevor es 'physikalisch' passiert, also bevor der Tree tatsächlich mehr Platz braucht.
Lass dir mal im Tree Listener das Ergebnis von computeSize des Tree Widgets ausgeben.
Sollte sich diese Vermutung bestätigen solltest du versuchen das layout über asyncExec auszuführen, damit der Tree die Zeit bekommt seine Größe zu verändern.

 

[dzim]

Ja, du scheinst mit deiner Vermutung richtig zu liegen.
Ein Beispiel:
Wenn ich in einem der Trees den größten Ast zusammenklappe, bekomme ich dank

viewer.getTree().computeSize(SWT.DEFAULT, SWT.DEFAULT)

den Wert "Point {241, 269}". Klappe ich das Element wieder auseinander, bekomme ich aber "Point {241, 85}".
Es scheint also so, als würde er mit der Größenberechnung immer einen Schritt "hinterherhinken".
Dann aber gibt es praktisch gesehen, keine Möglichkeit, an die korrekten Daten zu kommen - es sei denn, ich berechne sie von Hand - und dass will ich nun wirklich nicht machen müssen - dazu bin ich zu faul

 

[Wildcard]

Wie gesagt, wenn du das layout über asyncExec weiter nach hinten in die Queue schiebst, dann sollte der Tree seine Größe berechnet haben bis das asyncExec ausgeführt wird. Und dann sollte (in der Theorie) alles funktionieren

 

[dzim]

So ein sch**ß. Ich hab deinen vorangegangenen Post ja gelesen, aber den Teil mit asyncExec glatt wieder vergessen...
Es geht damit! (Einzig ein kurzes Flackern, bei dem manchmal unsinnigerweise für einen Bruchteil einer Sekunde ein Scrollbalken auftaucht ist daran störend - aber das kann ich erst mal verkraften )
Danke für die Tipps!

 

[Wildcard]

Hmm, schade das es flackert, hätte ich mir aber eigentlich denken können. Eventuell kann man das beheben wenn man auf dem Parent mit den Scrollbars vor dem asyncExec setRedraw(false) aufruft und dann im asyncExec und nach dem Layout setRedraw(true). Etwas besseres fällt mir zur Zeit leider nicht ein.

 

[dzim]

Na dass werd ich morgen mal versuchen. Im Grunde wird es vermutlich eh nie groß auffallen, da ich die Bäume erst einmal aufgeklappt lasse. Am besten wäre wohl, ich lege den Anwendern nahe, sie sollen den anderen Navigator mit PShelfs verwenden - bei dem tritt das Problem erst gar nicht auf.
Schade ist allerdings, das das PShelf und viele andere Nebula-Komponente nicht mehr weiterentwickelt werden - einige fand ich da zumindest recht interessant...

 

[Wildcard]

Schade ist allerdings, das das PShelf und viele andere Nebula-Komponente nicht mehr weiterentwickelt werden - einige fand ich da zumindest recht interessant...

Ob und zu kommt immer noch ein neues Widget dazu. Ich habe das Gefühl das deshalb nicht weiterentwickelt wird, weil die Dinger im Prinzip alle funktionieren (ich hatte zumindest noch keine Probleme).
Ich vermute fast, dass man einfach kein Graduation Review beantragt weil Nebula weder diversifizierte Committer hat, noch eine Community vorhanden ist (Nutzer ja, Community nein). Beides sind eigentlich Vorraussetzungen um das Review zu bestehen und den Incubator verlassen zu dürfen.

 

[dzim]

Ein kleiner abschließender Bericht sei hier mal noch drin...
Es hilft leider nichts mit den setRedraw(true/false) - aber wie gesagt: Das ist aber nun auch nicht so dramatisch, da es ja eine "Ausweichmöglichkeit" in Form der PShelf-basierten Navigation gibt.
Danke jedenfalls für deine Hilfe!