Ich nutze Neo-Vars mit anderen Layoutvarianten, welche leider in die portablen Version von Neovars auf der Homepage nicht integriert sind. Eigentlich gibt es meiner Meinung nach gar kein Grund die Portabilität nicht in den Hauptzweig von NeoVars zu integrieren. Vor allem hängt es nur an dem Pfad zur Ini-Datei, Neo2.ini. Ich habe das Skript so modifiziert, dass in beiden Pfaden nach der .ini geschaut wird, in AppData, sowie dem Skriptverzeichnis. Der Temp-Ordner kann m.E. so bleiben, das tut ja der Portabilität nichts.
Anbei ein Patch, der dies implementiert.
Ich nutze Neo-Vars mit anderen Layoutvarianten, welche leider in die portablen Version von Neovars auf der Homepage nicht integriert sind. Eigentlich gibt es meiner Meinung nach gar kein Grund die Portabilität nicht in den Hauptzweig von NeoVars zu integrieren. Vor allem hängt es nur an dem Pfad zur Ini-Datei, Neo2.ini. Ich habe das Skript so modifiziert, dass in beiden Pfaden nach der .ini geschaut wird, in AppData, sowie dem Skriptverzeichnis. Der Temp-Ordner kann m.E. so bleiben, das tut ja der Portabilität nichts.
Anbei ein Patch, der dies implementiert.
Der Patch würde so nicht funktionieren für die „nicht-portable“ Version, da inital keine .ini in %APPDATA% vorhanden ist. Letztlich ist aber NeoVars grundsätzlich portabel in dem Sinne, dass nichts installierst wird: die .exe-Datei enthält alle Daten. Die Konfiguration wird jedoch benutzerspezfisch gespeichert.
Eventuell sollte man das Skript so umstellen, dass es auch die Konfiguration aus dem Arbeitsverzeichnis liest. Dann wäre NeoVars zwar nicht mehr mehrbenutzerfähig – aber da es nicht global installiert wird, wäre dies ggf. sogar ein Vorteil.
Der Patch würde so nicht funktionieren für die „nicht-portable“ Version, da inital keine .ini in %APPDATA% vorhanden ist. Letztlich ist aber NeoVars grundsätzlich portabel in dem Sinne, dass nichts installierst wird: die .exe-Datei enthält alle Daten. Die Konfiguration wird jedoch benutzerspezfisch gespeichert.
Eventuell sollte man das Skript so umstellen, dass es auch die Konfiguration aus dem Arbeitsverzeichnis liest. Dann wäre NeoVars zwar nicht mehr mehrbenutzerfähig – aber da es nicht global installiert wird, wäre dies ggf. sogar ein Vorteil.
Es wird zuerst im Arbeitsverzeichnis geschaut und wenn dort keine Neo2.ini ist, wird das alte Verzeichnis in %APPDATA% benutzt.
Wurde in 978f6436c1e7cce8ca2e83e425cff6542fbfe7b2 eingeführt.
Es wird zuerst im Arbeitsverzeichnis geschaut und wenn dort keine Neo2.ini ist, wird das alte Verzeichnis in %APPDATA% benutzt.
Ich nutze Neo-Vars mit anderen Layoutvarianten, welche leider in die portablen Version von Neovars auf der Homepage nicht integriert sind. Eigentlich gibt es meiner Meinung nach gar kein Grund die Portabilität nicht in den Hauptzweig von NeoVars zu integrieren. Vor allem hängt es nur an dem Pfad zur Ini-Datei, Neo2.ini. Ich habe das Skript so modifiziert, dass in beiden Pfaden nach der .ini geschaut wird, in AppData, sowie dem Skriptverzeichnis. Der Temp-Ordner kann m.E. so bleiben, das tut ja der Portabilität nichts.
Anbei ein Patch, der dies implementiert.
Patch
Der Patch würde so nicht funktionieren für die „nicht-portable“ Version, da inital keine .ini in %APPDATA% vorhanden ist. Letztlich ist aber NeoVars grundsätzlich portabel in dem Sinne, dass nichts installierst wird: die .exe-Datei enthält alle Daten. Die Konfiguration wird jedoch benutzerspezfisch gespeichert.
Eventuell sollte man das Skript so umstellen, dass es auch die Konfiguration aus dem Arbeitsverzeichnis liest. Dann wäre NeoVars zwar nicht mehr mehrbenutzerfähig – aber da es nicht global installiert wird, wäre dies ggf. sogar ein Vorteil.
Wurde in
978f6436c1
eingeführt.Es wird zuerst im Arbeitsverzeichnis geschaut und wenn dort keine Neo2.ini ist, wird das alte Verzeichnis in %APPDATA% benutzt.