Hallo zusammen,
ich hab eine Frage bezüglich der Portierbarkeit des Quellcodes. Sagen wir mal ich schreibe mein Programm zunächst in/unter und für Windows. Zum Teil sind hierbei API Aufrufe und kleine Tricks notwendig damit das Programm so funktioniert wie es soll. Als Beispiel sei hier mal das direkte reagieren auf die ScrollBar genannt, das also mein Programm erfasst wenn die Scrollbar bewegt wird, dient bei mir dazu meine Tilemap auf dem Bildschirm zu verschieben. Hierfür habe ich folgenden Code von FluidByte verwendet:
http://www.purebasic.fr/german/viewtopi ... lbargadget
Das funktioniert zwar bestens, ist aber wohl nur unter Windows möglich und müsste für Linux angepasst werden. Daher ein paar Fragen:
1. Gibt es eine Möglichkeit das Bewegen der Slider so zu erfassen das der Code später auch unter Linux funktioniert?
2. Wenn die Antwort bei 1. Nein lautet - macht es Sinn das Programm so weiter zu entwickeln?
3. Kann man sich bei den PB eigenen Befehlen und Funktionen darauf verlassen das ein Programm auch unter Linux voll funktionsfähig sein wird? Ich selbst habe noch kein Linux System und dahingehend auch noch keine Erfahrung.
Vielen Dank schonmal
ScrollBargadget und portierbarkeit von Quellcode
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
WinAPI-Tricks funktionieren natürlich unter Linux überhaupt nicht.
eventuell gibt es entsprechungen in der Linux-API, die müßtest du dir
dann auch einzeln suchen. Generell ist es besser, nativ in PB zu
programmieren, wenn man auf Portierbarkeit hohen Wert legt.
auch bei nativem PB Code kann es feine Unterschiede geben, um eine
Anpassung kommt man nicht herum. Das betrifft aber eher besonders
OS-spezifische Punkte, in vielen Bereichen ist Code allgemeingültig.
generell muss ich dir aber sagen, wenn ich an deine sehr speziellen
Fragen denke, was den WindowedScreen betrifft, habe ich schon
jetzt ein flaues Gefühl hinsichtlich der portierbarkeit.
je mehr du am rumtricksen bist, schon unter Betreiebssystem A,
um so mehr musst du over-over-hardcore rumschrauben,
wenn es exakt genauso sein soll unter Betriebssystem B
ungefähr bei Level "Hammerschwierig" auf System A
erreichst du dann den Level "Unmöglich" für System B.
zu 2.
ob es für dich einen Sinn ergibt, ein Programm weiter zu entwickeln,
bei dem du später noch einiges an Zeit investieren musst, um es auf
Linux zum laufen zu bringen, kannst nur du allein entscheiden.
PS:
professionelle Teams würden wohl eher so vorgehen,
Basisfunktionalität und GUI konzeptionell komplett zu trennen,
die Funktionalität cross-platform aufzusetzen,
und zwei getrennte GUI-Systeme zu entwickeln.
eventuell gibt es entsprechungen in der Linux-API, die müßtest du dir
dann auch einzeln suchen. Generell ist es besser, nativ in PB zu
programmieren, wenn man auf Portierbarkeit hohen Wert legt.
auch bei nativem PB Code kann es feine Unterschiede geben, um eine
Anpassung kommt man nicht herum. Das betrifft aber eher besonders
OS-spezifische Punkte, in vielen Bereichen ist Code allgemeingültig.
generell muss ich dir aber sagen, wenn ich an deine sehr speziellen
Fragen denke, was den WindowedScreen betrifft, habe ich schon
jetzt ein flaues Gefühl hinsichtlich der portierbarkeit.
je mehr du am rumtricksen bist, schon unter Betreiebssystem A,
um so mehr musst du over-over-hardcore rumschrauben,
wenn es exakt genauso sein soll unter Betriebssystem B
ungefähr bei Level "Hammerschwierig" auf System A
erreichst du dann den Level "Unmöglich" für System B.
zu 2.
ob es für dich einen Sinn ergibt, ein Programm weiter zu entwickeln,
bei dem du später noch einiges an Zeit investieren musst, um es auf
Linux zum laufen zu bringen, kannst nur du allein entscheiden.
PS:
professionelle Teams würden wohl eher so vorgehen,
Basisfunktionalität und GUI konzeptionell komplett zu trennen,
die Funktionalität cross-platform aufzusetzen,
und zwei getrennte GUI-Systeme zu entwickeln.
Zuletzt geändert von Kaeru Gaman am 01.08.2008 09:56, insgesamt 1-mal geändert.
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
In meinen Augen kommt eigentlich nur eine Loesung in Frage, und zwarKaeru Gaman hat geschrieben: PS:
professionelle Teams würden wohl eher so vorgehen,
Basisfunktionalität und GUI konzeptionell komplett zu trennen,
die Funktionalität cross-platform aufzusetzen,
und zwei getrennte GUI-Systeme zu entwickeln.
ein UI das auf allen Zielplattformen laeuft, z.B. gtk, qt usw.
In PB sind die Workarounds manchmal so gross, das man es auch
gleich richtig haette machen koennen.
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
das ist die zweite Möglichkeit; ich weiß allerdings nicht,
wieviel Design- und Layout-technische Einschränkungen man dafür hinnehmen müßte.
... damit haben so viele zu knacken, wenn es einer drauf hat,
ein gutaussehendes, funktionelles cross-platform UI zu erstellen,
könnte er mit einem Tutorial fast schon Geld verdienen.
wieviel Design- und Layout-technische Einschränkungen man dafür hinnehmen müßte.
... damit haben so viele zu knacken, wenn es einer drauf hat,
ein gutaussehendes, funktionelles cross-platform UI zu erstellen,
könnte er mit einem Tutorial fast schon Geld verdienen.
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
Man hat natuerlich Einschraenkung, mal davon abgesehen das man sich mit
der API auseinander setzen muss, was man aber so oder so muss, bleibt
noch das Aussehen, da z.B. GTK keine native UI nutzt.
Wenn man GTK auf beiden System installiert hat, kann man den Source,
ohne ihn anzupassen, auf beiden Systemen mit PB kompilieren.
Das ganze ist aber wirklich nur dann sinnvoll, wenn man auf Windows,
Linux oder Mac, grosse Sachen plant, die sich mit PB Befehlen nicht, oder
nur mit Kraempfen realisieren lassen.
der API auseinander setzen muss, was man aber so oder so muss, bleibt
noch das Aussehen, da z.B. GTK keine native UI nutzt.
Wenn man GTK auf beiden System installiert hat, kann man den Source,
ohne ihn anzupassen, auf beiden Systemen mit PB kompilieren.
Das ganze ist aber wirklich nur dann sinnvoll, wenn man auf Windows,
Linux oder Mac, grosse Sachen plant, die sich mit PB Befehlen nicht, oder
nur mit Kraempfen realisieren lassen.