UI-graphisch programmieren

[Hmooslechner]

Ich wünsche mir die Möglichkeit, die Vorschau der UI graphisch editieren zu können.

Die Lage der Einträge - sobald markiert - sollten mit der Maus verschoben, größengeändert - vielleicht sogar gedreht werden können. Diese graphische Änderung sollte ins Script "zurückschlagen".


Die derzeitige Arbeitsweise - Pixelweise im Text die Einträge zu verschieben - visuell zu kontrollieren - wieder zu verschieben - zu kontrollieren - ist ein "Pickel im A...."!

Die Möglichkeit - mittels Parametern ein Pseudo-Raster einzuführen - ist bestenfalls ein "Workaround" für dieses grundlegende Versäumnis von Graphisoft.

Wenn das Herstellen eines schönen UI so zeitraubend bleibt wie bisher - wird es wohl wenig UI's geben... 😉

[Hmooslechner]

Bei längerem Nachdenken kommt man auf andere Gedanken:

Parameter in der normalen Parameterliste:

hier bestimmt man bisher etwa den Namen, die Bezeichnung für den Anwender, die Art des Parameters, ob er im normalen UI (Liste) sichtbar ist, ob er sich unterordnet usw..

Hier könnte man eine weitere Spalte anlegen, wo bestimmt ist, dass dieser Parameter in der grafischen UI (oder anderswo - zB. in der Infoleiste oder im Kontextmenü der rechten Maustaste oder in der Pet-Pal.) auftauchen soll.

Wenn hier Parameter für die grafische UI eingeschalten wurden, sollten diese in einem automatischen Raster von selber in der grafischen UI eingetragen sein. Vorgefertigte Templates wären hier sehr hilfreich - besonders für den späteren Anwender - weil sich die UIs dann automatisch standardisieren würden.

Dort sollte grafisch jeder Eintrag verändert werden können.

Dass Ergebnis sollte in ein automatisches Script einfließen - das man dann im script manuell weiter anpassen könnte - die Möglichkeit des Scriptes sollte also bestehen bleiben - wie bisher.


Ich weiß schon: Alles = Chancenlos - aber es gibt immer wieder Wunder 😉

[Frank Beister]

Ich weiß schon: Alles = Chancenlos - aber es gibt immer wieder Wunder 😉

Wer weiß, aber ein graphischer Editor ist entweder sehr umständlich oder bleibt dann wieder weit hinter den Möglichkeiten von GDL zurück. Bedingte Darstellung, Reaktion auf ArchiCAD-Version und Platform...

[Hmooslechner]

Hallo Frank!

Wenn Du Dir einen grafischen Editor fürs UI als umständlich vorstellst, läuft mit meiner Beschreibung von dessen Funktion was falsch..

Stelle Dir meinen Vorschlag vielleicht so vor:

Um es überspitzt zu formulieren - Nach Deiner Meinung könnte man dann beim normalen CAD-Zeichnen auch auf die Maus verzichten, weil man ja mit numerischer Angabe des Einsetzpunktes eines Elementes und dessen numerischer Größe und Ausrichtung ja auch alles zeichnen kann - und natürlich noch viel genauer..

Trotzdem denke ich aber, dass die Manipulation von Wänden - Decken - Fenstern usw - mit der Maus rein visuell schon seine Berechtigung hätte - grins..

Ich will ja nicht auf das Scripten verzichten. Soll "bitteschön" bleiben!

Aber das verschieben, verändern usw - von Elementen in der Vorschau mit der Maus oder zumindest den Pfeiltasten würde ich mir von einem sonst auch grafisch arbeitenden CAD-Programm schon erwarten.

[Frank Beister]

Nach Deiner Meinung könnte man dann beim normalen CAD-Zeichnen auch auf die Maus verzichten

🙄 🙄 🙄 Hä?

Nein, ich kann mir einen graphischen Editor für UIs sehr wohl sehr einfach vorstellen. Ich habe sowas auch in anderen Sprachen schon gesehen. Aber dann kommt dabei relativ einfacher, dummer Code heraus. Oder er ist eben kompliziert und nicht mehr einfach.

Wieder mal eine akademische Frage. Ich glaube nicht, dass GS uns da was spendiert. Wobei.... GS hat seit AC 18 Das Aus der Parameterliste eingeläutet. Vielleicht gibts ja eine neue Kampagne 😉

[Hmooslechner]

🙄 🙄 🙄 Hä?

Ich sehe - Du hast verstanden - grins..

Der Kern meines Wunsches ist - sichtbare Einträge dann in der Vorschau verschieben zu können. Das ändert am Code gar nichts - ausgenommen die Koordinateneinträge. Da wird gar nichts anders im Code - als Du Ihn zuvor selber geschrieben hast.

Bei kompletter reiner grafischer Neu-Herstellung allerdings könntest Du natürlich recht haben - was sich durch Verwendung von Templates verhindern ließe. Ein zwingend unübersichtlicher Maschinencode muss ja nicht sein - kann man alles "richtig" machen 😁

Und meine vielen "akademischen Diskussionen" hier - sind mir auch klar - heisst aber im Umkehrschluss, dass auch Du denkst - dass uns Graphisoft eigentlich "im eigenen Saft kochen lässt".

Damit wäre die Wunschliste also sinnlos. Will ich mir nicht vorstellen.. 😢

Realistischerweise muß ich allerdings anmerken - hier in der deutschen Version des Forums habe ich wirklich den Eindruck - von Graphisoft real (Budapest) - also nicht Graphisoft Deutschland - liest wirklich keiner mit. Und auf Graphisoft Deutschland scheint man in Budapest auch nicht wirklich zu "hören".

Von meiner "handvoll" Wünsche, die ich im internationalen Forum gepostet habe, gab es bisher von Graphisoft Budapest ein einziges mal eine direkte Rückmeldung zu einem Wunsch - die Vereinfachung der graphischen hotspots wollten die Ungarn wirklich "realisieren". (nur mehr eine einzige Zeile zur Definition nötig und nicht wie bisher 6 Anweisungen)

Ich habe dann versucht - ein wenig nachzuhaken - bekam aber dann nur mehr einen Hinweis auf "company poitics".. 😁 Aber dort wird offensichtlich mitgelesen und auch drüber nachgedacht!

[Frank Beister]

Die Wunschliste ist nicht überflüssig! Wünsche auch nicht. Akademische auch nicht. Und nicht alle sind akademisch. Und auf diesen Wunsch bezogen weiß ich (weil mir das GS so mehr oder weniger direkt mitgeteilt hat), dass GDl nur ein sehr geringer Teil nutzt. Daher wird die Entwicklungsumgebung auch nur gepflegt und nicht weiterentwickelt. Ich habe das hier schon mal geschrieben.

Und nochmal zu Deinem Wunsch:

Bei mir sieht eine Skriptcode eines Interfaces z.B. so aus:

	uiY=uiY+uiZH
	txt="Breite / Höhe"
	IF querschnitt=3 THEN
		IF maszbezug=1 THEN txt="Durchmesser" ELSE txt="Nominaler Durchmesser"
		ELSE
		IF querschnitt=1 THEN
			UI_INFIELD "B", LM+uiL+4*uiS, uiY, uiS*2-uiF, uiFH   UI_TOOLTIP "Höhe"
			ELSE
			IF maszbezug>1 THEN txt="Öffnungsbreite / Höhe"
			ENDIF
		ENDIF
	UI_OUTFIELD txt+":",LM+uiL+0*uiS,uiY+uidY,uiL,uiTH, 0+4*(maszbezug>1)
	IF maszbezug=1 THEN
		UI_INFIELD "A", LM+uiL+2*uiS, uiY, uiS*2-uiF, uiFH   UI_TOOLTIP "Breite"
		ELSE
		IF maszbezug=3 OR (querschnitt=3 AND maszbezug=2) THEN
			UI_INFIELD "aFIX", LM+uiL+2*uiS, uiY, uiS*2-uiF, uiFH   UI_TOOLTIP "Lichter Durchmesser"
			ELSE
			WDdim_form="%."+str("%1.0",nachK)+einheit
			UI_OUTFIELD str(WDdim_form,A)+einheit,LM+uiL+2*uiS,uiY+uidY,uiS*2-uiF,uiTH, 2+4*(maszbezug>1)
				IF querschnitt=2 THEN
					UI_OUTFIELD "/",LM+uiL+4*uiS-uiF,uiY+uidY,uiF,uiTH, 2+4*(maszbezug>1)
					UI_OUTFIELD str(WDdim_form,B)+einheit,LM+uiL+4*uiS,uiY+uidY,uiS*2-uiF,uiTH, 2+4*(maszbezug>1)
					ENDIF
			ENDIF
		ENDIF

Diese bedingte Formatierung graphisch nachzubilden ist entweder sehr kompliziert oder geht schlicht nicht. Mal ganz abgesehen davon, dass das dann auch nur bei neuen Objekten geht.

Ich programmiere meine UIs so, dass ich jederzeit eine Zeile Eingabefelder einfügen kann oder die Feldgröße skalierbar bleibt. Ich brauche da den graphischen Editor eigentlich nicht.

[Hmooslechner]

Dieses Codebeispiel - genau das habe ich gemeint mit "Workaround" für Graphisofts Versäumnis. Toll gemacht! Auch ich finde mir Wege. Aber diese Einstellung gilt nicht für jeden Nutzer.

Und könnte es nicht auch sein, dass unser schönes GDI deshalb so wenig Nutzer findet, weil es so umständlich ist und nur seit X Versionen "gepflegt" und nur in Ameisenschrittweiten weiterentwickelt wird?


Abgesehen davon - auch wenn es wenig Scripter sind - stellen genau wir "Programmierer 😁 " und unsere Erzeugnisse einen nicht zu unterschätzenden Vorteil für alle anderen User dar. (Ich erhalte fast täglich irgendwelche Dankesschreiben für Vids und auch GDLs.)

Sieht Graphisoft das denn nicht?

Ich meine den Vorteil für Graphisoft - wenn es uns "Entwickler" besser unterstützt?

Schön, dass Du für Dich Wege gefunden hast, diese "Unterlassungssünden" zu umschiffen.

Aber Anfänger mit nicht einem so großen Durchhaltevermögen beim Erlernen der komplexen Sprache lassen es dann eben bleiben - obwohl sie auch gute Ideen haben können - was ich schade finde. Natürlich - dann gibt es einen "Konkurrenten" weniger - aber so denke ich eigentlich nicht.

[Frank Beister]

Das ist kein Workaround für ein Versäumnis. Das ist Programmierung. Der Dataglove aus Minority Report erzeugt keinen Quellcode. Auch wenn nur 10% von dem Code nichts mit dem UI zu tun haben, sondern anderswo ihre Bedeutung und Ursprung haben sind das 10% zu viel, um es rein graphisch zu lösen.
Du hast aber insofern recht: Für ein einfach strukturiertes Interface wäre ein graphischer Editor hilfreich. Der muss dann aber unbedingt auflösbaren, dann unabhängig bearbeitbaren GDL-Code erzeugen.