Re: Completely baffled by NSTabViewController + Autolayout
> I am missing something big, because I am having nothing but insane trouble > when trying to get a simple tab view working with autolayout. Every path I > head down > has strange problems. I've tried slimming it down to the smallest test > project and > I'm still confused. That's because you're not using the... ZooLib C++ Cross-Platform Application Framework: http://www.zoolib.org/ The ZooLib Cookbook http://zoolib.soggywizard.com/doc/cookbook/ ZooLib will also make your iOS and Mac OS X apps readily portable to many of the operating system offerings of Apple's friendly competitors. (Soggy Wizard is a brand-new domain however I expect to start my web server by tomorrow afternoon or so.) Have A Nice Day. Michael David Crawford P.E., Consulting Process Architect http://mike.soggywizards.com/ mdcrawf...@gmail.com One Must Not Trifle With Wizards For It Makes Us Soggy And Hard To Light. PS: I've been bleeding in six colors since 1986. On 8/17/15, Seth Willits wrote: > I am missing something big, because I am having nothing but insane trouble > when trying to get a simple tab view working with autolayout. Every path I > head down has strange problems. I've tried slimming it down to the smallest > test project and I'm still confused. > > The problems I'm seeing are randomly positioned views and inconsistent > sizing: > http://www.sethwillits.com/temp/TabViewResizing1.mp4 > > Here's the project: > http://www.sethwillits.com/temp/TabViewResizing.zip > > > The goal of this project as is, is simple: using an NSTabViewController, add > multiple tab view items where each of the items has a view with its own > autolayout-determined fixed size (as in, either an intrinsic content size, > or the constraints of the subviews dictate the size of the view itself.) > **That's it.** And I've been struggling with this for hours. > > In the test project I have two tabs. Each has an NSView subclass that has an > intrinsic size so that the view itself must always be at that size. Those > views are then added to the tabview via tab view items. I expect that the > layout system will resize the views to be at their intrinsic size, and > position them properly within the tab view. > > Instead I'm seeing them a) not always be at their intrinsic size, and b) if > the tab switches in the middle of animating, then it stops at some > interrupted size. > > > Can anyone explain this? > > > > Bonus question: > How am I supposed to get a normal bordered tab view with tabs on top using > an NSTabViewController? Using > NSTabViewControllerTabStyleSegmentedControlOnTop shows the segmented > control, but there's no border? Using NSTabViewControllerTabStyleUnspecified > + tabView.tabViewType = NSTopTabsBezelBorder; is as close as I can get, but > then the tab view item's view placement is wrong? > > > > -- > Seth Willits > > > > > ___ > > 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/mdcrawford%40gmail.com > > This email sent to mdcrawf...@gmail.com -- Michael David Crawford, Consulting Software Engineer mdcrawf...@gmail.com http://www.warplife.com/mdc/ Every Deity Hath the Insight to Foretell the Future Yet G-d Almighty Himself Possesseth Not the Power to Undo the Past. ___ 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
Completely baffled by NSTabViewController + Autolayout
I am missing something big, because I am having nothing but insane trouble when trying to get a simple tab view working with autolayout. Every path I head down has strange problems. I've tried slimming it down to the smallest test project and I'm still confused. The problems I'm seeing are randomly positioned views and inconsistent sizing: http://www.sethwillits.com/temp/TabViewResizing1.mp4 Here's the project: http://www.sethwillits.com/temp/TabViewResizing.zip The goal of this project as is, is simple: using an NSTabViewController, add multiple tab view items where each of the items has a view with its own autolayout-determined fixed size (as in, either an intrinsic content size, or the constraints of the subviews dictate the size of the view itself.) **That's it.** And I've been struggling with this for hours. In the test project I have two tabs. Each has an NSView subclass that has an intrinsic size so that the view itself must always be at that size. Those views are then added to the tabview via tab view items. I expect that the layout system will resize the views to be at their intrinsic size, and position them properly within the tab view. Instead I'm seeing them a) not always be at their intrinsic size, and b) if the tab switches in the middle of animating, then it stops at some interrupted size. Can anyone explain this? Bonus question: How am I supposed to get a normal bordered tab view with tabs on top using an NSTabViewController? Using NSTabViewControllerTabStyleSegmentedControlOnTop shows the segmented control, but there's no border? Using NSTabViewControllerTabStyleUnspecified + tabView.tabViewType = NSTopTabsBezelBorder; is as close as I can get, but then the tab view item's view placement is wrong? -- Seth Willits ___ 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
variadic functions missing in bridgesupport file
Hi I'm trying to use gen_bridge_metadata to create a bridgesupport file for a c library that contains a mixture of variadic and non-variadic functions. The non-variadic functions appear in the bridgesupport xml, but the variadic functions do not. Is this a known limitation? It looks to me like gen_bridge_metadata has some code that mentions variadic functions, but bridgesupportparse.parse does not detect them so they are never logged in the xml. Any advice gratefully received! Cheers Lee ___ 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: Constraints across sibling stack views?
> On Aug 9, 2015, at 10:14 PM, Seth Willits wrote: > > > In my OS X view, I have four popup buttons vertically stacked, each with a > label on the left. The labels all have equal width as each other and are > right-aligned, and the popups all have equal width as well. > > To manage this layout I created four horizontal stack views, one for each > label-popup pair, and placed those four stack views into a vertical stack > view. At this point, the labels are all sized to fit, as are the popups. > > > If I add a constraint that says one label should be equal width to another > popup, I then get a constraint warning that there's a size mismatch for the > label. > > What's the proper way to have these labels all equal width, when they're in > different NSStackViews? Do you mean for the label to be equal width to another label (although it shouldn’t matter, but I just want to make sure I understand from your pictures)? I would expect that to work generically, but I don’t have any particular insight into why it might not. If that fails, you might try doing 2 vertical stacks and using baseline alignments across the vertical stack views instead... > > > What I want: > http://www.sethwillits.com/temp/upshot/upshot_7Yna0OGF.png > > After dumping into stack views: > http://www.sethwillits.com/temp/upshot/upshot_yX7dV6OL.png > > > > -- > Seth Willits > > > > > ___ > > 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/david.duncan%40apple.com > > This email sent to david.dun...@apple.com -- David Duncan ___ 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: Nullability annotation "best practice"
> On Aug 8, 2015, at 1:15 PM, Seth Willits wrote: > > Let's stipulate that _Nullable and _Nonnull are great to have because they > can catch bugs and express API intent better than before, so we want them. > The question is where to put them? > > > _Nullable and _Nonnull make perfect sense to specify in the @interface. Since > those annotations existing in the @interface will produce applicable warnings > and errors in the counterpart @implementation,there's really no _need_ to > respecify them in the @implementation of those same methods. > > It makes sense for private methods to have nullability annotations for all > the same reasons public Now let's assume that private methods aren't > specified in any @interface, even the anonymous one. In that case, those > methods would naturally have no annotations on their parameters or return > values unless they're specified within the @implementation. But specifying > them on the private methods in the @implementation while *not* specifying > them for the public methods in the @implementation is inconsistent and > potentially confusing. > > > So I see two choices here: > > 1) Always add nullability annotations, for all methods and properties in both > the @interface and @implementation. (Private methods may or may not be > declared within @interfaces — but these days I think it's generally not done?) > > 2) Only add nullability annotations in the @interface, and always declare > private methods within an @interface. > > Is there a third choice I'm not thinking of? > > Thoughts? I'm curious how Apple is adopting these annotations themselves. This is my personal opinion, but I would probably annotate everything given time and ability. From my experience, and as others have mentioned it definitely can catch bugs, and will help clarify your thoughts. However, given the verbosity of the syntax compared to Swift, it can be hard to get this done in a large code base. Also something to consider is that you can’t really add it piecemeal – if you add one notation, the compiler will generate warnings for all other declarations, which can cause a lot of warnings. So I would be pragmatic about it at this time. But if it is code you plan to port to Swift (as opposed to rewriting it entirely, but maybe even then) having the information there for you now can be very useful. > > > > -- > Seth Willits > > > > > ___ > > 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/david.duncan%40apple.com > > This email sent to david.dun...@apple.com -- David Duncan ___ 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: Referring to self in property initializer
On 14 Aug 2015, at 8:47 PM, Rick Mann wrote:
>
> So, adding lazy lets it work with the closure (makes self available to the
> closure):
>
> lazy varbackgroundSession : NSURLSession=
> {
...
>
> I really wish you could do lazy let foo = I don't see why the language
> can't support that.
I see your logic: `let` is a constant, guaranteed set before first access (you
can write all the code you want between declaration and access, so long as all
provable execution paths guarantee the constant is initialized). You can’t get
the value of a `lazy` symbol without triggering the initializer and thus
guaranteeing a value exists. So you might as well call it a `let`.
I don’t know enough about the constraints on the compiler or the design of the
language that might make `lazy let` undesirable:
Must a `let` constant’s value be known (and inline-able) immediately _before_
the source requests the access (consequently triggering the initializer)? And
not after the value returns to the code that requests it?
Is it fair to say that even if you can’t access the value _in Swift code_
without triggering, that the value of the symbol does not exist in memory until
it is initialized, and the name for a symbol with a value that can change is
`var`, not `let`?
Is it difficult for the compiler, or confusing to the user, to have `lazy let`
be an exception to the requirement that all ivars (remember `let`s are
notionally not variables at all) must be set before a call out of an `init`?
— F
___
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: Help understanding Apple's approach in documentation a little better.
On Aug 16, 2015, at 2:58 PM, Alex Zavatone wrote: > Would be REALLY nice if there was something visual that simply communicated > to you that they are not for public consumption. > > If I see it in the left pane of the debugger, and no visual indicators are > stating that it's restricted, It's telling us that it's available - unless we > spend the time to look up the internals for everything that's displayed in > the variables pane that exposes an object instanced from a framework class. > > I know it's too simplistic to assume that a color change would be enough and > appropriate to indicate to the programmer that "you can see there, but you > really don't have access to them", but SOME sort of treatment to the private > data would be really nice when displaying it, so that it's painfully obvious > to the developer that it's private freaking data. > > The developer should just have to look and instantly see that it's data > that's used behind the scenes and they can't play with it. > > If the debugger's variable pane exposes it, it's misleading if it doesn't > somehow indicate that it's not for the developer to access. > > At the least, it's confusing, because the docs say it's not supposed to be > there, yet there it is. No, both the headers and docs communicate what's public and what's not; the debugger's variable panel exposes all the properties, public or not. AFAIK there's no Obj-C ivar/property/method runtime attribute that marks that item as public or private, thus the debugger has no means of determining such. As has been mentioned previously, that useful (to you) private methods exist is an implementation detail subject to change in a future OS release. That may have been the best way to implement class functionality at the time, but since the method isn't in the public header or documentation, Apple is free to remove any or all of those private methods at any time or, more problematically, change the behavior of those methods. You can test for the former but not for the latter so you'd have to keep testing your app on every dot-release. Think about this from your own point of view: If you released a framework for developers to use, would you leave in all of your private methods forever even if you made radical internal changes, just so that you didn't break a developer who used one of them? ___ 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
