On Sat, Sep 12, 2009 at 10:16 PM, Erik Kay <[email protected]> wrote:
> > +kathyw (since you have some doc feedback) > > On Sat, Sep 12, 2009 at 7:02 PM, Evan Martin <[email protected]> wrote: > > > > [resend, I think I screwed up the previous three tries] > > I wrote an extension that adds a page action to trigger Readability: > > http://lab.arc90.com/experiments/readability/ > > > > It's basically just a glorified bookmarklet. > > > > Code is here: > > http://neugierig.org/software/git/?url=chrome-readability/ > > Browse it here: > > http://neugierig.org/software/git/?url=chrome-readability/tree/ > > > > I can't provide a .crx because I wasn't able to figure out how to > > build one, which I think means I can't actually install it. :~( > > Packaging isn't implemented on Linux yet, so this will cause you some > problems. > > You have two (non-Windows) options in the meantime. The first is > that you can use the gallery to package it (not an option for > nn-Googlers yet, sorry). The second is that you can use a ruby script > that was posted on this mailing list a while back. > > Of course the other option is to help port the public key crypto code > that's missing here. > > > > Here's some feedback on the process. I know extensions are still > > under development, and that surely most if not all of these are > > already known bugs, and that others are probably my fault for doing it > > on Linux. I thought it would still be helpful to give an overview of > > points of confusion I ran into, in case any of these aren't yet known > > bugs. > > Thanks for taking the time and for writing the feedback. > > > > - Weight. > > This feels like a *lot* of code (content script, page action, > > background page, manifest, message ports) just to make a bookmarklet > > appear in the URL bar. I wonder if there's a place for a "simple" > > extension API for bookmarklet-y sorts of things? > > Sure. We've talked about this a bit. Perhaps we could have a way of > packaging bookmarklets directly. Aside from autoupdate though, > conceptually it would just be a bookmarklet (maybe with the ability to > be in the omnibox). Do you think there's anything else you'd want? > > > > - Making my page action show up. > > It wasn't clear to me how to make my action just always show up. > > I think I may have done it wrong: > > > http://neugierig.org/software/git/?url=chrome-readability/tree/background.html > > since it feels unreliable (sometimes it doesn't show). > > I'll leave this to Finnur to answer. > Might be http://crbug.com/21324, fixed on trunk. > > > > - The failure modes are confusing. > > Sometimes it prints to the console (when I've made a typo in my > > manifest); other times it prints to the error console of the extension > > (bugs in my background js); other times it prints to the page's error > > console (bugs in my content script). Many of those times there's no > > obvious way to map the error back to the line that is failing. > > Agree with you here. In particular, the way we handle manifest > errors is not easy. > > I'm not sure what we can do about different errors from the different > pieces. Did you find chrome://extensions? It has a list of all of > your pages and a button that let's you open the web inspector for each > one (although not content scripts). > > - JS console. > > Do we really have no UI to get to the JS console? I had to open the > > developer tools, then guess that one of the icons at the bottom of > > the window would show me the messages. > > Agree that this could be better. Maybe someone from devtools could > talk to this. Personally, I'd like it if opening up the devtools > showed the console by default. > Yes yes yes. It was more than a little annoying to have to click three times every time I reloaded my extension-in-development (reload, open inspector, open JS console). - Pam > > > - 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 > > > > - 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. > > I think the current intent is to make the pages like toolstrip a bit > richer rather than making more of a split between API reference and > concepts. We'd like the overall thing to be more approachable and > less dense. It's possible we'll just break down and do a more > traditional concepts/reference split, but at the moment, we'd like to > avoid that. > > > > - Building the .crx. > > strace -fo log chromium-browser --user-data-dir=/home/martine/test > > --pack-extension=`pwd`/readext > > --pack-extension-key=chrome-readability.pem > > Doesn't show it ever trying to create my .pem. Maybe it's not > implemented, > > but it'd be nice if it at least complained in that case. > > yeah, sorry. As I said, this doesn't exist on linux yet. > > Erik > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
