[WFX] VirtualPanel: Temporary panel for TC

[sgp]

I tried to test it on XP but strangely TC didn't cache thumbs at all, even in physical folders (thumbs file didn't changed, don't know why, caching is seems to be enabled).

But then I tested it on Win7 (Win7x64, TC8.01x32), all work fine, TC uses same cache ids for both physical and virtual items so after caching any of folders (physical or virtual one) both are loaded immediately (tested on folder with 300+ JPGs).

Funny, it seems for me it's just the opposite, cache on Win7 and no cache on XP. There must be some reason. Possibly there's something weird going on with TC's caching mechanism, regardless of your plugin. BTW, thanks for posting this version, I'm sure we'll make it work with thumbs eventually.

[MVV]

Funny, it seems for me it's just the opposite, cache on Win7 and no cache on XP.

For me it caches under Win7 and I can't check it under XP because of strange thing.

[sgp]

On Win7 it takes 4-5 seconds to display each single thumb (400x176) and each time I leave the VP tab and then go back to it thumb rebuilding starts all over again. Can you please copy here all the *thumb* settings from your wincmd.ini ?

edit: And I just confirmed that on WinXP everything is fine; thumbs build at a rate of 4-5 / 1s and they're properly cached and redisplayed. I am running TC from a USB key, so it's exactly the same configuration and files and cache. I guess the difference is in the way TC calls into the different operating systems.

[MVV]

Have you tried to use clean wincmd.ini? It works fine for me with it. I have no any special settings for thumbnails since I'm using brief view mode in 99% cases.

Just tested it again in virtual Win7x64 with TC8.0b1x32 and clean INI (only added VP for test), after caching physical folder TC loads thumbs in virtual one immediately, also after switching tabs.

[sgp]

Have you tried to use clean wincmd.ini?

OK, I found the issue. My setup enables showing custom fields below thumbnails, and one of the custom fields misbehaves by greatly slowing down thumbnail creation on Win7. In WinCmd.ini:

Code: Select all

ThumbsCustomField=[=tc.comment]
ThumbsCustomField=[=ntlinks.Obj_RealPath.Symbolic]
ThumbsCustomField=[=tc.comment] [=ntlinks.Obj_RealPath.Symbolic]
  ^^^^^^^^^ previous three lines work fine
     next three lines slow down thumbnails vvvvvvv
ThumbsCustomField=[=filex.Group]
ThumbsCustomField=[=filex.GrandPaDir:7-99]
ThumbsCustomField=[=tc.comment] [=filex.GrandPaDir:7-99]

For now I'll stick to using [=tc.comment] only.

[MVV]

Great that you've found it.

[sgp]

Hi again MVV, is <export capable of exporting only the selected items? Or can selective export be done in some other way?

I already have an existing cmd.exe script that processes TC's %L file, now I want to make a new button, select virtual objects and click the button to pass real files to my script. If the new button parameter was %L, the list would include selected virtual paths, not good. If the button command was TCFS2.exe ^export outlist.lst . the list would include real paths but of all objects, not just the selected ones.

I do have a solution already coded, but it's cumbersome and slow and I want something simpler and more native. This solution enables a specific custom column set in the VP, copies all details of the selected objects to the clipboard, and parses the clipboard to extract real paths from file details (one of the columns includes a content plugin field to retrieve the real path). Isn't that ugly.

I don't know if the plugin interface allows to do what I'm asking for. In case it doesn't here's an idea of how to use %L plus a new VP command that you'd need to code here's how it would pan out.
With %L we get the selected virtual paths into a file, say Vpaths.txt. Then with TCFS2 we give that file to a new VP command, say <lookup Rpaths.txt Vpaths which creates the list of real paths in Rpaths.txt. What do you think?
Or it could be done as a new filelist parsing option of <put, something like this: <put /lv \temp\Vfolder Vpaths.txt <export Rpaths.txt \temp\Vfolder <del /d \temp\Vfolder Here <put has a new option /v which tells it to parse Vpaths.txt as a list of virtual objects (so it does an internal lookup like <lookup would). I think this second implementation is acceptable, although it's more complicated than <lookup from a usage standpoint and it's also somewhat hidden, while a new <lookup command would do more justice to a new feature like this. What do you think?

[MVV]

Hi again MVV, is <export capable of exporting only the selected items? Or can selective export be done in some other way?

No, there is no public way to get selection.

You can use some kind of srcipt that exports files from current folder via <save command and then exports selected names via %L and then matches names from TC filelist with names from VP filelist lines in order to get real paths.

Maybe I'll add some command to convert list of virtual names to list of physical ones. It seems that TC won't allow to get list of physical names for a long time...

[sgp]

You can use some kind of srcipt that exports files from current folder via <save command and then exports selected names via %L and then matches names from TC filelist with names from VP filelist lines in order to get real paths.

Yes, I've got something sketched out, conceptually it isn't difficult, but I ran into some limitations already, can you please advise me. Here's the sketch - it's missing the CMD.exe workhorse script but you should still get the idea

Code: Select all

; either use ansi encoding /a and don't debomize or no /a but later must convert UTF16-LE-to-UTF8-NOBOM (because of the tools I plan to use in CMD.exe script)
<save /a c:\temp\x.vp "%${}Path%"
; saved as relative paths; matching will be problematic and unreliable, need absolute paths but how to get them?

<exec \System\TCFS2.exe /u- /ef tem(em_VP_selection_to_listfile)

[em_VP_selection_to_listfile]
cmd="%COMMANDER_PATH%\util\VPsel2lst.cmd"
param=""%L""
tooltip="V>P export selected VP object paths to real listfile"

So when I started coding VPsel2lst.cmd I realized that the BOM mark is an issue for the unix-like tools I want to use (cut and grep) because they can only deal with UTF8 NO BOM encoding. Another issue is that accurate matching needs absolute virtual paths but <save seems to export relative paths onlly.

Maybe I'll add some command to convert list of virtual names to list of physical ones. It seems that TC won't allow to get list of physical names for a long time...

Please do

[MVV]

Another issue is that accurate matching needs absolute virtual paths but <save seems to export relative paths onlly.

Why? You have list of names like:

Code: Select all

1.txt
2.txt
etc.etc

And you have exported list with contents like:

Code: Select all

00002C20	01CD6B41 630CCDC8	\1.txt	D:\1.txt
00002C20	01CD6B41 630CCDC8	\2.txt	D:\2.txt
00002C20	01CD6B41 630CCDC8	\3.txt	D:\3.txt

So in order to get real path for 1.txt you need to add prefix "\t\\" (tab character and backslash) to it - "\t\\1.txt" - and find a line from second list with such string, and then split it into substrings using '\t' character as divider and get the last substring with "D:\\1.txt" (characters in red are escape sequences).
So you don't need full absolute paths at all, it is a redundant information for such task.

[sgp]

You're right I guess. I got confused because I thought that VP supported branch view so there could be multiple objects by the same filename. But since VP doesn't support branch view this is a non-issue.

So, I drag-drop this real folder structure onto VP virtual folder \test

c:\temp\b./
c:\temp\b/2.txt
c:\temp\b/1.txt
c:\temp\a./
c:\temp\a/2.txt
c:\temp\a/1.txt

and run this script from virtual folder \test\b

Code: Select all

<save /f C:\temp\x.txt %${}Path%

x.txt holds

00000420 01CD85C4 87D5B789 \1.txt c:\temp\b\1.txt
00000420 01CD85C4 8B1153D3 \2.txt c:\temp\b\2.txt

while %L holds

\\\Virtual Panel\test\b\2.txt
\\\Virtual Panel\test\b\1.txt

Match \\\Virtual Panel\test\b\1.txt to \1.txt in x.txt column 1 to get c:\temp\b\1.txt in column 2.
So I think the way to match is to take the filename part from %L, prefix <TAB>\ and look for <TAB>\filename in x.txt (like you said).

BTW, I noticed the undocumented /r flag in <save and ran this script from virtual folder \test

Code: Select all

<save /fr C:\temp\x.txt %${}Path%

then x.txt became

00000410 01CD85C4 D11D6060 \a
00000420 01CD85C4 6CF1151B 2\1.txt c:\temp\a\1.txt
00000420 01CD85C4 823538C1 2\2.txt c:\temp\a\2.txt
00000410 01CD85C4 D11C00D0 \b
00000420 01CD85C4 87D5B789 2\1.txt c:\temp\b\1.txt
00000420 01CD85C4 8B1153D3 2\2.txt c:\temp\b\2.txt

Note what looks like a bug, 2\1.txt instead of a\1.txt, etc. Anyway, /r is undocumented
edit: not bug but compact format see below.

[MVV]

Internally <save and <export are processed by same code, only different output formats are used. I can't remember why recursive flag is not mentioned in <save description. As far I can remember <save command should be always recursive (maybe I've changed something and miss that fact)...

Note what looks like a bug, 2\1.txt instead of a\1.txt, etc.

It is not a bug it is a compact export format (new-style filelist), full paths always start with \ while packed paths start with numbers that specify how many characters of previous line's full path reused (file size economy in case of long virtual paths). E.g. theese two are identical:

Code: Select all

\one
\one\1.txt
\one\two
\one\two\2.txt
\one\two-2
\one\two-2\2.txt

Code: Select all

\one
4\1.txt
4\two
8\2.txt
4\two-2
10\2.txt

If you want readable list, use additional flag /o (also this format may be disabled in configuration).

Anyway you don't need recursion flag for your task. TC doesn't support branch view for FS-plugins so only names from current folder may be selected.

[sgp]

Compact format... interesting! Of course, for matching paths I need readable format /o. Thanks

[MVV]

As I said, you don't need full paths, only filenames with slashes (w/o /r flag), just look onto my example (you should also use %F instead of %L to get only names w/o paths). There is no format difference w/o /r flag.

BTW compact format is supported since VP 1.0.0.620.

[sgp]

OK, here's the skeleton of a CMD.exe script that converts selected virtual files to real paths. The script assumes:
* batch argument %1 is TC's %L or %F, the list of selected virtual files
* VPBatch.exe and w32 busybox.exe (or equivalent stand-alone unix utilities) are in the %PATH%

Code: Select all

VPBatch ^^silent ^^save /afo c:\LF "%%${}Path%%"
busybox sed -e "s/.*\\/\t\\/" %1 > c:\LF0
busybox tr -d \r < c:\LF0 > c:\LF1
busybox grep -F -f c:\LF1 c:\LF > c:\LF0
busybox cut -f 4 c:\LF0 > c:\LF1
del c:\LF
del c:\LF0
echo selection list is in c:\LF1 (with unix-style line endings)

In this particular case either %L or %F can be used, it makes no difference.