[chromium-dev] Re: Proposal: per-tab open/save dialogs
This seems like a good idea. Maybe there could also be some visual indication on tabs as to whether they currently have a save/open dialog to avoid hunting through all open tabs to find that one tab where you were going to save that image or whatever. -Paul Wicks On Fri, Aug 14, 2009 at 11:03 AM, Viet-Trung Luuviettrung...@gmail.com wrote: Dear all, In the spirit of reducing modality, I propose that, where possible, Open/Save (and other?) dialog boxes should be per-tab (i.e., tab-modal, rather than window-modal). Does anyone have any UI concerns with this? (Nudge, nudge, UI people) As a proof-of-concept, an implementation for Mac is in the CL http://codereview.chromium.org/164547 (be gentle, there are some bugs to be worked out). I'm told that this should be feasible under Linux, but perhaps isn't under Windows. If that's the case, does anyone object to Mac and Linux Chromium having a superior user experience to Windows? (Or, better, does anyone know how to embed a Windows file selection dialog in a window?) - Trung --~--~-~--~~~---~--~~ 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: Flakiness. Please help.
Maybe this is a stupid question, but where can I find test-expectations.txt? I looked in the tree and didn't see it. -Paul Wicks On Wed, Aug 5, 2009 at 11:12 PM, Peter Kastingpkast...@google.com wrote: On Wed, Aug 5, 2009 at 10:10 PM, Eric Seidel esei...@chromium.org wrote: Do we have a list of flakey tests? I feel like we used to have one... Every test in test-expectations.txt marked PASS FAIL or PASS FAIL CRASH or some similar set of multiple expectations is flaky, or at least thought to be so. 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] Reviewer needed for OS X spelling panel CL
I've got a decent size CL to add support for the os x spellchecker's spelling panel to chromium and I need to get it reviewed. I would have pinkerton review it, but he's out this week. Anybody want to give it a shot (maybe somebody else from the mac team) and let me know what stupid thing's i've done? ;) The issue on code review is here: http://codereview.chromium.org/160565 Thanks, -Paul Wicks --~--~-~--~~~---~--~~ 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: How to attach to Renderer Process in XCode
You might try attaching gdb from the command-line. I've always had better results doing it that way than using xcode. Once you've started chromium with the --renderer-startup-dialog flag, you can attach by starting gdb in a terminal window and typing attach 460 (or whatever the pid of the renderer is). Once gdb is attached to the renderer, you can set any breakpoints you like and then continue to run chromium (c is continue by default). Note that every time a new renderer is started, chromium will pause until you tell it to continue (usually by attaching a debugger). -Paul Wicks On Sun, Jul 26, 2009 at 2:23 PM, n179911 n179...@gmail.com wrote: On Thu, Jul 16, 2009 at 12:46 AM, Jeremy Moskovichjer...@chromium.org wrote: You can find instructions here: http://dev.chromium.org/developers/debugging-on-os-x Ultimately, we should really combine all the platform debugging articles into one page :| Best regards, Jeremy Thanks. I tried it. I saw this in the shell: [460:2055:4872081828141:WARNING:/Users/n179911/chromium/src/chrome/renderer/renderer_main.cc(65)] Renderer (460) paused waiting for debugger to attach @ pid And then I got XCode and Attached to '460'. But i see this in my shell, and chromium never get launched. [460:11783:4914670085769:ERROR:/Users/n179911/chromium/src/ipc/ipc_channel_posix.cc(649)] pipe error on 3: Broken pipe Thank you for any help. On Thu, Jul 16, 2009 at 9:29 AM, hap497 hap...@gmail.com wrote: Hi, chromium.org has this http://dev.chromium.org/developers/how-tos/debugging for debugging renderer process on Windows. My question is how can I do the same in XCode on MacOS X? I go to Run-Attach To Process, all the menu item entries are disabled. Thank you for any tip. --~--~-~--~~~---~--~~ 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
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] What's the deal with document tags?
I'm working on implementing the OS X spelling panel for chromium and I was wondering about document tags (a unique tag for every spellcheckable thing). These tags are needed in order to support ignoring words, which the spelling panel has a button for. It looks like there is some support for it in webkit (the method Editor::spellCheckerDocumentTag defers to EditorClientImpl which has the it marked as NOTIMPLEMENTED()). The problem is that Editor::spellCheckerDocumentTag doesn't seem to ever get called (or at least, a breakpoint in the renderer at that line doesn't get hit on a page with an editable textarea element). The tags themselves are pretty easy to generate (NSSpellChecker has a method to do it), but I'm a bit lost as to how they work in webkit. So, if anybody knows anything about how these are supposed to work, that would be awesome. Thanks, -Paul Wicks --~--~-~--~~~---~--~~ 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: Changing the language of the spellchecker?
Oh, ok, so when the language is changed, a new spellchecker object is created. That's what I thought might be happening. Thanks, -Paul Wicks On Wed, Jun 17, 2009 at 5:14 PM, sidchat sidc...@chromium.org wrote: Yes, Evan is right. So, when you change a spellcheck language in the Options menu (languages_page_view.cc), it changes a pref member (prefs::kSpellCheckDictionary) value. This change is caught by the Profile (ProfileImpl::Observe in profile.cc), which (re)initializes the spellchecker with the new language. The pref member can also be changed from the right-click context menu, as Evan pointed out (see RenderViewContextMenu::ExecuteItemCommand() in render_view_context_menu.cc). So it seems implementing languages Options menu and context menu items items for spellchecker might make this whole thing work automatically. -Sid On Jun 17, 4:02 pm, Evan Martin e...@chromium.org wrote: Just a guess, but perhaps when you change languages a new Spellchecker object with the new language is constructed. I would expect the language-picking options haven't yet been implemented. You can also switch languages via the right-click menu on a text area, but that may also be unimplemented. It might be worth implementing those as a prereq for your current project. :) On Wed, Jun 17, 2009 at 3:54 PM, pwickspwick...@gmail.com wrote: I'm working on porting the os x spellchecker to chromium and I've run into a question. I'm trying to figure out how the language of the spellchecker is change. The only place that I can see where it is ever specified is in the constructor to Spellchecker. I don't see any other functions/methods that deal with language selection, just with querying the available languages. I was going to try and trace this through in the debugger, but the button on the options pane to change the language is greyed out. Anybody know anything about how this works or can point me in the right direction? (Sid, is this what you were talking about when you mentioned that there was something unimplemented?) Thanks, --Paul Wicks --~--~-~--~~~---~--~~ 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: Adding Mac OS X Spellchecker to Chromium
Thanks all for the input. I've successfully implemented basic spellchecking using the OSX spellchecker, although the implementation is a bit untested, so I'm trying to get that cleaned up a little bit before moving any more forward. As for keeping hunspell or not, I've left it there, it isn't take much work to keep it around, since the code is already there and working. It should work more or less as Sid mentioned, only taking over when OSX doesn't support the language. The design on the whole didn't change too much from what I originally talked about above, although I have added the calls into cocoa as wrapper functions in a seperate file. The main issues I still have to work out for basic spellchecker functionality (not the spelling panel) mainly revolve around language selection. It's a bit unclear to me how the language of the spellchecker is changed, since the only place to specify it is in the constructor to the spellchecker. I don't see any other functions/methods that deal with language selection. I was going to try and trace this through in the debugger, but the button on the options pane to change the language is greyed out. Anybody know anything about how this works or can point me in the right direction (or is this the not-implemented piece that Sid mentioned)? -Paul Wicks On Thu, Jun 11, 2009 at 11:59 AM, sidchat sidc...@chromium.org wrote: Use of OS X spellchecker integration in our multi process model probably should be the primary goal here to begin with. If that is achieved, the other stuff (auto spell correct, automatically setting the dictionary etc) should not be too problematic. Note that the actual replacement for auto-correct is done in WebCore (WebKit) - Chrome just provides the decision as to whether to auto- correct it or not. So, as you pointed out, our method SpellcheckWord, instead of using Hunspell, can ask OS X SpellCheck API to provide the decision. The multi-process model is automatically taken care of here from existing design, since any query for spellchecking comes to the spellchecker in the browser process - and the browser process can talk to the OS X API I guess. Same goes for generic spell checking. There is some integration with Chrome UI where one can set the spellcheck dictionary languages, enable/disable spellchecking/auto- correct. Again, all these decisions eventually seep down to the spellchecker residing in the browser process, and as far as you are concerned, the SpellCheckWord and GetAutoCorrectWord methods should continue asking OS X for the spelling decisions, now based on the new language, or not, depending on the setting. If OS X does not support some languages, this can be dealt with easily. You can make a list of languages that OS X supports, and based on that, either ask OS X spellcheck API, or simply initialize Hunspell in SpellChecker when the language is changed. The Profile, which initializes spellchecker, can be blissfully unaware of this, as it does not care how you are providing the spellchecking as long as the spellchecker object exists, and is providing decisions. I am not exactly sure how automatically setting dictionary language will work out, as it has not been implemented yet. But you can get to that later - my thought is, it should be on similar lines, where you have to only worry about spellchecker.cc. -Sid On Jun 10, 8:29 pm, Ben Goodger (Google) b...@chromium.org wrote: +Sid I think it's worth understanding the API requirements of the new features. I know nothing about Spellchecking though. Maybe Sid can add more? -Ben On Wed, Jun 10, 2009 at 8:14 PM, Nick Baumnickb...@chromium.org wrote: In particular, Ben is referring to the automatic spelling correction that Sid is implementing. Off the top of my head, I can think of a few different ways this could fit in: We can implement Sid's auto-correction on top of native spellcheck, just like today it's implemented on top of Hunspell. OS X will provide similar (though not identical) functionality, and we deem this good enough. We decide native integration is more important than feature parity. As we add more smarts to the spellchecker, we'd need to keep re-evaluating. Thoughts? -Nick On Wed, Jun 10, 2009 at 2:38 PM, Ben Goodger (Google) b...@chromium.org wrote: For whoever is coordinating this effort, please sync up with Nick Baum on spell checking. He has some additional considerations in mind we should make sure we understand what's possible here. -Ben On Wed, Jun 10, 2009 at 2:36 PM, Mike Pinkerton pinker...@chromium.org wrote: I think we're all on the same page. I pushed Paul to consider having both in his initial design since I forgot about the ability to add additional dictionaries. I'm glad others are in support of that as the way to get additional language support as opposed to trying to shim both implementations
[chromium-dev] Adding Mac OS X Spellchecker to Chromium
I've been looking implementing support for the OS X spellchecker on the Mac build as part of my SoC project and I thought I'd run some thoughts I had today by the list. For the basic design, both hunspell and the os x spellchecker need to be useable, since hunspell supports * my idea for the overall design * other stuff to be included (mainly the spelling panel) -Paul Wicks --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Adding Mac OS X Spellchecker to Chromium
Crap, sorry to post an incomplete version of this post earlier. Accidentally hit send before I finished it. Argh... Anyway, I've been looking at implementing support for the OS X spellchecker on the Mac build as part of my SoC project and I thought I'd run some thoughts I had today by the list. For the basic design, both hunspell and the os x spellchecker need to be usable, since hunspell supports more languages than OS X does. The public interface of the Spellchecker class is fairly small (mainly 2 methods: SpellCheckWord, AddWord). It seems that mapping these onto the OS X spellchecker shouldn't be too hard. I originally thought to do something more elaborate and create seperate spellchecker classes for each platform, but then realized that I could do it more simply as follows: -leave the majority of spellchecker.cc as is. It works and I don't see any reason to mess with what works. -for SpellCheckWord, change the call to hunspell_-spell(...) to call a (new) private method in the SpellChecker class. In this method, add some code at the beginning that will check if we are on the mac and if the built-in spellchecker supports the current language and if so checks the word using it, other wise using hunspell as before. This way, we can leave the rest of the code alone and still use the SpellCheckWordIterator to grab individual words out of the string. As for getting the suggestions for a word, it might make sense to do things a little differently, since there is no need to create and manage the char** suggestions variable to pass to hunspell, as NSSpellChecker can give us an easy-to-iterate-through NSArray. Probably just an #if defined(OS_MACOSX) would suffice here, since the code here will be wholly different. -for AddWord, their probably isn't as much of a need to abstract the hunspell specific code (it's all hunspell code), so just an #if defined( OS_MACOSX)+language support check would suffice. -The other public methods all deal with language selection and querying, which should remain the same, since the OS X spellchecker only supports a subset of the languages supported by hunspell. (there may need to be a little bit of code to translate between the codes for supported languages so that the built-in spellchecker always gets used when it should, but this should be a relatively simple matter. -The private method IsValidContraction could call the same new private method as defined above. -This way, the public interface stays the same and the mac folks get to use their own dictionary. -The newly added autocorrection code should work just the same as before, as it relies on SpellCheckWord. -also, [NSApplication sharedApplication] needs to be called before the the built in spellchecker is used. I'm not sure of where the best place to put this call is. The upside to doing it this way is that it should be relatively easy to modify the spellchecking code for any one platform without breaking any other. The main downside that I can see for doing it this way is that for languages that are supported by OS X, we will be keeping a hunspell object around that we don't need, at least until the language changes to something hunspell supports and os x doesn't There are a few additional features that the OS X spellchecker supports that need some discussion. 1. Grammar checker: I know I've seen some talk about adding this to chromium somewhere. The OS X spellchecker also has support for checking the grammar of a string (only in 10.5+), so that is something to keep in mind when that stage is reached. 2. Spelling Panel: The OS X spellchecker has support for a Spelling Panel. Similar to spellchecking in most word processors, this provides a seperate GUI Panel that allows for checking a whole paragraph in one go. The main problems here are that this is functionality that is in no way matched by the Windows or Linux Builds. Additionally, it would require some way of identifying the source of each word, since the spelling panel allows for the creation of a list of ignored words, which are unique to a document. In the case of chromium, a document would correspond to a given textfield, most likely. The NSSpellChecker API provides a function (uniqueSpellDocumentTag) to generate tags for this purpose, but a way would have to be found to generate and match these tags up, which could be complicated (although I admit that I've not spent a lot of time looking at the code that would need to be altered to make this aspect of the spelling panel function). Any thoughts would be great. Thanks, -Paul Wicks --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] An Introduction and a question
Hello Chromium Developers! My name is Paul Wicks and I am one of the students working for this project as part of Google's Summer of Code (Mike Pinkerton is my mentor). Specifically, I am working on implementing support for the OSX dictionary/spellchecker in Chromium. There is a blog of my progress at http://pwicks-bloggingchrome.blogspot.com/ ,although there really isn't any content at the moment. Just thought I'd introduce myself. Well, know that I have your attention, I do have one question. I've been looking at the spellchecker code to try and figure out how it works/what I need to do to make it work in the OSX port. I've looked at spellchecker.cc and its associated files in /chrome/browser/ and everything there makes sense more or less, but I'm having a little trouble figuring out where calls to the spellchecker come from. I'd guess this is something that would happen over IPC, given that the spellchecker lives on the I/O thread and the content of tabs will live in their own processes. If anyone could point me in the right direction to understand how this whole process works, that would be great. -Paul Wicks --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
