Der richtige Ort für Daten und Einstellungen

[Cyborg]

(Abgespalten vom AmigaOS4.1FE und Codebench Thema, weil es dann doch in eine ganz andere Richtung ging.

Bei mir liegt das Problem nur darin das ich alles an nachträglich installierten Programmen auf eine eigene Partition liegen habe.
Und das auch nur um in Falle einer "Neuinstallation" des Betriebssystems nicht alles wieder neu installieren zu müssen!

Weitere Software auf einer eigenen Partition ist durchaus sinnvoll, habe ich selbst und empfehle ich auch jedem. Dennoch ist das halt kein Garant dafür, daß sie einfach so nach einer Neuinstallation des Betriebssystems wieder läuft, weil eben auch viele Dinge irgendwo im System abgelegt werden.

[tommysammy]

Oft sitzt das Problem vorm dem Bildschirm, das merke ich immer wieder. Leute fangen an Software hin und her zu kopieren und wissen nicht genau was sie da anstellen. Es wird einfach nur der Ordner der Software kopiert anstatt es besser neu zu installieren. Das ist jetzt aber kein Vorwurf. Dasselbe passiert ja ständig bei anderen Betriebssystemupdates genauso.

[Cyborg]

Das ist aber der falsche Ansatz, denn normalerweise sollte es ja bei AmigaOS genau so laufen: Programmschublade einfach kopieren und fertig. Oder löschen und fertig. Und keine Installations- und Deinstallationsorgien wie bei Windoof oder Linux. Der Mac hat das zum Großteil noch genauso behalten, wie wir mal waren... aber irgendwie scheinen immer mehr Leute dem Wahn zu verfallen, alles Schlechte von Windoof und Linux übernehmen zu müssen

Aber wir weichen jetzt schon zu weit vom Thema ab.

[whose]

@Cyborg:

Wie man´s nimmt... wir diskutieren ja quasi die Ursache des Themas

Mir wäre es auch ganz lieb, wenn Du bei dem einen oder anderen Entwickler bewirken könntest, daß die diesen Unfug mit ENV-Variablen für Programm-Parameter endlich mal bleiben lassen.

Andererseits ist es ja mal geplant gewesen, richeditor.gadget zum Systembestandteil zu machen...

[Cyborg]

@ whose

Warum? Wenn es um Systembestandteile geht, sehe ich das nicht so. ENV: ist schon immer für die Systemeinstellungen dagewesen. Oder beziehst Du Dich auf was anderes?

@ ShawnBaxe

Ich habe mich hauptsächlich auf die weniger versierten bezogen, von denen es naturgemäß einen Haufen mit UAE gibt. Die kommen dann auch schon Mal an und wollen eine neue CD, weil sie (durch falsche Einstellungen) ihre nicht unter UAE zum Booten bekommen

[tommysammy]

Ein Programm einfach von A nach B kopieren und dann zu hoffen das es läuft, funktioniert meistens nicht. Dafür gibt es einfach zu viele mögliche Abhängigkeiten die in C oder Sobjc oder Libs oder Env oder S/Arexx oder Userstartup oder Help und Locale oder L liegen können. Das beste ist immer zu installieren und/oder in der readme reinzuschauen.

[Blackbird]

So ein Quark....!

Das beste ist, sich mit der Materie etwas vertraut zu machen, da nutzt das ganze rumgeheule nix

Neuinstallation, wenn ich das schön höre. Warum ? nur weil ein Bestandteil fehlt soll ich mir meine mühsam eingerichtete Config löschen und Standard installieren lassen ?

Nö, da such ich lieber nach der Ursache.
Der beste Ansatz ist immer erstmal Snoopy/SnoopDos wenn ich so gar nicht weis wo ich suchen soll.
Dann schau ich mir das Archiv an was drin ist, oder lass mir den Installercode anzeigen.
Wenn das auch nicht hilft, frage ich in Foren.
Und wenn gar nix hilft kommt dann erst eine Installation in Frage...

Immer dieses Nachgehechel von Windows/Linux.... Nee ne

[whose]

@Cyborg:

Bei Systembestandteilen wäre das für mich kein Problem... es wäre dann sogar sehr einfach, eine Art "Migrationsutility" zu bauen, welches die aktuellen ENV-Variablen, Fonts etc. sichert und auf Wunsch auf eine nagelneue Installation überträgt. Wobei es mir schon etwas auf die Nerven geht, daß man bei bestimmten Systemteilen dazu übergegangen ist, von IFF auf XML umzuschwenken. Aber meine Vorbehalte gegen XML kennst Du ja schon

Es gibt aber auch ein paar Beispiele, die Einstellungen in ENV: speichern, aber kein Systembestandteil sind. Auf Anhieb fallen mir da Wordworth (bzw. Digita-Produkte allgemein) und lpr.device ein. Wobei es beim lpr.device gar nicht SO klar ist, daß ENV: der falsche Ort ist. Wäre mit einem "Migrationsutility" aber auch abdeckbar, von daher...

Auch AmiBoing und Cherry_Darling-Gedöns speichert alles in ENV:, wo es aber definitiv nichts zu suchen hat. Das ist teilweise aber auch dem Hype um XML zu verdanken. Der Kram ist natürlich simpler mittels PutVar/GetVar() zu schreiben, als es in den Tooltypes unterzubringen (wo es aber auch nicht reinpassen würde) oder mittels Write() in PROGDIR: zu schreiben.

Trotzdem würde ich es wirklich bevorzugen, wenn Spielstände und Ähnliches in PROGDIR: landet. Gilt eigentlich für alle Programmeinstellungen, sofern die mit dem OS nichts an der Mütze haben.

Dann hat man auf jeden Fall bedeutend weniger Zeug, daß man (vorerst) von Hand auf eine Neuinstalltion übertragen muß. Und weniger Nachfragen, weil irgendein Programm mit der neuen Partition nicht will.

[Cyborg]

1) Migrationstool ist eine sinnvolle Anmerkung. Habe ich mir auch schon gedacht, aber das Problem ist halt die liebe Zeit Steht aber schon mal in meiner Ideensammlung. Immerhin

2) Deine XML-Vorbehalte kenne ich. Wobei Du strikt die durchaus vorhandenen Vorteile ignorierst Manuelle editierbar, leichter verständlich, willkürlich änderbar (und nicht auf irgendwelche Datenstrukturen festgezurrt wie bei IFF), etc.

3) Wir können nichts gegen Tool XY machen, das im ENV: Zeug ablegt. Nur am System selbst.

4) Ich weiß nicht, was AmiBoing und Cherry Darling tatsächlich machen. Sinnvoll wäre natürlich die Nutzung der application.library samt PrefsObjects-Interface und das Ablegen der Daten im PROGDIR:. Keine Frage.

[Blackbird]

Das sehe ich genauso wie Wolfgang.
In den Env-variablen haben Spieledaten oder sonstiges nichts verloren. Entspricht das eigentlich den Styleguides ?

Programme sollten ihre Configdaten in ihrem eigenen Ordner suchen. Daten die von Programmen benötigt werden ebenso. Wenns um einfache Sachen geht solltten die in die Tooltypes, da gibts eigentlich gar nix dran zu deuteln...

Bei Librarys oder Zusatzbefehlen die manche Programme dringend benötigen sollten ebenfalls nicht in sys:c oder eben sys:Libs verschwinden.

MorphOs hats doch vorgemacht, die Lösung wäre auch für OS4.x angebracht.
Man könnte sich auch selbst behelfen, in dem man sich z.B auf Work: (oder wie auch immer das bei den Leuten heist wo sie ihre Programme bunkern) C und Libs Verzeichnisse anlegt wo man dann alle Libs die zusätzlich gebraucht werden und nix mit dem System zu tun haben speichert (installieren lassen) und dann eifach einen Assign add drauf...

Dann entfällt sicherlich die nachinstalliererei von Libs&Co. Das einzige was man dann tun müßte wäre eben die user-startup um die add einträge zu ergänzen und das wars

Warum umständlich ?