Re: Bindings and Editing in a row
On Feb 17, 2015, at 12:35 , John MacMullin wrote:
>
> So it appears that I don’t need shouldEditTableColumn because of the
> bindings. Where is this in the docs? (rather than random cocoa sources).
I’m not sure it’s got anything to do with bindings. Configuring table views is
just a bit messy, probably because they’ve evolved so much over the years.
If the delegate method is absent, then I’d expect the “Editable” checkbox on
the table column in IB to control the behavior. It’s certainly possible that
some bindings options may further restrict editability, and if you have a
NSArrayController between the table and its data model, it may also have
settings that affect editability.
The delegate method is likely intended to cover cases where the editability is
determined per-row, or by some other factor that isn’t easy to express in IB,
array controllers or bindings.
> If I take out the following:
>
> - (BOOL)tableView:(NSTableView *)tableView shouldSelectRow:(NSInteger)row
> {
>if (tableView) {
>if (row >=0) {
>return YES;
>}
>}
>return YES;
> }
>
> I can’t select any row. So it would appear that some of the table view
> methods operate independently of the bindings. Where is this documented?
It shouldn’t be necessary to have this method just to enable selection, and
it’s got nothing to do (intrinsically) with bindings. You’ve got some other
problem that’s interfering.
For example, if you have the table’s “selected row indexes” binding bound to a
property that doesn’t actually save the selection persistently, it’ll seem like
selection doesn’t work (though in such a hypothetical scenario, it is working,
but just getting cleared later, before you notice).
Tracking down misbehaviors in table views can be painful, because there are
lots of places to check, and no clear indication of what to look for.
Generally, you just need to persevere, perhaps with some judicious NSLogging to
check your assumptions about what’s happening and when.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Package/folder confusion
Yep, I was literally Doing It Wrong. I thought the extension was the link. Use the ID instead, and the packages are packages. Doesn’t look like that magically fixed the other issues, but at least it’s one less bug to squash. — Charles On February 17, 2015 at 12:34:52 PM, Quincey Morris (quinceymor...@rivergatesoftware.com) wrote: On Feb 17, 2015, at 06:31 , Charles Jenkins wrote: In my target’s Info tab, I have one Document Type: I filled in its Name, Class (the class of my Document window controller), and Extension. I selected Editor as the Role and made sure “Document is distributed as a bundle” is checked. I also have one Exported UTI: I filled in the same extension as the Document Type, added a Description, and indicated it Conforms To com.apple.package. If this is literally what you’ve done, you’re Doing It Wrong™. The Exported UTI and the File Type are linked by the UTI itself (the string in the “Identifier” field), not by the extension. You should copy the UTI from the “Identifier” field of the Exported UTI into the “Identifier” field of the File Type. In that case, the File Type’s extension and “is bundle” flag are ignored. The fact that you have two conflicting definitions of the document type may account for the results you’re seeing in the Finder. It’s also possible that the cause is different, that you have a leftover built app lying around somewhere that has incomplete file type information. If the above doesn’t fix your problem, you’ll need to go on a search-and-destroy mission to find copies of your app on any mounted disc. (Or, if you have tools to examine the LS database, look in it to find the path(s) to the wayward app bundles.) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Bindings and Editing in a row
Ok with programmatic bindings, I have:
1. on the interface.
2. In set up:
NSButtonCell *recCell11 = [NSButtonCell new];
[recCell11 setButtonType:NSSwitchButton];
[recCell11 setTitle:NULL_STRING];
[recCell11 setImagePosition:NSImageOnly];
[recCell11 setEditable:YES];
[[transTableView tableColumnWithIdentifier:@"11"]setDataCell:recCell11];
[[transTableView tableColumnWithIdentifier:@"11"]setEditable:YES];
Plus my bindings in all columns.
3. Also, in set up:
[transTableView setDelegate:self];
[transTableView setDataSource:self];
4. Later in the code:
- (BOOL)tableView:(NSTableView *)tableView shouldSelectRow:(NSInteger)row
{
if (tableView) {
if (row >=0) {
return YES;
}
}
return YES;
}
5. Commented Out in the code:
/*
- (BOOL)tableView:(NSTableView *)tableView shouldEditTableColumn:(NSTableColumn
*)tableColumn row:(NSInteger)row
{
NSLog(@"shouldEditTableColumn");
if ([tableView tag] == 10 ) {
if (([tableColumn identifier] == @"11") && (row >= 0)) {
return YES;
} else {
return NO;
}
}
return NO;
}
*/
and 6. My:
- (void)tableView:(NSTableView *)tableView setObjectValue:(id)object
forTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row
which works just fine.
So it appears that I don’t need shouldEditTableColumn because of the bindings.
Where is this in the docs? (rather than random cocoa sources).
If I take out the following:
- (BOOL)tableView:(NSTableView *)tableView shouldSelectRow:(NSInteger)row
{
if (tableView) {
if (row >=0) {
return YES;
}
}
return YES;
}
I can’t select any row. So it would appear that some of the table view methods
operate independently of the bindings. Where is this documented?
Best regards,
John MacMullin
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Package/folder confusion
On Feb 17, 2015, at 06:31 , Charles Jenkins wrote: > > In my target’s Info tab, I have one Document Type: I filled in its Name, > Class (the class of my Document window controller), and Extension. I selected > Editor as the Role and made sure “Document is distributed as a bundle” is > checked. > > I also have one Exported UTI: I filled in the same extension as the Document > Type, added a Description, and indicated it Conforms To com.apple.package. If this is literally what you’ve done, you’re Doing It Wrong™. The Exported UTI and the File Type are linked by the UTI itself (the string in the “Identifier” field), not by the extension. You should copy the UTI from the “Identifier” field of the Exported UTI into the “Identifier” field of the File Type. In that case, the File Type’s extension and “is bundle” flag are ignored. The fact that you have two conflicting definitions of the document type may account for the results you’re seeing in the Finder. It’s also possible that the cause is different, that you have a leftover built app lying around somewhere that has incomplete file type information. If the above doesn’t fix your problem, you’ll need to go on a search-and-destroy mission to find copies of your app on any mounted disc. (Or, if you have tools to examine the LS database, look in it to find the path(s) to the wayward app bundles.) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Package/folder confusion
I’ve got a goofy issue that’s been with me for a while, but I had more important things to work on. Months ago, members of this list told me how to set up my project so the document would be stored as a package. I tried it, it worked, and all was great. But at that time I was developing different parts of the app separately and saving them off as I got each bit working—so I’d have a separate working example to come back to later and compare with if I screwed things up. At some point in my iterations, I think I must’ve confused Yosemite, because my document packages now usually appear in Finder as directories. That has been very convenient for testing and inspecting my file format, since it saves me the step of opening the package, but now I’d like to cure the issue. Mostly because I have a couple of other problems I think may be related: My Recent documents menu isn’t populating, and sometimes after saving, when I open a file inside the package-directory to inspect it, I see the *old* contents. I somehow get an old Version of the file until I Force Quit Finder. (I’m using TextWrangler to inspect my files, and when Finder gets in a mood to serve up old Versions, sometimes TextWrangler blows up even trying to read them. Then after a Force Quit, Finder shows the proper content again and the new file can be read.) In my target’s Info tab, I have one Document Type: I filled in its Name, Class (the class of my Document window controller), and Extension. I selected Editor as the Role and made sure “Document is distributed as a bundle” is checked. I also have one Exported UTI: I filled in the same extension as the Document Type, added a Description, and indicated it Conforms To com.apple.package. I examined the Info.plist file viewing raw keys and values to confirm that LSTypeIsBundle = YES for my document type, and I’ve triple-checked that I typed the extension exactly the same in both places. I also compared against the old version of the app I was working on back when my packages always appeared as packages. I was coding in Swift then and using a different extension name, but the settings are virtually the same. Now if I use Onyx to rebuild Launch Services, after a reboot my documents show up as packages. But then the second I start debugging my app in Xcode, the documents revert to being plain directories. Any ideas how to fix this? — Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Idea for Improving Vibrancy
If you wanted to do this, I would grab the desktop image somehow, apply the effect to it once, and then use (a shifting portion of) that image as the background of your Source View, etc…. That way there is no need to mess with additional windows, or apply the expensive effect continually. There is the tricky bit (for both solutions) of determining when the desktop has changed (or you have changed screens). It is definitely possible, but requires care to get the edge cases right. FWIW, I agree with you on the effect. I may be in the minority on this list, but I like the colorfulness of the source lists, and I agree with charles that it seems like waste to spend all that processor power just to get the grey of the window behind it. It would be nice to have a desktop picture mode. That said, I am sure Apple at least considered it, and it is possible that it caused some sort of cognitive issue in testing (e.g. breaking object permanence) which sent things into uncanny valley territory. It is amazing what subtle things can have a strong effect. Filing a radar was the right call, IMHO. Thanks, Jon > On Feb 15, 2015, at 6:13 AM, Charles Jenkins wrote: > > I have an idea for improving vibrancy, but right now it’s just a thought > experiment. I don’t know how to accomplish it, so I wonder if you guys could > provide any advice. > > I just posted this suggestion to Apple’s OS X feedback site: "Please consider > adding NSVisualEffectBlendingModeDesktop and making it the default for > objects like the Source View which reside in an app's main or document > window. A window with that visual effect mode would use the desktop image > ONLY for vibrancy blending. Doing so would be kind to users: they have chosen > the desktop image presumably because it and its colors are pleasing. Blending > with other randomly intervening windows due to the current default of > NSVisualEffectBlendingModeBehindWindow is unkind to users because (a) it > ignores the user's clearly expressed preference for the desktop image (b) > without conveying any useful information whatsoever.” > > Well, I’m not going to hold my breath. But it did occur to me that an app’s > main/document window could accomplish something similar by creating its own > secondary window that would somehow “stick” behind it. The secondary window’s > only purpose would be to replicate the portion of the desktop image occluded > by its bounds. That way, no matter what apps are running, it would show a > portion of the desktop image, and though users would never actually see this > secondary window, the main/document window would blend with it, giving the > user pleasing vibrancy using the desktop image he has chosen. > > Is this possible, do you think, to open a window that always hides directly > behind the working window? > > — > > Charles > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/jhull%40gbis.com > > This email sent to jh...@gbis.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Cocoa Documentation PlugIn for Safari
Hi All, A while back I Installed a plug in for Safari that showed the Cocoa Reference Documents and allow searching etc. When I updated to Yosemite/XCode 6 it seems to have gone missing (not sure why?). I tried to find it again but not having much luck, does anyone know where these PlugIns live? Thanks a lot Dave ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
