[chromium-dev] Re: Unable to download Chrome Source Code
Hi Nakro, Thank you for the reply.. Can you please guide me through the procedure to download via gclient tool, since I found no info regarding same on the website. Regards Pradeep On Jul 21, 1:20 am, nakro yoav.zilberb...@gmail.com wrote: Pradeep, i was also never able to download the source via the tarball what i did in the end was use gclient sync as it continues from where it left off, if the download is interrupted also a friend of mine could only get the source code like this --~--~-~--~~~---~--~~ 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: Unable to download Chrome Source Code
It is explained here, read the section regarding To check out directly from SVN::http://dev.chromium.org/developers/how-tos/get-the-code Or you could use the awesomeness git. http://code.google.com/p/chromium/wiki/UsingGit http://dev.chromium.org/developers/how-tos/get-the-code -- Mohamed Mansour On Tue, Jul 21, 2009 at 2:04 AM, Pradeep moluchan...@gmail.com wrote: Hi Nakro, Thank you for the reply.. Can you please guide me through the procedure to download via gclient tool, since I found no info regarding same on the website. Regards Pradeep On Jul 21, 1:20 am, nakro yoav.zilberb...@gmail.com wrote: Pradeep, i was also never able to download the source via the tarball what i did in the end was use gclient sync as it continues from where it left off, if the download is interrupted also a friend of mine could only get the source code like this --~--~-~--~~~---~--~~ 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: Unable to download Chrome Source Code
Thank you Mohamed fro your answer. I will definitely follow this link. Thanks Regards Pradeep On Jul 21, 11:16 am, Mohamed Mansour m...@chromium.org wrote: It is explained here, read the section regarding To check out directly from SVN::http://dev.chromium.org/developers/how-tos/get-the-code Or you could use the awesomeness git.http://code.google.com/p/chromium/wiki/UsingGit http://dev.chromium.org/developers/how-tos/get-the-code -- Mohamed Mansour On Tue, Jul 21, 2009 at 2:04 AM, Pradeep moluchan...@gmail.com wrote: Hi Nakro, Thank you for the reply.. Can you please guide me through the procedure to download via gclient tool, since I found no info regarding same on the website. Regards Pradeep On Jul 21, 1:20 am, nakro yoav.zilberb...@gmail.com wrote: Pradeep, i was also never able to download the source via the tarball what i did in the end was use gclient sync as it continues from where it left off, if the download is interrupted also a friend of mine could only get the source code like this --~--~-~--~~~---~--~~ 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: Mozilla design challenge
I feel like people are using tabs as a replacement for a good history system. At least in all current browser implementations, tabs are running. Even if we can make the UI scale to 1000 tabs, the 500 flash instances that are likely running aren't really going to perform. The making tab performance scale is a separate technical issue that will hopefully also improve. Looking at a lot of these design videos, they looked more like good ideas to me for history navigation than tab navigation. If history was good, I think people wouldn't be so worried about losing something by closing a tab. Having had bad history systems for so many years, people are now trained to keep tabs open if they ever might want to look at that page again in the future :\ On Sat, Jul 18, 2009 at 1:16 AM, Peter Kastingpkast...@google.com wrote: http://design-challenge.mozilla.com/summer09/ The results of the Reinventing Tabs in the Browser challenge have been announced. Collapsible Tab Groups includes among others some things I've proposed, including grouping and collapsing groups. Favitabs reminds me of some old brainstorming ideas from pamg about converting certain tabs into favicon buttons. Folks considering the future of tabs (e.g. Ben, Glen, Scott) might do well to take a look at some of these. 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] No more buildbot auto-refresh - Update your bookmark!
Hi, Last week a lot of people on this list said that they like the idea of disabling the auto-reload for our buildbot waterfall and console view. This is now implemented. If you do want to keep the page auto-refreshing, please update your bookmark. just add the query parameter reload=X, where X is the number of second to wait between each reloads. X used to be 90. Depending on your needs, you can increase or decrease this number. Examples: console view: http://build.chromium.org/buildbot/waterfall/console?reload=180 waterfall : http://build.chromium.org/buildbot/waterfall/waterfall?reload=180 For sheriffs: http://build.chromium.org/buildbot/waterfall/waterfall?failures=1reload=30 Thanks 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: Please keep TOOLKIT_VIEWS green!
Can we have a trybot with that configuration, which would just compile the code? I think it would really save people's time. I never build with TOOLKIT_VIEWS, and in case of breakage I would have to immediately revert and then investigate. If I got a trybot failure, I would know much more before committing. On Mon, Jul 20, 2009 at 17:50, Ben Goodger (Google) b...@chromium.orgwrote: This mostly applies to people working on UI. Sometime tonight or tomorrow we'll be moving the TOOLKIT_VIEWS builder to the front page of the waterfall. Right now it's building just the chrome target, and running no tests, but in time we'll build this out. This is an experimental build distinct from the standard Chromium linux which we will ship but a codepath which we will support as first class for other purposes. So please keep it green! If it goes red, the same rules that apply to any other builder on the front page will apply. To build, export GYP_DEFINES=toolkit_views=1 gclient runhooks --force hammer chrome Thanks, -Ben --~--~-~--~~~---~--~~ 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: Please keep TOOLKIT_VIEWS green!
On Mon, Jul 20, 2009 at 5:50 PM, Ben Goodger (Google) b...@chromium.orgwrote: This mostly applies to people working on UI. Sometime tonight or tomorrow we'll be moving the TOOLKIT_VIEWS builder to the front page of the waterfall. Right now it's building just the chrome target, and running no tests, but in time we'll build this out. This is an experimental build distinct from the standard Chromium linux which we will ship but a codepath which we will support as first class for other purposes. So please keep it green! If it goes red, the same rules that apply to any other builder on the front page will apply. Now available at : http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20(Toolkit%20dbg) To build, export GYP_DEFINES=toolkit_views=1 gclient runhooks --force hammer chrome Thanks, -Ben --~--~-~--~~~---~--~~ 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: Please keep TOOLKIT_VIEWS green!
On Tue, Jul 21, 2009 at 8:31 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: Can we have a trybot with that configuration, which would just compile the code? I think it would really save people's time. I never build with TOOLKIT_VIEWS, and in case of breakage I would have to immediately revert and then investigate. If I got a trybot failure, I would know much more before committing. Ben: How likely is this to break? I'm reluctant to add yet another try bot because they do take a lot of resources. There are maybe 200-300 try changes sent every day. That means we need enough resources to build this configuration that many times, and it needs to answer fast enough. I think we should create this try bot, but make it on demand only. We are already planning to do this for valgrind, purify and layout tests. That won't help much catching random errors at the first place, but at least you'll be able to see if you fixed it correctly. And if you think your code might be breaking it, you can always pre-emptively trigger a try run on this try bot. I'm not sure yet when this kind of infrastructure is going to be ready. I think it's on maruel's plate. Nicolas On Mon, Jul 20, 2009 at 17:50, Ben Goodger (Google) b...@chromium.orgwrote: This mostly applies to people working on UI. Sometime tonight or tomorrow we'll be moving the TOOLKIT_VIEWS builder to the front page of the waterfall. Right now it's building just the chrome target, and running no tests, but in time we'll build this out. This is an experimental build distinct from the standard Chromium linux which we will ship but a codepath which we will support as first class for other purposes. So please keep it green! If it goes red, the same rules that apply to any other builder on the front page will apply. To build, export GYP_DEFINES=toolkit_views=1 gclient runhooks --force hammer chrome Thanks, -Ben --~--~-~--~~~---~--~~ 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: Please keep TOOLKIT_VIEWS green!
On Tue, Jul 21, 2009 at 8:42 AM, Nicolas Sylvainnsylv...@chromium.org wrote: On Tue, Jul 21, 2009 at 8:31 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Can we have a trybot with that configuration, which would just compile the code? I think it would really save people's time. I never build with TOOLKIT_VIEWS, and in case of breakage I would have to immediately revert and then investigate. If I got a trybot failure, I would know much more before committing. Ben: How likely is this to break? I'm reluctant to add yet another try bot because they do take a lot of resources. There are maybe 200-300 try changes sent every day. That means we need enough resources to build this configuration that many times, and it needs to answer fast enough. I don't think an automatically-running trybot is very critical for this build at the moment. Most of the things that break it are pretty simple (need to add a file to GYP, or maybe a stub for something) so the breakage won't be super complicated. Most errors will be caught by the regular trybots. Brett --~--~-~--~~~---~--~~ 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: Mozilla design challenge
You may be on to something, but I think it's more complex than this. For example bookmark systems don't work because people use them for a number of conflicting purposes (my list of things to read every day, a simple history system, a 'to read' list, a collection of links for research), which have different UI requirements. I think the same thing has happened with tabs (and there's a surprising amount of overlap). Here are the use cases I know I wind up using: - a few long running apps that need to keep running, potentially notifying me of new events (calendar, mail, chat, buildbot, etc.) - a few pages that I'm currently actively using (a screenshot from a bug I'm looking at, some reference documentation, a writely page I'm editing between compiles, etc.) - a to read list of pages that I started reading but didn't finish yet (sometimes this is a collection of related pages when researching something) - I'm sure there are others. In my use case, 80% of my tabs could easily be killed / suspended (or even hidden altogether) without any downside to me. The problem is that there isn't a way to automatically figure out which ones are which. Which ones have pending state that might be lost? (yes, some of this is bad app design, but there are many like this) Which ones do I expect to keep running all of the time because of notifications? What about that flash game that I left running in the background? Maybe we could come up with some heuristics that could detect some of this automatically, but I worry that there will be so many exceptions that it won't work. That means we'd need to come up with a better UI to express these concepts where the user chose to treat tabs differently in some explicit way. There are a number of extensions that try to do this for some specific use cases (to read lists, pinned tabs, etc.). I'm not sure that these are better than bandaids though. Erik On Tue, Jul 21, 2009 at 8:28 AM, Dean McNamee de...@chromium.org wrote: I feel like people are using tabs as a replacement for a good history system. At least in all current browser implementations, tabs are running. Even if we can make the UI scale to 1000 tabs, the 500 flash instances that are likely running aren't really going to perform. The making tab performance scale is a separate technical issue that will hopefully also improve. Looking at a lot of these design videos, they looked more like good ideas to me for history navigation than tab navigation. If history was good, I think people wouldn't be so worried about losing something by closing a tab. Having had bad history systems for so many years, people are now trained to keep tabs open if they ever might want to look at that page again in the future :\ On Sat, Jul 18, 2009 at 1:16 AM, Peter Kastingpkast...@google.com wrote: http://design-challenge.mozilla.com/summer09/ The results of the Reinventing Tabs in the Browser challenge have been announced. Collapsible Tab Groups includes among others some things I've proposed, including grouping and collapsing groups. Favitabs reminds me of some old brainstorming ideas from pamg about converting certain tabs into favicon buttons. Folks considering the future of tabs (e.g. Ben, Glen, Scott) might do well to take a look at some of these. 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: Mozilla design challenge
+1. There are tabs which I am using and will use consistently all the time (mail, calendar, things like that). For awhile on Firefox I had those pinned and turned into favicon-only tabs using extensions, and it mostly worked well. Then there are collections of on deck tabs associated with things I'm doing. These might be documentation and the like, and mostly I don't need them to be live, I just need them to be easily available, and I'd like them to be grouped together. And then there are one-off tabs like watching a video and looking at someone's photos or reading news, where I'm just going to grind through their contents and dismiss them. There may be new and interesting presentation ideas in there. For a collection of documentation tabs, I might be happy to freeze-dry them in a form which will let me easily come back to them, but which doesn't have to be live at all. Like PDFifying them, except I'd still want them to be resizable and stuff. I'd be very happy if I could do searches over the entire group, or have the browser show me snippets from other docs in the group which might reflect on the doc I'm reading, I'd be super happy if these docs were optimized such that I could flip between them super-duper fast. -scott On Tue, Jul 21, 2009 at 8:28 AM, Dean McNameede...@chromium.org wrote: I feel like people are using tabs as a replacement for a good history system. At least in all current browser implementations, tabs are running. Even if we can make the UI scale to 1000 tabs, the 500 flash instances that are likely running aren't really going to perform. The making tab performance scale is a separate technical issue that will hopefully also improve. Looking at a lot of these design videos, they looked more like good ideas to me for history navigation than tab navigation. If history was good, I think people wouldn't be so worried about losing something by closing a tab. Having had bad history systems for so many years, people are now trained to keep tabs open if they ever might want to look at that page again in the future :\ On Sat, Jul 18, 2009 at 1:16 AM, Peter Kastingpkast...@google.com wrote: http://design-challenge.mozilla.com/summer09/ The results of the Reinventing Tabs in the Browser challenge have been announced. Collapsible Tab Groups includes among others some things I've proposed, including grouping and collapsing groups. Favitabs reminds me of some old brainstorming ideas from pamg about converting certain tabs into favicon buttons. Folks considering the future of tabs (e.g. Ben, Glen, Scott) might do well to take a look at some of these. 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: Mozilla design challenge
On Tue, Jul 21, 2009 at 12:32 PM, Erik Kayerik...@chromium.org wrote: In my use case, 80% of my tabs could easily be killed / suspended (or even hidden altogether) without any downside to me. The problem is that there isn't a way to automatically figure out which ones are which. Which ones have pending state that might be lost? Well, to a first approximation, ones which have had user interaction besides scrolling since they were opened? (typing, navigating a link, etc.) --Amanda --~--~-~--~~~---~--~~ 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: Mozilla design challenge
On Tue, Jul 21, 2009 at 9:52 AM, Amanda Walker ama...@chromium.org wrote: On Tue, Jul 21, 2009 at 12:32 PM, Erik Kayerik...@chromium.org wrote: In my use case, 80% of my tabs could easily be killed / suspended (or even hidden altogether) without any downside to me. The problem is that there isn't a way to automatically figure out which ones are which. Which ones have pending state that might be lost? Well, to a first approximation, ones which have had user interaction besides scrolling since they were opened? (typing, navigating a link, etc.) I frequently avoid interacting with articles from popular news sites for thirty seconds or so (as they sit in the background) to let their stupid interstitial ad timeouts fire. Scott Hess' comment that some tabs could be changed into static documents is accurate from a UX perspective, but as this thread has already mentioned it's hard to decide which tabs those are. For example, today we load tabs opened from gmail in the same renderer process as gmail because we don't realize that those two pages are never going to script each other. If we don't know page A and page B won't script each other, how can we freeze A or B? To put it even more simply, if given a tab A, how do we know it won't run script at some point in the future? My own claim is that multiselection of tabs is implementable and useful, and we should start by implementing that (which in fact Ben is currently doing, I think), and then see if it helps any of our organization issues. After that, perhaps some concept of tab pinning would be useful. The idea here is to add things we know we can do in hopes that better usage patterns emerge, instead of trying to envision the ideal design from nothing :) 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: Question about V8 bindings
Sigh. I keep sending this with the wrong email address. I wish Gmail would just use the address from the last time I replied to the thread. -=-=- It seems like that would have some undesirable side-effects, aside from the fact that WebKit frowns on using virtual functions unnecessarily. So, let's imagine that I have two derived classes, SharedWorkerContext and DedicatedWorkerContext. DedicatedWorkerContext wants to expose postMessage() as a public callable function, but SharedWorkerContext would not. If we only have a single V8 class for both of these (WORKERCONTEXT) then that implies: 1) I have to define postMessage() as a virtual function on the base WebCore class (WorkerContext). In fact, WorkerContext ends up containing the union of all exposed APIs for every future derived class, which seems ugly. 2) From javascript, if I have a SharedWorkerContext, and I do this typeof postMessage, it should return undefined (since SharedWorkerContext does not define this attribute) - however, since SharedWorkerContext is actually just a vanilla WORKERCONTEXT behind the scenes, it would return function, which violates the spec. It seems like the right way to do this is to actually have separate V8 items. The alternative is to have just a single WORKERCONTEXT, but instead of using polymorphism have custom getters/setters for every attribute that check the type of the impl class and do the appropriate thing. But it seems like the whole point of having the V8ClassIndex enum is to avoid this kind of manual polymorphism. -atw On Mon, Jul 20, 2009 at 8:22 PM, Jeremy Orlow jor...@chromium.org wrote: In other words, make all workers appear the same to V8 (i.e. as a WORKERCONTEXT) and then implement polymorphism in the implementations being wrapped by V8. On Mon, Jul 20, 2009 at 8:19 PM, Jeremy Orlow jor...@chromium.org wrote: Sorry if this is a dumb question, but why woudn't you simply have a WORKERCONTEXT and let virtual dispatch do its job for the rest? Shared methods can be implemented on the base class and the rest can be purely virtual with implementations in the sub classes. J On Mon, Jul 20, 2009 at 3:21 PM, Drew Wilson atwil...@chromium.orgwrote: Following up on this. Let's imagine that I don't define a V8ClassIndex enum for the common base class (so, in my case, I get rid of WORKERCONTEXT, and have only DEDICATEDWORKERCONTEXT and SHAREDWORKERCONTEXT (the derived classes). Now, let's say I'm defining an ACCESSOR_GETTER on the base class - the first thing I want to do is get a pointer to the native object. I don't know which concrete class the native object is (DedicatedWorkerContext or SharedWorkerContext), but I do know that it's guaranteed to be an instance of the base native class (WorkerContext). Currently I'm doing this: WorkerContext* workerContext = V8DOMWrapper::convertToNativeObjectWorkerContext(V8ClassIndex::WORKERCONTEXT, info.Holder()); If I remove V8ClassIndex::WORKERCONTEXT, then I can't pass that in to convertToNativeObject. It looks like the passed-in enum is only used for error checking currently, so I guess what I should use instead is convertDOMWrapperToNative()?: WorkerContext* workerContext = V8DOMWrapper::convertDOMWrapperToNativeWorkerContext(info.Holder()); Is that the general pattern people use for cases like this? -atw On Mon, Jul 20, 2009 at 3:21 PM, Drew Wilson atwil...@chromium.orgwrote: resending from correct acct: Currently, Web Workers have a class (WorkerContext) which represents the global scope for a worker. The custom V8 bindings for this class are defined in V8WorkerContextCustom, and we also define V8ClassIndex::WORKERCONTEXT for the wrapper object. I'm refactoring the WebCore impl class, so WorkerContext becomes (essentially) an abstract base class, and the actual worker context will be one of two derived classes: DedicatedWorkerContext or SharedWorkerContext. In my refactoring, I've only implemented a single derived class (DedicatedWorkerContext) for now. I'm trying to figure out the correct way to structure the V8 bindings - I've already made a pass at it that passes all of the unit tests: https://bugs.webkit.org/show_bug.cgi?id=27420 I've defined V8ClassIndex::DEDICATEDWORKERCONTEXT, but I'm not certain if I need to remove V8ClassIndex::WORKERCONTEXT or not, since there shouldn't ever be a wrapper object created for that base class. Are the wrapper types defined in V8Index.h only for actually instantiable wrapper objects (in which case I should only define them for the leaves of the tree), or is it used for other things like instanceof? -atw --~--~-~--~~~---~--~~ 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: Question about V8 bindings
On Tue, Jul 21, 2009 at 10:19 AM, Drew Wilson atwil...@google.com wrote: It seems like that would have some undesirable side-effects, aside from the fact that WebKit frowns on using virtual functions unnecessarily. So, let's imagine that I have two derived classes, SharedWorkerContext and DedicatedWorkerContext. DedicatedWorkerContext wants to expose postMessage() as a public callable function, but SharedWorkerContext would not. If we only have a single V8 class for both of these (WORKERCONTEXT) then that implies: 1) I have to define postMessage() as a virtual function on the base WebCore class (WorkerContext). In fact, WorkerContext ends up containing the union of all exposed APIs for every future derived class, which seems ugly. 2) From javascript, if I have a SharedWorkerContext, and I do this typeof postMessage, it should return undefined (since SharedWorkerContext does not define this attribute) - however, since SharedWorkerContext is actually just a vanilla WORKERCONTEXT behind the scenes, it would return function, which violates the spec. It seems like the right way to do this is to actually have separate V8 items. The alternative is to have just a single WORKERCONTEXT, but instead of using polymorphism have custom getters/setters for every attribute that check the type of the impl class and do the appropriate thing. But it seems like the whole point of having the V8ClassIndex enum is to avoid this kind of manual polymorphism. Good points. Are there other use cases for building polymorphism into V8? Is there any notion of polymorphism in the IDL files? Maybe the best answer is to just make them two completely different classes. It kind of seems like doing this elegantly is going to cost us performance wise one way or another. J On Mon, Jul 20, 2009 at 8:22 PM, Jeremy Orlow jor...@chromium.org wrote: In other words, make all workers appear the same to V8 (i.e. as a WORKERCONTEXT) and then implement polymorphism in the implementations being wrapped by V8. On Mon, Jul 20, 2009 at 8:19 PM, Jeremy Orlow jor...@chromium.orgwrote: Sorry if this is a dumb question, but why woudn't you simply have a WORKERCONTEXT and let virtual dispatch do its job for the rest? Shared methods can be implemented on the base class and the rest can be purely virtual with implementations in the sub classes. J On Mon, Jul 20, 2009 at 3:21 PM, Drew Wilson atwil...@chromium.orgwrote: Following up on this. Let's imagine that I don't define a V8ClassIndex enum for the common base class (so, in my case, I get rid of WORKERCONTEXT, and have only DEDICATEDWORKERCONTEXT and SHAREDWORKERCONTEXT (the derived classes). Now, let's say I'm defining an ACCESSOR_GETTER on the base class - the first thing I want to do is get a pointer to the native object. I don't know which concrete class the native object is (DedicatedWorkerContext or SharedWorkerContext), but I do know that it's guaranteed to be an instance of the base native class (WorkerContext). Currently I'm doing this: WorkerContext* workerContext = V8DOMWrapper::convertToNativeObjectWorkerContext(V8ClassIndex::WORKERCONTEXT, info.Holder()); If I remove V8ClassIndex::WORKERCONTEXT, then I can't pass that in to convertToNativeObject. It looks like the passed-in enum is only used for error checking currently, so I guess what I should use instead is convertDOMWrapperToNative()?: WorkerContext* workerContext = V8DOMWrapper::convertDOMWrapperToNativeWorkerContext(info.Holder()); Is that the general pattern people use for cases like this? -atw On Mon, Jul 20, 2009 at 3:21 PM, Drew Wilson atwil...@chromium.orgwrote: resending from correct acct: Currently, Web Workers have a class (WorkerContext) which represents the global scope for a worker. The custom V8 bindings for this class are defined in V8WorkerContextCustom, and we also define V8ClassIndex::WORKERCONTEXT for the wrapper object. I'm refactoring the WebCore impl class, so WorkerContext becomes (essentially) an abstract base class, and the actual worker context will be one of two derived classes: DedicatedWorkerContext or SharedWorkerContext. In my refactoring, I've only implemented a single derived class (DedicatedWorkerContext) for now. I'm trying to figure out the correct way to structure the V8 bindings - I've already made a pass at it that passes all of the unit tests: https://bugs.webkit.org/show_bug.cgi?id=27420 I've defined V8ClassIndex::DEDICATEDWORKERCONTEXT, but I'm not certain if I need to remove V8ClassIndex::WORKERCONTEXT or not, since there shouldn't ever be a wrapper object created for that base class. Are the wrapper types defined in V8Index.h only for actually instantiable wrapper objects (in which case I should only define them for the leaves of the tree), or is it used for other things like instanceof? -atw --~--~-~--~~~---~--~~ Chromium Developers mailing list:
[chromium-dev] Re: Question about V8 bindings
On Tue, Jul 21, 2009 at 10:27 AM, Drew Wilson atwil...@chromium.org wrote: Sigh. I keep sending this with the wrong email address. I wish Gmail would just use the address from the last time I replied to the thread. Settings - Accounts - When receiving a message:Reply from the same address the message was sent to -=-=- It seems like that would have some undesirable side-effects, aside from the fact that WebKit frowns on using virtual functions unnecessarily. So, let's imagine that I have two derived classes, SharedWorkerContext and DedicatedWorkerContext. DedicatedWorkerContext wants to expose postMessage() as a public callable function, but SharedWorkerContext would not. If we only have a single V8 class for both of these (WORKERCONTEXT) then that implies: 1) I have to define postMessage() as a virtual function on the base WebCore class (WorkerContext). In fact, WorkerContext ends up containing the union of all exposed APIs for every future derived class, which seems ugly. 2) From javascript, if I have a SharedWorkerContext, and I do this typeof postMessage, it should return undefined (since SharedWorkerContext does not define this attribute) - however, since SharedWorkerContext is actually just a vanilla WORKERCONTEXT behind the scenes, it would return function, which violates the spec. It seems like the right way to do this is to actually have separate V8 items. The alternative is to have just a single WORKERCONTEXT, but instead of using polymorphism have custom getters/setters for every attribute that check the type of the impl class and do the appropriate thing. But it seems like the whole point of having the V8ClassIndex enum is to avoid this kind of manual polymorphism. -atw On Mon, Jul 20, 2009 at 8:22 PM, Jeremy Orlow jor...@chromium.org wrote: In other words, make all workers appear the same to V8 (i.e. as a WORKERCONTEXT) and then implement polymorphism in the implementations being wrapped by V8. On Mon, Jul 20, 2009 at 8:19 PM, Jeremy Orlow jor...@chromium.orgwrote: Sorry if this is a dumb question, but why woudn't you simply have a WORKERCONTEXT and let virtual dispatch do its job for the rest? Shared methods can be implemented on the base class and the rest can be purely virtual with implementations in the sub classes. J On Mon, Jul 20, 2009 at 3:21 PM, Drew Wilson atwil...@chromium.orgwrote: Following up on this. Let's imagine that I don't define a V8ClassIndex enum for the common base class (so, in my case, I get rid of WORKERCONTEXT, and have only DEDICATEDWORKERCONTEXT and SHAREDWORKERCONTEXT (the derived classes). Now, let's say I'm defining an ACCESSOR_GETTER on the base class - the first thing I want to do is get a pointer to the native object. I don't know which concrete class the native object is (DedicatedWorkerContext or SharedWorkerContext), but I do know that it's guaranteed to be an instance of the base native class (WorkerContext). Currently I'm doing this: WorkerContext* workerContext = V8DOMWrapper::convertToNativeObjectWorkerContext(V8ClassIndex::WORKERCONTEXT, info.Holder()); If I remove V8ClassIndex::WORKERCONTEXT, then I can't pass that in to convertToNativeObject. It looks like the passed-in enum is only used for error checking currently, so I guess what I should use instead is convertDOMWrapperToNative()?: WorkerContext* workerContext = V8DOMWrapper::convertDOMWrapperToNativeWorkerContext(info.Holder()); Is that the general pattern people use for cases like this? -atw On Mon, Jul 20, 2009 at 3:21 PM, Drew Wilson atwil...@chromium.orgwrote: resending from correct acct: Currently, Web Workers have a class (WorkerContext) which represents the global scope for a worker. The custom V8 bindings for this class are defined in V8WorkerContextCustom, and we also define V8ClassIndex::WORKERCONTEXT for the wrapper object. I'm refactoring the WebCore impl class, so WorkerContext becomes (essentially) an abstract base class, and the actual worker context will be one of two derived classes: DedicatedWorkerContext or SharedWorkerContext. In my refactoring, I've only implemented a single derived class (DedicatedWorkerContext) for now. I'm trying to figure out the correct way to structure the V8 bindings - I've already made a pass at it that passes all of the unit tests: https://bugs.webkit.org/show_bug.cgi?id=27420 I've defined V8ClassIndex::DEDICATEDWORKERCONTEXT, but I'm not certain if I need to remove V8ClassIndex::WORKERCONTEXT or not, since there shouldn't ever be a wrapper object created for that base class. Are the wrapper types defined in V8Index.h only for actually instantiable wrapper objects (in which case I should only define them for the leaves of the tree), or is it used for other things like instanceof? -atw --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives,
[chromium-dev] Re: Question about V8 bindings
Yes, there's polymorphism in the IDL files. For example, the IDL for
DedicatedWorkerContext is:
interface [
bunch of random attributes
] DedicatedWorkerContext : WorkerContext {
void postMessage(in DOMString message, in [Optional] MessagePort
messagePort)
raises(DOMException);
attribute EventListener onmessage;
};
The JSC bindings reflect this nicely, because there's a class hierarchy in
JSC that matches the hierarchy in the IDL files.
-atw
On Tue, Jul 21, 2009 at 10:32 AM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Jul 21, 2009 at 10:19 AM, Drew Wilson atwil...@google.com wrote:
It seems like that would have some undesirable side-effects, aside from
the fact that WebKit frowns on using virtual functions unnecessarily.
So, let's imagine that I have two derived classes, SharedWorkerContext and
DedicatedWorkerContext. DedicatedWorkerContext wants to expose postMessage()
as a public callable function, but SharedWorkerContext would not.
If we only have a single V8 class for both of these (WORKERCONTEXT) then
that implies:
1) I have to define postMessage() as a virtual function on the base
WebCore class (WorkerContext). In fact, WorkerContext ends up containing the
union of all exposed APIs for every future derived class, which seems ugly.
2) From javascript, if I have a SharedWorkerContext, and I do this typeof
postMessage, it should return undefined (since SharedWorkerContext does
not define this attribute) - however, since SharedWorkerContext is actually
just a vanilla WORKERCONTEXT behind the scenes, it would return function,
which violates the spec.
It seems like the right way to do this is to actually have separate V8
items. The alternative is to have just a single WORKERCONTEXT, but instead
of using polymorphism have custom getters/setters for every attribute that
check the type of the impl class and do the appropriate thing. But it seems
like the whole point of having the V8ClassIndex enum is to avoid this kind
of manual polymorphism.
Good points.
Are there other use cases for building polymorphism into V8? Is there any
notion of polymorphism in the IDL files? Maybe the best answer is to just
make them two completely different classes. It kind of seems like doing
this elegantly is going to cost us performance wise one way or another.
J
On Mon, Jul 20, 2009 at 8:22 PM, Jeremy Orlow jor...@chromium.org wrote:
In other words, make all workers appear the same to V8 (i.e. as a
WORKERCONTEXT) and then implement polymorphism in the implementations being
wrapped by V8.
On Mon, Jul 20, 2009 at 8:19 PM, Jeremy Orlow jor...@chromium.orgwrote:
Sorry if this is a dumb question, but why woudn't you simply have a
WORKERCONTEXT and let virtual dispatch do its job for the rest? Shared
methods can be implemented on the base class and the rest can be purely
virtual with implementations in the sub classes.
J
On Mon, Jul 20, 2009 at 3:21 PM, Drew Wilson atwil...@chromium.orgwrote:
Following up on this. Let's imagine that I don't define a V8ClassIndex
enum for the common base class (so, in my case, I get rid of
WORKERCONTEXT,
and have only DEDICATEDWORKERCONTEXT and SHAREDWORKERCONTEXT (the derived
classes).
Now, let's say I'm defining an ACCESSOR_GETTER on the base class - the
first thing I want to do is get a pointer to the native object. I don't
know
which concrete class the native object is (DedicatedWorkerContext or
SharedWorkerContext), but I do know that it's guaranteed to be an instance
of the base native class (WorkerContext).
Currently I'm doing this:
WorkerContext* workerContext =
V8DOMWrapper::convertToNativeObjectWorkerContext(V8ClassIndex::WORKERCONTEXT,
info.Holder());
If I remove V8ClassIndex::WORKERCONTEXT, then I can't pass that in to
convertToNativeObject. It looks like the passed-in enum is only used for
error checking currently, so I guess what I should use instead is
convertDOMWrapperToNative()?:
WorkerContext* workerContext =
V8DOMWrapper::convertDOMWrapperToNativeWorkerContext(info.Holder());
Is that the general pattern people use for cases like this?
-atw
On Mon, Jul 20, 2009 at 3:21 PM, Drew Wilson atwil...@chromium.orgwrote:
resending from correct acct:
Currently, Web Workers have a class (WorkerContext) which represents
the global scope for a worker. The custom V8 bindings for this class are
defined in V8WorkerContextCustom, and we also define
V8ClassIndex::WORKERCONTEXT for the wrapper object.
I'm refactoring the WebCore impl class, so WorkerContext becomes
(essentially) an abstract base class, and the actual worker context will
be
one of two derived classes: DedicatedWorkerContext or
SharedWorkerContext.
In my refactoring, I've only implemented a single derived class
(DedicatedWorkerContext) for now.
I'm trying to figure out the correct way to structure the V8 bindings
- I've already made a pass at it that
[chromium-dev] Re: Question about V8 bindings
I think the way this works in general is that you create the wrapper for the derived class. You can see all the switch statements in V8DOMWrapper.cpp that try to do this for Nodes, etc. Adam On Tue, Jul 21, 2009 at 10:32 AM, Jeremy Orlowjor...@chromium.org wrote: On Tue, Jul 21, 2009 at 10:19 AM, Drew Wilson atwil...@google.com wrote: It seems like that would have some undesirable side-effects, aside from the fact that WebKit frowns on using virtual functions unnecessarily. So, let's imagine that I have two derived classes, SharedWorkerContext and DedicatedWorkerContext. DedicatedWorkerContext wants to expose postMessage() as a public callable function, but SharedWorkerContext would not. If we only have a single V8 class for both of these (WORKERCONTEXT) then that implies: 1) I have to define postMessage() as a virtual function on the base WebCore class (WorkerContext). In fact, WorkerContext ends up containing the union of all exposed APIs for every future derived class, which seems ugly. 2) From javascript, if I have a SharedWorkerContext, and I do this typeof postMessage, it should return undefined (since SharedWorkerContext does not define this attribute) - however, since SharedWorkerContext is actually just a vanilla WORKERCONTEXT behind the scenes, it would return function, which violates the spec. It seems like the right way to do this is to actually have separate V8 items. The alternative is to have just a single WORKERCONTEXT, but instead of using polymorphism have custom getters/setters for every attribute that check the type of the impl class and do the appropriate thing. But it seems like the whole point of having the V8ClassIndex enum is to avoid this kind of manual polymorphism. Good points. Are there other use cases for building polymorphism into V8? Is there any notion of polymorphism in the IDL files? Maybe the best answer is to just make them two completely different classes. It kind of seems like doing this elegantly is going to cost us performance wise one way or another. J On Mon, Jul 20, 2009 at 8:22 PM, Jeremy Orlow jor...@chromium.org wrote: In other words, make all workers appear the same to V8 (i.e. as a WORKERCONTEXT) and then implement polymorphism in the implementations being wrapped by V8. On Mon, Jul 20, 2009 at 8:19 PM, Jeremy Orlow jor...@chromium.org wrote: Sorry if this is a dumb question, but why woudn't you simply have a WORKERCONTEXT and let virtual dispatch do its job for the rest? Shared methods can be implemented on the base class and the rest can be purely virtual with implementations in the sub classes. J On Mon, Jul 20, 2009 at 3:21 PM, Drew Wilson atwil...@chromium.org wrote: Following up on this. Let's imagine that I don't define a V8ClassIndex enum for the common base class (so, in my case, I get rid of WORKERCONTEXT, and have only DEDICATEDWORKERCONTEXT and SHAREDWORKERCONTEXT (the derived classes). Now, let's say I'm defining an ACCESSOR_GETTER on the base class - the first thing I want to do is get a pointer to the native object. I don't know which concrete class the native object is (DedicatedWorkerContext or SharedWorkerContext), but I do know that it's guaranteed to be an instance of the base native class (WorkerContext). Currently I'm doing this: WorkerContext* workerContext = V8DOMWrapper::convertToNativeObjectWorkerContext(V8ClassIndex::WORKERCONTEXT, info.Holder()); If I remove V8ClassIndex::WORKERCONTEXT, then I can't pass that in to convertToNativeObject. It looks like the passed-in enum is only used for error checking currently, so I guess what I should use instead is convertDOMWrapperToNative()?: WorkerContext* workerContext = V8DOMWrapper::convertDOMWrapperToNativeWorkerContext(info.Holder()); Is that the general pattern people use for cases like this? -atw On Mon, Jul 20, 2009 at 3:21 PM, Drew Wilson atwil...@chromium.org wrote: resending from correct acct: Currently, Web Workers have a class (WorkerContext) which represents the global scope for a worker. The custom V8 bindings for this class are defined in V8WorkerContextCustom, and we also define V8ClassIndex::WORKERCONTEXT for the wrapper object. I'm refactoring the WebCore impl class, so WorkerContext becomes (essentially) an abstract base class, and the actual worker context will be one of two derived classes: DedicatedWorkerContext or SharedWorkerContext. In my refactoring, I've only implemented a single derived class (DedicatedWorkerContext) for now. I'm trying to figure out the correct way to structure the V8 bindings - I've already made a pass at it that passes all of the unit tests: https://bugs.webkit.org/show_bug.cgi?id=27420 I've defined V8ClassIndex::DEDICATEDWORKERCONTEXT, but I'm not certain if I need to remove V8ClassIndex::WORKERCONTEXT or not, since there shouldn't ever be a wrapper object created for that base class. Are the wrapper types defined in V8Index.h only
[chromium-dev] Re: Question about V8 bindings
The other unanswered question is whether it's useful to define the base type in V8Index.h. If a wrapper of the base type (WRAPPERCONTEXT) is never instantiated, do I still need to define it for the purposes of things like instanceof and prototype chains? Or is it *only* used to specify the type of wrapper instances? -atw On Tue, Jul 21, 2009 at 10:58 AM, Adam Barth aba...@chromium.org wrote: I think the way this works in general is that you create the wrapper for the derived class. You can see all the switch statements in V8DOMWrapper.cpp that try to do this for Nodes, etc. Adam On Tue, Jul 21, 2009 at 10:32 AM, Jeremy Orlowjor...@chromium.org wrote: On Tue, Jul 21, 2009 at 10:19 AM, Drew Wilson atwil...@google.com wrote: It seems like that would have some undesirable side-effects, aside from the fact that WebKit frowns on using virtual functions unnecessarily. So, let's imagine that I have two derived classes, SharedWorkerContext and DedicatedWorkerContext. DedicatedWorkerContext wants to expose postMessage() as a public callable function, but SharedWorkerContext would not. If we only have a single V8 class for both of these (WORKERCONTEXT) then that implies: 1) I have to define postMessage() as a virtual function on the base WebCore class (WorkerContext). In fact, WorkerContext ends up containing the union of all exposed APIs for every future derived class, which seems ugly. 2) From javascript, if I have a SharedWorkerContext, and I do this typeof postMessage, it should return undefined (since SharedWorkerContext does not define this attribute) - however, since SharedWorkerContext is actually just a vanilla WORKERCONTEXT behind the scenes, it would return function, which violates the spec. It seems like the right way to do this is to actually have separate V8 items. The alternative is to have just a single WORKERCONTEXT, but instead of using polymorphism have custom getters/setters for every attribute that check the type of the impl class and do the appropriate thing. But it seems like the whole point of having the V8ClassIndex enum is to avoid this kind of manual polymorphism. Good points. Are there other use cases for building polymorphism into V8? Is there any notion of polymorphism in the IDL files? Maybe the best answer is to just make them two completely different classes. It kind of seems like doing this elegantly is going to cost us performance wise one way or another. J On Mon, Jul 20, 2009 at 8:22 PM, Jeremy Orlow jor...@chromium.org wrote: In other words, make all workers appear the same to V8 (i.e. as a WORKERCONTEXT) and then implement polymorphism in the implementations being wrapped by V8. On Mon, Jul 20, 2009 at 8:19 PM, Jeremy Orlow jor...@chromium.org wrote: Sorry if this is a dumb question, but why woudn't you simply have a WORKERCONTEXT and let virtual dispatch do its job for the rest? Shared methods can be implemented on the base class and the rest can be purely virtual with implementations in the sub classes. J On Mon, Jul 20, 2009 at 3:21 PM, Drew Wilson atwil...@chromium.org wrote: Following up on this. Let's imagine that I don't define a V8ClassIndex enum for the common base class (so, in my case, I get rid of WORKERCONTEXT, and have only DEDICATEDWORKERCONTEXT and SHAREDWORKERCONTEXT (the derived classes). Now, let's say I'm defining an ACCESSOR_GETTER on the base class - the first thing I want to do is get a pointer to the native object. I don't know which concrete class the native object is (DedicatedWorkerContext or SharedWorkerContext), but I do know that it's guaranteed to be an instance of the base native class (WorkerContext). Currently I'm doing this: WorkerContext* workerContext = V8DOMWrapper::convertToNativeObjectWorkerContext(V8ClassIndex::WORKERCONTEXT, info.Holder()); If I remove V8ClassIndex::WORKERCONTEXT, then I can't pass that in to convertToNativeObject. It looks like the passed-in enum is only used for error checking currently, so I guess what I should use instead is convertDOMWrapperToNative()?: WorkerContext* workerContext = V8DOMWrapper::convertDOMWrapperToNativeWorkerContext(info.Holder()); Is that the general pattern people use for cases like this? -atw On Mon, Jul 20, 2009 at 3:21 PM, Drew Wilson atwil...@chromium.org wrote: resending from correct acct: Currently, Web Workers have a class (WorkerContext) which represents the global scope for a worker. The custom V8 bindings for this class are defined in V8WorkerContextCustom, and we also define V8ClassIndex::WORKERCONTEXT for the wrapper object. I'm refactoring the WebCore impl class, so WorkerContext becomes (essentially) an abstract base class, and the actual worker context will be one of two derived classes: DedicatedWorkerContext or SharedWorkerContext. In my refactoring, I've only
[chromium-dev] Re: No more buildbot auto-refresh - Update your bookmark!
Nicolas, Are you going to be turning back on the extension support at any point? If not, just let us know so that we can remove the feature from the sample. Right now it looks broken. - a On Tue, Jul 21, 2009 at 8:27 AM, Nicolas Sylvainnsylv...@chromium.org wrote: Hi, Last week a lot of people on this list said that they like the idea of disabling the auto-reload for our buildbot waterfall and console view. This is now implemented. If you do want to keep the page auto-refreshing, please update your bookmark. just add the query parameter reload=X, where X is the number of second to wait between each reloads. X used to be 90. Depending on your needs, you can increase or decrease this number. Examples: console view: http://build.chromium.org/buildbot/waterfall/console?reload=180 waterfall : http://build.chromium.org/buildbot/waterfall/waterfall?reload=180 For sheriffs: http://build.chromium.org/buildbot/waterfall/waterfall?failures=1reload=30 Thanks 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: No more buildbot auto-refresh - Update your bookmark!
On Tue, Jul 21, 2009 at 11:37 AM, Aaron Boodman a...@chromium.org wrote: Nicolas, Are you going to be turning back on the extension support at any point? If not, just let us know so that we can remove the feature from the sample. Right now it looks broken. Is the reload in the extension still 30secs? If it can be changed to 2 or 5 minutes I will reenable it. Nicolas - a On Tue, Jul 21, 2009 at 8:27 AM, Nicolas Sylvainnsylv...@chromium.org wrote: Hi, Last week a lot of people on this list said that they like the idea of disabling the auto-reload for our buildbot waterfall and console view. This is now implemented. If you do want to keep the page auto-refreshing, please update your bookmark. just add the query parameter reload=X, where X is the number of second to wait between each reloads. X used to be 90. Depending on your needs, you can increase or decrease this number. Examples: console view: http://build.chromium.org/buildbot/waterfall/console?reload=180 waterfall : http://build.chromium.org/buildbot/waterfall/waterfall?reload=180 For sheriffs: http://build.chromium.org/buildbot/waterfall/waterfall?failures=1reload=30 Thanks 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: Please keep TOOLKIT_VIEWS green!
What brett said. When the infrastructure is available to easily configure an on-demand one, go ahead and do it then. -Ben On Tue, Jul 21, 2009 at 3:56 PM, Brett Wilsonbre...@chromium.org wrote: On Tue, Jul 21, 2009 at 8:42 AM, Nicolas Sylvainnsylv...@chromium.org wrote: On Tue, Jul 21, 2009 at 8:31 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Can we have a trybot with that configuration, which would just compile the code? I think it would really save people's time. I never build with TOOLKIT_VIEWS, and in case of breakage I would have to immediately revert and then investigate. If I got a trybot failure, I would know much more before committing. Ben: How likely is this to break? I'm reluctant to add yet another try bot because they do take a lot of resources. There are maybe 200-300 try changes sent every day. That means we need enough resources to build this configuration that many times, and it needs to answer fast enough. I don't think an automatically-running trybot is very critical for this build at the moment. Most of the things that break it are pretty simple (need to add a file to GYP, or maybe a stub for something) so the breakage won't be super complicated. Most errors will be caught by the regular trybots. Brett --~--~-~--~~~---~--~~ 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: Mozilla design challenge
Is it possible to provide an intuitive UI that allows users to choose which tabs to be suspended?For example, just like users can click buttons on taskbar to pop up a particular window, we could provide a small window that pop-in tabs / windows. And then we can suspend all windows / tab that are popped into. Ryosuke On Tue, Jul 21, 2009 at 9:32 AM, Erik Kay erik...@chromium.org wrote: You may be on to something, but I think it's more complex than this. For example bookmark systems don't work because people use them for a number of conflicting purposes (my list of things to read every day, a simple history system, a 'to read' list, a collection of links for research), which have different UI requirements. I think the same thing has happened with tabs (and there's a surprising amount of overlap). Here are the use cases I know I wind up using: - a few long running apps that need to keep running, potentially notifying me of new events (calendar, mail, chat, buildbot, etc.) - a few pages that I'm currently actively using (a screenshot from a bug I'm looking at, some reference documentation, a writely page I'm editing between compiles, etc.) - a to read list of pages that I started reading but didn't finish yet (sometimes this is a collection of related pages when researching something) - I'm sure there are others. In my use case, 80% of my tabs could easily be killed / suspended (or even hidden altogether) without any downside to me. The problem is that there isn't a way to automatically figure out which ones are which. Which ones have pending state that might be lost? (yes, some of this is bad app design, but there are many like this) Which ones do I expect to keep running all of the time because of notifications? What about that flash game that I left running in the background? Maybe we could come up with some heuristics that could detect some of this automatically, but I worry that there will be so many exceptions that it won't work. That means we'd need to come up with a better UI to express these concepts where the user chose to treat tabs differently in some explicit way. There are a number of extensions that try to do this for some specific use cases (to read lists, pinned tabs, etc.). I'm not sure that these are better than bandaids though. Erik On Tue, Jul 21, 2009 at 8:28 AM, Dean McNamee de...@chromium.org wrote: I feel like people are using tabs as a replacement for a good history system. At least in all current browser implementations, tabs are running. Even if we can make the UI scale to 1000 tabs, the 500 flash instances that are likely running aren't really going to perform. The making tab performance scale is a separate technical issue that will hopefully also improve. Looking at a lot of these design videos, they looked more like good ideas to me for history navigation than tab navigation. If history was good, I think people wouldn't be so worried about losing something by closing a tab. Having had bad history systems for so many years, people are now trained to keep tabs open if they ever might want to look at that page again in the future :\ On Sat, Jul 18, 2009 at 1:16 AM, Peter Kastingpkast...@google.com wrote: http://design-challenge.mozilla.com/summer09/ The results of the Reinventing Tabs in the Browser challenge have been announced. Collapsible Tab Groups includes among others some things I've proposed, including grouping and collapsing groups. Favitabs reminds me of some old brainstorming ideas from pamg about converting certain tabs into favicon buttons. Folks considering the future of tabs (e.g. Ben, Glen, Scott) might do well to take a look at some of these. 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: Mozilla design challenge
I don't think it's reasonable to require the user to specify which tabs to suspend, except, perhaps, if we develop a metric for power-hungry tabs and expose that. I think there is some potential for UI geared towards particular use-cases which could be overloaded to also allow more aggressive suspend. For instance, WRT my earlier posting, I would expect my pinned tabs to be given stronger priority, and my on-deck-to-read tabs to be treated more like preloaded/rendered bookmarks. There could be other UI advantages in there, like the on-deck tabs for a particular project could group under a single tab with other UI widgets to select which document within the group. -scott On Tue, Jul 21, 2009 at 1:50 PM, Ryosuke Niwarn...@google.com wrote: Is it possible to provide an intuitive UI that allows users to choose which tabs to be suspended? For example, just like users can click buttons on taskbar to pop up a particular window, we could provide a small window that pop-in tabs / windows. And then we can suspend all windows / tab that are popped into. Ryosuke On Tue, Jul 21, 2009 at 9:32 AM, Erik Kay erik...@chromium.org wrote: You may be on to something, but I think it's more complex than this. For example bookmark systems don't work because people use them for a number of conflicting purposes (my list of things to read every day, a simple history system, a 'to read' list, a collection of links for research), which have different UI requirements. I think the same thing has happened with tabs (and there's a surprising amount of overlap). Here are the use cases I know I wind up using: - a few long running apps that need to keep running, potentially notifying me of new events (calendar, mail, chat, buildbot, etc.) - a few pages that I'm currently actively using (a screenshot from a bug I'm looking at, some reference documentation, a writely page I'm editing between compiles, etc.) - a to read list of pages that I started reading but didn't finish yet (sometimes this is a collection of related pages when researching something) - I'm sure there are others. In my use case, 80% of my tabs could easily be killed / suspended (or even hidden altogether) without any downside to me. The problem is that there isn't a way to automatically figure out which ones are which. Which ones have pending state that might be lost? (yes, some of this is bad app design, but there are many like this) Which ones do I expect to keep running all of the time because of notifications? What about that flash game that I left running in the background? Maybe we could come up with some heuristics that could detect some of this automatically, but I worry that there will be so many exceptions that it won't work. That means we'd need to come up with a better UI to express these concepts where the user chose to treat tabs differently in some explicit way. There are a number of extensions that try to do this for some specific use cases (to read lists, pinned tabs, etc.). I'm not sure that these are better than bandaids though. Erik On Tue, Jul 21, 2009 at 8:28 AM, Dean McNamee de...@chromium.org wrote: I feel like people are using tabs as a replacement for a good history system. At least in all current browser implementations, tabs are running. Even if we can make the UI scale to 1000 tabs, the 500 flash instances that are likely running aren't really going to perform. The making tab performance scale is a separate technical issue that will hopefully also improve. Looking at a lot of these design videos, they looked more like good ideas to me for history navigation than tab navigation. If history was good, I think people wouldn't be so worried about losing something by closing a tab. Having had bad history systems for so many years, people are now trained to keep tabs open if they ever might want to look at that page again in the future :\ On Sat, Jul 18, 2009 at 1:16 AM, Peter Kastingpkast...@google.com wrote: http://design-challenge.mozilla.com/summer09/ The results of the Reinventing Tabs in the Browser challenge have been announced. Collapsible Tab Groups includes among others some things I've proposed, including grouping and collapsing groups. Favitabs reminds me of some old brainstorming ideas from pamg about converting certain tabs into favicon buttons. Folks considering the future of tabs (e.g. Ben, Glen, Scott) might do well to take a look at some of these. 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: Hacking on WebKit is easier than ever
On Wed, Jul 15, 2009 at 12:39 PM, Adam Barth aba...@chromium.org wrote: Thanks to some recent work by Dimitri, Victor, and others, hacking on WebKit is now easier than ever. If you work on WebKit and Chromium, I recommend using a hybrid source tree: http://dev.chromium.org/developers/contributing-to-webkit With the patches I have landed, combined with the four patches awaiting review on https://bugs.webkit.org/show_bug.cgi?id=27323 , I have been able to successfully check out WebKit inside Chromium using the depot_tools (not Cygwin) SVN; update it; prepare, create, apply, unapply, and submit patches; and build WebKit cleanly and run Safari with it. Therefore, once those four patches land (might be a little while, one may cause problems for Apple folks), I claim that this setup is finally ready for Windows developers to use. There are still a few rough edges (creating patches to files that don't have svn:eol-style set may result in patches that don't apply/unapply cleanly, due to an apparent SVN bug; I haven't tested all the scripts [e.g. bugzilla-tool], just the ones I use), but by and large things work. 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: Hacking on WebKit is easier than ever
On Tue, Jul 21, 2009 at 3:35 PM, Peter Kasting pkast...@chromium.orgwrote: On Wed, Jul 15, 2009 at 12:39 PM, Adam Barth aba...@chromium.org wrote: Thanks to some recent work by Dimitri, Victor, and others, hacking on WebKit is now easier than ever. If you work on WebKit and Chromium, I recommend using a hybrid source tree: http://dev.chromium.org/developers/contributing-to-webkit With the patches I have landed, combined with the four patches awaiting review on https://bugs.webkit.org/show_bug.cgi?id=27323 , I have been able to successfully check out WebKit inside Chromium using the depot_tools (not Cygwin) SVN; update it; prepare, create, apply, unapply, and submit patches; and build WebKit cleanly and run Safari with it. Nice! Thanks a lot Peter! Therefore, once those four patches land (might be a little while, one may cause problems for Apple folks), I claim that this setup is finally ready for Windows developers to use. There are still a few rough edges (creating patches to files that don't have svn:eol-style set may result in patches that don't apply/unapply cleanly, due to an apparent SVN bug; I haven't tested all the scripts [e.g. bugzilla-tool], just the ones I use), but by and large things work. Would it be safe for the script to just automatically apply that flag on any file it's touching? --~--~-~--~~~---~--~~ 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: Hacking on WebKit is easier than ever
On Tue, Jul 21, 2009 at 3:35 PM, Peter Kasting pkast...@chromium.orgwrote: On Wed, Jul 15, 2009 at 12:39 PM, Adam Barth aba...@chromium.org wrote: Thanks to some recent work by Dimitri, Victor, and others, hacking on WebKit is now easier than ever. If you work on WebKit and Chromium, I recommend using a hybrid source tree: http://dev.chromium.org/developers/contributing-to-webkit With the patches I have landed, combined with the four patches awaiting review on https://bugs.webkit.org/show_bug.cgi?id=27323 , I have been able to successfully check out WebKit inside Chromium using the depot_tools (not Cygwin) SVN; update it; prepare, create, apply, unapply, and submit patches; and build WebKit cleanly and run Safari with it. Therefore, once those four patches land (might be a little while, one may cause problems for Apple folks), I claim that this setup is finally ready for Windows developers to use. There are still a few rough edges (creating patches to files that don't have svn:eol-style set may result in patches that don't apply/unapply cleanly, due to an apparent SVN bug; I haven't tested all the scripts [e.g. bugzilla-tool], just the ones I use), but by and large things work. PK This is awesome news! Thanks Peter :-) -Darin --~--~-~--~~~---~--~~ 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: Hacking on WebKit is easier than ever
On Tue, Jul 21, 2009 at 3:40 PM, Jeremy Orlow jor...@google.com wrote: Therefore, once those four patches land (might be a little while, one may cause problems for Apple folks), I claim that this setup is finally ready for Windows developers to use. There are still a few rough edges (creating patches to files that don't have svn:eol-style set may result in patches that don't apply/unapply cleanly, due to an apparent SVN bug; I haven't tested all the scripts [e.g. bugzilla-tool], just the ones I use), but by and large things work. Would it be safe for the script to just automatically apply that flag on any file it's touching? Which script? Which flag? It would be nice if every file in the WK repo had svn:eol-style set to an appropriate value. We have this in Chromium, and enforce it with a commit hook (and make life easier on developers by listing some auto-props for them to use). According to eseidel, darin (that's Darin Adler) used to keep eol-style set on most things in WebKit, but stopped some time ago. So if you look in the tree, a large number of files have this, but another large number don't. Changing WebKit to work like Chromium in this regard would require four things: (1) Agreement that this is valuable to WebKit (e.g. because it makes Windows hacking much saner) (2) Someone to run scripts over the tree to correct all existing files, as pamg (?) did for Chromium. (3) A commit hook to ensure things don't regress. (4) Clear instructions for developers about how to set up SVN to apply the right eol-style automatically, so people don't have to do it manually. I don't have the ability to do any of those, except for maybe trying for the first one. And there I think I might rather not push my luck right now :) 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: Hacking on WebKit is easier than ever
On Tue, Jul 21, 2009 at 3:56 PM, Jeremy Orlow jor...@google.com wrote: I was suggesting that any scripts that depend on the eol style could set the flag on any files it's touching. For example, svn-create-patch could set it on all the files that have been modified. This could even be done only when running on Windows not under cygwin to minimize compatibility issues. But, given that so many of the files already have the flag set, it's probably OK to do, right? This isn't really a feasible solution. Among other things, the rules for what eol-style goes on what file can be complex, it may not be possible to set this property without first modifying the file's line endings, this would add runtime penalties and code complexity to a number of scripts, and users would be surprised to have some of these scripts causing further modifications to their checkout. I have sent a message to webkit-dev regarding eol-style, mentioning how we handle it for Chromium, which is pretty much the way things would have to work if we wanted to address this issue. 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: Mozilla design challenge
On Tue, Jul 21, 2009 at 8:28 AM, Dean McNameede...@chromium.org wrote: I feel like people are using tabs as a replacement for a good history system. At least in all current browser implementations, tabs are running. Even if we can make the UI scale to 1000 tabs, the 500 flash instances that are likely running aren't really going to perform. The making tab performance scale is a separate technical issue that will hopefully also improve. Guess we should continue to remove more and more reasons for people to build things in Flash, then = ) Looking at a lot of these design videos, they looked more like good ideas to me for history navigation than tab navigation. If history was good, I think people wouldn't be so worried about losing something by closing a tab. Having had bad history systems for so many years, people are now trained to keep tabs open if they ever might want to look at that page again in the future :\ On Sat, Jul 18, 2009 at 1:16 AM, Peter Kastingpkast...@google.com wrote: http://design-challenge.mozilla.com/summer09/ The results of the Reinventing Tabs in the Browser challenge have been announced. Collapsible Tab Groups includes among others some things I've proposed, including grouping and collapsing groups. Favitabs reminds me of some old brainstorming ideas from pamg about converting certain tabs into favicon buttons. Folks considering the future of tabs (e.g. Ben, Glen, Scott) might do well to take a look at some of these. 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] Proposal for adding ChangeLog files to Chromium
In order to make it easier for the community to see the changes are going on inside Chromium I'd like to propose that we add one or more ChangeLog files into our code base. The proposed usage would go something like this: - When a developer completes a visible or notable change, they'd add an entry to the ChangeLog along with their commit. - The entry would have the date, author, a plain English description (suitable for release notes) of the change, along with a reference to any related bugs. - Example: 2009-07-21 [lafo...@chromium.org]: Creating a patch to make change tracking easier (Bugs:12345,67890) *Immediate Benefits:* - Assuming that changes were checked in with the code they were mapped to, ChangeLogs would stay up to date even through reverts and branch merges. - It would be very easy, given a range of revisions to see what precisely changed in Chromium. Overall, I think this would make it much simpler to view the team's progress and help us improve our overall level of transparency. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ 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: Proposal for adding ChangeLog files to Chromium
On Tue, Jul 21, 2009 at 9:37 PM, Anthony LaForge lafo...@google.com wrote: In order to make it easier for the community to see the changes are going on inside Chromium I'd like to propose that we add one or more ChangeLog files into our code base. The proposed usage would go something like this: - When a developer completes a visible or notable change, they'd add an entry to the ChangeLog along with their commit. - The entry would have the date, author, a plain English description (suitable for release notes) of the change, along with a reference to any related bugs. - Example: 2009-07-21 [lafo...@chromium.org]: Creating a patch to make change tracking easier (Bugs:12345,67890) *Immediate Benefits:* - Assuming that changes were checked in with the code they were mapped to, ChangeLogs would stay up to date even through reverts and branch merges. - It would be very easy, given a range of revisions to see what precisely changed in Chromium. Overall, I think this would make it much simpler to view the team's progress and help us improve our overall level of transparency. I am very against adding ChangeLogs unless absolutely necessary. They're a major pain in WebKit development...enough so that there have been pushes to get rid of them there. It's nice that you're only asking for major changes to be added to the ChangeLog, but I still think it's going to add a lot of overhead. ChangeLogs mean that you can only have one (change-log-worthy) change per client at a time. They also mean that every time you sync your client, you're going to have to resolve conflicts. WebKit has a script to do this for you, but it's still a pain. I don't understand why the svn commit logs aren't enough for our purposes here. Especially if we use the RELEASE_NOTE annotation Aaron suggested. Does this information not get carried forward with branches? Could we create a script that automatically generates ChangeLogs based on the svn commit logs if not? 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: Proposal for adding ChangeLog files to Chromium
On Tue, Jul 21, 2009 at 9:37 PM, Anthony LaForgelafo...@google.com wrote: In order to make it easier for the community to see the changes are going on inside Chromium I'd like to propose that we add one or more ChangeLog files into our code base. The proposed usage would go something like this: I'm not saying anything that Jeremy and Adam haven't already said, just reinforcing their point in case there's any question. What you want is `git log | grep RELEASE_NOTE` 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: Question about V8 bindings
If you don't need the base 'type' in the binding layer code, you don't have to specify it in the V8Index file. Prototype chains and instanceof operations are all handled by V8 based on the code generated from the IDL files and it is independent of the 'type' declarations in the V8Index file. Cheers,-- Mads On Tue, Jul 21, 2009 at 6:13 PM, Drew Wilsonatwil...@chromium.org wrote: The other unanswered question is whether it's useful to define the base type in V8Index.h. If a wrapper of the base type (WRAPPERCONTEXT) is never instantiated, do I still need to define it for the purposes of things like instanceof and prototype chains? Or is it *only* used to specify the type of wrapper instances? -atw On Tue, Jul 21, 2009 at 10:58 AM, Adam Barth aba...@chromium.org wrote: I think the way this works in general is that you create the wrapper for the derived class. You can see all the switch statements in V8DOMWrapper.cpp that try to do this for Nodes, etc. Adam On Tue, Jul 21, 2009 at 10:32 AM, Jeremy Orlowjor...@chromium.org wrote: On Tue, Jul 21, 2009 at 10:19 AM, Drew Wilson atwil...@google.com wrote: It seems like that would have some undesirable side-effects, aside from the fact that WebKit frowns on using virtual functions unnecessarily. So, let's imagine that I have two derived classes, SharedWorkerContext and DedicatedWorkerContext. DedicatedWorkerContext wants to expose postMessage() as a public callable function, but SharedWorkerContext would not. If we only have a single V8 class for both of these (WORKERCONTEXT) then that implies: 1) I have to define postMessage() as a virtual function on the base WebCore class (WorkerContext). In fact, WorkerContext ends up containing the union of all exposed APIs for every future derived class, which seems ugly. 2) From javascript, if I have a SharedWorkerContext, and I do this typeof postMessage, it should return undefined (since SharedWorkerContext does not define this attribute) - however, since SharedWorkerContext is actually just a vanilla WORKERCONTEXT behind the scenes, it would return function, which violates the spec. It seems like the right way to do this is to actually have separate V8 items. The alternative is to have just a single WORKERCONTEXT, but instead of using polymorphism have custom getters/setters for every attribute that check the type of the impl class and do the appropriate thing. But it seems like the whole point of having the V8ClassIndex enum is to avoid this kind of manual polymorphism. Good points. Are there other use cases for building polymorphism into V8? Is there any notion of polymorphism in the IDL files? Maybe the best answer is to just make them two completely different classes. It kind of seems like doing this elegantly is going to cost us performance wise one way or another. J On Mon, Jul 20, 2009 at 8:22 PM, Jeremy Orlow jor...@chromium.org wrote: In other words, make all workers appear the same to V8 (i.e. as a WORKERCONTEXT) and then implement polymorphism in the implementations being wrapped by V8. On Mon, Jul 20, 2009 at 8:19 PM, Jeremy Orlow jor...@chromium.org wrote: Sorry if this is a dumb question, but why woudn't you simply have a WORKERCONTEXT and let virtual dispatch do its job for the rest? Shared methods can be implemented on the base class and the rest can be purely virtual with implementations in the sub classes. J On Mon, Jul 20, 2009 at 3:21 PM, Drew Wilson atwil...@chromium.org wrote: Following up on this. Let's imagine that I don't define a V8ClassIndex enum for the common base class (so, in my case, I get rid of WORKERCONTEXT, and have only DEDICATEDWORKERCONTEXT and SHAREDWORKERCONTEXT (the derived classes). Now, let's say I'm defining an ACCESSOR_GETTER on the base class - the first thing I want to do is get a pointer to the native object. I don't know which concrete class the native object is (DedicatedWorkerContext or SharedWorkerContext), but I do know that it's guaranteed to be an instance of the base native class (WorkerContext). Currently I'm doing this: WorkerContext* workerContext = V8DOMWrapper::convertToNativeObjectWorkerContext(V8ClassIndex::WORKERCONTEXT, info.Holder()); If I remove V8ClassIndex::WORKERCONTEXT, then I can't pass that in to convertToNativeObject. It looks like the passed-in enum is only used for error checking currently, so I guess what I should use instead is convertDOMWrapperToNative()?: WorkerContext* workerContext = V8DOMWrapper::convertDOMWrapperToNativeWorkerContext(info.Holder()); Is that the general pattern people use for cases like this? -atw On Mon, Jul 20, 2009 at 3:21 PM, Drew Wilson atwil...@chromium.org wrote: resending from correct acct: Currently, Web Workers have a class (WorkerContext) which represents the global
