Prof. Cross-Platf. Nutzorient. UI

[Vermilion]

Meine Frage ist, wie kann ich ein User Interface realisieren, dass mit den Standard Gadgets etwas zu schwer bzw. unpassend umzusetzen wäre? Skinning. Aber wie? Das soll nicht schick aussehen, sondern das User Interface soll der Benutzung dienen (gravierenden Unterschied zu den meisten geskinnten Programmen). Beispiel, Steinbergs CuBase:



Die Sache ist die, Fensterrahmen kann meinetwegen bleiben wie er ist, es kommt ja nur auf den Fensterinhalt an (es müssen Gadgets erstellt werden, die gibt es eigentlich gar nicht, wie zum Beispiel die Tonspuren, Drehknöpfe usw.). Natürlich, selber zeichnen, ins ImageGadget rein und fertig. Aber ist das so eine gute Idee? Unter Linux haben da meine Programme seltsamerweise immer etwas gesponnen (früher als ich das getestet habe). Ist diese selbst-zeichnen-ImageGadget Variante nicht etwas "unprofessionell"? Direkt auf das Fenster zeichnen wäre ja etwas doof wegen dem Window Refresh. Und die schnellsten Möglichkeiten sollen das ja auch nicht gerade sein (GDI und so). Vielleicht was mit OpenGL? Kann mir da jemand etwas sagen?

Das alles natürlich unter dem Aspekt der Plattform Unabhängigkeit.

[edel]

Vielleicht solltest du dich erst einmal mit Windows / Linux beschaeftigen,
bzw deren API fuer die GUI. Der Rest duerfte dann von alleine kommen.

[Vermilion]

Naja, es soll ja auf beidem laufen, deshalb wäre das etwas doof, immer Systemspezifische API zu verwenden.

[kswb73]

Wenn nur was Anzeigen soll, könnt man 'nen Screen erstellen

[edel]

Naja, es soll ja auf beidem laufen, deshalb wäre das etwas doof, immer Systemspezifische API zu verwenden.

Quatsch, PB z.b. macht es ja nicht anders. Du kannst natuerlich auch
einfach auf 'nen Bild malen ...

[Vermilion]

Ja ok, aber dann müssten alle Betriebssysteme entsprechend gleiche Funktionen aufweisen, und da es hier ja eher um etwas sehr fachliches geht...

Meine Frage ist, ich würde es vielleicht so machen, ob das mit den ImageGadgets nicht zu Amateurhaft ist. Andernfalls hatte ich mir überlegt, einfach einen OpenGL Screen aufmachen und alles selber machen (Ein PureBasic Screen lässt sich ja nicht einfach so resizen).

[ZeHa]

Du kannst eig. schon die Img.Gad.-Methd. benutz., mache ich u. Java teilw. auch, da man halt wirkl. sehr indiv. Contr. damit erzg. kann.

Wenn PB objektor. wäre, liefe das etwas einf. ab, da würde man sich halt ein paar eig. Klass. machen, aber das geht ja leid. nicht, von dh. müßtest Du Dir halt 'ne Vorg.w. suchen, mit der Du d. G. sehr übers. hinbek.



Ist das jetzt eigtl. Gefl.?

[Vermilion]

Maaaan, ZeHa! ^^ Die Topics müssen einen endlichen Titel besitzen, wenn man sie erstellt, das ist der Grund für meinen Abkürzungswahn. ^^ Sollte eigentlich heißen: Plattformunabhängige, ("professionelle",) Nutzorientierte UI
Das war aber anscheinend zu lang, sogar so lang dass noch etwas abgeschnitten wurde (vor dem Bearbeiten, bei der 1. Version des Titels).

[ZeHa]

Joo ist ok dachte nur daß schon noch etwas mehr Platz gewesen wäre

Naja aber dennoch, ich glaube es wäre wirklich das beste, ImageGadgets zu verwenden, oder andere Gadgets, auf die Du zeichnen kannst (habe mich was PB betrifft noch nie so 100%ig damit befaßt).

Mit OpenGL oder Sprites würd ich es dagegen nicht machen, da Du somit auch noch das ganze Event-Handling machen mußt. Wenn Du aber bestehende Gadgets benutzt und nur drüberzeichnest, dann hast Du zumindest schonmal das ganze Klicken und Drag'n'Drop usw. und brauchst das halt nicht mehr neu zu programmieren (was dann auch wieder direkt Fehler vermeidet).

[edel]

Selbst wenn man auf 'nen Bild malt, muessen die Events abgefragt werden,
und das garantiert nicht in einer PB Eventschleife. Von daher muss er sich
so oder so mit der API beschaeftigen und dann kann man es auch gleich
richtig machen.