Bridge: Ability to export folder listing to text file

app.system(commandLine)

Yes but not directly from within Bridge. You'd have to already have the script written. And it works differently on the two platforms as I'm sure you know.

Plus you still need a way to find paths. Most people don't know how to figure out the pathname they want.

There is a reason that command lines are buried. We aren't in 1982 anymore.

"It works differently on the two platforms..."  Anyone using the Photoshop suite on Windows isn't doing serious design work.

Seriously? That's an ignorant comment and I'm a hardcore Mac user.

A lot of people use the tools that their employers choose to purchase. And Bridge is used by people other than designers.

It's apparent that you are just a troll so please stop commenting and go bother someone else.

You'll be master if you do the same with Stacks (incl. subfolders that would be equivalents of another placed elements / layers of Photoshop Smart Objects) so you'll be like Paul Riggott :D

app.document.presentationPath returns null for folders with expanded subfolders. No idea why, not sure if its a bug.

Just added code to list stacks at the top of the exported file.

---------------------------------------------

/*
FolderListExport created by David M. Converse ©2018
www.lumigraphics.com
Last updated 8-1-2018

This script uses Extendscript and ScriptUI to save a text list of the currently selected folder or collection in Bridge.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/

#target bridge
if(BridgeTalk.appName == 'bridge'){
    var newCommand = new MenuElement('command', 'Export Folder List...', 'at the end of Tools');
    }

newCommand.function (){
    FolderListExport();
    }

function FolderListExport(){
    var FileList = [];
    var CollList = [];

    try{
        if(app.document.presentationPath){
            var parentFolder = new Thumbnail(app.document.presentationPath);
            }
        else{
            alert('Expanded subfolder listing is not currently supported, sorry.');
            return;
            }
        app.synchronousMode = true;
        parentFolder.refresh();
        if(parentFolder.container){
            FileList = parentFolder.children;
            }
        else{
            CollList = app.getCollections();
            for(var j=0;j < CollList.length; j++){
                if((CollList[j].name + '.filelist') == parentFolder.name){
                    FileList = app.getCollectionMembers(CollList[j]);
                    break;
                    }
                }
            }
        if(FileList.length == 0) return;
        fileWriter(FileList, parentFolder);
        app.synchronousMode = false;
        }
    catch(e){
        alert('List not saved.');
        return;
        }
    }

function fileWriter(FileList, parentFolder){
    var logPath = '';
    var logFile = File(logPath);
    var listing = '';
    var numHidden = 0;
    var txtHidden = '';
   
    try{
        numHidden = FileList.length - app.document.visibleThumbnailsLength;
        if(numHidden != 0){
            txtHidden = ', ' + numHidden + ' Hidden';
            }
        listing = parentFolder.name;
        if(! parentFolder.container){
            listing = parentFolder.name.split('.');
            if(listing.length > 1){
                listing.length--;
                }
            listing = listing.join('.') + ' Collection';
            }
        logFile = new File('~/Desktop/' + listing + '.txt').saveDlg('Create New Log File', '*.txt');
        logFile.open('w:');
        if(parentFolder.container){
            logFile.writeln(parentFolder.spec.fullName);
            }
        else{
            logFile.writeln(listing);
            }
        logFile.writeln(app.document.visibleThumbnailsLength + ' Items' + txtHidden + '.\r\r');
        for(var i=0;i<app.document.stacks.length;i++){
            logFile.writeln('Stack ' + (i+1));
            for(var j=0;j<app.document.stacks[i].thumbnails.length;j++){
                logFile.writeln(app.document.stacks[i].thumbnails[j].name);
                }
            logFile.writeln('-------\r');
        }
        for(var i = 0;i < FileList.length;i++){
            listing = FileList[i].name;
            if(FileList[i].container){
                listing = listing + ' (Folder)';
                }
            if(! FileList[i].hidden || numHidden == 0){
                logFile.writeln(listing);
                }
            }
        logFile.close();
        }
    catch(e){
        alert('Could not save listing.');
        return;
        }
    }

Another task for you (however it's little off-topic as not strictly refered to your idea):

I noticed when you have for ex. files (let's say .jpg's) in the same folder like:

a, b, c, d, e, f, g, h


and you will make 4 stacks from certain pairs in this order:

a + b
g + h
c + d
e + f


then making a loop over them they will be read by date of creation. So quite the contrary than with single files or folders. Can you change this behaviour they will be read by a loop alphabeticaly, so:

a + b
c + d
e + f
g + h



I'm not sure you answred to this but nasted folders / stacks in stacks are not added to list of .txt file.

I never use stacks so I don't see stuff like this. I'm reading an array of stacks and each contains an array of thumbnails which are the files in the stack. The stack objects don't have names so they can't be sorted. [array.sort()]

There is a similar problem with collection lists, they are stored on disk by uri and the array can't be sorted so files are listed out of alphabetical filename order.

And I'm not sure how you do nested stacks?

That's the problem, they don't have names untill we don't consider the first file / folder in a stack for their names. That's default and can't be changed other way than promote other file / folder in the same stack. That doesn't change fact stacks are still not read by names in a loop but by a date.

I asked if you maybe know some method to omit it as if we had many stacks and single files/folders in the same folder then unfortunately in some cases there's need to compare all stacks to selected thumbnails to ensure which of them are stacks. If we could do it alphabetically then entire process would be faster. I know you don't know what I'm talking now about, but mainly I was curcious can selected stacks be stored to an array alphabetically. Like you say they are objects, not names, so it seems we can't. Because we can't access directly these objects we have to read name of first file / folder in all stacks that makes we loop them like regular array.

Regarding collections I never used them, but I believe Br team could make some things simpler.

Nested stacks are like folowing example shows:

top stack: some file + some folder
next stack can be nested in that 'some folder'

and so on; whenever you want to imitate smart objects or fodlers with contained subfolders / files you can put to every deeper 'some folder' nasted in certain stack another subfolder that grouped with other file(s) or/and folder(s) makes nasted stack. This way we can reflect .psd smart objects.

They would exists as structure of flattened .jpg's.

Interesting, I never have used stacks but I use collections at my day job.

app.document.stacks returns an array of stack objects. Each has thumbnails array and read/write properties array. I suppose you could add a property to sort by and then use array.sort() to arrange the stacks array.

Or create an array variable to store the objects and order them by your custom property.

I'm trying to keep this simple and have no need to dive into stacks but feel free to add to my code above if you'd like.

Interesting, I never have used stacks but I use collections at my day job.

app.document.stacks returns an array of stack objects. Each has thumbnails array and read/write properties array. I suppose you could add a property to sort by and then use array.sort() to arrange the stacks array.

Or create an array variable to store the objects and order them by your custom property.

I'm trying to keep this simple and have no need to dive into stacks but feel free to add to my code above if you'd like.

Okey, so far I used app.document.stacks and acessed files from thumbnails array. It seems you're more experienced as you suggest something special I could do, that is add property to that object holding array of thumbanils. So then following you I could sort them. Could you tell me how to add that new property I would use them to sort stacks?

Bridge CC 2018 JavaScript Reference page 40 has the documentation. Arrays are addressed by index.

app.document.stacks[i].properties[j] = foo;

where foo is your custom value.

i would determine which stack, and j would let you address elements of the properties array (arrays are zero index.)

You have to figure out how you wanted to sort things and then create a custom value foo that would be in that order. Then maybe have another array k to hold that sort order.

So if you wanted the custom order to be 4, 6, 1, 3, 2, 0, 5 store [foo, i]: [0, 4], [1, 6], [2, 1], [3, 3], [4, 2], [5, 0], [6, 5] in k.

The latest JS Bridge reference I have is for CS6 EXTENDED time, and on page 40 there is nothing about it. I didn't know of 2018 version so I wanted to download it, but just read what I just posted in my message:

https://forums.adobe.com/message/9934315#9934315

Can you give me a link to that most uptodate reference, THX!

Now it opens download page, but nothing goes on. Probably there's some other problem I'll find.

Yeah they moved their development resources to that new site. adobe.io

Regarding properties. Probelem is I had to make a loop over all stacks to sort them, and then make another loop over already sorted. That wasn't my intenition, as I wanted to avoid 2 loops, or even one full loop. My goal was to make a loop over already sorted stacks by Bridge, so when I reach some stack that fits my expectations I can break loop.

This way it's better to make loop over all stacks only once, as now I know there is no other way. Bridge does not allow for other solution untill like you noticed I put stacks to an array and sort them by my order before make another loop.

Yeah I'm not sure how you avoid that. If you could read the values during the first loop it would be best, instead of doing so twice. Maybe make a feature request for sorting and naming stacks?

I'm affraid dealing with current settings is easier than expecting Bridge team is going to change that specific behaviuor for stacks or anything. You know good as me there is no chance even for easier and more usefull functionalities many people would appreciate.

If you could name stacks, that alone might fix the problem.

Yes, that would be best option. For now Stacks names are associated with name of first file / folder they contain. That is useless as we don't know which file / folder is first in certain stack array untill we make a loop over stacks. Unfortunatelly we can't also check from file perspective is it in some stack. We can only find all stacks in first instance, and then see their files / folders array. Not in the other order, what makes it's really bad, especially like I wrote earlier there's no way to call some thumbnail to check if that's item of some stack, before we weren't called some stack to see what are its thumbnails.

btw I noticed '.container' is usless in Bridge if I'm right. You can use directly '.children'

So when actively selected thumbnail is a folder it gives array of content, but if a file then just undefined without error. I know you probably do it for readability.

Similary it is with '.children.length'. When it's folder with conent you get length of it, but if it's a file then you get the same result as that would be empty folder, so 0.

Both doesn't need to use try...catch statement.

Using .container lets you know if it is a folder. so if(thumbnail.container) tells me if it is a file or folder. A folder can be empty.

And using a catch statement lets me deal with cases like the Desktop, which throws an error for presentationPath. Its also easier to debug, I can add an alert (e + e.line) to tell me what broke.

I could list content an alternate way- wait until it loads, select all, then loop through the selected files and write the name of each one. That's actually almost as fast as what I'm doing now. However, if a folder is partially loaded, there isn't a way to force load it so you get an incomplete selection and export.

Actually yes. There would be no difference if folder was empty. Both file and empty folder would result as 0, so we couldn't know which is folder and which a file. There's some other way to see is our thumbnail a folder. That's less convinient, but shorter of two characters though :)

For example when file / folder is selected:

new Thumbnail(app.document.selections[0]).container

new Thumbnail(app.document.selections[0]).type[4]


For container it's false / true, while for type[4] it's undefined / e.


Regarding sorting stacks I found you can do it by a trick, as all are stored in .BridgeSort hidden by default file. Instead of making first loop to collect all, we can rewrite order of stacks in that file, so visible stacks will not be read by date, but name.

Interesting that they have undocumented sort behavior.

Selections can be either a container or a file, but some folders have buggy behavior. Not sure how much is getting fixed for future releases.