I’ve been frustrated by those ‘broken’ nib files for a while but never bothered to look into it. And I wondered why nobody else was complaining about it. It seems like the language issue here explains all of it.

Still sucks, though.

If you control-click a Nib file and select “Show Package Contents” you’ll see the constituent files that makes up a Nib package. It turns out that IB only really needs the Objects.nib file to instantiate the objects at runtime. The other two files are for Interface Builder’s benefit in showing the user how they may edit the relationships.

For some reason those files have been removed from the localization editions in Mail. If you drag the “Info.nib” and “Classes.nib” from an English counterpart Nib to inside a German one, you should then find yourself able to open and edit it. I’m pretty sure this is safe because the Info and Classes data don’t contain localized information. I might be wrong about that, though.

It might make a nice AppleScript or shell script that would simply go through and “repopulate” the localized versions, copying over from the English.

But anyway, back to your original question, it’s precisely the removal of these files that developers sometimes use as a way of “read-protecting” their Nib files.

I just checked anyway, and indeed in Mail I am able to open English nib files. I’m interested in the German ones, though which IB tells me ‘can’t be opened’ Try one of rhose…

I’ve filed the bug (#4578272) and we’ll see how that goes. It’s exactly the kind of problem that I don’t really expect to see improvements on.

(BTW, what exactly does Apple do to cripple their nib files in a way that IB refuses to open them? And how can I undo it? That just seems to make exploration or improvement of things unnecessarily difficult. Although using UI Element Inspector is a cool idea here!)

Here’s what’s going on with your Mail case. If you download Apple’s UI Element Inspector, you can see as you hover the mouse over the text fields in Mail, that all of them are NSTextField. But most of them are textfield enclosed in a scroll view. I’m supposing that somehow the presence of the scroll view is enabling the drag receptivity.

Stingerman: It seems like the bug could be solved by a category on NSTextField to cause it to accept text drags. But it must be more complicated than that. Maybe there are issues with sneaking text changes into the control without going through the whole “become focused, edit, then commit” process.

I just tried this out once more to reproduce things. And in the place where it most frequently bugs me - in Mail - it looks downright ridiculous: Given a Mail window with the To, CC and subject fields and the keyboard focus on the To field, I can get three different drag & drop behaviours.

1. Drag to the To field: green + cursor appears, no other highlight in the field, text is inserted
2. Drag to the CC field: greeen + cursor appears, black frame appears around the field, text is inserted
3. Drag to the Subject field: no cursor change, no text insertion

Very very odd. I guess I should file a bug report on this.

I tried to make a film of that, but the cursor movements and cursor types don’t appear coorectly on there, so it’s not actually useful (http://www.stud.uni-goettingen.de/~s275288/stuff/DD.mov)