Scripting function Tabset()

[Borut]

I added this in v10.60.0126. Does it work for you?

I am pretty sure this is what Marco wished to have. On my part, ehmmm, I am almost afraid to ask, but, well, as a suggestion:

Would it be difficult to add the operation "openas", which would do almost the same as loadas, but instead of using parameter "name" which points to the tabset to load, it would present a tabset selection dialog, as the operation "open" does?

Hope this wish does not spoil your day now. It is only a nice-to-have one.

[admin]

Makes total sense to me. Might even add it to the UI... (Open As...).

[Marco]

I added this in v10.60.0126. Does it work for you?

Sure it works. Like a charm
Thanks Don!

[Borut]

Code: Select all

v10.60.0128 - 2011-12-14 14:10
    + SC tabset enhanced. New operation "openas" allows you to select a 
      tabset from a folder of your choice and load it as a clone under a 
      name of your choice. Just like with loadas, no overwriting prompt 
      will appear before any existing tabset of that name is 
      overwritten.

I feel like Santa was already here Wonderful - Thank you! I am now using this simple one liner:

Code: Select all

//opens a clone of a tabset selected from C:\_LocalXyTabsets\ 
// in the active pane under the name <xypane>
tabset("openas", "C:\_LocalXyTabsets\", , <xypane>);

Regarding

Code: Select all

    > Toolbar | Tabsets: Hold CTRL when selecting a tabset from the MRU 
      list to load it as a clone.

This sounds very interesting, but for those that are using tabsets in a manner of Marco and myself, maybe it would be more useful, if MRU would contain both source ("opened") names and destination ("as") names.

Also, I believe that a nice-to-have feature could be the possibility of selecting/changing the base folder somewhere on the open and openas dialogs. (Something for 2012, if you find it a good idea at all.)

BTW, I would say that the current state of XY is ripe for the help updating, home page updating and publishing the 10.70, so that you then finally go to hide somewhere and take some rest!

[admin]

BTW, I would say that the current state of XY is ripe for the help updating, home page updating and publishing the 10.70, so that you then finally go to hide somewhere and take some rest!

Oh yeah, almost there. 10.70 is already looking around the corner, and I'm looking around for a plane...

[admin]

Regarding

Code: Select all

    > Toolbar | Tabsets: Hold CTRL when selecting a tabset from the MRU 
      list to load it as a clone.

This sounds very interesting, but for those that are using tabsets in a manner of Marco and myself, maybe it would be more useful, if MRU would contain both source ("opened") names and destination ("as") names.

This idea is so cool, I had to add it. Very nice! See next beta...

[Borut]

Code: Select all

v10.60.0130 - 2011-12-15 12:02
      Examples for "open":
      // select a tabset in E:\Tabsets and open as "clone1"
        tabset("open", "E:\Tabsets as: clone1");

Cool, thanks! As I wanted to completely separate Tabsets on each of machines I work on (including the tabsets 1 and 2, which I use as "working areas"), I changed my script to:

Code: Select all

$LocalTabsetBase="C:\_LocalXyTabsets";
   $ActivePaneNr=substr(<xypane>, -1);
   tabset("open", "$LocalTabsetBase as: $LocalTabsetBase\$ActivePaneNr");

BTW, watch out not to miss your flight!

[Marco]

Code: Select all

$LocalTabsetBase="C:\_LocalXyTabsets";
   $ActivePaneNr=substr(<xypane>, -1);
   tabset("open", "$LocalTabsetBase as: $LocalTabsetBase\$ActivePaneNr");

Why don't you use directly <get pane> to have the active pane number?

[Borut]

Why don't you use directly <get pane> to have the active pane number?

Because I overlooked that it exists. Thank you!

[Marco]

Why don't you use directly <get pane> to have the active pane number?

Because I overlooked that it exists. Thank you!

You're welcome You save one line, and maybe some CPU clock cycles, who knows... (Don knows, for sure... )

OK, I now have designed a way that should please everybody (even me). It will even allow for a comfy "Revert to Saved" command for any loaded tabset.

It's a bit tricky to implement, therefore I won't be able to do it this year, but you can hope for it in January 2012.

Code: Select all

v10.60.0130 - 2011-12-15 12:02
    * Tabsets: Now tabsets opened as clone via Open As are stored as
      such in the MRU list. Original source name and clone name are
      separated by " as: ", e.g. "work_1 as: clone1". If you select such
      a "clone item" from the MRU list, the cloning is repeated exactly
      as it was done the first time. This makes it very comfortable to
      work with different cloned (effectively read-only) tabsets.
      Tip: If the current tabset has been loaded as a clone then
      selecting the first MRU item amounts to a "Revert to Saved".

Times in Germany flows way fast

[admin]

Times in Germany flows way fast

Well, this is not what I planned for January (which will be real read-only tabsets). But maybe, this tricky read-only stuff is not that important anymore now that we have good and comfy clone support.

[Borut]

But maybe, this tricky read-only stuff is not that important anymore now that we have good and comfy clone support.

Yes, I also think that it might not be needed. I am happy.

[Marco]

I was thinking, now that we have the " as: " syntax, shouldn't the operations "openas" and "loadas" be deprecated and removed?
Moreover, since all the operations (except browse and open) could potentially overwrite an existing tabset, yet there're powerusers who know exactly what they're doing and don't want to be bugged , shouldn't a switch be present (as fourth parameter, a-la http://www.xyplorer.com/xyfc/viewtopic. ... 145#p66335) to be/not be warned of possible deletions?

[I basically summarized all the tabset() things in the attachment, with "loadas" and "openas" stripped out as well as the addition in red. A grand unification attempt]

And finally a technical question: let's suppose I run tabset("load", "work as: 1"). Everything is fine, work tabset is loaded as tabset 1. Now, if I browse (inside XY) to <xypane> and then rerun tabset("load", "work as: 1") I get an error message from Windows (can't read from disk). Looks like the folder containing the tabset 1 gets deleted while still browsed or when it doesn't exist anymore, I'm not sure. Why so? Ok not a big deal but I was just curious.

[Borut]

I was thinking, now that we have the " as: " syntax, shouldn't the operations "openas" and "loadas" be deprecated and removed?
Moreover, since all the operations (except browse and open) could potentially overwrite an existing tabset, yet there're powerusers who know exactly what they're doing and don't want to be bugged , shouldn't a switch be present (as fourth parameter, a-la http://www.xyplorer.com/xyfc/viewtopic. ... 145#p66335) to be/not be warned of possible deletions?

I was thinking the same about "openas" and "loadas" today - there is still time to remove them while it is a beta (a few beta users that have used this have most probably already "upgraded" their scripts, so no trouble to be expected there).

Warnings suppression possibility, like the one by tab("close") - as you are pointing at - would in my view also bring some more uniformity to SC.

Very nice documentation - hopefully in time for Don to make some use of it while updating help.

[admin]

Yes, nice documentation (tabset.zip)! Do you need a job, Marco? The Help file needs an overhaul.

It's true, it looks like I can deprecate loadas and openas. But as the "as:"-syntax is very new (and isn't it revolutionary?!) I will keep the code in place and just don't mention them in the Help file.

Conc. the switch: I had planned a flags parameter anyway (it could also handle the question of saving or not the previous tabset). it's a little late now, but this can be added to the next version.

BTW, I'm a bit surprised that Borut and Marco take such a hardcore approach to tabsets (and seem to switch them constantly in high frequency), and nobody else seems to care. Is this a polarizing feature?