Could layouts/settings (optionally) sit within a user profile?

[teknowledgist]

I realize that this is a portable application, but how difficult would it be to adjust the code so that if %A_WorkingDir% isn't %A_ScriptDir% then EPKL checks for override settings/layouts files an "EPKL" subdirectory of %A_WorkingDir%, and if any overrides are set via the GUI, it saves them to this location?

The effect would be that current users could download and double-click EPKL.exe just as they do now. If they currently drag and create a shortcut of EPKL.exe somewhere, the default "Start In" field is the same directory as the EXE, so again it works just as now. In fact, because of the SetWorkingDir %A_ScriptDir% line, there is no reason any current user would ever change the "Start In" field for an EPKL shortcut because it would have no effect.

However, with a change like that, should an admin put the EPKL application folder (with all it's defaults) in %ProgramFiles% or %ProgramData% and create a shortcut in the start menu with a modified "Start In" field of %AppData%, then all users starting from that shortcut would get the default settings and any adjustments they made/saved in the GUI would be only for them in their profile. Any updates would use their previous, personal overrides. You would effectively have a machine "install" of EPKL so all users could try different keyboard tricks without needing to download anything, nor affecting any other user's personal settings.

If you can easily make this change, that seems like a win-win to me! At that point, I would be interested in building/maintaining a Chocolatey package for EPKL so more folks could discover it and/or try it with confidence knowing that they can easily remove it as well. (I have some experience with that already.)

Thanks!

[DreymaR]

If you'll help make EPKL chocolatey, that sounds great! I've been thinking of getting it on PortableApps as that's where I use it today, but I haven't done it yet.

What you're requesting is a way of keeping the user data dir separate from the program dir, right? That'd be nice for PortableApps too! It shouldn't be too hard I hope. I use a "LayStack" that looks for info in the sequence layout file → baselayout file → override → default; only the two last levels are read in initially, to determine the rest. It'd be entirely possible to keep the override in the user folder, and if users want to use their own layout and/or baselayout files those could be there too I think. Interesting idea.

So basically... look for default files in scriptdir, make and read override files in workingdir. Then, allow a syntax that lets users choose whether the layout folder is in one or the other...?

[teknowledgist]

Something like that.

I'm not going to pretend to understand how it all works, but the gist of the question is about adding the ability to split the files containing settings into "defaults" that determine what a new user starts with (and that is probably protected from modifications by non-admins) and "customizations" that any user can apply to only themselves. That model is very common in the Windows world (which is what I'm most familiar with). At the same time, I don't want to alienate current users who are used to an entirely portable, download-and-go product.

I'm envisioning that Chocolatey would act much like an installer. As long as I know which setting sits where, I can offer (the most common) install parameters to allow users to have certain defaults before the program is ever started.

I am not (yet) a Colmak user, and that is mostly because I'm touching different machines all day and Colemak isn't included with Windows. I've been interested in playing with EPKL because of that, but when I find something interesting that doesn't have a Chocolatey package, I feel compelled to try to make one.

[DreymaR]

The original PKL was designed to run in two main ways: The usual way, and compact mode which means keeping all necessary files in the same folder as the program file – typically chucking away all the other folders to save space. I don't even know if the latter still works, as I haven't tested it for ages. I hope it does... but I've had no requests for it.

I've made EPKL easier to run from the GitHub repo by adding the Override files which aren't tracked by Git so they allow users to add their own settings and whatnot and still be able to update EPKL without incurring conflicts. In addition, the Override files felt a bit safer to work with when I made the settings GUI, as people could always chuck away the Override file if something got screwed up really badly.

So I think we're ready for the next step which would be a separate user folder, it's a great idea I think. There are some things still left to add, as some special files like Extend and PowerStrings may not be entirely overridable yet. I'll look into it.