Hive-GUI

[drohne235]

Mal ein neues Thema: GUI

Ich persönlich bin ja durchaus ein Fan der Kommandozeile, vielleicht mit mehreren Session wie unter Linux, aber reiner Text ist natürlich erstmal was die Ressourcen betrifft am sparsamsten. Aber es wird sicher nicht ausbleiben das es auch eine einfache GUI für den Hive geben wird. Klar ist dabei eines: Ein großer Teil des Codes kann in den Bellatrix-Chip ausgelagert werden. Im Prinzip kann es soweit gehen das bis zur Auswahl eines Bedienelementes (Menüpunkt, Button, Icon) alles in Bellatrix verwaltet wird, und das dieses Ereignis dann weitergeleitet wird an den eigentlichen Anwendungscode in Regnatix.

Aber mir ist gerade bei den Überlegungen zum HIVEnet eine alte Idee wieder eingefallen: Was wäre wenn man die GUI minimalistisch an HTML orientiert? In Bellatrix läuft dann quasi zur Darstellung ein minimalistischer Browser, welcher die HTML-Benutzeroberfläche darstellt. Natürlich nicht den ganzen HTML-Befehlsumfang, aber doch eine kleiner kompatible Teilmenge. Eine sich daraus ergebende Eigenschaft wäre, dass man die GUI vielleicht recht einfach über das Netzwerk leiten kann, um sie in einem normalen Browser, oder auf einem anderen Hive darzustellen.
Jedes "Desktop" liegt dann als Text vor, oder komprimiert in einem HTML-Bytecode. Vielleicht würde eine solche Betrachtungsweise ja neue interessante Eigenschaften ergeben.

Aber das ist nur mal so ein Gedanke mit dem man spielen kann.

[Julian]

Die Idee find ich gut. Dann wäre das GUI programmieren auch nicht so schwer. Aber wie gesagt hab wie immer keine Ahnung wie sich das technisch umsetzen lässt.

[Rainer]

Hallo drohne,

die Idee ist gut, hat aber (für mich) ein paar Nachteile.
Ich habe da vor ein paar Jahren schon mal damit rumgespielt (allerdings auf einem Webserver). Geht ganz gut aber das Problem sind immer dynamische Inhalte.
Z.B. ein Chatfenster müsste ja eigentlich ununterbrochen aktualisiert werden. Die ständige flackerei beim Fensteraufbau oder im IFrame stresst Mitleser ziemlich.
Ist ja ein Pull/Push alle paar Sekunden ... je nachdem. Dem entgeht man z.B. durch einen Stream oder irgendwelche ActiveX, Ajax, whatever.
Da sowas auf dem Hive wohl nicht läuft, müsste man sich was Eigenes ausdenken (was ja prinzipiell kein Problem ist), was aber dann auf normalen Browsern nicht mehr läuft (was mir aber jetzt wurst wäre).

Was ich noch zu bedenken geben will. Wir werden mit absoluter Sicherheit mit der Zeit eine GUI für den Hive haben. Mag es sowas sein wie GEOS oder GEM, aber ein Problem hast Du dann auf alle Fälle. Die "WEB-GUI" kollidiert u.U. mit der GUI auf dem Hive. Man kann (und muß) das zwar in Fenster umleiten, aber eine GUI in der GUI könnte ziemlich verwirrend sein.

Trotzdem ist der Ansatz durchaus überlegenswert, da ich glaube das eine HTML oder XML-GUI relativ einfach zu machen wäre, wenn der Hive das Ding parsen kann. Damit wäre man ultraflexibel.

[EDIT]
@Julian:
GUI Programmieren ist nicht schwer, wenn man ein paar Grundlegende Funktionen als Basis hat. Ich mag zwar Kommandozeilen auch ganz gerne, aber habe mich lange hobbymäßig mit "Mensch-Maschine"-Schnittstellen beschäftigt. Da sind wir noch lange nicht am Ende der Fahnenstange angekommen. Windows-GUI und auch die GUI's von Linux ( KDE, XWindows, wie sie alle heißen) oder MAC (OSX) sind alle noch lange nicht da angekommen wo man es nach der langen Zeit eigentlich erwarten könnte.
Statt effektiv arbeiten zu können muß man sich animierten Schwachsinn ansehen, hat 3 Millionen Applets und Müll auf dem Schirm, usw.
Schau Dir mal z.B. GEM von 1984 an .... und vergleiche es mal mit dem was Du gerade auf dem Rechner hast. Hat sich nicht wirklich was getan, außer daß Du jetzt 16 Millionen Farben und 13000 Fenster gleichzeitig offen haben kannst ... und doch nur in EINEM wirklich arbeitest. Viel Firlefanz, wenig Neues und Innovatives
[/EDIT]

[EDIT2]
Ummm .. moment mal. Eigentlich ist die Idee mit der HTML-GUI doch ziemlich cool wenn man ein bißchen darüber nachdenkt (was ich nächstes mal tun sollte bevor ich einfach drauf los scheibe )
Lassen wir den "Online-Aspekt" mal außer acht, kann man da schon super Sachen machen. Mit der richtigen Programmierung einer Hardware-nahen und einer Geräteunabhängigen Schicht könnte man einiges erreichen. Da dann der Parser drüber, fertig.
Damit wäre GUI ändern "on the fly" möglich ... wie geil ist DASS denn ?
[/EDIT2]


Gruß.
Rainer

[laserjones]

Ich könnte mir ebenfalls ein Zwei-Schichten-System vorstellen: ein einfacher Window-Manager, der sich nur um Fensterstatus, Position etc. kümmert, und ein HTML-Parser, der den Inhalt jedes Fensters aus je einer HTML-Datei generiert. Für dynamische Inhalte muss der Parser halt schnell sein und das Fenster oft refresht werden. Ich glaube nicht, dass das langsamer wäre als das Fenster herkömmlich als Grafik zu verwalten und zu refreshen - eher sogar schneller, und auf jeden Fall speichersparender, oder?

Es wäre aber zu prüfen, ob es nicht eine bessere Beschreibungssprache als HTML gibt. HTML-Tags verbrauchen für mein Gefühl ziemlich viele Bytes. Aber wir könnten den Code natürlich auch in ein "proprietäres" Format komprimieren.

[Rainer]

Ich könnte mir ebenfalls ein Zwei-Schichten-System vorstellen: ein einfacher Window-Manager, der sich nur um Fensterstatus, Position etc. kümmert, und ein HTML-Parser, der den Inhalt jedes Fensters aus je einer HTML-Datei generiert. Für dynamische Inhalte muss der Parser halt schnell sein und das Fenster oft refresht werden. Ich glaube nicht, dass das langsamer wäre als das Fenster herkömmlich als Grafik zu verwalten und zu refreshen - eher sogar schneller, und auf jeden Fall speichersparender, oder?

Es wäre aber zu prüfen, ob es nicht eine bessere Beschreibungssprache als HTML gibt. HTML-Tags verbrauchen für mein Gefühl ziemlich viele Bytes. Aber wir könnten den Code natürlich auch in ein "proprietäres" Format komprimieren.

Was drohne glaube ich vorschwebt und ich Anfangs einfach nur falsch verstanden hatte, ist die komplette GUI in HTML. Also nicht den Inhalt von Fenstern Parsen (das wäre ja ein normaler Webbrowser), sondern die Fenster SIND schon in HTML .. und alles was darunter liegt. Also das eigentliche Desktop, die Ikons, Taskleiste, usw.
Was eigentlich der Wahnsinn ist, da ich durch einfaches austauschen der HTML-Datei von Fenster-GUI auf z.B. eine einfache Palm-OS-GUI, WindowsCE-GUI,usw. wechseln könnte.

Die Referenz von Drohne auf das Hivenet hat mich da wohl in die Irre geführt.

Gruß.
Rainer

[laserjones]

Also nicht den Inhalt von Fenstern Parsen (das wäre ja ein normaler Webbrowser), sondern die Fenster SIND schon in HTML ..

Aber ich wüsste nicht, wie man bewegliche und womöglich sogar größenveränderliche Fenster auf einem Desktop in (einfachem) HTML realisieren sollte ... Das würde ja mehrere Layer erfordern, und so was geht nur mit DHTML, also unter exzessivem Einsatz von Javascript o. Ä., und das würde der Einfachheit der Grundidee widersprechen. HTML an sich ist eine statische Seitenbeschreibung.

Ich sehe daher nur zwei Möglichkeiten: Entweder ein GUI ohne herkömmliche Fenster (muss vom Gesichtspunkt der Usability nicht unbedingt ein Nachteil sein) oder eben ein separater Window-Manager, der unter den HTML-Inhalten liegt.

[Rainer]

Ah, ok. Jetzt habe ich Dich verstanden.

Daß das mit HTML nicht so ohne weiteres geht ist klar. Natürlich muß da eine "Schicht" darunter sein.
Was ich meinte war die reine Optik der GUI. Wenn ich z.B. ein Fenster zeichnen will, macht das Hardware-nah natürlich eine PASm oder SPIN-Funktion, aber die Optik wird durch HTML generiert. Natürlich kann man so was auch ohne HTML (oder XML, whatever) machen, aber man hätte dann nahezu unbegrenzte Möglichkeiten des Designs, da man sich mit den darunterliegenden System nicht befassen muß (Einer muß es natürlich erst mal geschrieben haben).

Wenn ich als also sagen wir mal eine Windows ähnliche GUI geschrieben hätte, Du Windows aber grundsätzlich hasst, kannst Du im Normalfall entweder das Ding nicht benutzen, oder Du musst damit leben. Wenn ich die jetzt aber über HTML "draufgesetzt" hätte, könntest Du mit ein paar einfachen HTML-Tags die komplette GUI umkrempeln.

Gruß.
Rainer

[digger]

Also drohnes Idee ist Top, hab gerade mal so ein wenig drüber nachgedacht ... das wäre was echt innovatives und in der Art auch einmaliges ... obwohl, da gabs ja mal das Display-Postscript das durchaus einige Parallelen hat.

Also das Forum hier nenn ich mal eine geile Ideenschmiede.

[Cromax]

vielleicht sollte man sich ein wenig von der bezeichnung html loesen. html ist auch nichts anderes als eine spezielles definiertes xml. wir koennten uns also ein eigenes hive xml ausdenken, fuer die gui entwicklung .. so in der art:

<rect left="20" top="0" width="100" height="50">
<title>fenstername</title>
<content>inhalt</content>
</rect>

zeichnet ein rechteck welches 20 pixel von links gezeichnet wird und 0 pixel von oben. es ist 100pixel breit und 50 hoch. der titel lautet fenstername und inhalt .. ja entsprechend ..
sieht halt html sehr aehnlich, aber bei einer eigenen definition, kann man auch benoetigte eigenschaften, die html vielleich nicht bietet mit einbauen. zum beispiel:

<content reload="5">
inhalt
</content>

hier wuerde der parser entsprechend ein element erstellen, welches sich alle fuenf sekunden aktualisiert. muss ja alles nur im parser dann beruecksichtigt werden.
man koennte die tags und attribute auch wesentlicher kuerzer machen, damit man weniger speicher auf dem hive belegt .. so in der art:

<re l=20 t=0 w=100 h=50>
<t>fenstername</t>
<c>inhalt</c>
</re>

dabei duerfen die tags t und c nur innerhalb von re auftauchen. in einer anderen umgebung haben sie dann meinetwegen wieder eine andere bedeutung.
mit xml definitionen und entsprechenden parsern kenne ich mich aus. habe schon einige entworfen und entwickelt. fuer eine gui definition bisher zwar noch nicht .. wuerd mich aber wirklich reizen =)
wir muessten nur ueberlegen, was die gui alles anzeigen koennen soll, dann entwickel ich eine definition dafuer und kann auch ein konzept fuer den parser entwickeln.

damit haetten wir dann genau das, was wir wollen und brauchen und haetten eine flexibilitaet wie in html

edit:
man koennte es hgml nennen:
Hive Graphical Markup Language

=)

[Rainer]

@Cromax:
Ganz GENAU so meinte ich das.
Wenn jetzt nämlich jemand ein Programm geschrieben und genau diese Technik verwendet hat, kann ich ohne am eigentlichen Programm was zu ändern einfach die Definitionen der "HGML"-Datei ändern, und schon hat (in Deinem Beispiel) das Fenster mit "color=5" eine andere Randfarbe, oder mit einem versetzten 2. rect-Tag plötzlich einen Schatten. Wenn das jetzt alles in einem Tag "<window>" gekapselt ist, haben alle Fenster genau dieses Aussehen, die Wiederholrate, die ICH haben will, usw.

Du kannst das wirklich bedeutend besser erklären als ich

Die Ideen, die die Leute hier im Forum haben (in diesem Fall drohne235), überraschen und begeistern mich immer wieder

Gruß.
Rainer