Layouts 2.0

[admin]

Here is an idea for one of the next versions:

I will separate content settings (paths, filters, ...) from form settings (layout, visible features, visible menu commands, toolbar buttons), so XYplorer.ini will be split into 2 files (yes, this has been wished already many times). Panes and tabsets and custom toolbar buttons makes this a little tricky but I will find a way...

Then you can easily save/load such "layouts" (I might include this into the current layout functions). There will be pre-defined "layouts" in the release package and for download, like "simple", "medium", "geek" or so...

One of the fascinating options this will bring is a toolbar button by which you can toggle between a simple and an advanced layout of app. This will open it for non-power users.

[SkyFrontier]

...so users can create and share their layouts? Great.

[admin]

Yes, the idea is to completely separate the look from the contents and save it in a file. So you can share the look without sharing any actual data.

[Stef123]

Great to hear. I also wished for it. It separates content from appearance, similar to CSS and HTM, or styles vs templates in other applications.

Sounds like a bigger project. I hope it won't push other things from your schedule, especially not this one:
http://www.xyplorer.com/xyfc/viewtopic. ... ox#p117943

[klownboy]

For those of use who use SC loadlayout/setlayout, the attributes (e.g., ShowToolbar=0, ShowNav=1,etc.) in the layout txt files are independent of 'content' as it stands currently. In other words the 'look' is separate from contents. I'm certainly not against it, but I'm not sure how / what this will do? Is it more geared towards easier layout changes for new users? Because the features mentioned will be separated, does it mean we can then associate a layout to a particular path(s) and filter(s) if desired? I ask because back when 'layouts version 1' was released some of us were hoping at some point we might be able to tie in location (paths) to layouts. Thanks.

[bdeshi]

@Ken: I suppose the separate layout settings file will also contain [default] column-layouts, thumbnail settings, font options, [default] liststyles etc.
But on the other hand, most of the layout is already exposed to the scripting engine... so, Ken 1 : 1 Don .

I will separate content settings (paths, filters, ...) from form settings (layout, visible features, visible menu commands, toolbar buttons), so XYplorer.ini will be split into 2 files (yes, this has been wished already many times). Panes and tabsets and custom toolbar buttons makes this a little tricky but I will find a way...

Not a bad idea. You can go all the way and separate all the particularly different sections into different inis: ctb.ini, cc.ini, vf.ini, ... , mru.ini...


Also (couldn't help sneaking in a request or two) as long you're digging in that part of the source-code, maybe you'll find a way to get/set settings values in-memory ...

btw, won't this break scripts that work with the ini-structure as it is? Or will you somehow pipe read/writes on current xyplorer.ini to appropriate child-inis ?

[klownboy]

I wasn't in any way trying to be negative, only trying to understand what's coming.

separate all the particularly different sections into different inis: ctb.ini, cc.ini, vf.ini, ... , mru.ini...

Now that would certainly break some current scripts unless there's some type of redirection applied. I'm not sure that would be necessary since you can easily get and change the info in XYplorer.ini file as it is now. Unless the intent is to be able to use multiple ini's like ctb.ini, but even that's not necessary when you can quickly change the content of those on the fly now.

maybe you'll find a way to get/set settings values in-memory

At some point that would be nice.

[bdeshi]

I wasn't in any way trying to be negative.

I know.


you know, I largely agree with you, there's no pressing need at all to venture into this particular feature.
However, seperate inis mean ctb, cc etc becomes far more easily shareable, some settings can be applied without having to save/reset all unsaved ini settings (eg, when a script is just trying to toggle one single key, it doesn't have to make decisions for the user, such as whether to save her yet-unsaved new CC definitions or throw them out). Also, the registration data becomes more "leak-resistant"

[SkyFrontier]

Will this allow to save history, recent locations and/or hotlist into separate .inis?
Long time wish, this one...

[klownboy]

I wouldn't mind in the slightest having to update or change my existing layout text files when moving to Layouts 2.0, especially if in the end they become more powerful.

[admin]

I'm collecting ideas for this, and yes, I think it will become quite powerful. But it won't come before the new preview, and this won't come before summer. And now it's soon time to get poolside ready...

[Stef123]

But it won't come before the new preview

Glad to hear this still has priority. A reliable preview is yet another tickmark off the list of reasons to switch to other tools.

Sharing my own experience with poolside workplaces - get a Panaosonic toughbook - though not waterproof, it is water-resistant enough to use it at the side of the pool. Survives collapsing deck chairs and hits by beachballs.