[chromium-dev] Re: readability extension (experience writeup)
> I was using dev. I think I just searched on Google and clicked > through to whichever docs I found -- I didn't realize there were two > sets. Should we always point users to trunk until extensions are in > beta? I don't think we can, since the generated API docs need to match whatever the user's most likely to be using (in this case, dev; in the future, beta). However... We should advertise somewhere that you can look at different versions of the doc. Maybe in an "about this doc" section at the bottom of the front page, or maybe in the sidenav. > But yes, the trunk docs look great, and I see they've also addressed > my prior complaint about organization. Cool. It's great to hear that. -k- --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: readability extension (experience writeup)
> - The docs around content scripts communicating with the embedding > page aren't too clear. See e.g.: > http://code.google.com/chrome/extensions/content_scripts.html#messaging > That section is mostly just a big example but for example nowhere is > the postMessage API described. I'd prefer it to be laid out more > like: > - how to make each endpoint listen for messages > - how to make each endpoint send a message Yes, these need to be improved. There will also be some new API that'll make the common case of sending a message much easier. > - Doc organization. > It would've been clearer to me if there is one more level of nesting. > Sections like toolstrips, page actions are features with manifest > edits as well as APIs, while sections like tabs and windows are just > API references. If you look at the trunk version of the docs, there is one more level of nesting in the sidenav. Does this help? http://code.google.com/chrome/extensions/trunk/ -k- --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: [chromium-extensions] Re: [chromium-dev] Proposal: extensions API documentation system
I believe the O3D API reference doc is generated using Doxygen (on IDL input) plus a bunch of custom code that tweaks the Doxygen output. I think they generate the O3D API ref doc every time they update the API, and the O3D writer then copies those files and puts it alongside the handwritten O3D doc. -k- On Tue, Jun 23, 2009 at 11:41 AM, Jeremy Orlow wrote: > For what it's worth, I was really impressed by the O3D documentation: > http://code.google.com/apis/o3d/docs/index.html > Not sure how they did it, but I believe it was all generated. Not sure if > that's close enough to what you had envisioned. > > On Tue, Jun 23, 2009 at 11:36 AM, Aaron Boodman wrote: >> >> We're getting to the point with the extensions project where we need >> to figure out how our documentation will work. From working on Gears, >> Greasmonkey, and other previous projects I have some strong feelings >> about how it should *not* work, and that led naturally to: >> >> >> http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/doc-viewer-design-doc >> >> Feedback desired. >> >> Before people ask: No, I have not yet seriously investigated any >> existing systems (Doxygen, Bigbook) that we could reuse, rather than >> build. It could very well be that something like this -- or close >> enough -- already exists. Part of next steps would be to investigate >> reusing existing options. >> >> - a >> >> > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
