Editor Gui Talk [split aus dem screenshot thread]

this-*gt*that

Hab mich gestern noch per Messenger mit Vertexwahn unterhalten und vermutlich entwickeln wir jetzt beide parallel unsere Editoren mit Qt und können uns dann immer wieder mal gegenseitig helfen.
In 6+ Monaten gibts dann vllt sogar die ersten Screenshots;P

GUI coden find ich eigentlich ganz angenehm und eine willkommene Abwechslung zum komplexen 3D-Grafik-Mathe gehaxx0r. Is schön entspannend und man muss nicht viel nachdenken (im Grunde wie Webdesign). Hauptberuflich möcht ich sowas auch net machen, aber zwischendurch find ichs angenehm.

Ich war mit WinForms extrem zufrieden. Der GUI Designer ist klasse und Performance Probleme hatte ich auch nie. Klar braucht .NET Runtime einiges an Speicher, aber auf heutigen PCs nicht mehr wirklich ein Problem. Der ständig steigende Speicherbedarf bei dir könnte auch an einer suboptimalen Renderloop liegen. Hab da auch einige Zeit googeln müssen, bis ich eine gute hatte. Wenn man nicht aufpasst, allokiert .NET in jedem "Schleifendurchlauf" Speicher.

Ich habe mir so ziemlich alle großen GUI Toolkits angeschaut und mein Kurzfazit ist:

WinForms: Klasse, man kommt sehr schnell voran. Angenehmer Code.
WPF: Genial, extrem mächtig. Aber man braucht schon fast einen Grafiker, um was wirklich beeindruckendes zu schaffen.
MFC: Alt, hässlich.
wxWidgets: Alt, hässlich, MFC-Stil.
QT: Sehr angenehme API, gut dokumentiert. Das schönste native GUI Toolkit, das ich gefunden hab.
Motif: Alt, hässlich.
GTKmm: Ganz ok.

rapso

hab bis ich zur arbeit musste auch noch ein partiel alternativen angeschaut (hatte backups gemacht und das verlangt nur ab und zu nen klick oder dateiverschieben).

-CeGUI angesehen, an sich schaut das nett aus, wohl ausreichend fuer spiele (hat auch styles die man laden kann), allerdings wohl nicht maechtig genug umalles machen zu koennen (also eher lightweight im vergleich was ein leveleditor machen muss).
-WinForms angesehen (mit c++ /clr), an sich auch ganz gut, erinnert mich ein wenig an den borland builder.
-Qt hatte ich mir schon vorher angesehen, da gefaellt mir das feste binden von signal->slot nicht, wenn ich schon signals verwende, dann nutze ich lose bindungen. (also ein signal wird verschickt und die empfaenger filtern sich schon raus was noetig ist). hab zuviele projekte mit libsig gesehen die debugging horror waren, vielleicht bin ich deswegen biased.
-WTL, hmm,an sich nett, aber code based gui basteln ist auf dauer eing raus (jedenfalls waren die ganzen ergoogleten tutorials so).
-MFC mal wieder angesehen, ich muss sagen, es wirkt wie WinForms von der integration in VS her, so richtig was stoerendes daran hab ich nicht gefunden (aber ich mag ja auch wxWidgets).

kann mir jemand sagen (vielleicht an beispielen, vielleicht sogar auf gfx editoren) was so schlecht an MFC/wxWidgets ist. Ich code alle 10jahre mal nen editor und da opfer ich nur die aller aller noetigste zeit fuer die gui.

meine traum gui lib wuerde wohl komplett entkoppelt von der eigentlichen app laufen, nur auf signals/events warten und diese zurueckliefern, eine event-queue als schnittstelle und das wars.

GuiSingleton=GUI::Init("guiAusEinemExternenEditor.xml");

//somewhere in main loop
while(pEvent=EvenQueue.Pop())
{
if(!GuiSingleton->Process(pEvent) && 
   !EngineSingleton->Process(pEvent))
   Console.Warning("Missed event:",pEvent->AsString());
}   
.
.
.
EngineSingleton->Render();
EngineSingleton->BltOnTop(GuiSingleton->Render());

this-*gt*that

rapso schrieb:

kann mir jemand sagen (vielleicht an beispielen, vielleicht sogar auf gfx editoren) was so schlecht an MFC/wxWidgets ist.

Keine Ahnung wieso es andere mies finden, aber MIR gefallen die nicht weil es nicht modernes C++ ist, sondern eher C mit hässlichen Makros. Wenn ich damit entwickel, komme ich mir vor wie im Jahr 1990. Wieso mich also damit rumplagen, wenn es schönere Alternativen gibt.

rapso

Naja, das macht alles visual studio im hintergrund, da sollte sich niemand mit plagen imho. oder muss man da noch was von hand machen? (wie gesagt, ich schreib selten gui, deswegen die vielleicht dummen fragen).

this-*gt*that

Hm, hab grad mal wieder den Code geöffnet (seit über einem Jahr^^) und wie es aussieht mach ich auch nix besonderes. Im Großen und Ganzen erzeug ich nur eine Instanz meiner Fensterklasse und starte dann die Anwendung mit Application::Run(form).
Dann häng ich im Ctor meiner Fensterklasse einen Eventhandler an das OnIdle Event der Application:

Application::Idle += gcnew EventHandler(this, &EditorForm::OnIdle);

...
void OnIdle(Object^ sender, EventArgs^ e) {
   MSG msg;		
   while(!PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE))
      processFrame(); 
}

processFrame() ruft dann mein update() und render() auf.
Hab die Anwendung vor gut 2 Jahren unter Vista geschrieben und jetzt zum 1. Mal seit langem versucht das Ding wieder zu starten (benutze mittlerweile Win 7) - gibt leider eine Exception
Drum kann ich dir im Moment leider net sagen, ob bei meiner Anwendung auch permanent der allokierte Speicher steigt.

Da ich jetzt wohl eh auf QT umsteig und alles neuschreib, werd ich vermutlich auch garnet mehr versuchen meinen WinForms Editor zu fixen. (Nervig isses irgendwie schon, dass es nicht mehr geht, nur weil ich von Vista auf Win7 gewechselt hab...)

rapso

vielleicht mal das compatibility flag setzen, oder bist du vielleicht von 32bit auf 64bit gegangen?

Jochen S.

Naja, mein Editor war auch so ein Projekt, das ich "mal eben so" angefangen habe, ich hatte gerade mein letztes Spiel fertig und da dachte ich, ich mache mal was anderes. Dass ich jetzt die Gui-Komponente meiner Engine für die Oberfläche benutzt hab, liegt daran, dass ich die sowiso schon für meine Spiele geschrieben habe. (Bei den Spielen kann man nicht so eingach auf windows forms zurückgreifen, oder?)
Ich hab mich auch mit den ganzen Gui-Bibliotheken zu wenig befasst, ich wusste nicht, wie ich in dem Fenster Direct3D-Grafik mit Hardwarebeschleunigung integrieren sollte. Aber die Gui-Klasse ist eigentlich ausreichend für meine Zwecke. An der Klasse ist auch eineiges an gemurkse, z.B. kann man ein Button in eine Proces-Bar umwandeln, wenn man möchte. Mit den Nachrichten hab ich das so gelöst, dass man einer Instanz einen zeiger auf eine Funktion übergeben wird, die Aufgerufen wird, wenn etwas mit dem Element passiert ist.

MfG, Jochen

rapso

winforms wohl nicht, aber WPF soll d3d fuers rendern nutzen.

wie werdet ihr die editor-gui erstellen? per code oder mittels tools? (also die qt jungs hauptsaechlich).

this-*gt*that

Jochen S. schrieb:

(Bei den Spielen kann man nicht so eingach auf windows forms zurückgreifen, oder?)

Nein, das geht nicht.

rapso schrieb:

winforms wohl nicht, aber WPF soll d3d fuers rendern nutzen.

Japp, allerdings wohl nur D3D9, damit es auch noch auf WindowsXP läuft. D3D10/11 zu integrieren soll bissi schwieriger sein.
Was man mit WPF machen kann, ist schon ziemlich cool: http://www.youtube.com/watch?v=MTfM5pmUrnU&feature=related
Das meiste ist zwar Spielerei, aber allein DASS es geht ist interessant.

Jochen S. schrieb:

wie werdet ihr die editor-gui erstellen? per code oder mittels tools? (also die qt jungs hauptsaechlich).

Bei QT gibts ja einen Designer. Wenn der gut ist, werd ich den benutzen. Is mir auf jeden Fall lieber als die ganzen Controlwerte (Positions, Widths, Heights, Margins etc.) im Code reinzuhacken und alle 5 Minuten zu kompilieren um zu schauen obs gut aussieht.
Im Idealfall design ich die GUI im GUI Designer und programmiere den größten Teil der Logik sowie Engine Interop und Engine selber in VS 2010.

Vertexwahn

wie werdet ihr die editor-gui erstellen? per code oder mittels tools?

Ich hab so viel wie geht mit dem QT Designer erstellt. Meine persönliche Philosophie: Alles was möglich ist im Designer machen - wenn möglich keine Zeile Programmcode tippen.