Re: The speed of popover displays within Xcode
Re: The speed of popover displays within Xcode
- Subject: Re: The speed of popover displays within Xcode
- From: Alex Zavatone <email@hidden>
- Date: Thu, 19 Jul 2012 18:13:31 -0400
Thanks man.
It seems amazing that we have shortcut keys to help us do our operations faster, but when we use them, we are often held up as we watch the GUI fade in, slide in or otherwise animate an effect that does not need animating.
This is why I want to turn them off or minimize the time allocated for them to appear.
The factor here is that I know I operate on momentum, I'd expect that some others do to. We get to a point where we start cranking through the UI and go as fast as we can, typing and navigating the UI. What really sucks with regards to usability IMHO, is when there is a time limit set on the display or dismissal of an item, be it a fade in, a push, a whatever.
It's during that split second where you're actually looking at the screen thinking "FINISH DAMN YOU", and your enthusiasm, your momentum, is dented.
I was running into another relevant GUI factor the other day, when you drag a connector from the little circle on an item to a chunk of code in an h or m file. The natural trend is "since you are dragging from a little circle GUI item to another area with a circle item next to it, that releasing over the other circle would complete the task".
It doesn't. You have to drag into the block of code. If you've forgotten the instructions, this is completely nonintuitive.
You are control dragging from a GUI element that is an empty circle to an IBAction with a little empty circle right to the left of it. The expectation fostered is that dragging from similar element to similar element is what constitutes completion of the task.
Apple, for all its GUI standards, completely violates its own when the initial tendency that it fosters (drag from an empty circle to an area the same type of circle right to the left of it), doesn't do anything at all.
Sure, I felt like an idiot for going a little bit farther and not dragging into the code, but the exact action hinted at is to go from a circle to a circle.
It appears that the Xcode team should really add an intersection rect around the circle to the left of the IBAction to allow wiring up things like IBActions and iBOutlets.
Sure, lots of Xcode is great, but It just bums me out that parts of Xcode are more focused on "animating stuff" or a 3/4 solution to the problem than on contributing to the developer's productivity.
And on that note, back to it.
On Jul 19, 2012, at 5:48 PM, Ben Gollmer wrote:
> On Jul 19, 2012, at 3:11 PM, Alex Zavatone wrote:
>
>> That leads me to ask, since the defaults terminal command allows us to override built in values of settings used in applications, is there a process to query an application to see just what these settings are?
>
> In general, there is no way to do this. Consider an application you've written - you can call [[NSUserDefaults standardUserDefaults] objectForKey:] and supply any key you like; there's no means to force you to document the keys you use, or the range of acceptable values.
>
> A common method to find "hidden" settings in an app is to run strings(1) on an app binary and looking for things that resemble defaults keys, but that is by no means exhaustive or foolproof.
>
> --
> Ben
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden