Thema: GUI-Team

[hannibal]

ich wuerde mal sagen, dass der grafik-*server* an sich nicht austauschbar sein muss, aber die treiber eben schon (siehe N00B`s post)

lg, hannibal

[Svenska]

Das wichtigste wäre zunächst mal zu überlegen, ob die GUI lediglich mit VESA funktionieren wird oder ob man in Zukunft auch richtige Grafiktreiber bereitstellen kann.

Hab ich schonmal gesagt, nur VESA ist dumm.
Wenn das OS auch auf nem 486er mit gutem Tempo laufen tun kann, so werde ich sicherlich irgendwann ein paar alte ISA-Grafiktreiber dazuliefern

Der Treiber muss verschiedene Funktionen haben, am besten ist hier, sich mal den Vesa-Standard anzuschauen und wesentliche Funktionen rauszusuchen.

Grafik/Textmodus, Auflösung, Farbtiefe ändern (On the Fly? Ram umorganisieren!)
Punkt setzen (Strich setzen, Kasten setzen, etc => Beschleunigerfunktionen?)

Und so geht's halt weiter. Sicher könnte man alles von der Punkt-Funktion
ableiten, aber Grafikkarten und -beschleuniger haben in den letzten
Jahren auch Algorithmen entwickelt, die ein Fenster, ne Linie oder so
schneller zeichnen können.

Svenska

[DarkThing]

Wie wärs mit ganzen Bitmaps malen? Also eine Funktion die ein geladenes Bitmap an eine bestimmte Position zeichnet. Wenn man ne schöne GUI machen will, macht das denke ich Sinn. Und wenns auch noch schnell werden soll, sollte man die Funktion im Treiber stehen haben.

[DDR-RAM]

In ferner Zukunft, unterstützung von DirectX, OpenGL und Windows nativen Grafiktreibern, wäre ne schöne  Sache.

Wäre das eigentlich erlaubt? Die Treiber sind ja eigentlich umsonst oder kriegt man mit MS ärger? Hat wer von euch schonmal für windows nen Treiber gebaut?

MfG
DDR-RAM

[Another Stupid Coder]

OpenGL könnte machbar sein (in ferner Zukunft) siehe Mesa, etc...

[matthieuriolo]

In ferner Zukunft, unterstützung von DirectX, OpenGL und Windows nativen Grafiktreibern, wäre ne schöne  Sache.

Ich würde die finger von DirectX lassen! Lieber auf Opengl. Dann hat man was vernünftiges das "alle" weltkennt und damit umgehen kann. Vorallem will ich kein mix haben! 1 Engine die alles kann, BASTA! Darum würd ich Opengl nehmen ^^ ... mit dem bastle ich im moment herum...

[DarkThing]

Wenn man ne Menge Standards usw. erfüllt sollte OGL auf jeden Fall machbar sein. Immerhin ist es im Gegenteil zu DX komplett OpenSource und auch andere OS unterstützen das schon.

[DDR-RAM]

In ferner Zukunft, unterstützung von DirectX, OpenGL und Windows nativen Grafiktreibern, wäre ne schöne  Sache.

Ich würde die finger von DirectX lassen! Lieber auf Opengl. Dann hat man was vernünftiges das "alle" weltkennt und damit umgehen kann. Vorallem will ich kein mix haben! 1 Engine die alles kann, BASTA! Darum würd ich Opengl nehmen ^^ ... mit dem bastle ich im moment herum...

Hm, wenn das Projekt tatsächlich wachsen sollte, dann kann ein Team ogl und eins dx (falls man das dann überhaupt so nennen darf) implementieren, schließt sich nicht aus, siehe Windoof

MfG
DDR-RAM

[DarkThing]

Aber OGL kannste einfach portieren und DX ist afaik nicht OpenSource. Also müsste man sich den Source auf mehr oder weniger illegale Weise holen oder alles nachprogrammieren, was aber meiner Meinung nach viel zu lange dauert und zu umständlich ist wenn man eh OGL hat.

[DDR-RAM]

Aber OGL kannste einfach portieren und DX ist afaik nicht OpenSource. Also müsste man sich den Source auf mehr oder weniger illegale Weise holen oder alles nachprogrammieren, was aber meiner Meinung nach viel zu lange dauert und zu umständlich ist wenn man eh OGL hat.

Wenn alle Spiele OGL-fähig wären ja klar, würde ich dir zustimmen, aber dem ist leider nicht so, und ich strebe maximale Kompatiblität an.
Deshalb darf ein Team oder ein einzelner in ferner Zukunft DirectX nachprogrammieren, wenn es/er Zeit aufbringen möchte.
Ob es je soweit kommen wird und das wenn ogl wahrscheinlich zuerst gemacht wird ist mir klar

MfG
DDR-RAM

[mastermesh]

Ich würde mir an eurer Stelle weniger Gedanken um irgendwelche Grafik-APIs machen. Wichtig ist, dass ihr ein gescheites GUI-Framework hinkriegt. Und dafür braucht ihr nicht mal zu warten, bis Kernel, graphic_server, VESA-Treiber usw. fertig sind... ihr könnt ja ne vorläufige SDL-Implementierung oder sowas machen...

[Golum]

Ich hab morgen in der Schule ohnehin Informatik da kann ich ja mal mit einem Wrapper für die SDL-Funktionen anfangen, ich würde sagen für den Anfang reichen mal die Funktionen: Punkt, Linie, Rechteck (gefüllt) und Rahmen. Bitmaps werden wir so schnell schätze ich nicht brauchen.

Die Fragen die wir uns dann noch zu beantworten haben wären schon wie es im Endeffekt aussehen soll. Windowsartig oder hat jemand Bessere Ideen ?

Und auf welche Art und weise soll der Anwendungsprogrammierer darauf zugreifen können ? Ich kenne nur die Windows-API also würde ich es ähnlich aufbaun.

Wie sehn euere Meinungen dazu aus ?

mfg
Golum

[stultus]

bezüglich aussehen mach dir mal keine Sorge, da bastelt nen guter freund bereits dran (sieht gut aus was ichb is jetz vorgelegt bekommen hab, und sollte für Windows-Umsteiger nicht allzu kompliziert sein). einzigstes problem wo er mich schon vorgewarnt hat wär das wir vermutlich antialiasing für fonts brauchen...

@Golum: check mal ICQ...

[matthieuriolo]

Was (zum teufel nochmal) wollt ihr spiele (von dennen ihr nie den source sehen werdet) auf das OS transportieren? Vielleicht sollte man sich hier die frage stellen, was unser OS werden soll? Nen zock os, ne arbeits maschine oder nur ne Vorlage für andere OS's? Bitte nicht so ne blöde antwort wie "alles" das wird nie möglich sein...


Also ich glaube das wir mit Opengl sehr gut dran wären. Und ich als mac user ( ^^ ) verabschaue ein bisschen DX weil man dies auf keiner anderen Plattformen findet wird. Und ich finde es auch sinnlos unnötig energie in das nachahmung zu stecken! Lieber ne Opengl erweiterung die ähnliche funktionen abnimt ^^ ... und diese Bibliothek opensource stellen

[Svenska]

ääääähhhhmmmm
Das OS sollte mal ein Lern-OS sein, in dem man am Source sieht, wie ein OS prinzipiell aufgebaut ist.
Ueber Mesa, OpenGL, DirectX und so nen Zeugs würde ich mir jetzt noch keine Gedanken machen, da wir ja noch nichtmal ne kleine Shell haben...das einzige, was ich kriege ist nen General Protection Error, unabhängig ob ich die Zeilen im Source auskommentiere oder nicht.

Svenska

[Golum]

Wer Mitarbeiten will ist herzlich dazu eingeladen. Meldet euch einfach im Forum,bei N00B oder mir.

Im moment arbeite ich gerade an einer "Entwicklungsumgebung" für die GUI mit SDL. Danach könnten wir eigentlich schon beginnen. Ich hoffe der Code ist dann auch halbwegs portierbar aufs CommOS.

[hannibal]

waers vielleicht nicht irgendwie besser, wenn man vielleicht zuerst die GUI lauffaehig macht, bevor man dafuer eine entwicklungsumgebung entwickelt? (was fuer ein wortspiel!)

[DarkThing]

Man braucht auf jeden Fall einen genauen Plan davon, wie die GUI funktioniert. Also wie man die Funktionen aufruft, welche es gibt, welche Parameter die brauchen, usw. Dann kann man auch eine Anwendung entwickeln, nur nicht testen.

@Mitmachen: Was für Aufgaben sind denn noch da?

[The-Programmerfish]

waers vielleicht nicht irgendwie besser, wenn man vielleicht zuerst die GUI lauffaehig macht, bevor man dafuer eine entwicklungsumgebung entwickelt? (was fuer ein wortspiel!)

Er meinte damit sehr wahrscheinlich keine Entwicklungsumgebung innerhalb der GUI sonder für die GUI. Schätze mal er meinte damit nen kleinen Satz an Grafik Funktionen die in der Testphase auf SDL basieren und so grundlegend sind dass man sie später auch fürs CommOS schreiben kann (bzw. muss ^^)

@Darkthing:

Bevor man nen Plan erstellt was für Funktionen es gibt, was für Parameter usw. es gibt sollte man sich erstmal Gedanken machen

- Was die GUI alles können soll
- Wie sie aufgebaut ist (Angesichts dessen dass der Kernel AFAIK in C++ gecoded ist sollten wir die GUI vielleicht auch objektorientiert gestalten)
- Wie sie aussieht
- Der ganze Aufbau im Hintergrund bezüglich Treiber usw.

Wenn wir da erstmal nen rohen Plan erstellt haben wies funktionieren soll kann man sich Gedanken über die einzelnen Bestandteile & Funktionen machen.

@Alle

Ich würde vorschlagen ein Treffen in nem IRC Channel zu veranstalten, ist einfacher als hier das Forum dicht zu posten ^^

[DarkThing]

Ich würd eine GUI auf jeden Fall in C++ coden. Aber bevor eine GUI auch nur plant sollte erstmal mindestens Milestone1 vom Kernel fertig sein. Man braucht halt was zum Testen. Ich glaube die meisten waren dafür die GUI wie ein normales Programm zu handeln. Also sollte auch Programmausführung drin sein.