PFDefines.skn: String-Konstanten für App.-pfade, etc. verwenden

    Hallo Ralf,


    jetzt habe ich entdeckt, warum Du gestern sooo traurig warst. ;)
    Sorry, aber ich lese diesen Thread heute zum ersten Mal - nicht böse sein - aber ich lese längst nicht alles hier im Forum, sonst hätte ich keine Zeit mehr zum Skinnen.


    Ich habe jetzt alles von oben bis unten 1x durchgelesen. Mit meinem "Seniorhirn" dauert das Kapieren allerdings entweder länger, oder manchmal klappt's auch garnicht. :lachen


    Mein Istzustand:
    1.) Ich benötige 2-3 Instanzen des Tools, also Speicherorte in unterschiedlichen Verzeichnissen.
    2.) In meinem Installations-rar ist dann jeweils das Tool bereits mehrfach - gleich im richtigen Verzeichnis - enthalten (in älteren Skins auch nur 1x, wenn reicht).
    3.) Ich benutze momentan bewußt nur Dinge, die auch nach einem Hardreset noch einwandfrei funktionieren.


    Da sehe ich Probleme:
    3.) Ich will eigentlich nicht, dass User sich in Zukunft selbst darum kümmern müssen, ob die Tools in a) richtiger Version, b) richtiger Anzahl und c) genügend Instanzen bereits gespeichert sind, weil gerade die Beginner damit völlig überfordert wären. Das hat dann nichts mehr mit Bedienerfreundlichkeit zutun.
    4.) Wenn ich das den Usern überlasse, hagelt es an Rückfragen, weil nichts richtig funktioniert. Darauf habe ich keinen Bock.
    5.) Selbst Stefan hat in seiner eigenen Anleitung bereits verschiedene Installationspfade angegeben ...\Programme\koord465.exe und \Programme\Koord\koord465.exe) ... Auch das lesen die User.
    6.) Beim Skinwechsel ohne Wechseltool - was passiert da wirklich bei den Usern? ?( Ich ahne Chaos...


    Wo ist der Gewinn bei Deinem Vorschlag?
    Dass Du nur noch in einer Mini-Datei nachschauen mußt, wo das Tool hingehört?
    Oder änderst Du diese Datei dann nach Deinen eigenen Bedürfnissen ab? Was machen Anfänger?


    Oder funktioniert das Skin-Wechsel-Tool jetzt garnicht richtig, wegen der unterschiedlichen Speicherorte für das Koord-Tool / vieler anderer Verzeichnisse, die geändert werden müssen?


    Ich sehe den Vorteil eigentlich nur bei PowerUsern wie Dich, die auch in der Lage sind, das nicht ganz einfache Skin-Wechsel-Tool zu handhaben (denn mit "einfach mal kopieren" ist es ja nicht getan).


    Ich sehe die Lösung eigentlich einzig darin, dass StefanDausR eine generelle Empfehlung herausgibt: 1. Instanzpfad, 2. Instanzpfad, 3. Instanzpfad
    Dann kann ich meine Installation wieder so bedienungsfreundlich gestalten wie ich will, oder kann. ;)


    An meinen Zeilen siehst Du bestimmt, dass ich Deine Idee noch nicht wirklich kapiert habe, oder? Komm hilf mir mal auf die Beine ...;D


    gruss sokobana

    Paßt hier vielleicht ganz gut rein:
    Kleiner Hinweis an die Skin-Schnipsler: Hier steht wie man die PFSkin.skn aufsplitten kann...

    Hi sokobana!


    Warum sollte ich Dir böse sein? ;)
    Selbst mir als Nicht-Skinner rutschen da so einige Threads durch, die ich später dann mehr zufällig, oder wenn sie wieder nach oben gespült werden, entdecke. Daher war meine gestrige Bemerkung (die hoffentlich nicht mißverstanden wurde) auch mehr als Reminder gedacht. Ich hatte nur übersehen, Dir gleich den Link mitzuliefern.



    Zu Deinen Anmerkungen (und nochmal generell) zum grundsätzlichen Verständnis meiner Idee:
    Jede Aufruf-Instanz einer bestimmten Programm-Version benötigt eine Pfadangabe, die in den *.skn-Dateien bisher immer 'festverdrahtet' angegeben worden ist.
    Ein Ändern und Anpassungen an die eigene Umgebung, hauptsächlich bei Verwendung des Tauschers, mußte dann immer an den untersch. Stellen in den Skin-Dateien selber erfolgen oder man nahm in Kauf, daß sich gleiche Versionen in den untersch. Pfaden tummelten.


    Werden nun alle Programmpfade extern in einer sep. Datei (PFDefines.skn) als Konstante definiert, ist es IMHO auch bei Dir möglich, ohne Komfortverlust alles das innerhalb eines Archivs mitzuliefern, was ein problemloses Setup auszeichnet. Die zus. PFDefines.skn enthält ja nur die Pfadangaben, der Rest (also die Auflösung der Konstanten selber) geschieht immer noch über Deine Skin-Logik.


    Muß aus irgendwelchen Gründen eine ältere (oder bestimmte) Prg.-Version verwendet werden, ist eine kurzer Kommentar in der PFDefines.skn unabdingbar, damit erkennbar ist, warum diese Konstante (und damit die Funktionalität) zwingend auf das Verz. einer älteren Version zeigen muß. Oder man ändert nichts an den jew. Vorgaben, dann läuft trotzdem alles wie gehabt.


    Ich hoffe, ich habe damit Deine Fragen einigermaßen verständlich beantwortet.


    Und solltest Du weiterhin Bedenken haben, Deine Ablauf- oder Setup-Logik läßt sich damit nicht so komfortabel umsetzen wie bisher von Dir gewohnt, dann habe ich dafür Verständnis. Wie gesagt, letztlich profitieren nur die, die mehrere Skins parallel installiert und auch ausprobieren wollen.



    EDIT: Ein kleiner Vorteil ergibt sich auch für den Skin-Ersteller: Ändert sich ein Aufruf-Pfad oder kann eine ältere Version mit einer Aktuelleren zusammengelegt werden, brauch nur an einer Stelle der Pfad in der PFDefines.skn geändert zu werden, anstatt, wie jetzt, den Find&Replace eines Editors zu benutzen.

    Zitat

    Original von m.g
    Paßt hier vielleicht ganz gut rein:
    Kleiner Hinweis an die Skin-Schnipsler: Hier steht wie man die PFSkin.skn aufsplitten kann...


    Danke für den Hinweis.
    Gute Idee, da hast Du meine Überlegungen zum Auslagern und (fast) variablem Einbinden bestimmter Funktionsblöcke noch weiter verfeinert bzw. ausgebaut.


    Bin mal gespannt, wie man das noch sinnvoll ausbauen kann. Bei der Tastatureinbindung wird es sicherlich Sinn machen: einfach nur die includes zu ändern, ohne gleich ganze Skript-Blöcke überschreiben zu müssen.