On Mon, Sep 29, 2008 at 1:06 PM, Marshall Greenblatt
[EMAIL PROTECTED] wrote:
Perhaps these questions are a bit too broad, given the lack of existing code
that utilizes this capability.
New question:
Should it be possible to create an NPObject representation of a JavaScript
Array from
Hi Stefan,
Did you get this to actually work? I was trying to do the same thing,
and though I am calling this API it doesn't prevent scrollbars from
showing.
- a
On Mon, Nov 3, 2008 at 5:31 PM, slandvogt [EMAIL PROTECTED] wrote:
Actually I got it to work: Toplevel-Scroller dont show up
Hi!
A few of us have been talking for the past few weeks about how to do
extensions in Chromium. Here's a design doc that explains the
beginning of our plan:
http://dev.chromium.org/developers/design-documents/extensions
To start, we're going to focus mostly on the infrastructure for
Roboform support is a pretty common request. While we can't integrate
it ourselves, we will definitely try and make it as easy as possible
for the Roboform team to do so.
- a
On Wed, Dec 3, 2008 at 11:30 PM, Massimo [EMAIL PROTECTED] wrote:
Maybe I'm not the first one, but I know there are
Interesting idea. We are really concerned about extensions causing a
lot of clutter and want to make sure that isn't a major problem. We
haven't started designing the UI yet, but when we do, we'll keep this
idea in mind.
Thanks,
- a
On Fri, Dec 5, 2008 at 6:49 AM, Alg [EMAIL PROTECTED] wrote:
Thanks everyone for the feedback. I've made the following changes to
the design doc:
* Removed the ability to match every URL with @match *
* Made it possible to match intranet hosts and IP addresses
* Removed the .tld feature because there is no guarantee that
google.some public suffix is the
Forgot to reply to one point:
On Wed, Dec 10, 2008 at 3:56 PM, Erik Kay erik...@chromium.org wrote:
Yes, I thought this was in the original design. We should also
explicitly support chrome:// URLs (and again, not have it match with
*). Users should be able to use these scripts to hack on
It would be better if we could consult Google for spelling
recommendations. It seems like I frequently misspell a word, get the
red squiggly, get no recommendations from Chromium, then go to Google
and it gets it exactly right.
I know, this would be great for an extension.
- a
On Mon, Dec 15, 2008 at 1:52 PM, Ian Fette i...@chromium.org wrote:
We actually looked into this earlier. One thing that stopped us from doing
so is that the corrections are not based on proper spelling, but based
rather on searches and results. The masses are not always right, and we
thought
Doing per-user extension installation w/ per-profile disabledness
override and configuration is an interesting idea. Seems simpler in
some ways, and perhaps better than purely per-profile.
Since I already have this change almost lined up that implements
per-profile, I'll send it out anyway so we
On Thu, Dec 18, 2008 at 11:25 AM, Darin Fisher da...@chromium.org wrote:
Why not try to do something cleaner (and more predictable) like
auto-dismiss background alerts?
How would autodismissing background alerts work with, eg, calendar
meeting notifications. Would we just recommend some
It seemed complicated to allow other processes direct access to the
DOM, so we were not going to do that. For something like the
inspector, what we were thinking is a client/server model, with the
client being JS that interacts with the DOM and the server being in
another process and showing the
On Tue, Jan 27, 2009 at 12:04 PM, Søren Gjesse sgje...@chromium.org wrote:
With regard to moving the DOM inspector out of process Sergey Ryazanov have
filed https://bugs.webkit.org/show_bug.cgi?id=23502 with a rather large
patch where the inspector access to the DOM is being factored to an
On Fri, Jan 30, 2009 at 9:31 AM, Scott Violet s...@chromium.org wrote:
The second test class is InProcessBrowserTest. This test class invokes
BrowserMain (but not BrowserInit) to startup Chrome, then runs your
test method. Your test method is then running as if you were inside
Chrome. You can
I've created a list of possible extension APIs to the wiki, just so
that we have it:
http://dev.chromium.org/developers/design-documents/extensions/apis
We haven't yet prioritized these (hence the empty priority column).
We'll need to figure that out next, probably based on number and
popularity
On Thu, Feb 5, 2009 at 11:29 AM, Matt Perry mpcompl...@chromium.org wrote:
On Thu, Feb 5, 2009 at 10:35 AM, John Abd-El-Malek j...@chromium.org wrote:
Looks good, one comment: previously there's been some high level
comments about how workers can be used to give extensions a long lived
On Thu, Feb 5, 2009 at 11:51 AM, Marshall Greenblatt
magreenbl...@gmail.com wrote:
Will it be possible to create Chrome extensions with binary components? For
instance, Mozilla extensions can distribute and access XPCOM components.
We were thinking that you could use NPAPI for binary
On Thu, Feb 12, 2009 at 10:27 AM, Alex Russell slightly...@google.com wrote:
What about *another* (optional) page for config, then? I agree that
overloading the execution context seems the wrong way to handle this,
but as Chrome extensions get ever more sophisticated and begin to
resemble
I'm trying to commit a change
(http://codereview.chromium.org/19737/diff/1440/1448 ) which adds a
base class for unit tests that exercise JavaScript. It uses v8.h,
which is disallowed by DEPS. What is the right way to do this?
- a
--~--~-~--~~~---~--~~
Chromium
The other day I mentioned off-hand in a hallway conversation that I
thought it should be a goal for the extensions system in Chrome to
significantly increase the average number of extensions installed per
user, and to happily support up to 20 or 30 extensions installed at
once (both visually and
On Mon, Feb 23, 2009 at 11:29 AM, Matt Perry mpcompl...@google.com wrote:
Interesting thoughts. This is sounding more like Android's services
(long-running background tasks) and activities (apps run in response
to a user action) model.
One thought I had in response to this is, who would
http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/api-pattern
I'm thinking about what the general pattern for the APIs we expose to
extensions should be. I've been leaning toward something that is quite
a bit of a departure from the style of the DOM and more
Here's a pretty sweet Firefox extension that we should be able to
someday support. Tons of features. Lots of very well done UI.
Watch the video: http://www.zotero.org/
- a
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
PS, there are also some sample extensions as attachments at the bottom
of the doc.
- a
On Mon, Mar 16, 2009 at 4:46 PM, Aaron Boodman a...@chromium.org wrote:
I've created a starter document for people wanting to create Chromium
extensions:
http://dev.chromium.org/developers/design
I have a CL that implements default CSS for toolstrips to make 'em
pretty (well, relatively pretty). But it doesn't work because the
gradient crashes in webkit for some reason.
Anyway, this isn't a huge need at this moment, so I'll probably
abandon the change for now. But if anyone later wants
I'm starting to dig into implementing the tab and window API as a
first example of all the other browser-automation type APIs we
eventually want to implement for extensions.
One of my early assumptions was that the APIs we exposed would be
service-style, where we pass dumb json data structures
On Thu, Mar 26, 2009 at 11:22 AM, Brett Wilson bre...@chromium.org wrote:
Those are exposed, but I wonder which cases an extension needs to
refer to them. They are internal IDs generated by sqlite. If you clear
your history, you'll get re-used ones. This could also theoretically
possible
Another thing you should be able to do with an extension.
Note that our current proposals for a bookmark API don't have an index
property (within the parent). We need to add that.
- a
-- Forwarded message --
From: mertoman merto...@gmail.com
Date: Tue, Apr 7, 2009 at 8:03 AM
On Wed, Apr 8, 2009 at 11:55 PM, Tim Steele t...@chromium.org wrote:
Nice stuff. I think this question primarily applies to bookmarks, but how
does the API deal with keeping states consistent? By the time a getBookmarks
callback or an event reaches the listener (in a separate process), the
On Thu, Apr 9, 2009 at 10:28 AM, Erik Kay erik...@google.com wrote:
On Wed, Apr 8, 2009 at 11:52 PM, Aaron Boodman a...@chromium.org wrote:
Should changes to the contents of a folder trigger eventbookmarkupdated for
that folder? How about the folders above it?
This is a meta question
On Thu, Apr 9, 2009 at 1:29 PM, Nick Baum nickb...@chromium.org wrote:
Well that begs the question: if the folder gets updated, what about the
folder it's contained in? Is it updates all the way up? I think it'd be
simpler to not send updates for the folders when the bookmarks change.
Why
We want to watch directories recursively for extensions, but not for
user scripts. So ideally, we'd like it to be an option. If I had to
choose one, I'd say I want recursive, because it's more important to
have extensions work well than to have the user script directory not
work as well.
- a
On
Resending from right address...
- a
On Wed, Apr 22, 2009 at 10:32 AM, Aaron Boodman a...@google.com wrote:
I've started a small refactor of our design docs:
http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions
The main changes are:
- Created a new simple
Is it possible to enforce these rules with code rather than capital letters?
I don't think I've made this particular error, but it's something I
could see myself doing. From their names, chrome/common seems like a
reasonable thing to include from chrome/views.
Just a thought. Don't we have
On Mon, Apr 27, 2009 at 9:26 AM, Erik Kay erik...@chromium.org wrote:
I think these changes are an improvement, however it does feel a bit weird
for it to be tab-based rather than URL based. With only a tab id, I think
there will be some races. So if an extension script realizes that this
On Mon, Apr 27, 2009 at 10:00 AM, Erik Kay erik...@chromium.org wrote:
On Wed, Apr 22, 2009 at 3:35 PM, Aaron Boodman a...@chromium.org wrote:
Updating:
- We have bookmarks.setTitle(id, title) and windows.updateWindow({id,
top, left, width, height, ...})
- My vote. I like the single update
Ok, I think we have enough consensus (Rafael also contacted me on IRC
with consensus or lack of opinion on each point). I will update the
documents on dev.chromium.org with TODOs for the changes.
- a
--~--~-~--~~~---~--~~
Chromium Developers mailing list:
I heard you have to fix at least five layout tests, then they go away.
- a
On Mon, Apr 27, 2009 at 6:47 PM, Glen Murphy g...@chromium.org wrote:
I have zero need for the layout tests, yet I've never been able to set
up a client without them - even with the suggested custom_deps line, I
I have always felt like running the WebCore backend in the browser
process with an IPC channel between it and the frontend was a really
elegant design for this problem. And I never really understood why we
weren't allowed to depend on WebCore (even indirectly) in the browser
process. Is the idea
on
dev.chromium.org!
-Ben
On Wed, Apr 22, 2009 at 3:35 PM, Aaron Boodman a...@chromium.org wrote:
A few of us extension guys were talking offline Monday about how now
that we've all had a chance to implement some APIs, we are probably
better positioned to come to consensus on the remaining style
Was this a recent regression? I made some changes in that area
recently to support transparent webviews. I tried not to change
anything in the case where transparency is not needed, but I imagine
this could have been me.
Here is the change:
Right now, we are unpacking extensions in the browser process. This
basically consists of unzipping the package into a directory structure
and parsing a JSON manifest.
Both of these things feel like things we should not be doing in the
browser. Additionally, extensions can contains PNG images
Thanks for the replies!
On Fri, May 1, 2009 at 10:42 AM, Adam Barth aba...@chromium.org wrote:
I think we should go with the utility process. We've seen several
examples where this would be a useful concept to have.
On Fri, May 1, 2009 at 10:48 AM, Erik Kay erik...@chromium.org wrote:
There
Amazing! Congrats Dimitri :)
- a
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
On Mon, May 4, 2009 at 11:08 AM, jack js2...@gmail.com wrote:
Dear experts,
I am recently playing around Chrome extension development
Sweet!
does chrome has an add-on preference system? I think a
preference system is an essential component for an add-on ecosystem.
What I mean is
it for testing :).
- a
2009/5/5 PhistucK phist...@gmail.com:
Then... no way for now?
:(
I built a little instant messaging notifier with the extensions. :)
☆PhistucK
On Wed, May 6, 2009 at 02:45, Peter Kasting pkast...@google.com wrote:
On Tue, May 5, 2009 at 4:43 PM, Aaron Boodman
This also makes sense to me as something for the wider web platform. I
wonder if there could be awindow.onidle event. This seems generally
useful to all web apps.
- a
2009/5/6 PhistucK phist...@gmail.com:
I wish I had the disk space and the know how.
☆PhistucK
On Wed, May 6, 2009 at 20:08,
usage pattern. Apps could
then key off of the notification to start/stop workers or timers for
idle processing, etc.
--Amanda
2009/5/6 Aaron Boodman a...@chromium.org:
This also makes sense to me as something for the wider web platform. I
wonder if there could be awindow.onidle event
Yes, this is a known issue. I've created a bug that you can track if
you're interested:
http://code.google.com/p/chromium/issues/detail?id=11547
- a
On Wed, May 6, 2009 at 11:37 AM, jack js2...@gmail.com wrote:
The phenomenon is quite simple: the addon code may not be loaded
(quite random)
On Wed, May 6, 2009 at 12:39 PM, Mike Beltzner beltz...@mozilla.com wrote:
On 6-May-09, at 3:30 PM, Jeremy Orlow wrote:
Anyhow, I've heard arguments both ways. Some people think we should not
let the standards keep us from experimenting (and then raising the topics
with the standards group
Blargh.
On Wed, May 6, 2009 at 1:35 PM, Aaron Boodman a...@google.com wrote:
On Wed, May 6, 2009 at 1:26 PM, Jeremy Orlow jor...@google.com wrote:
Aaron, what's the plan for extensions using localStorage and databases. I
assume they'll each have their own origin that's independent of what
there is
-webkit-border-radius for CSS. Something like:
window.onIdleWebKit
or
window.onIdleWK
Adam
On Wed, May 6, 2009 at 1:07 PM, Aaron Boodman a...@chromium.org wrote:
On Wed, May 6, 2009 at 12:39 PM, Mike Beltzner beltz...@mozilla.com wrote:
On 6-May-09, at 3:30 PM, Jeremy Orlow
The way that makes most sense to me to implement this in the
extensions system is:
a) In C++ use content sniffing to make sure that the content type is
always correct for feeds
b) Add a feature to content scripts in extensions, so that they can
match by content type
c) Have a content script that
Why bother with view-feed://? Why not just have the feed be styled
more nicely, similar to the way that XML is styled more nicely by
default in most browsers?
- a
On Wed, May 6, 2009 at 6:13 PM, Evan Martin e...@chromium.org wrote:
On Wed, May 6, 2009 at 5:36 PM, Finnur Thorarinsson
Let's say the feed is http://foo.com/feed.xml
What about a setup where the content rendered in the tab area is
running on chrome://, but contains a frame that hosts the actual feed
running on http://foo.com? The subscribe UI runs on the other page, so
it is the only thing that needs elevated
On Thu, May 7, 2009 at 12:03 AM, Adam Barth aba...@chromium.org wrote:
On Wed, May 6, 2009 at 11:55 PM, Aaron Boodman a...@chromium.org wrote:
What about a setup where the content rendered in the tab area is
running on chrome://, but contains a frame that hosts the actual feed
running on http
Right now, the extension system treats any downloaded file that ends
in .crx as an extension.
This seems like a bad idea, and that we should use a content type.
Firefox uses the content type application/x-xpinstall. However, as a
Firefox extension developer, I can tell you the content type thing
On Thu, May 7, 2009 at 3:52 PM, Evan Martin e...@chromium.org wrote:
You have two use cases in mind here, and I think your solutions are mixing
them.
In the (rare) case where someone has the correct mime type set, we
should obey the mime type and do no sniffing. I think that's
On Thu, May 7, 2009 at 4:09 PM, Adam Barth aba...@chromium.org wrote:
Ugg.
I know. What can I say? We are caught between idealism and practicality.
1) If the response has the right MIME type, then we can believe that
the site has endorsed the extension. As Adam says, Site
On Thu, May 7, 2009 at 4:20 PM, Adam Barth aba...@chromium.org wrote:
On Thu, May 7, 2009 at 4:17 PM, Aaron Boodman a...@chromium.org wrote:
Ok, thanks for the recommendation. Currently the magic string is
Cr24. Not enough characters?
I suggested the above to be analogous to HTML5's appcache
Hello everyone,
The extensions posse would like to point out that as of today's dev channel
release (2.0.180.0), extensions are starting to be a bit more useful. We can
now put little bits of UI in the chrome of Chrome, and some of the APIs are
starting to come together.
There is still quite a
Argh, Gmail. You're not my friend anymore.
On Tue, May 12, 2009 at 5:15 PM, Aaron Boodman a...@chromium.org wrote:
Following in what is apparently a tradition[1], one of our samples is a
builtbot monitor. Here is what it looks like when it is running:
http://dev.chromium.org/_/rsrc
2009/5/12 PhistucK phist...@gmail.com:
Note that in the Content Scripts page, there are two things to fix -
The sample Content Script for google.com (replacing the image) does not work
because the document.images.length is 0.
Also, there is a mentioning in the comment of the API reference of
2009/5/13 jack js2...@gmail.com:
Thanks for your feedback. My understanding is that Chrome is actively
working on an official user preference system based on HTML 5 local
storage. In the meantime, I was suggested trying bookmarks as a
workaround. I haven't tried the new release yet, but in
Hi Jack,
On Fri, May 15, 2009 at 2:05 PM, jack js2...@gmail.com wrote:
I have spent some time playing around the new release of Chrome,
especially building user preference system using the bookmarking and
script/extension communication aspects. I have to say it is not
reliable enough yet to
on a toolstrip button makes Chrome focus
on an arbitrary tab all of a sudden?
☆PhistucK
On Sat, May 16, 2009 at 00:18, Aaron Boodman a...@chromium.org wrote:
Hi Jack,
On Fri, May 15, 2009 at 2:05 PM, jack js2...@gmail.com wrote:
I have spent some time playing around the new release
FYI, I've moved all the tasks I'm aware of for the extensions project
to the normal issue tracker. Here's a nice query:
http://code.google.com/p/chromium/issues/list?q=Area:extensionssort=pri+sizecolspec=ID%20Pri%20Area%20Status%20Summary%20Owner%20Size
Here is how I filled out the fields:
P1:
On Tue, May 19, 2009 at 11:35 AM, jack js2...@gmail.com wrote:
Sorry for this late response. I was piled up in the past days. I did
some additional trials. It's quite random and it is hard to get unique
results. But let's handle it one by one. I am attaching a sample
toolstrip.html file. For
On Wed, May 20, 2009 at 3:03 PM, Jeremy Orlow jor...@chromium.org wrote:
Hopefully real storage appears soon, and we can use that instead.
I'm currently doing some refactoring work on the WebKit LocalStorage
implementation so that it can fit into Chromium's multi-processs model.
It's hard
Yup, very cool. It's nice to see more projects embracing our new HTML overlords.
I was also pleased to see a Gmail notifier as a first extension :). It
will be like a battle of the Gmail notifiers.
- a
On Wed, May 20, 2009 at 3:58 PM, Peter Kasting pkast...@google.com wrote:
On Mon, May 25, 2009 at 3:44 PM, Evan Martin e...@chromium.org wrote:
If you're trying to catch a notification that needs to get to a worker
thread, a pattern we use elsewhere is to have an object that lives on
the UI thread that gets the notification then makes an async call over
to the
This has actually been implemented. I've just updated the docs:
http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/tabs-api
- a
On Tue, May 26, 2009 at 12:09 PM, Mohamed Mansour
m0.interact...@gmail.com wrote:
That is why it is nice to have page events that
This is definitely a bug in Chrome, but out of a sense of morbid
curiosity, I tried implementing the lock tabs feature as an
extension:
http://aaronboodman.com/z_dropbox/tablock.crx
You will need the Chrome dev channel and the --enable-extensions flag
to use this. See the instructions at the
An easy way around this problem is to make a trivial change to the grd
file, such as adding a single whitespace. If you look at the history
of, eg, browser_resources.grd, you will see people doing this
frequently.
- a
On Sat, May 30, 2009 at 3:37 PM, Mohamed Mansour
m0.interact...@gmail.com
bcc: chromium-dev
cc: chromium-discuss
Can you send the code for the complete toolstrip?
- a
On Sun, May 31, 2009 at 4:57 PM, Zak zakk...@gmail.com wrote:
Hi,
I'm really not a coding person, but I followed the documentation
here:
really know how to utilize the code he posted.
On Jun 1, 12:22 pm, Aaron Boodman a...@chromium.org wrote:
bcc: chromium-dev
cc: chromium-discuss
Can you send the code for the complete toolstrip?
- a
On Sun, May 31, 2009 at 4:57 PM, Zak zakk...@gmail.com wrote:
Hi,
I'm really
1, 2009 at 12:43 PM, Aaron Boodman a...@chromium.org wrote:
There is a bug in the code. The string %20250 needs to have single
quotes around it. If you add that, it works.
But there are better ways to write this since you're not constrained
to fit it all into a single javascript statement
Some people have expressed interest in implementing a translate this
page feature as an extension. This can be done as a content script
today, but it requires heavy and tricky modification of the DOM which
could introduce compat and performance problems.
Because of these problems, I'm exploring
On Mon, Jun 1, 2009 at 11:46 AM, Evan Martin e...@chromium.org wrote:
This feels kinda one-off-y to me. Is there any use of this *other*
than running through Google Translate? I worry about adding a lot of
API surface area for little gain.
That is one of the things I was concerned about
[I actually created this awhile ago, but never sent it 'round]
It is really common for extensions to want to offer additional
contextual options for content elements. For example Download this
movie, edit this image, call this phone number, etc.
You can use content scripts for this, but since
On Wed, Jun 3, 2009 at 1:33 PM, Brett Wilson bre...@chromium.org wrote:
Say I have an extension that allows me to open images in Photoshop.
Does that mean all images would have these things highlighting them?
That seems like it would be annoying.
Yeah, we'd have to experiment with the
, Andrew Charlton adcharl...@gmail.com wrote:
Could a gleam maybe be a popup toolstrip rather than a single icon - I
think that would open up lots of possibilities. You could have
something like chrome.gleam.getSelected to return the selection.
On Jun 4, 8:00 am, Aaron Boodman a...@chromium.org
You mean the idea in general won't work well, or this particular
approach? I talked it over with Feng awhile ago, and he seemed to
think the general idea was implementable. I think the code has changed
since then though, with workers.
- a
On Thu, Jun 4, 2009 at 10:00 AM, Mike Belshe
Hi Jack,
Is the detail on hover of the toolstrip meant to work in Chrome? I see
that you have a content script that looks like it wants to implement
this, but it doesn't seem to do anything for me.
Are you storing the preferences on the server? That is what it appears
like to me.
Nice work
On Tue, Jun 9, 2009 at 12:14 PM, jackjs2...@gmail.com wrote:
[Jack] It should be working in Chrome. Note when you hover over the
toolstrip AniWeather provides a detailed view of current condition
near the toolstrip. To avoid annoyance you have to stay your cursor on
the toolstrip for a while
On Tue, Jun 9, 2009 at 6:23 PM, Nick Baumnickb...@chromium.org wrote:
This is very cool, Jack. I l really like the polish of the UI, and in the
future I hope we can enable these kinds of interactions without needing to
use content scripts.
I wonder if we should retroactively inject
This is a known issue: the inspector is busted in the current dev
build. It should be fixed in the next dev release.
-a
On Wed, Jun 10, 2009 at 2:00 PM, Nebojša Ćirićnci...@gmail.com wrote:
I tried that too, but as I said, tools are broken for me. JavaScript console
window looks badly
as the page loads.
If the background page was guaranteed to load first, the toolstrips could
all make sure to find it when they loaded.
-Nick
2009/6/10 Aaron Boodman a...@chromium.org
On Wed, Jun 10, 2009 at 3:17 PM, Nebojša Ćirićnci...@gmail.com wrote:
What about the second issue? Shouldn't
all views // if loads first, no other views are going to be in the
list
...
all other views:
...
o. have a function that would update view once called from background page
...
Or do you expect views to poll background page?
Cira
2009/6/10 Aaron Boodman a...@chromium.org
I agree
On Thu, Jun 11, 2009 at 5:13 PM, Stuart Morganstuartmor...@chromium.org wrote:
I'm working on getting the Intl2 test set from the page cycler up and
running on the Mac, which currently crashes very quickly. It turns out
that one of the test pages has hundreds of images on it, and we
I landed the change to modify the format of extension IDs tonight
(http://src.chromium.org/viewvc/chrome?view=revrevision=18351).
This ended up requiring lots of test data files to be renamed, and
lots of little changes to the unit tests. I expect this to cause some
merge pain if you are working
Definitely a question for chromium-dev...
-- Forwarded message --
From: Dinge Raphael raphael.di...@gmail.com
Date: Mon, Jun 22, 2009 at 5:45 AM
Subject: [chromium-discuss] Integrating Chromium to my project
To: chromium-disc...@googlegroups.com
Hi,
(I'm not sure if this
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:
One important piece of feedback I got was that this system wouldn't
spider well. I've modified the proposal so that instead of generating
the final views at runtime, we generate them at check-in time using
something like Django:
On Tue, Jun 23, 2009 at 5:09 PM, Jeremy Orlowjor...@google.com wrote:
What your describing sounds exactly like a lightweight (i.e. only the
features you want) version of what's already out there. (At least now that
you've ditched the no file generation requirement.)
Unless you have some
On Tue, Jun 23, 2009 at 5:19 PM, Jeremy Orlowjor...@chromium.org wrote:
Why are you so against existing systems if you haven't even looked into
them?
I'm not -- I'm just fleshing out an idea at this point. I still need
to do the work of looking at existing systems and seeing how difficult
it
Thanks for sending this out, I'm excited to see i18n happen for
extensions. Here are some thoughts:
* I think it makes sense to use a flat file for the message
definitions. They don't have any structure, they are just a list of
name/value pairs. Each line could just be of the form
On Tue, Jun 30, 2009 at 1:13 PM, Jungshik Shin (신정식,
申政湜)js...@chromium.org wrote:
I like this way of avoiding having to ALL_ALL. On the other hand, stowing
away all the resource files somewhere below root might be a good idea ?
Maybe not because existing extensions have them in the root and
On Tue, Jun 30, 2009 at 3:24 PM, Nebojša Ćirićc...@chromium.org wrote:
2009/6/30 Aaron Boodman a...@chromium.org
Thanks for sending this out, I'm excited to see i18n happen for
extensions. Here are some thoughts:
* I think it makes sense to use a flat file for the message
definitions
On Tue, Jun 30, 2009 at 4:58 PM, Nebojša Ćirićc...@chromium.org wrote:
* This document should propose a specific JavaScript API for
programmatically resolving messages.
What do you thing about having a getMsg(key, optional_namespace) function
for JavaScript API (similar to gadgets api)?
So
1 - 100 of 224 matches
Mail list logo
