[chromium-dev] Looking for a chrome developer with skia-fu
Hey guys, I'm trying to triage bug 9589, which is a UMR in skia. Who would be good to help triage a skia bug? Thanks, James Hawkins -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Thoughts on // NOLINT?
Agreed. There are certain situations where conforming to lint expectations leads to messier code. I just checked in a CL that contains a section of lines longer than 80 cols. Trying to wrap these lines would make the definitions unreadable. It's one thing to have lint report zero errors; it's another to muddy the source to achieve that goal. grep'ing through the code, I found hundreds of NOLINTs though, so maybe we're in the minority. On Wed, Dec 9, 2009 at 3:48 PM, John Abd-El-Malek j...@chromium.org wrote: Lately I've been seeing more and more // NOLINT added to the code. It's great that people are running lint to make sure that they're following the guidelines, but I personally find adding comments or gibberish to our code for tools that are supposed to make the code quality better happy/more consistent a bit ironic. I also find it distracting when reading the code. Am I the only one? -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] buildbot cycle time dashboard?
Thanks for the link Eric! Can someone explain what the Percentage of failures graph is representing? Thanks, James Hawkins On Tue, Dec 8, 2009 at 2:56 PM, Eric Seidel esei...@chromium.org wrote: http://build.chromium.org/buildbot/waterfall/stats On Tue, Dec 8, 2009 at 2:51 PM, Dan Kegel d...@kegel.com wrote: Hey folks, I seem to recall we have a dashboard somewhere showing the cycle time of each of our build/test bots, but I can't find it. Can somebody point me to it? If it doesn't exist, maybe I'll scrape one together. Thanks... -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Request for a reviewer
Hi, Any kind soul willing to review a simple regexp parser? 211 lines. http://codereview.chromium.org/439008 Thanks, James Hawkins -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] RFC: AutoFill++ Design Document
Hi, please read the inlined proposed design for AutoFill++. Any feedback and comments are appreciated. Thanks, James Hawkins *AutoFill++* *Status:* *Draft* (as of 2009-10-16) *James Hawkins** jhawk...@chromium.org Modified: Fri Oct 16 2009 * Objective The purpose of this document is to describe a significant improvement in the current form autofill feature of Google Chrome. The current implementation is less of a form autofill and more of a form history. This approach has some limitations: - Values are saved per-site, so a Name value saved on penguin.com will not be suggested for the Name field on turtle.com. - The form must be filled out field-by-field. I am proposing a new approach to form filling based on the client/server statistic-based model implemented by Google Toolbar. This feature provides the following benefits: - Forms are completely auto-filled. - Values are saved in user profiles, so the Name field can be auto-filled for a form on a site one has never visited. Background The main problem with the current autofill feature is that the user must move from field to field to fill out a form, even when each field can be auto-filled. The history is site-specific, so the user must enter form data for each site before autofill can be useful. Overview To use the AutoFill++ feature in Google Chrome, the user must enter personal information (name, address, email, etc.) into a form on any site and submit this form. An infobar will ask the user if he wants to enable autofill, and if so, AutoFill++ will parse the form data and query the autofill server for the field types. If the server knows the field types for the form on this particular site, AutoFill++ will match the data with the fields; otherwise, a heuristic based on the names of the fields and how they are layed out on the form is used to make this match. The map of (field, data) will then be saved in the user form data database. When the user starts entering information into any other form, a list of saved profiles will be presented to the user in a selection drop-down. After picking a profile, AutoFill++ will autofill all fields that it knows about and has information in the database for. The user will be able to enter additional profile information at any time through the AutoFill++ dialog. This dialog will be shown after the user first enters form information, and will also be available through the options dialog. Note that no personal information will be sent to the autofill server, just the field types determined by the heuristics. Detailed Design The first step in implementing AutoFill++ is to rename the current AutofillForm data structures to better match their behavior: FormFieldHistory. Just like Toolbar AutoFill++, the client will implement some strategies to reduce the bandwitdth on the autofill server. These include: - Ignore common search forms by ignoring forms that contain only one textfield with an id of q. - Ignore forms using the GET method to submit for data. - Ignore forms that have the word search in the target url for that form. - Using a flag in the query response from the server to tell the client whether or not it should upload the data if a user submits this form. *Data Structure* *Description* *AutoFillForm* The container that holds the (field, value) pairs, parsed from HTML. *RenderViewHostDelegate::AutoFill* An interface implemented by a class that wants to be notified of AutoFill events from the RenderView *AutoFillService* The main AutoFill++ class. Coordinates between the RenderView, the autofill server, and the PersonalDatabaseManager Each TabContents has one, and each instance is lazily created. *AutoFillQueryXMLParser *Builds and parses XML queries that are sent to and received from the autofill server. *AutoFillDownloadThread* Spins off a new thread to download/upload data to the autofill server. *AutoFillProfileDialog* The UI for displaying the AutoFill++ profile dialog. *PersonalDatabaseManager* The gateway between the AutoFillService and the profile database. *AutoFillProfile* Contains all available personal information provided by the user. This is written to and read from the database. The following is a description of the program flow for a typical autofill session. 1. User fills out and submits form. - RenderView::willSubmitForm - An *AutoFillForm* is created using * AutoFillForm::**Create*, which parses the form fields and values from a given WebForm. - ViewHostMsg_AutoFillFormSubmitted - Sends an IPC to the browser's render view host containing a map of the fields and values. - *RenderViewHostDelegate::AutoFill-AutoFillFormSubmitted* - *AutoFillService::HandleSubmit* - *AutoFillQueryXMLParser* - Creates the XML representation of the form data, in the format specified by the autofill communication
[chromium-dev] Re: RFC: AutoFill++ Design Document
For the mac case, we can probably query this service to populate the autofill database before the first form is filled out. The major question I have is, what happens when the user edits our copy of the personal information (or the other after we've copied it)? Should we make these copies read-only? Having the profiles out of sync is not desirable. On Tue, Oct 20, 2009 at 10:25 AM, Mike Pinkerton pinker...@chromium.orgwrote: Mac browsers (Safari and Camino, at least) allow the user to auto-fill from their me card in the OS X Address Book application, containing name, address, and phone number. This would be a nice feature to provide to users who have grown accustomed to the functionality. Is there any mechanism to allow us to recognize and provide this info to the form instead of requiring the user to fill out the form completely? On Tue, Oct 20, 2009 at 1:13 PM, James Hawkins jhawk...@chromium.org wrote: Hi, please read the inlined proposed design for AutoFill++. Any feedback and comments are appreciated. -- 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: RFC: AutoFill++ Design Document
Sorry, the text isn't very clear about that. For lack of a better name (yet), it's a new database that contains the autofill profiles. On Tue, Oct 20, 2009 at 10:56 AM, Scott Violet s...@chromium.org wrote: What is the 'profile database' ? The webdb? -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: RFC: AutoFill++ Design Document
I've been looking at this since you brought it up, and I agree that these values should go into the web db. On Tue, Oct 20, 2009 at 12:09 PM, Scott Violet s...@chromium.org wrote: Do we really want another database file and associated thread? Shouldn't we put this in the web db? -Scott On Tue, Oct 20, 2009 at 10:58 AM, James Hawkins jhawk...@chromium.org wrote: Sorry, the text isn't very clear about that. For lack of a better name (yet), it's a new database that contains the autofill profiles. On Tue, Oct 20, 2009 at 10:56 AM, Scott Violet s...@chromium.org wrote: What is the 'profile database' ? The webdb? -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: RFC: AutoFill++ Design Document
The current design keys off autofill after the user enters a value in the name field. A drop down menu is shown allowing the user to select which profile to autofill. If the user does not select a profile, the form will not be autofilled (using AutoFill++). I'll try to clarify this in the doc. Thanks, James On Tue, Oct 20, 2009 at 12:43 PM, Darin Fisher da...@chromium.org wrote: One security concern: Autofill should not give users information to the page until the user makes some gesture to accept the autofill choices. For the existing autofill, this is done by having the user choose from the drop down menu. The page can read the value of an INPUT field once it is set, so you have to be careful. I wonder if a solution already exists to support Safari's autofill. -Darin On Tue, Oct 20, 2009 at 10:13 AM, James Hawkins jhawk...@chromium.orgwrote: Hi, please read the inlined proposed design for AutoFill++. Any feedback and comments are appreciated. Thanks, James Hawkins *AutoFill++* *Status:* *Draft* (as of 2009-10-16) *James Hawkins** jhawk...@chromium.org Modified: Fri Oct 16 2009 * Objective The purpose of this document is to describe a significant improvement in the current form autofill feature of Google Chrome. The current implementation is less of a form autofill and more of a form history. This approach has some limitations: - Values are saved per-site, so a Name value saved on penguin.com will not be suggested for the Name field on turtle.com. - The form must be filled out field-by-field. I am proposing a new approach to form filling based on the client/server statistic-based model implemented by Google Toolbar. This feature provides the following benefits: - Forms are completely auto-filled. - Values are saved in user profiles, so the Name field can be auto-filled for a form on a site one has never visited. Background The main problem with the current autofill feature is that the user must move from field to field to fill out a form, even when each field can be auto-filled. The history is site-specific, so the user must enter form data for each site before autofill can be useful. Overview To use the AutoFill++ feature in Google Chrome, the user must enter personal information (name, address, email, etc.) into a form on any site and submit this form. An infobar will ask the user if he wants to enable autofill, and if so, AutoFill++ will parse the form data and query the autofill server for the field types. If the server knows the field types for the form on this particular site, AutoFill++ will match the data with the fields; otherwise, a heuristic based on the names of the fields and how they are layed out on the form is used to make this match. The map of (field, data) will then be saved in the user form data database. When the user starts entering information into any other form, a list of saved profiles will be presented to the user in a selection drop-down. After picking a profile, AutoFill++ will autofill all fields that it knows about and has information in the database for. The user will be able to enter additional profile information at any time through the AutoFill++ dialog. This dialog will be shown after the user first enters form information, and will also be available through the options dialog. Note that no personal information will be sent to the autofill server, just the field types determined by the heuristics. Detailed Design The first step in implementing AutoFill++ is to rename the current AutofillForm data structures to better match their behavior: FormFieldHistory. Just like Toolbar AutoFill++, the client will implement some strategies to reduce the bandwitdth on the autofill server. These include: - Ignore common search forms by ignoring forms that contain only one textfield with an id of q. - Ignore forms using the GET method to submit for data. - Ignore forms that have the word search in the target url for that form. - Using a flag in the query response from the server to tell the client whether or not it should upload the data if a user submits this form. *Data Structure* *Description* *AutoFillForm* The container that holds the (field, value) pairs, parsed from HTML. *RenderViewHostDelegate::AutoFill* An interface implemented by a class that wants to be notified of AutoFill events from the RenderView *AutoFillService* The main AutoFill++ class. Coordinates between the RenderView, the autofill server, and the PersonalDatabaseManager Each TabContents has one, and each instance is lazily created. *AutoFillQueryXMLParser *Builds and parses XML queries that are sent to and received from the autofill server. *AutoFillDownloadThread* Spins off a new thread to download/upload data to the autofill server. *AutoFillProfileDialog* The UI for displaying the AutoFill++ profile dialog
[chromium-dev] Re: [chromium-checkins] r25367 - in trunk/src: chrome/browser chrome/browser/chromeos chrome/browser/gtk chrome/browser/views chrome/browser/views/extensions chrome/browser/views/fram
On Thu, Sep 3, 2009 at 1:58 PM, fin...@chromium.org wrote: Author: fin...@chromium.org Date: Thu Sep 3 13:58:01 2009 New Revision: 25367 Log: Fix 9867: Activating the previous/next buttons with the keyboard in the find bar should not change the focus. Add param const Event event to ButtonPressed, so that recipients can find out more about the event that generated the ButtonPress message. Modified: trunk/src/views/controls/button/native_button.cc == --- trunk/src/views/controls/button/native_button.cc (original) +++ trunk/src/views/controls/button/native_button.cc Thu Sep 3 13:58:01 2009 @@ -4,8 +4,14 @@ #include views/controls/button/native_button.h +#if defined(OS_WIN) +#include atlbase.h +#include atlapp.h // for GET_X/Y_LPARAM +#endif + Please don't add more dependencies to ATL. We're in the process of removing said dependencies. GET_X/Y_LPARAM can be replaced by MAKEPOINTS which doesn't require ATL. -- James Hawkins --~--~-~--~~~---~--~~ 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: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 2:41 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 2:02 PM, JT Olds jto...@xnet5.com wrote: None of the below Linux browsers select the entire URL on the first click: Firefox Epiphany Seamonkey Galeon Midori Konqueror Dillo In fact, I can't find a single browser that does what you claim on Linux. I am on record ( http://groups.google.com/group/chromium-reviews/browse_thread/thread/878579dd61c53a00/213560d76d537337 ) as saying It would be better to just not select the text at all (a la Firefox) than to appear to select the text but not update the X primary selection. If the current behavior becomes intolerable, that is the route I'd go. Intolerable is more than just not how the native controls normally work -- it's dramatically interferes with user behavior. That may well be true on Linux. In that thread, though, we discussed a lot of other alternate methods of pasting in a URL, such as paste-and-go, middle-clicking blank sections of the tabstrip, etc. I'd want some Linux UI folks to be able to say concretely, we've lived with this for several weeks, and it's clearly not enough; we need to change. PK Will you accept opinions of the opposite? I love our current behavior and can't stand having to triple-click in Firefox. Consider the following cases. a) The user is trying to completely change the contents of the omnibox. - Current behavior: 1 click - Suggested behavior: 3 clicks b) The user is trying to modify the contents of the omnibox. - Current behavior: 2 clicks - Suggested behavior: 1 click I have no facts to back up this claim, but I'd say that 70% of operations are of the former (a), with the caveat that this is a conservative estimate based on my personal experience. 100 operations - Current behavior: 70*1 + 30*2 = 130 clicks Suggested behavior: 70*3 + 30*1 = 240 clicks This analysis only pertains to number of clicks and ignores the issue of nuking the PRIMARY selection, which I've personally never had a problem with. Linux UI devel, James Hawkins --~--~-~--~~~---~--~~ 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: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 3:14 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 2:57 PM, James Hawkins jhawk...@chromium.org wrote: Will you accept opinions of the opposite? I love our current behavior and can't stand having to triple-click in Firefox. Consider the following cases. a) The user is trying to completely change the contents of the omnibox. - Current behavior: 1 click - Suggested behavior: 3 clicks b) The user is trying to modify the contents of the omnibox. - Current behavior: 2 clicks - Suggested behavior: 1 click I have no facts to back up this claim, but I'd say that 70% of operations are of the former (a), with the caveat that this is a conservative estimate based on my personal experience. I chatted with several people just now about the Mac behavior, since unlike Linux, there aren't blowing away my clipboard concerns and it seemed to me that the argument above was compelling. According to pinkerton, the behavior in Chrome Mac is not just to match Safari, Camino, or platform conventions, but ultimately for the same reason that Camino decided to place-cursor-on-click instead of selecting all: editing was thought to be common enough that selecting all becomes frustrating. To me something is wrong when we argue opposite (non-platform-dependent) conclusions on different platforms, so I filed http://crbug.com/19879 about collecting some real-world data to inform this debate. If we found that 99% of user navigations followed replacing all the text, for example, I would plead strongly with the Mac people to change their decision; if we found that 50% of navigations involved editing, I would probably argue we should reverse the Windows and Linux behaviors both. Of course, if we do get this data, the numbers are unlikely to be so clear-cut. But we won't know until then. If anyone wants to contribute a patch to do this, it would be welcome... PK I absolutely agree. My 70% guesstimate was purely based on my own behavior, and I have no idea how it's used for the majority of users. Most of our UI decisions in the past have been based on user data, and this is another experiment we should set up. I'm willing to look into what's required to run this experiment. -- James Hawkins --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] running reliability tests
Hi, How can I run the reliability tests, specifically the automated UI tests, locally? Thanks, James Hawkins --~--~-~--~~~---~--~~ 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: valgrind updated
I believe Pawel is referring to build-valgrind-for-chromium.sh, as in why use this script to build valgrind instead of the system-supplied valgrind. There are a few bugs that aren't in upstream releases that we patch to workaround. https://bugs.kde.org/show_bug.cgi?id=162848 https://bugs.kde.org/show_bug.cgi?id=186796 James On Wed, Jul 22, 2009 at 2:23 PM, Evan Stadeest...@chromium.org wrote: it's just a helpful wrapper, doing stuff like --malloc-fill=41 and pointing at the suppression file. -- Evan Stade On Wed, Jul 22, 2009 at 8:53 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: Seems like a good news, but why should I use this script instead of regular valgrind? I don't know the difference. On Wed, Jul 22, 2009 at 20:39, Dan Kegel d...@kegel.com wrote: If you don't run valgrind, you can probably ignore this. tools/valgrind/build-valgrind-for-chromium.sh has been updated. Used to be, if you had gold as your system linker, it would generate a valgrind that couldn't even valgrind /bin/true. It's now a bit smarter, and won't build or install a broken valgrind. It also adds a patch to properly terminate log files on exec (which gets rid of an annoying delay when running tools/valgrind/chrome_tests.sh on some tests). Separately, http://wiki.corp.google.com/Main/ChromeBuildbotLinux was also updated, and a new valgrind and gold were pushed to the main valgrind bots, codf15[678]. They were missing the long suppressions patch before, so the update should prevent recurrence of one of the intermittent valgrind warnings seen today. (It already had a suppression, but because the suppresson had a line longer than 200 chars, it was ignored.) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] automation provider assistance
Hi, Will someone please inform me who I should talk to concerning the automation provider (chrome/browser/automation)? svn log in that directory is all over the place, so that wasn't much help. I'm looking at porting automation provider to linux and have a few questions. Thanks, James Hawkins --~--~-~--~~~---~--~~ 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] green flashes in page content
On Tue, May 19, 2009 at 11:20 PM, William Chan (陈智昌) willc...@chromium.org wrote: On Tue, May 19, 2009 at 5:12 PM, James Hawkins jhawk...@chromium.org wrote: On Tue, May 19, 2009 at 5:07 PM, Evan Stade est...@chromium.org wrote: Are we sure we need this functionality? I understand the intention of seeing when we're not drawing fast enough, but I'm seeing the green background all the time (on a fast machine), which leads me to believe that the debugging aid is a red herring. Yea, you should see it all the time. We'll never be able to fix that. But how much of it you see is a good measure of jank. If enough people hate it, we can remove it (and only enable when we care to look at jank). We should leave page load/rendering time to measurements from the tests. This should be something that a developer working on jankiness could enable himself. It's rather distracting to the developers who don't need to look into jankiness, but do need to run debug builds regularly. I personally like seeing the green background, since I do like seeing how much jank there is. It doesn't bother me at all. That said, I can see how it'd annoy some people. If most people dislike it, then I think we should just make it the same as the release behavior (use a white background), but I think it'd be nice to have a command line flag or a preference or something so I can run with a green or whatever background to aid in debugging jankiness. Sure, I think a flag or pref would be ideal. --~--~-~--~~~---~--~~ 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] green flashes in page content
Are we sure we need this functionality? I understand the intention of seeing when we're not drawing fast enough, but I'm seeing the green background all the time (on a fast machine), which leads me to believe that the debugging aid is a red herring. On Tue, May 19, 2009 at 4:59 PM, Evan Martin e...@chromium.org wrote: If you're seeing green flashes when you resize, don't worry -- that's just the window background showing through in debug builds. estade checked it in as a debugging aid to see when we're not drawing fast enough. It's white on release builds. --~--~-~--~~~---~--~~ 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] green flashes in page content
On Tue, May 19, 2009 at 5:07 PM, Evan Stade est...@chromium.org wrote: Are we sure we need this functionality? I understand the intention of seeing when we're not drawing fast enough, but I'm seeing the green background all the time (on a fast machine), which leads me to believe that the debugging aid is a red herring. Yea, you should see it all the time. We'll never be able to fix that. But how much of it you see is a good measure of jank. If enough people hate it, we can remove it (and only enable when we care to look at jank). We should leave page load/rendering time to measurements from the tests. This should be something that a developer working on jankiness could enable himself. It's rather distracting to the developers who don't need to look into jankiness, but do need to run debug builds regularly. -- James Hawkins --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Linux TabStrip design doc 3-3-09
Hi,
We on the Linux team have settled on a TabStrip design that will allow
us to share as much code as possible without having to reimplement
Views, which would take a considerable amount of time and effort. The
TabStrip interfaces will be refactored to have cross-platform
super-classes and platform-specific subclasses. This split often
occurs where Views classes are pulled into the TabStrip interface.
This allows sharing of common code, such as tab animation. The
platform-specific code, for the most part, will be the implementation
of the UI for the tab strip. For example, the TabStrip class is
currently defined as:
class TabStrip : public views::View,
public TabStripModelObserver,
public Tab::TabDelegate,
public views::Button::ButtonListener,
public MessageLoopForUI::Observer {
The new super-class will be:
class TabStrip : public TabStripModelObserver,
public Tab::TabDelegate,
and the win subclass:
class TabStripWin : public views::View,
public views::Button::ButtonListener,
public MessageLoopForUI::Observer,
public TabStrip {
We are using the C interface for gtk, so the gtk variant TabStripGtk
will simply inherit from TabStrip. All of the UI needed by TabStrip
will be overridden and implemented using gtk.
On a higher level, the Linux tab strip will be implemented using a
gdkpixmap in a container, which allows fast blitting of the skbitmap
used by TabRenderer.
--
James Hawkins
--~--~-~--~~~---~--~~
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 TabStrip design doc 3-3-09
On Tue, Mar 3, 2009 at 11:36 AM, Ben Goodger (Google) b...@chromium.org wrote: Can you give a more detailed breakdown of the code/methods that'll be moved to the shared base? To be shared: * All of the TabAnimation classes. * The following methods: - GetPreferredHeight - CanProcessInputEvents - PointIsWithinWindowCaption, though we don't have a custom frame on linux yet - IsCompatibleWith - IsAnimating - model - IsDragSessionActive - AbortActiveDragSession - DestroyDragController - DestroyDraggedSourceTab - GetIdealBounds - UpdateLoadingAnimations - TabStripModelObserver implemenation - Tab::Delegate implemenation - GetTabAt - GetTabAtAdjustForAnimation - GetTabCount - GetCurrentTabWidths - GetDesiredTabWidths - ResizeLayoutTabs - all of the methods under the Animations section It's probably easier to look at it from the other side though, i.e. how much are we taking out of TabStrip? * The following inherited super-classes: - views::View - views::Button::ButtonListener - MessageLoopForUI::Observer * Any platform-specific code, usually Views overrides. -- James Hawkins --~--~-~--~~~---~--~~ 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 TabStrip design doc 3-3-09
Yes that is the case. On Tue, Mar 3, 2009 at 1:57 PM, Ben Goodger (Google) b...@chromium.org wrote: Because you're reusing display methods that retrieve metrics, I assume your tabstrip will have exactly the same bounds for itself and its contents as the windows one? -Ben On Tue, Mar 3, 2009 at 11:49 AM, James Hawkins jhawk...@chromium.org wrote: On Tue, Mar 3, 2009 at 11:36 AM, Ben Goodger (Google) b...@chromium.org wrote: Can you give a more detailed breakdown of the code/methods that'll be moved to the shared base? To be shared: * All of the TabAnimation classes. * The following methods: - GetPreferredHeight - CanProcessInputEvents - PointIsWithinWindowCaption, though we don't have a custom frame on linux yet - IsCompatibleWith - IsAnimating - model - IsDragSessionActive - AbortActiveDragSession - DestroyDragController - DestroyDraggedSourceTab - GetIdealBounds - UpdateLoadingAnimations - TabStripModelObserver implemenation - Tab::Delegate implemenation - GetTabAt - GetTabAtAdjustForAnimation - GetTabCount - GetCurrentTabWidths - GetDesiredTabWidths - ResizeLayoutTabs - all of the methods under the Animations section It's probably easier to look at it from the other side though, i.e. how much are we taking out of TabStrip? * The following inherited super-classes: - views::View - views::Button::ButtonListener - MessageLoopForUI::Observer * Any platform-specific code, usually Views overrides. -- James Hawkins -- James Hawkins --~--~-~--~~~---~--~~ 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: g++ bug reduced to a test case
On Wed, Feb 11, 2009 at 4:00 AM, Dean McNamee de...@chromium.org wrote:
Hey Jay,
When you inherit from a templated base, and explicitly call the
constructor, you must instantiate the template, otherwise it's
ambiguous.
The line:
explicit InternalGetCommandsRequest(CallbackType* callback) :
CancelableRequest(callback) {
Should be:
explicit InternalGetCommandsRequest(CallbackType* callback) :
CancelableRequestInternalGetCommandsCallback(callback) {
That compiles fine for me here.
Success! Thanks Dean. How could I have ever doubted gcc? :-)
--
James Hawkins
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
Fwd: [chromium-dev] Linux TabStrip design doc
On Tue, Feb 10, 2009 at 11:36 AM, Evan Martin e...@chromium.org wrote: On Tue, Feb 10, 2009 at 11:22 AM, James Hawkins jhawk...@chromium.org wrote: 2) Redesigned TabStrip using one GtkDrawArea, handling drawing and input to the tabs ourselves. Evan M. proposed that we use one GtkDrawArea for the entire TabStrip area of the window (a GtkDrawArea is just a container in which you can draw in.) We would have to handle placement and drawing of the tabs. We would also have to handle input for the tabs, i.e. calculating if a mouse click is within the bounds of a particular tab. Part of my argument is that the placement/drawing/mouse-clicking are parts of the code we should share. TabStripModel = good, will use in any design. TabStrip depends on views::View and views::Button, so we'd need to implement that much of Views unless I'm mistaken. automatic input handling. Tab depth is controlled by ordering the drawing of the buttons. Since we're using a GtkFixed container, we can overlap the buttons/tabs to achieve the Chrome look. pros: Input handling is automatic, animation is simpler. It's not clear to me how animation plays into this. Could you elaborate? In the case where each tab is a widget, the animation is achieved solely by moving the widget within the container. The difference is subtle, but to me it's simpler because the re-drawing is done for us and our custom drawing is abstracted away from the animation. --~--~-~--~~~---~--~~ 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 TabStrip design doc
On Tue, Feb 10, 2009 at 12:30 PM, Dean McNamee de...@chromium.org wrote: Evan just explained the xshape stuff to me today. I'm curious how well it will work. You don't get alpha, etc. I could see it not working out that well, but I guess it's up to how you divide it. I honestly don't think hit testing a 20 pixel high rectangular area is going to be too tricky. Also, even with the button approach, even if the window has areas that are see through, I'm not sure how the works with events. I wouldn't be surprised if we'll have to do more calculations when the button is pressed, to make sure it's not in the space in between, etc. We'd use gdk_window_input_shape_combine_region, set up to match the exact (very close) region of the tab, which is not rectangular. If you do treat it as a rectangle, then you have to deal with clicking in the small space between the tabs. I guess that means I support 2, along with reusing the animation classes, etc. If majority opinion wants this, I will certainly go along with. I'd really like to hear some pros for 2 though. I don't see the advantages over 3. --~--~-~--~~~---~--~~ 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 TabStrip design doc
On Tue, Feb 10, 2009 at 12:47 PM, Ben Goodger (Google) b...@chromium.org wrote: BTW - Are GtkDrawAreas native widgets underneath? Can they be transparently rendered over others? GtkDrawingAreas (sorry, typo in my first email) are widgets, and they can be rendered over other widgets in certain situations (say using a GtkFixed container). By transparent, do you mean that whatever is beneath the GtkDrawingArea will show through parts of the area that we haven't drawn on yet? I'm not sure about that effect with GtkDrawingArea API, but from what I've read elsewhere it seems possible. --~--~-~--~~~---~--~~ 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 TabStrip design doc
On Tue, Feb 10, 2009 at 1:28 PM, Ben Goodger (Google) b...@chromium.org wrote: So what you probably want then is a views/NSView-like system for your toolbar stack then? Does Gtk provide abstractions for this? In Gtk parlance a widget is what win calls a view and mac calls NSView. I'm not sure what abstraction you're specifically asking about here though. --~--~-~--~~~---~--~~ 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-checkins] Re: r8862 - in trunk/src/webkit: build/WebCore tools/test_shell
On Thu, Jan 29, 2009 at 7:44 AM, Dean McNamee de...@chromium.org wrote: The files seem quite different 1 file changed, 336 insertions(+), 835 deletions(-) Anyone interested in taking a look at this today? Hey Adam, I worked on the gtk2drawing unforking to see why it caused so many test failures. The first problem is that platform/chromium/gtkdrawing.h wasn't unforked as well, so that header was being used instead of the appropriate platform/gtk/gtkdrawing.h. This caused a problem because a new type was added to the GtkThemeWidgetType enum, so when MOZ_GTK_DROPDOWN was requested, we got MOZ_GTK_ENTRY_CARET drawn. Unforking gtkdrawin.h would fix that problem. That fixes about 40 layout tests. The remaining ~100 failures are because of differences in the way the two gtk2drawing.c's render certain widgets. I think chromium's gtk2drawing widgets look a lot better, but another solution is to rebaseline those tests. -- James Hawkins --~--~-~--~~~---~--~~ 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-checkins] Re: r8862 - in trunk/src/webkit: build/WebCore tools/test_shell
I'll take a look. -- James On Thu, Jan 29, 2009 at 7:44 AM, Dean McNamee de...@chromium.org wrote: The files seem quite different 1 file changed, 336 insertions(+), 835 deletions(-) Anyone interested in taking a look at this today? On Thu, Jan 29, 2009 at 4:19 PM, Adam Langley a...@chromium.org wrote: On Thu, Jan 29, 2009 at 5:31 AM, Dean McNamee de...@chromium.org wrote: This made a ton of layout tests start failing, most likely we are drawing differently now? I should have checked that, but I didn't. (After all, the render-theme says where to draw and GTK says what to draw - what's left?). But I've reverted this change for now. Will look more closely next week. Thanks for spotting it. 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: seeking a scons expert
Michael was very helpful and pointed out an example of what I'm trying to do in third_party/icu38/icu38.scons: need_common_implementation = [ 'source/common/ubidi.c', 'source/common/ubidiln.c', ] for n in need_common_implementation: common_input_files.remove(n) o = env.ChromeObject(n, CPPDEFINES = env['CPPDEFINES'] + ['U_COMMON_IMPLEMENTATION', 'U_COMBINED_IMPLEMENTATION']) common_input_files.append(o) I'm writing up a similar bit of magic in WebCore.scons to the specific dirs/files I want to set CCFLAGS for. On Thu, Jan 29, 2009 at 3:42 PM, Dan Kegel d...@kegel.com wrote: What I usually do is do a verbose run, turn that into a shell script, and then edit the shell script... On Thu, Jan 29, 2009 at 3:30 PM, Michael Moss mm...@chromium.org wrote: I'll try to help. On Thu, Jan 29, 2009 at 2:36 PM, James Hawkins jhawk...@chromium.org wrote: Hi, I'm tracking down the layout test failures caused by the debug build of Linux Webkit. So far I've narrowed it down to the fact that appending -ffloat-store to CCFLAGS for the WebCore build file (src/webkit/build/WebCore/SConscript) fixes the failures. What I need to do now is narrow down my search to specific directories in WebCore first, then specific files within the offending directory. That means modifying CCFLAGS for those specific dirs/files. I've read through the scons 'manual', but I did not find a solution to this particular problem, especially considering the complexity of our build configuration. Anyone know if this is feasible? Thanks, James Hawkins --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] linux: tabs on top
On Wed, Jan 28, 2009 at 11:56 AM, Evan Martin e...@chromium.org wrote: (This is discussion of the UI independent of how it's implemented with views or not.) On Linux the window frame, if one even exists, is managed and drawn by a different process than the application. Additionally, people use a variety of window managers and so there's no guarantees for the way a frame will look. So there's no way to draw into it like we do on Windows. Two options: 1) Set the hint that turns off window frame drawing, and render something that looks like the Windows one. This would mean implementing window dragging via the title bar, etc. manually. (Ben's magic browzr work was undoing code like this on Windows, because it's endless pain. I think it may be less pain for us but it'd still be bad.) The right-click menu on the frame would be wrong. 2) Give up, and just make the tabs flush with the top of the window we have. This is probably ugly in the general case (since there will be an edge between the title bar and tabs), but will work in all situations. What about rolling out 2) initially, then implement 1) as a 'group 20% project', the group being the linux team? That work could be done in a branch, and if we get it working, merge the branch and start testing; otherwise, drop it if it ends up being a waste of time. -- James Hawkins --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] select option popup menu
Hi, Attached are screen shots of the rendering of LayoutTests/fast/forms/select-style.html on various browsers and platforms. I'm fixing this layout test for Linux, but I need to know which style to implement. The Win folks have already added a new baseline that matches the rendering used by Firefox. Safari uses the aqua style on all platforms. My guess is that we want to implement the same look as Chrome Win and Firefox. Any thoughts? -- James Hawkins --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~--- inline: firefoxlinux.pnginline: safarimac.pnginline: safariwin.PNGinline: chromelinux.png
