[chromium-dev] Fwd: converting the Linux build to gyp
The Linux build is ready to convert from Hammer to gyp.
I'm planning to close the tree for the conversion late some night, mainly to
coordinate the buildbot pieces with the other CLs (and to avoid interference
with other work, and vice versa, if things need rolling back). If closing
the tree to do this late tomorrow night (Wednesday 25 March) or Thursday
night would case you hardship, let me know.
If you don't develop on Linux, the only visible change *should* be that,
once this is complete, you will no longer need to update SCons files by
hand. In fact, the checked-in SCons files will disappear from the tree
completely, in favor of just updating .gyp files.
If you do develop on Linux (using the SCons build), most things should
behave more or less the same, module the following visible changes:
- icu38 data is compiled in, no icudt38l.dat in the build directory.
- You'll need to run gyp to re-generate SCons config files after changing
any .gyp configuration. On checkout, this will be handled for you by a
gclient hook.
- The default output directory will now be called Debug, not Hammer (to
match the other platforms).
- The mode= option will let you specify building Debug or Release, too
(or both: hammer --mode=Debug,Release). I
- You'll be able to build in a separate output directory using an
autoconf-like --srcdir option:: hammer
--srcdir='/path/to/chrome/trunk/src/{build,base,chrome,etc.}
- Since we won't actually be using the Hammer infrastucture anymore, it
will also build with any installed SCons, provided you pass in the right
--site-dir option so that it finds the trunk/src/site_scons directory. (The
hammer wrapper script will stick around, for at least the short term,
since it wraps up that logic.)
I'm working on getting pieces ready to update the wiki build instructions
and other stuff and will obviously send out an announcement once things have
been converted.
If any of the above poses a problem, or you have any suggestions or
requests, let me know.
--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: Does JSONStringValueSerializer expect UTF8?
Yes, it assumes the input is utf-8. From src/base/json_reader.h: // Known limitations/deviations from the RFC: // - Assumes input is encoded as UTF8. The spec says we should allow UTF-16 // (BE or LE) and UTF-32 (BE or LE) as well. On Tue, 24 Mar 2009, Book'em Dano wrote: Awesome. Thanks PK and SC for your prompt replies. I was unaware that snipgeneral pattern in the code is that narrow strings are UTF-8/ snip. Good to know. On Mar 24, 9:30 pm, Peter Kasting pkast...@chromium.org wrote: On Tue, Mar 24, 2009 at 8:57 PM, Book'em Dano daniel.c...@gmail.com wrote: Hi guys, I notice that JSONStringValueSerializer in chrome\common takes a narrow string. It expects a UTF8 encoded string, right (i.e. it doesn't have to be ASCII only)? The general pattern in the code is that narrow strings are UTF-8 unless explicitly commented some other way (with ASCII usually being that commented exception). So I would expect that yes, this takes UTF-8. 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: src/media/
Hi peng! I'm one of the programmers working on that code. You can see how it's used by looking at the renderer process: /src/renderer/webmediaplayer_delegate_impl.cc /src/renderer/media/audio_renderer_impl.cc /src/renderer/media/data_source_impl.cc /src/renderer/media/video_renderer_impl.cc We're working on making a test application available that shows how to use /src/media outside of Chrome. /src/media is still under development, so things are still changing. Andrew On Wed, Mar 25, 2009 at 2:12 AM, peng peng.chengy...@gmail.com wrote: Hi how to to use src/media/ ? It is very useful ! peng --~--~-~--~~~---~--~~ 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: src/media/
Hi Andrew Thanks for your info. Yes, it is very valuable if we know how to use /src/media OUTSIDE Chrome because it uses ffmpeg. Look forward to this! peng --~--~-~--~~~---~--~~ 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: porting chrome_process_filter
Thanks for all your comments. Actually chrome_process_filter is only used by tests to enumerate chrome processes. So I plan to add a chrome_process_enumerator in chrome/test and remove chrome/common/chrome_process_filter. --~--~-~--~~~---~--~~ 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: You might need to clobber your Linux client
If you see this error, the correct thing to do is run hammer with --implicit-deps-changed. By default scons caches dependencies to speed up builds. When some dependencies change, scons doesn't know about it. This doesn't impact the builders because they always build with --implicit-deps-changed. On Wed, 25 Mar 2009, Dan Kegel wrote: Both my Linux clients were getting the build error scons: *** [Hammer/dbg/grit_derived_sources/grit/browser_resources.h] Implicit dependency `browser/resources/extensions.html' not found, needed by target `Hammer/dbg/grit_derived_sources/browser_resources.rc'. Deleting Hammer seemed to fix it. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Last Known Good Revision
Just to be clear, it's really the last known good revision for the try server, so it's the thinest definition of lkgr you can ever find. It only checks for unit_tests to pass and nothing else, in debug on windows, linux and mac. http://build.chromium.org/buildbot/continuous/LATEST/REVISION is a much better reference for now (albeit for the windows version only). It is being reworked to have that sorted by platforms so linux and mac LASTEST will be there too very soon. M-A On Wed, Mar 25, 2009 at 12:18 PM, Marc-Andre Decoste m...@chromium.org wrote: Salut Chromium-Dev'ers, if you are not interested in knowing about the last revisions that successfully built, you can stop reading here (or you could actually go on if you are curious because this email isn't that long anyway :-). We just added a new builder status receiver to the build bot so that we can post the revision number when a build succeeds all the way to the unit test on all platforms (win, mac and linux). You can access the latest good revision from this URL: http://chromium-status.appspot.com/lkgr, which simply returns the revision number (so you could easily use it in a script automating your local build with the Last Known Good Revision). You can also access the list of the last known good revisions here: http://chromium-status.appspot.com/revisions. We will soon start using the LKGR number on the try servers to make sure that the patches you try are not affected by a failing HEAD build. Enjoy! BYE MAD --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Last Known Good Revision
Salut Chromium-Dev'ers, if you are not interested in knowing about the last revisions that successfully built, you can stop reading here (or you could actually go on if you are curious because this email isn't that long anyway :-). We just added a new builder status receiver to the build bot so that we can post the revision number when a build succeeds all the way to the unit test on all platforms (win, mac and linux). You can access the latest good revision from this URL: http://chromium-status.appspot.com/lkgr, which simply returns the revision number (so you could easily use it in a script automating your local build with the Last Known Good Revision). You can also access the list of the last known good revisions here: http://chromium-status.appspot.com/revisions. We will soon start using the LKGR number on the try servers to make sure that the patches you try are not affected by a failing HEAD build. Enjoy! BYE MAD --~--~-~--~~~---~--~~ 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: Including Droid font in Chrome?
MSFT did a new set of fonts to take specific advantage of ClearType: http://www.microsoft.com/typography/ClearTypeFonts.mspx The Core Fonts are still available and installed by default on all windows versions that I can find information on, but they were designed for a simpler time when sub-pixel hinting was still rare. I'm not sure that implies that we should do anything in particular WRT Droid, though. Regards On Wed, Mar 25, 2009 at 8:17 AM, Evan Martin e...@chromium.org wrote: On Tue, Mar 24, 2009 at 9:49 PM, Alex Russell slightly...@google.com wrote: A potential plus is that we could (finally?) count on having at least one consistent font between platforms. I'm not sure that's an un-adulterated Good Thing (TM), but I can imagine wanting a uniform main body font that's not whatever junk Windows or Linux default to. These days you can more or less rely on the Microsoft core web fonts on Windows/Linux. (Arial, Verdana, Georgia, etc. but notably not Tahoma.) I think our test shell even fails to start if you don't have them install. Dunno about Macs. I also dunno if that qualifies as junk, but they are what the current web uses. http://corefonts.sourceforge.net/ --~--~-~--~~~---~--~~ 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: Last Known Good Revision
working on it. On Wed, Mar 25, 2009 at 10:00 AM, Patrick Johnson patr...@chromium.org wrote: Nice! Can we add an option to gclient to make it automatically sync to the last known good revision? Patrick On Wed, Mar 25, 2009 at 9:18 AM, Marc-Andre Decoste m...@chromium.org wrote: Salut Chromium-Dev'ers, if you are not interested in knowing about the last revisions that successfully built, you can stop reading here (or you could actually go on if you are curious because this email isn't that long anyway :-). We just added a new builder status receiver to the build bot so that we can post the revision number when a build succeeds all the way to the unit test on all platforms (win, mac and linux). You can access the latest good revision from this URL: http://chromium-status.appspot.com/lkgr, which simply returns the revision number (so you could easily use it in a script automating your local build with the Last Known Good Revision). You can also access the list of the last known good revisions here: http://chromium-status.appspot.com/revisions. We will soon start using the LKGR number on the try servers to make sure that the patches you try are not affected by a failing HEAD build. Enjoy! BYE MAD --~--~-~--~~~---~--~~ 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: Last Known Good Revision
That should not be to hard: LKGR = 'http://build.chromium.org/buildbot/continuous/LATEST/REVISION' revision_arg = '--revision=...@%s' % int(urllib.urlopen(LKGR).read()) Needs a bit of error handling, but it should be easy to put in gclient.py, optionally with a feature to allow you to specify the URL of the page that has the revision number. Berend-Jan SkyLined Wever (skyli...@google.com) - Security Software Engineer Google NL B.V. Reg: C. Debussylaan 34, 15th floor 1082 MD A'dam 34198589 NL VAT / Tax ID:- 812788515 B01 On Wed, Mar 25, 2009 at 18:00, Patrick Johnson patr...@chromium.org wrote: Nice! Can we add an option to gclient to make it automatically sync to the last known good revision? Patrick On Wed, Mar 25, 2009 at 9:18 AM, Marc-Andre Decoste m...@chromium.orgwrote: Salut Chromium-Dev'ers, if you are not interested in knowing about the last revisions that successfully built, you can stop reading here (or you could actually go on if you are curious because this email isn't that long anyway :-). We just added a new builder status receiver to the build bot so that we can post the revision number when a build succeeds all the way to the unit test on all platforms (win, mac and linux). You can access the latest good revision from this URL: http://chromium-status.appspot.com/lkgr, which simply returns the revision number (so you could easily use it in a script automating your local build with the Last Known Good Revision). You can also access the list of the last known good revisions here: http://chromium-status.appspot.com/revisions. We will soon start using the LKGR number on the try servers to make sure that the patches you try are not affected by a failing HEAD build. Enjoy! BYE MAD --~--~-~--~~~---~--~~ 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: Including Droid font in Chrome?
On Wed, Mar 25, 2009 at 10:16 AM, Alex Russell slightly...@google.com wrote: MSFT did a new set of fonts to take specific advantage of ClearType: http://www.microsoft.com/typography/ClearTypeFonts.mspx The Core Fonts are still available and installed by default on all windows versions that I can find information on, but they were designed for a simpler time when sub-pixel hinting was still rare. I'm not sure that implies that we should do anything in particular WRT Droid, though. I have them on my Windows box. They are nice fonts, but I think they are optimized for the antialiasing algorithm on Andorid: I don't find that they look quite as good on Windows using ClearType. For a while, I was interested in including their fallback font which we could use to guarantee that glyphs are available for most characters. But (I assume) for space reasons on the phone, this font is not hinted, so looks pretty ugly. 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: [chrome-team] Design-Doc: Automatic Spelling Correction
Hi Peter, I'll let Sid chime in on the details of the implementation, but it's definitely been designed to allow for other algorithms. If there's a better way to integrate it into Hunspell itself, that might be worth looking into. -Nick On Tue, Mar 24, 2009 at 10:54 PM, Peter Kasting pkast...@chromium.orgwrote: On Tue, Mar 24, 2009 at 10:16 PM, Nick Baum nickb...@chromium.org wrote: We want to start out with a very conservative approach so as to not be annoying. We considered using the hunspell suggestions, but we wanted something that captured one particular, common type of misspelling. However, I believe Sid has built it in a way that lets us test other algorithms, including using hunspell's algorithm. That's still pretty easy to do with this -- you make your distance oracle return 1 for two words that differ by a letter swap, and infinity for every other case. You get the same results but it becomes trivial to add anything else you want later. If you're saying you can accomplish the points I was shooting for by tweaking the existing mechanism, you are right; I am simply suggesting that this route will be cleaner, saner and more future-proof in the end. 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] Disabling This type of file can harm your computer
First of all, I'm using Chrome 2.0.171.0 I have been unable to find a way to disable the notification that comes up when downloading an EXE or MSI type file using Chromium. Is there a way of disabling this notification? I would like the files to begin downloading immediately. If there is no way of disabling this, I find that extremely annoying. There needs to be options for the little things like this for power/ technical users. There is a bug report on this here: http://code.google.com/p/chromium/issues/detail?id=7016 --~--~-~--~~~---~--~~ 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: Disabling This type of file can harm your computer
It's important to have this discussion, but we should be having it in the bug tracker instead of on chromium-dev. Thanks, Adam On Wed, Mar 25, 2009 at 11:22 AM, Robert Dailey rcdai...@gmail.com wrote: First of all, I'm using Chrome 2.0.171.0 I have been unable to find a way to disable the notification that comes up when downloading an EXE or MSI type file using Chromium. Is there a way of disabling this notification? I would like the files to begin downloading immediately. If there is no way of disabling this, I find that extremely annoying. There needs to be options for the little things like this for power/ technical users. There is a bug report on this here: http://code.google.com/p/chromium/issues/detail?id=7016 --~--~-~--~~~---~--~~ 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: ScrollBar Implementation
There are different kinds of scrollbar supported by views... that native scrollbar and the bitmap scrollbar. bitmap scrollbar isn't used right now but likely will be again. ScrollBar is the base class of both NativeScrollbar and Bitmapscrollbar. Scrollview has a ScrollBar* so it doesn't have to care about the particular implementation. -Ben On Tue, Mar 24, 2009 at 6:36 PM, Mohamed Mansour m0.interact...@gmail.com wrote: Hi chromium, I cc'd Ben cause he seems to be working on UI on chrome alot :x Sorry Ben! I am working on a feature http://code.google.com/p/chromium/issues/detail?id=7231 which requires context menu support for Chromium scroll bars. While searching the code I have come up with these classes: - NativeScrollBar - ScrollBar - ScrollView - BitmapScrollBar The context menu functionality should have the following (system wide in windows, every window that has scrollbar, has that context menu) Horizontal: 1) Scroll Here 2) Left Edge 3) Right Edge 4) Page Left 5) Page Right 6) Scroll Left 7) Scroll Right Vertical: 1) Scroll Here 2) Top 3) Bottom 4) Page Up 5) Page Down 6) Scroll Up 7) Scroll Down So my question is as follows, Chromium uses ScrollView as its main scroll bar. It doesn't use NativeScrollBar, nor BitmapScrollBar. So why do those exist? Why do we have a ScrollBar class? Why can't we just use ScrollView and instead of passing in a ScrollBar, are we assuming Chromium will have *many* different types of scrollbars? Why are we not using native windows scrollbar support, since chromium is creating different views in every operating system, why not just use the standard windows components? There are many functionality within the scrollbar, how would you guys advice me to continue? Should I create a separate class called ScrollBarContextMenu and implement the horizontal and vertical context menu for scroll bars? There must be an easier way, to just use windows/gtk/mac controls for scrollbar support, instead of recreating it from scratch. Ideas? --~--~-~--~~~---~--~~ 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: ScrollBar Implementation
Do you recommend me to refactor the Context Menu code from BitmapScrollBar into ScrollBar so that both will have context menu implementations? Currently, the context menu is the page context menu that has reload, print, view page info, etc. Would that be the best approach fixing this feature bug. http://code.google.com/p/chromium/issues/detail?id=7231 -m0 On Wed, Mar 25, 2009 at 3:49 PM, Ben Goodger (Google) b...@chromium.org wrote: There are different kinds of scrollbar supported by views... that native scrollbar and the bitmap scrollbar. bitmap scrollbar isn't used right now but likely will be again. ScrollBar is the base class of both NativeScrollbar and Bitmapscrollbar. Scrollview has a ScrollBar* so it doesn't have to care about the particular implementation. -Ben On Tue, Mar 24, 2009 at 6:36 PM, Mohamed Mansour m0.interact...@gmail.com wrote: Hi chromium, I cc'd Ben cause he seems to be working on UI on chrome alot :x Sorry Ben! I am working on a feature http://code.google.com/p/chromium/issues/detail?id=7231 which requires context menu support for Chromium scroll bars. While searching the code I have come up with these classes: - NativeScrollBar - ScrollBar - ScrollView - BitmapScrollBar The context menu functionality should have the following (system wide in windows, every window that has scrollbar, has that context menu) Horizontal: 1) Scroll Here 2) Left Edge 3) Right Edge 4) Page Left 5) Page Right 6) Scroll Left 7) Scroll Right Vertical: 1) Scroll Here 2) Top 3) Bottom 4) Page Up 5) Page Down 6) Scroll Up 7) Scroll Down So my question is as follows, Chromium uses ScrollView as its main scroll bar. It doesn't use NativeScrollBar, nor BitmapScrollBar. So why do those exist? Why do we have a ScrollBar class? Why can't we just use ScrollView and instead of passing in a ScrollBar, are we assuming Chromium will have *many* different types of scrollbars? Why are we not using native windows scrollbar support, since chromium is creating different views in every operating system, why not just use the standard windows components? There are many functionality within the scrollbar, how would you guys advice me to continue? Should I create a separate class called ScrollBarContextMenu and implement the horizontal and vertical context menu for scroll bars? There must be an easier way, to just use windows/gtk/mac controls for scrollbar support, instead of recreating it from scratch. Ideas? --~--~-~--~~~---~--~~ 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: ScrollBar Implementation
No. What's not working? -Ben On Wed, Mar 25, 2009 at 12:54 PM, Mohamed Mansour m0.interact...@gmail.com wrote: Do you recommend me to refactor the Context Menu code from BitmapScrollBar into ScrollBar so that both will have context menu implementations? Currently, the context menu is the page context menu that has reload, print, view page info, etc. Would that be the best approach fixing this feature bug. http://code.google.com/p/chromium/issues/detail?id=7231 -m0 On Wed, Mar 25, 2009 at 3:49 PM, Ben Goodger (Google) b...@chromium.org wrote: There are different kinds of scrollbar supported by views... that native scrollbar and the bitmap scrollbar. bitmap scrollbar isn't used right now but likely will be again. ScrollBar is the base class of both NativeScrollbar and Bitmapscrollbar. Scrollview has a ScrollBar* so it doesn't have to care about the particular implementation. -Ben On Tue, Mar 24, 2009 at 6:36 PM, Mohamed Mansour m0.interact...@gmail.com wrote: Hi chromium, I cc'd Ben cause he seems to be working on UI on chrome alot :x Sorry Ben! I am working on a feature http://code.google.com/p/chromium/issues/detail?id=7231 which requires context menu support for Chromium scroll bars. While searching the code I have come up with these classes: - NativeScrollBar - ScrollBar - ScrollView - BitmapScrollBar The context menu functionality should have the following (system wide in windows, every window that has scrollbar, has that context menu) Horizontal: 1) Scroll Here 2) Left Edge 3) Right Edge 4) Page Left 5) Page Right 6) Scroll Left 7) Scroll Right Vertical: 1) Scroll Here 2) Top 3) Bottom 4) Page Up 5) Page Down 6) Scroll Up 7) Scroll Down So my question is as follows, Chromium uses ScrollView as its main scroll bar. It doesn't use NativeScrollBar, nor BitmapScrollBar. So why do those exist? Why do we have a ScrollBar class? Why can't we just use ScrollView and instead of passing in a ScrollBar, are we assuming Chromium will have *many* different types of scrollbars? Why are we not using native windows scrollbar support, since chromium is creating different views in every operating system, why not just use the standard windows components? There are many functionality within the scrollbar, how would you guys advice me to continue? Should I create a separate class called ScrollBarContextMenu and implement the horizontal and vertical context menu for scroll bars? There must be an easier way, to just use windows/gtk/mac controls for scrollbar support, instead of recreating it from scratch. Ideas? --~--~-~--~~~---~--~~ 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: ScrollBar Implementation
There is no context menu for the ScrollBar. -m0 On Wed, Mar 25, 2009 at 3:55 PM, Ben Goodger (Google) b...@chromium.org wrote: No. What's not working? -Ben On Wed, Mar 25, 2009 at 12:54 PM, Mohamed Mansour m0.interact...@gmail.com wrote: Do you recommend me to refactor the Context Menu code from BitmapScrollBar into ScrollBar so that both will have context menu implementations? Currently, the context menu is the page context menu that has reload, print, view page info, etc. Would that be the best approach fixing this feature bug. http://code.google.com/p/chromium/issues/detail?id=7231 -m0 On Wed, Mar 25, 2009 at 3:49 PM, Ben Goodger (Google) b...@chromium.org wrote: There are different kinds of scrollbar supported by views... that native scrollbar and the bitmap scrollbar. bitmap scrollbar isn't used right now but likely will be again. ScrollBar is the base class of both NativeScrollbar and Bitmapscrollbar. Scrollview has a ScrollBar* so it doesn't have to care about the particular implementation. -Ben On Tue, Mar 24, 2009 at 6:36 PM, Mohamed Mansour m0.interact...@gmail.com wrote: Hi chromium, I cc'd Ben cause he seems to be working on UI on chrome alot :x Sorry Ben! I am working on a feature http://code.google.com/p/chromium/issues/detail?id=7231 which requires context menu support for Chromium scroll bars. While searching the code I have come up with these classes: - NativeScrollBar - ScrollBar - ScrollView - BitmapScrollBar The context menu functionality should have the following (system wide in windows, every window that has scrollbar, has that context menu) Horizontal: 1) Scroll Here 2) Left Edge 3) Right Edge 4) Page Left 5) Page Right 6) Scroll Left 7) Scroll Right Vertical: 1) Scroll Here 2) Top 3) Bottom 4) Page Up 5) Page Down 6) Scroll Up 7) Scroll Down So my question is as follows, Chromium uses ScrollView as its main scroll bar. It doesn't use NativeScrollBar, nor BitmapScrollBar. So why do those exist? Why do we have a ScrollBar class? Why can't we just use ScrollView and instead of passing in a ScrollBar, are we assuming Chromium will have *many* different types of scrollbars? Why are we not using native windows scrollbar support, since chromium is creating different views in every operating system, why not just use the standard windows components? There are many functionality within the scrollbar, how would you guys advice me to continue? Should I create a separate class called ScrollBarContextMenu and implement the horizontal and vertical context menu for scroll bars? There must be an easier way, to just use windows/gtk/mac controls for scrollbar support, instead of recreating it from scratch. Ideas? --~--~-~--~~~---~--~~ 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: ScrollBar Implementation
As Peter said, the ScrollBar object is not responsible for drawing scroll bars on pages, which is what the bug is about. Brett On Wed, Mar 25, 2009 at 1:15 PM, Mohamed Mansour m0.interact...@gmail.com wrote: There is no context menu for the ScrollBar. -m0 On Wed, Mar 25, 2009 at 3:55 PM, Ben Goodger (Google) b...@chromium.org wrote: No. What's not working? -Ben On Wed, Mar 25, 2009 at 12:54 PM, Mohamed Mansour m0.interact...@gmail.com wrote: Do you recommend me to refactor the Context Menu code from BitmapScrollBar into ScrollBar so that both will have context menu implementations? Currently, the context menu is the page context menu that has reload, print, view page info, etc. Would that be the best approach fixing this feature bug. http://code.google.com/p/chromium/issues/detail?id=7231 -m0 On Wed, Mar 25, 2009 at 3:49 PM, Ben Goodger (Google) b...@chromium.org wrote: There are different kinds of scrollbar supported by views... that native scrollbar and the bitmap scrollbar. bitmap scrollbar isn't used right now but likely will be again. ScrollBar is the base class of both NativeScrollbar and Bitmapscrollbar. Scrollview has a ScrollBar* so it doesn't have to care about the particular implementation. -Ben On Tue, Mar 24, 2009 at 6:36 PM, Mohamed Mansour m0.interact...@gmail.com wrote: Hi chromium, I cc'd Ben cause he seems to be working on UI on chrome alot :x Sorry Ben! I am working on a feature http://code.google.com/p/chromium/issues/detail?id=7231 which requires context menu support for Chromium scroll bars. While searching the code I have come up with these classes: - NativeScrollBar - ScrollBar - ScrollView - BitmapScrollBar The context menu functionality should have the following (system wide in windows, every window that has scrollbar, has that context menu) Horizontal: 1) Scroll Here 2) Left Edge 3) Right Edge 4) Page Left 5) Page Right 6) Scroll Left 7) Scroll Right Vertical: 1) Scroll Here 2) Top 3) Bottom 4) Page Up 5) Page Down 6) Scroll Up 7) Scroll Down So my question is as follows, Chromium uses ScrollView as its main scroll bar. It doesn't use NativeScrollBar, nor BitmapScrollBar. So why do those exist? Why do we have a ScrollBar class? Why can't we just use ScrollView and instead of passing in a ScrollBar, are we assuming Chromium will have *many* different types of scrollbars? Why are we not using native windows scrollbar support, since chromium is creating different views in every operating system, why not just use the standard windows components? There are many functionality within the scrollbar, how would you guys advice me to continue? Should I create a separate class called ScrollBarContextMenu and implement the horizontal and vertical context menu for scroll bars? There must be an easier way, to just use windows/gtk/mac controls for scrollbar support, instead of recreating it from scratch. Ideas? --~--~-~--~~~---~--~~ 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: Last Known Good Revision
Yé! BJ is now fluent in Python! A month or two ago, that would have been written in JS... :) On Wed, Mar 25, 2009 at 1:18 PM, Berend-Jan Wever skyli...@chromium.org wrote: That should not be to hard: LKGR = 'http://build.chromium.org/buildbot/continuous/LATEST/REVISION' revision_arg = '--revision=...@%s' % int(urllib.urlopen(LKGR).read()) Needs a bit of error handling, but it should be easy to put in gclient.py, optionally with a feature to allow you to specify the URL of the page that has the revision number. Berend-Jan SkyLined Wever (skyli...@google.com) - Security Software Engineer Google NL B.V. Reg: C. Debussylaan 34, 15th floor 1082 MD A'dam 34198589 NL VAT / Tax ID:- 812788515 B01 On Wed, Mar 25, 2009 at 18:00, Patrick Johnson patr...@chromium.org wrote: Nice! Can we add an option to gclient to make it automatically sync to the last known good revision? Patrick On Wed, Mar 25, 2009 at 9:18 AM, Marc-Andre Decoste m...@chromium.org wrote: Salut Chromium-Dev'ers, if you are not interested in knowing about the last revisions that successfully built, you can stop reading here (or you could actually go on if you are curious because this email isn't that long anyway :-). We just added a new builder status receiver to the build bot so that we can post the revision number when a build succeeds all the way to the unit test on all platforms (win, mac and linux). You can access the latest good revision from this URL: http://chromium-status.appspot.com/lkgr, which simply returns the revision number (so you could easily use it in a script automating your local build with the Last Known Good Revision). You can also access the list of the last known good revisions here: http://chromium-status.appspot.com/revisions. We will soon start using the LKGR number on the try servers to make sure that the patches you try are not affected by a failing HEAD build. Enjoy! BYE MAD --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Recent refactoring of widget creation code
In re to http://codereview.chromium.org/48103/show: I like where you went, but this leaves me in a tough spot. I was implementing them in http://codereview.chromium.org/45040/show and now I'm a bit stuck. RWHV lives inside a view, and self-destructs when it's removed from the view. Its lifetime is entirely due to the view and while it knows about its host, it's not actually owned by it (see ShutdownHost()). In your new revision, CreateNewWidgetInternal creates a new widget, which is only parented in a view during the call to InitAsPopup in ShowCreatedWidgetInternal. Between those two calls the widget lives in some kind of cache, outside a view. During construction of RenderWidgetHostViewMac, I had to split it into two, the C++ side and the ObjC side. Given the lifetime semantics, I chose to have the ObjC class have strict ownership of the C++ class. Then the ObjC class would have view lifetime. WebContentsViewMac honors that; it creates the RWHVM and immediately embeds it. With your new scheme, I'm stuck. Whoever calls CreateNewWidgetInternal will try to keep the RWHV around, but it can't. Since it wasn't hosted in the view system, it'll immediately self-destruct. I'm not sure of a great way around this. CreateNewWidgetInternal might have to tell the RWHV that it's going to be embedded (and tell it where) rather than leaving that to ShowCreatedWidgetInternal... 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: Recent refactoring of widget creation code
Oh! CreateNewWidgetInternal is virtual! That's... useful. Avi On Wed, Mar 25, 2009 at 4:58 PM, Avi Drissman a...@chromium.org wrote: In re to http://codereview.chromium.org/48103/show: I like where you went, but this leaves me in a tough spot. I was implementing them in http://codereview.chromium.org/45040/show and now I'm a bit stuck. RWHV lives inside a view, and self-destructs when it's removed from the view. Its lifetime is entirely due to the view and while it knows about its host, it's not actually owned by it (see ShutdownHost()). In your new revision, CreateNewWidgetInternal creates a new widget, which is only parented in a view during the call to InitAsPopup in ShowCreatedWidgetInternal. Between those two calls the widget lives in some kind of cache, outside a view. During construction of RenderWidgetHostViewMac, I had to split it into two, the C++ side and the ObjC side. Given the lifetime semantics, I chose to have the ObjC class have strict ownership of the C++ class. Then the ObjC class would have view lifetime. WebContentsViewMac honors that; it creates the RWHVM and immediately embeds it. With your new scheme, I'm stuck. Whoever calls CreateNewWidgetInternal will try to keep the RWHV around, but it can't. Since it wasn't hosted in the view system, it'll immediately self-destruct. I'm not sure of a great way around this. CreateNewWidgetInternal might have to tell the RWHV that it's going to be embedded (and tell it where) rather than leaving that to ShowCreatedWidgetInternal... 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: Recent refactoring of widget creation code
I agree the popup lives in a strange state of limbo before InitAsPopup() is called, but this structure seems to be a side effect of the messages the renderer sends us. It didn't turn out to be much of a problem for linux/win, but if it is for mac then let me know and I'll try to help figure something out. (your last comment made it sound like you'd just override those functions?) -- Evan Stade On Wed, Mar 25, 2009 at 2:02 PM, Avi Drissman a...@chromium.org wrote: Oh! CreateNewWidgetInternal is virtual! That's... useful. Avi On Wed, Mar 25, 2009 at 4:58 PM, Avi Drissman a...@chromium.org wrote: In re to http://codereview.chromium.org/48103/show: I like where you went, but this leaves me in a tough spot. I was implementing them in http://codereview.chromium.org/45040/show and now I'm a bit stuck. RWHV lives inside a view, and self-destructs when it's removed from the view. Its lifetime is entirely due to the view and while it knows about its host, it's not actually owned by it (see ShutdownHost()). In your new revision, CreateNewWidgetInternal creates a new widget, which is only parented in a view during the call to InitAsPopup in ShowCreatedWidgetInternal. Between those two calls the widget lives in some kind of cache, outside a view. During construction of RenderWidgetHostViewMac, I had to split it into two, the C++ side and the ObjC side. Given the lifetime semantics, I chose to have the ObjC class have strict ownership of the C++ class. Then the ObjC class would have view lifetime. WebContentsViewMac honors that; it creates the RWHVM and immediately embeds it. With your new scheme, I'm stuck. Whoever calls CreateNewWidgetInternal will try to keep the RWHV around, but it can't. Since it wasn't hosted in the view system, it'll immediately self-destruct. I'm not sure of a great way around this. CreateNewWidgetInternal might have to tell the RWHV that it's going to be embedded (and tell it where) rather than leaving that to ShowCreatedWidgetInternal... 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: Recent refactoring of widget creation code
That should work. If I just override those functions and retain/release the view through it, we should be fine. avi On Wed, Mar 25, 2009 at 5:09 PM, Evan Stade est...@chromium.org wrote: I agree the popup lives in a strange state of limbo before InitAsPopup() is called, but this structure seems to be a side effect of the messages the renderer sends us. It didn't turn out to be much of a problem for linux/win, but if it is for mac then let me know and I'll try to help figure something out. (your last comment made it sound like you'd just override those functions?) -- Evan Stade On Wed, Mar 25, 2009 at 2:02 PM, Avi Drissman a...@chromium.org wrote: Oh! CreateNewWidgetInternal is virtual! That's... useful. Avi On Wed, Mar 25, 2009 at 4:58 PM, Avi Drissman a...@chromium.org wrote: In re to http://codereview.chromium.org/48103/show: I like where you went, but this leaves me in a tough spot. I was implementing them in http://codereview.chromium.org/45040/show and now I'm a bit stuck. RWHV lives inside a view, and self-destructs when it's removed from the view. Its lifetime is entirely due to the view and while it knows about its host, it's not actually owned by it (see ShutdownHost()). In your new revision, CreateNewWidgetInternal creates a new widget, which is only parented in a view during the call to InitAsPopup in ShowCreatedWidgetInternal. Between those two calls the widget lives in some kind of cache, outside a view. During construction of RenderWidgetHostViewMac, I had to split it into two, the C++ side and the ObjC side. Given the lifetime semantics, I chose to have the ObjC class have strict ownership of the C++ class. Then the ObjC class would have view lifetime. WebContentsViewMac honors that; it creates the RWHVM and immediately embeds it. With your new scheme, I'm stuck. Whoever calls CreateNewWidgetInternal will try to keep the RWHV around, but it can't. Since it wasn't hosted in the view system, it'll immediately self-destruct. I'm not sure of a great way around this. CreateNewWidgetInternal might have to tell the RWHV that it's going to be embedded (and tell it where) rather than leaving that to ShowCreatedWidgetInternal... 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] recent changes to webkit test list expectations
tests_ignored.txt and tests_fixable.txt no longer exist. They were merged into a single file: src/webkit/tools/layout_tests/test_expectations.txt. All the files that were previously ignored now have the WONTFIX metadata applied to them. WONTFIX means that we never intend to pass the test. WONTFIX WIN LINUX : /path/to/mac-specific/test = FAIL So, that says that this test fails on Windows and Linux and that we never intend to fix it on those platforms, presumably because it tests something mac specific. Please update your scripts appropriately. Ojan --~--~-~--~~~---~--~~ 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: layout tests and bug triaging
We could go with option 3 until someone is annoyed enough by the overhead to write a script. :) On Tue, Mar 24, 2009 at 4:19 PM, Ojan Vafai o...@google.com wrote: OK. So, what I'm hearing is that every test should have a bug assigned to it, no matter the priority. In that case, there's a couple other options. *Option 3* Get rid of DEFER and don't add priorities to the test list. Instead require that every test have an associated bug (multiple tests can share a bug) and rely on the bug priority/owner to figure out when the test needs fixing and who is responsible for fixing it. Pros: -Works with our current bug triage process (kind of) -Makes for one easy place that people need to look for their todo list (the google code issue tracker) Cons: -Overhead of filing and closing bugs when the common case is just a rebaseline anyways -Hard to triage layout tests without understanding what's wrong with them *Option 4* Same as option 3, except we have a script that monitors the test list and automatically files a bug whenever a new test appears. The subject of the test is just the path listed in the test list, so the test can be found by searching the issue tracker. Similarly, when a test is removed from the test list, the bug is automatically closed. This has the same pros and cons as option 3 except that it totally removes the overhead associated with having a bug for each test path. Also, this would require someone to write the script to do this. Ojan On Tue, Mar 24, 2009 at 12:31 PM, David Levin le...@google.com wrote: I like this proposal. I would also like a bugs for P3 which could explain why it is a P3. If is it an unimplemented feature, then all tests for that unimplemented feature could have the same bug. (Since I do merges and took a while to layout test file bugs from that) I like option 2. BUT I'm concerned that adding someone's email address to test_fixable will not get any attention. Right now, when you file a bug, people get email and the bugs seem to be followed up. BUGS/PRIORITY TRIAGING Option 1 Addition Pro Email sent about new bug alerts people to the new issue -- I suppose one could email people separately when adding their email address to test_fixable (but this step could easily be missed). Dave On Tue, Mar 24, 2009 at 12:14 PM, Marc-Andre Decoste m...@chromium.org wrote: I personally prefer having a bug assigned for the layout tests that we want to be fixed soon... It makes for a more consistent way of following up on our progress... Even if the end result is just a re-baseline, we also gain the link to the bug from the committed change list (and vice versa). And if we want some sort of dashboard for this, we could add a page on the chromium-status appEngine that would read from the latest version of the test list file, and maybe some details (e.g., owner) from the issue tracker... Maybe... ;-) BYE MAD On Tue, Mar 24, 2009 at 2:57 PM, Ojan Vafai o...@google.com wrote: I'm going about adding support to the webkit test list for BUGx metadata and replacing DEFER with P0/P1/P2/P3. I've come to the conclusion that we need to better understand our desired workflow for dealing with failing layout tests. TEST OWNERSHIP: Firstly, can we move away from using the spreadsheet to take ownership of layout tests and just put our names directly in the test list? This seems way more intuitive to me and avoids needing to look at multiple locations for the state of the layout tests. I like having a read-only dashboard that present this information in a useful way like the spreadsheet currently does, but there should only be one place we modify. BUGS/PRIORITY TRIAGING Option 1 Every P0/P1/P2 test is required to have a bug id associated with it. New failures get the UNTRIAGED property (does not require a bug id perhaps?). The people who triage bugs also triage the UNTRIAGED layout tests and assign them a priority (and file a bug?). The bugs are then fixed via our normal bug triage process. People own fixing a given layout test by becoming the owner of the bug. Pros: -Works with our current bug triage process (kind of) -Makes for one easy place that people need to look for their todo list (the google code issue tracker) Cons: -Overhead of filing and closing bugs when the common case is just a rebaseline anyways -Hard to triage layout tests without understanding what's wrong with them Option 2 The same as above, except that bug ids are not required. Bug ids are just for cases where someone has looked into a test and needs to provide information about why/how it's failing, but can't fix it immediately. People become owners for a given layout test by putting their name as one of the metadata bits for that test. Like Option 1, there needs to be a triage process to assign priorities. Pros: -Minimizes overhead of
[chromium-dev] What packages does Chromium depend on to run on Linux?
After reading about people installing Chromium on Ubuntu, I gave it a try today on my Debian Unstable. I first tried the latest .deb package from http://build.chromium.org/buildbot/snapshots/chromium-rel-linux/?O=D. It installs fine, but I only get the chrome, i.e. the tab strip and the menu. Whenever I navigate to any URL, the title is updated, but nothing shows in the browser body. I also get tons of Not implemented reached in ... messages on the console. I am suspecting that some libraries are incompatible, but I cannot figure out which. I also tried the Ubuntu package for Intrepid from https://launchpad.net/~chromium-daily/+archive/ppa, but got the same result. I have upgraded libgtk2.0-0 and libnspr4-0d. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
IMPORTANT: Re: [chromium-dev] Re: layout tests and bug triaging
Just want to make sure everyone sees this. Please voice yourself now if you care about layout test fixing process and about managing test list process. I'll give another day. Unless I hear objections, I'll make run_webkit_tests do option 3. I'm not quite sure how we transition from the current world with no bug ids to a future world with a bug id for each test, but I'll figure that out. Ojan On Wed, Mar 25, 2009 at 3:51 PM, David Levin le...@google.com wrote: We could go with option 3 until someone is annoyed enough by the overhead to write a script. :) On Tue, Mar 24, 2009 at 4:19 PM, Ojan Vafai o...@google.com wrote: OK. So, what I'm hearing is that every test should have a bug assigned to it, no matter the priority. In that case, there's a couple other options. *Option 3* Get rid of DEFER and don't add priorities to the test list. Instead require that every test have an associated bug (multiple tests can share a bug) and rely on the bug priority/owner to figure out when the test needs fixing and who is responsible for fixing it. Pros: -Works with our current bug triage process (kind of) -Makes for one easy place that people need to look for their todo list (the google code issue tracker) Cons: -Overhead of filing and closing bugs when the common case is just a rebaseline anyways -Hard to triage layout tests without understanding what's wrong with them *Option 4* Same as option 3, except we have a script that monitors the test list and automatically files a bug whenever a new test appears. The subject of the test is just the path listed in the test list, so the test can be found by searching the issue tracker. Similarly, when a test is removed from the test list, the bug is automatically closed. This has the same pros and cons as option 3 except that it totally removes the overhead associated with having a bug for each test path. Also, this would require someone to write the script to do this. Ojan On Tue, Mar 24, 2009 at 12:31 PM, David Levin le...@google.com wrote: I like this proposal. I would also like a bugs for P3 which could explain why it is a P3. If is it an unimplemented feature, then all tests for that unimplemented feature could have the same bug. (Since I do merges and took a while to layout test file bugs from that) I like option 2. BUT I'm concerned that adding someone's email address to test_fixable will not get any attention. Right now, when you file a bug, people get email and the bugs seem to be followed up. BUGS/PRIORITY TRIAGING Option 1 Addition Pro Email sent about new bug alerts people to the new issue -- I suppose one could email people separately when adding their email address to test_fixable (but this step could easily be missed). Dave On Tue, Mar 24, 2009 at 12:14 PM, Marc-Andre Decoste m...@chromium.org wrote: I personally prefer having a bug assigned for the layout tests that we want to be fixed soon... It makes for a more consistent way of following up on our progress... Even if the end result is just a re-baseline, we also gain the link to the bug from the committed change list (and vice versa). And if we want some sort of dashboard for this, we could add a page on the chromium-status appEngine that would read from the latest version of the test list file, and maybe some details (e.g., owner) from the issue tracker... Maybe... ;-) BYE MAD On Tue, Mar 24, 2009 at 2:57 PM, Ojan Vafai o...@google.com wrote: I'm going about adding support to the webkit test list for BUGx metadata and replacing DEFER with P0/P1/P2/P3. I've come to the conclusion that we need to better understand our desired workflow for dealing with failing layout tests. TEST OWNERSHIP: Firstly, can we move away from using the spreadsheet to take ownership of layout tests and just put our names directly in the test list? This seems way more intuitive to me and avoids needing to look at multiple locations for the state of the layout tests. I like having a read-only dashboard that present this information in a useful way like the spreadsheet currently does, but there should only be one place we modify. BUGS/PRIORITY TRIAGING Option 1 Every P0/P1/P2 test is required to have a bug id associated with it. New failures get the UNTRIAGED property (does not require a bug id perhaps?). The people who triage bugs also triage the UNTRIAGED layout tests and assign them a priority (and file a bug?). The bugs are then fixed via our normal bug triage process. People own fixing a given layout test by becoming the owner of the bug. Pros: -Works with our current bug triage process (kind of) -Makes for one easy place that people need to look for their todo list (the google code issue tracker) Cons: -Overhead of filing and closing bugs when the common case is just a rebaseline anyways -Hard to triage layout tests without understanding
[chromium-dev] Re: What packages does Chromium depend on to run on Linux?
http://code.google.com/p/chromium/wiki/LinuxBuildInstructionsPrerequisites is the canonical list. To get a useful product as quickly as possible, we've been targeting one particular release (Ubuntu Hardy). Once we have a working browser we of course intend to spend the time to track down glitches on all systems. In the interim, if you can figure out what is wrong I'd love a patch (or even a fix to those docs). On Wed, Mar 25, 2009 at 3:56 PM, Wei Hu wei@gmail.com wrote: After reading about people installing Chromium on Ubuntu, I gave it a try today on my Debian Unstable. I first tried the latest .deb package from http://build.chromium.org/buildbot/snapshots/chromium-rel-linux/?O=D. It installs fine, but I only get the chrome, i.e. the tab strip and the menu. Whenever I navigate to any URL, the title is updated, but nothing shows in the browser body. I also get tons of Not implemented reached in ... messages on the console. I am suspecting that some libraries are incompatible, but I cannot figure out which. I also tried the Ubuntu package for Intrepid from https://launchpad.net/~chromium-daily/+archive/ppa, but got the same result. I have upgraded libgtk2.0-0 and libnspr4-0d. --~--~-~--~~~---~--~~ 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: What packages does Chromium depend on to run on Linux?
On Wed, Mar 25, 2009 at 3:56 PM, Wei Hu wei@gmail.com wrote: the menu. Whenever I navigate to any URL, the title is updated, but nothing shows in the browser body. This can also be caused by not having msttcorefonts installed. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Including Droid font in Chrome?
On Mar 25, 2:52 pm, Mike Reed r...@android.com wrote: Indeed, its unhinted to keep it small. That said, we could (with some $$) have it hinted, either generically, or with cleartype in mind. Our font fallback is incomplete, Uniscribe is a no-go due to the sandbox. This seems something worth exploring. For these purpose the font wil have to include most (all?) unicode points so it will be pretty big. On Wed, Mar 25, 2009 at 1:45 PM, Brett Wilson bre...@chromium.org wrote: On Wed, Mar 25, 2009 at 10:16 AM, Alex Russell slightly...@google.com wrote: MSFT did a new set of fonts to take specific advantage of ClearType: http://www.microsoft.com/typography/ClearTypeFonts.mspx The Core Fonts are still available and installed by default on all windows versions that I can find information on, but they were designed for a simpler time when sub-pixel hinting was still rare. I'm not sure that implies that we should do anything in particular WRT Droid, though. I have them on my Windows box. They are nice fonts, but I think they are optimized for the antialiasing algorithm on Andorid: I don't find that they look quite as good on Windows using ClearType. For a while, I was interested in including their fallback font which we could use to guarantee that glyphs are available for most characters. But (I assume) for space reasons on the phone, this font is not hinted, so looks pretty ugly. 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: What packages does Chromium depend on to run on Linux?
On Mar 25, 11:56 pm, Wei Hu wei@gmail.com wrote: I also tried the Ubuntu package for Intrepid fromhttps://launchpad.net/~chromium-daily/+archive/ppa, but got the same result. If you used those builds older than 2 days and you didn't have mscorefonts installed, you got a blank page. I fixed the package to depend on ttf-mscorefonts-installer ~2 days ago. It solved the blank page issue, at least for those who reported it to me. This is not satisfactory for Ubuntu. We don't want that mscorefonts thing as a mandatory dep. This is clearly non-free. So i guess someone will have to patch that, if not upstream, then downstream, with all the consequences it implies. --~--~-~--~~~---~--~~ 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
On windows the exe/dll separation it was meant to simplify upgrade but in practice the exe changes frequently enough that we still need to support exe upgrading in place. We always wanted to have a do nothing exe that just loads the chrome dll but that never happened, reasons: 1) the sandbox 2) breakpad 3) google_update. All this things are living on the exe. We could move to a no-dll world easier than moving to a dumb exe world. On Mar 24, 9:50 pm, Craig Schlenter craig.schlen...@gmail.com wrote: On Tue, Mar 24, 2009 at 8:45 PM, Thomas Van Lententhoma...@chromium.org wrote: [snip] Linux currently builds as one executable also. But Adam proposed we create a second executable (via hardlink?) for AppArmor as a sandbox? Will a hard link work for selinux btw.? I'm under the impression that selinux is inode based so Fedora etc. would have to do something different there. As for the shared library overhead that Dean mentioned, there is some interesting work on linux that is mentioned herehttp://lwn.net/Articles/192624/... hopefully some of that has made it into the default toolchain by now. Pre-linking is enabled by default on Fedora btw. ... I'm unsure of other distributions. --Craig --~--~-~--~~~---~--~~ 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: What packages does Chromium depend on to run on Linux?
On Wed, Mar 25, 2009 at 6:08 PM, fta f...@sofaraway.org wrote: thing as a mandatory dep. This is clearly non-free. So i guess someone will have to patch that, if not upstream, then downstream, with all the consequences it implies. At some point I can imagine changing the default font and rebaselining pretty much every test. That will mark the final departure from Windows metrics in the test results. However; not soon I'm afraid. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
