XYplorer Beta Club

Hi Sammay, I hope all is well. That script is rather cool. One thing I noticed on a few runs is hitting the Dual pane or Toggle Active Pane toolbar buttons did nothing. I assume due to the looping, but I didn't investigate. Hitting Escape, clicking in pane 2, or another tab as you said, did break out of the script and the dual pane and toggle button became functional again.

If one wanted to spend some time on it, you could set it up on a dedicated TB button / Customized keyboard shortcut and taking advantage of the state and have the button changed (state and icon) when it's toggled on and off either by the button or keyboard shortcut. Normally the difficult part would be trying to get the TB button to change when the script is stopped by an action other than hitting the button or a keyboard shortcut like one of the above actions, clicking in pane 2. Though in this case, breaking out of the while loop is done in the script so that would be the trigger. I agree with the others, something like this might make a nice addition for Don to consider.

Hi Sammay, I hope all is well. That script is rather cool. One thing I noticed on a few runs is hitting the Dual pane or Toggle Active Pane toolbar buttons did nothing.

(Thanks. I'm fine busy bee. hope you're all okay too.)
Those actions do abort the script over here. I had edited the post+script after submission. Were you running the latest iteration of the script?
Meanwhile I have buffed up the script quite a bit already, with some config and hopefully better use case handling. I'll post it some time in half a day, maybe you can help test it.

I had some interesting ideas and wanted to see ow it might work as a script, but I'd be rather happy to see this as a native feature myself. This ducktaped script is very finicky with all the manual focus checks, pane flickers etc.

Hi Ken,

I've been using it for many months now

Yeah, me too

It would make a good option for the script - stats on top or bottom.

I've added it as an option...

Here's the better version of the pane previewer I was working on. (Will probably post later in a separate topic.)
[NOTE: latest version of this script is here: viewtopic.php?f=7&t=17968&p=152778]

Highend, thanks for the update for PreviewFolder_v0.6.2. It's cleaner than my hack.

Sammay, you've certainly been busy with the new version with the html based configuration. Very nice.

In testing a number of times, I end up with numerous FolderPanePreview tabs in Pane 2. I do have destroy Preview Tab on exit checked. It seems to happen most when exiting by clicking in Pane 2 (which to me is the easiest and cleanest way to exit). When exiting by Escape it doesn't happen.

I'm not sure what your intent is to initiate the script, TB button or CKS, but when initiated I think it would be best not to have to make a separate click in a menu to perform the pane preview. It might be better to have the preview as the default action of the toolbar button or keyboard shortcut and set up the script to enter the configuration by some other means like only if a mod key is held down (i.e., $mod = get("shift"); if (($mod == 1)) or right click of TB button.

Thanks

Thanks for testing.

klownboy wrote:I end up with numerous FolderPanePreview tabs in Pane 2. It seems to happen most when exiting by clicking in Pane 2

Will look into the issue. well, actually that's intentional. If you click on the preview tab, it's assumed you have seen something of interest there, so the tab remains open. If you click any other tab (header ) on the 2nd pane, the preview tab does get closed. Good candidate for another config switch.

klownboy wrote:TB button or CKS, but when initiated I think it would be best not to have to make a separate click in a menu to perform the pane preview.

Noted. I am in the process of integrating CTB and UDC triggers into the script. CTB left click will preview, right click will open menu or config.

SammaySarkar wrote:well, actually that's intentional. If you click on the preview tab, it's assumed you have seen something of interest there, so the tab remains open. If you click any other tab (header ) on the 2nd pane, the preview tab does get closed. Good candidate for another config switch.

Sorry, I should have been clearer when I mentioned clicking in Pane 2. I was clicking in the white space and now I realize in real world use (as opposed to me just clicking around like a madman), you'd expect that the Folder Pane Preview tab would remain open since it's the currently opened tab. The number of Folder Pane Preview tabs will grow however. Is it possible or does it make sense upon restarting the script, to reuse an existing Preview tab if one exists or close an old one first to avoid multiples. Thanks.

klownboy wrote:reuse an existing Preview tab if one exists or close an old one first to avoid multiples. Thanks.

Great idea, but I couldn't find any sane way to activate a specific tab, surprisingly.
Here's another update that will, among a few other things, reuse an open and already active preview tab on the 2nd pane ("active" being the keyword).

Can you think of any other usability improvements? I've finished most all I wanted to do with this script.

Having some trouble with CTB/UDC integration, specifically with running specific subscripts (either _Init and _Term won't get called or the "appears to be recursive" warning dialog is thrown.) edit: hang on, this might be a bug.

[latest version of this script is here: viewtopic.php?f=7&t=17968&p=152778]

Hey again Sammay, working with tabs can be a bit cumbersome. Could you use something along these lines...determine the FolderPanePreview tab's index with a specific name regardless of status. So you could use the tab's index, if the FolderPanePreview tab is present, to later relocate the tab to the new folder path selected or use the index to simply close it. Added: I noticed that if I initiate the script and I happen to have both panes open and Pane 2 has focus, or if only pane 2 is open or visible, nothing happens other than getting the status bar message, "folder-pane-preview:: exited." Could you change focus to pane 1 and go on from there. It works fine if you initiate with dual pane with Pane 1 having focus or if you have only pane 1 open. Does it not make sense that a user would do that? He may have been looking at pane 1 but simply forgot the focus was on pane 2.

I'd thought about that, but to me this doesn't seem to fit very well with the workflow. On each run of the script, we are concerned with exactly two tabs: the source and the preview. From this viewpoint, closing extra preview tabs feels like it's jumping out of bounds. Besides, with the two new settings to reuse and force-close preview tabs, you should not be left with too many of them. And if you are, the script considers them intentional, as I said earlier, and forsakes any responsibility!

I have to respectfully say that I'm not convinced.

Ok Sammay, not a problem it seems to be working well for me the way you have it. You may not have seen added comment on my previous post.

klownboy wrote:You may not have seen added comment on my previous post.

Had not.

Could you change focus to pane 1 and go on from there.

Of course (sometimes I think blindly ) Will do that.

Well, barring any untested bugs appearances/inspired ideas, this will be final version.
Due to the way the script is structured, CTB/UDC integration is quite iffy. It can be run from these, but not toggled. Read the first run message.
Also, please reconfigure as the config permanent variable was renamed.
Thanks for testing. Hope this helps. [Latest version of the script is here: viewtopic.php?f=7&t=17968&p=152778]


This does a pretty useful job if I do say so myself. @Donald, can you please consider implementing something like this natively as part of Sync Select Sync Browse?

<monologue>I had another script in the back burner, which would have a mechanism for continuously running in the background (like this one) for auto-updating scripted interactions. But as I have so far confirmed with this experiment, XY is not really built with something like that in mind. For starters, <get trigger> is remembered *globally* while a script is running, which apparently interferes with *all other* ctb's interactions. The same goes for UDCs.

Guess I went quite overboard with this. As Don said earlier, the same thing can be done with a simple shortcut to the #1062. But then again, as xy123 said, that can quickly get annoying. I guess I could've avoided a major percentage of the code by just continuously sending that shortcut instead . But the idea of a dedicated preview was stuck in my head, which snowballed into more and more additional micro-features. Anyway, this was an educational experience at the very least. </monologue>

Excellent job Sammay! I totally agree. Don should definitely consider implementing this script. It would make a very nice XYplorer feature.

I know you haven't been spending as much time here lately, but had you seen TheQwerty's script, GalleryWall? He implements a method of keeping a CTB and a Keyboard shortcut in sync in this case he's cycling different thumbnail views. The CTB icon / state is changed when you click the CTB or use a keyboard shortcut. It would seem that 'possibly' the same technique might be used here. It would allow you to have a CTB icon change to reflect whether the Preview pane was On or Off and that CTB icon state also change when hitting the CKS. viewtopic.php?f=3&t=15489&p=135357&hili ... ll#p135382

You should get this in the scripts section.

Thanks,
Ken

Thanks Ken.

Glanced over GalleryWall but I'm not sure it will be any help. Actually folder-pane-preview.xys already does have CTB "hooks" coded in. You can test it too, with some manual nudging.
Set up a CTB like this: And set $P_FOLDERPANEPREVIEW_CONFIGSET's last token (which should be -1) to that ctb's index.

Okay. Now click the ctb to open the preview, and the ctbstate will be updated when the preview is started and when it's over. In fact, you can run the preview from elsewhere (regular scripting, UDC, catalog whatnot). And the associated ctbstate will still be updated!

Nice, right? But here's the real issue: if you start the script from a button, then you can't use that button again to turn it off. (However if started from elsewhere, then the CTB can used normally.)

This is why I've disabled/removed "ctb monitor" code, to avoid unnecessary end-user confusions with a half-baked feature.

My guess is, XYplorer checks if get('trigger') has a value before firing any CTB actions. And when this script is called from a CTB, get('trigger') has a value as long as the script is running.