# Listview Plug-In Issues and Questions



## jimburgess (Aug 16, 2011)

First off, many thanks for writing this plug-in. It provides a capability that should have been in LR from the beginning. 

I have some questions and some issues regarding the plug-in (sorry for the length of the post...wanted to be sure to include enough info).

All testing has been performed with Listview Ver. 1.54 running under LR 3.4.1 on a Mac Pro, OS X Ver. 10.6.8.

 (1) When exiting the list view, if there are no selections and the user clicks "Close and select" an error message is displayed:
"An internal error has occurred. assertion failed."
I would have expected list view to simply exit, selecting no images.

(2) Choosing "Smaller thumbnails, more rows" doesn't actually display any more rows. The font is smaller, but there's still only 30 rows -- same as standard.

 Regarding Export:
(3) After initial installation of the plug-in, the default external apps are set to:
Browser: /Applications/Safari.app
Excel: /Applications/Microsoft Office 2008/Excel.app
Safari makes sense since it is the default browser, but Excel doesn't exist on the system. I would have expected the Excel app to be set to Numbers (which is on the system), or set to blank, or set to a message like "No Default Application".
(4) Since the Excel default app doesn't exist, when you perform an export nothing happens as you would expect. But there's no indication to the user that this is the case.
(5) Using LR's Plug-In Manager, set the default browser app to another browser, e.g., Google Chrome or Firefox.
When you export from the List View, the Safari browser is always used rather than the specified browser. 
If you go back into the Plug-In Manger, the default browser has been set back to Safari. So it appears the specified default browser setting isn't being applied, nor it is being remembered.
(6) Using LR's Plug-In Manager, set the default "Excel" app to Numbers. 
When you export from the List View, Numbers is used but an error occurs because the exported format is an html file which Numbers cannot open. Both export options output the same file type, namely html. I would have expected CSV format to be used for the "Excel" export.
Now if you go back into the Plug-In Manager, the default Excel app has been set back to the original default setting. So in this case it appears the specified default setting is being applied, but only for one export. Then it is forgotten and reset back to the original Microsoft Excel setting.
(7) I assume the intent is to produce a CSV file as the output for spreadsheets rather than the html file currently being exported.
(8) When performing consecutive exports, the exported file "List View.html" is being overwritten without warning. What if the user wants to save different output files?
(9) The html export format doesn't seem to be very useful (maybe I'm missing the point). See the attached screen shot...all the values run together making it difficult to read. There are also three superflous column headings to the right of the last column:  "keywords modified2 marked". There's no data in those columns. What are they?

Thanks, more to come later regarding usability.


----------



## johnbeardy (Aug 16, 2011)

Hi Jim

Thanks for the feedback. Apologies if the responses seem a bit abrupt but I hope I'm answering everything and giving an insight into my thinking.

John



jimburgess said:


> (1) When exiting the list view, if there are no selections and the user clicks "Close and select" an error message is displayed:
> "An internal error has occurred. assertion failed."
> I would have expected list view to simply exit, selecting no images.


OK, I consider that a bug - I never thought of someone deselecting all the images. Easy enough to fix.



jimburgess said:


> (2) Choosing "Smaller thumbnails, more rows" doesn't actually display any more rows. The font is smaller, but there's still only 30 rows -- same as standard.


30 is the maximum number of rows. If you were using a smaller screen, then the more/fewer rows calculation would kick in.



jimburgess said:


> Regarding Export:
> (3) After initial installation of the plug-in, the default external apps are set to:
> Browser: /Applications/Safari.app
> Excel: /Applications/Microsoft Office 2008/Excel.app
> Safari makes sense since it is the default browser, but Excel doesn't exist on the system. I would have expected the Excel app to be set to Numbers (which is on the system), or set to blank, or set to a message like "No Default Application".


On Mac it does assume that the most common version of Excel would be installed.



jimburgess said:


> (4) Since the Excel default app doesn't exist, when you perform an export nothing happens as you would expect. But there's no indication to the user that this is the case.


OK, could do better. I do have a dialog box phobia and get fed up of messages that tell you something is done. 



jimburgess said:


> (5) Using LR's Plug-In Manager, set the default browser app to another browser, e.g., Google Chrome or Firefox.
> When you export from the List View, the Safari browser is always used rather than the specified browser.
> If you go back into the Plug-In Manger, the default browser has been set back to Safari. So it appears the specified default browser setting isn't being applied, nor it is being remembered.


There's a bug here that will be fixed with 1.56. It also affects the spreadsheet preference.



jimburgess said:


> (6) Using LR's Plug-In Manager, set the default "Excel" app to Numbers.
> When you export from the List View, Numbers is used but an error occurs because the exported format is an html file which Numbers cannot open. Both export options output the same file type, namely html. I would have expected CSV format to be used for the "Excel" export.
> Now if you go back into the Plug-In Manager, the default Excel app has been set back to the original default setting. So in this case it appears the specified default setting is being applied, but only for one export. Then it is forgotten and reset back to the original Microsoft Excel setting.
> (7) I assume the intent is to produce a CSV file as the output for  spreadsheets rather than the html file currently being exported.


The default app should be remembered, as noted above. 

CSV was  certainly the obvious format. But I chose HTML because it's much more resistant to oddities like people putting all sorts of sh1t like commas and quotes in their metadata, so fewer people will get confused by columns being broken up unpredictably, and because I judged it important that the exported metadata should be formatted in a way people might be able to use. It's more likely that I will add XML export as an option (though my experimentation with XSLT transformation directly to spreadsheet formats was disappointing).

I don't plan to offer specific support for Numbers or OpenOffice as I'm not a fan of either program (sorry). So far I've only had one person asking for OpenOffice and now you mentioning Numbers, and more people saying they were pleased to find they could set up Dreamweaver to launch from the "Excel" button.



jimburgess said:


> (8) When performing consecutive exports, the exported file "List View.html" is being overwritten without warning. What if the user wants to save different output files?


This is another case where I adopted a "this is what it does, get over it" stance and in fact commented out some code which detects the existing file and prompts for a Save As alternative. The trouble is, if you let the user choose the file name and location and I'd soon be answering questions from people who can't find where they exported the file and blame the plug-in for losing it. I might add a suffix, but it's going to go to the desktop. 



jimburgess said:


> (9) The html export format doesn't seem to be very useful (maybe I'm missing the point). See the attached screen shot...all the values run together making it difficult to read. There are also three superflous column headings to the right of the last column:  "keywords modified2 marked". There's no data in those columns. What are they?


I've largely explained why HTML is the choice - it's a quick, universally-formatted dump to an external editor so the user could decide what to do with it. XML-XSLT allowed fancy report formats but I considered it too complex for people (10 years ago I was using XML in big financial systems and confidently expected it would be mainstream by now, but it's still a niche format).

Those columns will be custom fields from another plug-in. I've written in various places that there's a danger that metadata entered through LR plug-ins can easily be locked inside LR - eg if the other plug-in's developer vanishes and it no longer works. The SDK only provides limited access to another plug-in's fields, but I feel it's important to provide an exit strategy and therefore List View simply dumps any custom to the spreadsheet by brute force.


----------



## jimburgess (Aug 17, 2011)

John,
Have an additional question regarding usability:
It appears there is no way to select a range of rows in the list. You can select all, select none, or select one-at-a-time. So for example, if I wanted to sort out all the images shot with spot-metering mode and select just those images I would have to individually click the select box for every row. I assume this is a limitation of the SDK, but wanted to check. 

Regarding the other areas:



> On Mac it does assume that the most common version of Excel would be installed.


Not sure about that assumption. People on Macs tend to avoid Microsoft.



> CSV was  certainly the obvious format. But I chose HTML because it's much more resistant to oddities like people putting all sorts of sh1t like commas and quotes in their metadata, so fewer people will get confused by columns being broken up unpredictably, and because I judged it important that the exported metadata should be formatted in a way people might be able to use. It's more likely that I will add XML export as an option (though my experimentation with XSLT transformation directly to spreadsheet formats was disappointing).


I feel that the advantages of CSV export outweigh the negative points you raise. By including the ability to change the column separator, most of the problems you mentioned can be eliminated. CSV can be imported into any spreadsheet program, and can be used with any number of database programs. In my view, HTML is pretty restricted in comparison.

This one's likely a show-stopper for me.  



> I don't plan to offer specific support for Numbers or OpenOffice as I'm not a fan of either program (sorry). So far I've only had one person asking for OpenOffice and now you mentioning Numbers, and more people saying they were pleased to find they could set up Dreamweaver to launch from the "Excel" button.


But the ability to do CSV export from ListView would obviate the need to directly support other spreadsheets. I'm not going to install Excel on my system, nor Dreamweaver. I have no need for either of them. Again, show-stopper, primarily because I have no easy way to get metadata out of LR via ListView and perform subsequent analysis and reporting on the data.



> I might add a suffix, but it's going to go to the desktop.


That's reasonable.



> XML-XSLT allowed fancy report formats but I considered it too complex for people (10 years ago I was using XML in big financial systems and confidently expected it would be mainstream by now, but it's still a niche format).


Have to agree. I've yet to find an easy way to work with XML files.



> Those columns will be custom fields from another plug-in.


I see now those are LR/Transporter fields. 

Thanks for your response.


----------



## johnbeardy (Aug 18, 2011)

Yes, it is a limitation of the SDK that you can't select groups of rows. I did consider a pair of boxes where you'd enter the starting and ending row, but it was so far below Excel-style behaviour that it wasn't worth pursuing.

I hadn't actually thought of using a character other than a comma as a separator in a CSV file, despite having recently done something along those lines. I'm not promising, but would Numbers be able to handle the pipe | character?  OpenOffice isn't a problem - I almost consider it a professional app! 

John


----------



## jimburgess (Aug 18, 2011)

John,
A pipe character is one alternative, but by itself doesn't address all issues.
Based on a little research and some limited testing I've done, here's a possible approach:

 a. Provide the user with a choice of characters to use for the column delimiter:
comma    (The default)
tab        (Since it is the most common besides a comma)
semicolon    (e.g., for international currency)
pipe        (To hopefully take care of other stuff)
b. Enclose all exported fields in double quotes.
This eliminates problems with imbedded commas, imbedded new lines, tabs and whatever else users come up with in their metadata.

However, a problem exists with imbedded double quote characters. In that case, the quotes have to escaped with an adjacent quote (a double-double quote if you will). Since adding that is likely a significant programming effort, you could leave it up to the user to worry about (your _"this is what it does, get over it"_ stance). Besides, the html output would be available for a user with these kinds of data issues.

Another thought: Since you are already producing an export file on the desktop why even bother with specifying/remembering the apps that will open the exported file? Let the user choose whatever browser or other software they want to open the files once the data has been exported. This eliminates a lot of the issues I brought up earlier, and you wouldn't need to deal with the code necessary to specify, remember, and open the app. What you have is handy, but certainly not essential.

Here's a couple of bugs that have shown up:

When you change metadata and click "Save and Close" the list view isn't updated with the changes until you open the dialog again.

If you are working with a set of images that contain both masters and virtual copies and open the list view with only the masters or only the virtual copies selected, an error is generated (see attached screen shot) when you attempt an export.


----------



## johnbeardy (Aug 20, 2011)

Jim

Yes, I would always offer a choice of separator and do now have a csv option working with protection against junk in fields. It'll be a while before I roll it out but I may send you an advance copy to test. I can't see "now works in Numbers" as hold-the-front-page breaking news that will shift more copies, but you never know!

John


----------



## jimburgess (Aug 20, 2011)

John,
I would hope that the ability to easily import into other applications besides Numbers (e.g., database apps) would be a boost as well. More than happy to help out with testing. Thanks again for your efforts.
Jim


----------



## johnbeardy (Aug 20, 2011)

It was the comment about database apps that kicked me into life!

John


----------



## jimburgess (Sep 26, 2011)

John...regarding ListView Ver. 1.56


1) Based on the testing I've done, the new export features work properly. And Numbers can be successfully used as the spreadsheet! I've tested using imbedded new line characters and that is handled properly. I've also imported the CSV file into other software successfully.


There is a minor display issue when new line characters are imbedded, for example, in the Caption field. The row height on your listview is apparently based on the thumbnail size rather than the content of cells. For example, if the Standard row height is selected, a third line in a field is not displayed. Looking at "Screen Shot 1", the last items in the list contain  3 lines, but only 2 are shown. If "Bigger..." thumbnails are selected, then all 3 lines show up. I realize there's lots of ramifications to sizing rows based on cell content, but just wanted to point out the issue.


2) Rotations of thumbnails is sometimes messed up. In "Screen Shot 2", all of the photos were taken in portrait orientation, but some of them are rotated incorrectly in the list view. 


And a couple of questions:


3) The "Close to (sorted) collection" is certainly a useful addition. Any way to actually set the sort order to "User Order" in the collection? It currently defaults to Capture Time. Or is this another SDK limitation?


4) When List View is invoked all photos are selected regardless of the actual selections in the current LR view. Any way to match the selections in place when the plug-in is invoked? Or yet another SDK limitation?


Thanks again for all your efforts. This plug-in is a welcome feature to LR.


----------



## johnbeardy (Sep 27, 2011)

Thanks Jim

re 1, doesn't the tooltip take care of that?

pt 2 is an SDK limitation. I'm using an undocumented and unsupported SDK feature and it's a bit flaky - better when the previews have been built? I don't think I've seen any other plug-ins access LR's previews mechanism directly, but I felt the benefit outweighed the flakiness.

re 3, Jim, that's a limitation of the SDK - I would do it if I could. 

You're actually mistaken on pt 4. If 1 item is selected, it selects all visible images - it assumes that you're asking for a list view and don't need a "one item or all" nagging dialog. If multiple items are selected, they are listed.  No items, then everything.

John


----------



## jimburgess (Sep 27, 2011)

Submitted by mistake


----------



## jimburgess (Sep 27, 2011)

johnbeardy said:


> re 1, doesn't the tooltip take care of that?


Yes, it does. Thanks.



> pt 2 is an SDK limitation. I'm using an undocumented and unsupported SDK feature and it's a bit flaky - better when the previews have been built? I don't think I've seen any other plug-ins access LR's previews mechanism directly, but I felt the benefit outweighed the flakiness.


I've noticed that when list view is initally displayed the orientation of thumbnails is correct. When sorting is changed to a different column, the thumbnail orientation changes, seemingly randomly. (Tested with a folder of photos where all orientations were portrait.) You likely know this, but thought I would point it out just in case. 



> re 3, Jim, that's a limitation of the SDK - I would do it if I could.


Not a major issue since the user order is remembered properly in the collection.



> You're actually mistaken on pt 4. If 1 item is selected, it selects all visible images - it assumes that you're asking for a list view and don't need a "one item or all" nagging dialog. If multiple items are selected, they are listed. No items, then everything.


You're right...I got confused by my own notes. Starting over....
I was expecting behavior that emulates the grid view selections, so that when you enter list view all photos displayed in the grid or filmstrip are also displayed in the list view but with the same selections in place. That way it doesn't matter if none, one, some or all are selected since the list view would mimic the grid/filmstrip selections. (This is also the way Aperture's list view works.) Your approach filters the grid view based on the selections in place before entering list view. Understand this is a design decision you made. I was expecting the other way.

Thanks again for a useful plug-in.


----------

