Open Radar

 
====================
Summary:
====================


It would be really great if Xcode's fancy new QuickLook system could be extended to support C types.

For example, let's say I have a struct which represents a region of time. It's composed of two NSTimeIntervals: a date and a duration.

Debugging things which use this structure would normally be a chore, as the debugger gives you two meaningless big numbers, e.g:

timeFrame STGTimeFrame
  | date          NSTimeInterval     404956800
  | duration    NSTimeInterval     18489600

Not only that, but if you've used timeIntervalSinceReferenceDate, you first need to convert these values to something 1970-based before using an online unix timestamp converter.

Forum thread: https://devforums.apple.com/thread/215979?tstart=0

There is a dev-forum thread about this where I was advised to file a radar. Python script type summaries are mentioned as a possible workaround. They do help a lot, but you can't get the same visual debugging information from a python script that you can with QuickLook. For some types, that extra visual information could make a real difference.

For example, I've got a second type - STGTimeFrameSubtractionResult. It contains two timeFrames. I've got a nice little algorithm which allows me to subtract one region of time from another (possibly resulting in a "hole" - modelled by two timeFrames, left and right). This function is used for delta processing - we can subtract the old timeFrame from the new timeFrame and load new data only for regions of time which have been added.

It would be much more helpful to visualise this as an image (e.g. a timeline showing the included regions, with a hole in the middle and some relevant dates labelled) than as textual output. You can work with the text output, sure, but it is much less than ideal.

This is one example, and the point is that C types can represent rather complex things which are a bit of a headache to deal with in text format. An extension of the visual debugger to cover them would be really nice.

====================
Steps to Reproduce:
====================

N/A

====================
Expected Results:
====================

My proposal would be one of the following:

1. A C function with a custom attribute, similar to UI_APPEARANCE_SELECTOR, which does nothing other than to tell the debugger that this returns a QuickLook summary object for a given type.

e.g.

UIImage * __getTimeFrameImage( STGTimeFrame timeFrame ) DEBUG_QUICKLOOK_PROVIDER( STGTimeFrame )

2. A Quicklook manager class, with which we can register custom C functions.

#import <DebugSupport/DebuggingQuickLookManager>

@interface DebugQuickLookProviders: NSObject
@end

@implementation DebugQuickLookProviders

+ (void)load {

    [DebuggingQuickLookManager registerFunction: __getTimeFrameImage
                                                                    forType: @encode( STGTimeFrame )];
}

UIImage* __getTimeFrameImage( STGTimeFrame timeFrame ) {

// Do something fancy and return an image.
}

@end

****

The benefit to these, of course, is that you get to do far more elaborate things and be far more visual than you can with an LLDB python script. Since they are part of the project, they are also portable - automatically registering for anybody else who uses your project (team members, open-source downloaders, etc).

My own preference is for #2. Of course, since you would be mixing C functions with Obj-C types (which is perfectly legal), the QuickLook functions would have to go in a separate .m file. This is nice because it kind of enforces a separation from the C code which defines the C types and the QuickLook code which uses Obj-C to enhance debugging output.

====================
Actual Results:
====================

N/A

====================
Version:
====================

Xcode 5.1

====================
Notes:
====================

====================
Configuration:
====================

====================
Attachments:
====================