NSAlert accessory view fill horizontal space, respecting margins

[Tor Arne Vestbø via Cocoa-dev]

Hi all,

I’m trying to get the accessory view of an NSAlert to layout similarity to the 
the text fields of the messageText and informativeText. That is:


  *Fill the the available horizontal space of the alert, respecting margins
 *   Including accounting for the different margins of the normal and wide 
appearance
  *Overflow any content of the accessory view by increasing its height
 *   Never contributing to increasing the width of the alert itself

But attempts at doing this with auto layout constraints have failed me, as 
merely setting translatesAutoresizingMaskIntoConstraints = NO for my view to 
set up constraints seems to break the margins that NSAlert applies to the 
accessory view, and I don’t know how to restore them.

Looking at the disassembly of NSAlert  
(_buildLayoutConstraintsForWideAppearance e.g.) it seems to use constraint 
based layout, with the accessory view is wrapped inside another view 
(accessoryContainer), but if I print out the constraints of the views in play 
all I see are instances of NSAutoresizingMaskLayoutConstraint. And inspecting 
the views in the hierarchy, they all respond YES to 
translatesAutoresizingMaskIntoConstraints. Perhaps this is a red herring, but 
shouldn’t I be seeing non-autoresizing constants here?

How would one expand the accessory view to fill its superview 
(accessoryContainer), in a way that keeps the accessoryContainer’s position and 
margins in both normal and wide apperance?

Here’s a reproducer of some of the things I’m seeing:


#import 


int main()

{

bool triggerWideApperance = true;

NSString *loremIpsum = @"Lorem ipsum dolor sit amet, consectetur adipiscing 
elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.";

loremIpsum = [@"" stringByPaddingToLength:(triggerWideApperance ? 5 : 1) * 
loremIpsum.length withString:loremIpsum startingAtIndex:0];



NSAlert *alert = [NSAlert new];

alert.messageText = loremIpsum;

alert.informativeText = loremIpsum;



// Attempt 1: Disables the wide alert apperance, making the alert super wide

alert.accessoryView = [NSTextField wrappingLabelWithString:loremIpsum];



// Attempt 2: Retains the wide alert apperance, but loses the left margin 
of the accessory view,

alert.accessoryView = [NSStackView stackViewWithViews:@[

[NSTextField wrappingLabelWithString:loremIpsum]

]];



[alert layout];

[alert runModal];

}

Thanks for any tips or insights on this!

Cheers,
Tor Arne




___

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: ARC and C++ structures

[Tor Arne Vestbø via Cocoa-dev]

On 15 Sep 2021, at 17:39, Matt Jacobson 
mailto:mhjacob...@me.com>> wrote:



On Sep 15, 2021, at 11:21 AM, Tor Arne Vestbø 
mailto:tor.arne.ves...@qt.io>> wrote:


On 14 Sep 2021, at 16:33, Matt Jacobson via Cocoa-dev 
mailto:cocoa-dev@lists.apple.com>> wrote:

By default, when an NSWindow is `-close`d (which can only happen once in its 
lifetime),

Interesting. If the NSWindow is retained elsewhere, can it not be ordered in 
again? Appreciate any details you can provide :)

I was wrong about this detail.  The window can definitely be ordered in again, 
and any subsequent `-close` does *not* issue a `-release`, even if the window 
`isReleasedWhenClosed`.  (How confusing.)

Thanks for the clarification!

Cheers,
Tor Arne
___

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: ARC and C++ structures

[Tor Arne Vestbø via Cocoa-dev]

On 14 Sep 2021, at 16:33, Matt Jacobson via Cocoa-dev 
mailto:cocoa-dev@lists.apple.com>> wrote:

By default, when an NSWindow is `-close`d (which can only happen once in its 
lifetime),

Interesting. If the NSWindow is retained elsewhere, can it not be ordered in 
again? Appreciate any details you can provide :)

Cheers,
Tor Arne


___

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: Future of Cocoa #2

[Tor Arne Vestbø via Cocoa-dev]

> On 11 Dec 2019, at 21:35, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> 
>> QT is probably the most viable cross-platform tool, but steep learning
>> curve and mediocre GUI.  Will it survive if Cocoa is deprecated?
> 
> Good question - I have no idea.
> 
> But I suggest you reach out to the support, or ask on Qt's forums about 
> roadmaps,
> or meet them in person at an expo/conference (I met them a few years ago at 
> Siggraph).

It will. 

Qt has survived Carbon removal, 32-bit-removal, and will stay on macOS 
regardless of the underlying Apple technologies used to implement the Qt 
platform layers.

Cheers,
Tor Arne

___

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: lockFocusIfCanDraw behavior in layer-backed mode

[Tor Arne Vestbø]

Thank you Matt for a very detailed and thorough reply! This is very useful and 
clarifying information.

> On 17 Dec 2018, at 20:39, Matt Jacobson  wrote:
> 
> Even if it were, it’s still unsafe to ignore the rect passed to -drawRect:.  
> That’s because the system might require you to redraw a larger area than what 
> your code thinks needs to be redrawn.

Speaking of this, getRectsBeingDrawn: doesn’t seem to work outside of 
drawRect:, e.g. in displayLayer:. Is there any way to get at CA/AppKit’s view 
of what needs redrawn another way? Without this information we’re forced to do 
full updates on every repaint, even when originating from say 
setNeedsDisplayInRect:CGRectMake(50, 50, 10, 10).

>> (I know this is a bad ida, but) is there a way to achieve the same 
>> synchronous flush with layer-backing?
> 
> No.
> 
> The imperative view drawing model you’re describing has long been 
> discouraged.  Among others problems, imperative drawing disrupts the drawing 
> of overlapping views (both siblings and superview–subview pairs), is 
> incompatible with layer-backed views, and prevents system drawing 
> optimizations.

Right. We are aware of the situation. Unfortunately Qt’s Widget module assumes 
an imperative drawing model. 

During AppKit driven updates the flow goes something like this:

- [QNSView drawRect:] or [QNSView displayLayer:] (depending on whether 
layer-backing is enabled or not)
- QCocoaWindow::handleExposeEvent(dirtyRegion)
- QWidgetBackingStore::beginPaint() 
- QWidgetBackingStore::endPaint() 
- QWidgetBackingStore::flush()
- QCocoaBackingStore::flush()
- a) non-layer-backed
- [view lockFocusIfCanDraw] (if 
there’s no focusView)
- [backingStoreImage 
drawInRect:]
- [view unlockFocus] and 
[view.window flushWindow] (if there was no focusView)
- b) layer-backed
- view.layer.contents = 
CGImageFrom(backingStoreImage)

But when QtWidget drives an update, say after clicking a button, we end up with:

- Qt’s CFRunLoopSource for posted events
- QWidgetWindow::event(QEvent::UpdateRequest):
- QWidgetBackingStore::beginPaint() 
- QWidgetBackingStore::endPaint() 
- QWidgetBackingStore::flush()
- QCocoaBackingStore::flush()
- a) non-layer-backed
- [view lockFocusIfCanDraw] (if 
there’s no focusView)
- [backingStoreImage 
drawInRect:]
- [view unlockFocus] and 
[view.window flushWindow] (if there was no focusView)
- b) layer-backed
- view.layer.contents = 
CGImageFrom(backingStoreImage)

https://github.com/qt/qtbase/blob/5.12/src/plugins/platforms/cocoa/qcocoabackingstore.mm#L81

A similar situation happens when an animation is driven by a CVDisplayLink, 
where the display-link callback coming in on the secondary thread is delivered 
to the main thread via dispatch_source event handler, so we’re again drawing & 
flushing outside of the display cycle.

https://github.com/qt/qtbase/blob/5.12/src/plugins/platforms/cocoa/qcocoascreen.mm#L270

If we can’t (shouldn’t) do any imperative drawing, should a CVDisplayLink 
callback always just call setNeedsDisplay and let the callback be coalesced 
into the main runloop's display cycle? Even for OpenGL or Metal, where you can 
present a frame imperatively? 

>   • using -[NSImage initWithSize:flipped:drawingHandler] to capture 
> drawing code into a block; by drawing that image in -drawRect:, you’ll defer 
> execution of the drawing code until then

This one looks interesting!

> 
> I hope this helps!

Very much so, thanks again!! 😊 

Cheers,
Tor Arne 

___

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: lockFocusIfCanDraw behavior in layer-backed mode

[Tor Arne Vestbø]

> On 15 Dec 2018, at 18:49, Richard Charles  wrote:
> 
> 
>> On Dec 15, 2018, at 8:07 AM, Tor Arne Vestbø  wrote:
>> 
>> Piggy-backing on this thread, what does lockFocusIfCanDraw actually do in 
>> layer-backed mode?
> 
> I have a layer-hosting view running under macOS 10.12.6 and lockFocus is 
> called by the system frameworks.

Right. I was thinking more what happens when calling it outside of the display 
cycle. The behavior I described was on Mojave (10.14.2)

> 
> WWDC 2018 Session 209 states the following.
> 
> "With our changes to layer backing, there's a few patterns I want to call out 
> that aren't going to work in macOS 10.14 anymore. If you're using NSView 
> lockFocus and unlockFocus, or trying to access the window's graphics contents 
> directly, there's a better way of doing that. You should just subclass NSView 
> and implement draw rect. Both of those methods have been kind of finicky for 
> a while. So, you'll be saving yourself some trouble."
> 
> Note that all of the NSView focus methods are now depreciated.

The session doesn’t go into what do if you want to draw synchronously outside 
of the display cycle though. Is it enough to setNeedsDisplay and then call 
[NSView displayIfNeeded] or [CALayer displayIfNeeded]? I guess the latter since 
I don’t want AppKit to walk the view hierarchy and display other views (unless 
it’s smart enough to treat a layer-backed view as not needing that behavior).

Cheers,
Tor Arne 
___

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

lockFocusIfCanDraw behavior in layer-backed mode

[Tor Arne Vestbø]

Hey hey,

> On 15 Dec 2018, at 01:38, Matt Jacobson  wrote:
> 
> You were probably calling -lockFocusIfCanDraw 
> ,
>  which does not say that.

Piggy-backing on this thread, what does lockFocusIfCanDraw actually do in 
layer-backed mode? 

Without layer-backing, lockFocusIfCanDraw could be used to draw into the 
NSWindow surface outside of the normal display-cycle, in a push-fashion.

With layer-backing, it seems to set up some sort of “Null” context, and calls 
setNeedsDisplay? Is the context it sets up valid and you should draw to it like 
normal, and then unlockFocus And then AppKit will flush that context on the 
next display cycle? Is there then a way to detect in the next display-cycle 
(drawRect:/displayLayer:) that its a result of lockFocusIfCanDraw, so you don’t 
actually need to redraw everything once again?

I guess this also means it’s not as synchronous as the non-layered mode where 
you could use [NSWindow flushWindow] to push the result to the screen, eg:

for (int i = 0; i < animationFrames; ++i) {
lockFocusIfCanDraw
draw to NSGraphicsContext currentContext]
unlockFoucs
[NSWindow flushWindow]
}

(I know this is a bad ida, but) is there a way to achieve the same synchronous 
flush with layer-backing?

Cheers,
Tor Arne 

___

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: How to clear macOS app bundle cache

[Tor Arne Vestbø]

> On 8 Sep 2018, at 21:20, Andreas Falkenhahn  wrote:
> 
> Unfortunately not. I can see my app in the lsdump and the path points to the
> network share but purging the LS database doesn't have any effect. macOS
> still loads the old version of my app, not the latest one on the share. Only
> by rebooting or by re-copying the bundle's executable can I force macOS to
> use the latest copy.

I don’t think there’s any “application cache” here, it’s just the filesystem 
cache getting in the way (on some level).

I haven’t been successful in disabling the SMB client side cache to achieve 
what you want, but this works for me:

 sshfs -o cache=no,nolocalcaches,volname=buildmachine buildmachine.local:/ 
/mnt/buildmachine/

Cheers,
Tor Arne 

___

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: Carbon -> Cocoa

[Tor Arne Vestbø]

On 24 Aug 2018, at 21:16, Alastair Houghton  
wrote:
> 
> On 24 Aug 2018, at 20:01, Tor Arne Vestbø  wrote:
>> 
>> On 23 Aug 2018, at 12:06, Alastair Houghton  
>> wrote:
>>> 
>>> Run loops are based on dispatch queues too, these days.
>> 
>> Are they? We use CFRunLoop in the Qt event dispatchers on macOS and iOS, and 
>> I these behave as normal sources without any sign of dispatch queues as far 
>> as I can tell?
>> 
>> I did experiment with using dispatch sources instead, but these can not be 
>> recursed, which was a showstopper unfortunately. I would have loved to use 
>> the queue debugging feature (backtrace recording) to tie posted Qt events 
>> back to their origin.
> 
> You can see the code here
> 
> https://opensource.apple.com/source/CF/CF-1153.18/CFRunLoop.c.auto.html
> 
> Perhaps “based on dispatch queues” is an exaggeration; it’s more that they’re 
> very tightly integrated… CFRunLoop appears to be using dispatch queues for 
> timers, and there’s clearly integration such that dispatched calls will run 
> within the run loop.
> 
> It does still have its own separate run loop sources, observers and so on, I 
> believe; they all talk to the run loop itself via a set of Mach ports.

Right, that matches my understanding. In a sense dispatch queues are based on 
runloops as well, so your description of “tightly integrated” is accurate 😊 

Cheers,
Tor Arne 
___

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: Carbon -> Cocoa

[Tor Arne Vestbø]

On 23 Aug 2018, at 12:06, Alastair Houghton  
wrote:
> 
> Run loops are based on dispatch queues too, these days.

Are they? We use CFRunLoop in the Qt event dispatchers on macOS and iOS, and I 
these behave as normal sources without any sign of dispatch queues as far as I 
can tell?

I did experiment with using dispatch sources instead, but these can not be 
recursed, which was a showstopper unfortunately. I would have loved to use the 
queue debugging feature (backtrace recording) to tie posted Qt events back to 
their origin.

Cheers,
Tor Arne 

___

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