+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. > - 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. > - 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 -~----------~----~----~----~------~----~------~--~---
