NSPredicateEditor query

[Jonathan Mitchell]

I have an NSPredicateEditor configured to generate my queries.

I have two questions:

1. I want my users to be able to construct queries from a simple initial 
predicate.
Ideally I would like the initial predicate to operate on a single key path and 
look something like:

@"(self.fullName CONTAINS[cd] '')”

However I would also like the composite predicate row to be visible initially - 
This is the row that says “”Any / All of the following are true”;
The following works but always logs Warning - unable to find template matching 
predicate 1 == 1

@"(self.fullName CONTAINS[cd] '') AND (1 == 1)”

Is there a workaround for this?

2. The second query is connected.

I would also like to offer the ability to add additional composite predicate 
operators (Any/All).
The default UI doesn’t seem to implement this.

Is the solution simply to implement an action that takes the current predicate 
format, append an “AND ()” statement and regenerate the predicate?


Thanks

J
___

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

VoiceOver/Accessibility of transparent UIView, navigating through subviews in VoiceOver

[Motti Shneor]

Hello.

I’m trying to make parts of my iOS app accessible, and find myself stumped.

I have some video playing in a plain UIView. A custom (subclass of UIView) 
subview is displayed over the video view, containing a hierarchy of views, 
UIControls (buttons, progress bars, labels etc.).

This overlay subview, is always in the view hierarchy, but after some time it 
fades away, animating its alpha (from 1.0 to 0.0). 
When user taps the video view, we bring it up, animating the alpha back from 
0.0 to 1.0

1. When the overlay (containing the controls) is transparent - none of its 
sub-views (controls) is accessible in VoiceOver. Why? How can I revert this 
behavior?
2. When the overlay (and all its subviews) are visible, I can navigate to them 
in VoiceOver, but cannot enlist them by swiping down with two fingers, or 
swiping right/left to select next/prev accessible Item.

I tried all kinds of things.

* sending 
UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, nil), 
nil) when the overlay finishes fading in/out. No effect (probably because my 
view hierarchy doesn't change).

* Implementing the full  UIAccessibility protocol on my overlay custom UIView - 
but It is pretty heavy, because I need to deal with recursive search for 
accessible elements, and amazingly enough - even when I am correctly reporting 
them all — still VoiceOver won’t enlist them, and still they won’t be navigable 
when the overlay is transparent.

* I tried to make my overlay view accessible - but that immediately bans it 
from being accessibility container - it won’t even be asked for its contained 
accessibleElement items. This overlay view is not tailored for a specific use - 
we use it in many places in the app (it draws a vague gradient, and all the 
control hierarchies over this gradient).

* Most frustrating,  when my overlay view is visible (forever, alpha=1.0, no 
animations) all the buttons are separately accessible no matter how deep they 
are in the view hierarchy. This means, UIView itself implements accessibility 
container protocol - to certain degree. So why won’t VoiceOver enlist them, or 
allow the user navigate through them?

When I print the .accessibilityElementCount() of one of those plain UIViews in 
my control hierarchy (they’re only there to layout together sets of related 
controls, with constraints) I get the value of NSNotFound  — which is out of 
the very definition of that protocol method definitions say a number - 0 if 
none. NSNotFound is a huge integer. 

When I print the .accessibilityElements property of those plain UIView in my 
hierarchy - I simply get nil. If so - HOW DOES VOICEOVER dig down my hierarchy 
to find the controls? The documentation states that VoiceOver is not part of 
your process, and so it has no access to the view hierarchy - only toe the 
Accessibility protocol. That doesn’t match my reality.

The documentation on Apple’s site is somewhat cryptic, and only answers to 
“what happens if everything is Apple’s controls” or “what happens if everything 
is your own custom accessibility elements” but not what happens in the middle - 
where most views Apple provided, accessible UIControls, but only SOME views in 
the hierarchy are NOT. It seems a little stupid to force full-fledge collection 
views everywhere, just to get the free behavior of accessibility navigation, 
where UIViews are meant to contain other views.

After going through tons of blogs, docs, sample code and WWDC videos. I’m not a 
bit closer to an accessible app. Any knowledgable hint can make me smile again.

Thanks!
Motti Shneor

___

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

VoiceOver/Accessibility of transparent UIView

[Motti Shneor]

___

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: Control default color inconsistencies

[じょいすじょん]

> On 2016 Dec 15, at 0:47, Andreas Falkenhahn  wrote:
> 
> I'm creating my GUI programmatically. It simply consists of a UILabel,
> a UITableView and two UIButtons.
> 
> When creating those three controls I've noticed that they all seem to
> use different color schemes by default which makes the GUI look rather
> silly.
> 
> Here are my observations:
> 
> 1) By default, UILabel seems to set both background and text color to
> black, i.e. nothing is readable before you change the colors to some
> more meaningful values.
> 
> 2) By default, UITableView appears with a gray background and black
> text on top.
> 
> 3) By default, UIButton appears with a black background and blue (!)
> text on top.
> 
> Is there any rationale why all three controls seem to use entirely
> different color schemes by default here? 
> 
> When writing desktop GUIs it's bad practice to use custom color schemes
> because they might clash with the user's theme settings. Doesn't such
> a paradigm apply to iOS as well? Or am I really forced to explicitly
> set foreground and background colors for each UI control? I'd really
> prefer to use the default iOS look instead. On Android I don't have to
> set background and foreground colors either, the OS will automatically
> use some meaningful and consistent (!) default colors.
> 
> This makes me wonder if there is a default iOS color scheme for apps
> at all? Or are all apps supposed to define their own color scheme?
> If there is a default iOS color scheme, why don't the controls use
> it then when not specifying any colors?
> 
> It's all quite confusing... I hope somebody can shed some more light
> onto this. But please no lectures on that I should use Interface Builder,
> Storyboard, or whatever it is called now instead, I really like to do
> things manually - always have, always will ;)
> 
> -- 
> Best regards,
> Andreas Falkenhahn  mailto:andr...@falkenhahn.com

Nobody can guess what you are actually doing.
Please share some code so people can help you.

___

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

Control default color inconsistencies

[Andreas Falkenhahn]

I'm creating my GUI programmatically. It simply consists of a UILabel,
a UITableView and two UIButtons.

When creating those three controls I've noticed that they all seem to
use different color schemes by default which makes the GUI look rather
silly.

Here are my observations:

1) By default, UILabel seems to set both background and text color to
black, i.e. nothing is readable before you change the colors to some
more meaningful values.

2) By default, UITableView appears with a gray background and black
text on top.

3) By default, UIButton appears with a black background and blue (!)
text on top.

Is there any rationale why all three controls seem to use entirely
different color schemes by default here? 

When writing desktop GUIs it's bad practice to use custom color schemes
because they might clash with the user's theme settings. Doesn't such
a paradigm apply to iOS as well? Or am I really forced to explicitly
set foreground and background colors for each UI control? I'd really
prefer to use the default iOS look instead. On Android I don't have to
set background and foreground colors either, the OS will automatically
use some meaningful and consistent (!) default colors.

This makes me wonder if there is a default iOS color scheme for apps
at all? Or are all apps supposed to define their own color scheme?
If there is a default iOS color scheme, why don't the controls use
it then when not specifying any colors?

It's all quite confusing... I hope somebody can shed some more light
onto this. But please no lectures on that I should use Interface Builder,
Storyboard, or whatever it is called now instead, I really like to do
things manually - always have, always will ;)

-- 
Best regards,
 Andreas Falkenhahn  mailto:andr...@falkenhahn.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

Re: Users default alert sound

[Quincey Morris]

On Dec 14, 2016, at 09:45 , Sandor Szatmari  
wrote:
> 
> I am currently using [NSSound soundNamed:] to play any arbitrary sound.  But 
> I want to play the one configured in System Preferences.

You can use the NSBeep () global function to play the configured alert sound. I 
don’t know if there’s an API to get its file name — it’s not obvious that it is 
even a separate file, always.

___

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: Users default alert sound

[Britt Durbrow]

Also, not everyone *has* a sound that plays… if the volume is turned all the 
way down, or if they have a hearing issue, for example, they will often have 
the screen flash turned on; calling NSBeep() triggers this correctly.



> On Dec 14, 2016, at 10:51 AM, Sandor Szatmari  
> wrote:
> 
> I didn't know that automatically played the configured sound.  That's great 
> thanks!  I knew I was missing something straightforward.
> 
> Sandor
> 
>> On Dec 14, 2016, at 12:58, Quincey Morris 
>>  wrote:
>> 
>>> On Dec 14, 2016, at 09:45 , Sandor Szatmari  
>>> wrote:
>>> 
>>> I am currently using [NSSound soundNamed:] to play any arbitrary sound.  
>>> But I want to play the one configured in System Preferences.
>> 
>> You can use the NSBeep () global function to play the configured alert 
>> sound. I don’t know if there’s an API to get its file name — it’s not 
>> obvious that it is even a separate file, always.
>> 
> ___
> 
> 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/bdurbrow%40rattlesnakehillsoftworks.com
> 
> This email sent to bdurb...@rattlesnakehillsoftworks.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

Autolayout warnings

[Doug Hill]

I'm seeing warnings in the console when I dynamically make autolayout 
constraints active/inactive at runtime.

I have two constraints that align a container view leading or trailing edge 
with another view's edge. This is to move the container onscreen or offscreen. 
I have another view whose trailing edge aligns with the leading edge of the 
first container view so it moves with it as autolayout constraints change.

At runtime, I make one of these constraints active and the other inactive, like 
so:

- (IBAction)toggleCommentsVisibility:(id)sender
{
self.commentsAreHidden ? [self showComments:self] : [self 
hideComments:self]; 
}

- (IBAction)showComments:(id)sender
{
self.showCommentsConstraint.active = YES;
self.hideCommentsContainerConstraint.active = NO;

self.commentsAreHidden = NO;
}

- (IBAction)hideComments:(id)sender
{
self.showCommentsConstraint.active = NO;
self.hideCommentsContainerConstraint.active = YES;

self.commentsAreHidden = YES;
}

When I call showComments, I get the following warning in the console:

=

Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't 
want. 
Try this: 
(1) look at each constraint and try to figure out which you don't 
expect; 
(2) find the code that added the unwanted constraint or constraints and 
fix it. 
(
"",
"",
"",
""
)

Will attempt to recover by breaking constraint 


Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch 
this in the debugger.

=

This is puzzling because IB doesn't give me any autolayout errors/warning when 
I manually activate/deactivate these constraints. Also, I don't get this 
runtime warning when calling hideComments, only the 'show' case. Finally, 
things actually work at runtime because it's nice enough to "break" the 
constraint that I deactivated in code. But I would like to not have these 
warnings.

Any ideas on what's going on how I might go about debugging this?

Doug Hill
___

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: Control default color inconsistencies

[Gary L. Wade]

Set the background color of self.view to something other than black and your 
button and label will be more visible. I believe the color for your table view 
is a UIColor defined as a category in UITableView.h or close to there.
--
Gary L. Wade (Sent from my iPad)
http://www.garywade.com/

> On Dec 14, 2016, at 9:38 AM, Andreas Falkenhahn  
> wrote:
> 
>> On 14.12.2016 at 17:54 じょいすじょん wrote:
>> 
>> Nobody can guess what you are actually doing.
>> Please share some code so people can help you.
> 
> There is not much code to share. My code just creates UILabel, UIButton,
> and UITableView with absolutely minimal customization, the intention
> being to check out the default look of those controls. But, as I wrote in
> my last mail, this default look is pretty confusing and irritating because
> background and foreground color aren't consistent at all.
> 
> I'd like to avoid hard-coding specific colors as this is bad GUI coding
> practice on the desktop systems I come from. I'd like iOS to use the
> default colors instead but I'm not sure how to do this.
> 
> For reference, here is how I create the objects:
> 
>UIScreen *myScreen = [UIScreen mainScreen];
>CGRect rect = [myScreen bounds];
> 
>// results in a UILabel that has black background and foreground, i.e. 
> text is unreadable
>UILabel *header1 = [[UILabel alloc] initWithFrame:CGRectMake(0, 0, 
> rect.size.width, 48)];
>header1.text = @"Label test";
>[self.view addSubview:header1];
> 
>// results in gray background with black text
>UITableView *tableView = [[UITableView alloc] 
> initWithFrame:CGRectMake(0, 48, rect.size.width, rect.size.height - (48 + 
> 80))];
>tableView.dataSource = self;
>tableView.delegate = self;
>tableView.autoresizingMask = 
> UIViewAutoresizingFlexibleHeight|UIViewAutoresizingFlexibleWidth;
>[tableView registerClass:[UITableViewCell class] 
> forCellReuseIdentifier:@"Cell"];
>[tableView reloadData];
>[self.view addSubview:tableView];
> 
>// results in black background with blue label text
>UIButton *optionsButton = [UIButton 
> buttonWithType:UIButtonTypeRoundedRect];
>[optionsButton addTarget:self action:@selector(clickOptions:) 
> forControlEvents:UIControlEventTouchUpInside];
>[optionsButton setFrame:CGRectMake(0, rect.size.height - 80, 
> rect.size.width, 80)];
>[optionsButton setTitle:@"Button test" forState:UIControlStateNormal];
>[optionsButton setExclusiveTouch:YES];
>[self.view addSubview:optionsButton];
> 
> The controls are created in a UIViewController inside the viewDidLoad() 
> method. This
> UIViewController is then set as the UIWindow's rootViewController.
> 
> -- 
> Best regards,
> Andreas Falkenhahnmailto:andr...@falkenhahn.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

Re: Control default color inconsistencies

[Quincey Morris]

On Dec 14, 2016, at 09:38 , Andreas Falkenhahn  wrote:
> 
> But, as I wrote in
> my last mail, this default look is pretty confusing and irritating because
> background and foreground color aren't consistent at all.

You’re assuming that the “default” colors of the various controls (the colors 
you get if you don’t configure colors) are supposed to be the “standard” 
colors. What you’ve discovered is that this isn’t true. When you create 
controls programmatically, you take on the responsibility of deciding how your 
app should look. If you decide it should look like other apps, then it’s also 
your responsibility to implement that. If you implement that, it’s also your 
responsibility to change your app when the look of the rest of the apps changes 
with the iOS version.

Looking at these controls as configured by IB, I see that the "IB default" is 
typically a clear background. 

— I’m not sure why your UILabel defaults to the same color as the foreground, 
but I don’t see why you should be concerned about programmatically setting its 
background color to clear. The IB default foreground color is black.

— The IB default background for a UIView is gray, and the IB default background 
for a UITableView is clear. Cell views in IB have a white background. That 
means that section headers and footers let the gray background show through, 
and details rows have white backgrounds.

— The IB default color for button text is the tint color, which happens to be 
blue.

According to that information, you should set the UILabel background to clear 
or white, and set your cell view backgrounds to white, and leave everything 
else alone.

Also, take a look at view appearances. You might be able to use that API to 
ensure a consist look for all your controls without configuring every property 
manually for each UIControl instance.

I’d emphasize that if you set colors manually, you can’t necessarily expect 
that iOS will adjust your colors for new system designs in the future, whereas 
it may do this for apps that use IB-configured controls. That’s something you 
might lose by opting out of IB.
___

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: Users default alert sound

[Sandor Szatmari]

I didn't know that automatically played the configured sound.  That's great 
thanks!  I knew I was missing something straightforward.

Sandor

> On Dec 14, 2016, at 12:58, Quincey Morris 
>  wrote:
> 
>> On Dec 14, 2016, at 09:45 , Sandor Szatmari  
>> wrote:
>> 
>> I am currently using [NSSound soundNamed:] to play any arbitrary sound.  But 
>> I want to play the one configured in System Preferences.
> 
> You can use the NSBeep () global function to play the configured alert sound. 
> I don’t know if there’s an API to get its file name — it’s not obvious that 
> it is even a separate file, always.
> 
___

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: Autolayout warnings

[Doug Hill]

Quincey,

Thanks for the reply.

> On Dec 14, 2016, at 2:40 PM, Quincey Morris 
>  wrote:
> 
> On Dec 14, 2016, at 14:19 , Doug Hill  > wrote:
>> 
>>"> UIView:0x7f91426d9db0.width == 0.33*UIView:0x7f91426def30.width>",
>>"> H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>",
>>"> UIView:0x7f91426d9db0.trailing == UIView:0x7f91426d7f00.trailing>",
>>"> H:[UIView:0x7f91426def30(768)]>"
> 
> It kinda looks like the conflict is between the first and last of these. When 
> you move the comments view off to the trailing edge of what it’s aligned to, 
> you seem to be making the enclosing view wider according to some combination 
> of constraints, which violates the constraint (the last one) saying that the 
> enclosing view is 768 pts wide.

The funky  UIView-Encapsulated-Layout-Width constraint is not mine and I don't 
set it to 768. Not sure what it is.

> Can you set the comment view to 0 width when you hide it? That would probably 
> eliminate the problem, although a different approach might be preferable. 
> (For example, use conditional constraints on the view that expands to fill 
> the space occupied by the comment view, relative to the enclosing view, and 
> hide the comment view instead of moving it.)

I actually put a lot of time into trying to figure out how to architect the 
autolayout constraints to make everything move together using. This scheme 
seems good because, by not shrinking the container (which has a table view 
inside), it doesn't cause the table to relayout. But I'll try some of your 
techniques too.

Doug Hill
___

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: Autolayout warnings

[Quincey Morris]

On Dec 14, 2016, at 14:19 , Doug Hill  wrote:
> 
>" UIView:0x7f91426d9db0.width == 0.33*UIView:0x7f91426def30.width>",
>" H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>",
>" UIView:0x7f91426d9db0.trailing == UIView:0x7f91426d7f00.trailing>",
>" H:[UIView:0x7f91426def30(768)]>"

It kinda looks like the conflict is between the first and last of these. When 
you move the comments view off to the trailing edge of what it’s aligned to, 
you seem to be making the enclosing view wider according to some combination of 
constraints, which violates the constraint (the last one) saying that the 
enclosing view is 768 pts wide.

Can you set the comment view to 0 width when you hide it? That would probably 
eliminate the problem, although a different approach might be preferable. (For 
example, use conditional constraints on the view that expands to fill the space 
occupied by the comment view, relative to the enclosing view, and hide the 
comment view instead of moving it.)
___

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: Autolayout warnings

[Doug Hill]

> On Dec 14, 2016, at 2:46 PM, Ken Thomases  wrote:
> 
> On Dec 14, 2016, at 4:19 PM, Doug Hill  wrote:
>> 
>> I'm seeing warnings in the console when I dynamically make autolayout 
>> constraints active/inactive at runtime.
>> 
>> I have two constraints that align a container view leading or trailing edge 
>> with another view's edge. This is to move the container onscreen or 
>> offscreen. I have another view whose trailing edge aligns with the leading 
>> edge of the first container view so it moves with it as autolayout 
>> constraints change.
>> 
>> At runtime, I make one of these constraints active and the other inactive, 
>> like so:
> 
>> - (IBAction)showComments:(id)sender
>> {
>>  self.showCommentsConstraint.active = YES;
>>  self.hideCommentsContainerConstraint.active = NO;
> 
> Swap the order of these.  Always disable no-longer-applicable constraints 
> before enabling newly-applicable constraints.  The way you have it here, 
> after the first line, you temporarily have constraints which conflict 
> enabled.  You fix that with the next line, but you've already gotten the 
> warning by then.

Ding-Ding-Ding-Ding-Ding-Ding! We have a winner!

I went ahead and made this change and warnings are gone. Will keep the order of 
activation in mind for future coding.

Doug Hill
___

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: Autolayout warnings

[Doug Hill]

Ok, this is more good information to keep in mind when designing autolayout 
constraints. Given that my design isn't animatable, it's back to the autolayout 
drawing board. Again.

Doug Hill


> On Dec 14, 2016, at 3:07 PM, Gary L. Wade  
> wrote:
> 
> Right, activate and deactivate are not animatable, but the constant values in 
> constraints are.
> 
> True, it depends on what you’re showing as to whether to shrink or move your 
> view.  When I wanted to use a search bar in UISearchController with a 
> collection view in iOS to appear similarly as UITableView, I moved the search 
> bar:
> 
> https://whatweretheythinkingblog.wordpress.com/2016/11/19/effectively-using-uisearchcontroller-with-uicollectionview/
>  
> 
> 
> When I wanted to show an icon to the left of a title, where the item may not 
> have an icon but was only available through a REST call, I found it more 
> attractive to grow the icon and compress the title in that animation, 
> choosing a scale-to-fill option, when I determined there was an icon.
> --
> Gary L. Wade
> http://www.garywade.com/ 
>> On Dec 14, 2016, at 2:52 PM, Doug Hill > > wrote:
>> 
>> Gary,
>> 
>> Thanks for the reply.
>> I tried moving the container rather than resizing to 0 because there's a 
>> table inside this view and it will relayout when resizing. For an animation, 
>> I guess it depends on what effect you want: either seeing the view move or 
>> resize to 0.
>> 
>> Oddly, when I put my code to activate/deactivate constraints inside a 
>> [UIView animateWithDuration…] I get no animation. :(
>> 
>> Doug Hill
>> 
>>> On Dec 14, 2016, at 2:49 PM, Gary L. Wade >> > wrote:
>>> 
>>> If I understand you correctly, you might prefer the approach I chose to do. 
>>>  Rather than activating and deactivating constraints (BTW, you should 
>>> always deactivate before having multiple actives), set your constraints up 
>>> to always be active but change the width for the one you’re hiding to 0 and 
>>> the other to be the extra size needed to fill the gap.  I also chose to 
>>> animate the constant values, so the size-change is smooth to the user.
>>> --
>>> Gary L. Wade
>>> http://www.garywade.com/ 
 On Dec 14, 2016, at 2:19 PM, Doug Hill > wrote:
 
 I'm seeing warnings in the console when I dynamically make autolayout 
 constraints active/inactive at runtime.
 
 I have two constraints that align a container view leading or trailing 
 edge with another view's edge. This is to move the container onscreen or 
 offscreen. I have another view whose trailing edge aligns with the leading 
 edge of the first container view so it moves with it as autolayout 
 constraints change.
 
 At runtime, I make one of these constraints active and the other inactive, 
 like so:
 
 - (IBAction)toggleCommentsVisibility:(id)sender
 {
self.commentsAreHidden ? [self showComments:self] : [self 
 hideComments:self]; 
 }
 
 - (IBAction)showComments:(id)sender
 {
self.showCommentsConstraint.active = YES;
self.hideCommentsContainerConstraint.active = NO;
 
self.commentsAreHidden = NO;
 }
 
 - (IBAction)hideComments:(id)sender
 {
self.showCommentsConstraint.active = NO;
self.hideCommentsContainerConstraint.active = YES;
 
self.commentsAreHidden = YES;
 }
 
 When I call showComments, I get the following warning in the console:
 
 =
 
 Unable to simultaneously satisfy constraints.
 Probably at least one of the constraints in the following list is one you 
 don't want. 
 Try this: 
(1) look at each constraint and try to figure out which you don't 
 expect; 
(2) find the code that added the unwanted constraint or constraints and 
 fix it. 
 (
">>> UIView:0x7f91426d9db0.width == 0.33*UIView:0x7f91426def30.width>",
">>> H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>",
">>> UIView:0x7f91426d9db0.trailing == UIView:0x7f91426d7f00.trailing>",
">>> H:[UIView:0x7f91426def30(768)]>"
 )
 
 Will attempt to recover by breaking constraint 
 >>> H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>
 
 Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to 
 catch this in the debugger.
 
 =
 
 This is puzzling because IB doesn't give me any autolayout errors/warning 
 when I manually activate/deactivate these constraints. Also, I don't get 
 this runtime warning when calling hideComments, only the 'show' case. 

Re: Autolayout warnings

[Doug Hill]

Gary,

Thanks for the reply.
I tried moving the container rather than resizing to 0 because there's a table 
inside this view and it will relayout when resizing. For an animation, I guess 
it depends on what effect you want: either seeing the view move or resize to 0.

Oddly, when I put my code to activate/deactivate constraints inside a [UIView 
animateWithDuration…] I get no animation. :(

Doug Hill

> On Dec 14, 2016, at 2:49 PM, Gary L. Wade  
> wrote:
> 
> If I understand you correctly, you might prefer the approach I chose to do.  
> Rather than activating and deactivating constraints (BTW, you should always 
> deactivate before having multiple actives), set your constraints up to always 
> be active but change the width for the one you’re hiding to 0 and the other 
> to be the extra size needed to fill the gap.  I also chose to animate the 
> constant values, so the size-change is smooth to the user.
> --
> Gary L. Wade
> http://www.garywade.com/ 
>> On Dec 14, 2016, at 2:19 PM, Doug Hill > > wrote:
>> 
>> I'm seeing warnings in the console when I dynamically make autolayout 
>> constraints active/inactive at runtime.
>> 
>> I have two constraints that align a container view leading or trailing edge 
>> with another view's edge. This is to move the container onscreen or 
>> offscreen. I have another view whose trailing edge aligns with the leading 
>> edge of the first container view so it moves with it as autolayout 
>> constraints change.
>> 
>> At runtime, I make one of these constraints active and the other inactive, 
>> like so:
>> 
>> - (IBAction)toggleCommentsVisibility:(id)sender
>> {
>>  self.commentsAreHidden ? [self showComments:self] : [self 
>> hideComments:self]; 
>> }
>> 
>> - (IBAction)showComments:(id)sender
>> {
>>  self.showCommentsConstraint.active = YES;
>>  self.hideCommentsContainerConstraint.active = NO;
>> 
>>  self.commentsAreHidden = NO;
>> }
>> 
>> - (IBAction)hideComments:(id)sender
>> {
>>  self.showCommentsConstraint.active = NO;
>>  self.hideCommentsContainerConstraint.active = YES;
>> 
>>  self.commentsAreHidden = YES;
>> }
>> 
>> When I call showComments, I get the following warning in the console:
>> 
>> =
>> 
>> Unable to simultaneously satisfy constraints.
>> Probably at least one of the constraints in the following list is one you 
>> don't want. 
>> Try this: 
>>  (1) look at each constraint and try to figure out which you don't 
>> expect; 
>>  (2) find the code that added the unwanted constraint or constraints and 
>> fix it. 
>> (
>>"> UIView:0x7f91426d9db0.width == 0.33*UIView:0x7f91426def30.width>",
>>"> H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>",
>>"> UIView:0x7f91426d9db0.trailing == UIView:0x7f91426d7f00.trailing>",
>>"> H:[UIView:0x7f91426def30(768)]>"
>> )
>> 
>> Will attempt to recover by breaking constraint 
>> > H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>
>> 
>> Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to 
>> catch this in the debugger.
>> 
>> =
>> 
>> This is puzzling because IB doesn't give me any autolayout errors/warning 
>> when I manually activate/deactivate these constraints. Also, I don't get 
>> this runtime warning when calling hideComments, only the 'show' case. 
>> Finally, things actually work at runtime because it's nice enough to "break" 
>> the constraint that I deactivated in code. But I would like to not have 
>> these warnings.
>> 
>> Any ideas on what's going on how I might go about debugging this?
>> 
>> Doug Hill
>> ___
>> 
>> 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/garywade%40desisoftsystems.com
>>  
>> 
>> 
>> This email sent to garyw...@desisoftsystems.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

Re: Autolayout warnings

[Ken Thomases]

On Dec 14, 2016, at 5:15 PM, Doug Hill  wrote:
> 
> Ok, this is more good information to keep in mind when designing autolayout 
> constraints. Given that my design isn't animatable, it's back to the 
> autolayout drawing board. Again.

I think it works to animate a change of constraints if you do the 
-layoutIfNeeded on the window within the animation context.  It's technically 
animating the frame changes rather than the constraints, which can transition 
through some different states and even temporarily violate constraints, but for 
this case it should work.

Regards,
Ken


___

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: Autolayout warnings

[Doug Hill]

Great, more good stuff to know!

However, trying this out I see that some views animate and others don't (just 
jump into place). I guess I'll look into a more animatable design.

Doug Hill

> On Dec 14, 2016, at 3:24 PM, Ken Thomases  wrote:
> 
> On Dec 14, 2016, at 5:15 PM, Doug Hill  wrote:
>> 
>> Ok, this is more good information to keep in mind when designing autolayout 
>> constraints. Given that my design isn't animatable, it's back to the 
>> autolayout drawing board. Again.
> 
> I think it works to animate a change of constraints if you do the 
> -layoutIfNeeded on the window within the animation context.  It's technically 
> animating the frame changes rather than the constraints, which can transition 
> through some different states and even temporarily violate constraints, but 
> for this case it should work.
> 
> Regards,
> Ken
> 


___

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: Users default alert sound

[Sandor Szatmari]

Bonus!  Thanks for sharing!

Sandor

> On Dec 14, 2016, at 17:03, Britt Durbrow 
>  wrote:
> 
> Also, not everyone *has* a sound that plays… if the volume is turned all the 
> way down, or if they have a hearing issue, for example, they will often have 
> the screen flash turned on; calling NSBeep() triggers this correctly.
> 
> 
> 
>> On Dec 14, 2016, at 10:51 AM, Sandor Szatmari  
>> wrote:
>> 
>> I didn't know that automatically played the configured sound.  That's great 
>> thanks!  I knew I was missing something straightforward.
>> 
>> Sandor
>> 
 On Dec 14, 2016, at 12:58, Quincey Morris 
  wrote:
 
 On Dec 14, 2016, at 09:45 , Sandor Szatmari  
 wrote:
 
 I am currently using [NSSound soundNamed:] to play any arbitrary sound.  
 But I want to play the one configured in System Preferences.
>>> 
>>> You can use the NSBeep () global function to play the configured alert 
>>> sound. I don’t know if there’s an API to get its file name — it’s not 
>>> obvious that it is even a separate file, always.
>>> 
>> ___
>> 
>> 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/bdurbrow%40rattlesnakehillsoftworks.com
>> 
>> This email sent to bdurb...@rattlesnakehillsoftworks.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/admin.szatmari.net%40gmail.com
> 
> This email sent to admin.szatmari@gmail.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

Re: Autolayout warnings

[Ken Thomases]

On Dec 14, 2016, at 4:19 PM, Doug Hill  wrote:
> 
> I'm seeing warnings in the console when I dynamically make autolayout 
> constraints active/inactive at runtime.
> 
> I have two constraints that align a container view leading or trailing edge 
> with another view's edge. This is to move the container onscreen or 
> offscreen. I have another view whose trailing edge aligns with the leading 
> edge of the first container view so it moves with it as autolayout 
> constraints change.
> 
> At runtime, I make one of these constraints active and the other inactive, 
> like so:

> - (IBAction)showComments:(id)sender
> {
>   self.showCommentsConstraint.active = YES;
>   self.hideCommentsContainerConstraint.active = NO;

Swap the order of these.  Always disable no-longer-applicable constraints 
before enabling newly-applicable constraints.  The way you have it here, after 
the first line, you temporarily have constraints which conflict enabled.  You 
fix that with the next line, but you've already gotten the warning by then.

> 
>   self.commentsAreHidden = NO;
> }

Regards,
Ken


___

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: Autolayout warnings

[Gary L. Wade]

If I understand you correctly, you might prefer the approach I chose to do.  
Rather than activating and deactivating constraints (BTW, you should always 
deactivate before having multiple actives), set your constraints up to always 
be active but change the width for the one you’re hiding to 0 and the other to 
be the extra size needed to fill the gap.  I also chose to animate the constant 
values, so the size-change is smooth to the user.
--
Gary L. Wade
http://www.garywade.com/ 
> On Dec 14, 2016, at 2:19 PM, Doug Hill  wrote:
> 
> I'm seeing warnings in the console when I dynamically make autolayout 
> constraints active/inactive at runtime.
> 
> I have two constraints that align a container view leading or trailing edge 
> with another view's edge. This is to move the container onscreen or 
> offscreen. I have another view whose trailing edge aligns with the leading 
> edge of the first container view so it moves with it as autolayout 
> constraints change.
> 
> At runtime, I make one of these constraints active and the other inactive, 
> like so:
> 
> - (IBAction)toggleCommentsVisibility:(id)sender
> {
>   self.commentsAreHidden ? [self showComments:self] : [self 
> hideComments:self]; 
> }
> 
> - (IBAction)showComments:(id)sender
> {
>   self.showCommentsConstraint.active = YES;
>   self.hideCommentsContainerConstraint.active = NO;
> 
>   self.commentsAreHidden = NO;
> }
> 
> - (IBAction)hideComments:(id)sender
> {
>   self.showCommentsConstraint.active = NO;
>   self.hideCommentsContainerConstraint.active = YES;
> 
>   self.commentsAreHidden = YES;
> }
> 
> When I call showComments, I get the following warning in the console:
> 
> =
> 
> Unable to simultaneously satisfy constraints.
> Probably at least one of the constraints in the following list is one you 
> don't want. 
> Try this: 
>   (1) look at each constraint and try to figure out which you don't 
> expect; 
>   (2) find the code that added the unwanted constraint or constraints and 
> fix it. 
> (
>" UIView:0x7f91426d9db0.width == 0.33*UIView:0x7f91426def30.width>",
>" H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>",
>" UIView:0x7f91426d9db0.trailing == UIView:0x7f91426d7f00.trailing>",
>" H:[UIView:0x7f91426def30(768)]>"
> )
> 
> Will attempt to recover by breaking constraint 
>  H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>
> 
> Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch 
> this in the debugger.
> 
> =
> 
> This is puzzling because IB doesn't give me any autolayout errors/warning 
> when I manually activate/deactivate these constraints. Also, I don't get this 
> runtime warning when calling hideComments, only the 'show' case. Finally, 
> things actually work at runtime because it's nice enough to "break" the 
> constraint that I deactivated in code. But I would like to not have these 
> warnings.
> 
> Any ideas on what's going on how I might go about debugging this?
> 
> Doug Hill
> ___
> 
> 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/garywade%40desisoftsystems.com
> 
> This email sent to garyw...@desisoftsystems.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

Re: Autolayout warnings

[Gary L. Wade]

Right, activate and deactivate are not animatable, but the constant values in 
constraints are.

True, it depends on what you’re showing as to whether to shrink or move your 
view.  When I wanted to use a search bar in UISearchController with a 
collection view in iOS to appear similarly as UITableView, I moved the search 
bar:

https://whatweretheythinkingblog.wordpress.com/2016/11/19/effectively-using-uisearchcontroller-with-uicollectionview/

When I wanted to show an icon to the left of a title, where the item may not 
have an icon but was only available through a REST call, I found it more 
attractive to grow the icon and compress the title in that animation, choosing 
a scale-to-fill option, when I determined there was an icon.
--
Gary L. Wade
http://www.garywade.com/ 
> On Dec 14, 2016, at 2:52 PM, Doug Hill  wrote:
> 
> Gary,
> 
> Thanks for the reply.
> I tried moving the container rather than resizing to 0 because there's a 
> table inside this view and it will relayout when resizing. For an animation, 
> I guess it depends on what effect you want: either seeing the view move or 
> resize to 0.
> 
> Oddly, when I put my code to activate/deactivate constraints inside a [UIView 
> animateWithDuration…] I get no animation. :(
> 
> Doug Hill
> 
>> On Dec 14, 2016, at 2:49 PM, Gary L. Wade > > wrote:
>> 
>> If I understand you correctly, you might prefer the approach I chose to do.  
>> Rather than activating and deactivating constraints (BTW, you should always 
>> deactivate before having multiple actives), set your constraints up to 
>> always be active but change the width for the one you’re hiding to 0 and the 
>> other to be the extra size needed to fill the gap.  I also chose to animate 
>> the constant values, so the size-change is smooth to the user.
>> --
>> Gary L. Wade
>> http://www.garywade.com/ 
>>> On Dec 14, 2016, at 2:19 PM, Doug Hill >> > wrote:
>>> 
>>> I'm seeing warnings in the console when I dynamically make autolayout 
>>> constraints active/inactive at runtime.
>>> 
>>> I have two constraints that align a container view leading or trailing edge 
>>> with another view's edge. This is to move the container onscreen or 
>>> offscreen. I have another view whose trailing edge aligns with the leading 
>>> edge of the first container view so it moves with it as autolayout 
>>> constraints change.
>>> 
>>> At runtime, I make one of these constraints active and the other inactive, 
>>> like so:
>>> 
>>> - (IBAction)toggleCommentsVisibility:(id)sender
>>> {
>>> self.commentsAreHidden ? [self showComments:self] : [self 
>>> hideComments:self]; 
>>> }
>>> 
>>> - (IBAction)showComments:(id)sender
>>> {
>>> self.showCommentsConstraint.active = YES;
>>> self.hideCommentsContainerConstraint.active = NO;
>>> 
>>> self.commentsAreHidden = NO;
>>> }
>>> 
>>> - (IBAction)hideComments:(id)sender
>>> {
>>> self.showCommentsConstraint.active = NO;
>>> self.hideCommentsContainerConstraint.active = YES;
>>> 
>>> self.commentsAreHidden = YES;
>>> }
>>> 
>>> When I call showComments, I get the following warning in the console:
>>> 
>>> =
>>> 
>>> Unable to simultaneously satisfy constraints.
>>> Probably at least one of the constraints in the following list is one you 
>>> don't want. 
>>> Try this: 
>>> (1) look at each constraint and try to figure out which you don't 
>>> expect; 
>>> (2) find the code that added the unwanted constraint or constraints and 
>>> fix it. 
>>> (
>>>">> UIView:0x7f91426d9db0.width == 0.33*UIView:0x7f91426def30.width>",
>>>">> H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>",
>>>">> UIView:0x7f91426d9db0.trailing == UIView:0x7f91426d7f00.trailing>",
>>>">> H:[UIView:0x7f91426def30(768)]>"
>>> )
>>> 
>>> Will attempt to recover by breaking constraint 
>>> >> H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>
>>> 
>>> Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to 
>>> catch this in the debugger.
>>> 
>>> =
>>> 
>>> This is puzzling because IB doesn't give me any autolayout errors/warning 
>>> when I manually activate/deactivate these constraints. Also, I don't get 
>>> this runtime warning when calling hideComments, only the 'show' case. 
>>> Finally, things actually work at runtime because it's nice enough to 
>>> "break" the constraint that I deactivated in code. But I would like to not 
>>> have these warnings.
>>> 
>>> Any ideas on what's going on how I might go about debugging this?
>>> 
>>> Doug Hill
>>> ___
>>> 
>>> 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 

Re: Autolayout warnings

[Gary L. Wade]

In case it helps with your future animatable design, my particular app has a 
layout kind of like this:

——
| | (8 points separation)Title (could be long)
| | (8 points separation)Subtitle (could be long)
—— 

and I used something like this in viewDidLoad to preserve the values before I 
had any data:

-(void)viewDidLoad
{
self.iconIndicatorWidthOriginalConstant =
self.iconIndicatorWidth.constant;
self.iconTitleLabelLeadingOriginalConstant =
self.iconTitleLabelLeading.constant;
self.iconSubtitleLabelLeadingOriginalConstant =
self.iconSubtitleLabelLeading.constant;

self.iconIndicatorWidth.constant = 0;
}

and I used something like this when I knew whether or not I wanted to show the 
icon indicator (the box to the left of the title and subtitle):

-(void)updateUI:(BOOL )showIconIndicator
{
CGFloat newIconIndicatorWidthConstant;
CGFloat newIconTitleLabelLeadingConstant;
CGFloat newIconSubtitleLabelLeadingConstant;

if (showIconIndicator)
{
newIconIndicatorWidthConstant =
self.iconIndicatorWidthOriginalConstant;
newIconTitleLabelLeadingConstant =
self.iconTitleLabelLeadingOriginalConstant +
self.iconIndicatorWidthOriginalConstant + 8;
newIconSubtitleLabelLeadingConstant =
self.iconSubtitleLabelLeadingOriginalConstant +
self.iconIndicatorWidthOriginalConstant + 8;
}
else
{
newIconIndicatorWidthConstant = 0;
newIconTitleLabelLeadingConstant =
self.iconTitleLabelLeadingOriginalConstant;
newIconSubtitleLabelLeadingConstant =
self.iconSubtitleLabelLeadingOriginalConstant;
}

if (newIconIndicatorWidthConstant != self.iconIndicatorWidth.constant)
{
[self.iconIndicator.superview layoutIfNeeded];
[UIView animateWithDuration:0.3 animations:
^{
self.iconIndicatorWidth.constant =
newIconIndicatorWidthConstant;
self.iconTitleLabelLeading.constant =
newIconTitleLabelLeadingConstant;
self.iconSubtitleLabelLeading.constant =
newIconSubtitleLabelLeadingConstant;

[self.iconIndicator.superview layoutIfNeeded];
}];
}
}

--
Gary L. Wade
http://www.garywade.com/ 
> On Dec 14, 2016, at 3:39 PM, Doug Hill  wrote:
> 
> Great, more good stuff to know!
> 
> However, trying this out I see that some views animate and others don't (just 
> jump into place). I guess I'll look into a more animatable design.
> 
> Doug Hill
> 
>> On Dec 14, 2016, at 3:24 PM, Ken Thomases  wrote:
>> 
>> On Dec 14, 2016, at 5:15 PM, Doug Hill  wrote:
>>> 
>>> Ok, this is more good information to keep in mind when designing autolayout 
>>> constraints. Given that my design isn't animatable, it's back to the 
>>> autolayout drawing board. Again.
>> 
>> I think it works to animate a change of constraints if you do the 
>> -layoutIfNeeded on the window within the animation context.  It's 
>> technically animating the frame changes rather than the constraints, which 
>> can transition through some different states and even temporarily violate 
>> constraints, but for this case it should work.
>> 
>> Regards,
>> Ken
>> 
> 

___

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

Users default alert sound

[Sandor Szatmari]

How do you determine the name of the sound as configured in 'System 
Preferences' > Sound > 'Sound Effects' > 'Select an alert sound:'?

What I'm trying to do:  I want to play the alert sound under certain 
circumstances.

I am currently using [NSSound soundNamed:] to play any arbitrary sound.  But I 
want to play the one configured in System Preferences.

Thanks,
Sandor
___

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: Control default color inconsistencies

[Andreas Falkenhahn]

On 14.12.2016 at 18:41 Alex Zavatone wrote:

> On Dec 14, 2016, at 9:47 AM, Andreas Falkenhahn wrote:

> I'm creating my GUI programmatically. It simply consists of a UILabel,
> a UITableView and two UIButtons.

> Mac OS or iOS?  Please state the specifics first so that we can
> stop reading if we don't have experience in the area of your problem.  Thanks.

Huh? Aren't UIButton and UITableView iOS-specific with NSButton and
NSTableView being the macOS equivalents?

But to answer your question: It's iOS but I thought you could've guessed
that because AFAIU UIButton and the likes are UIKit which is iOS.

-- 
Best regards,
 Andreas Falkenhahnmailto:andr...@falkenhahn.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

Re: Control default color inconsistencies

[Gary L. Wade]

Seeing code and how you have things visually laid out will help, but most 
likely what you think are black backgrounds may be clear backgrounds showing 
through to another view or super view that has black as its background color. 
You may have very valid reasons for doing this in code, but before doing that, 
try working through things in Interface Builder first so you get an idea of 
what you need to do.
--
Gary L. Wade (Sent from my iPad)
http://www.garywade.com/

> On Dec 14, 2016, at 7:47 AM, Andreas Falkenhahn  
> wrote:
> 
> I'm creating my GUI programmatically. It simply consists of a UILabel,
> a UITableView and two UIButtons.
> 
> When creating those three controls I've noticed that they all seem to
> use different color schemes by default which makes the GUI look rather
> silly.
> 
> Here are my observations:
> 
> 1) By default, UILabel seems to set both background and text color to
> black, i.e. nothing is readable before you change the colors to some
> more meaningful values.
> 
> 2) By default, UITableView appears with a gray background and black
> text on top.
> 
> 3) By default, UIButton appears with a black background and blue (!)
> text on top.
> 
> Is there any rationale why all three controls seem to use entirely
> different color schemes by default here? 
> 
> When writing desktop GUIs it's bad practice to use custom color schemes
> because they might clash with the user's theme settings. Doesn't such
> a paradigm apply to iOS as well? Or am I really forced to explicitly
> set foreground and background colors for each UI control? I'd really
> prefer to use the default iOS look instead. On Android I don't have to
> set background and foreground colors either, the OS will automatically
> use some meaningful and consistent (!) default colors.
> 
> This makes me wonder if there is a default iOS color scheme for apps
> at all? Or are all apps supposed to define their own color scheme?
> If there is a default iOS color scheme, why don't the controls use
> it then when not specifying any colors?
> 
> It's all quite confusing... I hope somebody can shed some more light
> onto this. But please no lectures on that I should use Interface Builder,
> Storyboard, or whatever it is called now instead, I really like to do
> things manually - always have, always will ;)
> 
> -- 
> Best regards,
> Andreas Falkenhahn  mailto:andr...@falkenhahn.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

Re: Control default color inconsistencies

[Andreas Falkenhahn]

On 14.12.2016 at 17:54 じょいすじょん wrote:

> Nobody can guess what you are actually doing.
> Please share some code so people can help you.

There is not much code to share. My code just creates UILabel, UIButton,
and UITableView with absolutely minimal customization, the intention
being to check out the default look of those controls. But, as I wrote in
my last mail, this default look is pretty confusing and irritating because
background and foreground color aren't consistent at all.

I'd like to avoid hard-coding specific colors as this is bad GUI coding
practice on the desktop systems I come from. I'd like iOS to use the
default colors instead but I'm not sure how to do this.

For reference, here is how I create the objects:

UIScreen *myScreen = [UIScreen mainScreen];
CGRect rect = [myScreen bounds];

// results in a UILabel that has black background and foreground, i.e. 
text is unreadable
UILabel *header1 = [[UILabel alloc] initWithFrame:CGRectMake(0, 0, 
rect.size.width, 48)];
header1.text = @"Label test";
[self.view addSubview:header1];

// results in gray background with black text
UITableView *tableView = [[UITableView alloc] 
initWithFrame:CGRectMake(0, 48, rect.size.width, rect.size.height - (48 + 80))];
tableView.dataSource = self;
tableView.delegate = self;
tableView.autoresizingMask = 
UIViewAutoresizingFlexibleHeight|UIViewAutoresizingFlexibleWidth;
[tableView registerClass:[UITableViewCell class] 
forCellReuseIdentifier:@"Cell"];
[tableView reloadData];
[self.view addSubview:tableView];

// results in black background with blue label text
UIButton *optionsButton = [UIButton 
buttonWithType:UIButtonTypeRoundedRect];
[optionsButton addTarget:self action:@selector(clickOptions:) 
forControlEvents:UIControlEventTouchUpInside];
[optionsButton setFrame:CGRectMake(0, rect.size.height - 80, 
rect.size.width, 80)];
[optionsButton setTitle:@"Button test" forState:UIControlStateNormal];
[optionsButton setExclusiveTouch:YES];
[self.view addSubview:optionsButton];

The controls are created in a UIViewController inside the viewDidLoad() method. 
This
UIViewController is then set as the UIWindow's rootViewController.

-- 
Best regards,
 Andreas Falkenhahnmailto:andr...@falkenhahn.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

Re: Control default color inconsistencies

[Alex Zavatone]

On Dec 14, 2016, at 9:47 AM, Andreas Falkenhahn wrote:

> I'm creating my GUI programmatically. It simply consists of a UILabel,
> a UITableView and two UIButtons.

Mac OS or iOS?  Please state the specifics first so that we can stop reading if 
we don't have experience in the area of your problem.  Thanks.
___

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