Hi Ken,
one of my posts in this thread had been a complete rewrite as well. In my case it was Notepad++ crashing (for the very first time, so I was only drafting but never saving lol)
Your asking interesting questions. But before adressing them I would like to drop some general words about the script implementation and its XY "hosting" context. This also may help to clear up any misconceptions before they arise (the ghost of my very recent experience speaks through me..
).
1. XY and scripts
My XY script - as well as all others in XY - doesn't just sit somewhere in the background and waits for its menu button to be clicked. It's the other way round: XY is the master, XY captures all the user events like mouse-clicks, key shortcuts etc. and triggers all actions registered with them.
What happens if the LM user button is clicked?
The script(s) is run - and once the menu (or any other derived popup) is closed, the script run is over. So, each menu open/close event is associated with a complete script lifecycle (just like a XY session being started and finally closed by hitting 'X')!Everything you see in such a menu lifecycle is done on-the-fly. Each time, the whole menu setup is "generated" from scratch based upon the saved ini-data (and one global variable I'll come back to soon).
The same principle applies for loading a layout (be it py picking a named favorite or via the load popup). Each time, the script reads the entire property set from the ini, then checks every single one against its corresponding state in the running XY host application. And only if
To-Be is different from
As-Is, the XY state is changed (the comparison is required, because in XY the script commands to hide/show gui elements I'm using aren't real switches with freely adressable ON/OFF-states, but toggles with strictly serial ON-OFF-ON-OFF-logic: e.g. F8).
And what's in between those open/close cycles? There simply is "no LM script" at all!
2. LM and XY application state(s)
You remember, the script is dead once the menu is gone. Therefore it should be obvious that for a script there is no means to "monitor" any XY state changes and react to them in real-time - for instance, by marking a layout as "changed, but not saved yet" or doing a sort of autosave. The autosave stuff is completely governed by the user via XY's settings-handling settings!
Now, let me turn to your questions.
klownboy wrote:I'm not totally sure what you meant by a "layout switch", each and every change to a layout attribute or a switch in layouts via Layout Manager?
A layout switch is happening when the
To-Be/As-Is property comparison results in at least one difference. Just make a test: Save any existing layout under a new name and apply them alternatingly. What do you see? Correct, nothing happens on the gui, even the counters remain unchanged -> no layout switch. It's just the same thing having to different names.
klownboy wrote:One question though, currently (as of version 0.6 alpha), you are not saving layout attributes each and every time a person makes a layout change (without a save in Layout Manager), are you? Don't you simply save the the layout changes to layouts.ini when a person saves the layout or saves one as a new layout?
You're completely right, a layout save is only triggered via "Save Layout" or "Save Layout As" (because of 2.). But note: In contrast, the ini General settings are saved/updated (almost) every time the script is run (menu open/close)!
klownboy wrote:If that's the case, wouldn't it be cleaner to somehow (I'm not a coder) flag the current layout (i.e., the layout with the golden star) when it is changed or saved so it can be addressed later, rather than coming up with a "last layout".
Good question. Have been thinking about that, too. My first conclusion was: No change marker.
The reasons weren't technical, but conceptual in the first place. To me, a layout is just a batch-shortcut, a quick way to setup the gui as I need it. So I have set up a basic set of layouts to cover a useful range of starting points. In my notion - though I know I do - I don't "feel to change" a layout once I modify a loaded layout (for instance, TreeXPane by hitting F8), I'm rather creating a new one (XPanes, for example). Do you know, what I mean?
But after reading my last sentence over and over again, I see the logical conflict in "conceptually a change isn't a change".
From the user's perspective you would find an asteriks a meaning- and helpful add-on for daily use?
The "lastlayout" is a different beast. Why a lastLayout-Property or the golden-star phenomenon?
In my first sketches, the "golden star" was supposed to simply mark the last picked/loaded layout, independent from it being "changed" in XY but outside the script scope later on. I simply defined a script variable holding the name after the "layout switch", the rest is just matching names. This also means, by now there's no "smart" layout detection logic involved at all. As a side note: Now, I see why the term "current" layout can/will be misleading.
After the lines of code became more and more I decided to split the script into pieces to reduce heavy mouse-wheel scrolling. Now, technically I faced a problem. The entry script builds the menu, but the layout application is done by a second script file triggered from the first script. So, how should the first menu script know, what layout have been picked during the last script runtime? My luck, XY's script engine has a concept of "permanent" variables, which comes in two flavors.
Flavor one means, it's a variable global to the XY session. You can reference it in as many scripts as you like. As long as all those scripts are run during the same XY session, they will all "see"/share the same variable value (e.g. $name = "Filehero"). Fine, my original problem was solved. The second flavor comes in the game, when you activate F9/Advanced/Remember permanent variables in XY. Now the value even survives sessions.
I'm sure, you already know what I'm after. In my XY standard usage scenario my "lastLayout" persistence is provided by XY. When I open a new XY instance, the permament variable previoulsy saved with its last value is read from XY's dat-files and "passed" to the script runtime again. So, during development I always saw "Plain" golden star-red. But since I completely share your view that the user is the only authority about how XY's settings should be handled, I had to implement my own "Remember permanent variable" - "lastLayout" was born.
Oups, what an epic writing...as much fun as scripting(*), I guess.
klownboy wrote:Sorry for being so wordy
ahem....
Thanks a lot for your valid input and interesting discussion! It's always astonishing how focusing on things (which is a good thing per se) can easily turn into a sort of tunnel-vision when overdone.
I'll think I have to revisit some stuff, especially the 'golden star' appears to require another stringency and consistency check. I'm not sure about the asterisk change mark.
But other things (making the current version stable) will have to come first.
Cheers,
Filehero
*: Had to be canceled for today
But it will come this week. 
My fault, I should have saved a draft. Here goes again.
XYplorer Beta Club