Tabsets - Small Bugs & Wishes Thread

[serendipity]

Nice..Good to see it's finally implemented. Waiting for tabset mru

Conc. MRU I wonder whether to make a global MRU or one for each pane. Opinions?

I think global, so that I can open a tabset on either pane.
Also, how about "Swap Tabsets" option? like "swap panes" we already have.

[admin]

"Swap Tabsets"...? Hmmm, a bit bloaty IMO.
Store the size of the open dialog... hmmmmaybe.

My idea of panewise MRU was inspired by the unstandable wish (and planned feature) for toggling the last tabset. That would be naturally panewise, right? Now "toggle last" is virtually a special case of an MRU feature, so ...

[eil]

"Swap Tabsets"...? Hmmm, a bit bloaty IMO.
Store the size of the open dialog... hmmmmaybe.

My idea of panewise MRU was inspired by the unstandable wish (and planned feature) for toggling the last tabset. That would be naturally panewise, right? Now "toggle last" is virtually a special case of an MRU feature, so ...

swap could save some time, 'cause otherwise it's: chose another tab set/create a copy; open in panel2 copy/last tabset of panel1; open in panel1 last tabset of panel2...

open dialog just too big(imo), and i'm glad i can resize it, but it doesn't remember it.

as you said now, it sounds reasonable to make mru panelwise, but how will it remember those last tabsets + remember to which panel they were dedicated ? doesn't all non used tabsets are free to be assigned to any panel?..

[admin]

as you said now, it sounds reasonable to make mru panelwise, but how will it remember those last tabsets + remember to which panel they were dedicated ? doesn't all non used tabsets are free to be assigned to any panel?..

The MRU popup menu will be different depending on the active pane.

[PeterH]

Hmm, any better idea anybody?

how about a adding to Templates > Title bar <tabset_name> ?

1. the titlebar might be to small if long paths are involved

As <ini> is the name of the .ini without path, <tabset_name> could be the name of the tabset without the path, i.e. just the folder name? In most cases this would be unambinguous - bad luck for the others. But at least: better than nothing...

[PeterH]

Having read this thread it seams no one saw/reported my problem - so here it goes...

I work *without* "Save Settings on Exit". Before "Tabsets" it was so that after working with XY, then closing and restarting, both panes were shown as I once created and manually saved them. Just a kind of "starting set".

If I see it right, now, after Tabset/New... or /Open... the current tabset (being the one I've started XY with) is overwritten - and my "don't save on exit" doesn't make sense any more!

From my point of view, when "Save on exit" is *not* set, "Tabsets ..." should never implicit save the old tabset. It should only do on explicit requests "Save" or "Save as...".
("Save copy as..." doesn't save the current, and saving the copy is OK.)

Further: for me a tabset would be a starting point for "some business" (like administrating pictures, or PC maintenance). Here it's as before: if I want to administrate foobar-installation, I don't want to start on installation files for motherboard, but on main install folder. So for me tabsets are bases for some work - not saves for what I happened to do last. That is: for me a tabset is static and should only be changed at will.
(Of course I could explicitely save a temporary tabset under a temporary name: good and useful, but as said: only at will!)

[admin]

Having read this thread it seams no one saw/reported my problem - so here it goes...

I work *without* "Save Settings on Exit". Before "Tabsets" it was so that after working with XY, then closing and restarting, both panes were shown as I once created and manually saved them. Just a kind of "starting set".

If I see it right, now, after Tabset/New... or /Open... the current tabset (being the one I've started XY with) is overwritten - and my "don't save on exit" doesn't make sense any more!

From my point of view, when "Save on exit" is *not* set, "Tabsets ..." should never implicit save the old tabset. It should only do on explicit requests "Save" or "Save as...".
("Save copy as..." doesn't save the current, and saving the copy is OK.)

Further: for me a tabset would be a starting point for "some business" (like administrating pictures, or PC maintenance). Here it's as before: if I want to administrate foobar-installation, I don't want to start on installation files for motherboard, but on main install folder. So for me tabsets are bases for some work - not saves for what I happened to do last. That is: for me a tabset is static and should only be changed at will.
(Of course I could explicitely save a temporary tabset under a temporary name: good and useful, but as said: only at will!)

Actually, I had this coded (Save previous only if "Save on exit") but then removed it because I thought users would not understand the relation. I will be put it back.

[Marco]

Having read this thread it seams no one saw/reported my problem - so here it goes...

I work *without* "Save Settings on Exit". Before "Tabsets" it was so that after working with XY, then closing and restarting, both panes were shown as I once created and manually saved them. Just a kind of "starting set".

If I see it right, now, after Tabset/New... or /Open... the current tabset (being the one I've started XY with) is overwritten - and my "don't save on exit" doesn't make sense any more!

From my point of view, when "Save on exit" is *not* set, "Tabsets ..." should never implicit save the old tabset. It should only do on explicit requests "Save" or "Save as...".
("Save copy as..." doesn't save the current, and saving the copy is OK.)

Further: for me a tabset would be a starting point for "some business" (like administrating pictures, or PC maintenance). Here it's as before: if I want to administrate foobar-installation, I don't want to start on installation files for motherboard, but on main install folder. So for me tabsets are bases for some work - not saves for what I happened to do last. That is: for me a tabset is static and should only be changed at will.
(Of course I could explicitely save a temporary tabset under a temporary name: good and useful, but as said: only at will!)

That's almost exactly my workflow. I have "Save on exit" enabled (just in case my work spans across system restarts or similar) but I'd like to imagine a tabset as a base from which start my work, and at end of the day should be revertable to it's original state. Being this technically impossible, this is how I solved:

Code: Select all

$tabset=<xypane>;									//get and store the path of the current tabset
tabset("load","<get pane> - %winver%");	//load my "default" tabset, named "pane_number - major version of operating system kernel"
delete 0, 0, $tabset;							//delete immediately and silently the previous tabset
tabset("saveas",$tabset);					//"clone" the current tabset, naming it as the previous tabset

Let me know if you find this useful.

[PeterH]

Actually, I had this coded (Save previous only if "Save on exit") but then removed it because I thought users would not understand the relation. I will be put it back.

I think the users that don't understand it are those that don't understand (and don't use) "Don't Save Settings". But for those it doesn't matter: they will not see it

And I will be very glad when you "put it back". After that change it will be a very helpful feature for me!
Thanks a lot!

By the way: till now I only thought about it in regards of Menu functions. Next I will have to have a look on the scripting command...

[PeterH]

Let me know if you find this useful.

Sorry to say: I don't exactly understand it.

For me it seems: you load your default tabset, and restore it under the name of previous.
If you now load a tabset, your default is gone?

(PS, after having written the rest of this post:
Looking at it again I see I didn't notice that "Saveas" switches to the new (here: old ) name. That is: you assume that your "current" tabset is what I name "temp". Meaning: the tabset you start XY with is only temp...)

I'd had taken the other way round: after loading a tabset an immediate "Save as dummy" - now a "save" wouldn't destroy the original.
(But the current would always be named "dummy"
and the XY original tabset would always be in risk to being destroyed...)

So I'm convinced that changing the behavior of XY is the best.
After that I can load a tabset "pictures 1" anytime without without any risk, and everything is fine.

[admin]

Did you see the new "loadas" command: it loads a clone of a stored tabset under a new name. Isn't that what you want?

[Marco]

Let me know if you find this useful.

Sorry to say: I don't exactly understand it.

For me it seems: you load your default tabset, and restore it under the name of previous.
If you now load a tabset, your default is gone?

(PS, after having written the rest of this post:
Looking at it again I see I didn't notice that "Saveas" switches to the new (here: old ) name. That is: you assume that your "current" tabset is what I name "temp". Meaning: the tabset you start XY with is only temp...)

I'd had taken the other way round: after loading a tabset an immediate "Save as dummy" - now a "save" wouldn't destroy the original.
(But the current would always be named "dummy"
and the XY original tabset would always be in risk to being destroyed...)

So I'm convinced that changing the behavior of XY is the best.
After that I can load a tabset "pictures 1" anytime without without any risk, and everything is fine.

My whole setup has been this:
1. creating my "default" tabset and saving it;
2. then making an active copy through the command "saveas": this is the tabset where I work, mess around and what not.
When I execute the script I first get the name of the tabset where I work (the "messed" one), then simply reload the default one, delete the messed one so the last operation (saveas) can take place, since the new tabset has the same name of the first one. Yes, I'm basically bouncing between default and messed.
So eventually you understood correctly the functioning of my script. The default never risks anything, because is just loaded and then "duplicated" via "saveas".

Did you see the new "loadas" command: it loads a clone of a stored tabset under a new name. Isn't that what you want?

Yes it is, but consider this:
"saveas" operates on the current (active) tabset and requires a filename as input, which can be given via the script;
"loadas" may require a filename, but will also (in a second phase) popup a window asking for another filename (the name of the "cloned" tabset).
Since I want my script to be totally automatic I have to use saveas.

[PeterH]

Did you see the new "loadas" command: it loads a clone of a stored tabset under a new name. Isn't that what you want?

Do you mean me? Then: no!
(*If* I'm right that loadas saves the old tabset before it loads? I would understand it that way, but am not sure. But I think that command could be useful for Marco's handling...)

That's the difference of thinking if saved values are "current-state", or they are "initial-state".

When I (with saves = "initial-state") start XY, then it starts with a default-initial state, no matter what i messed around yesterday.
And no matter what I do after the new start, (if not *explicit* save,) this "initial/current" may not be changed.

Edit 3 men at work.
But for some time I'll be off for cooking

[admin]

I made a mistake in taking it back ("Save settings on exit"...): Tabs are always written on tab switch (the closed tab is written), even if "Save settings on exit" is OFF! Otherwise the app would not work as expected because certain data like search results cache, tabwise find settings, and tabwise history are stored on disk, not in memory.

Therefore I will have to take back taking it back.

[kiefer]

Are scroll positions of tabs also loaded ?