Graphisches Toolkit

[chrome]

Hi, erstmal ein großes Servus an alle, dies ist mein erster Post hier ^^

nachdem schon wer vor einer ganzen Weile auf die Idee kam, die GTK mitsamt Gnome-Desktop auf den gamepark zu porten, was eher kläglich denn sinnvoll endete, reift in mir mittlerweilen eine Idee:

Ein Tollkit a `là GTK oder QT für den gp2x, auf die spezielen Bedürfnisse der Handheldsteuerung angepasst, d.h. simpler und auf Maussteuerung oder deren emulation verzicend (mich regen Cursor auf, die mit kriechgeschwindigkeit per stick bewegt werden müßen).

Dieses als kleine und schnelle Bibliothek angeboten.
Dies würde die Möglichkeiten der Software-Programmierung, welche über Spiele hinausgeht, erheblich erleichtern, vileicht rudimentere GTK-Ähnlichkeit von der Ansteuerung her, was auch das Porten erleichtern würde.

Mann Könnte auh universelle Selektor-Guis für Emulatoren einbauen, was ja wohl kein großer Aufwand wäre und die Bedienung verinheitlichen und damit vereinfachen würde.

Derzeit arbeite ich an inem größeren projekt (nicht für den gp2x), doch wenn dieses abgeschloßen ist (1-3 Monate) würden für mich entweder eine raycasting-engine für gp2x anstehen, oder eben dieses Toolkit. Da ich nebenher zur Entspannung mit einem von beiden anfangen wollte gedachte ich einfach mal nachzufragen,
ob überhaupt das Interesse gegeben ist, denn für mich allein und die zwei programme die ich vieleicht mal für den Gamepark schreibseln werde wäre der Aufwand übertrieben, doch wenn es nachfrage gibt lege ich gerne los.


Frundliche grüße, Chrome.

 

[chrome]

Keine Antworten?

 

[relei]

Hallo,

doch ich will was sagen!!! :-D.

Ich verstehe nicht ganz was du meinst???

Aber ich fände eine art Toolkit schön mit dem man Qt Grafik Elemente schnell in ein Programm einbinden könnte und dazu dann auch Maus bzw Button Steuerung. Meinst du so was???

Gruß

Rene

 

[chrome]

Jaah!
Ich dachte an Buttons, Registerboxen, Scrollbars . . .
Kein Cursor im Sinne "herkömmlichen" Mausersatzes, das nervt nur, ich hab da ein paar Ideen, und werd mir sehr viele Spiele-menüs ansehen um eine optimierte tastensteuerung zu finden.

Lg, chrome

 

[mick]

Ein Tollkit a `là GTK oder QT für den gp2x, auf die spezielen Bedürfnisse der Handheldsteuerung angepasst, d.h. simpler und auf Maussteuerung oder deren emulation verzicend.

QT und GTK+ in den entsprechenden "embedded" Versionen sollten sich relativ problemlos auf den GP2X portieren lassen. Am besten nimmt man dazu gleich die passenden kompletten Handheld-Environments. Für QT wäre dies Trolltechs Qtopia bzw. die OS-Alternative OPIE, welche es bereits für den GP2X gibt. Für GTK gibt es GPE, dazu ist allerdings (ein) X-Window (Manager) (Matchbox) notwendig. Beide Toolkits sollten sich auch durch das Pad steuern lassen.

Dieses als kleine und schnelle Bibliothek angeboten.

QT2/3 ist zwar im Prinzip nur eine shared Library in der Größenordnung von 3..5 MB und sollte sich evtl. auch statisch linken lassen. Allerdings abhängig von libc/libg(++) & Co. Und GTK+ 2.6 hat leider recht viele Abhängigkeiten. Beide erfüllen nicht den Anspruch klein und schnell.
Die neuesten Versionen sind entweder noch "aufgeblähter" wie QT4.x oder auch wesentlich langsamer als der Vorgänger wie GTK+2.10 .

Dies würde die Möglichkeiten der Software-Programmierung, welche über Spiele hinausgeht, erheblich erleichtern, vileicht rudimentere GTK-Ähnlichkeit von der Ansteuerung her, was auch das Porten erleichtern würde.

Ds Problem it eigentlich nicht das reine Portieren von QT oder GTK+ Desktop zu GP2X. Wenn man PC-Spiele/Anwendungen von z.B. 1024x768 auf eine Auflösung von 320x240 portiert, dann muss man sich unbedingt um eine Neuanordung der GUI-Controls Gedanken machen. Außerdem müßte mn an alle Mouse-orientieren Controls wie Scrollbalken, pull-down Menüs, Drag & Drop etc. durch eine passende Pad-Steuerungersetzen.

Mann Könnte auh universelle Selektor-Guis für Emulatoren einbauen, was ja wohl kein großer Aufwand wäre und die Bedienung verinheitlichen und damit vereinfachen würde.

Es fehlt halt eine vernünftige GUI-Bibliothek für SDL. Jeder programmiert manuell seine eigenen Button, Menüs und Auswahlcontrols.

oder eben dieses Toolkit. Da ich nebenher zur Entspannung mit einem von beiden anfangen wollte gedachte ich einfach mal nachzufragen, ob überhaupt das Interesse gegeben ist, denn für mich allein und die zwei programme die ich vieleicht mal für den Gamepark schreibseln werde wäre der Aufwand übertrieben, doch wenn es nachfrage gibt lege ich gerne los.

Ja, Interesse bestünde bei mir an einem GUI-Toolkit für SDL, optimiert für den GP2X ohne/mit Touchscreen. Dazu sollte man sich die existieren Projekte erst einmal anschauen, um das Rad nicht ein zweites mal zu erfinden.

Gruß, Mick

 

[chrome]

Servus mick,
Ich kenne sowohl OPIE als auch GPE, beides ist auf meinen handheld pc wunderbar(auch wenn ich GPE persönlich besser find), und hörte das zumindest GPE geportet wird/ist. Allerdings kann ich mir nicht vorstellen das das auf dem gamepark auch so schön zu bedienen ist, weil(zumindest auf meinen)der touchscreen fehlt . So wie du bereits sagtest stell ich mir vor, die Bibliothek direkt auf SDL aufzusetzen, und die bedienung der GUI elemente von vornherein auf das d-Pad auszulegen. Meine momentane vorstellung währe in etwa folgende:


------------------------------
I I zeile 1
() button 1 () button 2 zeile 2


die Idee währe bisher, die gui elemente in bildschimbreite gruppen nebeneinander auszurichten,
welche man mit hoch und runter auf dem d-pad wechseln kann, und mit links und rechts kann man sich in den elementen der jeweiligen zeilie bewegen und mit A das element auswählen. Sollte das ausgewählte Element dann zum beispiel ein textfeld sein, würde sich die steuerung nur noch auf dieses beziehen, und man würde dann hier mit hoch und runter den scrollbalken betätigen. mit X könnte man das Element dann wieder verlassen und im gesammten Programm navigieren. Auf diese weise braucht man dann keinen Mausersatz und muss nicht jede Taste einzelln durchgehen.
Dieses bedienkonzept hab ich auch bei einen Programm unter dos erfolgreich umgesetzt.
(natürlich müsste sich die zeilenbreite nicht auf den kompleten Bildschirm beziehen, denkbar währen Fenster die man mit den Schultertasten durchschalten könnte.)

Lg, Chrome