[chromium-dev] Re: A Dictionary-Evaluation Plan
Before launch, we asked a team of international Googlers to assess quality. We could reach out to that group again. Anders Sandholm coordinated that effort and would be a good person to reach out to if we want to repeat it. 2009/10/28 Hironori Bono (坊野 博典) hb...@chromium.org Hi Evan, Thank you for your feedback. 2009/10/28 Evan Martin e...@chromium.org: It still might be worth soliciting feedback from users directly. For example, if the new dictionary is missing a common word the above measure would get a high count of Add to Dictionary, and maybe users could tell us about this. Counting a common word is a good option for English. On the other hand, I'm wondering how much this idea works for case languages, such as Russian, Polish, etc. For example, a Russian noun has six cases (nominative, accusative, genitive, prepositional, and instrumental) and each noun changes its form according to the case and number. For example, a masculine noun стол (table) has six forms: стол, стол, стола, столу, столе, and столом. If a noun is countable, its plural form столы (tables) also has six forms: столы, столы, столов, столам, столах, столами. So, when we count each form as a separated dictionary word, the frequency count of a Russian word statistically (*1) becomes 1/6 of an English word. To write more about Russian, a Russian noun has three genders (masculine, feminine, and neutral) and each adjective has to change its form according to the gender and the case of a noun being qualified. That is, the frequency count of a Russian adjective statistically becomes 1/(3*6) = 1/18 of an English adjective. (This is a reason why our ru_RU.dic_delta file doesn't have adjectives.) If we can add an option menu so that a user can choose such grammatical information when the user adds a word, it definitely helps. (*1) In reality, some cases (nominative) are used more often than other cases. Regards, Hironori Bono E-mail: hb...@chromium.org --~--~-~--~~~---~--~~ 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: External protocol dialog checkbox
Seems like everyone agrees that Cancel should become Don't launch On Tue, Oct 20, 2009 at 1:07 PM, Mark Mentovai m...@chromium.org wrote: Evan Stade wrote: There's a checkbox in the external protocol dialog with the text Remember my choice for all links of this type. (On windows and linux, this is not actually implemented, but there are bugs out to fix that) The options are then Cancel and Launch Application. The conflict here is that in general Cancel is supposed to not do anything, hence it can't honor the Remember my choice for all links of this type option. So that checkbox should either be renamed Always allow this protocol, and not allow the user to always block that protocol, or the cancel button should be renamed to don't launch app or equivalent. I agree with this 100%. When Avi implemented this dialog on the Mac, I was really mean about it and I wouldn't let him make the remember checkbox actually remember anything as long as the button's text remained Cancel. The button label should change to Don't Launch or something along those lines. Leaving it at Cancel is ambiguous. Mark --~--~-~--~~~---~--~~ 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: detecting tabs using a lot of CPU?
I'm not convinced that we should bother users with this kind of stuff. If an advanced user want to see what's consuming resources, they can open the task manager. If we want this for debugging, perhaps it should live behind a flag. It would be cool if some kind combo of dev tools + extensions could allow developers to be notified of conditions like this. On Wed, Oct 7, 2009 at 10:35 AM, Evan Martin e...@chromium.org wrote: We had also discussed putting icons indicating audio into tabs. That sounds crowded with icons, though: imaginably a game could have facicon, Unicode symbols, CPU load, audio, and the x displayed. I worry there just aren't enough pixels to display all the relevant information. On Wed, Oct 7, 2009 at 10:10 AM, Glen Murphy g...@chromium.org wrote: Something like yes! Maybe not a dialog, as I use things that peg my CPU (games) somewhat frequently. One idea we toyed with was marking such tabs as 'on fire' (icon or color), so at least there was a visual indication. I think this would be a good starting point before anything more obtrusive like a dialog or bar. On Wed, Oct 7, 2009 at 9:59 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Just a while before one of my tabs (GMail) started using a lot of CPU time (67% while I was compiling in the background). The browser and the system were responsive at all times, but processing power was wasted. We have a warning dialog for hanged renderers offering to kill them. What do you think about a warning dialog for renderers consistently using a lot of CPU? --~--~-~--~~~---~--~~ 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: [DESIGN DOC] registerProtocolHandler HTML5 API
You should talk with the open web leads (darin, ifette, dglazkov, slightlyoff) for help on floating this out there. On Thu, Oct 1, 2009 at 1:12 PM, Nick Baum nickb...@chromium.org wrote: I've never done this, but I'm happy to learn. I got an intro to how to do it a few weeks back re:some extensions APIs. Where do I send the email? I'll send out a draft here beforehand. -Nick On Thu, Oct 1, 2009 at 2:41 PM, Brad Green (大面包) b...@google.com wrote: API: How does the page know it's registered? If Gmail notices you have Chrome and this isn't set, it might put a big promo on your inbox page. However, if it's already set, if would of course want to hide this. I understand your point now. It is something that should be brought up in whatwg and discussed. --~--~-~--~~~---~--~~ 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: [DESIGN DOC] registerProtocolHandler HTML5 API
I'm concerned that the page actions style Omnibox icon is not sufficient notification for users that this capability exists. I'll add this to the list of features for UI team to create mocks for. On Thu, Sep 24, 2009 at 12:51 PM, b...@chromium.org wrote: I've shared a document with you: [HTML5] registerProtocolHandler API http://docs.google.com/Doc?docid=0AVgZ1iILHLkdZGQ0bjd6cTVfMGdqZmpiNGZrhl=eninvite=CI6z8vgG It's not an attachment -- it's stored online at Google Docs. To open this document, just click the link above. This is a design document for the worked needed to resolve http://crbug.com/11359 beyond the webkit implementation. Please feel free to comment inline or in this thread. I look forward to your critics and suggestions. --~--~-~--~~~---~--~~ 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: [DESIGN DOC] registerProtocolHandler HTML5 API
In general, we've been operating under the assumption that a user-initiated gesture (click here to make gmail your mailto handler) results in a dialog. Non-user-initiated (site intitiated) results in an infobar. If you've denied the infobar this in the past, the site will have to get you to click on something in its UI to prompt you for this again. On Fri, Sep 25, 2009 at 12:14 PM, Peter Kasting pkast...@google.com wrote: On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow jor...@chromium.orgwrote: If you click no on an info bar, then how would you later change your mind? I don't know. Maybe at that point the icon appears in the address bar. 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: Why does Chromium on mac have a theme switch UI in the preferences?
Yes, I wholeheartedly agree that these are gallery features. We should remove them from options/prefs panels. On Mon, Aug 10, 2009 at 11:09 AM, Avi Drissman a...@google.com wrote: On Mon, Aug 10, 2009 at 1:31 PM, Aaron Boodman a...@chromium.org wrote: Incidentally, two other asks: * When installing a theme, give the user a way to switch back to the previous theme (e.g. an infobar). We currently have an option to switch back to the default theme, which is also useful, in different cases. We have a bug open on this. It requires some changes to the themes service. I think that Avi is working on this. I am? Please assign the bug, then, because I was unaware of it. Avi --~--~-~--~~~---~--~~ 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: Design Doc: Adaptive spell checking for multilingual users
I fear that this is treading into territory where the software is trying to be too smart. Most users will type in one language. Many users will type in two languages. Few users will type in more than two languages. A simpler design is simply to notice that the user seems to be multilingual and offer to expand spell check to the additional language(s). I'm concerned that frequent on-the-fly switches will result in incorrect flagging of misspelled words and will irritate users. -Brian On Mon, Jul 20, 2009 at 2:08 PM, Paul Wicks pwick...@gmail.com wrote: Another thing to consider is that something sort of like this is already supported by the OS X spellchecker through the Multilingual language setting. There is currently no way to switch to Multilingual in Chromium on OS X, but it wouldn't be that hard to enable that and it really is something that should be enabled if we want to support the native spelling correction panel on OS X (something which I have about 2/3's done), since the spelling panel shows Multilingual as a language option even if the context menu doesn't. I've done a little bit of experimenting and Multilingual seems to work pretty well in Chromium if you can enable it. One thing that might be a problem is that as far as I can tell, the Multilingual setting just checks all dictionaries for a word, so there could be problems there since a misspelling in the language being used might not be marked if it is a word in another language. I don't think I can say whether chromium is willing to accept Multilingual as the solution for this on OS X. If it is, then what you propose needs to be done in such a way that it doesn't touch the way OS X does this. If this is the solution for all platforms, OS X included, then we need to figure out a way around the spelling panel problem (no matter what, the spelling panel provided by NSSpellChecker will show Multilingual as an option). Whatever is decided, this definitely looks good for the other platforms. If this does go forward, I could probably help out, if you need a hand. -Paul Wicks On Mon, Jul 20, 2009 at 1:00 PM, sidchat sidc...@chromium.org wrote: A new feature to add to the SpellChecker would be its ability to adapt to the user's language of choice when typing in a text box. A design doc can be found at: http://sites.google.com/a/chromium.org/dev/developers/design-documents/advancedspellchecker It will be great if you could go over it and provide suggestions/ improvements, before I move ahead and start implementing this feature as an experiment. -Sid --~--~-~--~~~---~--~~ 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: Meeting Notes From 2/9/2009 Now Posted!
We stopped posting because (a) the notes seemed not to be very useful out of context and (b) removing any Google-specific info, though it was minimal, was pretty labor intensive. I think it may be more productive to try to keep some public roadmaps and tasklists updated. Ian is working on creating an OWP roadmap that will be updated weekly with the status of the main areas of work. If that works out, perhaps we can do the same for other areas of the project. It seems like that would be more helpful and also more practical. Does that seem like it would meet the needs of the external developers? I want to make sure contributors have the info they need to be productive, but I don't want to create unnecessary work. Brian On Thu, Jul 9, 2009 at 8:10 PM, Evan Stade est...@chromium.org wrote: Is it possible to continue posting these? external developers have requested it. -- Evan Stade On Wed, Feb 11, 2009 at 10:18 AM, Peter Kastingpkast...@google.com wrote: On Tue, Feb 10, 2009 at 6:19 PM, Glenn Wilson gwil...@chromium.org wrote: Meeting notes from February 9, 2009 are now posted on the Chromium developer documentation: http://sites.google.com/a/chromium.org/dev/developers/meeting-notes#02092009 Please contact me if you have any questions, and enjoy! It might be nice to post these on a blog somewhere, primarily so they can be grabbed via RSS; various Mozilla meeting notes are posted this way. 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: Google Summer of Code application
Hi, I'm glad to hear that you are interested in helping us improve Chromium. Please review our project ideas pagehttp://docs.google.com/Edit?id=dhk32tn7_0g7kcr2cgand prepare an application for a specific project that you would be interested in pursuing. The more detail you can include that demonstrates your qualifications for your project, the better your chances will be. For more information, check out the recent blogpost at http://google-opensource.blogspot.com/2009/03/reminder-applications-for-google-summer.html Thanks, Brian On Wed, Apr 1, 2009 at 1:10 PM, kmger kmger kmger...@gmail.com wrote: What is your academic major and how far along are you? I am a Computer Science Major and currently I am in my senior year (Graduating in December 2009). I am in a honors program working towards my M.S. in Software Engineering (which I will complete in May 2010) What school are you attending? University of Southern California What is the most complicated coding project you've completed? What was your role on that project? The most complicated coding project I completed was working a full multi-player open source game called developed in C++. I was with the project from start to finish and actively participated in the entire development process. I was in charge of the control module of the game and implemented the keyboard control as well as a Sony PlayStation 2 control capability. Do you have any experience working on open source projects or on development teams? Yes (as mentioned above) Do you have any experience developing for Windows, Mac, or Linux? I have strong experiene developing for Windows and LInux and some experience developing for the Mac. Which programming languages are you most comfortable with? C, C++, Java What would you like to work on to make Chromium better? Why is that project worth spending time on? What qualifies you for that project? I am particularly interested in improving the performance aspect of the project and possibly working on the UI What do you hope to learn from working on Chromium? Simply put, I hope to gain hands on experience of working with such large project such as Chromium and to further my skills as a software engineer. In addition I want to hopefully come out of the project knowing that my knowledge and skills have contibuted to advancing an application that is going to be used by millions of users across the world. --~--~-~--~~~---~--~~ 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: Framework for automated test case simplification
Hi Jonas,I'm glad to hear that you are interested in helping us improve Chromium. The project you've identified seems interesting. If you haven't already, please prepare an application including as much detail demonstrating your qualifications for the project as you can. It's not immediately obvious how you would automate the process of creating a reduced test case, so I'm excited to see what you can tell us. For more information about the program, check out the recent blogpost at http://google-opensource.blogspot.com/2009/03/reminder-applications-for-google-summer.html Thanks, Brian On Wed, Apr 1, 2009 at 2:22 PM, Jonas Fonseca jonas.fons...@gmail.comwrote: Hello, I am considering taking part in this years GSoC to create a framework for chromium to automatically reduce test cases. Currently, the issue tracker contains 71 issues labeled NeedsReduction[1], which suggests that such a framework could be of assistance to developers and testers. The basic idea is to create an external tool, plugin or extension, which implements some of the existing testing tips[2] and concepts from the delta debugging project[3] and allows to automatically creates reduced test cases using an iterative approach. [1] http://crbug.com/?q=label:NeedsReduction [2] http://dev.chromium.org/for-testers/backend-testing/website-compatibility/reduced-test-cases [3] http://www.st.cs.uni-saarland.de/papers/tse2002/ I would like to know if such a framework would be of interest to the Chromium project or if it already exists internally at Google, since I see links, such as http://go/reductions/5680/testcase.html, in some of the issues that needs reduction. About me: In the past, I have been a developer on the ELinks text-mode browser. On my master, I have worked on creating a test framework for networked embedded systems and am interested in applying some of the ideas I have stumbled upon during this experience to other areas. -- Jonas Fonseca --~--~-~--~~~---~--~~ 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 App Executables Disk Layout
I'm supportive of some UI to let the user know that there is a update pending. This should be non-model and minimally distracting. We've talked about a notification area on the NTP. It would also serve as a place that we could tell people about cool new features. We'll throw this on the queue for the UI team to mock up (if we don't have mocks already). On Sun, Mar 29, 2009 at 3:49 PM, John Grabowski j...@chromium.org wrote: This is a very delicate line to walk. We want to silently update... yet not actually be silent. We want updates to take effect immediately... yet not require an app restart. You have provided some good ideas but, in practice, it can be difficult to close on a compromise that doesn't make some subset of players very upset, or expose a new class of complexity. Chrom(ium) packaging and resource finding is different on each platform, which has implications for an update strategy. For the Mac, thomasvl is currently reworking the app structure, so it is probably best to wait for his work to complete before we make a proposal. jrg On Sun, Mar 29, 2009 at 2:31 PM, Jim Roskind j...@chromium.org wrote: Perhaps we need to think about how to encourage such a restart, without being the traditional pop-up pain-in-the-er-um-rear. Can we find real-estate that won't tend to detract from the ui to alert the user that an update is pending? Perhaps atop a new-tab page? Perhaps an extra entry ot the top-level wrench menu? ...in a different color near About Chrome?? On windows, should we be alerting the user via the little updates are pending dialog that Windows and others are using?? Can we make the update especially painless for users, by temporarily opting them into to restore the existing tab settings, even if they don't usually do so?? Can we do other things to make it easy, and obvious to encourage a user to allow an upgrade? I don't think it is possible... but can we detect when it would be a good time to upgrade, and just help them along? I suspect that too much state would be lost (sign in, cookies, SSL session keys, etc. etc.). Maybe we can detect* that they are in a very reproducible state and that they are quiescent and then do the update (perchance a large percentage of users live in such states)?? Can we do some fancy optimization to do most of the startup of the new version before we shut down the old version, so the transition is super-fast?? It is clear to me that our wonderful work to crash less is working... and greatly extending the time-till-update after the user has the downloaded update on disk. IMO, delaying an upgrade is probably a Bad Thing (TM) for the user (which is why we push out better versions)... but interrupting a user's action is a very Bad Thing. Can we improve the compromise, and help the user? Jim On Sun, Mar 29, 2009 at 1:25 PM, Erik Kay erik...@chromium.org wrote: On Sun, Mar 29, 2009 at 1:02 PM, Thomas Van Lenten thoma...@chromium.org wrote: Most mac apps solve this by having the app exit as part of the upgrade process, this way a new copy is launched w/ the new resources. yes, but this is the problem with silent autoupdate. We don't want to force the user to stop what they're doing when an update starts. Erik On Sun, Mar 29, 2009 at 4:40 AM, John Grabowski j...@chromium.org wrote: How will in-place updating work on the Mac and Linux? To be frank, we haven't solved this problem on Mac. Right now we're doing an rsync to klobber on update, which is fine for pre-dogfood. E.g. our normal Mac crash rate far exceeds any possible crashes caused by version mismatching in the 3 auto-updates we have sent out internally. Although we could load all resources on startup, that ignores one critical piece. Since renderers are separate processes and are launched on-demand, we would still have the problem of old browser talking to new renderer. All platforms would have this problem if they don't force the apps to bounce as part of the upgrade process, no? TVL I suspect we'll need to have either a versioned scheme line Windows, or a complete upgrade step on initial launch. jrg --~--~-~--~~~---~--~~ 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: Design doc: Background Browser Task
Drag and drop seems like a clumsy and unfamiliar mechanism for granting this capability. A modal dialog would be better. We can inject a delay on making the OK button active if we are worried about clever attacks that get users to click on an OK that appears underneath the cursor. -Brian On Tue, Oct 28, 2008 at 5:55 PM, [EMAIL PROTECTED] [EMAIL PROTECTED]wrote: Hi all, Here is a draft of a design doc for Background Browser Task: http://docs.google.com/View?docid=dd6rm2wb_3fmz8pnnp Your feedback is appreciated. Thanks, Jian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
