> On 19 Dec 2015, at 5:23 AM, Jens Alfke wrote:
>
>
>> On Dec 18, 2015, at 1:24 AM, Graham Cox wrote:
>>
>> I want to display a path to the user. I have a URL, I need to show the local
>> file path that represents (it’s always a local file path), where the
>> /Users// is replaced by ~/
>
>
> On 19 Dec 2015, at 7:51 PM, Graham Cox wrote:
>
> But I do want the string to be the most understandable for the user. I don’t
> know really how many average users understand what ~/ means, but it’s
> probably the best I can do.
Actually - heh, -displayNameAtPath: really strips it back to
This seems tangential to cocoa-dev, though I am in a callback from a Cocoa
method, I don't think the crash is inside Cocoa but my own code. But here's
the problem, maybe someone can suggest a better forum.
I have a crash dump from a customer. I cannot reproduce the problem, and I
cannot expect the
> On 2015 Dec 19, at 08:05, Aandi Inston wrote:
> Anyway, what would you do with a crash dump routine + offset, not
> reproducible?
Aandi, I would step back and consider that I am over-thinking the problem.
I would look at the information I have, which should be my function in which
the crash
NSPathControl really is the best thing - people are used to seeing it, even
power users who know what those slashes mean. We use it everywhere in Fusion
settings. Popup style is appropriate where the most important info is the last
part but sometimes they want to see the whole path. Standard sty
On Dec 19, 2015, at 10:05 AM, Aandi Inston wrote:
>
> I have a crash dump from a customer. I cannot reproduce the problem, and I
> cannot expect the customer to have endless patience to run test versions
> etc. The crash dump identifies the crash location as Routine+offset as I
> would expect. Th
> corresponds to your code. You might want to get the assembly from each of
> lldb and "otool -tV", as each may provide symbolication that the other
> doesn't. Hopefully, nearby references to selectors or strings will help you
> figure out which line of code the crash occurred on.
otool -t -V
> On Dec 19, 2015, at 12:57 AM, Graham Cox wrote:
>
> Actually - heh, -displayNameAtPath: really strips it back to just the folder
> name, with no path at all. That doesn’t tell the user *where* the folder is.
> Unless they’re already familiar with the location it’s likely less helpful
> than
On Sat, 19 Dec 2015 19:51:03 +1100, Graham Cox said:
>I don’t think a NSPathControl is really appropriate for this.
I'm curious why... that's what it's for.
Cheers,
--
Sean McBride, B. Eng s...@rogue-research.com
Rogu
I was thinking that I didn’t want the user attempting to use it to navigate the
folder hierarchy - but actually just using it for display and setting it to
refuse First Responder does the trick pretty nicely. Because it shows the home
folder as the user name and has the Home icon it’s much clear
Though you might consider including an analog of the slightly hidden but
discoverable way Finder also exposes shell style paths from the Go menu with Go
to Folder...
The kb shortcut works in open/save panels as well.
Sent from my iPhone
> On Dec 20, 2015, at 8:00 AM, Graham Cox wrote:
>
> I
11 matches
Mail list logo
