On Aug 15, 2013, at 06:41:49, Kyle Sluder wrote:
> This is only true for sandboxed apps, but it is a very good point. If Steve's
> app is sandboxed, it needs to forward the- orderOut: message to Powerbox over
> XPC. That would require running the runloop.
It is not sandboxed.
--
Steve Mills
o
On Aug 14, 2013, at 04:14:58, Uli Kusterer wrote:
> I vaguely remember having the same issue where an open panel stayed open too
> long. I think it might be related to autorelease pools holding on to the
> actual window-owning object (some private thing, I think). You might want to
> try creat
On Aug 14, 2013, at 2:14 AM, Uli Kusterer wrote:
>
> Also keep in mind that in current MacOS X releases, open and save panels are
> out-of-process windows managed by PowerBox (think sandbox), and NSOpenPanel
> and NSSavePanel are only proxy objects in your process. Many actions you had
> on N
On Aug 14, 2013, at 7:51, Graham Cox wrote:
> On 14/08/2013, at 1:38 AM, Steve Mills wrote:
>>> unning an open panel modally is a user-hostile experience that prevents
>>> the user from interacting with other documents. OS X applications should
>>> not behave this way.
>>
>> Apple didn't feel th
OK, but now we're getting into the dodgy bits:
// Give windows a chance to display/disappear because we're tracking
events in a loop.
[[NSRunLoop currentRunLoop] runUntilDate:[NSDate
dateWithTimeIntervalSinceNow:0.1]];
On Aug 14, 2013, at 11:42 AM, Steve Mills wrote:
> On Aug 14, 2
On 14/08/13 16:00 , cocoa-dev-requ...@lists.apple.com wrote:
Date: Wed, 14 Aug 2013 14:58:42 -0400
Message-ID: <20130814185842.823741...@mail.rogue-research.com>
On Wed, 14 Aug 2013 09:03:59 -0500, Steve Mills said:
There most certainly is not a deeper issue with my code. Run this and
you'll se
On Aug 14, 2013, at 14:20:42, Quincey Morris
wrote:
> Keep in mind that even if you get things running smoothly on your Mac, you
> have no guarantee that all your customers will see the same good behavior.
Right. That's why we have a great QA department. :)
--
Steve Mills
office: 952-818-3871
On Aug 14, 2013, at 11:44 , Steve Mills wrote:
> I only used sleep in that example to illustrate that orderOut was not hiding
> the window, and that there were not "deeper issues" in our code base.
What I was trying to say is that using 'sleep' -- as it turns out -- can't
illustrate anything,
On Aug 14, 2013, at 14:01:59, Alex Zavatone wrote:
> Can't you make the opening a two stage process and use a notification when
> the window hasbeenclosed to issue the "real" opening?
Not the way it's currently written. Hopefully we'll be able to rewrite this
portion another time. Just not now
On Aug 14, 2013, at 13:58:42, Sean McBride wrote:
> Are you able to try that on 10.6? I had some similar problems starting with
> 10.7 because of the document architecture re-architecting. A lot of the
> openDocument chain is now done (internally) with libdispatch which had some
> subtle sid
Can't you make the opening a two stage process and use a notification when the
window hasbeenclosed to issue the "real" opening?
I wonder if there is a delegate to the open dialog that has events for that.
Issuing delays to start a thread blocking operation at this point seems to beg
for potent
On Wed, 14 Aug 2013 09:03:59 -0500, Steve Mills said:
>There most certainly is not a deeper issue with my code. Run this and
>you'll see for yourself:
>
>-(IBAction) openDocument:(id)sender
>{
> NSOpenPanel*p = [NSOpenPanel openPanel];
>
> if([p runModal] ==
With that in mind, any reason why you wouldn't wrap that in a block and
dispatch to GCD?
Mind you, I only have marginal experience with blocks on iOS, so this is also a
question as a suggestion.
Sent from my iPad
On Aug 14, 2013, at 11:10 AM, Steve Mills wrote:
> On Aug 14, 2013, at 21:54:00
On Aug 14, 2013, at 13:11:31, Quincey Morris
wrote:
> Actually, it's going to be the Window Server that removes the window from the
> screen. However, it may be that ordering-out an app window triggers a run
> loop source or event, which in turn notifies the Window Server. If so, the
> 'sleep
On Aug 14, 2013, at 13:40:00, Lee Ann Rucker
wrote:
>
> [p orderOut:self];
> // Let the run loop finish so the UI updates - button finishes tracking,
> window updates, etc
> [self performSelector:@selector(documentOpeningStuff:) withObject:p
> afterDelay:0];
As I've already indicated o
uot;
Cc: "Cocoa dev"
Sent: Wednesday, August 14, 2013 7:03:59 AM
Subject: Re: Dismissing Open dlog before doc actually opens
On Aug 13, 2013, at 18:56:20, Kyle Sluder wrote:
> And for a long time you used to have to keep the mouse button held down
> while navigating a menu hierarch
On Aug 14, 2013, at 08:52 , Graham Cox wrote:
> Well, there's logically 'closed' and there's having the pixels on the screen
> removed or updated. The run loop has to run for that to happen in the normal
> course of things.
Actually, it's going to be the Window Server that removes the window
On Aug 14, 2013, at 11:53:41, Bryan Vines
wrote:
> Using Graham's NSRunLoop solution, it looks like you don't even need to send
> -orderOut to the panel.
Hmm, most of the time yes. If I go through the dlog quickly, it remains
onscreen until the file has been opened. Like if I quickly command
Steve,
Using Graham's NSRunLoop solution, it looks like you don't even need to send
-orderOut to the panel.
--
Bryan Vines
On Aug 14, 2013, at 11:02 AM, Steve Mills wrote:
> On Aug 14, 2013, at 10:52:55, Graham Cox
> wrote:
>
>> [[NSRunLoop mainRunLoop] runUntilDate:[NSDate
>> dateWithTime
On 14/08/2013, at 5:52 PM, Graham Cox wrote:
> The only other thing you might try is running the run loop a few cycles in
> your completion handler so that the orderOut: is processed. It might have
> unexpected side-effects though, which might also reveal a very good reason
> why it's not do
On Aug 14, 2013, at 10:52:55, Graham Cox
wrote:
> The only other thing you might try is running the run loop a few cycles in
> your completion handler so that the orderOut: is processed. It might have
> unexpected side-effects though, which might also reveal a very good reason
> why it's not
On 14/08/2013, at 5:10 PM, Steve Mills wrote:
> The header comment for runModal says "It returns only after the user has
> closed the panel." The key word here is "closed", which makes it seem like
> the window should indeed close, not be marked for closure at some later time.
Well, there's
On Aug 14, 2013, at 21:54:00, Alex Zavatone wrote:
> Wild guess, but by any chance are you blocking the thread or blocking the
> thread that the UI is drawn on?
Yes. Refer back to the small sample I sent to illustrate that orderOut doesn't
hide the window right away.
The header comment for ru
On Aug 14, 2013, at 10:33 AM, Steve Mills wrote:
> On Aug 14, 2013, at 09:23:11, Roland King wrote:
>
>> What does that code end up doing? Not order the window out, not order it out
>> until after the 5 seconds have elapsed or what? Not much of an OSX guy but
>> something similar on iOS, with
On Aug 14, 2013, at 09:21:25, Graham Cox wrote:
> Doesn't the main event loop need to run for the window to visibly close? At
> least the modal session has to finish. If the completion code is run
> synchronously, it will inevitably delay this until the main loop runs.
That must be the case, b
On Aug 14, 2013, at 8:23 AM, Graham Cox wrote:
> Strange - maybe it's due to iCloud support being enabled? I get a
> different-looking dialog that has iCloud/On My Mac buttons and it's certainly
> non-modal. But this is getting well off-topic.
AHA! I do not have iCloud enabled.
And, actually,
On Aug 14, 2013, at 09:23:11, Roland King wrote:
> What does that code end up doing? Not order the window out, not order it out
> until after the 5 seconds have elapsed or what? Not much of an OSX guy but
> something similar on iOS, with a 5 second piece of work on the main thread,
> would sto
On 14/08/2013, at 4:14 PM, Scott Ribe wrote:
> Not for me, also on 10.8. They are application-modal...
Strange - maybe it's due to iCloud support being enabled? I get a
different-looking dialog that has iCloud/On My Mac buttons and it's certainly
non-modal. But this is getting well off-topic
On 14 Aug, 2013, at 10:03 PM, Steve Mills wrote:
>
> There most certainly is not a deeper issue with my code. Run this and you'll
> see for yourself:
>
> -(IBAction) openDocument:(id)sender
> {
> NSOpenPanel*p = [NSOpenPanel openPanel];
>
> if([p runModal
On Aug 14, 2013, at 5:49 AM, Graham Cox wrote:
> Well, just quickly looking at TextEdit & Preview for example, the Open dialog
> is quite definitely non-modal (10.8).
Not for me, also on 10.8. They are application-modal...
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
On Aug 13, 2013, at 18:56:20, Kyle Sluder wrote:
> And for a long time you used to have to keep the mouse button held down
> while navigating a menu hierarchy. Times change.
Let's focus on the question, shall we?
> The fact that -orderOut: didn't dismiss the open panel points at a
> deeper issu
On 14/08/2013, at 12:05 PM, Jeremy Hughes wrote:
> I must be missing something here.
>
> Which Apple applications have non-modal Open dialogs?
>
> All the ones that I tried (TextEdit, Preview.app, Safari, Xcode 3.2.6) have
> modal Open dialogs - you can't do anything in other documents while
running on 10.5.8.
Pages '08
Safari 5.0.6
M
On Aug 14, 2013, at 3:05 AM, Jeremy Hughes wrote:
Graham Cox (14/8/13, 06:51) said:
They did, which is why first modeless dialogs (from System 1? 2?) and
then sheets (OSX 1.0) were developed. Even as far back as the
original
Inside Macintos
Graham Cox (14/8/13, 06:51) said:
>They did, which is why first modeless dialogs (from System 1? 2?) and
>then sheets (OSX 1.0) were developed. Even as far back as the original
>Inside Macintosh the use of modal dialogs was strongly discouraged when
>it was possible to use something else. The orig
On 14/08/2013, at 1:38 AM, Steve Mills wrote:
>> unning an open panel modally is a user-hostile experience that prevents
>> the user from interacting with other documents. OS X applications should
>> not behave this way.
>
> Apple didn't feel that way in the past, so I don't believe it's user-h
On Tue, Aug 13, 2013, at 04:38 PM, Steve Mills wrote:
> On Aug 13, 2013, at 16:33:25, Kyle Sluder wrote:
>
> > On Tue, Aug 13, 2013, at 11:02 AM, Steve Mills wrote:
> >
> >> We expect the Open dlog to be modal, not modeless. Any other ideas? I
> >> also tried calling orderOut after runModal retu
On Aug 13, 2013, at 16:33:25, Kyle Sluder wrote:
> On Tue, Aug 13, 2013, at 11:02 AM, Steve Mills wrote:
>
>> We expect the Open dlog to be modal, not modeless. Any other ideas? I
>> also tried calling orderOut after runModal returned, but it didn't make
>> it go away.
>
> Running an open panel
On Tue, Aug 13, 2013, at 11:02 AM, Steve Mills wrote:
> We expect the Open dlog to be modal, not modeless. Any other ideas? I
> also tried calling orderOut after runModal returned, but it didn't make
> it go away.
Running an open panel modally is a user-hostile experience that prevents
the user f
Steve,
Could you use a boolean property such as fileIsBeingRead? Set that to YES when
you start the file read on the background thread, then set it back to NO when
the file read has completed.
I used this technique in a proof-of-concept app. The app has a status label in
its window; the label'
On Aug 12, 2013, at 21:22:07, Bryan Vines wrote:
> Can you run an NSOpenPanel with a completion handler block, and in that
> block, call a method on a background thread to actually perform the file read
> operation?
Well, this won't work. The current code runs the dlog with runModal instead of
On Mon, 12 Aug 2013 23:27:59 +, Mills, Steve said:
>I haven't been able to find any info about this, but I might be
>searching for the wrong thing. How can we get rid of the Open dlog so it
>doesn't hang around while the document is being read? It's an incredibly
>annoying design.
Dismiss the
On Aug 12, 2013, at 21:42:10, Kyle Sluder
wrote:
> Are you using NSDocument? If so, return YES from
> +canConcurrentlyReadDocumentsOfType: to let NSDocumentController know it can
> initialize your document in the background. Then it will call
> -makeWindowControllers on the main thread.
>
>
On Aug 12, 2013, at 4:27 PM, "Mills, Steve" wrote:
> I haven't been able to find any info about this, but I might be searching for
> the wrong thing. How can we get rid of the Open dlog so it doesn't hang
> around while the document is being read? It's an incredibly annoying design.
Are you us
Steve,
Can you run an NSOpenPanel with a completion handler block, and in that block,
call a method on a background thread to actually perform the file read
operation?
As a test, I put this together. I called the selectAFile method and chose a 4GB
text file. The open panel was dismissed after
44 matches
Mail list logo
