[REQ] Zerlegen der wincmd.ini

[DoubleT]

Hallo,
ich bin gerade am Zerlegen der wincmd.ini um mir meinen TC ein wenig mobiler zu gestallten. Dabei sind mir unter der Sektion [Configuration] einige Einstellungen aufgefallen, wo ich denke, dass sie eine eigene Sektion verdienen, um sie dann mit RedirectSection auslagern zu können.
Dies wäre sehr hilfreich, da an anderen Rechnern bzw. unter anderen Benutzerprofilen Abweichungen diesbezüglich vorhanden sein können.

Hier meine Vorstellung dazu...

[ViewEdit]
Viewer=none
Viewertype=0
Editor=C:\Programme\...
MultiRenameEdit=C:\Programme\...

[CopyDelete]
CopyBlockSize=32
CopyBlockSizeOther=32
CopyHugeBlockSize=10240
CopyHugeBlockSizeOther=64
SamePartitions=C,D,EF
CopyCompatDrives=EXZ
CopyCompatUsbSticks=0
ExplorerForCopy=0
CopyDirTimeStamp=1
Win95Delete=0
UseTrash=1

[Thumbnail]
ThumbsLocation=%$LOCAL_APPDATA%\GHISLER
ThumbsCopyDel=1
ThumbsInDlg=0
ThumbsCustomFieldsEnabled=1
ThumbOptions=15
ThumbExplTypes=*.* | *.htm *.html
ThumbPlgTypes=*.*
ThumbIrfXnTypes=*.*
ThumbTxtTypes=*.txt *.ini
...


Dann wäre da noch etwas in Sachen Lesbarkeit der Ini's. Es wäre schön, wenn vor jeder Sektion immer eine Leerzeile vorhanden wäre. Das würde ungemein helfen, da nicht immer ein Syntax-Highlighting zur Verfügung steht.

Btw,
- In der Hilfe ist SamePartitions nicht alphabetisch einsortiert.
- Die Einstellung SpeedLimit ist zweimal vorhanden. Einmal unter [Configuration] und zum anderen unter [General].
- In der Hilfe ist die Sektion [General] nicht beschrieben.
- Sollte die Sektion [Extensions] nicht auch bei gesetztem AlternateUserIni dorthin ausgelagert werden?

[DoubleT]

Hm, ist mein Anliegen so abwegig, oder habe ich etwas übersehen?

[ghisler(Author)]

Das Problem ist die Rückwärtskompatibilität...

[DoubleT]

Hm, sowas löst man doch normalerweise mit einer kleinen Konvertierroutine im Programm.
Altes/neues Format lesen -> Neues Format schreiben.

[Hacker]

DoubleT,
Christian meint leider die Vorwaertskompatibilitaet, d.h. dass z.B. TC 6.57 diese wincmd.ini nicht mehr verstehen wuerde.

Roman

[HolgerK]

Mmmh,

[DirMenu]
RedirectSection=rdir_DirMenu.ini

Ist das vorwärts kompatibel?

Gruß,
Holger

[DoubleT]

DoubleT,
Christian meint leider die Vorwaertskompatibilitaet, d.h. dass z.B. TC 6.57 diese wincmd.ini nicht mehr verstehen wuerde.

Das ist doch Unsinn! Wenn ich mir eine neue Version installiere, dann benutze ich die auch. Ich kenne niemanden, der dann wieder zurück auf eine ältere Version wechselt. Die einzige Ausnahme wäre, dass grobe Bugs in der neuen Version vorhanden sind. Und selbst wenn, dann hat man halt immer noch seine alte Ini, wo es dann ja auch nicht weiter stört. Allternativ baut man eine '6.58', die mit dieser Ini umgehen kann, und gut ist's.

Das selbe würde ich auch bei der Änderung von wincmd.ini auf totalcmd.ini behaupten. Ich verstehe einfach nicht, warum der TC diese Datei nicht akzeptiert und lesen kann. Ist mir ein absolutes Rätsel.

Selbst wenn mir alle Einstellungen flöten gehen, dauert es 10 min. und alles ist wieder so wie es mal war. Die Argumentation, dass es mit der neuen Ini im alten TC nicht mehr funktioniert, ist völlig abwegig. Wen interessiert das? Wieso muss eine neue Ini mit eine alten Version funktionieren? Wo ist da der Fortschritt?
Dieser Argumentaion kann ich nicht wirklich folgen. Ich habe dann halt eine neue Ini, Punkt. Sie wird einmal konvertiert und gut. Wo ist das Problem?!?

Btw, ich bin selber Dev, und weiss wovon ich spreche.

PS. @Hacker, mein Post ist nicht gegen dich gerichtet! Ich quote nur dein Argument.

[Hacker]

DoubleT,

PS. @Hacker, mein Post ist nicht gegen dich gerichtet! Ich quote nur dein Argument.

Ist nicht mein Argument.

Roman

[dumbledore954]

Mir fallen auf Anhieb auch im professionellen Bereich keine 2 Softwareprodukte ein, bei denen auf Vorwärtskompatibilität geachtet wurde. Das wäre doch im Prinzip der absolute Feind jeder Innovation!

Ich möchte nicht zählen, wie oft ich schon Clients updaten musste, weil sie die Daten der nächsten Programmversion auf irgendeinem Server nicht mehr lesen konnten...

[versalzen]

das thema rückwärtskompatibilität ist ein totschlagargument.

mir gefällt allerdings besonders diese idee, die ich gerne supporte und die auch durch das o.g. argument keine entkräftung erfährt.

Es wäre schön, wenn vor jeder Sektion immer eine Leerzeile vorhanden wäre. Das würde ungemein helfen, da nicht immer ein Syntax-Highlighting zur Verfügung steht.

gibt es hier genügend interesse, so das man mal einen neuen request thread aufmachen kann?

[Lefteous]

das thema rückwärtskompatibilität ist ein totschlagargument.

Wenn man allerdings bedenkt, dass RedirectSection auch keine bidrektionale Kompatibiltität bietet, muss man sich wundern dass es in diesem Zusammenhang benutzt wird.

[versalzen]

das thema rückwärtskompatibilität ist ein totschlagargument.

Wenn man allerdings bedenkt, dass RedirectSection auch keine bidrektionale Kompatibiltität bietet, muss man sich wundern dass es in diesem Zusammenhang benutzt wird.

ich habe und werde es nicht testen, aber ich denke/vermute/meine/hoffe/rate, das ältere versionen die umleitung einfach ignorieren und somit kompatibel sind, weil der sektionsname existiert und somit auch innerhalb diesen geschrieben werden kann.

[Lefteous]

2versalzen
Natürlich wird die Umleitung bei einer neuen ini in einer alten version einfach ignoriert. Genau das hat aber zur Folge, dass die umgeleiteten Einträge nicht gelesen werden - also die Standardwerte benutzt werden - und beim Schreiben in die beinahe leeren Sektionen neue Werte geschrieben werden. Es ist mir schleierhaft wie man das als kompatibel bezeichnen kann.

Wenn das kompatibel ist, dann kann man mit ähnlichen Mechanismen auch die vorhandenen Sektionen zerlegen wie hier vorgeschlagen oder/und meinem Vorschag folgen, der es ermöglichen würde einzelne Sektionen und auch einzelne Werte aus einer anderen Datei zu lesen und den Rest (alles was nicht überstimmt wurde) aus der normalen Wincmd.ini zu lesen.
http://www.ghisler.ch/wiki/index.php?title=New_approach_for_INI_file_location

[versalzen]

2versalzenEs ist mir schleierhaft wie man das als kompatibel bezeichnen kann.

grund: es geht nix kaputt ;-)

Wenn das kompatibel ist, dann kann man mit ähnlichen Mechanismen auch die vorhandenen Sektionen zerlegen wie hier vorgeschlagen oder/und meinem Vorschag folgen, der es ermöglichen würde einzelne Sektionen und auch einzelne Werte aus einer anderen Datei zu lesen und den Rest (alles was nicht überstimmt wurde) aus der normalen Wincmd.ini zu lesen.
http://www.ghisler.ch/wiki/index.php?title=New_approach_for_INI_file_location

ja, das liesst sich gut an. ältere versionen wären auch kompatibel i.s.v. o.g. weil sie die sektion, die die umleitungen enthält, einfach ignorieren würde.

[OT]
es gibt hier nicht wirklich ein voting-system, bei dem jeder user (angemeldet im forum) eine stimme [x] für / [x] gegen eine jeweilige idee/request/vorschlag abgeben kann? (wohlformuliert und in irgendwelchen anderen threads zur genüge ausdiskutiert)
vorschläge gibt es ja zur genüge und entsprechende threds, aber -so wie ich das mitlese- verlaufen die meistens nach einem kurzen argument des autors im sande, oder werden irgendwann[tm] implementiert.
die "support++" bekundungen in diversen verschiedenen threads finde ich etwas sehr mühsam/unübersichtlich. wüsste allerdings auch nicht, ob es für diese board-software geeignete tools und überhaupt interesse gibt.
ich bin mir fast sicher, das jetzt ein: "das haben wir alles schonmal in irgendeinen thread gehabt[tm]" kommt. :-)
deswegen belasse ich es bei dieser aussage und meinem kundtuen, das ich dies sinnvoll finde.
falls ein aktueller thread dabei ist, wäre es nett mir den link zu zeigen, ich finde bei der suche nichts aktuelles.
[/OT]

[StatusQuo]

es gibt hier nicht wirklich ein voting-system

Du meinst nicht etwas wie Total Commander Polls (English)?