Thanks all for the input. I ended up keeping file wrappers for the
expensive parts of the bundle, invalidating them when an action takes
place, and that has brought the save time down to an acceptable level in
most cases.
John
--
John Brownie, john_brow...@sil.org or j.brow...@sil.org.pg
Summe
On 24 Jun 2014, at 2:33 pm, Quincey Morris
wrote:
> Sorry, I wasn’t carping at you
Nor I at you - I was just curious as to how the discussion suddenly veered over
into Swift.
> Because Swift is codifying and enforcing Objective-C's designated initializer
> pattern. Similar enforcement in O
On Jun 23, 2014, at 8:16 PM, Graham Cox wrote:
> On 24 Jun 2014, at 11:14 am, Quincey Morris
> wrote:
>> Actually, I understood the thrust of Sean’s question as being that
>> NSWindowController’s initializers don’t follow Swift rules.
>
> Well, Swift wasn't mentioned at all in the OP, but this
On Jun 23, 2014, at 20:16 , Graham Cox wrote:
> And the example code is Obj-C. Why would Swift come into it?
Sorry, I wasn’t carping at you. It just occurred to me that “no one cares” in
the pure Obj-C case — we know that invoking ‘super initWithWindowNibName:’ is
safe, since we’ve all done it
On 24 Jun 2014, at 11:14 am, Quincey Morris
wrote:
> Actually, I understood the thrust of Sean’s question as being that
> NSWindowController’s initializers don’t follow Swift rules.
>
Well, Swift wasn't mentioned at all in the OP, but this was:
> The Obj-C designated initializer rules say
On 24 Jun 2014, at 12:48 pm, Trygve Inda wrote:
> It works fine on my system, but is there any reason Apple will not approve
> of this? The Mach-O code bundle gets loaded into the main app and becomes
> part of it.
>
> Has anyone submitted something to the App Store that works like this?
I ca
I have an app that normally exists as a System Preference Pane. To get it to
work in an app, and share the same code as the prefPane, I built a small
"host" app that simply loads the prefPane (a Mach-O bundle) with:
[self setPaneObject:[[[paneClass alloc] initWithBundle:paneBundle]
autorelease]];
Heh, thanks.
I also wrote a bug to Apple saying I should be able to do this in IB.
On Jun 23, 2014, at 19:04 , Carl Hoefs wrote:
> Relax. You've just helped improve iOS apps all across the globe!
> -Carl
>
> On Jun 23, 2014, at 7:01 PM, Rick Mann wrote:
>
>> A genius wouldn't have spent the
Relax. You've just helped improve iOS apps all across the globe!
-Carl
On Jun 23, 2014, at 7:01 PM, Rick Mann wrote:
> A genius wouldn't have spent the last 2 hours on this...
>
> Especially because I think I've run into this before. Augh, too many projects
> on too many platforms.
>
> On Jun
A genius wouldn't have spent the last 2 hours on this...
Especially because I think I've run into this before. Augh, too many projects
on too many platforms.
On Jun 23, 2014, at 19:00 , Carl Hoefs wrote:
> Ah! You're a genius! It works perfectly!
> -Carl
>
> On Jun 23, 2014, at 6:56 PM, Rick
Ah! You're a genius! It works perfectly!
-Carl
On Jun 23, 2014, at 6:56 PM, Rick Mann wrote:
> Found it! It's "barTintColor"!
>
> Thanks for getting me to look in the headers!
>
> On Jun 23, 2014, at 18:56 , Carl Hoefs wrote:
>
>> -tintColor
>> The tint color to apply to the navigation items
Found it! It's "barTintColor"!
Thanks for getting me to look in the headers!
On Jun 23, 2014, at 18:56 , Carl Hoefs wrote:
> -tintColor
> The tint color to apply to the navigation items and bar button items.
>
> If you do manage to get it working under iOS 7, post it! The white nav bar is
> t
-tintColor
The tint color to apply to the navigation items and bar button items.
If you do manage to get it working under iOS 7, post it! The white nav bar is
the ugliest part of my app!
-Carl
On Jun 23, 2014, at 6:53 PM, Rick Mann wrote:
> iOS 7.1 in the simulator.
>
> On Jun 23, 2014, at 1
iOS 7.1 in the simulator.
On Jun 23, 2014, at 18:52 , Carl Hoefs wrote:
> Are you on iOS 7? You're describing an iOS 6 behavior. Doing the following on
> iOS 7 (in -viewDidLoad):
>
>self.navigationController.navigationBar.tintColor = [UIColor redColor];
>
> has no effect other than changi
Are you on iOS 7? You're describing an iOS 6 behavior. Doing the following on
iOS 7 (in -viewDidLoad):
self.navigationController.navigationBar.tintColor = [UIColor redColor];
has no effect other than changing the text within the bar items. Under iOS 6 it
changed the tint of the entire navig
Before, I had the nav bar as a separate entity in my view hierarchy. Then, I
was able to select it and set the tint color to the color I wanted in IB.
I changed things to a formal UINavigationController stack to make it easier for
my contained class to modify the items in the nav bar, and now th
FWIW, for setting the UINavigationBar color you can specify any color as long
as it's white. The -tintColor method appears to specify the color of the text
within the navbar button items only.
-Carl
On Jun 23, 2014, at 6:08 PM, Rick Mann wrote:
> I'm having a heck of a time setting the tint c
On 24 Jun, 2014, at 9:14 am, Quincey Morris
wrote:
> On Jun 23, 2014, at 17:30 , Graham Cox wrote:
>
>> I interpret that to mean it must call a designated initializer *eventually*,
>> not necessarily directly. Since all -initXXX methods of the superclass must
>> call the superclass's design
On Jun 23, 2014, at 17:30 , Graham Cox wrote:
> I interpret that to mean it must call a designated initializer *eventually*,
> not necessarily directly. Since all -initXXX methods of the superclass must
> call the superclass's designated initializer, your subclass's D.I. can call
> any of the
I'm having a heck of a time setting the tint color for a navigation bar. I
can't set it in IB (my controller is contained in a UINavigationController,
which is embedded in another custom controller). I can't set the tint bar
directly when the root navigation controller is embedded in its contain
I'm trying to implement something like the photos app delete button. I present
the action sheet to confirm deletion, but the sheet is too large for the single
button; there's a larger gap below the button than above it. Any idea what's
going on, or how to address it?
http://cl.ly/image
On 24 Jun 2014, at 10:35 am, Varun Chandramohan
wrote:
> Hi All,
>
> Is there ant simple to have a split header view to generalise sub header?
> Here is an example of what I want to achieve using NSTableHeaderView?
>
> ---
> |header 1 | Common Header Txt
Hi All,
Is there ant simple to have a split header view to generalise sub header? Here
is an example of what I want to achieve using NSTableHeaderView?
---
|header 1 | Common Header Txt |
| |
--
On 24 Jun 2014, at 3:38 am, Sean McBride wrote:
> The Obj-C designated initializer rules say that if a subclass creates a new
> designated initializer that its implementation must call (one of) the
> superclass' designated initializer.
>
> The docs for NSWindowController say initWithWindow: i
On Jun 23, 2014, at 11:38 AM, Sean McBride wrote:
> Hi all,
>
> The Obj-C designated initializer rules say that if a subclass creates a new
> designated initializer that its implementation must call (one of) the
> superclass' designated initializer.
>
> The docs for NSWindowController say init
On Jun 23, 2014, at 16:17 , Luke Hiesterman wrote:
> Because the touch is an instantaneous event, so the selection should show
> immediately. Similarly, you’ll notice when you select a table cell with
> touch, the selection does not animate in - it appears immediately.
I suppose that's true.
Collection view will call setSelected: on the cell inside an animation block if
the selection is an animated one. A selection from a touch is not animated, but
a programmatic selection which does [collectionView selectItemAtIndexPath:path
animated:YES scrollPosition:scrollPosition] will result i
Why is there no -[UICollectionViewCell setSelected:animated]? UITableViewCell
has this.
But the real problem seems to be that when iOS is handling UICollectionView
cell selection, it doesn't set selected on a cell inside an animation block.
Since I don't to participate in the cell-selection pro
On 23 Jun 2014, at 14:38, Sean McBride wrote:
> Hi all,
>
> The Obj-C designated initializer rules say that if a subclass creates a new
> designated initializer that its implementation must call (one of) the
> superclass' designated initializer.
>
> The docs for NSWindowController say initWith
Hi all,
The Obj-C designated initializer rules say that if a subclass creates a new
designated initializer that its implementation must call (one of) the
superclass' designated initializer.
The docs for NSWindowController say initWithWindow: is the (only) designated
initializer.
Countless exa
On Jun 22, 2014, at 8:50 PM, Jim Geist wrote:
> My iOS application needs to keep the device active by disabling the idle
> timer, but dims the display to conserve battery since it will be running for
> long periods. This works fine, but I want to make sure to restore the user’s
> settings if
31 matches
Mail list logo
