Lowlevel
Lowlevel => tyndur => Thema gestartet von: Roshl am 07. May 2005, 15:11
-
Auch wenn es noch ein wenig früh ist, aber wir sollten schonmal an ein GUI-Team denken. Vorerst sollten die Mitglieder dabei noch nicht viel programmieren, sondern sich mehr Gedanken um die Implementierung machen. Es gelten dabei die selben Grundregeln wie bei dem Kernel-Team auch, also wir brauchen zu allererst mal ein Core-Team und dann die restlichen Leute die so mitarbeiten. Das Core-Team wird grösstenteil die Designfragen übernehmen und nur zweitranging am Coding selbst beteiligt sein. Also wir suchen Opfer äääh Freiwillige.
-
Ich würde mich als Opfe... ähhh Freiwilliger melden 8)
Ich bekomm demnächst DSL und hab dann auch genug Zeit um Online zu sein ^^
-
Anzumerken wäre vielleicht noch, dass die Leute im GUI-Team durchaus auch grafisch begabt sein sollten... d.h. mit Photoshop/was_auch_immer Mockups von der GUI erstellen können.
-
What the Hell sind Mockups?
-
Ich bin noch ziemlich nen noob in sache OS dev (auch sonst... aber müssen ja nicht alle wissen ;) ). Aber ich traue mir zu das ich nen Fenster in photoshop hinkriege (natürlich auch mehr) und ich glaube ich wäre vielleicht bei den Designer gut aufgehoben. So kann ich gerade noch paar sachen vom proggen aufschnappen ;)
-
Mockups sind Entwürfe. D.h. du machst mit Photoshop einen Entwurf der späteren GUI, die dann irgendwann einmal implementiert wird.
-
wenn ich erstmal ne laufende testumgebung hab (also das sdk fertig ist und funktioniert sowie ich meinen bochs gescheit konfiguriert hab) könnt ich evtl. als progger helfen (vorallem wenn dann schon ne rudimentäre lib für grafik drin is, also mit funktionen für Punkte, Linien, Boxen, Kreise)
-
Das SDK wird komplett mit gcc, g++, binutils, make, nasm, rawrite, bochs und diversen Buildscripts kommen. Alles vorkonfiguriert, du musst nur noch coden :)
-
Dann isset gut dann würd sogar ich mitmachen.
Photoshop hab ich nicht aber mit Corel Photopaint oder Gimp kann ich einigermassen gut umgehen.
-
Ein WENIG Gimpen kann ich auch ;)
Aber ich würde mich mal melden, falls es nötig wird die "buildscripte" (sofern das nur batch-dateien sind) in Makefiles/Shellskripte umzuschreiben für diverse Unix-Systeme :)
-
Photoshop hab ich leider nicht, aber so was ähnliches (Fotocanvas)
aber wir komen hier vll vom Thema ab.
Es sooll ja ums Design gehen.
Soll es z. B. eine Sidear geben?
wie soll das Desktop aussehen?
Diese fragen müssen noch alle beantwortet werden.
-
Dafür wäre eventuell ein Contest nützlich ;)
-
Dann mach ma doch einen
-
Leute um das Aussehen soll sich doch das GUI-Team kümmern, also müssen sich die Leute die dann ins Team gesteckt werden sich diese Fragen selbst beantworten. Dann sortiert ihr entsprechend und macht daraus was Grafisches was dann den Codern zwecks Machbarkeit übergeben wird. Die entscheiden dann obs es machbar ist oder nicht, wenn nicht darf das Core-Team nochmal ran.
-
Genau. Hier müsst IHR euch organisieren. Ich habe keine Ahnung von Grafik und sonstiger Ãsthetik, deshalb werde ich im GUI-Team nichts machen.
-
Hmmm Grafisches Design ist nicht so meines. Würde mich gerne im Bereich zwischen dem Designen und dem Coden betätigen.
Als zB. Lösungen suchen wie etwas Code dann verwirklicht wird. Ich hoffe ich habe mich nicht zu undeutlich ausgedrückt.
-
Sehr richtig. Genau genommen hat das GUI-Team zwei Aufgaben: Code-Design (wie funktioniert die GUI genau? Wie ist die Beziehung der Fenster untereinander etc.) und Grafisches Design (dazu gehören auch funktionale Aspekte wie z.b. eine Taskbar/Dock/sonstwas).
Hier ist z.b. ein recht gutes Dokument, das ihr euch durchlesen solltet: http://www.osdever.net/tutorials/GUI_tut.php?the_id=62
-
Juhuu ich mach mit freut euch schon auf meine kreativen Ergüsse ^^
-
Design bin ich dabei, grafik nicht. bin dann kernel und gui im design. dann is da ne art brücke, denn irgendwelche interfaces vom kernel müssen für die gui ja da sein ;)
-
Na gut, nun möcht ich mal wissen wer aller im GUI-Team dabei ist, denn ihr könnt ja schon anfangen, ein Konzept zu erarbeiten :!:
-
Wenn niemand was dagegen einzuwenden hat bin ich dabei (Vorwiegend im Design)
-
Würde mich gern beim Coden bzw Codedesign beteiligen.
-
Gut, wie gesagt... es muss sich hier jemand finden, der das ganze organisiert... ich mach das nicht.
-
Ich auch nicht, bin ja im Kernel-Core-Team
Ich schlage euch folgendes vor: Ihr ernennt gemeinsam jemanden, der als naja sagen wir Teamleader fungiert, er bestimmt dann wer ins Core-Team kommt und wer in die restlichen Bereiche (wie auch immer die jez nochmal heissen). Dann kann das Core-Team ja schonmal mit diversen Beratungen zwecks Design anfangen aber das liegt alles dann bei euch.
Ist nur eine Anregung von mir.
-
Ich würds machen aber dafür hab ich sowieso zuwenig Ahnung ^^
-
Ich würd die Leitung ja auch übernehmen, gäbs nur nen kleines Problem, bis wir ordentlich anfangen können vergehn ja wahrscheinlich noch ein paar wochen, und ab Juli (genauer, die ganzen Sommerferien von NRW) bin ich weg...
-
Okay bis jetzt haben:
matthieuriolo
N00B
The-Programmerfish
Another Stupid Coder
joachim_neu
Golum
Gesagt das sie auf irgendeine art und weise bei der GUI mithelfen würden, wer von euch will jetzt sicher mitmachen. Wenn sich kein anderer findet übernehm ich die Organisation des GUI-Teams.
Auf jeden fall müssen wir uns als erstes auf ein Kommunikationsmittel einigen. Ich würde sagen ICQ oder E-mail für Nachrichten und wenn es was zu beschprechen gibt nutzen wir IRC. Wie ist eure Meinung dazu ?
mfg
Golum
-
Oder IRC, mann müsste einfach mal ne Zeit abmachen und nen Datum. Wer hat wann frei?
Ich bin so ziemlich jeden Tag von den 4-5 uhr frei. Wochenende sind bei mir problematischer da ich endweder im ausgang bin ( und am anderen tag noch ein bisschen mühe habe mit überlegen) oder bis um 4 am comp bin und dann laaaaange ausschlafe.
-
Ãhm...ich hab gesagt, dass ich mitmachen würde? Interessant...:D
Nya, ich würd schon, nur hab ich kaum Zeit dafür...
-
Ich wäre für nen IRC Channel zur Kommunikation ansonsten Email und ICQ
Da richt ich mich ganz nach euch
-
@Another Stupid Coder
Aber ich würde mich mal melden, falls es nötig wird die "buildscripte" (sofern das nur batch-dateien sind) in Makefiles/Shellskripte umzuschreiben für diverse Unix-Systeme Smilie
Ich habe unter der Woche meistens von 6-8 Uhr zeit. Am Wochenende entweder den ganzen Tag oder garnicht. Notfalls werd ichs wahrscheinlich auch einrichten können das ich mir zu anderen Zeiten Zeit für die GUI nehme aber an den oben genannten Zeiten habe ich zu 95% Zeit.
-
sinnvoll wäre wenn man es abspeichert damit auch solche mitkommen die nicht dabei waren.
-
In dieversen anderen Threads redete man bereits über die Einrichtung eines CVS oder SVN Repostrys. Ich denke dass das fürs GUI Team auch gilt.
-
Fuer jeden Teil ein eigenes Repesitory (oder wie man das schreibt) fände
ich uebertrieben; man könnte doch jeden Teil in ein eigenes Verzeichnis
packen und somit das Projekt als ein einzelnes Projekt pflegen und
warten. Ansonstne kommt sowas wie bei Linux raus, dass jeder sein
Sueppchen kocht und darum wäre es schade.
Ein IRC-Chat wäre in Ordnung, Chatlogs ebenfalls.
Svenska
-
Mal die erste wichtige Frage (eher an das Kernel-Team) welche Grafik-funktionen werden im Kernel sein und welche werden uns überhaupt zur verfügung stehen ?
Wenn wir das wissen können wir uns ja einen "Emulator" für's OS schreiben. Zumindest für die Grafikfunktionen zB. mit SDL. Dann könnte man schon beginnen zu Coden und müsste den Code dann nur gegen die API von CommOS linken.
mfg
Dead_mouse
-
Der Kernel selber bietet keine Grafikfunktionen :D
-
Hmm okay aber GUI und Grafikfunktionen sind zwei paar Schuhe also wer bietet die dann an ?
-
Das wissen wir noch nicht genau.
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. Wenn nämlich letzteres der Fall ist, bräuchte man eine weitere Abstraktionsschicht, eine Art graphic_server, der Funktionen für die GUI bereitstellt und selber auf den VESA-Treiber / die Grafik-Treier zugreift.
-
Man sollte den Grafiktreiber eigentlich schon irgendwie austauschen können, auch wenns erstmal unnötig ist, man weiß ja nie was kommt. außerdem müsste vom Treiber eigentlich nur Plot (zum Punkte malen, weiß net obs wo anders nicht evtl. anders heißt, hab in dieser hinsicht nur basic-erfahrung) zur verfügung gestellt werden, den rest könnte man ja selber basteln (baut schließlich alles auf der einen Funktion auf)
-
Ich bin auch für einen austauschbaren Grafik-Server. Zum Beispiel gibt es ja für NVidia und ATI freie 2D-Treiber bei Linux...
-
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
-
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
-
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.
-
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
-
OpenGL könnte machbar sein (in ferner Zukunft) siehe Mesa, etc...
-
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...
-
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.
-
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
-
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.
-
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
-
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...
-
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
-
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...
-
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
-
äääää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
-
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.
-
waers vielleicht nicht irgendwie besser, wenn man vielleicht zuerst die GUI lauffaehig macht, bevor man dafuer eine entwicklungsumgebung entwickelt? (was fuer ein wortspiel!)
-
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?
-
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 ^^
-
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.
-
Hi,
noch mal was wegen der GUI:
Soll die eigentlich n "schönes Design wie XP bekommen, oder ehr so wie die älteren Windows-Versionen?
PS: Mir is schon klar, dass sie net so wie XP aussehen wird! Sondern viel schöner! :wink:
-
wie waers, wenn man sich mal was neues einfallen laesst, und nicht immer die alten sachen kopiert? ;)
-
@Programmerfish
Ich halte deinen Vorschlag für sinnvoll, besprich das mal mit Golum
@Darkthing
Wenn ihr warten wollt, bis der Kernel bereit ist, eine GUI zu hosten, dann müsst ihr euch _sehr_ lange gedulden. Mit Milestone 1 wird das definitiv _nicht_ möglich sein, da er kein Treiberinterface haben wird. Und auch Milestone 2 wird euch wenig nützen, da zunächst einmal grundlegende Sachen wie App-Server, Graphic-Server, VESA-Treiber, FS-Treiber usw. geschrieben werden muss.
Deshalb war mein Vorschlag, dass die GUI zunächst auf der Basis von SDL implementiert wird und später auf das LOST-System portiert wird.
@T-Head & hannibal
Ich denke, Themeing wäre ein sehr nettes Feature, das auch nicht zu schwer zu implementieren wäre.
-
Also ich persönlich finde das LSD-Design von WindowsXP absolut nicht schön, sondern eher potthässlich, aber das ist nunmal Geschmackssache. Ich denke es gibt genug andere GUIs an denen man sich Orientieren kann, einige Windowmanager wie Blackbox, IceWM, WMI, haben sehr einfache aber schöne Designs..zudem fände ich es eine Gute Idee sich an der alten NextStep (bzw GnuStep/... für Linux) zu orientieren.
-
Hi,
@ASC
Es ist aber schöner wie das Design von 98! Das is zu grau!
NAtürlich gibtz da viel viel schöneres! ICh will ja auch ganich das von Win haben, da müsst ich ja imer an M$ denken! :wink:
ICh wär natürlich auch für was ganz neues! :P
-
Ich mach jetzt mal wie schon erwähnt auf SDL-Basis so Grundlegende Funktionen wie Punkt Strich Rahmen viel mehr nicht.
Dann können wir schonmal anfangen zu Planen wie die GUI auf sachen wie Mausklicke etc. reagiert. Falls ihr Vorschläge etc. habt ich hab meine ICQ-Nummer angegeben und werd versuchen möglichst oft im IRC zu sein (euIRC (irc.euirc.net) Channel #gui.lost)
Wies im moment aussieht werden ich und Noob gemeinsam die Organisation übernehmen. Kann sich aber noch viel ändern. Werd mich melden wenn ich mit dem SDL-Kram fertig bin.
Wenn ihr vorschläge dazu habt wie die GUI mit Fenstern kommunizieren zB. eingaben weiterleiten meldet euch bitte da das auch über SDL laufen muss und es sicher einfacher ist sowas von Anfang an da einzubauen.
mfg
Dead_mouse
-
Hi,
es könnte ja mal jeder der will z.B. ein Fenster Designen, und dann könnten wir schaun, was für Funktionen da drann müssen, ...
Wie z.B. Wann man irgendwo hin klickt wird es geschlossen, Minimiert, Maximier, ...
-
Ich meinte eher von wo die Anwendung die zu einem Fenster gehört weiß das sie angeklickt worden ist. Eine möglichkeit wäre das System von Windows wo die Anwendung solche Nachrichten abfragen muss aber mich würde interessieren ob jemand andere (bessere?) Ideen hat.
Initialisieren und Deinitialisieren sowie Punkt-Funktion sind Fertig. Werd mich jetzt mal an Linien machen.
-
Leider bin ich so von M$ geprägt, dass immer wenn ich versuche, Fenster zu designen, eine gewisse ähnlichkeit zu Windos erkennbar ist...
-
Hi,
ok, dann fällst du schon mal für das designen aus! :twisted: :lol:
Aber wir könntens ja so gra blau (LowLevel-Artig) machen! :?:
So wie das: (http://www.lowlevel.brainsware.org/forum/templates/subSilver/images/lowlevel_s.jpg)
-
Ich hab dem Designer dieses Logos eine Mail geschrieben, mit dem Vorschlag, er könnte uns für LOST eine GUI designen. Mal sehen, was er davon hält.
-
ich hab auch schon vor einiger zeit einen drauf angesetzt was zu designen, zwar net ganz lowlevel-design (Hellblau/Silber) und erinnert bis jetz (hab erst menüentwürfe zu gesicht bekommen) stark an winxp, sieht aber trotzdem gut aus. ich lads kurz rauf, dann könnt ihrs euch ja ansehn (link kommt gleich per edit)
EDIT: hab jetz ne kleine seite fertiggestellt, zu finden ist sie unter http://gui.commos.overgames.de/index.php . Einfach oben das gewünschte Auswählen und freuen das die Bilder kommen :) Wer noch nen Entwurf hat, möge mir bitte einen oder mehrere Screenshots mit Beschreibung schicken, genaueres hierzu auf Anfrage / PN.
-
Hi,
also ich wr für das Desing, von dem Lowlevel-logo!
Schon mal weit forgegriffen: Wie wird eigentlich mit Icons??
-
Also ich bin ja für möglichst flexibles Design,
also möglichst viel variabel einstellbar.
Und um den Windowsuser den Umstieg zu erleichtern :twisted:,
sollte auch Windowsartiges-Design angeboten werden.
MfG
DDR-RAM
-
Hi,
ja! Das is klar! Aber ich denk mal, dass wir hier vom Grunddesign reden! :wink:
-
Schon mal weit vorgegriffen: Wie wird eigentlich mit Icons??
Woher willst du wissen das wir sowas wie Icons überhaupt haben?
Um solche Überlegungen anzustellen ist es definitiv noch zu früh. Wir haben noch nicht drüber nachgedacht wie die GUI aufgebaut ist, was für Funktionen sie bietet usw. Solche Sachen gehen IMHO vor. Wenn wir da mal ein Konzept gemacht haben können wir uns langsam Gedanken über das Aussehen machen.
-
Da ihr mit dem Posten ja nich warten könnt, nochmal hier ne Kopie von meinem letzten Posting damits auch ja jeder lesen kann ;)
ich hab auch schon vor einiger zeit einen drauf angesetzt was zu designen, zwar net ganz lowlevel-design (Hellblau/Silber) und erinnert bis jetz (hab erst menüentwürfe zu gesicht bekommen) stark an winxp, sieht aber trotzdem gut aus. ich lads kurz rauf, dann könnt ihrs euch ja ansehn (link kommt gleich per edit)
EDIT: hab jetz ne kleine seite fertiggestellt, zu finden ist sie unter http://gui.commos.overgames.de/index.php . Einfach oben das gewünschte Auswählen und freuen das die Bilder kommen Smilie Wer noch nen Entwurf hat, möge mir bitte einen oder mehrere Screenshots mit Beschreibung schicken, genaueres hierzu auf Anfrage / PN.
Ansonsten denk ich das es sowas wie Icons gibt is klar, oder habt ihr andere Ideen um sowas zu ersetzen?
-
Nur mit der Ruhe wir haben noch nichtmal die Grundlegenden Grafikfunktionen zur verfügung.
Ich mal mal nen eigenen Thread für Vorschläge zur GUI auf.
-
Hi,
@N00B
Ich find dess gar net mal so schlecht! :P
-
Soweit es meine Zeit zuläßt, würde ich auch gern beim (Code-)Design mitmischen. :)
-
in anbetracht der neuesten entwicklungen in den anderen GUI-threads wuerde ich mich gern noch als GUI-API & GUI-server programmierer melden.
damit ich euch noch mehr meine meinung aufs aug druecken kann :twisted:
*runs*
-
GUI-Server würde schon eher zum Kernel gehören oder ?
-
Kommt drauf an, was man jetzt unter GUI-Server versteht: Wenn das jetzt das Ding sein soll, wo das gesamte Programm mitsamt Windowmanager usw. drin ist, würde ich eher nein sagen.
Ich glaube, wir sollte langsam mal ein paar Begriffe klären. ;)
-
GUI-Server würde schon eher zum Kernel gehören oder ?
soweit ich weiss wollen wir doch immer noch einen micro-kernel machen ? da hat ein GUI-server glaub ich nichts drin verloren ^^
-
Jeder der lust hat kann sich auf den IRC-Server irc.euirc.org begeben
Wir sind dort öfters im Channel #gui.lost anzutreffen.
-
Morgen :D :D :D
ich wollt mal Frägen ob ihr noch nen Coder sucht :?: Wenn ja würd ich mich anbieten. Kann C und teilweise C++, Basic und Perl(wenig). Hab am Tag 2 Std. Zeit und auch schon ein paar gute ideeen.
-
Im moment leigt die Gui auf eis weil die gröbste Planung getan ist und alles weitere vom Kernel abhängen würde. (Wo sich im moment nichts tut)