Double-clicking .tif should open ImageJ64

[vischer]

Hello all,

On OS X, one can define which program should handle a double-clicked ".tif" file.

To do this, I followed this sequence (OS X Lion):

Select any ".tif" file
File> Get Info
Open With: "Other"
Navigate to ImageJ64.app and select it
Click "Always Open With"
Click "Add"

-- The choice shows now correctly "ImageJ64.app"

Now I click on "Change All.." and  "Continue"

-- Unexpectedly, the choice jumps back to "ImageJ.app".

Even if I hide ImageJ.app in an archive, the choice jumps to micromanager, which is also on my hard disk.

So  I never succeeded.
My work-around is to manually open "ImageJ64.app" before double-clicking any  ".tif".

Any idea?



Norbert Vischer

[Aivar Grislis]

 >Unexpectedly, the choice jumps back to "ImageJ.app"

I just tried these instructions in Lion 10.7.3, with ImageJ 1.46m, using the clown image saved as a tiff file and didn't see this bug.

(After playing around with changing the default application I'm noticing that the "Get Info" version of the default application ["ImageJ64.app"] doesn't agree with the one I get when I right click and choose "Open With..." ["Preview.app (default)"].)

Aivar


On 5/7/12 1:54 PM, Norbert Vischer wrote:

> Hello all,
>
> On OS X, one can define which program should handle a double-clicked ".tif" file.
>
> To do this, I followed this sequence (OS X Lion):
>
> Select any ".tif" file
> File>  Get Info
> Open With: "Other"
> Navigate to ImageJ64.app and select it
> Click "Always Open With"
> Click "Add"
>
> -- The choice shows now correctly "ImageJ64.app"
>
> Now I click on "Change All.." and  "Continue"
>
> -- Unexpectedly, the choice jumps back to "ImageJ.app".
>
> Even if I hide ImageJ.app in an archive, the choice jumps to micromanager, which is also on my hard disk.
>
> So  I never succeeded.
> My work-around is to manually open "ImageJ64.app" before double-clicking any  ".tif".
>
> Any idea?
>
>
>
> Norbert Vischer

[Aivar Grislis]

If you Google "get info change all doesn't work" there are a few
interesting hits toward the top from MacWorld and Apple forums.  
Apparently this bug has been around for years, various workarounds are
discussed but I couldn't find a definitive answer.

On 5/7/12 2:27 PM, Aivar Grislis wrote:

> >Unexpectedly, the choice jumps back to "ImageJ.app"
>
> I just tried these instructions in Lion 10.7.3, with ImageJ 1.46m,
> using the clown image saved as a tiff file and didn't see this bug.
>
> (After playing around with changing the default application I'm
> noticing that the "Get Info" version of the default application
> ["ImageJ64.app"] doesn't agree with the one I get when I right click
> and choose "Open With..." ["Preview.app (default)"].)
>
> Aivar
>
>
> On 5/7/12 1:54 PM, Norbert Vischer wrote:
>> Hello all,
>>
>> On OS X, one can define which program should handle a double-clicked
>> ".tif" file.
>>
>> To do this, I followed this sequence (OS X Lion):
>>
>> Select any ".tif" file
>> File>  Get Info
>> Open With: "Other"
>> Navigate to ImageJ64.app and select it
>> Click "Always Open With"
>> Click "Add"
>>
>> -- The choice shows now correctly "ImageJ64.app"
>>
>> Now I click on "Change All.." and  "Continue"
>>
>> -- Unexpectedly, the choice jumps back to "ImageJ.app".
>>
>> Even if I hide ImageJ.app in an archive, the choice jumps to
>> micromanager, which is also on my hard disk.
>>
>> So  I never succeeded.
>> My work-around is to manually open "ImageJ64.app" before
>> double-clicking any  ".tif".
>>
>> Any idea?
>>
>>
>>
>> Norbert Vischer

[dscho]

Hi Norbert,

On Mon, 7 May 2012, Norbert Vischer wrote:

> On OS X, one can define which program should handle a double-clicked ".tif" file.
>
> To do this, I followed this sequence (OS X Lion):
>
> Select any ".tif" file
> File> Get Info
> Open With: "Other"
> Navigate to ImageJ64.app and select it
> Click "Always Open With"
> Click "Add"
>
> -- The choice shows now correctly "ImageJ64.app"
>
> Now I click on "Change All.." and  "Continue"
>
> -- Unexpectedly, the choice jumps back to "ImageJ.app".
>
> Even if I hide ImageJ.app in an archive, the choice jumps to micromanager, which is also on my hard disk.
>
> So  I never succeeded.
> My work-around is to manually open "ImageJ64.app" before double-clicking any  ".tif".
>
> Any idea?

Usually this is tied to the information provided in the Info.plist file
which you can find in the ImageJ64.app directory (Ctrl-Click on the
ImageJ64 icon and click on "Show Contents") in the subdirectory called
'Contents'.

The part I *think* is responsible to accept ImageJ64 as handler is below
the line reading

        <key>CFBundleDocumentTypes</key>

Ciao,
Johannes

[Aivar Grislis]

>The part I *think* is responsible to accept ImageJ64 as handler is below
>the line reading
>
> <key>CFBundleDocumentTypes</key>

This accords with some other information I've read, like:

'Lately, it seems that it is often difficult to assign an extension to
be opened by an application if that app does not explicitly list that
extension among the ones in the 'CFBundleDocumentTypes' array of the
app's "Info.plist" file - wildcards don't cut it any more.'

--Some guy on the net, "biovizier", from 2007:
http://hintsforums.macworld.com/archive/index.php/t-73919.html

FYI, I'm not seeing this problem and my Info.plist has:

     . . .
<key>CFBundleDocumentTypes</key>
<array>
<dict>
<key>CFBundleTypeIconFile</key>
<string>text.icns</string>
<key>CFBundleTypeName</key>
<string>ImageJ Document</string>
<key>CFBundleTypeOSTypes</key>
<array>
<string>****</string>
</array>
<key>CFBundleTypeRole</key>
<string>Editor</string>
</dict>
</array>
     . . .

Here's the documentation from Apple:

<a href="http://developer.apple.com/library/mac/#documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html#//apple_ref/doc/uid/20001431-101685">http://developer.apple.com/library/mac/#documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html#//apple_ref/doc/uid/20001431-101685

So the four asterisks of CFBundleTypeOSTypes is a wildcard, any file
type could potentially be assigned to ImageJ.  The documentation says
this key was deprecated in 10.5 and is overridden by the newer key
LSItemContentTypes if present.  The newer key description doesn't
mention wildcards, it gives an explicit list of file types.

Aivar

On 5/7/12 6:12 PM, Johannes Schindelin wrote:

> Hi Norbert,
>
> On Mon, 7 May 2012, Norbert Vischer wrote:
>
>> On OS X, one can define which program should handle a double-clicked ".tif" file.
>>
>> To do this, I followed this sequence (OS X Lion):
>>
>> Select any ".tif" file
>> File>  Get Info
>> Open With: "Other"
>> Navigate to ImageJ64.app and select it
>> Click "Always Open With"
>> Click "Add"
>>
>> -- The choice shows now correctly "ImageJ64.app"
>>
>> Now I click on "Change All.." and  "Continue"
>>
>> -- Unexpectedly, the choice jumps back to "ImageJ.app".
>>
>> Even if I hide ImageJ.app in an archive, the choice jumps to micromanager, which is also on my hard disk.
>>
>> So  I never succeeded.
>> My work-around is to manually open "ImageJ64.app" before double-clicking any  ".tif".
>>
>> Any idea?
> Usually this is tied to the information provided in the Info.plist file
> which you can find in the ImageJ64.app directory (Ctrl-Click on the
> ImageJ64 icon and click on "Show Contents") in the subdirectory called
> 'Contents'.
>
> The part I *think* is responsible to accept ImageJ64 as handler is below
> the line reading
>
> <key>CFBundleDocumentTypes</key>
>
> Ciao,
> Johannes

[vischer]

> -- The choice shows now correctly "ImageJ64.app"
>
> Now I click on "Change All.." and  "Continue"
>
> -- Unexpectedly, the choice jumps back to "ImageJ.app".

I have solved my problem meanwhile, and I also have an idea what happened in OS X.
Thanks Aivar and Johannes for your useful contributions.

I solved the problem by disabling all ImageJ applications on my system except the one ImageJ64.app. Disabling meant that I put them temporarily into a zip archive and deleted the original. Then the "Change All.."  command works as expected.
This problem is not related to ImageJ -I can reproduce it when trying to connect ".docx" to Microsoft Word 2008 instead 2011. Obviously, both applications have the same "creator" signature (using a term that was used in OS 9).
The bundle information in Info.plist inside the ImageJ package with its deprecated wildcards "****" still does the job correctly.
The OS obviously has an internal table to map extensions to applications, and even individual files with same extensions can be linked to different apps. However it does not process "Change All.." consistently when there are several apps with same signature such as ImageJ.app and ImageJ64.app.


 
Norbert Vischer
Research Engineer
Centre for Advanced Microscopy
Swammerdam Institute for Life Sciences (SILS)
University of Amsterdam
Science Park 904
1098 XH Amsterdam, the Netherlands