XYplorer Beta Club

admin wrote:... "Search results" tab is nothing but a tab named "Search results". Plus some service added: ... all search results are directed to it

I'm not convinced of that, in the other thread discussing search results I gave an example where I could have two tabs that received the results that were sent to the Search Results tab.

Gandolf wrote:

admin wrote:... "Search results" tab is nothing but a tab named "Search results". Plus some service added: ... all search results are directed to it

I'm not convinced of that, in the other thread discussing search results I gave an example where I could have two tabs that received the results that were sent to the Search Results tab.

Uh, yes, but not in the next version

admin wrote: So, what you are asking for is another special service: make the name "Search results" temporary: automatically lose it when find mode is left (and when it is not locked). Correct?

Given that I don't 100% understand ALL the implications/ramifications of "locked", the part that I do say to correct to is "lose it when find mode is left", since at that time, tab with title SR could not possibly contain any SR.

Now about the locked...does that lock the contents or just the title or both? Because IF title is locked yet contents change to user clicked tree folder, there likely should be some indication, other than tab icon change, that title is incorrect...not sure exactly how or what though...what might be possible? A RED file folder instead of yellow?

The reason I don't lock the SR tab is that sometimes I don't want it visible so to close it, I have to unlock it and then close. Possible solution option: Cntl+Shift+W to close a locked tab if viewing it?

j_c_hallgren wrote:Now about the locked...does that lock the contents or just the title or both?

Locked means you can't change it's location (and for a tab in search mode, it will just stay that way); clicking on a folder in the treeview will open a new tab.
BTW "lock the title" doesnt really "mean" anything, as a tab's title isn't linked to anything but the tab, I mean it doesn't matter what location the tab is in. So if you rename a tab "New music files", "My working tab" or "Search results" it will be the tab's title, no matter what location or even mode it's in; no matter if it changes or not either.
It's up to you to remove it's title if you don't think it's appropriate anymore. And you can do that with the SR tab aswell; if you've made it showing a folder & think it shouldn't have that title, rename it and leave it blank, it will then get its location as title.

j_c_hallgren wrote:The reason I don't lock the SR tab is that sometimes I don't want it visible so to close it, I have to unlock it and then close.

Actually, when you try to close a locked tab XY will ask you: "It's locked, close anyway?" Just say yes and it will be closed

Jacky, I'd like to thank you for descrip of locked! It helped clear up some misconceptions I'd had...and given that I wrote that post around 4:30am, just before bed, I wasn't thinking 100%, and didn't take the time to try some things further.

Ok, so back to the issue...thus, IF a SR gets locked, it wouldn't be able to have its contents changed (via tree click, etc) so SR title would still remain as correct. But while it's un-locked, contents might become non-SR, so a title chg would be needed, IMO.

And you can do that with the SR tab as well; if you've made it showing a folder & think it shouldn't have that title, rename it and leave it blank, it will then get its location as title.

Agreed! My wish was to make that process the standard operating process for SR tab.

j_c_hallgren wrote:Agreed! My wish was to make that process the standard operating process for SR tab.

Yeah I understand that, but the thing is because the SR tab is nothing but a tab with a title, and since titles aren't lost/changed when tabs change locations (or modes) it probably cannot be done.
Or, it would be another special behavior: When changing to file mode (so if not locked) a tab named "Search results" would "loose" its title... Could be confusing though that a tab named "Search results" would loose its title, while another tab in search mode too named "my results for smthg" would keep its title even when going in file mode....

and since titles aren't lost/changed when tabs change locations

Hold on a second...whenever I bounce around in the tree, the tab title changes to that path name. I thought that was standard operation for unlocked tab.

search mode too named "my results for smthg" would keep its title even when going in file mode....

Ok, BUT the major difference is: that title was CUSTOM created by user, so user would be responsible for knowing what contents are...and icon changes from folder to stacked pages or reverse when in file vs search mode as I see it.

Because when I'm in SR tab looking at results and then click on a tree/folder, the tab icon reverts back to folder so from that, I have clue that it's no longer SR, but don't see the folder name to match it.

j_c_hallgren wrote:Hold on a second...whenever I bounce around in the tree, the tab title changes to that path name. I thought that was standard operation for unlocked tab.

Yes, sorry i meant custom titles dont change, and the SR tab is just a tab with a custom title.

j_c_hallgren wrote:Ok, BUT the major difference is: that title was CUSTOM created by user, so user would be responsible for knowing what contents are...

Yes, but as it's been said before: the SR tab is nothing but a tab with a custom title, set automaticly by XY if it didn't already exists (cause someone could do a search & manually rename the tab "Search results", it would then be the SR tab aswell)

and the SR tab is just a tab with a custom title.

Not quite.
It has one special feature: That IT can be specifically selected as output from a find operation, no matter which tab you're on. No other tabs are similar. Yes, you can say current/new, but those then get "correct" titles as needed. We're making this too involved...When you reuse SR tab for another function (file mode), the custom title SR becomes invalid. Thus, having it adapt the new path as title makes the title valid.

j_c_hallgren wrote:

and the SR tab is just a tab with a custom title.

Not quite.

Quite! There is nothing special about the SR tab compared to other named tabs: the name stays regardless of the location. That's the idea of naming it.

I think what confuses you is the little automatic naming service XY provides. Without it, the situation would be like this:
If you rename a tab to "Search results" AND choose "Search results" as target tab for search results then the target tab of search results is "Search results"
The naming service: XY does the renaming to "Search results" for you if necessary. That's all.

Doing what you want would be adding yet another rule: the name of named tabs stays regardless of the location, UNLESS the name is "Search results". That would be weird...

Or maybe this helps: the tab title "Search results" is not a category as e.g. "File list", but a name as e.g. "John".

There is nothing special about the SR tab compared to other named tabs: the name stays regardless of the location. That's the idea of naming it.

Let me try again: Yes, while I do basically agree there is nothing special about SR tab, there actually is something "special": And that is ->No other tab is SPECIFICALLY named as one of the three output choices from a search. The other two are generic functions (Current/New).
And IF there is no tab at time of search named SR, and that is desired output tab, a tab with that SPECIFIC name is created, true? And IF tab SR exists, then no matter what location it's in, it SPECIFICALLY gets the output, true? So those properties make it "special" it would seem.

Doing what you want would be adding yet another rule: the name of named tabs stays regardless of the location, UNLESS the name is "Search results". That would be weird...

Location of tabs, whether it be left, middle, right, whatever has no relationship to this topic. And keeping/changing the name of tabs in this topic, as far as I'm concerned, ONLY applies to the SR tab, no other ones.

When SR tab contents are no longer SR, due to other user activity, then SR name is obsolete. That's the entire issue.

j_c_hallgren wrote:

Doing what you want would be adding yet another rule: the name of named tabs stays regardless of the location, UNLESS the name is "Search results". That would be weird...

Location of tabs, whether it be left, middle, right, whatever has no relationship to this topic.

With "location" I mean their current path.

OH! Terminology used differently can definitely cause confusion...
To me, location was where tab was on screen along that row compared to other tabs...and contents was more what it was pointed to and/or contained...but now I understand that you use location for path/folder...fine! Sorry If that caused part of the misunderstanding, ok?

No matter, this scenario still remains: Once a user does something to cause contents of SR tab to become non-search results, that one specific generic name becomes obsolete/confusing as it doesn't reflect that reuse, ok?

And when I reuse the SR tab for a selected path somewhere else, the hover tip name changes to the new path, so why not just get the SR tab name to match? So that way it's visible without having to hover. You reset the icon back to a folder from stacked, so that's my only clue right now that it no longer is truely SR.

Coming back to this (after some nights of sleepy meditation).

(a) I admit that for newbies it's confusing that a tab called "Search results" does not contain search results. And most of the people on this planet are newbies.

(b) However, simply auto-removing the name "Search results" from this tab when it quits containing search results has several disadvantages:
- It would be an exception from the rule (there is no auto-removing of names). Especially if a user would manually name a tab "Search results", he would be very surprised by this behavior...
- On the next search, a new tab named "Search results" would be created, so choosing "Results to tab Search results" would be installing a tab-gun (a configuration that creates more and more tabs).

So I propose the following change to the current behavior: When you choose "Results to tab Search results" and a new "Search results" tab is auto-created it will also be auto-locked! Which will make it stay the SR tab as long as you don't unlock it manually in which case you should not be so confused about what started this thread (see (a) above).

As the originator of this item (who is currently a bit tired..it's almost 5am here), I'll give partial feedback for now...

1) Given that IF name "Search results" is well documented and actions related to it also, I doubt a user would intentionally rename a tab to that.
If they did, they shouldn't be surprised IF they read any of the docs.

And auto-renaming of tabs is basically what happens on "normal" tab when you go somewhere else, so that behavior is typical.

2) A tab-gun would not happen as a new tab is only created when no SR tab exists, so at most the one SR tab would be created. Now IF I then renamed it to, let's say "SR-xx1", then I'm doing so to preserve that tab and force creation of a new SR on next use with same option. Because if SR exists, then it would be re-used. Correct?
It's less tab creation than if user kept asking for "new" tab, but then, that user REQUESTED each new tab...they don't just keep automatically appearing like porno pop-up ads!

3) I'll defer comments on lock until I think about it more clearly...but it sounds sensible at first glance...not 100% sure yet.