>> - 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, that sounds reasonable. Opening the console is usually the first action I do after opening Dev Tools. We just need to be sure that this plays well with, say, docked mode of Dev Tools window. On Sun, Sep 13, 2009 at 09:16, 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. > > >> - 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 -~----------~----~----~----~------~----~------~--~---
