Hive-GUI

[laserjones]

das wäre was echt innovatives und in der Art auch einmaliges ...

Eine Verquickung zwischen Desktop und HTML gab's ja (optional) schon in Windows 98. Dort aber eher ungeliebt, weil die Schichten nicht sauber zu trennen waren. Wenn wir so etwas konsequenter implementieren, wäre das wirklich was Tolles. An XML hatte ich auch schon gedacht, damit sind wir wesentlich flexibler und auch noch sauberer in der Implementierung. HTML ist ja eigentlich veraltet und (rückblickend) als unsaubere Vorstufe von XML zu betrachten. Den einstellbaren Refresh finde ich z. B. genial!

[Janaha]

Halloe.

Wenn ihr HTML/XML für die GUI nehmen wollt, schaut euch mal den Word of Warcraft Client an. Der Client baut seine komplette GUI aus ein paar HTML/XML Scripts auf. Auch dynamische Änderungen an den aufgebauten Fenstern sind da im LUA- Script später kein Problem mehr. Auch können mehrere Fenster von unterschiedlichen Addons gleichzeitg laufen.

Das ganze sieht dann in etwa so aus: ( Auszug aus einem der diversen Addons zu WoW )

Code: Alles auswählen

<Ui xmlns="http://www.blizzard.com/wow/ui/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.blizzard.com/wow/ui/..\FrameXML\UI.xsd">
	<Button name="AtlasEntryTemplate" hidden="true" virtual="true">
		<Size>
			<AbsDimension x="330" y="15" />
		</Size>
		<Layers>
			<Layer level="OVERLAY">
				<FontString name="$parent_Text" inherits="GameFontHighlight" wraponspaces="false" justifyH="LEFT">
					<Size>
						<AbsDimension x="330" y="15" />
					</Size>
				</FontString>
			</Layer>
		</Layers>
		<Scripts>
			<OnUpdate>
				AtlasEntryTemplate_OnUpdate(self);
			</OnUpdate>
			<OnLeave>
				GameTooltip:Hide();
			</OnLeave>
		</Scripts>
	</Button>
	<Frame name="AtlasFrame" toplevel="true" enableMouse="true" movable="true" parent="UIParent" hidden="true" frameStrata="MEDIUM">
		<Size>
			<AbsDimension x="921" y="601"/>
		</Size>
		<Anchors>
 			<Anchor point="TOPLEFT">
 				<Offset>
 					<AbsDimension x="0" y="-104"/>
 				</Offset>
 			</Anchor>
 		</Anchors>
		<Frames>
			<Button name="AtlasFrameCloseButton" inherits="UIPanelCloseButton">
				<Anchors>
					<Anchor point="TOPRIGHT" relativeTo="AtlasFrame" relativePoint="TOPRIGHT">
						<Offset>
							<AbsDimension x="5" y="-7"/>
						</Offset>
					</Anchor>
				</Anchors>
			</Button>

Schön zu sehen ist hier, wie die einzelnen Elemente der GUI definiert werden und wie die Handler für die Events angebunden werden. Zu jeder dieser XML- Dateien gibt es dann ein LUA- Script das die Events wie z.B. Buttonclicks erhält und abarbeitet. Die Scripts können dann über eigene Schnittstellen die im Ram gehaltenen Grafischen Objekte jederzeit verändern, ohne das sie dazu neue XML- Dateien erzeugen müssten. Das XML wird nur genommen um die Objekte sozusagen zu initialisieren.

Grüße
Janaha

[laserjones]

Was natürlich auch noch zu bedenken wäre, ist die Farbzahl und Auflösung, die ja schon in einem anderen Thread diskutiert werden. Wenn das GUI komplett im Chip-RAM von Bellatrix laufen soll, wären wir hier ziemlich eingeschränkt. Wenn man die Auflösung variabel gestalten möchte, müsste man das auch bei der Farbzahl machen (um überhaupt mit dem RAM hinzukommen), und dann müssten wiederum alle GUI-Elemente in mehreren Farbtiefen hinterlegt werden, was die Sache aufwendig macht. Wahrscheinlich wäre es dann besser, ein bestimmtes GUI-Design (das der User dann immer noch durch ein anderes ersetzen könnte) fest an eine Auflösung und Farbtiefe zu koppeln. Also pro "Theme" ein festes Set aus Auflösung, Farbtiefe, GUI-Grafiken und XML-Definitionen.

Und es wäre zu überlegen, ob man die Grafikausgabe zwecks Performance und Speicherplatz Tile-basiert realisiert, wodurch zwar die Fensterpositionen gerastert wären, aber das fände ich persönlich nicht so schlimm. Ein Mauszeiger als stufenlos bewegliches Sprite wäre natürlich trotdzem sehr wünschenswert, wenn auch nicht zwingend (vgl. simple Mausoberfächen für MS-DOS, wo einfach immer ein Zeichen = Tile umgefärbt wird).

[drohne235]

Und es wäre zu überlegen, ob man die Grafikausgabe zwecks Performance und Speicherplatz Tile-basiert realisiert, wodurch zwar die Fensterpositionen gerastert wären, aber das fände ich persönlich nicht so schlimm. Ein Mauszeiger als stufenlos bewegliches Sprite wäre natürlich trotdzem sehr wünschenswert, wenn auch nicht zwingend (vgl. simple Mausoberfächen für MS-DOS, wo einfach immer ein Zeichen = Tile umgefärbt wird).

Mauszeiger ist kein Problem, der wird schon in diversen Parallax-Demos quasi als Sprite durch eine Cog dynamisch im Videostrom übergeblendet.

Die GUI auf Tiles basieren zu lassen wollte ich gerade vorschlagen. Tiles sind ja eine Form der Kompression gegenüber einem ausgewachsenen Rasterpuffer. Außerdem müssen zur Modifikation kaum Daten bewegt werden, in den meisten Fällen ja nur Zeiger, was die Basis für eine vernünftige Geschwindigkeit ist. Ebenso könnte man die Seitenbeschreibung als Bytecode realisieren, was gegenüber reinem Text auch wieder einiges an Speicher freimacht.

Zu überlegen wäre auch folgendes: Was braucht man wirklich für Elemente in der GUI? Ich persönlich denke das es nicht unbedingt mehrere frei verschiebbare Fenster sein müssen und finde eine Oberfläche wie bei PalmOS ganz funktional. Jede Anwendung bekommt einen eigenen Screen mit einer kleinen Menüzeile am oberen Rand und hat den Bildschirm für sich. Buttons, Radiobuttons, Eingabefelder, Scrollleiste, Schieberegler und Ramen für Dialoge - viel mehr braucht es dann vielleicht nicht mehr. Vielleicht noch zwei oder mehr Screens zwischen denen man komplett umschalten kann. An vielen Stellen ist dieses PalmOS wie ein kleines GEM auf den ST-Computern. Es sollte halt alles nicht zu kompliziert sein, aber dennoch ansprechend und funktional, so das man bei resultierenden Anwendungen gut damit klar kommt, ohne gleich 80% der Zeit um ein kleines Programm zu schreiben, mit der GUI zu verschwenden.

[Cromax]

ohne fenster finde ich auch nicht schlecht .. man koennte so eine art tabbed browsing basteln .. am anfang nur eine seite mit den icons, wie beim palm oder aehnlichen geraeten .. oeffnet man ein program, dann oeffnet es sich quasi in einem neuen tab .. der erste tab ist dann immer der desktop

[Rainer]

Ich bin der meinung man bräuchte einfach nur ein "Framework", daß die Grundfunktionen abdeckt.
Das wird dann die Minimal-Hive-GUI.
Den Rest überlässt man den Leuten selber ... dann kann sich jeder das basteln (und evtl. veröffentlichen hier für alle) was er will .. ob das jetzt eine "TABBED-GUI", Fenster-Gui oder eine GUI in Form eines Flipperautomaten ist, kann ja jeder selbst entscheiden .... wir müssten halt nur dafür sorgen, daß das auch möglich ist.

Gruß.
Rainer

[laserjones]

ob das jetzt eine "TABBED-GUI", Fenster-Gui oder eine GUI in Form eines Flipperautomaten ist, kann ja jeder selbst entscheiden .... wir müssten halt nur dafür sorgen, daß das auch möglich ist.

Wobei "mit oder ohne Fenster" möglicherweise eine gewichtige Entscheidung ist, weil für bewegliche Fenster das Framework deutlich flexibler sein müsste. Ich kann es mir auch gut ohne vorstellen.

[Cromax]

ist eigentlich gar nicht so ein grosser unterschied, wenn man mal drueber nachdenkt .. fuer bewegliche fenster muss halt nur ein handler her, der die position des fensters aendert und dann den bildaufbau neulaedt, um es mal ganz vereinfacht auszudruecken .. ob ich jetzt auf einen tab klicke und sich das fenster in kompletter groesse neu aufbaut oder ob ich einfach ein fenster an einer anderen stelle anzeigen lassen, ist ja kein grosser unterschied .. muessten halt nur entsprechend ein paar events und handler her

[Janaha]

Hm,

wenn ihr wirklich eine grafische Benutzeroberfläche machen wollt hier ein paar Beispiele:

640 * 400 Pixel (2 Farben z.B. Schwarz/Weiss) braucht pro Bildpuffer 31,25 KB
320 * 200 Pixel ( 2 Farben ) braucht pro Bildpuffer 7,81 KB
320 * 200 Pixel ( 4 Farben ) braucht pro Bildpuffer 15,625 KB
320 * 200 Pixel ( 8 Farben ) braucht pro Bildpuffer 23,44 KB

1024 * 768 (128 * 96 Zeichen Textmode ) braucht 12 KB

Also ich dachte auch schon drüber nach evtl. lieber einen Text / Tilebasierten Modus zu machen. Man könnte auch anfangen rumzutricksen. Der Chip baut das Videosignal ja voll in Software auf. Es wäre also auch denkbar die Fensterränder nicht als Bildpunkte zu speichern, sondern als Liniendefinitionen und den Textinhalt der Fenster über einen Zeichensatz / Tiles zu definieren. Auch würde uns nichts dran hindern, die Auflösungen zu mischen. Also sowas wie lores- Grafik gemischt mit Hires- Text. Hier brauchst noch bissel anstrengungen, aber ich denke da kriegen wir sicher was tolles hin.

Grüße
Janaha

[Rainer]

Also ich sehe das alles noch relativ entspannt, was den Bildspeicher angeht.

Alles PAL/NTSC:
In der Horizontalen Austastlücke von 12µs (10,9 µs NTSC) kann der Mauszeiger verarbeitet und dargestellt oder anderer Kram gemacht werden.
In der Vertikalen Austastslücke von 3,2ms ( 2,08ms) kann man durchaus 32kB aus dem eRAM in Bellatrix laden. Das dauert ~1,6ms (~0,8ms im Burstmodus (rechnerisch)).
Vll. kann man sogar in der Zeit über Regnatix nach Bellatrix laden, dann muß man Bellatrix keinen direkten eRAM-Zugriff geben.

Bei VGA ist alles ein bischen enger, aber sollte trotzdem machbar sein.
Im eRAM ist genug Platz für Bildschirmpuffer. Andere COGS arbeiten halt immer in den "unsichtbaren" Bildschirmpuffern (was den Bus natürlich weiter auslastet).

Ich teile da Janaha's Zuversicht. Das werden wir hinkriegen.

Ich hoffe, ich habe da keine groben Denkfehler.

Gruß.
Rainer