Re: mydoc.myext/QuickLook/Preview.html and full screen
Re: mydoc.myext/QuickLook/Preview.html and full screen
- Subject: Re: mydoc.myext/QuickLook/Preview.html and full screen
- From: "Julien Jalon" <email@hidden>
- Date: Fri, 2 Jan 2009 19:33:02 +0100
On Fri, Jan 2, 2009 at 5:05 PM, Gerd Knops <email@hidden>wrote:
>
> On Dec 31, 2008, at 8:43 PM, Julien Jalon wrote:
>
>>
>>> On Wed, Dec 31, 2008 at 10:37 PM, Gerd Knops <email@hidden>
>>> wrote:
>>>
>>>>
>>>> Seemingly arbitrary limitation, when according to the documentation
>>> Java applets and Flash are supported.
>>>
>>
>> Web Plug-ins are not supported (if this is in QL documentation, it is a
>> bug).
>>
>>
> http://developer.apple.com/documentation/UserExperience/Conceptual/Quicklook_Programming_Guide/QLDynamicGeneration/chapter_7_section_3.html#/
> /apple_ref/doc/uid/TP40005020-CH15-SW2
>
> Last Paragraph claims:
>
> "Although the code listing uses an img HTML element for the
> cid-scheme reference to the image attachment, you can also use the object
> element for all kinds of attachments (images, audio, videos, Java applets,
> and Flash animations). It is not recommended that you use Web Kit plug-ins
> in enriched HTML passed back to Quick Look."
>
Please file a bug as this is incorrect.
>
>
>
>> Would have been nice to have some client-side javascript to produce a
>>> nice functional QuickLook document, instead of being limited to 'no nib
>>> allowed' C code. Why no full Objective-C support for Quicklook seems rather
>>> odd.
>>>
>>
>> Security, stability and other reasons.
>>
>> QL is not meant to fully replace an application. It's not meant to be some
>> sort of Active X or OpenDoc either. Its goal is much more limited (but in
>> the end much more useful ;-) ).
>>
>
> For more complex document formats the ability to provide a UI is necessary.
> For example to explore archives, or in my case a hybrid document that
> contains a number of other documents (each of which do have PDF and gif
> previews), and where the document state changes dynamically because it is of
> a collaborative nature.
>
That's a misunderstanding. Quick Look is not meant to "explore" files but to
provide a "quick look" of the file. Goals of QL generators is to provide a
simple standard representation of the files' contents regardless of the UI
(QL is then responsible to provide the best UI possible depending on the
context, be it the Quick Look panel, Cover Flow or any other place in the
system it might make sense, today or in the future). If you feel the
proposed representations for your documents can't really suit your needs,
please file a bug describing exactly what your document is all about.
>
> In general, QL could be made a lot nicer for Cocoa Programmers than that
> limited C API.
>
Once you have a CGContext, you have a NSGraphicContext and you can use
whatever Cocoa drawing API (you can even use printing APIs or -[NSView
displayInContext...]).
Note that there is a more suited mailing list to discuss Quick Look (
email@hidden)
--
Julien
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden