[chromium-dev] GYP-generated make files now auto-regenate
Heads up for those using the GYP make generator: the GYP update last night included a patch from mattm to add dependencies to the generated Makefiles to run gyp to auto-regenerate the Makefiles if the .gyp file(s) change. You should now be able to make changes to the .gyp configuration and rebuild by just typing 'make', bypassing the need for a manual 'gclient runhooks --force' step. --SK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Linux views trybot
I created a builder for that. It is not in the default pool since I connected only one slave to it. On Wed, Sep 16, 2009 at 1:24 AM, Peter Kasting pkast...@google.com wrote: We need one. I have broken the Linux views build three times in the past three days. This is wasting my time and the sheriffs' both. Is someone working on making this happen? 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: Need help on how to send data from RenderView to a custom DOMUI instantly
Here is a brute force way I think would *work*, but I'm not sure it's the right thing to do. Do we send big images across IPC anywhere currently? I think we send small stuff like favicons... So don't try this at home unless others say it isn't crazy, or you just want a proof of concept :) Creating your special DOMUI would happen shortly after handling the context menu click, so you can register a ChromeURLDataManager::DataSource for the print preview html at that time, before the request is sent to the RenderView to load the print:// URL. Some time after that your code to generate the image snapshot in the RenderView will get triggered, and a resource request will be issued to the browser process for the HTTP GET. So your image code could send the bitmap across, and the DOMUI in the associated TabContents would just sit tight until it received it. It would have to then send it to the data source or wait for the data source to ask for it, FileIconSource does something like this with HistoryBackend. The data source would respond asynchronously with the full HTML (e.g SendResponse) once it has received the image data and stuffed it into the html template. It feels convoluted to send the image through all these hoops though only to send it back down to the renderer though. I'm not sure what kind of hooks we'd need on the renderer side to avoid it.. we intercept for some about: urls and we have the alt error page fetcher, but I'm not sure how to go about generating the print preview html at the renderer entirely. On Tue, Sep 15, 2009 at 9:21 PM, Mohamed Mansour m...@chromium.org wrote: The UI is going to be in JavaScript with callbacks from the DOMUI page same as NTP, Downloads, History, etc... Therefore in render_view.cc, I need to replace the WebFrame with the DOMUI (I think). I don't want to introduce my own set of methods that exposes this, that is why I am asking for some thoughts, on the right approach. How do you recommend making print preview to work? The UI team's mockup was visioning a domui that handles the print preview/settings. Should we open a new tab for print preview, or should we use the same tab? In either case, how can I pass data, in particular the Bitmap image that is created in RenderView to the DOMUI page so I can view it. Any help is appreciated. - Mohamed On Wed, Sep 16, 2009 at 12:06 AM, Brett Wilson bre...@chromium.orgwrote: On Tue, Sep 15, 2009 at 7:31 PM, Mohamed Mansour m0.interact...@gmail.com wrote: Hi all, I am having trouble trying to figure out how I could replace the contents of a specific WebFrame while I am in RenderView with a custom DOMUI page that I have created. Here is a scenario: User visits http://www.google.com User waits till page is done loading User selects Options Print Preview The current page will be replaced with a custom PrintPreview DOMUI page (print:http://www.google.com) where I would be passing some Data such as a vector of bytes (image) from RenderView to PrintPreviewDOMUI I have created the DOMUI page and made sure it works, and created the bitmap and encoded it with JPEGEncoder, but I am clueless on how the connection would be from RenderView to DOMUI. Any assistance is appreciated. The reason why I want to replace the current contents is because print preview depends on what is exactly visible at that time. Unless there is a better way. Thanks in advance! Is the code you're writing in C++ or JS? 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: Need help on how to send data from RenderView to a custom DOMUI instantly
Here is a brute force way I think would *work*, but I'm not sure it's the right thing to do. Do we send big images across IPC anywhere currently? We did briefly (to and from the extension unpacker process), but it was changed to using on-disk files because were limits on the amount of data that could be sent (1MB, I think). Matt Perry knows more. --~--~-~--~~~---~--~~ 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: Need help on how to send data from RenderView to a custom DOMUI instantly
Step 4 is wrong, you don't replace in-place, you do a navigation, like view-source. Random idea; the page's could be duplicated in a hidden iframe with javascript disabled, greatly simplifying the code to generated the print preview pages jpg and making the DOM duplication a 100% javascript issue. I don't know if that can be safely done merely with javascript, that would be awesome. Only caveat, print preview would be disabled when javascript is disabled. We need to find a way to not make the printed pages preview jump to the browser, that would be (slightly) insane. M-A On Sep 15, 2009 10:32 PM, Mohamed Mansour m0.interact...@gmail.com wrote: Hi all, I am having trouble trying to figure out how I could replace the contents of a specific WebFrame while I am in RenderView with a custom DOMUI page that I have created. Here is a scenario: 1. User visits http://www.google.com 2. User waits till page is done loading 3. User selects Options Print Preview 4. The current page will be replaced with a custom PrintPreview DOMUI page (print:http://www.google.com) where I would be passing some Data such as a vector of bytes (image) from RenderView to PrintPreviewDOMUI I have created the DOMUI page and made sure it works, and created the bitmap and encoded it with JPEGEncoder, but I am clueless on how the connection would be from RenderView to DOMUI. Any assistance is appreciated. The reason why I want to replace the current contents is because print preview depends on what is exactly visible at that time. Unless there is a better way. Thanks in advance! - Mohamed Mansour --~--~-~--~~~---~--~~ 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: Need help on how to send data from RenderView to a custom DOMUI instantly
On Tue, Sep 15, 2009 at 9:21 PM, Mohamed Mansour m...@chromium.org wrote: The UI is going to be in JavaScript with callbacks from the DOMUI page same as NTP, Downloads, History, etc... Therefore in render_view.cc, I need to replace the WebFrame with the DOMUI (I think). I don't want to introduce my own set of methods that exposes this, that is why I am asking for some thoughts, on the right approach. There are many layers here, and you have to be careful you're at the right one. Because we wanted to prevent mistakes allowing web content access to privileged browser data (unless something's changed since I last worked on it) you have to use an entirely new renderering process for DOMUI. WebFrame is down within a given renderer, while DOMUI is a browser-level abstraction above the IPC layer. You can have a DOMUI within the same tab, of course (that's how you can click links from the new tab page). If you really want to show the original page, you'll have to do something either tricky or sneaky. M-A's idea is good. Another idea is to add more goop at the UI level to allow a tab to display a DOMUI toolbar (with the print button etc.) while still showing the original page below the toolbar. Like a frame, but done at a higher level so the page can't bust out of its frame. If instead you just want to display an image of the page, previewed, that's easier. Grab the snapshot when navigating away to your DOMUI; don't even tell the page you've navigated away (avoids all the do you want to save? dialogs etc.) and swap its renderer out entirely. To get the snapshot back in to your new DOMUI, the rest of what Tim wrote (aside from the part I just contradicted in the last sentence) about how to get images in is right. The way we load thumbnails into the NTP is a good resource; basically the page would have something like img src='whatever-the-internal-scheme-is://preview' and you'd hook up a data handler to serve the image data on that URL. You might run into some jankiness because of the way images are currently served (just as one huge string rather than incrementally loaded) but that is an optimization detail that can be worked on after you have it kinda working. --~--~-~--~~~---~--~~ 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: GYP-generated make files now auto-regenate
On Wed, Sep 16, 2009 at 6:00 AM, Steven Knight s...@chromium.org wrote: Heads up for those using the GYP make generator: the GYP update last night included a patch from mattm to add dependencies to the generated Makefiles to run gyp to auto-regenerate the Makefiles if the .gyp file(s) change. You should now be able to make changes to the .gyp configuration and rebuild by just typing 'make', bypassing the need for a manual 'gclient runhooks --force' step. --SK Nice ! Antoine --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Chrome Library for tweaking Windows Network Settings
Hi, I am trying to automate few test cases that requires me to simulate certain scenarios like 'Network is down' or 'Sync server not reachable' etc.. I am not sure about the Chrome Library that I can use to play with Windows Network Settings. I am using InProcBrowser Test. Pointers to library or examples will be helpful... -- Thanks, Tejas --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Is there any good tool on Linux to browser and cross reference chromium source code?
I don't know if you've already looked at Doxygen, but to help bootstrap me into the code, I ran it on the codebase minus third_party/webkit. It picked up the doxygen specific formatting for V8, but the classes and files sections are there: http://chrome.nerdbox.net (r21988) I have also in the past used LXR to explore larger codebases. I have an older version of LXR indexing SQLite code here: http://read.cs.ucla.edu/~vandebo/sqlite/ -- Steve On Wed, Sep 16, 2009 at 10:41 AM, Evan Martin e...@chromium.org wrote: I'd like to set up a web-based code browser on chromium.org, but I played around with a couple and wasn't too happy with any of them. Suggestions are welcome. On Tue, Sep 15, 2009 at 9:19 PM, James Su su...@chromium.org wrote: Hi, I'm currently using cscope + vim, but it's so slow and hard to use. Is there any better choice? Regards James Su --~--~-~--~~~---~--~~ 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: browser/sync is moving in
Hey there, just wondering if the --enable-sync option is working under
Google Chrome 4.0.207.0 for Linux? Thanks in advance.
On Jul 31, 5:07 pm, Tim Steele t...@chromium.org wrote:
Hi!
A bunch of us have been working on a feature to sync user data in Chromium
with a Google account. (Surprise! :)) The great news is that we'll be
starting to work directly in the Chromium project this week, and let me tell
you, are we excited to do that! This email discusses how we're planning to
get started, in detail (maybe too much detail... sorry).
We have built a library that implements the client side of our sync
protocolhttp://sites.google.com/a/chromium.org/dev/developers/design-document...,
as well as the Google server-side infrastructure to serve Google Chrome
users and synchronize data to their Google Account. Of course, all the code
going into Chromium is open source, and the messages between the client and
server use the open protobuf http://code.google.com/p/protobuf/ format and
library. Check out the sync developer
pagehttp://sites.google.com/a/chromium.org/dev/developers/design-document...
if
you're interested in low-level goals and technical details.
We will be landing this code in a few steps rather than one giant changelist
for a number of reasons. First, this makes reviewing a *lot* easier; it
isn't the most straightforward code by nature, so the more fine grained
scrutiny the code gets, the better. Second, we've been working in a
proprietary environment until now because of the dependency of having to
build the complementary Google production server environment for syncing.
As such, the code uses a small number of internal libraries that we need to
open-source or replace, as well as libraries that would be redundant to what
Chromium already includes. Removing these, and open sourcing the entire
sync engine, is our highest priority and we expect this to take about three
weeks.
So how will we commit the code in pieces and not totally hose the build in
the process? First, a little more background. You may have come across the
CHROME_PERSONALIZATION #define when digging through Chromium source code.
Right now, this is used in conjunction with a relatively small number of
private c++ source files to conditionally build Chromium with sync enabled.
These files are in fact a glue layer between Chromium and what is called
the syncapi, which is the bulk of the client library I was talking about
above. On windows, syncapi is built into a DLL, and when
CHROME_PERSONALIZATION is defined this DLL gets placed alongside chrome.dll
for use at runtime. Syncapi builds and runs on Linux, but not Mac (yet).
With the initial checkin, we will leave the CHROME_PERSONALIZATION #define
as-is, so the sync code will not be built by default. We'll be working hard
over the coming weeks to make sure the code passes all existing test suites
that are part of the regular buildbot cycle, and on removing the #define.
After that, our hope is that we will be free of the DLL altogether and have
all the code checked in to the repository, fully functional or not, in a few
weeks. We do *not* plan on ever checking in the windows-only syncapi dll to
the main chromium repository. So until the dll is no longer needed, the
public repository won't have all the bits to actually build Chromium with
sync enabled. That said, we want to keep the sync build running smoothly,
so we will use a combination of command-line flag (to enable sync) and
delay-loading syncapi.dll only when it is needed. This will allow the
glue code to compile as part of the normal Chromium build without
introducing a dependency on this dll, yet still make it possible to run with
the dll present.
On that note, we're planning to use the syncapi DLL to produce a
sync-enabled Google Chrome build for dev-channel users in a week or so, to
get the feature into experimentally inclined hands. We have a great deal of
infrastructure, both in the browser and in the form of production Google
services, that need to start seeing real user traffic and usage. It takes a
great deal of testing and confidence inspired by real usage statistics
before any complex system like this can be deemed adequate for use by a
large user base. So if we want to let all Google Chrome users use sync (and
we do! we do!), we've got to get started on this pronto.
Our developer
pagehttp://sites.google.com/a/chromium.org/dev/developers/design-document...
also
covers the hierarchy of files we're landing that you can expect to start
syncing (in the gclient sense) down in the next couple of days. We can't
wait (*really*) to work on this with the rest of the Chromium community and
going even further in creating the best browzr ever!
Thanks for reading, and happy syncing!
- the cloudy bunch
{idana, nick, nickbaum, chee, munjal, brg, chron, zork, laforge, tejasshah,
tim} at chromium.org
[chromium-dev] Re: Chrome Library for tweaking Windows Network Settings
On Tue, Sep 15, 2009 at 1:54 PM, TJ Shah tejass...@chromium.org wrote: Hi, I am trying to automate few test cases that requires me to simulate certain scenarios like 'Network is down' or 'Sync server not reachable' etc.. I am not sure about the Chrome Library that I can use to play with Windows Network Settings. I am using InProcBrowser Test. Instead of changing Windows' network settings, you should use a mocked-out network layer in the browser that you make do these things. I suspect we already have some facility for this so we can test other cases. 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: Chrome Library for tweaking Windows Network Settings
You can mock the HostResolver to make it fail to resolve anything (possibly except localhost). For examples, see HostResolver's unit tests and possibly other places where it is used. You can also make it fail to resolve specific hosts, which should also be handy. On Tue, Sep 15, 2009 at 13:54, TJ Shah tejass...@chromium.org wrote: Hi, I am trying to automate few test cases that requires me to simulate certain scenarios like 'Network is down' or 'Sync server not reachable' etc.. I am not sure about the Chrome Library that I can use to play with Windows Network Settings. I am using InProcBrowser Test. Pointers to library or examples will be helpful... -- Thanks, Tejas --~--~-~--~~~---~--~~ 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: Crashes due to 25633
I believe brettw new sqlite wrappers removed that. Maybe he has not landed it or I misunderstood. Let me check. Of course even if landed I don't know to what revision you synch to. Also that points to a bug, possibly sqlite db corruption. Do you mind filling a bug or having one of the users filling it? On Sep 14, 10:35 am, spotrh spo...@gmail.com wrote: A fair amount of the Fedora users using my package are reporting browser crashes when trying to type in the URL bar, and they seem to be caused by the change in 25633: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/sqlite_... The code said it is planned to be removed once it has a few days of air time. ... I was wondering if those few days had passed. :) ~spot --~--~-~--~~~---~--~~ 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: Crashes due to 25633
On 09/16/2009 02:25 PM, cpu wrote: I believe brettw new sqlite wrappers removed that. Maybe he has not landed it or I misunderstood. Let me check. I don't see any changes to src/chrome/common/sqlite_utils.cc in SVN trunk. ~spot --~--~-~--~~~---~--~~ 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: Crashes due to 25633
On 09/16/2009 02:23 PM, Evan Martin wrote: What is the error message? I wonder if there is something Linux-specific where we're getting an error code that is harmless. (We've had a lot of that in code that checks errno where the value differs between Linux and OS X.) User says it reports: [5070:5093:8302515214:FATAL:/mnt/chromium/rpmbuild/BUILD/chromium-20090910svn25958/src/chrome/common/sqlite_utils.cc(52)] Check failed: false. sqlite fatal error 11 ~spot --~--~-~--~~~---~--~~ 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: Crashes due to 25633
On Wed, Sep 16, 2009 at 12:44 PM, spotrh spo...@gmail.com wrote: On 09/16/2009 02:23 PM, Evan Martin wrote: What is the error message? I wonder if there is something Linux-specific where we're getting an error code that is harmless. (We've had a lot of that in code that checks errno where the value differs between Linux and OS X.) User says it reports: [5070:5093:8302515214:FATAL:/mnt/chromium/rpmbuild/BUILD/chromium-20090910svn25958/src/chrome/common/sqlite_utils.cc(52)] Check failed: false. sqlite fatal error 11 Hm, that doesn't sound good! #define SQLITE_CORRUPT 11 /* The database disk image is malformed */ --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Verdict: Menu string casing
For Mac, we're creating copies of some strings with Title Case for menu items rather than the Sentence case we use on Windows. (Windows Vista HIG recommends Sentence case, Mac recommends Title Case). It sounds like Linux wants Title Case too so it should just use those strings. We will not duplicate strings for any other reason unless they refer to a concept that does not exist on the relevant platform. The idea is that we should have a single set of string content (independent of casing) that documentation can refer to. That is all. -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: Crashes due to 25633
On Wed, Sep 16, 2009 at 12:59 PM, Evan Martin e...@chromium.org wrote: On Wed, Sep 16, 2009 at 12:44 PM, spotrh spo...@gmail.com wrote: On 09/16/2009 02:23 PM, Evan Martin wrote: What is the error message? I wonder if there is something Linux-specific where we're getting an error code that is harmless. (We've had a lot of that in code that checks errno where the value differs between Linux and OS X.) User says it reports: [5070:5093:8302515214:FATAL:/mnt/chromium/rpmbuild/BUILD/chromium-20090910svn25958/src/chrome/common/sqlite_utils.cc(52)] Check failed: false. sqlite fatal error 11 Hm, that doesn't sound good! #define SQLITE_CORRUPT 11 /* The database disk image is malformed */ FYI, I'm almost finished updating our (locally patched) SQLite to version 3.6.18 instead of 3.6.1 that we have now; apparently 3.6.18 handles corruption much better than 3.6.1 does. (I am holding off checking it in until I can run it through all the tests I can find to make sure something won't break, but other than that it's ready.) I don't know what effect it might have on this issue, but hopefully it will be a good effect... --~--~-~--~~~---~--~~ 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: Verdict: Menu string casing
On Wed, Sep 16, 2009 at 1:07 PM, Ben Goodger (Google) b...@chromium.org wrote: We will not duplicate strings for any other reason unless they refer to a concept that does not exist on the relevant platform. The idea is that we should have a single set of string content (independent of casing) that documentation can refer to. To be clear, that means splitting along platform conventions for stuff like Preferences vs Options is out? (Don't have a strong opinion, just curious.) --~--~-~--~~~---~--~~ 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: Crashes due to 25633
On 09/16/2009 04:07 PM, Mike Mammarella wrote: FYI, I'm almost finished updating our (locally patched) SQLite to version 3.6.18 instead of 3.6.1 that we have now; apparently 3.6.18 handles corruption much better than 3.6.1 does. (I am holding off checking it in until I can run it through all the tests I can find to make sure something won't break, but other than that it's ready.) I don't know what effect it might have on this issue, but hopefully it will be a good effect... This is good news, but FWIW, this is also a big reason why forking from established upstreams can lead to headaches. Is there any chance of reworking the chromium specific sqlite changes into something that upstream might merge? ~spot --~--~-~--~~~---~--~~ 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: Verdict: Menu string casing
Hi Ben, We will not duplicate strings for any other reason unless they refer to a concept that does not exist on the relevant platform. The idea is that we should have a single set of string content (independent of casing) that documentation can refer to. at least in non-english languages, this is not possible without looking very bad. Save as for example is translated to German as Speichern als on windows and as Sichern unter on OS X (Save as is in the page menu, so this is something that's on all platforms, not a os x-menu-only thing). As far as I remember, even apps like Firefox, MS Office, and Adobe apps get this right. Do you want to disallow different translations between platforms? If so, people will hate that. If not, then your argument becomes invalid :-) Nico --~--~-~--~~~---~--~~ 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: Verdict: Menu string casing
That's what ben meant by concepts that do not exist for the relevant platform. There are no preferences on windows or options on Mac. That's the one area where we will diverge. However, a menu item like Next Tab should be changed globally to Select Next Tab on all platforms, not just specifically on Mac to match Safari (case appropriate, of course). That's the kind of forking we will not be doing. On Wed, Sep 16, 2009 at 4:20 PM, Evan Martin e...@chromium.org wrote: On Wed, Sep 16, 2009 at 1:07 PM, Ben Goodger (Google) b...@chromium.org wrote: We will not duplicate strings for any other reason unless they refer to a concept that does not exist on the relevant platform. The idea is that we should have a single set of string content (independent of casing) that documentation can refer to. To be clear, that means splitting along platform conventions for stuff like Preferences vs Options is out? (Don't have a strong opinion, just curious.) -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Crashes due to 25633
One of the things I've done is to *find* all of our changes and try to separate them out from one another, so that should help. (I've created a set of patch files which contain all the changes compared to vanilla 3.6.18.) Some of our changes had been sent upstream already, and of those, some have now been merged. I don't know much about exactly why we have all the changes we do though, so I'm not really the best one to make a case for them in sending them upstream. Hopefully we can track down the authors of these patches though, and ask them to push them upstream. --Mike On Wed, Sep 16, 2009 at 1:21 PM, spotrh spo...@gmail.com wrote: On 09/16/2009 04:07 PM, Mike Mammarella wrote: FYI, I'm almost finished updating our (locally patched) SQLite to version 3.6.18 instead of 3.6.1 that we have now; apparently 3.6.18 handles corruption much better than 3.6.1 does. (I am holding off checking it in until I can run it through all the tests I can find to make sure something won't break, but other than that it's ready.) I don't know what effect it might have on this issue, but hopefully it will be a good effect... This is good news, but FWIW, this is also a big reason why forking from established upstreams can lead to headaches. Is there any chance of reworking the chromium specific sqlite changes into something that upstream might merge? ~spot --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] building with make / 64-bit in the face of recent gyp changes
If you're getting errors like NameError: name 'javascript_engine' Then you need to adjust how you build. 1) You can't pass flags to gyp anymore. Instead export GYP_GENERATORS='make' export GYP_DEFINES='target_arch=x64' 2) You must run this other gyp_chromium from exactly the directory above chrome/src: python ./src/build/gyp_chromium Some of these may be bugs, dunno, but that will at least get you working again. --~--~-~--~~~---~--~~ 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: Crashes due to 25633
On Wed, Sep 16, 2009 at 1:07 PM, Mike Mammarella m...@chromium.org wrote: On Wed, Sep 16, 2009 at 12:59 PM, Evan Martin e...@chromium.org wrote: On Wed, Sep 16, 2009 at 12:44 PM, spotrh spo...@gmail.com wrote: On 09/16/2009 02:23 PM, Evan Martin wrote: What is the error message? I wonder if there is something Linux-specific where we're getting an error code that is harmless. (We've had a lot of that in code that checks errno where the value differs between Linux and OS X.) User says it reports: [5070:5093:8302515214:FATAL:/mnt/chromium/rpmbuild/BUILD/chromium-20090910svn25958/src/chrome/common/sqlite_utils.cc(52)] Check failed: false. sqlite fatal error 11 Hm, that doesn't sound good! #define SQLITE_CORRUPT 11 /* The database disk image is malformed */ FYI, I'm almost finished updating our (locally patched) SQLite to version 3.6.18 instead of 3.6.1 that we have now; apparently 3.6.18 handles corruption much better than 3.6.1 does. (I am holding off checking it in until I can run it through all the tests I can find to make sure something won't break, but other than that it's ready.) I don't know what effect it might have on this issue, but hopefully it will be a good effect... To be clear, newer SQLite handles corruption much better in the sense that it detects it and throws SQLITE_CORRUPT in cases which previous code did not detect. In general, if the older code throws SQLITE_CORRUPT, the newer code will also throw SQLITE_CORRUPT. -scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Verdict: Menu string casing
Preferences vs Options is one such exception. Quit vs. Exit is another. Let me know if there are others. -Ben On Wed, Sep 16, 2009 at 1:20 PM, Evan Martin e...@chromium.org wrote: On Wed, Sep 16, 2009 at 1:07 PM, Ben Goodger (Google) b...@chromium.org wrote: We will not duplicate strings for any other reason unless they refer to a concept that does not exist on the relevant platform. The idea is that we should have a single set of string content (independent of casing) that documentation can refer to. To be clear, that means splitting along platform conventions for stuff like Preferences vs Options is out? (Don't have a strong opinion, just curious.) --~--~-~--~~~---~--~~ 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: Chrome Library for tweaking Windows Network Settings
Pawel's suggestion is a good way. We already do this in the existing test suites (for example, search for RuleBasedHostResolverProc in http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/in_process_browser_test.cc) So you should be able to just call methods on RuleBasedHostResolverProc (see src/net/base/mock_host_resolver.h): AddRuleWithLatency(host_pattern, replacement, latency) AllowDirectLookup(host) AddSimulatedFailure(host) AddIPv6Rule(host, ipv6_literal) On Wed, Sep 16, 2009 at 11:21 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: You can mock the HostResolver to make it fail to resolve anything (possibly except localhost). For examples, see HostResolver's unit tests and possibly other places where it is used. You can also make it fail to resolve specific hosts, which should also be handy. On Tue, Sep 15, 2009 at 13:54, TJ Shah tejass...@chromium.org wrote: Hi, I am trying to automate few test cases that requires me to simulate certain scenarios like 'Network is down' or 'Sync server not reachable' etc.. I am not sure about the Chrome Library that I can use to play with Windows Network Settings. I am using InProcBrowser Test. Pointers to library or examples will be helpful... -- Thanks, Tejas --~--~-~--~~~---~--~~ 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: building with make / 64-bit in the face of recent gyp changes
On Wed, Sep 16, 2009 at 1:36 PM, Evan Martin e...@chromium.org wrote: If you're getting errors like NameError: name 'javascript_engine' Then you need to adjust how you build. 1) You can't pass flags to gyp anymore. Instead export GYP_GENERATORS='make' export GYP_DEFINES='target_arch=x64' 2) You must run this other gyp_chromium from exactly the directory above chrome/src: python ./src/build/gyp_chromium NOTE: there is *another* gyp_chromium in a different directory that will cause the original failure. Be sure you're using exactly the above command line. Some of these may be bugs, dunno, but that will at least get you working again. --~--~-~--~~~---~--~~ 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: Verdict: Menu string casing
Sentence case is terrible. Can't understand why Vista HIG would choose that. After all, why use Sentence case on all these things that are *not* sentences? Definitely should use Title Case, even for Windows. After all, they are titles! On Sep 16, 1:27 pm, Ben Goodger (Google) b...@chromium.org wrote: Preferences vs Options is one such exception. Quit vs. Exit is another. Let me know if there are others. -Ben On Wed, Sep 16, 2009 at 1:20 PM, Evan Martin e...@chromium.org wrote: On Wed, Sep 16, 2009 at 1:07 PM, Ben Goodger (Google) b...@chromium.org wrote: We will not duplicate strings for any other reason unless they refer to a concept that does not exist on the relevant platform. The idea is that we should have a single set of string content (independent of casing) that documentation can refer to. To be clear, that means splitting along platform conventions for stuff like Preferences vs Options is out? (Don't have a strong opinion, just curious.) --~--~-~--~~~---~--~~ 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: Verdict: Menu string casing
On Wed, Sep 16, 2009 at 2:30 PM, krtulmay krtul...@gmail.com wrote: Sentence case is terrible. Can't understand why Vista HIG would choose that. After all, why use Sentence case on all these things that are *not* sentences? Definitely should use Title Case, even for Windows. After all, they are titles! We decided this long ago. Nothing has changed since then. In particular, I don't understand the HIG, therefore we should break it is not sufficient motivation. There needs to be compelling user benefit, which Title Case does not provide. 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: Enabling --disable-hang-monitor for new windows when Chrome is already running
Okay, finally got around to starting this discussion on mozilla plugin-futures. - Mike On Fri, Sep 11, 2009 at 4:53 PM, John Abd-El-Malek j...@chromium.org wrote: On Fri, Sep 11, 2009 at 4:52 PM, Mike Morearty m...@morearty.com wrote: So, since Flash is installed by means other than as part of an Extension, does that mean that John Tamplin's suggestion of giving permissions via manifest.json won't work for me? I take it manifest.json is something that only applies to extensions, and not to the other methods of installing a plugin. right On the other hand, it seems to me that since (as far as I know) plugins are native code that can do whatever they want, there is no need for giving a plugin special permission to use the new NPN API -- just grant that permission to all plugins. Native plugins can already do just about anything, including read/write access to the filesystem and the Internet, so it doesn't seem necessary for them to need special permission to access this API. agreed On Fri, Sep 11, 2009 at 4:30 PM, John Abd-El-Malek j...@chromium.orgwrote: On Fri, Sep 11, 2009 at 4:03 PM, Mike Morearty m...@morearty.comwrote: On Fri, Sep 11, 2009 at 3:44 PM, John Tamplin j...@google.com wrote: On Fri, Sep 11, 2009 at 6:38 PM, John Abd-El-Malek j...@chromium.orgwrote: I presume you're referring to Chrome extensions? I don't see the advantage of making this depend on the plugin being distributed via extensions. How else would an end-user get a plugin installed for Chrome? I don't think you want to tell them to go create a directory if it doesn't exist, and copy the file there, and you don't want to have to write a platform-specific installer to do that either. I don't know quite how the Flash player got into my Chrome, but all I know is, it's there. Although I don't know for sure, I sort of suspect that when Chrome installed, it looked for either (a) all existing Netscape plugins, or (b) just Flash, and enabled it. We crawled the disk/registry for pointers to NPAPI plugins, using the same algorithm that other NPAPI browsers use. You probably already had the plugin from when you used Firefox. If you didn't, we have a plugin installer UI that, once given permission, would download and install it. As far as I know, we (Adobe) don't have any special Chrome extension for installing Flash player. We just have the ActiveX version and the Netscape plugin version. --~--~-~--~~~---~--~~ 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: Verdict: Menu string casing
On Wed, Sep 16, 2009 at 2:30 PM, krtulmay krtul...@gmail.com wrote: Sentence case is terrible. Can't understand why Vista HIG would choose that. After all, why use Sentence case on all these things that are *not* sentences? Definitely should use Title Case, even for Windows. After all, they are titles! Title Case is terrible. Can't understand why Mac would choose that. After all, why use Title Case on all things that are *not* titles ? Definitely should use Sentence case, even for Mac. After all they are sentences ! Personally I find Tile Case unreadable and I despise it. Then again I'm French. Besides, I like my bike shed yellow. Antoine On Sep 16, 1:27 pm, Ben Goodger (Google) b...@chromium.org wrote: Preferences vs Options is one such exception. Quit vs. Exit is another. Let me know if there are others. -Ben On Wed, Sep 16, 2009 at 1:20 PM, Evan Martin e...@chromium.org wrote: On Wed, Sep 16, 2009 at 1:07 PM, Ben Goodger (Google) b...@chromium.org wrote: We will not duplicate strings for any other reason unless they refer to a concept that does not exist on the relevant platform. The idea is that we should have a single set of string content (independent of casing) that documentation can refer to. To be clear, that means splitting along platform conventions for stuff like Preferences vs Options is out? (Don't have a strong opinion, just curious.) --~--~-~--~~~---~--~~ 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: Verdict: Menu string casing
Title Case is terrible. Can't understand why Mac would choose that. After all, why use Title Case on all things that are *not* titles ? Definitely should use Sentence case, even for Mac. After all they are sentences ! Personally I find Tile Case unreadable and I despise it. Then again I'm French. Besides, I like my bike shed yellow. *shudder* I can't stand a bike shed that isn't custard. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] parasite is awesome
Looks like a good candidate for LinuxDebugging wiki page. On Wed, Sep 16, 2009 at 17:04, Evan Martin e...@chromium.org wrote: http://chipx86.github.com/gtkparasite/ We had looked into using parasite back in the early days, but I forgot about it due to 32/64-bit stuff. But now that we've grown up it's trivial to build. If you're within the Google network you can scp bunny.sfo:/usr/lib/gtk-2.0/modules/libgtkparasite.so /tmp sudo cp /tmp/libgtkparasite.so /usr/lib/gtk-2.0/modules/libgtkparasite.so and then GTK_MODULES=gtkparasite ./out/Debug/chrome And it'll just work. Pretty awesome! --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] parasite is awesome
Good idea -- I took over http://code.google.com/p/chromium/wiki/LinuxDebuggingGtk and moved the old contents to a page on building a debug version of gtk. (That older one really needs some cleanup...) On Wed, Sep 16, 2009 at 5:07 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Looks like a good candidate for LinuxDebugging wiki page. On Wed, Sep 16, 2009 at 17:04, Evan Martin e...@chromium.org wrote: http://chipx86.github.com/gtkparasite/ We had looked into using parasite back in the early days, but I forgot about it due to 32/64-bit stuff. But now that we've grown up it's trivial to build. If you're within the Google network you can scp bunny.sfo:/usr/lib/gtk-2.0/modules/libgtkparasite.so /tmp sudo cp /tmp/libgtkparasite.so /usr/lib/gtk-2.0/modules/libgtkparasite.so and then GTK_MODULES=gtkparasite ./out/Debug/chrome And it'll just work. Pretty awesome! --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] parasite is awesome
Will there be t-shirts? Yes, I think that's something we just have to do. Out of curiosity, could this be integrated in our testing framework to have less-flaky UI tests (at least for some subset of the functionality currently tested with UI tests)? -Ian 2009/9/16 Evan Martin e...@chromium.org Good idea -- I took over http://code.google.com/p/chromium/wiki/LinuxDebuggingGtk and moved the old contents to a page on building a debug version of gtk. (That older one really needs some cleanup...) On Wed, Sep 16, 2009 at 5:07 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Looks like a good candidate for LinuxDebugging wiki page. On Wed, Sep 16, 2009 at 17:04, Evan Martin e...@chromium.org wrote: http://chipx86.github.com/gtkparasite/ We had looked into using parasite back in the early days, but I forgot about it due to 32/64-bit stuff. But now that we've grown up it's trivial to build. If you're within the Google network you can scp bunny.sfo:/usr/lib/gtk-2.0/modules/libgtkparasite.so /tmp sudo cp /tmp/libgtkparasite.so /usr/lib/gtk-2.0/modules/libgtkparasite.so and then GTK_MODULES=gtkparasite ./out/Debug/chrome And it'll just work. Pretty awesome! --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [chromium] Basic printing support on Linux landed in revision 26400.
Basic printing support is now available with the --enable-printing flag. There is no support for page preview, adjusting the margins, editing the header/footer, etc. If you have bug reports, please file them, but be sure to a href=http://code.google.com/p/chromium/issues/list? can=2q=label:Printin g# search existing issues/a first, because we know a lot of features are missing and there are still some bugs unresolved. I would like to thank Tony Chang, Marc-Antoine Ruel, Evan Stade, Adam Langley, Evan Martin, and Markus Gutschke helped me make this happen this summer. Min-Yu Huang --~--~-~--~~~---~--~~ 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: Verdict: Menu string casing
Title Case is terrible. Can't understand why Mac would choose that. After all, why use Title Case on all things that are *not* titles ? Definitely should use Sentence case, even for Mac. After all they are sentences ! Personally I find Tile Case unreadable and I despise it. +1. We should also turn them into real sentences, too. Do something that touches the file system.-Write HTML and images of the current webpages to disk (or other writable permanent storage mediums (that you have write permissions for)). is so much clearer than File-Save. And it makes it obvious that we should use sentence case. Nico --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] parasite is awesome
On Wed, Sep 16, 2009 at 17:22, Ian Fette i...@chromium.org wrote: Out of curiosity, could this be integrated in our testing framework to have less-flaky UI tests (at least for some subset of the functionality currently tested with UI tests)? I don't have idea how to use it for that purpose. I can certainly imagine a parasite which would make the tests more flaky though... ;-) The problem with UI tests is that the flakiness isn't really so much tied to the UI part. They are just big tests, and the main problem is waiting properly for events, and ensuring that the test is deterministic (Valgrind, Purify). Maybe the Parasite would be useful for things like dragging tabs, etc. - I'm not familiar enough with the tool to tell. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] parasite is awesome
If you set the name of a GtkWidget using gtk_widget_set_name, it shows that name in the Parasite tree. That makes it easier to find things (see screenshot), so don't be afraid to add 'em. On Wed, Sep 16, 2009 at 5:04 PM, Evan Martin e...@chromium.org wrote: http://chipx86.github.com/gtkparasite/ We had looked into using parasite back in the early days, but I forgot about it due to 32/64-bit stuff. But now that we've grown up it's trivial to build. If you're within the Google network you can scp bunny.sfo:/usr/lib/gtk-2.0/modules/libgtkparasite.so /tmp sudo cp /tmp/libgtkparasite.so /usr/lib/gtk-2.0/modules/libgtkparasite.so and then GTK_MODULES=gtkparasite ./out/Debug/chrome And it'll just work. Pretty awesome! --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~--- attachment: parasite.png
[chromium-dev] Re: [linux] parasite is awesome
On Wed, Sep 16, 2009 at 5:37 PM, Evan Martin e...@chromium.org wrote: If you set the name of a GtkWidget using gtk_widget_set_name, it shows that name in the Parasite tree. That makes it easier to find things (see screenshot), so don't be afraid to add 'em. caveat: I think this should be integrated with the system we already have for tagging GtkWidgets, namely ViewID---so don't go all willy-nilly with naming them just yet. I will file a bug on myself to make ViewID be useful for parasite. On Wed, Sep 16, 2009 at 5:04 PM, Evan Martin e...@chromium.org wrote: http://chipx86.github.com/gtkparasite/ We had looked into using parasite back in the early days, but I forgot about it due to 32/64-bit stuff. But now that we've grown up it's trivial to build. If you're within the Google network you can scp bunny.sfo:/usr/lib/gtk-2.0/modules/libgtkparasite.so /tmp sudo cp /tmp/libgtkparasite.so /usr/lib/gtk-2.0/modules/libgtkparasite.so and then GTK_MODULES=gtkparasite ./out/Debug/chrome And it'll just work. Pretty awesome! --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Is there any good tool on Linux to browser and cross reference chromium source code?
kdevelop is pretty good, if you just set the include path correctly it will index the code for you and let you jump to symbols. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Valgrind + 64bit binaries
Hello, While attempting to run x64 unit_tests under valgrind I am hitting an error: vex: priv/guest_amd64_toIR.c:14600 (disInstr_AMD64_WRK): Assertion `sz == 2 || sz == 4' failed. vex storage: T total 4600074960 bytes allocated vex storage: P total 816 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). ==25306==at 0x3802ADC4: report_and_quit (m_libcassert.c:145) ==25306==by 0x3802AE29: panic (m_libcassert.c:227) ==25306==by 0x3802AEA2: vgPlain_core_panic_at (m_libcassert.c:232) ==25306==by 0x3802AEC1: vgPlain_core_panic (m_libcassert.c:237) ==25306==by 0x380433F2: failure_exit (m_translate.c:674) ==25306==by 0x380B2AE8: vex_assert_fail (main_util.c:220) ==25306==by 0x38117CCE: disInstr_AMD64_WRK (guest_amd64_toIR.c:14600) ==25306==by 0x3811BB42: disInstr_AMD64 (guest_amd64_toIR.c:16116) ==25306==by 0x380C0BA1: bb_to_IR (guest_generic_bb_to_IR.c:229) ==25306==by 0x380B135C: LibVEX_Translate (main_main.c:420) ==25306==by 0x380410B5: vgPlain_translate (m_translate.c:1517) ==25306==by 0x38062F68: vgPlain_scheduler (scheduler.c:844) ==25306==by 0x3808AF74: run_a_thread_NORETURN (syswrap-linux.c:91) Has anyone had success valgrinding 64bit binaries? Cheers, Joel --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Is there any good tool on Linux to browser and cross reference chromium source code?
I just found DXR http://dxr.proximity.on.ca/dxr/index.html, which is awesome. Might be worth to have a try. Regards James Su 2009/9/17 Evan Martin e...@chromium.org I'd like to set up a web-based code browser on chromium.org, but I played around with a couple and wasn't too happy with any of them. Suggestions are welcome. On Tue, Sep 15, 2009 at 9:19 PM, James Su su...@chromium.org wrote: Hi, I'm currently using cscope + vim, but it's so slow and hard to use. Is there any better choice? Regards James Su --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
