[chromium-dev] Re: Reviewers
I got it. Thanks On Wed, Jul 8, 2009 at 12:49 AM, Thiago Farinathiago.far...@gmail.com wrote: Lei can you review this patch for me? http://codereview.chromium.org/155078 On Jul 6, 11:56 pm, Lei Zhang thes...@chromium.org wrote: You didn't give enough context. It'll be more helpful if you put links to the patches you want reviewed. On Mon, Jul 6, 2009 at 7:47 PM, Thiago Farinathiago.far...@gmail.com wrote: When I don't know who can review some patch for me what I have to do? Currently I have 3 patchs waiting for review, but I haven't received any feedback or contact until now. What I have to do in this cases? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] A suggestion to Drastically improve build times,
First off, i am not complaining, just suggesting as the build (especially link gets slower and slower) I contribed code before to chrome, and plan to do so in the future, however even changing one line of Code in say browser.vcproj leads to 10+ mins of linking (yes TEN) what i did was wrote scripts which allow me to re-enable incremental linking and i was happy with it since you lately moved to libs for chrome_dll and the like, the process became harder but i still manage to enable incremental linking (there is an option in VS2008 to use objs instead of static libraries which re-enables incremental linking) just to give you a taste of why i say this without incremental linking i get 10+ mins of build time for changing just one line of code with inc linking i am down to ~15 seconds for a simple change,, which is SUCH a great improvement i recall you removed inc linking since some projects (i know of ui_tests) needs more than 2GB for linking but you could just disable it for this one project i hope you will re-consider introducing inc linking on VS thanx (btw, there are issues with re-introducing inc linking as lib and obj rules are different, but they are kinda small) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Who wants to fix a build warning?
CXX /.../out/Debug/obj/webkit/glue/temporary_glue.o In file included from ./base/timer.h:49, from ./webkit/glue/resource_fetcher.h:19, from ./webkit/glue/image_resource_fetcher.h:9, from ./webkit/glue/webview_impl.h:16, from webkit/glue/temporary_glue.cc:8: ./base/logging.h:226:1: warning: LOG redefined In file included from third_party/WebKit/JavaScriptCore/wtf/RefCounted.h:24, from third_party/WebKit/WebCore/history/BackForwardList.h:31, from ./webkit/glue/back_forward_list_client_impl.h:8, from ./webkit/glue/webview_impl.h:15, from webkit/glue/temporary_glue.cc:8: third_party/WebKit/JavaScriptCore/wtf/Assertions.h:230:1: warning: this is the location of the previous definition Thanks -- dean --~--~-~--~~~---~--~~ 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: Reviewers
Hi Dean, Thanks for commiting this patch to me. On Jul 8, 6:33 am, Dean McNamee de...@chromium.org wrote: I got it. Thanks On Wed, Jul 8, 2009 at 12:49 AM, Thiago Farinathiago.far...@gmail.com wrote: Lei can you review this patch for me? http://codereview.chromium.org/155078 On Jul 6, 11:56 pm, Lei Zhang thes...@chromium.org wrote: You didn't give enough context. It'll be more helpful if you put links to the patches you want reviewed. On Mon, Jul 6, 2009 at 7:47 PM, Thiago Farinathiago.far...@gmail.com wrote: When I don't know who can review some patch for me what I have to do? Currently I have 3 patchs waiting for review, but I haven't received any feedback or contact until now. What I have to do in this cases? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Issue Fixed status
I noticed that the Issue 7863, that me and jcampan, we fixed, are available until now. I saw there are some other Issues are with the status: Available, but already well fixed. So some issues are being fixed but are not being updated in the Issue List. --~--~-~--~~~---~--~~ 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: A suggestion to Drastically improve build times,
I wonder if it would be possible to have a conditional flag, maybe in common.gypi, that you would flip to turn on incremental linking, with still non-incremental linking being the default. On Wed, Jul 8, 2009 at 05:00, nakroyoav.zilberb...@gmail.com wrote: First off, i am not complaining, just suggesting as the build (especially link gets slower and slower) I contribed code before to chrome, and plan to do so in the future, however even changing one line of Code in say browser.vcproj leads to 10+ mins of linking (yes TEN) what i did was wrote scripts which allow me to re-enable incremental linking and i was happy with it since you lately moved to libs for chrome_dll and the like, the process became harder but i still manage to enable incremental linking (there is an option in VS2008 to use objs instead of static libraries which re-enables incremental linking) just to give you a taste of why i say this without incremental linking i get 10+ mins of build time for changing just one line of code with inc linking i am down to ~15 seconds for a simple change,, which is SUCH a great improvement i recall you removed inc linking since some projects (i know of ui_tests) needs more than 2GB for linking but you could just disable it for this one project i hope you will re-consider introducing inc linking on VS thanx (btw, there are issues with re-introducing inc linking as lib and obj rules are different, but they are kinda small) --~--~-~--~~~---~--~~ 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: A suggestion to Drastically improve build times,
Pawel, since i have it working on my machine (or i really could not code with chrome) i can tell you it is much more than a flag just as an example the name of chrome_dll.vcproj produces chrome.dll, but the incremental files would clash with chrome.vcproj who does the exe another example : you seem to have several 'TCMalloc_SystemAlloc' functions, which the linker can resolve if they are in a lib but would clash if linked as objects but none of this is too hard to solve, and i think is worth it i have a T5200 cpu (translated slow) and a very slow hard disk, but unless all of you have 8 cores and SSD i think we would all benefit from it especially that lately it seems more non google employees are trying to help with chrome --~--~-~--~~~---~--~~ 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: A suggestion to Drastically improve build times,
As a general observation on large development teams, infrastructure can get less love, because everyone comes to the team to work on the exciting main product, not the more mundane build infrastructure. If you have ideas on how to fix this stuff, I think it would be perfectly reasonable to put up patches that will improve things. Not as exciting as changing something that millions of people will see, perhaps, but if your request is ever to happen, SOMEONE has to do the gruntwork to make it happen... -scott On Wed, Jul 8, 2009 at 8:14 AM, nakroyoav.zilberb...@gmail.com wrote: Pawel, since i have it working on my machine (or i really could not code with chrome) i can tell you it is much more than a flag just as an example the name of chrome_dll.vcproj produces chrome.dll, but the incremental files would clash with chrome.vcproj who does the exe another example : you seem to have several 'TCMalloc_SystemAlloc' functions, which the linker can resolve if they are in a lib but would clash if linked as objects but none of this is too hard to solve, and i think is worth it i have a T5200 cpu (translated slow) and a very slow hard disk, but unless all of you have 8 cores and SSD i think we would all benefit from it especially that lately it seems more non google employees are trying to help with chrome --~--~-~--~~~---~--~~ 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: A suggestion to Drastically improve build times,
On Wed, Jul 8, 2009 at 11:14 AM, nakro yoav.zilberb...@gmail.com wrote: Pawel, since i have it working on my machine (or i really could not code with chrome) i can tell you it is much more than a flag just as an example the name of chrome_dll.vcproj produces chrome.dll, but the incremental files would clash with chrome.vcproj who does the exe This was fixed in the past by putting chrome.dll in the intermediary directory and hardlinking it afterward in the ouput directory. I don't know what happens with the GYP conversion. Before the conversion, only the single projects that failed to link on 32 bit OS had incremental linking disabled. I don't know why it was disabled for every projects afterward. Maybe Steven can shed some light on that. another example : you seem to have several 'TCMalloc_SystemAlloc' functions, which the linker can resolve if they are in a lib but would clash if linked as objects but none of this is too hard to solve, and i think is worth it About directly linking object files, it's just nobody taking the time to fix the remaining issues and enabling the flag. Patches are welcome. M-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: A suggestion to Drastically improve build times,
On Wed, Jul 8, 2009 at 11:03 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: I wonder if it would be possible to have a conditional flag, maybe in common.gypi, that you would flip to turn on incremental linking, with still non-incremental linking being the default. Something like this probably makes sense to be a generator flag. I just beefed up the support for these in GYP. A cl for that should be pretty simple. The general build layout changes would be within the GYP files and probably want a flag to enable. TVL On Wed, Jul 8, 2009 at 05:00, nakroyoav.zilberb...@gmail.com wrote: First off, i am not complaining, just suggesting as the build (especially link gets slower and slower) I contribed code before to chrome, and plan to do so in the future, however even changing one line of Code in say browser.vcproj leads to 10+ mins of linking (yes TEN) what i did was wrote scripts which allow me to re-enable incremental linking and i was happy with it since you lately moved to libs for chrome_dll and the like, the process became harder but i still manage to enable incremental linking (there is an option in VS2008 to use objs instead of static libraries which re-enables incremental linking) just to give you a taste of why i say this without incremental linking i get 10+ mins of build time for changing just one line of code with inc linking i am down to ~15 seconds for a simple change,, which is SUCH a great improvement i recall you removed inc linking since some projects (i know of ui_tests) needs more than 2GB for linking but you could just disable it for this one project i hope you will re-consider introducing inc linking on VS thanx (btw, there are issues with re-introducing inc linking as lib and obj rules are different, but they are kinda small) --~--~-~--~~~---~--~~ 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: A suggestion to Drastically improve build times,
So... do you think it will make things quicker on Visual Studio 2005 also?(Will the incremental linking work there, too, or do these changes require some 2008 features?) ☆PhistucK On Wed, Jul 8, 2009 at 18:43, nakro yoav.zilberb...@gmail.com wrote: Ok, i am happy it catches your attention sadly, i cannot submit patches for it as i wrote an external tool who does it automatically for me by patching the sln and vcproj/vsprops (i can pass the source code to anyone if wanted, its a C++ file) but what i would be glad to do if you want is clobber my build and submit here a report on how to enable this incremental build which files need changes (i had to modify source code for it, which is why it is not a simple flag thing) +the nasty flags of VS2008 like UseLibraryDependencyInputs and things like it again we are talking ~40x and beyond speedup on my machine, and i guess on anyones --~--~-~--~~~---~--~~ 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: A suggestion to Drastically improve build times,
Yeah, I guess so, but they are not going to invest too much time on the build system, as they have stated in this thread. ☆PhistucK On Wed, Jul 8, 2009 at 19:05, nakro yoav.zilberb...@gmail.com wrote: Phistuck, this is Exactly why this issue is best handled by chrome ppl and not outsides like myslef if VS2005 does not have the tricks of 2008 with regards to using the objects who made the library then all that is needed is to not produce libs as much and turn browser.vcproj and renderer.vcproj to simple folders under chrome_dll then again, i only use 3 programs from this solution (ui_test, unit_test, and chrome) so maybe putting it as folder under chrome_dll would actually hurt other things but all in all, VS2005 works pretty good with incremental linking from past experience but i really trust (and not as fake flattery) that the chrome ppl have a much better overview on how to properly solve it --~--~-~--~~~---~--~~ 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: Who wants to fix a build warning?
This is probably due to my change. I'll look into it if someone hasn't already. -Darin On Wed, Jul 8, 2009 at 5:46 AM, Dean McNamee de...@chromium.org wrote: CXX /.../out/Debug/obj/webkit/glue/temporary_glue.o In file included from ./base/timer.h:49, from ./webkit/glue/resource_fetcher.h:19, from ./webkit/glue/image_resource_fetcher.h:9, from ./webkit/glue/webview_impl.h:16, from webkit/glue/temporary_glue.cc:8: ./base/logging.h:226:1: warning: LOG redefined In file included from third_party/WebKit/JavaScriptCore/wtf/RefCounted.h:24, from third_party/WebKit/WebCore/history/BackForwardList.h:31, from ./webkit/glue/back_forward_list_client_impl.h:8, from ./webkit/glue/webview_impl.h:15, from webkit/glue/temporary_glue.cc:8: third_party/WebKit/JavaScriptCore/wtf/Assertions.h:230:1: warning: this is the location of the previous definition Thanks -- dean --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] running browser_tests on more bots
I noticed that browser_tests run on the Chromium XP buildbot, but I couldn't see them on other official (non-FYI) buildbots, and they don't run on trybots. What's blocking us from enabling these tests on more buildbots? --~--~-~--~~~---~--~~ 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: running browser_tests on more bots
On Wed, Jul 8, 2009 at 9:42 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: I noticed that browser_tests run on the Chromium XP buildbot, but I couldn't see them on other official (non-FYI) buildbots, and they don't run on trybots. What's blocking us from enabling these tests on more buildbots? Hmmm. They do run on try bots. They also do run in debug and release on both vista and xp too on the main watefall. Not sure where you would like to see them. (Except maybe linux and mac... and I need to work on that this week). Nicolas --~--~-~--~~~---~--~~ 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: A suggestion to Drastically improve build times,
On Wed, Jul 8, 2009 at 8:43 AM, nakro yoav.zilberb...@gmail.com wrote: Ok, i am happy it catches your attention sadly, i cannot submit patches for it as i wrote an external tool who does it automatically for me by patching the sln and vcproj/vsprops (i can pass the source code to anyone if wanted, its a C++ file) That's fine. It might make sense to port it to another language (like Python) but that's hard to say without being able to see the code. but what i would be glad to do if you want is clobber my build and submit here a report on how to enable this incremental build which files need changes (i had to modify source code for it, which is why it is not a simple flag thing) +the nasty flags of VS2008 like UseLibraryDependencyInputs and things like it again we are talking ~40x and beyond speedup on my machine, and i guess on anyones There might be ways to speed up 2005, but it seems like a win if we can (cleanly) speed up even 2008. Why not post the code somewhere? Or (even better) take a stab at some patches? This could help a lot of people...even those with the fast machines. :-) J --~--~-~--~~~---~--~~ 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: A suggestion to Drastically improve build times,
Jeremy, First off, i will be happy to share the code or exe or whatever you will wish the thing is this, i am very interested in chrome (code wise) but i never took a stab with all your gyp and scripts... and while i know enough python to read your scripts (i learned it for it) i have no access to all the machines you do and all the platforms . to keep it short i would guess it should take one of you who knows your gyp/gclient(?) system 2 hours (at MOST ... nothing close to it) to work this out, and i would be more than happy to have this person chat with me live so i can share what i learned marc suggested i could try this on a try server, but i thought only commiters have access to these the reason i think one from chrome is the best is because these changes could affect MAC and UNIX as well normally i solve my own problems and submit patches (i recall you from the text only zoom, right?) but this one requires an inside job i think my mail if you have a person who wants to chat about this is yoav.zilberb...@gmail.com --~--~-~--~~~---~--~~ 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: A suggestion to Drastically improve build times,
On Wed, Jul 8, 2009 at 10:46 AM, nakroyoav.zilberb...@gmail.com wrote: the reason i think one from chrome is the best is because these changes could affect MAC and UNIX as well Regarding incremental linking: I don't believe it exists on Linux, but gold is quite fast. My links take around ~5s, though I have a very fast machine. --~--~-~--~~~---~--~~ 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: Rewrite of DOMUI l10n strings
Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik --~--~-~--~~~---~--~~ 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: Rewrite of DOMUI l10n strings
This time from a Chromium account: It would be nice if we didn't have to use JS and could just embed the strings live so that they could be cached, etc. Our CSS (and maybe even JS) files could use something like this, (currently we're just doing $0-$9 replacement). This may be separate to what you're looking for. On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidssona...@chromium.org wrote: Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik --~--~-~--~~~---~--~~ 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: Rewrite of DOMUI l10n strings
On Wed, Jul 8, 2009 at 11:05, Glen Murphyg...@chromium.org wrote: This time from a Chromium account: It would be nice if we didn't have to use JS and could just embed the strings live so that they could be cached, etc. Our CSS (and maybe even JS) files could use something like this, (currently we're just doing $0-$9 replacement). I'm not sure what you mean be embed the strings live so that they could be cached? This may be separate to what you're looking for. It was different from what I had in mind but maybe we should do the string injection on the front end instead of JS? What was the reason for doing it in JS in the first place? On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidssona...@chromium.org wrote: Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik -- erik --~--~-~--~~~---~--~~ 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: Rewrite of DOMUI l10n strings
What are the more advanced things that we use JST for? Off the top of my head, all I can think of is bulleted lists. I think we went with a JS solution because it seemed easier and safer at the time. I'm ok with doing string injection in the front end (i.e., a C++ HTML templating library), I'm just concerned about XSS. Is there a good existing library that would integrate well into chromium? On Wed, Jul 8, 2009 at 11:09 AM, Erik Arvidssona...@chromium.org wrote: On Wed, Jul 8, 2009 at 11:05, Glen Murphyg...@chromium.org wrote: This time from a Chromium account: It would be nice if we didn't have to use JS and could just embed the strings live so that they could be cached, etc. Our CSS (and maybe even JS) files could use something like this, (currently we're just doing $0-$9 replacement). I'm not sure what you mean be embed the strings live so that they could be cached? This may be separate to what you're looking for. It was different from what I had in mind but maybe we should do the string injection on the front end instead of JS? What was the reason for doing it in JS in the first place? On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidssona...@chromium.org wrote: Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik -- erik --~--~-~--~~~---~--~~ 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: Rewrite of DOMUI l10n strings
I'm not sure what you mean be embed the strings live so that they could be cached? Sorry. For things like CSS, it's convenient that we do all the string injection in the backend so that the frontend can cache the result and not have to do any work the next time the resource is requested. This may allow us to further speed up the DOM pages. --~--~-~--~~~---~--~~ 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: Rewrite of DOMUI l10n strings
On Wed, Jul 8, 2009 at 11:13, Tony Changt...@chromium.org wrote: What are the more advanced things that we use JST for? Off the top of my head, all I can think of is bulleted lists. jsselect - which allows iteration. This is used for bulleted lists and the like eval/switch - this is used to allowed arbitrary JS expressions but it is only used inside jsselect at the moments. I think we went with a JS solution because it seemed easier and safer at the time. I'm ok with doing string injection in the front end (i.e., a C++ HTML templating library), I'm just concerned about XSS. Is there a good existing library that would integrate well into chromium? I'm not sure. I think a small js solution is something I can do in a day or two and it will buy us about 30ms on every DOMUI page. Any objections to me going ahead with my initial plan? On Wed, Jul 8, 2009 at 11:09 AM, Erik Arvidssona...@chromium.org wrote: On Wed, Jul 8, 2009 at 11:05, Glen Murphyg...@chromium.org wrote: This time from a Chromium account: It would be nice if we didn't have to use JS and could just embed the strings live so that they could be cached, etc. Our CSS (and maybe even JS) files could use something like this, (currently we're just doing $0-$9 replacement). I'm not sure what you mean be embed the strings live so that they could be cached? This may be separate to what you're looking for. It was different from what I had in mind but maybe we should do the string injection on the front end instead of JS? What was the reason for doing it in JS in the first place? On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidssona...@chromium.org wrote: Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik -- erik -- erik --~--~-~--~~~---~--~~ 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: Rewrite of DOMUI l10n strings
This seems like a reasonable plan. It would be cool if whatever mechanism you chose could be leveraged by extensions as well (see the earlier extensions i18n proposal that was sent around last week). For this reason I'd prefer that if we moved to a C++ solution (as others in this thread have suggested) that it run in the renderer and not in the browser process (for security reasons). Erik On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidsson a...@chromium.org wrote: Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik --~--~-~--~~~---~--~~ 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: Rewrite of DOMUI l10n strings
On Wed, Jul 8, 2009 at 11:29, Erik Kayerik...@chromium.org wrote: This seems like a reasonable plan. It would be cool if whatever mechanism you chose could be leveraged by extensions as well (see the earlier extensions i18n proposal that was sent around last week). For this reason I'd prefer that if we moved to a C++ solution (as others in this thread have suggested) that it run in the renderer and not in the browser process (for security reasons). I'll go back and reread that design doc to see how that might change things. On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidsson a...@chromium.org wrote: Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik -- erik --~--~-~--~~~---~--~~ 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: Rewrite of DOMUI l10n strings
No objections from me-- a faster new tab page sounds great! A couple side goals to consider: - Maybe move this new js code into a pseudo protocol rather than appending the js blob into every html file. I think e.g., the devtools does this already. - It would be nice if this would some day completely replace jstemplate, but maybe that's not really worth the effort. On Wed, Jul 8, 2009 at 11:28 AM, Erik Arvidssona...@chromium.org wrote: On Wed, Jul 8, 2009 at 11:13, Tony Changt...@chromium.org wrote: What are the more advanced things that we use JST for? Off the top of my head, all I can think of is bulleted lists. jsselect - which allows iteration. This is used for bulleted lists and the like eval/switch - this is used to allowed arbitrary JS expressions but it is only used inside jsselect at the moments. I think we went with a JS solution because it seemed easier and safer at the time. I'm ok with doing string injection in the front end (i.e., a C++ HTML templating library), I'm just concerned about XSS. Is there a good existing library that would integrate well into chromium? I'm not sure. I think a small js solution is something I can do in a day or two and it will buy us about 30ms on every DOMUI page. Any objections to me going ahead with my initial plan? On Wed, Jul 8, 2009 at 11:09 AM, Erik Arvidssona...@chromium.org wrote: On Wed, Jul 8, 2009 at 11:05, Glen Murphyg...@chromium.org wrote: This time from a Chromium account: It would be nice if we didn't have to use JS and could just embed the strings live so that they could be cached, etc. Our CSS (and maybe even JS) files could use something like this, (currently we're just doing $0-$9 replacement). I'm not sure what you mean be embed the strings live so that they could be cached? This may be separate to what you're looking for. It was different from what I had in mind but maybe we should do the string injection on the front end instead of JS? What was the reason for doing it in JS in the first place? On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidssona...@chromium.org wrote: Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik -- erik -- erik --~--~-~--~~~---~--~~ 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: Rewrite of DOMUI l10n strings
Ideally we would use an existing library instead of rolling our own. One major benefit of using existing code is that all the XSS holes will have been worked out already. Adam On Wed, Jul 8, 2009 at 11:36 AM, Tony Changt...@chromium.org wrote: No objections from me-- a faster new tab page sounds great! A couple side goals to consider: - Maybe move this new js code into a pseudo protocol rather than appending the js blob into every html file. I think e.g., the devtools does this already. - It would be nice if this would some day completely replace jstemplate, but maybe that's not really worth the effort. On Wed, Jul 8, 2009 at 11:28 AM, Erik Arvidssona...@chromium.org wrote: On Wed, Jul 8, 2009 at 11:13, Tony Changt...@chromium.org wrote: What are the more advanced things that we use JST for? Off the top of my head, all I can think of is bulleted lists. jsselect - which allows iteration. This is used for bulleted lists and the like eval/switch - this is used to allowed arbitrary JS expressions but it is only used inside jsselect at the moments. I think we went with a JS solution because it seemed easier and safer at the time. I'm ok with doing string injection in the front end (i.e., a C++ HTML templating library), I'm just concerned about XSS. Is there a good existing library that would integrate well into chromium? I'm not sure. I think a small js solution is something I can do in a day or two and it will buy us about 30ms on every DOMUI page. Any objections to me going ahead with my initial plan? On Wed, Jul 8, 2009 at 11:09 AM, Erik Arvidssona...@chromium.org wrote: On Wed, Jul 8, 2009 at 11:05, Glen Murphyg...@chromium.org wrote: This time from a Chromium account: It would be nice if we didn't have to use JS and could just embed the strings live so that they could be cached, etc. Our CSS (and maybe even JS) files could use something like this, (currently we're just doing $0-$9 replacement). I'm not sure what you mean be embed the strings live so that they could be cached? This may be separate to what you're looking for. It was different from what I had in mind but maybe we should do the string injection on the front end instead of JS? What was the reason for doing it in JS in the first place? On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidssona...@chromium.org wrote: Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik -- erik -- erik --~--~-~--~~~---~--~~ 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: Rewrite of DOMUI l10n strings
I reread the thread and the design doc and it does not really cover when string replacements should happen. Doing a JST lite for l10n is something that can be used in extensions but I think the long term solution is to do this on the front end. On Wed, Jul 8, 2009 at 11:33, Erik Arvidssona...@chromium.org wrote: On Wed, Jul 8, 2009 at 11:29, Erik Kayerik...@chromium.org wrote: This seems like a reasonable plan. It would be cool if whatever mechanism you chose could be leveraged by extensions as well (see the earlier extensions i18n proposal that was sent around last week). For this reason I'd prefer that if we moved to a C++ solution (as others in this thread have suggested) that it run in the renderer and not in the browser process (for security reasons). I'll go back and reread that design doc to see how that might change things. On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidsson a...@chromium.org wrote: Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik -- erik -- erik --~--~-~--~~~---~--~~ 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: Rewrite of DOMUI l10n strings
On Wed, Jul 8, 2009 at 12:00 PM, Aaron Boodmana...@chromium.org wrote: Agree with Erik that it seems like we should share this code between DOMUI and the extensions system. (Erik Kay) --~--~-~--~~~---~--~~ 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: Rewrite of DOMUI l10n strings
On Wed, Jul 8, 2009 at 11:51, Adam Barthaba...@chromium.org wrote: Ideally we would use an existing library instead of rolling our own. One major benefit of using existing code is that all the XSS holes will have been worked out already. Replacing JST with something custom is something I am totally comfortable with. If we end up doing the string replacing on the front end I do agree that we should use some existing library since this is a much harder problem. Adam On Wed, Jul 8, 2009 at 11:36 AM, Tony Changt...@chromium.org wrote: No objections from me-- a faster new tab page sounds great! A couple side goals to consider: - Maybe move this new js code into a pseudo protocol rather than appending the js blob into every html file. I think e.g., the devtools does this already. - It would be nice if this would some day completely replace jstemplate, but maybe that's not really worth the effort. On Wed, Jul 8, 2009 at 11:28 AM, Erik Arvidssona...@chromium.org wrote: On Wed, Jul 8, 2009 at 11:13, Tony Changt...@chromium.org wrote: What are the more advanced things that we use JST for? Off the top of my head, all I can think of is bulleted lists. jsselect - which allows iteration. This is used for bulleted lists and the like eval/switch - this is used to allowed arbitrary JS expressions but it is only used inside jsselect at the moments. I think we went with a JS solution because it seemed easier and safer at the time. I'm ok with doing string injection in the front end (i.e., a C++ HTML templating library), I'm just concerned about XSS. Is there a good existing library that would integrate well into chromium? I'm not sure. I think a small js solution is something I can do in a day or two and it will buy us about 30ms on every DOMUI page. Any objections to me going ahead with my initial plan? On Wed, Jul 8, 2009 at 11:09 AM, Erik Arvidssona...@chromium.org wrote: On Wed, Jul 8, 2009 at 11:05, Glen Murphyg...@chromium.org wrote: This time from a Chromium account: It would be nice if we didn't have to use JS and could just embed the strings live so that they could be cached, etc. Our CSS (and maybe even JS) files could use something like this, (currently we're just doing $0-$9 replacement). I'm not sure what you mean be embed the strings live so that they could be cached? This may be separate to what you're looking for. It was different from what I had in mind but maybe we should do the string injection on the front end instead of JS? What was the reason for doing it in JS in the first place? On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidssona...@chromium.org wrote: Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik -- erik -- erik -- erik --~--~-~--~~~---~--~~ 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: build errors in l10n_util.h
Sure, but how should I do that in gyp (properly)? I have some idea, but it would be good to verify. On Wed, Jul 8, 2009 at 12:18, Evan Martine...@chromium.org wrote: The missing files are part of ICU, so probably need to depend on that somewhere. http://www.google.com/codesearch?q=rbbi.h+package:chromium On Wed, Jul 8, 2009 at 12:12 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: I'm adding a browser test on linux, and it uses app/l10n_util.h. I'm getting these errors: In file included from /chromium/src/chrome/browser/browser_browsertest.cc:7: /chromium/src/app/l10n_util.h:23:26: error: unicode/coll.h: No such file or directory /chromium/src/app/l10n_util.h:24:27: error: unicode/locid.h: No such file or directory /chromium/src/app/l10n_util.h:25:26: error: unicode/rbbi.h: No such file or directory /chromium/src/app/l10n_util.h:26:27: error: unicode/ubidi.h: No such file or directory /chromium/src/app/l10n_util.h:27:27: error: unicode/uchar.h: No such file or directory browser_browsertest.cc is the new test file. I probably have to make more modifications to the gyp file. Any hints? --~--~-~--~~~---~--~~ 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: build errors in l10n_util.h
The missing files are part of ICU, so probably need to depend on that somewhere. http://www.google.com/codesearch?q=rbbi.h+package:chromium On Wed, Jul 8, 2009 at 12:12 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: I'm adding a browser test on linux, and it uses app/l10n_util.h. I'm getting these errors: In file included from /chromium/src/chrome/browser/browser_browsertest.cc:7: /chromium/src/app/l10n_util.h:23:26: error: unicode/coll.h: No such file or directory /chromium/src/app/l10n_util.h:24:27: error: unicode/locid.h: No such file or directory /chromium/src/app/l10n_util.h:25:26: error: unicode/rbbi.h: No such file or directory /chromium/src/app/l10n_util.h:26:27: error: unicode/ubidi.h: No such file or directory /chromium/src/app/l10n_util.h:27:27: error: unicode/uchar.h: No such file or directory browser_browsertest.cc is the new test file. I probably have to make more modifications to the gyp file. Any hints? --~--~-~--~~~---~--~~ 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: Issue Fixed status
Issue 7863 is fixed now. We can ask the fix committers to review the status of other unfixed issues. Do you have the issue numbers of other such issues? You can list them individually like: http://crbug.com/N On Jul 8, 7:45 am, Thiago Farina thiago.far...@gmail.com wrote: I noticed that the Issue 7863, that me and jcampan, we fixed, are available until now. I saw there are some other Issues are with the status: Available, but already well fixed. So some issues are being fixed but are not being updated in the Issue List. --~--~-~--~~~---~--~~ 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: build errors in l10n_util.h
Actually, my idea failed. I added dependencies for +'../third_party/icu38/icu38.gyp:icui18n', +'../third_party/icu38/icu38.gyp:icuuc', but it now complains even more, like: /chromium/src/third_party/icu38/public/i18n/unicode/ucol.h:1152: error: expected constructor, destructor, or type conversion before 'void' /chromium/src/third_party/icu38/public/i18n/unicode/ucol.h:1175: error: expected constructor, destructor, or type conversion before 'void' /chromium/src/third_party/icu38/public/i18n/unicode/ucol.h:1192: error: 'U_STABLE' does not name a type /chromium/src/third_party/icu38/public/i18n/unicode/ucol.h:1214: error: 'U_STABLE' does not name a type 2009/7/8 Paweł Hajdan Jr. phajdan...@chromium.org: Sure, but how should I do that in gyp (properly)? I have some idea, but it would be good to verify. On Wed, Jul 8, 2009 at 12:18, Evan Martine...@chromium.org wrote: The missing files are part of ICU, so probably need to depend on that somewhere. http://www.google.com/codesearch?q=rbbi.h+package:chromium On Wed, Jul 8, 2009 at 12:12 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: I'm adding a browser test on linux, and it uses app/l10n_util.h. I'm getting these errors: In file included from /chromium/src/chrome/browser/browser_browsertest.cc:7: /chromium/src/app/l10n_util.h:23:26: error: unicode/coll.h: No such file or directory /chromium/src/app/l10n_util.h:24:27: error: unicode/locid.h: No such file or directory /chromium/src/app/l10n_util.h:25:26: error: unicode/rbbi.h: No such file or directory /chromium/src/app/l10n_util.h:26:27: error: unicode/ubidi.h: No such file or directory /chromium/src/app/l10n_util.h:27:27: error: unicode/uchar.h: No such file or directory browser_browsertest.cc is the new test file. I probably have to make more modifications to the gyp file. Any hints? --~--~-~--~~~---~--~~ 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: Rewrite of DOMUI l10n strings
It seems like we want to do the string replacing in the front-end. Does anyone have any experience with C++ l10n/template libraries that we might want to use? On Wed, Jul 8, 2009 at 12:00, Aaron Boodmana...@chromium.org wrote: On Wed, Jul 8, 2009 at 12:00 PM, Aaron Boodmana...@chromium.org wrote: Agree with Erik that it seems like we should share this code between DOMUI and the extensions system. (Erik Kay) -- erik --~--~-~--~~~---~--~~ 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: running browser_tests on more bots
Looks like the tests don't run on the mac, I'll look into that. TVL On Wed, Jul 8, 2009 at 3:17 PM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: Hmmm. They do run on try bots. Oh, indeed. But only on Windows. But I noticed you're working on this, so - seems good. They also do run in debug and release on both vista and xp too on the main watefall. Not sure where you would like to see them. (Except maybe linux and mac... and I need to work on that this week). Yes, it was mostly linux mac question. Thanks for the info. --~--~-~--~~~---~--~~ 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: Rewrite of DOMUI l10n strings
2009/7/8 Erik Arvidsson a...@chromium.org It seems like we want to do the string replacing in the front-end. Does anyone have any experience with C++ l10n/template libraries that we might want to use? I don't have, but I just came across a few: http://www.clearsilver.net/ (Apache license, C library, i18n support is explicitly mentioned) http://teng.sourceforge.net/ (C++ library, LGPL) http://www.lazarusid.com/libtemplate.shtml (claimed to be much simpler than the two above. license unclear) I'll also ask around. Jungshik On Wed, Jul 8, 2009 at 12:00, Aaron Boodmana...@chromium.org wrote: On Wed, Jul 8, 2009 at 12:00 PM, Aaron Boodmana...@chromium.org wrote: Agree with Erik that it seems like we should share this code between DOMUI and the extensions system. (Erik Kay) -- erik --~--~-~--~~~---~--~~ 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: running browser_tests on more bots
Looks like the tests don't run on the mac, I'll look into that. TVL On Wed, Jul 8, 2009 at 3:17 PM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: Hmmm. They do run on try bots. Oh, indeed. But only on Windows. But I noticed you're working on this, so - seems good. They also do run in debug and release on both vista and xp too on the main watefall. Not sure where you would like to see them. (Except maybe linux and mac... and I need to work on that this week). Yes, it was mostly linux mac question. Thanks for the info. --~--~-~--~~~---~--~~ 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: Linking with custom fontconfig
Thanks for the answers. I got test_shell to link with my copy of fontconfig, but it doesn't show line numbers in valgrind's stacktrace. I compiled with CFLAGS=-m32 -ggdb3 CXXFLAGS=-m32 -ggdb3. What should I do to make valgrind display the line numbers? --~--~-~--~~~---~--~~ 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: Rewrite of DOMUI l10n strings
I uploaded a CL of what I initially had in mind. http://codereview.chromium.org/155245 I realized now that JST is used for non l10n templating so the name needs to change. Still, I think this is such a small change with such a big win that I want to continue down this path until we have some solution for doing the templating on the front end. 2009/7/8 Jungshik Shin (신정식, 申政湜) js...@chromium.org: 2009/7/8 Erik Arvidsson a...@chromium.org It seems like we want to do the string replacing in the front-end. Does anyone have any experience with C++ l10n/template libraries that we might want to use? I don't have, but I just came across a few: http://www.clearsilver.net/ (Apache license, C library, i18n support is explicitly mentioned) http://teng.sourceforge.net/ (C++ library, LGPL) http://www.lazarusid.com/libtemplate.shtml (claimed to be much simpler than the two above. license unclear) I'll also ask around. Jungshik On Wed, Jul 8, 2009 at 12:00, Aaron Boodmana...@chromium.org wrote: On Wed, Jul 8, 2009 at 12:00 PM, Aaron Boodmana...@chromium.org wrote: Agree with Erik that it seems like we should share this code between DOMUI and the extensions system. (Erik Kay) -- erik -- erik --~--~-~--~~~---~--~~ 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: Linking with custom fontconfig
On Wed, Jul 8, 2009 at 2:32 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: Thanks for the answers. I got test_shell to link with my copy of fontconfig, but it doesn't show line numbers in valgrind's stacktrace. I compiled with CFLAGS=-m32 -ggdb3 CXXFLAGS=-m32 -ggdb3. Not really sure. I would check that: * valgrind is loading the correct libraries (i.e. that LD_LIBRARY_PATH is correct when running valgrind) * That the .so really has symbols (should be obvious from the size, but also run strings on it) AGL --~--~-~--~~~---~--~~ 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: Linking with custom fontconfig
On Wed, Jul 8, 2009 at 15:35, Adam Langleya...@chromium.org wrote: On Wed, Jul 8, 2009 at 2:32 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: Thanks for the answers. I got test_shell to link with my copy of fontconfig, but it doesn't show line numbers in valgrind's stacktrace. I compiled with CFLAGS=-m32 -ggdb3 CXXFLAGS=-m32 -ggdb3. Not really sure. I would check that: * valgrind is loading the correct libraries (i.e. that LD_LIBRARY_PATH is correct when running valgrind) Yes. Valgrind just shows me the path to my local library instead of the file and line number. * That the .so really has symbols (should be obvious from the size, but also run strings on it) I'm attaching the output of strings. I'm not sure if it has symbols... The size of the lib is 226K, compared to 169K from my Goobuntu 32-bit fontconfig. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~--- strings Description: Binary data
[chromium-dev] Re: expected chromium changes for Chrome OS support
There are a handful of changes in the tree intended for Chrome OS. They are wrapped in the LINUX2 ifdef, which will shortly change to CHROME_OS. While you can certainly build this configuration on Linux now, running it outside of Chrome OS isn't particularly interesting. -Scott On Wed, Jul 8, 2009 at 8:24 AM, Marshall Greenblattmagreenbl...@gmail.com wrote: Hi All, Can anyone comment yet on expected chromium changes for Chrome OS support? http://googleblog.blogspot.com/2009/07/introducing-google-chrome-os.html Thanks, Marshall --~--~-~--~~~---~--~~ 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: expected chromium changes for Chrome OS support
On Wed, Jul 8, 2009 at 3:45 PM, Scott Violet s...@chromium.org wrote: While you can certainly build this configuration on Linux now, running it outside of Chrome OS isn't particularly interesting. (Since I was curious, I asked more about this) In particular, this configuration makes use of communications to/from the windowmanager that only exist with the Chrome OS windowmanager. Running it under a different window manager would be somewhere between boring and broken. PK --~--~-~--~~~---~--~~ 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: expected chromium changes for Chrome OS support
brave is between boring and broken On Wed, Jul 8, 2009 at 3:48 PM, Peter Kastingpkast...@google.com wrote: On Wed, Jul 8, 2009 at 3:45 PM, Scott Violet s...@chromium.org wrote: While you can certainly build this configuration on Linux now, running it outside of Chrome OS isn't particularly interesting. (Since I was curious, I asked more about this) In particular, this configuration makes use of communications to/from the windowmanager that only exist with the Chrome OS windowmanager. Running it under a different window manager would be somewhere between boring and broken. PK --~--~-~--~~~---~--~~ 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: Linking with custom fontconfig
On Wed, Jul 8, 2009 at 3:43 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: I'm attaching the output of strings. I'm not sure if it has symbols... The size of the lib is 226K, compared to 169K from my Goobuntu 32-bit fontconfig. It's not clear. objdump -x maybe? AGL --~--~-~--~~~---~--~~ 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: Linking with custom fontconfig
It says no symbols. :-/ Do you have an idea how can I get them? On Wed, Jul 8, 2009 at 16:15, Adam Langleya...@chromium.org wrote: On Wed, Jul 8, 2009 at 3:43 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: I'm attaching the output of strings. I'm not sure if it has symbols... The size of the lib is 226K, compared to 169K from my Goobuntu 32-bit fontconfig. It's not clear. objdump -x maybe? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~--- objdump Description: Binary data
[chromium-dev] Re: Linking with custom fontconfig
On Wed, Jul 8, 2009 at 4:22 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: It says no symbols. :-/ Do you have an idea how can I get them? When you're building fontconfig, you're building it with no optimization and -g for debugging symbols, right? -- Elliot --~--~-~--~~~---~--~~ 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: expected chromium changes for Chrome OS support
For consistency the define is going to be OS_CHROMEOS. -Scott On Wed, Jul 8, 2009 at 3:45 PM, Scott Violets...@chromium.org wrote: There are a handful of changes in the tree intended for Chrome OS. They are wrapped in the LINUX2 ifdef, which will shortly change to CHROME_OS. While you can certainly build this configuration on Linux now, running it outside of Chrome OS isn't particularly interesting. -Scott On Wed, Jul 8, 2009 at 8:24 AM, Marshall Greenblattmagreenbl...@gmail.com wrote: Hi All, Can anyone comment yet on expected chromium changes for Chrome OS support? http://googleblog.blogspot.com/2009/07/introducing-google-chrome-os.html Thanks, Marshall --~--~-~--~~~---~--~~ 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: Linking with custom fontconfig
Got it working! The steps I used: make clean CFLAGS=-m32 -g -ggdb3 CXXFLAGS=-m32 -g -ggdb3 ./configure --host=i686-pc-linux-gnu --enable-debug --with-debug --prefix=/home/phajdan/local CFLAGS=-m32 -g -ggdb3 CXXFLAGS=-m32 -g -ggdb3 make make install I think that not all of the flags are necessary, but it at least it does what I want. So, this enables me to continue fontconfig leak investigation. Thanks for great and quick help! On Wed, Jul 8, 2009 at 16:28, Elliot Glaysher (Chromium)e...@chromium.org wrote: On Wed, Jul 8, 2009 at 4:22 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: It says no symbols. :-/ Do you have an idea how can I get them? When you're building fontconfig, you're building it with no optimization and -g for debugging symbols, right? -- Elliot --~--~-~--~~~---~--~~ 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: Linking with custom fontconfig
Please don't forget to update http://code.google.com/p/chromium/wiki/LinuxDebugging :) On Wed, Jul 8, 2009 at 5:04 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: Got it working! The steps I used: make clean CFLAGS=-m32 -g -ggdb3 CXXFLAGS=-m32 -g -ggdb3 ./configure --host=i686-pc-linux-gnu --enable-debug --with-debug --prefix=/home/phajdan/local CFLAGS=-m32 -g -ggdb3 CXXFLAGS=-m32 -g -ggdb3 make make install I think that not all of the flags are necessary, but it at least it does what I want. So, this enables me to continue fontconfig leak investigation. Thanks for great and quick help! On Wed, Jul 8, 2009 at 16:28, Elliot Glaysher (Chromium)e...@chromium.org wrote: On Wed, Jul 8, 2009 at 4:22 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: It says no symbols. :-/ Do you have an idea how can I get them? When you're building fontconfig, you're building it with no optimization and -g for debugging symbols, right? -- Elliot --~--~-~--~~~---~--~~ 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: expected chromium changes for Chrome OS support
On Wed, Jul 8, 2009 at 6:45 PM, Scott Violet s...@chromium.org wrote: There are a handful of changes in the tree intended for Chrome OS. They are wrapped in the LINUX2 ifdef, which will shortly change to CHROME_OS. While you can certainly build this configuration on Linux now, running it outside of Chrome OS isn't particularly interesting. From the article it sounds like a good portion of the Chrome OS user interface will be hosted in (or based on) Chromium. I imagine this could require complex controls like tree views, icon lists, date pickers, etc. Will we see these controls as native extensions to Chromium and WebKit, or is a JavaScript toolkit layer more likely? Personally, I would love to see native support for these types of common yet complex controls :-). -Scott On Wed, Jul 8, 2009 at 8:24 AM, Marshall Greenblattmagreenbl...@gmail.com wrote: Hi All, Can anyone comment yet on expected chromium changes for Chrome OS support? http://googleblog.blogspot.com/2009/07/introducing-google-chrome-os.html Thanks, Marshall --~--~-~--~~~---~--~~ 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: expected chromium changes for Chrome OS support
On Wed, Jul 8, 2009 at 5:12 PM, Marshall Greenblatt magreenbl...@gmail.comwrote: I imagine this could require complex controls like tree views, icon lists, date pickers, etc. Will we see these controls as native extensions to Chromium and WebKit, or is a JavaScript toolkit layer more likely? Personally, I would love to see native support for these types of common yet complex controls :-). I don't see why you'd expect there to be more controls than there are now. The stated purpose is to get people on the web. You don't need a date picker to get on the web. Also note that many of the things you mention are part of HTML5 (see the various types under input) so they'll be supported in WebKit eventually anyway. PK --~--~-~--~~~---~--~~ 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: build errors in l10n_util.h
Problem resolved. Maybe I forgot to re-gyp at some point, or maybe it was something else... 2009/7/8 Paweł Hajdan Jr. phajdan...@chromium.org: Actually, my idea failed. I added dependencies for + '../third_party/icu38/icu38.gyp:icui18n', + '../third_party/icu38/icu38.gyp:icuuc', but it now complains even more, like: /chromium/src/third_party/icu38/public/i18n/unicode/ucol.h:1152: error: expected constructor, destructor, or type conversion before 'void' /chromium/src/third_party/icu38/public/i18n/unicode/ucol.h:1175: error: expected constructor, destructor, or type conversion before 'void' /chromium/src/third_party/icu38/public/i18n/unicode/ucol.h:1192: error: 'U_STABLE' does not name a type /chromium/src/third_party/icu38/public/i18n/unicode/ucol.h:1214: error: 'U_STABLE' does not name a type 2009/7/8 Paweł Hajdan Jr. phajdan...@chromium.org: Sure, but how should I do that in gyp (properly)? I have some idea, but it would be good to verify. On Wed, Jul 8, 2009 at 12:18, Evan Martine...@chromium.org wrote: The missing files are part of ICU, so probably need to depend on that somewhere. http://www.google.com/codesearch?q=rbbi.h+package:chromium On Wed, Jul 8, 2009 at 12:12 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: I'm adding a browser test on linux, and it uses app/l10n_util.h. I'm getting these errors: In file included from /chromium/src/chrome/browser/browser_browsertest.cc:7: /chromium/src/app/l10n_util.h:23:26: error: unicode/coll.h: No such file or directory /chromium/src/app/l10n_util.h:24:27: error: unicode/locid.h: No such file or directory /chromium/src/app/l10n_util.h:25:26: error: unicode/rbbi.h: No such file or directory /chromium/src/app/l10n_util.h:26:27: error: unicode/ubidi.h: No such file or directory /chromium/src/app/l10n_util.h:27:27: error: unicode/uchar.h: No such file or directory browser_browsertest.cc is the new test file. I probably have to make more modifications to the gyp file. Any hints? --~--~-~--~~~---~--~~ 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: Updating Rietveld by replying to codereview emails
Note: this finds the Rietveld issue number by looking for the last http://codereview.chromium.org/ url in the email. So make sure to leave that url in the email, and if you add another url to a different issue, don't put it at the end. On Mon, Jul 6, 2009 at 9:11 PM, John Abd-El-Malek j...@chromium.org wrote: Just a heads up that you can now reply to code review emails and your reply will show up on Rietveld. --~--~-~--~~~---~--~~ 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: Updating Rietveld by replying to codereview emails
Hm...I wonder how mondrian (an internal Google tool) does it... Maybe the chromium-revi...@googlegroups.com could be changed to chromium-reviews+the review number@googlegroups.com and that could be used instead? On Wed, Jul 8, 2009 at 5:44 PM, John Abd-El-Malek j...@chromium.org wrote: Note: this finds the Rietveld issue number by looking for the last http://codereview.chromium.org/ url in the email. So make sure to leave that url in the email, and if you add another url to a different issue, don't put it at the end. On Mon, Jul 6, 2009 at 9:11 PM, John Abd-El-Malek j...@chromium.orgwrote: Just a heads up that you can now reply to code review emails and your reply will show up on Rietveld. --~--~-~--~~~---~--~~ 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: expected chromium changes for Chrome OS support
On Wed, Jul 8, 2009 at 8:19 PM, Peter Kasting pkast...@google.com wrote: On Wed, Jul 8, 2009 at 5:12 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: I imagine this could require complex controls like tree views, icon lists, date pickers, etc. Will we see these controls as native extensions to Chromium and WebKit, or is a JavaScript toolkit layer more likely? Personally, I would love to see native support for these types of common yet complex controls :-). I don't see why you'd expect there to be more controls than there are now. The stated purpose is to get people on the web. You don't need a date picker to get on the web. Well, I wouldn't choose the the word expect -- hope would be more accurate :-) To answer your question, it's because these types of controls are time consuming to develop and easy to get wrong from a usage and accessibility standpoint. Sure, lots of AJAX frameworks exist, but they can't be optimized for the underlying operating system or even necessarily match expected OS behaviors. A browser-based toolkit that uses native implementations where possible could provide the user experience and feature richness that I think many people look for when planning or selecting applications. This can be especially true for a branded product where a consistent user experience is one of the most important selling features (iPhone anyone?). Also note that many of the things you mention are part of HTML5 (see the various types under input) so they'll be supported in WebKit eventually anyway. Hopefully HTML5 will being everything promised :-). PK --~--~-~--~~~---~--~~ 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: Updating Rietveld by replying to codereview emails
They put the id in the subject, but I wanted to avoid doing that. The smaller the subject, the more chance of seeing the lgtm or objections of others without reading the email. On Wed, Jul 8, 2009 at 6:17 PM, Jeremy Orlow jor...@chromium.org wrote: Hm...I wonder how mondrian (an internal Google tool) does it... Maybe the chromium-revi...@googlegroups.com could be changed to chromium-reviews+the review number@googlegroups.com and that could be used instead? On Wed, Jul 8, 2009 at 5:44 PM, John Abd-El-Malek j...@chromium.orgwrote: Note: this finds the Rietveld issue number by looking for the last http://codereview.chromium.org/ url in the email. So make sure to leave that url in the email, and if you add another url to a different issue, don't put it at the end. On Mon, Jul 6, 2009 at 9:11 PM, John Abd-El-Malek j...@chromium.orgwrote: Just a heads up that you can now reply to code review emails and your reply will show up on Rietveld. --~--~-~--~~~---~--~~ 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: expected chromium changes for Chrome OS support
On Wed, Jul 8, 2009 at 6:21 PM, Marshall Greenblatt magreenbl...@gmail.comwrote: On Wed, Jul 8, 2009 at 8:19 PM, Peter Kasting pkast...@google.com wrote: On Wed, Jul 8, 2009 at 5:12 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: I imagine this could require complex controls like tree views, icon lists, date pickers, etc. Will we see these controls as native extensions to Chromium and WebKit, or is a JavaScript toolkit layer more likely? Personally, I would love to see native support for these types of common yet complex controls :-). I don't see why you'd expect there to be more controls than there are now. The stated purpose is to get people on the web. You don't need a date picker to get on the web. Well, I wouldn't choose the the word expect -- hope would be more accurate :-) To answer your question, it's because these types of controls are time consuming to develop and easy to get wrong from a usage and accessibility standpoint. Sure, lots of AJAX frameworks exist, but they can't be optimized for the underlying operating system or even necessarily match expected OS behaviors. A browser-based toolkit that uses native implementations where possible could provide the user experience and feature richness that I think many people look for when planning or selecting applications. This can be especially true for a branded product where a consistent user experience is one of the most important selling features (iPhone anyone?). I don't think anyone's arguing that the new controls in HTML 5 are a good thing. The only confusion is why they'd be special on Chrome OS. Anything that's not provided directly by the OS (most if not all of the new ones, IIRC) will need to be done in WebKit itself. As such, I believe Chrome OS will get these all for free once they're implemented in WebKit. And there are people working on it as we speak. :-) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Chromium Teams
There is a place I can find a list which the teams of chromium and the names of their members? For example: UI Team: member's name; Extensions Team: member's name; Security Team:member's name; I'm asking this because I was writting a patch that changed the UI, and Glen said this have to be approved by UI team. So in this case for example, how should I proceed, how can I request approval for changes in UI? --~--~-~--~~~---~--~~ 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: Chromium Teams
I think it's good maintain the things simple, and I agree that all UI changes needs to be approved before starting code. Because I didn't know about that I started writting the patch without the approval. I think this feature is a good addition to chrome, because the firefox has this feature, many users from firefox will want this too in chrome. On Jul 9, 12:52 am, Glen Murphy g...@chromium.org wrote: I'm asking this because I was writting a patch that changed the UI, and Glen said this have to be approved by UI team. I am part of that team - the point was that UI changes should generally be run past the UI folk before work begins to avoid people doing work that is later rejected or that needs redesigning. That group of people is b...@chromium.org, g...@chromium.org, brakow...@chromium.org and nickb...@chromium.org - I am sending your screenshot from that patch to them to discuss. Typically we're pretty conservative when it comes to adding things. --~--~-~--~~~---~--~~ 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: Chromium Teams
On Wed, Jul 8, 2009 at 9:01 PM, Thiago Farina thiago.far...@gmail.comwrote: I think it's good maintain the things simple, and I agree that all UI changes needs to be approved before starting code. Because I didn't know about that I started writting the patch without the approval. I think this feature is a good addition to chrome, because the firefox has this feature, many users from firefox will want this too in chrome. I have no idea what feature you're working on, but as a general statement: there are many parts of Firefox that we don't necessarily want in Chromium. The home button is one of them (though I guess we grudgingly added it as an option). :-) I'd also note that chromium-dev is the best place to send pretty much everything. Even UI change questions can probably come here, though it helps to cc the specific people Glen mentioned. On Jul 9, 12:52 am, Glen Murphy g...@chromium.org wrote: I'm asking this because I was writting a patch that changed the UI, and Glen said this have to be approved by UI team. I am part of that team - the point was that UI changes should generally be run past the UI folk before work begins to avoid people doing work that is later rejected or that needs redesigning. That group of people is b...@chromium.org, g...@chromium.org, brakow...@chromium.org and nickb...@chromium.org - I am sending your screenshot from that patch to them to discuss. Typically we're pretty conservative when it comes to adding things. --~--~-~--~~~---~--~~ 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: some questions about chrome's layout-test
Ok, let me make question simple. I get some ERRORs on my DOS while running layout-test, such as : 090706 15:37:19 __init__.py:1032 ERROR LayoutTests/fast/backgrounds/svg-as-mask.html failed: Text diff mismatch Image mismatch These ERRORs are made of two kinds: expected and unexpected, the unexpected ERRORs will be counted as the final number in : 090706 15:44:24 __init__.py:1032 INFO Exit status: 9 right?? --~--~-~--~~~---~--~~ 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: Chromium Teams
On Wed, Jul 8, 2009 at 9:05 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Jul 8, 2009 at 9:01 PM, Thiago Farina thiago.far...@gmail.comwrote: I think it's good maintain the things simple, and I agree that all UI changes needs to be approved before starting code. Because I didn't know about that I started writting the patch without the approval. I think this feature is a good addition to chrome, because the firefox has this feature, many users from firefox will want this too in chrome. I have no idea what feature you're working on, but as a general statement: there are many parts of Firefox that we don't necessarily want in Chromium. The home button is one of them (though I guess we grudgingly added it as an option). :-) I meant to add that we're trying to make extensions a rich enough platform that most of these features can be added that wayit's just that we want to keep the base feature set and UI very clean, simple, and polished. I'd also note that chromium-dev is the best place to send pretty much everything. Even UI change questions can probably come here, though it helps to cc the specific people Glen mentioned. On Jul 9, 12:52 am, Glen Murphy g...@chromium.org wrote: I'm asking this because I was writting a patch that changed the UI, and Glen said this have to be approved by UI team. I am part of that team - the point was that UI changes should generally be run past the UI folk before work begins to avoid people doing work that is later rejected or that needs redesigning. That group of people is b...@chromium.org, g...@chromium.org, brakow...@chromium.org and nickb...@chromium.org - I am sending your screenshot from that patch to them to discuss. Typically we're pretty conservative when it comes to adding things. --~--~-~--~~~---~--~~ 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: Is extension/script communication broken in 3.0.192.1?
Thanks for your clarification Matt. I agree with you that in a long run a more comprehensive regression test would be helpful. Similar regression happened in a previous release that broke another part of extension (i.e., deleting a bookmark item would crash Chrome) that is still hanging around. -Jack On Jul 8, 6:28 pm, Matt Perry mpcompl...@chromium.org wrote: Yes, I broke content script messaging. Sorry :(. I filed bughttp://code.google.com/p/chromium/issues/detail?id=16228to track. I'm working on a fix, but it will be a few days and might miss the next dev channel release. Again, sorry about this. When my fix is in, we'll have better testing to ensure this doesn't happen again. On Wed, Jul 8, 2009 at 6:07 PM, jack js2...@gmail.com wrote: I am about to release a new version of AniWeather, but after upgraded to the new 3.0.192.1, everything stopped working, neither the new nor the old (stable) version. I checked the code and the script never got any msg from extension. To test it out, just download the version 0.5.8 that worked in up to 3.0.191.x from aniweather.com. Is it broken? Any comments? Thanks, -Jack --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
