[chromium-dev] Re: Qt now a possibility?
I think getting something out the door for linux is a priority, rather than having support for multiple toolkits. I'm pretty sure - having been a Linux desktop user for 8 yrs+ - that someone will have an itch to make a QT front end once there is a beta+ release. I'm gasping for a chrome release on linux. Firefox is fab, really fab, but I find the speed of Chromium is what I need now, Having a clean separation between the backend and the UI is an excellent idea. Well done guys, keep up the good work.. --~--~-~--~~~---~--~~ 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: Linux Omnibox
On Thu, Feb 19, 2009 at 4:53 AM, Dean McNamee de...@chromium.org wrote: I've started working on a GTK omnibox widget. I'll let you know when I have some more progress. I've been trying to figure out omnibox from the Mac side. I don't see anyone else having claimed it, let me know if I'm wrong. -scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [extensions] Thoughts on scaling
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 technically). It occurred to me that our current thoughts for how extensions are built may not be the best match for this kind of scalability. For example, we have said that extensions will have a background context that has the same lifetime as the browser process. Such a background context is useful for many types of extensions, but there are probably just as many that don't need it. For example, there are probably lots of tool use cases that only really need to run code after a button is clicked in the toolbar. Similar thoughts around user scripts. Sure it's useful to run code on page load, but there are lots of use cases that don't require that. They only need to inject code into the page when a button is clicked. Another interesting related thought is that an extension which runs code only in response to declared UI is safer than an extension which automatically runs code for every page, or runs code persistently in the background. This all led me to the conclusion that background contexts and user script injection should be options, but not the default way to get things done. Many extensions can be accomplished with some declarative UI, and then some code which will be run when the UI is used. No extension code needs to be run until the user actually chooses to use the extension. As soon as the code is complete the execution environment can be torn down. Extension processes can be created as necessary to support calls from user scripts, or to display HTML UI, but then could go away once they aren't needed anymore. Running background processes and running user scripts automatically could event be a permission that an extension declares that it wants to do and is presented to the user on installation. Thoughts? - a --~--~-~--~~~---~--~~ 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: [extensions] Thoughts on scaling
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 display the UI? We'd be able to do something primitive in the browser, like static button + text, but for more complicated things, we'd want an HTML renderer. On Mon, Feb 23, 2009 at 11:20 AM, Aaron Boodman a...@chromium.org wrote: 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 technically). It occurred to me that our current thoughts for how extensions are built may not be the best match for this kind of scalability. For example, we have said that extensions will have a background context that has the same lifetime as the browser process. Such a background context is useful for many types of extensions, but there are probably just as many that don't need it. For example, there are probably lots of tool use cases that only really need to run code after a button is clicked in the toolbar. Similar thoughts around user scripts. Sure it's useful to run code on page load, but there are lots of use cases that don't require that. They only need to inject code into the page when a button is clicked. Another interesting related thought is that an extension which runs code only in response to declared UI is safer than an extension which automatically runs code for every page, or runs code persistently in the background. This all led me to the conclusion that background contexts and user script injection should be options, but not the default way to get things done. Many extensions can be accomplished with some declarative UI, and then some code which will be run when the UI is used. No extension code needs to be run until the user actually chooses to use the extension. As soon as the code is complete the execution environment can be torn down. Extension processes can be created as necessary to support calls from user scripts, or to display HTML UI, but then could go away once they aren't needed anymore. Running background processes and running user scripts automatically could event be a permission that an extension declares that it wants to do and is presented to the user on installation. Thoughts? - a --~--~-~--~~~---~--~~ 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: [extensions] Thoughts on scaling
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 display the UI? We'd be able to do something primitive in the browser, like static button + text, but for more complicated things, we'd want an HTML renderer. We'd have to see how far we could get with just simple images and other declarative layout. For example, you could declare an image with different states, and that the states should change depending on whether certain types of elements exist in the rendered page. We'd still need the ability to spin up extension processes to render bigger UI, like when a dialog needs to be opened or a sidebar needs to be displayed. And we might still eventually want the ability to use HTML for more full-featured toolbars. - a --~--~-~--~~~---~--~~ 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: [extensions] Thoughts on scaling
In general, I'm all for this approach. As you said, I think a large number of trivial extensions are either purely action based, or can be handled dynamically declarative ways (for example, maybe a weather extension could fetch the latest weather icon from a declared URL, RSS feed). On Mon, Feb 23, 2009 at 12:51 PM, Aaron Boodman a...@chromium.org wrote: We'd still need the ability to spin up extension processes to render bigger UI, like when a dialog needs to be opened or a sidebar needs to be displayed. Agree. I think in general if we can be on-demand or lazy with process creation, it'll be a big win. Another example of this is an extenion's config page. Erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
