Scripting function Tabset()

[Borut]

Here are actually two wishes:

1. Could the dialog "Overwrite existing tabset?" - which appears when executing the "saveas" operation and the "name"-tabset already exists - optionally be suppressed (under the motto: I know, what I am doing)? (This involves not only the scripting - I do not like it also when invoking it from the toolbar.)

2. Contrary to

Code: Select all

"browse" = Open/Load a stored tabset by browsing the file system. Name is ignored.

I happily noticed that the "browse" operation is indeed taking into account the "name", positioning the tree in the selection dialog to it. That is nice. However, It made me wish the following... Currently the "open" function is defined as:

Code: Select all

"open" = [default] Open/Load a stored tabset from the complete list of available tabsets in <xydata>\Panes. Name is ignored.

Would it be a problem to implement the following extension:

Code: Select all

"open" = [default] Open/Load a stored tabset from the complete list of available tabsets in <xydata>\Panes if name is not specified. 
If name is specified, then Open/Load a stored tabset from the complete list of available tabsets in name.

(I am currently experimenting with a script of the following kind:

Code: Select all

tabset("saveas", "XXX");
    tabset("browse", "C:\_LocalXyTabsets\");
    tabset("saveas", "1");

)

Thank you for consideration.

EDIT: Ooops! Regarding the second wish, it seems it is working that way already, isn't it? Great. Then only the first wish remains.

[admin]

I think "Overwrite existing tabset?" is a good prompt because a lot of work can be permanently deleted here.

I cannot imagine a work style where you very often have to face this prompt. If that is the case, probably something else in the app logic has to be changed.

[Borut]

I cannot imagine a work style where you very often have to face this prompt.

I want to be 100% sure that under no circumstances whatsoever shall my saved definition of a certain tabset be changed. Therefore I have to discard the current tabset and then load/open a chosen tabset in a kind of "working area", so to speak, using (for now) this trivial script:

Code: Select all

tabset("saveas", "XXX");
   tabset("open", "C:\_LocalXyTabsets\");
   tabset("saveas", "1");

I know that you did not want to think much about that paradigm (although probably every document processing application under the Sun uses it). OK, that is the direction you have taken - acceptable.

However, it is the fact of life, that there are XY users that do not use XY tabs like you do, or would like them to (and I am not the only one - you just answered to nony:

Maybe later. Let's see what feedback I get on 10.70 (official release of tabsets).

OK, this is also acceptable.

So, it is possible to create the paradigm I need via scripting (thank you very much for that!!). But, you see, my script has two "saveas"s, so I get that warning two times on each script run (many many times a day).

Maybe this change (optional suppression of tabset overwrite warning) would be "one small step for you, but one giant leap for some of your tab users", to paraphrase Armstrong.

[Marco]

@ Borut:
I'm in your situation. I see tabsets as some sort of immutable configurations, a starting point for my daily workflow, not a snapshot of the workflow status itself. So I first saved all my tabsets and then load them in a "dummy" tabset, called 1 for pane #1 and 2 for the other pane. Here's my script, absolutely warning-free:

Code: Select all

 setting "BackgroundFileOps", 0; //so every following file operation gets executed with proper timing
 $start=<xypane>; //gets the tabset name of the current, dummy tabset (see above)
 tabset("load",$end); //loads the requested tabset, $end is defined elsewhere in the script
 delete 0, 0, $start; //deletes the dummy tabset with no prompts and no recycle bin
 tabset("saveas",$start); //saves the tabset with either 1 or 2 as name, making it active

I can't see further improvements in this code.
BUT, a loadas function which gets two names in input (one for the source tabset and one for its clone name) and with no warnings could be our killer feature. My script would simply become

Code: Select all

tabset("loadas",$end,<get pane>)

[Borut]

Wow, Marco! Many thanks!

I have replaced your line:

tabset("load",$end);

with my:

tabset("open", "C:\_LocalXyTabsets\");

so that I can select tabset at that step via dialog and it seems to function great. I wonder, if there will be some interest in your script in the future (after 10.70 is out).

You have just made my day. Have a nice rest of the day!

[admin]

@ Borut:
I'm in your situation. I see tabsets as some sort of immutable configurations, a starting point for my daily workflow, not a snapshot of the workflow status itself. So I first saved all my tabsets and then load them in a "dummy" tabset, called 1 for pane #1 and 2 for the other pane. Here's my script, absolutely warning-free:

Code: Select all

 setting "BackgroundFileOps", 0; //so every following file operation gets executed with proper timing
 $start=<xypane>; //gets the tabset name of the current, dummy tabset (see above)
 tabset("load",$end); //loads the requested tabset, $end is defined elsewhere in the script
 delete 0, 0, $start; //deletes the dummy tabset with no prompts and no recycle bin
 tabset("saveas",$start); //saves the tabset with either 1 or 2 as name, making it active

I can't see further improvements in this code.
BUT, a loadas function which gets two names in input (one for the source tabset and one for its clone name) and with no warnings could be our killer feature. My script would simply become

Code: Select all

tabset("loadas",$end,<get pane>)

Could you shortly explain why you call the variable for the name parameter "$end"? Maybe the answer helps me to understand what you two are trying to achieve. I'm almost shocked that I so stubbornly fail to make sense out of your tabsets approach...

[Marco]

Could you shortly explain why you call the variable for the name parameter "$end"? Maybe the answer helps me to understand what you two are trying to achieve. I'm almost shocked that I so stubbornly fail to make sense out of your tabsets approach...

I call it $end because at the end I want a particular series of tab on my screen. So simple!
Anyway my (our, I suppose Borut's too) concept is explained quite clearly here: tabsets as some sort of immutable configurations, a starting point for [...] daily workflow, not a snapshot of the workflow status itself.

[admin]

Could you shortly explain why you call the variable for the name parameter "$end"? Maybe the answer helps me to understand what you two are trying to achieve. I'm almost shocked that I so stubbornly fail to make sense out of your tabsets approach...

I call it $end because at the end I want a particular series of tab on my screen. So simple!
Anyway my (our, I suppose Borut's too) concept is explained quite clearly here: tabsets as some sort of immutable configurations, a starting point for [...] daily workflow, not a snapshot of the workflow status itself.

OK; I slowly understand. Should there be an option "Save tabsets when closed" (which you and Borut would turn off)? Wouldn't that be better than unintuitively binding this behavior to "Save settings on exit". (I think this has been suggested already but I have no time now to search for it.)

[Marco]

I thought it was impossible. You said that changes to tabs are immediately written to disk...

[admin]

I thought it was impossible. You said that changes to tabs are immediately written to disk...

Yes, true for find tabs that get unselected AND (the find settings changed OR search results caching is on). Everything else could be kept untouched, which is a lot more than nothing. And the current binding to "Save settings on exit" has exactly the same problem anyway, so while not perfect, the situation would at least not get worse.

But I was more asking out of curiosity anyway. For now I will add this special version of "loadas" so you can make your script a one-liner...

[Borut]

Should there be an option "Save tabsets when closed" (which you and Borut would turn off)? Wouldn't that be better than unintuitively binding this behavior to "Save settings on exit". (I think this has been suggested already but I have no time now to search for it.)

I fully agree that binding this behavior to "Save settings on exit" is obfuscating.

I also thought, as Marco, that it is impossible. And I still do not understand what would this mean for the current tabset, when another one is loaded. If the first one would not be saved, than that is exactly what would suit my workflow (and Marco's, as far as I understand).

Marco's description

tabsets as some sort of immutable configurations, a starting point for [...] daily workflow, not a snapshot of the workflow status itself

could not be better. In my work flow a tabset is the almost never changeable starting situation for working on a particular project.

[admin]

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.

[Borut]

It will even allow for a comfy "Revert to Saved" command for any loaded tabset.

Mhmmmm... sounds good.

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.

I expected this. (I am using tabsets with Marco's script very happily.)

Take your time, rest and enjoy holiday season. Thank you already today for what you have in your surprise store for 2012!

[Marco]

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.

Thanks Don!
And worry for timings, enjoy these upcoming holidays!

[admin]

BUT, a loadas function which gets two names in input (one for the source tabset and one for its clone name) and with no warnings could be our killer feature. My script would simply become

Code: Select all

tabset("loadas",$end,<get pane>)

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