[chromium-dev] Re: What's missing in my view?
Don't you still need to engage some of webkit's code to ensure that space is made for the resizer (when there is only a vertical scrollbar)? -Darin On Sun, Dec 14, 2008 at 10:27 PM, Marc-Andre Decoste m...@google.com wrote: Salut Darin, I know, I have investigated that route, but the webkit code for the resizer is very tied to HTML tag rendering, so I had a hard time finding how to reuse it. Also, since I realized that I couldn't reuse it in the same way when I get to draw over bottom shelves like the download shelf, I concluded that it would be better to do it on our own... I have it all working when it is over the download shelf now, and looking at the status bubble as suggested by Jo, I see that it has to create its own window to set the status view as the content of that window... I think this would be a little overkill for a resize corner, but if it is the only way to do it over the tab content... so be it... Unless someone else has another suggestion? Thanks! BYE MAD On Sat, Dec 13, 2008 at 11:37 PM, Darin Fisher da...@chromium.org wrote: By the way, WebKit has support for drawing the resizer. So, if you are trying to add a resizer to windows that display web content, you might want to just enable the feature in WebKit (or at least the rendering portion of it). -Darin On Fri, Dec 12, 2008 at 1:32 PM, Marc-Andre Decoste m...@google.comwrote: Salut, I'm working on the resize corner view and am having a little trouble getting it to work. I tried to use the sample code provided in http://dev.chromium.org/developers/design-documents/views-windowing, by doing as follows: - in BrowserView::Init(), I create a label view and add it as a child of the contents_container_ - in BrowserView::Layout(), I get the parent of the label, as well as the preferred size of the label and then do as follows: label-SetBounds((parent_view-width() - ps.width() )/ 2, (parent_view-height() - ps.height()) / 2, ps.width(), ps.height()); - Then I run with a break point in Label::Paint() and it seems to do as it is told except... I don't see the Hello World text drawn anywhere... - I also tried my own BrowserResizerView class which also has mouse event overrides and they never get called, only the Paint override which seems to be painting on a /dev/nul canvas... What am I doing wrong? Do we have more detailed documentation about this, or is http://dev.chromium.org/developers/design-documents/chromeviews the only source of info we currently have? Thanks! BYE MAD --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: What's missing in my view?
On Mon, Dec 15, 2008 at 8:06 AM, Darin Fisher da...@chromium.org wrote: Don't you still need to engage some of webkit's code to ensure that space is made for the resizer (when there is only a vertical scrollbar)? He's doing that. (I was confused on this point too.) This requires providing a resizer rect to WebKit when it asks. The status bubble is overkill for this; it was a separate window mainly so it could move outside the main browser bounds as needed. I think there should be a way to do the right thing more easily here, but one would have to ask Ben, the Views guru, what it is. PK --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: What's missing in my view?
On Mon, Dec 15, 2008 at 10:12 AM, Peter Kasting pkast...@google.com wrote: The status bubble is overkill for this; it was a separate window mainly so it could move outside the main browser bounds as needed. Bah, I was wrong. Another issue is that the content area has its own HWND. If you want to draw above this, you need to have your own HWND too. There are two ways to do all this. You can do something like the status bubble, which will put all the code in one place and basically just work, at the cost of being a bit heavyweight. Perhaps we can refactor the status bubble code here (it would be nice to make use of it in the popup blocker UI as well). Or you can let WebKit draw the resize corner in some cases, and create a View to draw in the other cases (like when you're over the download shelf). Assuming the WebKit code just works, this is perhaps less code overall (unless we refactor the status bubble), at the expense of more design complexity (though maybe not much more, as either way you have to calculate the right rect to give WebKit). Ben may share more detailed thoughts; I think he supports the latter plan while I lean a bit more toward the former. Experimentation with both solutions will of course be the most informative :) PK --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: What's missing in my view?
A few thoughts on implementing the resizer: - Windows supports a resizer hit test code return value from WM_NCHITTEST. I think it's something like HTBOTTOMRIGHT (it's actually not HTGROWBOX, that doesn't work). When you return this value for coordinates in the resizer area, Windows will do the resizing for you automatically, just like it does for the window borders. Regardless of how you end up rendering the resizer, I think you should implement it this way for the event handling so that you're consistent with how we do resizing elsewhere. The right place to implement this is to add code to BrowserView::NonClientHitTest. The resizer is always a fixed size and location so that should be easy to add. - From what I understand WebKit supports rendering a a resizer. Apple relies on this API for Safari so I assume it is well supported. It seems like this would be simpler than adding a floating window or anything like that. I am generally suspicious of non-transient floating windows. - The Download Shelf is a special case - and in this case you could probably add code to the shelf's Paint function to render the resizer graphic at its bottom right. (BTW, thanks for dogfooding my windowing document. It's not finished yet as you can see but it is up to date at least!) -Ben On Fri, Dec 12, 2008 at 1:32 PM, Marc-Andre Decoste m...@google.com wrote: Salut, I'm working on the resize corner view and am having a little trouble getting it to work. I tried to use the sample code provided in http://dev.chromium.org/developers/design-documents/views-windowing, by doing as follows: in BrowserView::Init(), I create a label view and add it as a child of the contents_container_ in BrowserView::Layout(), I get the parent of the label, as well as the preferred size of the label and then do as follows: label-SetBounds((parent_view-width() - ps.width() )/ 2, (parent_view-height() - ps.height()) / 2, ps.width(), ps.height()); Then I run with a break point in Label::Paint() and it seems to do as it is told except... I don't see the Hello World text drawn anywhere... I also tried my own BrowserResizerView class which also has mouse event overrides and they never get called, only the Paint override which seems to be painting on a /dev/nul canvas... What am I doing wrong? Do we have more detailed documentation about this, or is http://dev.chromium.org/developers/design-documents/chromeviews the only source of info we currently have? Thanks! BYE MAD --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: What's missing in my view?
does the webkit resizer disappear when the download shelf appears? -darin On Mon, Dec 15, 2008 at 11:27 AM, Ben Goodger (Google) b...@chromium.orgwrote: A few thoughts on implementing the resizer: - Windows supports a resizer hit test code return value from WM_NCHITTEST. I think it's something like HTBOTTOMRIGHT (it's actually not HTGROWBOX, that doesn't work). When you return this value for coordinates in the resizer area, Windows will do the resizing for you automatically, just like it does for the window borders. Regardless of how you end up rendering the resizer, I think you should implement it this way for the event handling so that you're consistent with how we do resizing elsewhere. The right place to implement this is to add code to BrowserView::NonClientHitTest. The resizer is always a fixed size and location so that should be easy to add. - From what I understand WebKit supports rendering a a resizer. Apple relies on this API for Safari so I assume it is well supported. It seems like this would be simpler than adding a floating window or anything like that. I am generally suspicious of non-transient floating windows. - The Download Shelf is a special case - and in this case you could probably add code to the shelf's Paint function to render the resizer graphic at its bottom right. (BTW, thanks for dogfooding my windowing document. It's not finished yet as you can see but it is up to date at least!) -Ben On Fri, Dec 12, 2008 at 1:32 PM, Marc-Andre Decoste m...@google.com wrote: Salut, I'm working on the resize corner view and am having a little trouble getting it to work. I tried to use the sample code provided in http://dev.chromium.org/developers/design-documents/views-windowing, by doing as follows: in BrowserView::Init(), I create a label view and add it as a child of the contents_container_ in BrowserView::Layout(), I get the parent of the label, as well as the preferred size of the label and then do as follows: label-SetBounds((parent_view-width() - ps.width() )/ 2, (parent_view-height() - ps.height()) / 2, ps.width(), ps.height()); Then I run with a break point in Label::Paint() and it seems to do as it is told except... I don't see the Hello World text drawn anywhere... I also tried my own BrowserResizerView class which also has mouse event overrides and they never get called, only the Paint override which seems to be painting on a /dev/nul canvas... What am I doing wrong? Do we have more detailed documentation about this, or is http://dev.chromium.org/developers/design-documents/chromeviewsthe only source of info we currently have? Thanks! BYE MAD --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: What's missing in my view?
sorry, s/does/should/ On Mon, Dec 15, 2008 at 11:44 AM, Darin Fisher da...@chromium.org wrote: does the webkit resizer disappear when the download shelf appears? -darin On Mon, Dec 15, 2008 at 11:27 AM, Ben Goodger (Google) b...@chromium.orgwrote: A few thoughts on implementing the resizer: - Windows supports a resizer hit test code return value from WM_NCHITTEST. I think it's something like HTBOTTOMRIGHT (it's actually not HTGROWBOX, that doesn't work). When you return this value for coordinates in the resizer area, Windows will do the resizing for you automatically, just like it does for the window borders. Regardless of how you end up rendering the resizer, I think you should implement it this way for the event handling so that you're consistent with how we do resizing elsewhere. The right place to implement this is to add code to BrowserView::NonClientHitTest. The resizer is always a fixed size and location so that should be easy to add. - From what I understand WebKit supports rendering a a resizer. Apple relies on this API for Safari so I assume it is well supported. It seems like this would be simpler than adding a floating window or anything like that. I am generally suspicious of non-transient floating windows. - The Download Shelf is a special case - and in this case you could probably add code to the shelf's Paint function to render the resizer graphic at its bottom right. (BTW, thanks for dogfooding my windowing document. It's not finished yet as you can see but it is up to date at least!) -Ben On Fri, Dec 12, 2008 at 1:32 PM, Marc-Andre Decoste m...@google.com wrote: Salut, I'm working on the resize corner view and am having a little trouble getting it to work. I tried to use the sample code provided in http://dev.chromium.org/developers/design-documents/views-windowing, by doing as follows: in BrowserView::Init(), I create a label view and add it as a child of the contents_container_ in BrowserView::Layout(), I get the parent of the label, as well as the preferred size of the label and then do as follows: label-SetBounds((parent_view-width() - ps.width() )/ 2, (parent_view-height() - ps.height()) / 2, ps.width(), ps.height()); Then I run with a break point in Label::Paint() and it seems to do as it is told except... I don't see the Hello World text drawn anywhere... I also tried my own BrowserResizerView class which also has mouse event overrides and they never get called, only the Paint override which seems to be painting on a /dev/nul canvas... What am I doing wrong? Do we have more detailed documentation about this, or is http://dev.chromium.org/developers/design-documents/chromeviewsthe only source of info we currently have? Thanks! BYE MAD --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: What's missing in my view?
Yes that would be what would have to be done. The renderer would have to support showing/hiding it on demand. -Ben On Mon, Dec 15, 2008 at 11:44 AM, Darin Fisher da...@chromium.org wrote: does the webkit resizer disappear when the download shelf appears? -darin On Mon, Dec 15, 2008 at 11:27 AM, Ben Goodger (Google) b...@chromium.org wrote: A few thoughts on implementing the resizer: - Windows supports a resizer hit test code return value from WM_NCHITTEST. I think it's something like HTBOTTOMRIGHT (it's actually not HTGROWBOX, that doesn't work). When you return this value for coordinates in the resizer area, Windows will do the resizing for you automatically, just like it does for the window borders. Regardless of how you end up rendering the resizer, I think you should implement it this way for the event handling so that you're consistent with how we do resizing elsewhere. The right place to implement this is to add code to BrowserView::NonClientHitTest. The resizer is always a fixed size and location so that should be easy to add. - From what I understand WebKit supports rendering a a resizer. Apple relies on this API for Safari so I assume it is well supported. It seems like this would be simpler than adding a floating window or anything like that. I am generally suspicious of non-transient floating windows. - The Download Shelf is a special case - and in this case you could probably add code to the shelf's Paint function to render the resizer graphic at its bottom right. (BTW, thanks for dogfooding my windowing document. It's not finished yet as you can see but it is up to date at least!) -Ben On Fri, Dec 12, 2008 at 1:32 PM, Marc-Andre Decoste m...@google.com wrote: Salut, I'm working on the resize corner view and am having a little trouble getting it to work. I tried to use the sample code provided in http://dev.chromium.org/developers/design-documents/views-windowing, by doing as follows: in BrowserView::Init(), I create a label view and add it as a child of the contents_container_ in BrowserView::Layout(), I get the parent of the label, as well as the preferred size of the label and then do as follows: label-SetBounds((parent_view-width() - ps.width() )/ 2, (parent_view-height() - ps.height()) / 2, ps.width(), ps.height()); Then I run with a break point in Label::Paint() and it seems to do as it is told except... I don't see the Hello World text drawn anywhere... I also tried my own BrowserResizerView class which also has mouse event overrides and they never get called, only the Paint override which seems to be painting on a /dev/nul canvas... What am I doing wrong? Do we have more detailed documentation about this, or is http://dev.chromium.org/developers/design-documents/chromeviews the only source of info we currently have? Thanks! BYE MAD --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Inline spell checking.
It would be better if we could consult Google for spelling recommendations. It seems like I frequently misspell a word, get the red squiggly, get no recommendations from Chromium, then go to Google and it gets it exactly right. I know, this would be great for an extension. - a --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Inline spell checking.
Use this as the example extension for the extension design? On Mon, Dec 15, 2008 at 3:14 PM, Aaron Boodman a...@chromium.org wrote: It would be better if we could consult Google for spelling recommendations. It seems like I frequently misspell a word, get the red squiggly, get no recommendations from Chromium, then go to Google and it gets it exactly right. I know, this would be great for an extension. - a --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Inline spell checking.
On Mon, Dec 15, 2008 at 12:14 PM, Aaron Boodman a...@chromium.org wrote: It would be better if we could consult Google for spelling recommendations. It seems like I frequently misspell a word, get the red squiggly, get no recommendations from Chromium, then go to Google and it gets it exactly right. I know, this would be great for an extension. There is a bug in the current spellchecker where our suggestions don't work as well as they should. This was fixed a week or two ago on trunk. Brett --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Inline spell checking.
On Mon, Dec 15, 2008 at 12:14 PM, Aaron Boodman a...@chromium.org wrote: It would be better if we could consult Google for spelling recommendations. It seems like I frequently misspell a word, get the red squiggly, get no recommendations from Chromium, then go to Google and it gets it exactly right. The problem isn't technical, it's that to do that spell correction it'd involve sending all text form data up to a Google server. In fact, I believe Google Toolbar for IE already does it (glancing at this http://www.google.com/support/toolbar/bin/static.py?page=features.html page mentions spell check under the privacy section) But given the current perception of privacy and Chrome, I wonder if the negative perception of even an opt-in implementation would outweigh the user benefit in building in such a feature. (Consider how many people misunderstand our existing opt-in user metrics.) I agree it should be done as an extension -- hook keypresses on text input boxes and set a timer for contacting the server, etc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Inline spell checking.
On Mon, Dec 15, 2008 at 1:27 PM, Evan Martin e...@chromium.org wrote: The problem isn't technical, it's that to do that spell correction it'd involve sending all text form data up to a Google server. Only misspelled words, right? PK --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Inline spell checking.
We actually looked into this earlier. One thing that stopped us from doing so is that the corrections are not based on proper spelling, but based rather on searches and results. The masses are not always right, and we thought it might be strange for your dictionary to be offering you spelling corrections that were not actually correct, but rather popular. Subjective question: Is it really appropriate for your dictionary to suggest changing lozx to lolz? (Or a dictionary that thinks twelf is fine, because it's the name of a logic programming language, when in reality most people are probably looking for twelfth?) On Mon, Dec 15, 2008 at 1:43 PM, Peter Kasting pkast...@google.com wrote: On Mon, Dec 15, 2008 at 1:27 PM, Evan Martin e...@chromium.org wrote: The problem isn't technical, it's that to do that spell correction it'd involve sending all text form data up to a Google server. Only misspelled words, right? PK --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Inline spell checking.
On Mon, Dec 15, 2008 at 1:52 PM, Ian Fette i...@chromium.org wrote: We actually looked into this earlier. One thing that stopped us from doing so is that the corrections are not based on proper spelling, but based rather on searches and results. The masses are not always right, and we thought it might be strange for your dictionary to be offering you spelling corrections that were not actually correct, but rather popular. Subjective question: Is it really appropriate for your dictionary to suggest changing lozx to lolz? (Or a dictionary that thinks twelf is fine, because it's the name of a logic programming language, when in reality most people are probably looking for twelfth?) For me it is appropriate, since it is what I already do. I could see there perhaps being some UI that separates the google suggestions. My underlying complaint is really that the spell checker didn't seem to work well, so I'll wait and see if like Brett said, it's better on trunk. - a --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Inline spell checking.
Hi, I think (based on what Aaron Boodman said) that you could put a separator with the google suggestions and list at least the 2 top suggestions (3 will be good). Masses could be wrong, but with the 2 or 3 top suggestions I think that you could provide a more accurate rainbow of alternatives. Sorry, my english sucks, but I think that you get the point :) Cheers. On Mon, Dec 15, 2008 at 8:32 PM, Aaron Boodman a...@chromium.org wrote: For me it is appropriate, since it is what I already do. I could see there perhaps being some UI that separates the google suggestions. My underlying complaint is really that the spell checker didn't seem to work well, so I'll wait and see if like Brett said, it's better on trunk. - a --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Trunk build's biggest annoyances?
Google employees: in case you're not paying attention, this thread is public on chromium-dev. I want to do a Dev channel release from the trunk soon. I know there are a lot of issues with the current trunk because it hasn't had the same test exposure or release pressure as the 154 branch. I don't plan to get trunk to a Beta level of stability before releasing, but I would like to know what the biggest problems are so we can evaluate what needs to be fixed (or put under 'Known Issues'). I know there are bugs on file, but I'm trying to get a sense of the real burning issues from people who are actually using trunk (or trying to use it) every day. So... what are the 1-3 top issues you think need to get fixed on trunk to make it bearable for everyday use? My biggest peeve right now is the browser crash when you close an app window (at least once a day I take down my whole browser by closing my calendar. D'oh!). --Mark --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Trunk build's biggest annoyances?
On Mon, Dec 15, 2008 at 4:50 PM, Mark Larson (Google) m...@chromium.orgwrote: So... what are the 1-3 top issues you think need to get fixed on trunk to make it bearable for everyday use? Maximized mode is pretty awful in XP and Vista non-Aero. PK --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: bookmark menu
On Mon, Dec 15, 2008 at 4:50 PM, Darren Horrocks killallthehum...@gmail.com wrote: and as most people will only use the bookmark bar to access the other bookmarks button, Do you have data to back up this claim? PK --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Tree flakyness
Hello, As you all know, our tests are really flaky and are causing the tree to be red too often. I took a quick look at the test logs and compiled the stats about all the flakyness. UI TESTS: In the last 7 days, 188 ui tests failed. 47 of them failed more than 30 times. The biggest offenders: 122 BrowserTest.JavascriptAlertActivatesTab 85 UnloadTest.CrossSiteInfiniteUnloadAsync 82 ErrorPageTest.DNSError 78 UnloadTest.CrossSiteInfiniteBeforeUnloadAsync 52 BrowserTest.TabNavigationAccelerators 35 ChromeMainTest.SecondLaunch 35 AutomationProxyTest.GetTabCount 34 PreferenceServiceTest.PreservedWindowPlacementIsLoaded 34 AutomationProxyTest.GetBrowserWindow 34 AutomationProxyTest.GetActiveTabIndex I used to file bugs for all the flaky tests and disable them, but this approach did not work. We currently have 25 ui-tests that are disabled, and I don't think anyone is trying to fix them UNIT TESTS: This one is getting more stable. Nothing to report, but we have 13 disabled tests. PERF TESTS: The page cycler tests are often crashing. The offending code is in WebCore::ConsoleMessage::operator== which is a new function added a month ago. It's a bit late to start reverting this code though (was part of a v8 change), and hard to replicate on our dev machines (it never crashed in a debugger). If someone has time, it would be great if you could help debugging, mainly if you wrote any of these tests. Thanks Nicolas --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Tree flakyness
I have a fix pending for the CrossSite* ones. On Mon, Dec 15, 2008 at 4:58 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: Hello, As you all know, our tests are really flaky and are causing the tree to be red too often. I took a quick look at the test logs and compiled the stats about all the flakyness. UI TESTS: In the last 7 days, 188 ui tests failed. 47 of them failed more than 30 times. The biggest offenders: 122 BrowserTest.JavascriptAlertActivatesTab 85 UnloadTest.CrossSiteInfiniteUnloadAsync 82 ErrorPageTest.DNSError 78 UnloadTest.CrossSiteInfiniteBeforeUnloadAsync 52 BrowserTest.TabNavigationAccelerators 35 ChromeMainTest.SecondLaunch 35 AutomationProxyTest.GetTabCount 34 PreferenceServiceTest.PreservedWindowPlacementIsLoaded 34 AutomationProxyTest.GetBrowserWindow 34 AutomationProxyTest.GetActiveTabIndex I used to file bugs for all the flaky tests and disable them, but this approach did not work. We currently have 25 ui-tests that are disabled, and I don't think anyone is trying to fix them UNIT TESTS: This one is getting more stable. Nothing to report, but we have 13 disabled tests. PERF TESTS: The page cycler tests are often crashing. The offending code is in WebCore::ConsoleMessage::operator== which is a new function added a month ago. It's a bit late to start reverting this code though (was part of a v8 change), and hard to replicate on our dev machines (it never crashed in a debugger). If someone has time, it would be great if you could help debugging, mainly if you wrote any of these tests. Thanks Nicolas --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Trunk build's biggest annoyances?
I think http://crbug.com/5118 is one of my biggest annoyances. I'm a fan of tab dragging, and it's been fairly broken recently (at least in maximized mode). Patrick On Mon, Dec 15, 2008 at 4:50 PM, Mark Larson (Google) m...@chromium.org wrote: Google employees: in case you're not paying attention, this thread is public on chromium-dev. I want to do a Dev channel release from the trunk soon. I know there are a lot of issues with the current trunk because it hasn't had the same test exposure or release pressure as the 154 branch. I don't plan to get trunk to a Beta level of stability before releasing, but I would like to know what the biggest problems are so we can evaluate what needs to be fixed (or put under 'Known Issues'). I know there are bugs on file, but I'm trying to get a sense of the real burning issues from people who are actually using trunk (or trying to use it) every day. So... what are the 1-3 top issues you think need to get fixed on trunk to make it bearable for everyday use? My biggest peeve right now is the browser crash when you close an app window (at least once a day I take down my whole browser by closing my calendar. D'oh!). --Mark --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: bookmark menu
no, nothing i can give as a spreadsheet, hard fact, just what i have heard from people. to keep me from the effort of starting an argument that i wont win, because whoever's mind it is that decides this has already been made up, and this has less chance of getting in than the logo has of being changed to a photograph of hitler... On 16 Dec, 00:55, Peter Kasting pkast...@google.com wrote: On Mon, Dec 15, 2008 at 4:50 PM, Darren Horrocks killallthehum...@gmail.com wrote: and as most people will only use the bookmark bar to access the other bookmarks button, Do you have data to back up this claim? PK --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: bookmark menu
On Mon, Dec 15, 2008 at 5:02 PM, Bizzeh killallthehum...@gmail.com wrote: no, nothing i can give as a spreadsheet, hard fact, just what i have heard from people. to keep me from the effort of starting an argument that i wont win, because whoever's mind it is that decides this has already been made up, and this has less chance of getting in than the logo has of being changed to a photograph of hitler... *blink* I'd like to think the group is more open-minded than that. We just like to see something to back up claims about what is and isn't common. For example, I use the bookmark toolbar many times a day, and I never click Other bookmarks. But I recognize that I might just be an outlier, so I'd like to see broader data. - Pam On 16 Dec, 00:55, Peter Kasting pkast...@google.com wrote: On Mon, Dec 15, 2008 at 4:50 PM, Darren Horrocks killallthehum...@gmail.com wrote: and as most people will only use the bookmark bar to access the other bookmarks button, Do you have data to back up this claim? PK --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: bookmark menu
I wonder if it would make sense to reuse the existing star button for something like this. The behavior could be similar to the back button in that clicking is different from clicking-and-holding / clicking-and-dragging. Adam On Mon, Dec 15, 2008 at 4:50 PM, Darren Horrocks killallthehum...@gmail.com wrote: i have recently created a patch and submitted it to codereview http://codereview.chromium.org/14441/show the patch adds a menu button to the right of the address bar and the menu gives a menu of all the bookmarks within the bookmark manager and allows for a user to navigate to their bookmarks without the need for the bookmark bar or opening a new tab and then going to the bookmark button. the patch was designed for generally speeding up access to the users bookmarks, as this is one of the most complained about missing features that i have heard while in offices and around the web and around irc. IE7 has the star button, IE6 had the old style dropdown menu, safari also has the old style dropdown menu as with IE6. firefox and opera also have similar features directly on the main interface without the need to waste extra screen real estate on another toolbar we dont need. as this is at most a 28 pixel reduction in the width of the address bar, this is a far better use of the screen than 24 pixels of height in the form of an additional toolbar removing from the actual browser visability. and as most people will only use the bookmark bar to access the other bookmarks button, this truly is wasted space. Regards, Darren --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: bookmark menu
I am generally supportive of allowing users to put UI elements where they want, but I think the right context for this work is in allowing our toolbars to be customizable, as is possible in other software, rather than special casing this one particular issue. The end result for you, and others who have the same preferences is the same, but the way of getting there is much more powerful (and allows other people to create the configurations they want, too). -Ben On Mon, Dec 15, 2008 at 4:50 PM, Darren Horrocks killallthehum...@gmail.com wrote: i have recently created a patch and submitted it to codereview http://codereview.chromium.org/14441/show the patch adds a menu button to the right of the address bar and the menu gives a menu of all the bookmarks within the bookmark manager and allows for a user to navigate to their bookmarks without the need for the bookmark bar or opening a new tab and then going to the bookmark button. the patch was designed for generally speeding up access to the users bookmarks, as this is one of the most complained about missing features that i have heard while in offices and around the web and around irc. IE7 has the star button, IE6 had the old style dropdown menu, safari also has the old style dropdown menu as with IE6. firefox and opera also have similar features directly on the main interface without the need to waste extra screen real estate on another toolbar we dont need. as this is at most a 28 pixel reduction in the width of the address bar, this is a far better use of the screen than 24 pixels of height in the form of an additional toolbar removing from the actual browser visability. and as most people will only use the bookmark bar to access the other bookmarks button, this truly is wasted space. Regards, Darren --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: bookmark menu
Hi, I finally figured out what your trying to do, a place to quickly access your bookmarks. Which is really needed since it would be nice to have some sort of utility to quickly access your saved bookmarks. I think another icon would be needed since a UI with two same icons is not that great. So the real question is, how can we allow quick access to bookmarks with a few clicks. I like that idea, lets see what other people will say On Dec 15, 8:11 pm, Pam Greene p...@chromium.org wrote: On Mon, Dec 15, 2008 at 5:02 PM, Bizzeh killallthehum...@gmail.com wrote: no, nothing i can give as a spreadsheet, hard fact, just what i have heard from people. to keep me from the effort of starting an argument that i wont win, because whoever's mind it is that decides this has already been made up, and this has less chance of getting in than the logo has of being changed to a photograph of hitler... *blink* I'd like to think the group is more open-minded than that. We just like to see something to back up claims about what is and isn't common. For example, I use the bookmark toolbar many times a day, and I never click Other bookmarks. But I recognize that I might just be an outlier, so I'd like to see broader data. - Pam On 16 Dec, 00:55, Peter Kasting pkast...@google.com wrote: On Mon, Dec 15, 2008 at 4:50 PM, Darren Horrocks killallthehum...@gmail.com wrote: and as most people will only use the bookmark bar to access the other bookmarks button, Do you have data to back up this claim? PK --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: bookmark menu
this has totally missed the issue, the issue is not about user customisation, its about user experiance. nowhere did i mention anything about customising the toolbar, and nowhere did i limit it. what i did do, was reduce the amount of time needed to navigate bookmarks, and make it obvious that chrome actually has the feature. please, i am not some stupid kid who will fall for tactics such as avoiding the question, and creating unanswerable questions. congratulations on loosing a potential developer On 16 Dec, 01:16, Ben Goodger (Google) b...@chromium.org wrote: I am generally supportive of allowing users to put UI elements where they want, but I think the right context for this work is in allowing our toolbars to be customizable, as is possible in other software, rather than special casing this one particular issue. The end result for you, and others who have the same preferences is the same, but the way of getting there is much more powerful (and allows other people to create the configurations they want, too). -Ben On Mon, Dec 15, 2008 at 4:50 PM, Darren Horrocks killallthehum...@gmail.com wrote: i have recently created a patch and submitted it to codereview http://codereview.chromium.org/14441/show the patch adds a menu button to the right of the address bar and the menu gives a menu of all the bookmarks within the bookmark manager and allows for a user to navigate to their bookmarks without the need for the bookmark bar or opening a new tab and then going to the bookmark button. the patch was designed for generally speeding up access to the users bookmarks, as this is one of the most complained about missing features that i have heard while in offices and around the web and around irc. IE7 has the star button, IE6 had the old style dropdown menu, safari also has the old style dropdown menu as with IE6. firefox and opera also have similar features directly on the main interface without the need to waste extra screen real estate on another toolbar we dont need. as this is at most a 28 pixel reduction in the width of the address bar, this is a far better use of the screen than 24 pixels of height in the form of an additional toolbar removing from the actual browser visability. and as most people will only use the bookmark bar to access the other bookmarks button, this truly is wasted space. Regards, Darren- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: bookmark menu
Thanks for taking the time to send us your thoughts. Chrome functions as a project at scale by maintaining a set of development principles (some of which are outlined here: http://dev.chromium.org/developers/contributing-code ). One of these principles is encouraging communication with each other in a reasonable fashion. To be a successful member of the Chromium project, you should be mindful of the way we work and considerate of the principles that we think are important (such as communicating your ideas early, building consensus, backing up your arguments with data where appropriate, being prepared to have your ideas be challenged by your peers). Coming in and trying to blackmail us by saying we're losing a developer if we don't agree with you isn't going to work. If these values don't intersect with yours, then there may not be a good cultural fit for you in the Chromium project. -Ben On Mon, Dec 15, 2008 at 5:21 PM, Bizzeh killallthehum...@gmail.com wrote: this has totally missed the issue, the issue is not about user customisation, its about user experiance. nowhere did i mention anything about customising the toolbar, and nowhere did i limit it. what i did do, was reduce the amount of time needed to navigate bookmarks, and make it obvious that chrome actually has the feature. please, i am not some stupid kid who will fall for tactics such as avoiding the question, and creating unanswerable questions. congratulations on loosing a potential developer On 16 Dec, 01:16, Ben Goodger (Google) b...@chromium.org wrote: I am generally supportive of allowing users to put UI elements where they want, but I think the right context for this work is in allowing our toolbars to be customizable, as is possible in other software, rather than special casing this one particular issue. The end result for you, and others who have the same preferences is the same, but the way of getting there is much more powerful (and allows other people to create the configurations they want, too). -Ben On Mon, Dec 15, 2008 at 4:50 PM, Darren Horrocks killallthehum...@gmail.com wrote: i have recently created a patch and submitted it to codereview http://codereview.chromium.org/14441/show the patch adds a menu button to the right of the address bar and the menu gives a menu of all the bookmarks within the bookmark manager and allows for a user to navigate to their bookmarks without the need for the bookmark bar or opening a new tab and then going to the bookmark button. the patch was designed for generally speeding up access to the users bookmarks, as this is one of the most complained about missing features that i have heard while in offices and around the web and around irc. IE7 has the star button, IE6 had the old style dropdown menu, safari also has the old style dropdown menu as with IE6. firefox and opera also have similar features directly on the main interface without the need to waste extra screen real estate on another toolbar we dont need. as this is at most a 28 pixel reduction in the width of the address bar, this is a far better use of the screen than 24 pixels of height in the form of an additional toolbar removing from the actual browser visability. and as most people will only use the bookmark bar to access the other bookmarks button, this truly is wasted space. Regards, Darren- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: bookmark menu
this views do intersect with my own, however i do not feel that i was fairly treated. i feel as if i was treated as the kid that nobody wants around at school because everybody is fine as they are. what i have tried to introduce today is a feature that is a staple part of a browser, fast no-frills access to a users bookmarks. as this was met with critisism from the start, i tried the harder in order to win favour for compleating the feature. which was then met with why should we add it when we dont know if people want it, and it might mess up our image, which i have taken the liberty of translating we dont want to be anything like the other browsers at the detrement of our own browsers usability. i wasnt in any way trying to be nasty or offencive. i was simply speaking my mind about the situation in hand that should never have risen its head. the least i expected was for the feature i had taken the time to create to be considered, rather than instantly dismissed. Regards, Darren On 16 Dec, 01:32, Ben Goodger (Google) b...@chromium.org wrote: Thanks for taking the time to send us your thoughts. Chrome functions as a project at scale by maintaining a set of development principles (some of which are outlined here:http://dev.chromium.org/developers/contributing-code). One of these principles is encouraging communication with each other in a reasonable fashion. To be a successful member of the Chromium project, you should be mindful of the way we work and considerate of the principles that we think are important (such as communicating your ideas early, building consensus, backing up your arguments with data where appropriate, being prepared to have your ideas be challenged by your peers). Coming in and trying to blackmail us by saying we're losing a developer if we don't agree with you isn't going to work. If these values don't intersect with yours, then there may not be a good cultural fit for you in the Chromium project. -Ben On Mon, Dec 15, 2008 at 5:21 PM, Bizzeh killallthehum...@gmail.com wrote: this has totally missed the issue, the issue is not about user customisation, its about user experiance. nowhere did i mention anything about customising the toolbar, and nowhere did i limit it. what i did do, was reduce the amount of time needed to navigate bookmarks, and make it obvious that chrome actually has the feature. please, i am not some stupid kid who will fall for tactics such as avoiding the question, and creating unanswerable questions. congratulations on loosing a potential developer On 16 Dec, 01:16, Ben Goodger (Google) b...@chromium.org wrote: I am generally supportive of allowing users to put UI elements where they want, but I think the right context for this work is in allowing our toolbars to be customizable, as is possible in other software, rather than special casing this one particular issue. The end result for you, and others who have the same preferences is the same, but the way of getting there is much more powerful (and allows other people to create the configurations they want, too). -Ben On Mon, Dec 15, 2008 at 4:50 PM, Darren Horrocks killallthehum...@gmail.com wrote: i have recently created a patch and submitted it to codereview http://codereview.chromium.org/14441/show the patch adds a menu button to the right of the address bar and the menu gives a menu of all the bookmarks within the bookmark manager and allows for a user to navigate to their bookmarks without the need for the bookmark bar or opening a new tab and then going to the bookmark button. the patch was designed for generally speeding up access to the users bookmarks, as this is one of the most complained about missing features that i have heard while in offices and around the web and around irc. IE7 has the star button, IE6 had the old style dropdown menu, safari also has the old style dropdown menu as with IE6. firefox and opera also have similar features directly on the main interface without the need to waste extra screen real estate on another toolbar we dont need. as this is at most a 28 pixel reduction in the width of the address bar, this is a far better use of the screen than 24 pixels of height in the form of an additional toolbar removing from the actual browser visability. and as most people will only use the bookmark bar to access the other bookmarks button, this truly is wasted space. Regards, Darren- Hide quoted text - - Show quoted text -- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at
[chromium-dev] PSA: clobber build needed for windows
Landed a webkit merge today that requires a clobber build for windows. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Feature: Extra field to store tags for each bookmark item
Just a feature which is pretty useful. Currently, a bookmark is defined by the following: 1) Name 2) Url 3) Folder Would be nice to add another field such as Tag (or Label), where we could tag our own bookmarks. Personally, I have around 100+ websites bookmarked, some websites title don't reflect what the contents of the webpage has (most do), some title's have long descriptions, some have short descriptions, etc. It would be nice to tag each bookmark by anything, so when we search for something in the omnibox, or in the bookmark search, it will take account of that tag. A similar feature is what Firefox has, we can apply many tags that describe that bookmark. Then we could search them based on that tag. An example: I added http://www.w3.org/, I would like to tag that HTML, Standards, etc. Then I visit, http://www.htmldog.com I tag that HTML. When I search for HTML in my omnibox, it will see both of these websites. I believe it is a neat way to extend bookmarks, Google introduced Labels in E-Mails, which was a huge hit, why not apply Labels to bookmarks. Concerning how to develop that, creating an interface is relatively simple, we can extend the Edit Bookmark feature to add Tag support. Therefore tagging is optional. I don't know how the storage would be since currently we are using JSON, so we need to define a collection for Tags. I was hoping we could store everything as SQLite, but JSON was preferred for some reason. So what do you guys say, is it worth implementing? I could attempt starting it if a proper design plan is discussed. /m0 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Feature: Extra field to store tags for each bookmark item
On Mon, Dec 15, 2008 at 8:19 PM, Mohamed Mansour m0.interact...@gmail.comwrote: Would be nice to add another field such as Tag (or Label), where we could tag our own bookmarks. I think we've generally agreed internally that this has at least some utility, but we haven't been as sure how to make the UI useful and turn this into something that every user finds easy and helpful. We've been erring on the side of putting too little UI into bookmarks lest we introduce something we can never change or remove later once people have become dependent on it. Note that for many pages, fulltext search should pull them up in the address bar naturally, unless the tags never appear in the page. Bookmarked pages get a fulltext ranking boost, so even without tags, bookmarks can often be called up just by typing. So, my take is that we'd be willing to think about this, but I don't know how quickly we want to proceed. Lots of UI people are now on vacation, too, which will limit the amount of feedback you'll get in the near term. PK --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] porting views to linux/posix
Currently the test_shell uses GTK to create a basic rendering for Chromium. What are the plans so far on how to port the Views UI layout layer to linux? Will a widget toolkit such as GTK be used? Or maybe just use a more direct approach such as XLib. Using XLib to directly communicate with X server might provide some extra speed much like using the Win32 API for the Windows version of Views, but XLib might be a bit too low level. I'd like to see the wheels get rolling on porting Views over to linux. This will be a major leap in getting Chrome running on linux. I'm interesting in helping contribute code for porting views. So if anyone has suggestions, ideas, or comments please post them. Let's get some ideas flowing. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: porting views to linux/posix
I would like to see the plans on how would we approach the porting,many views use direct Win32 API calls for mouse events, keyboard, painting, etc. What would the proper way doing this, create a class with a bunch if if-defs and just calling that. If there are plans on what to do, I could spend time porting the correct way instead of doing it the incorrect way. /m0 On Tue, Dec 16, 2008 at 2:23 AM, joshthecoder jroessl...@gmail.com wrote: Currently the test_shell uses GTK to create a basic rendering for Chromium. What are the plans so far on how to port the Views UI layout layer to linux? Will a widget toolkit such as GTK be used? Or maybe just use a more direct approach such as XLib. Using XLib to directly communicate with X server might provide some extra speed much like using the Win32 API for the Windows version of Views, but XLib might be a bit too low level. I'd like to see the wheels get rolling on porting Views over to linux. This will be a major leap in getting Chrome running on linux. I'm interesting in helping contribute code for porting views. So if anyone has suggestions, ideas, or comments please post them. Let's get some ideas flowing. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Trunk build's biggest annoyances?
I'm not sure what the policy is for making up labels on the bug tracker, but I labeled these bugs SuperAnnoying. I filed and labeled another bug (space bar doesn't scroll window). Either my bug search skills suck or not that many people are dogfooding trunk. How can it be that no one noticed that the space bar doesn't scroll the page or that the Facebook home screen is rendered wrong? (Maybe these are very recent regressions?) Adam On Mon, Dec 15, 2008 at 5:01 PM, Patrick Johnson patr...@chromium.org wrote: I think http://crbug.com/5118 is one of my biggest annoyances. I'm a fan of tab dragging, and it's been fairly broken recently (at least in maximized mode). Patrick On Mon, Dec 15, 2008 at 4:50 PM, Mark Larson (Google) m...@chromium.org wrote: Google employees: in case you're not paying attention, this thread is public on chromium-dev. I want to do a Dev channel release from the trunk soon. I know there are a lot of issues with the current trunk because it hasn't had the same test exposure or release pressure as the 154 branch. I don't plan to get trunk to a Beta level of stability before releasing, but I would like to know what the biggest problems are so we can evaluate what needs to be fixed (or put under 'Known Issues'). I know there are bugs on file, but I'm trying to get a sense of the real burning issues from people who are actually using trunk (or trying to use it) every day. So... what are the 1-3 top issues you think need to get fixed on trunk to make it bearable for everyday use? My biggest peeve right now is the browser crash when you close an app window (at least once a day I take down my whole browser by closing my calendar. D'oh!). --Mark --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
