I want to change button tint from Aqua to Graphite. Why this code doesn't work?
[[myButton cell] setControlTint:NSGraphiteControlTint];
I don't know how to do it for one your control. I think something was changed in setControlTint work rules in OS 10.6 and later. But it's only hypothesis.
In any case you can try to use this code
[[NSUserDefaults standardUserDefaults] setInteger:NSGraphiteControlTint forKey:#"AppleAquaColorVariant"
But remember that it should be insert before NSApplicationMain(argc, (const char **)argv); You can also create subclass for your application class and change default settings in init method.
You can also set graphite theme for concrete window:
NSColorSpace* space = [NSColorSpace genericGrayColorSpace];
[_window setColorSpace:space];
It's very possible that the specific NSCell subclass you're using doesn't make use of the controlTint (and for NSButtonCell I don't think every buttonType supports the controlTint), I don't think all . With the direction Apple is taking in its recent UI I wouldn't be surprised if this eventually becomes deprecated.
If you do need a cell with a different tint, you could always subclass it and implement it directly.
Related
I'll try to keep it short. I want to create a 3D FPS game, just for myself, that can run on multiple platforms, but I figured that to keep it simple, perhaps it is best to start off with something that is exclusively for macOS. I opted for Objective-C because
(a) Window Application projects in Xcode can only be coded either in Obj-C or Swift (since we are dealing with Cocoa API) and
(b) Obj-C is closer to old-school then Swift.
But before I learn to draw/render 2D-shapes on the window's canvas by writing code, I have to learn to invoke an application window with its properties set to my liking. I've spent hours doing research and experimenting with chunks of code. This is what I've tried: I open with
#import <Cocoa/Cocoa.h>
int main(int argc, const char * argv[]) {
#autoreleasepool {
Then I go with ...
1)
NSWindow *window = [[[NSApplication sharedApplication] windows] firstObject];
NSRect frame = [window frame];
frame.origin.x = 100;
frame.origin.y = 200;
frame.size.width = 100;
frame.size.height = 500;
[window setFrame: frame display: YES];
... and close with ...
NSApplicationMain(argc, argv); // runs the win display function.
}
return (0) ;
}
But no visible changes. Nothing really gets reset. So instead of (1) I tried ...
2)
NSWindow *window = [[[NSApplication sharedApplication] windows] firstObject];
NSPoint newOrigin;
newOrigin.x = 400;
newOrigin.y = 100;
[window setFrameOrigin : newOrigin];
Still nothing. Then instead of (2) I tried:
3)
NSWindowController* controller = [[NSWindowController alloc]
initWithWindowNibName:#"MainMenu"];
[controller showWindow:nil];
Great. Now it's spitting out something I don't understand, especially since I'm new to Obj-C:
2020-02-08 21:53:49.782197-0800
tryout_macApp2[14333:939233] [Nib Loading] Failed
to connect (delegate) outlet from
(NSWindowController) to (AppDelegate): missing
setter or instance variable
I remember dicing around with an ApplicationDelegate, with CGSizeMake(), etc., but it just made the experience really inundating and frustrating. Nothing happened. Then there are NSView, NSViewController, and other classes, which is really mindboggling and begs the question: why are there so many classes when all I want to do is override the preset origin of the window and the dimensions preset by the MainMenu.xib file? (By the way, this project is derived from a Window Application project provided by Xcode.)
I really can't think of anything else to add to give you the entire picture of my predicament, so if you feel that something is missing, please chime in.
[Edit:] Moving forward to phase 2 of my project here: How do I paint/draw/render a dot or color a pixel on the canvas of my window with only a few lines in Obj-C on Mac OS X using Xcode?.
The short answer is that main() is too early to be trying to do this. Instead, implement -applicationDidFinishLaunching: on your app delegate class, and do it there. Leave main() as it was originally created by Xcode's template.
After that, I would say to obtain the window (if there's only going to be one main one), it's better to add an outlet to your app delegate and then, in the NIB, connect that outlet to the window. Then, you can use that outlet whenever you want to refer to the window.
Also, make sure that Visible at Launch is disabled for the window in the NIB. That's so you configure it as you want before showing it.
For a more complex app, it's probably better to not put a window into the Main Menu NIB. Instead, make a separate NIB for the window. Then, load it using a window controller object and ask that for its window.
I love Objective-C but also feel your pain, it has this testy ability to frustrate you endlessly.
I have not really developed a game but let me try and point you in the right direction. I think you need a UIViewController.
Now each UIViewController has a built in UIView that sort of represents the visible portion of it. You can use this or add a UIView and use that, whichever depends on your implementation. For now I'd suggest add a separate UIView and use that rather. Once you're comfortable you can then move the implementation to the UIViewController's view if you need to.
Anyhow, for now, create a UIView subclass, say MyGame or something, as for now all your code will end up there.
To do all of the above is not easy, especially if its the first time. If you can follow some tutorial it will be great. Even if the tutorial just adds a button, you can use it and replace the button with your view.
Anyhow, now that you've got that running and the view you've added shows up in green or some other neon colour just to verify that you can indeed change its properties, you're good to go.
Now you start. In MyGame, implement the
-(void)drawRect:(CGRect)rect
message, grab the context through
UIGraphicsGetCurrentContext
and start drawing lines and stuff on it, basically the stuff I understand you are interested in doing. You can also, through the same context, change the origin of what you are doing.
Hope this helps.
I know that UIActionSheets don't offer that much customization but what I am asking, is that instead of the grayish/white buttons, can I use a green button (my own UIImage)? I can supply my own image with the text already on there that I want; so using a normal UIActionSheet, can I supply my own image on one of the buttons? If so, how should I go upon doing that?
Thanks,
O.Z
#huesforalice is right - the cleanest way would be to create your own replacement of UIActionSheet. Basically you have 3 options:
A real replacement: You create a UIActionSheet-subclass to be protocol-compatible to ´UIActionSheetDelegate´. This would allow you to use it exactly as a UIActionSheet — but it might be a costly process to figure out when and why a UIActionSheet will call the delegates method implementation.
Even go a bit further and also extend the protocol. This will give you more possibilities, how to use it (i.e. allow picker to be used via new protocol methods), but will be even harder.
The most easiest way will be to create a very own implementation, that doesn't rely on UIActionSheet nor it's protocol — but it won't replace real UIActionSheet, in the meaning that you cannot drop it into your project and expect it to work. But you will have the highest degree on freedom.
I would recommend 3. I found a project, that is working like that. But be warned: It shows you how to do it in general, but has some poor underlying design-decisions:
It uses a method
- (void) addButtonWithTitle: (NSString*) buttonTitle buttonId: (NSInteger) buttonId textColor: (UIColor*) textColor textShadowColor: (UIColor*) textShadowColor backgroundColor: (UIColor*) buttonBackgroundColor increasedSpacing: (BOOL) spacing
Instead — IMHO — it should be
- (void) addButton: (UIButton*) button;
So you can add buttons with different designs more flexible, and don't depend for a section id, what is totally unnecessary, as the object has its own identity as an object already.
The method [actionSheet showWithAnimation:YES]; should be called
showor showAnimated: as …withAnimation: usually takes a block to perform a custom animation.
This ist not possible using UIActionSheet and the documented methods. You could write your own actionsheet, which you then probably would add to the main window and animate to slide up. Possibly there is a way to do what you want by analyzing the actionsheets private view hierarchy and adding custom buttons, but you have to keep in mind, that private view hierarchies may change from one iOS Version to another, so your app might break or might even get rejected from apple.
I have created a fairly simple screensaver that runs on Mac OS 10.6.5 without issue.
The configuration screen has accumulated quite a few different options and I'm trying to implement my own preview on the configureSheet window so the user (just me, currently) can immediately see the effect of a change without having to OK and Test each change.
I've added an NSView to the configureSheet and set the custom class in Interface Builder to my ScreenSaverView subclass. I know that drawRect: is firing, because I can remove the condition for clearing the view to black, and my custom preview no longer appears with the black background.
Here is that function (based on several fine tutorials on the Internet):
- (void)drawRect:(NSRect)rect
{
if ( shouldDrawBackground )
{
[super drawRect:rect];
shouldDrawBackground = NO;
}
if (pausing == NO)
[spiroForm drawForm];
}
The spiroForm class simply draws itself into the ScreenSaverView frame using NSBezierPath and, as mentioned, is not problematical for the actual screensaver or the built-in System Preferences preview. The custom preview (configureView) frame is passed into the init method for, um, itself (since its custom class is my ScreenSaverView subclass.) The -initWithFrame method is called in configureSheet before returning the configureSheet object to the OS:
[configureView initWithFrame:[configureView bounds] isPreview:YES];
Maybe I don't have to do that? It was just something I tried to see if it was required for drawing.
I eventually added a delegate to the configureSheet to try triggering the startAnimation and stopAnimation functions of my preview via windowWillBeginSheet and windowWillEndSheet notifications, but those don't appear to be getting called for some reason. The delegate is declared as NSObject <NSWindowDelegate> and I set the delegate in the configureSheet method before returning the configureSheet object.
I've been working on this for days, but haven't been able to find anything about how the OS manages the ScreenSaverView objects (which I think is what I'm trying to emulate by running my own copy.)
Does anybody have any suggestions on how to manage this or if Apple documents it somewhere that I haven't found? This isn't really required for the screensaver to work, I just think it would be fun (I also looked for a way to use the OS preview, but it's blocked while the configureSheet is activated.)
OK, there are a couple of 'duh' moments involved with the solution:
First of all, I was setting the delegate for the sheet notifications to the sheet itself. The window that the sheet belongs to gets the notifications.
Secondly, that very window that the sheet belongs to is owned by System Preferences, I don't see any way to set my delegate class as a delegate to that window, so the whole delegate thing doesn't appear to be a viable solution.
I ended up subclassing NSWindow for the configureSheet so that I could start and stop animation on my preview by over-riding the makeKeyWindow and close methods.
- (void) makeKeyWindow
{
if (myPreview != nil)
if ( ! [myPreview isAnimating])
{
[myPreview startAnimation];
}
[super makeKeyWindow];
}
I also had to add an IBOutlet for my preview object itself and connect it in Interface Builder.
Still working out a couple of issues, but now when I click on my screensaver Options button, my configureSheet drops down and displays its own preview while you set options. Sheesh. The hoops I jump through for these little niceties. Anyway, I like it. Onward and upward.
I currently have a color well which keeps track of a color that gets saved in the NSUserDefaults. It is bound to an NSUserDefaultsController. However, I also want to listen for changes to the color so I can update my views accordingly. Therefore, in addition to the binding, I added a target/action to the color well to my preferences controller that posts a notification with the color.
1) How safe is having both target/action and bindings? Is there a possibility that one might lag or they may be out of sync and report different values?
2) When I am getting the color in my IBAction method, should I get it from the user defaults or from the color well?
Here is my colorChanged: action:
- (IBAction)colorChanged:(id)sender
{
NSDictionary *userInfo = [NSDictionary dictionaryWithObject:[colorWell color] forKey:#"color"];
[notificationCenter postNotificationName:#"ColorChangedNotification" object:self userInfo:userInfo];
}
So should I be doing this:
[NSKeyedUnarchiver unarchiveObjectWithData:[[NSUserDefaults standardUserDefaults] objectForKey:#"color"]];
or:
[colorWell color];
Thanks!
1) How safe is having both
target/action and bindings? Is there a
possibility that one might lag or they
may be out of sync and report
different values?
I think for the most part, it should be OK. The best way to tell is to test it out.
2) When I am getting the color in my IBAction method, should I get it from the user defaults or from the color well?
You should definitely, definitely get it directly from the color well. Why? There could be a lag when saving to the user defaults. Heck, the defaults could even save only once right before the application terminates, and it would still be alright. (OK, this isn't entirely true, but still) The defaults' main purpose is to persist data in between application launches, not during the lifespan of the app.
It is safe to have both target/action and bindings. If you post notifications with an NSNotificationCenter, then the notifications are delivered synchronously to the observers. (With the obvious caveat that it is not magic--if observer A sends a message to observer B when it gets the notification, observer B will not have received the notification yet. Multiple threads add further complexity.) This is called out in the documentation for NSNotificationCenter.
Reading the color directly from the color well is fast, and probably fine from an IBAction. If you're running code when the application is starting it is best to read from the user defaults because the color well's bindings might not have been updated yet.
I want to disable the annoying clicks that the UIPickerView generates upon scrolling up and down. Is there a way to do this? I want to play short sounds for each item that the picker view lands upon. It gets ruined by the built in sound.
I understand that the picker sounds can be turned off globally by switching off the keyboard sounds in iPhone/iPod settings. But is there a way to programatically do this?
Any help will be much appreciated!
Thanks
I've been struggling with a UIPickerView sound issue, and even though it's only partially relevant to the original question, I'm posting the problem/solution here because this topic keeps coming up in my search results so I think anyone else in the same boat may end up here too…
I needed to initialize a UIPickerView to restore the currently selected row from saved data. Simple, right? In viewDidLoad, just call the selectRow:inComponent:animated method of UIPickerView:
[myPicker selectRow:currentRowIndex inComponent:0 animated:NO];
This works as expected, but has a side effect that it generates a single "click" sound as if the user had scrolled the control. The click sound only occurs when running on a device (not the simulator), and only if the device has iOS 3.x installed (I tested with 3.1.3 and 3.2). This was apparently a bug in iOS that was fixed starting with iOS 4.0. But if you need to target Gen1 iPhone, you're stuck with iOS 3.1.3 where this problem is present.
I discussed the issue with Apple DTS, but they were unable to suggest any workaround other than upgrading to 4.0. I asked if they would make an exception and permit the use of the undocumented setSoundsEnabled mentioned above (which does actually solve the problem). The answer was, "There are no exceptions."
After some additional detective work, I discovered that you can prevent the sound from occurring by temporarily removing the UIPickerView from the superview, call selectRow, then re-add it to the superview. For example, in viewDidLoad:
UIView *superview = [myPicker superview];
[myPicker removeFromSuperview];
[myPicker reloadAllComponents];
[myPicker selectRow:currentRowIndex inComponent:0 animated:NO];
[superview addSubview:myPicker];
This gets rid of the extraneous click sound without using undocumented/private APIs so should pass Apple's approval process.
After using this specific undocumented api for over a year on the App Store Apple finally asked me to remove it from my App. It is very frustrating for audio apps to have that damn click sound. The best advice is to share with users that the picker sound can be disabled globally in the settings application under "Sounds" and setting "Keyboard Clicks" to "Off". I also strongly recommend visiting https://bugreport.apple.com/ and filing a bug for UIPickerView, as it can cause distortion in audio applications when the picker click is played.
they have just rejected an app of mine because the use of undocumented api's...thats one of them.
Someone I know says he got this past the App Store review just last week:
// Hide private API call from Apple static analyzer
SEL sse = NSSelectorFromString([NSString stringWithFormat:#"%#%#%#", #"set",#"Sounds",#"Enabled:"]);
if ([UIPickerView instancesRespondToSelector:sse]) {
IMP sseimp = [UIPickerView instanceMethodForSelector:sse];
sseimp(self.thePicker, sse, NO);
}
There is an undocumented way (I'm actually not sure if it is still available in iphone 3.0) but here it is any way
#import <UIKit/UIKit.h>
#interface SilintUIPickerView: UIPickerView
{ }
- (void) setSoundsEnabled: (BOOL) enabled;
#end
use this subclass instead and call [view setSoundsEnabled: NO]
I'm interested in knowing how it goes in the latest SDK, give it a shot and let us know.
Could this trick work? Someone was able to suppress the camera shutter sound effect by playing an inverted copy of the sound at the same moment: https://stackoverflow.com/a/23758876/214070
Maybe this not the answer for this particular question, but I had a similar problem - set minimumDate for datePicker, and I wanted set it without annoying "click" sound. After some time found very simple solution:
datePickerCustomTime.minimumDate = [[NSDate date] dateByAddingTimeInterval:300]// min time to set = now + 5 min
[datePickerCustomTime setDate:[[NSDate date] dateByAddingTimeInterval:300] animated:NO];
I found small quickie solution for this try below
UIPickerView *pickerView = [[UIPickerView alloc] initWithFrame:CGRectMake(0, yPickerView, VIEW_WIDTH, PICKERVIEW_HEIGHT)];
pickerView.delegate = self;
pickerView.dataSource = self;
pickerView.showsSelectionIndicator = YES;
pickerView.alpha = 0.8f;
pickerView.tag = fieldTag;
[pickerView selectRow:pickerViewSelectedIndex inComponent:0 animated:NO];
set the animated:NO for selectRow: method