j...@gmail.com - Project Hosting on Google Code

User Profile		Updates

Earlier this year Nov 19, 2009 chromium issue 27626 (Blank favicons should have same icon in the bookmarkfolder a...) commented on - I would like us to use the globe icon everywhere. I will check in with the other ui folks and verify that this is ok. I would like us to use the globe icon everywhere. I will check in with the other ui folks and verify that this is ok. Nov 10, 2009 chromium issue 27284 (When dragging tabs, a browser window that touches the menu b...) commented on - I think it is that the menu bar is the easiest way to drag a window to the top of the screen and have it line up perfectly. If we made it target for tab drops, there would be no easy way to drag a tab out and align it to the top of the screen. You'd have to drag it downwards, release, grab the window chrome and then drag back up. I think it is that the menu bar is the easiest way to drag a window to the top of the screen and have it line up perfectly. If we made it target for tab drops, there would be no easy way to drag a tab out and align it to the top of the screen. You'd have to drag it downwards, release, grab the window chrome and then drag back up. Nov 10, 2009 chromium issue 27284 (When dragging tabs, a browser window that touches the menu b...) commented on - I think I disagree for a couple reasons: Historically, the mac menu bar has always been a safe target for drags, it is where you drag something to cancel the drag. In the case of windows it is a little different, but I still feel it is nice to have an area at the top of the screen you can use for detaching into a new window. Otherwise you'll always have a tab strip that tries to eat your tabs, and will have a harder time detaching a tab. I think I disagree for a couple reasons: Historically, the mac menu bar has always been a safe target for drags, it is where you drag something to cancel the drag. In the case of windows it is a little different, but I still feel it is nice to have an area at the top of the screen you can use for detaching into a new window. Otherwise you'll always have a tab strip that tries to eat your tabs, and will have a harder time detaching a tab. Nov 05, 2009 blacktree-secrets r61 (updated) committed - updated updated Nov 02, 2009 chromium issue 26457 (Bookmark folder icons are wrong) commented on - We should pull in the generic folder icon for our bookmark folder: I believe you can just request the icon for filetype 'fold' and you'll get the right thing. We should pull in the generic folder icon for our bookmark folder: I believe you can just request the icon for filetype 'fold' and you'll get the right thing. Oct 29, 2009 chromium issue 25941 (NTP-style bookmark bar stroke is wrong) commented on - This is a one line fix. The current border is drawing on a pixel boundary. NSRect drawRect = NSInsetRect(drawRect, 0.5, 0.5); Line width should be 1.0 This is a one line fix. The current border is drawing on a pixel boundary. NSRect drawRect = NSInsetRect(drawRect, 0.5, 0.5); Line width should be 1.0 Oct 26, 2009 chromium issue 21458 (Arial should never be used on the Mac for UI) commented on - This bug fills me with joy. This bug fills me with joy. Oct 20, 2009 chromium issue 25368 (Omnibox completion popup is too transparent) commented on - This looks like a job for CGSAddWindowFilter (it is in undocumented goodness) This looks like a job for CGSAddWindowFilter (it is in undocumented goodness) Oct 19, 2009 chromium issue 25205 (Chrome needs a "paste and match style" option) commented on - Agreed, right below paste, command-shift-option-v Contextual menu paste doesn't need it, that seems like more trouble than it is worth, and other apps don't bother. Agreed, right below paste, command-shift-option-v Contextual menu paste doesn't need it, that seems like more trouble than it is worth, and other apps don't bother. Oct 19, 2009 chromium issue 25205 (Chrome needs a "paste and match style" option) commented on - We should add this. We should add this. Oct 09, 2009 chromium issue 24349 (Single clicking in the address bar should not highlight all ...) commented on - There is strong consensus within the UI team that this is the right thing to do. I am as big a mac standards promoter as anyone, but I fully support this decision. Relying on platform guidelines is not going to encourage innovation. We feel that we should keep this behavior changed, add metrics, and reverse if data supports it. There is strong consensus within the UI team that this is the right thing to do. I am as big a mac standards promoter as anyone, but I fully support this decision. Relying on platform guidelines is not going to encourage innovation. We feel that we should keep this behavior changed, add metrics, and reverse if data supports it. Oct 09, 2009 chromium issue 24349 (Single clicking in the address bar should not highlight all ...) commented on - Re: number of clicks. I don't think it is number of clicks that is the problem. My main concern is behavior I've observed of novices using location bars. Very few know about triple click, and triple clicks are hard for some users to execute. It is poor UI when people have to resort to holding backspace, select all, or dragging to select the entire field. I generally believe we should stick to OS behaviors for standard fields, but omnibox is by no means a standard field. It is a custom control tailored to navigation. Re: number of clicks. I don't think it is number of clicks that is the problem. My main concern is behavior I've observed of novices using location bars. Very few know about triple click, and triple clicks are hard for some users to execute. It is poor UI when people have to resort to holding backspace, select all, or dragging to select the entire field. I generally believe we should stick to OS behaviors for standard fields, but omnibox is by no means a standard field. It is a custom control tailored to navigation. Oct 09, 2009 chromium issue 24349 (Single clicking in the address bar should not highlight all ...) commented on - I expect most of those would already work. I mostly pointed them out to show that a common edit operation (truncate path) is still a trivial operation. I expect most of those would already work. I mostly pointed them out to show that a common edit operation (truncate path) is still a trivial operation. Oct 09, 2009 chromium issue 24349 (Single clicking in the address bar should not highlight all ...) commented on - I strongly believe click-to-select is the best approach for most users. The most common location bar action is entering an entirely new url. This is especially important as this is our search box as well. I do think we can (partly) find a middle ground. How about this: Mouse down: select Mouse dragged: select a region Mouse dragged down: select to end Mouse dragged up: select to beginning Click and dwell (0.25sec), insert cursor <-- new behavior Alternatively, click and dwell could be used for dragging. Currently you have to click, then click and dwell I strongly believe click-to-select is the best approach for most users. The most common location bar action is entering an entirely new url. This is especially important as this is our search box as well. I do think we can (partly) find a middle ground. How about this: Mouse down: select Mouse dragged: select a region Mouse dragged down: select to end Mouse dragged up: select to beginning Click and dwell (0.25sec), insert cursor <-- new behavior Alternatively, click and dwell could be used for dragging. Currently you have to click, then click and dwell Oct 08, 2009 chromium issue 23941 (on dark themes, the close buttons are invisible) commented on - Your outburst makes me feel a little like a super hero, and a little like a garbage man. Your outburst makes me feel a little like a super hero, and a little like a garbage man. Oct 07, 2009 qsb-mac issue 348 (Searchable Items is not recursive) commented on - send the patch to me via jnj@? send the patch to me via jnj@? Oct 06, 2009 chromium issue 9732 (Fallback to site-search for URLs without Tab-to-search) commented on - I think it is fine if, for cases with a site that is invalid for site search, we simply beep if the user tries to pivot on it. Trying to match the next one down is unreliable behavior and it would be better if the user had to explicitly arrow down, training the system in the process. Ideally corp sites would implement opensearch or some similar protocol that we could use to search them instead. I think it is fine if, for cases with a site that is invalid for site search, we simply beep if the user tries to pivot on it. Trying to match the next one down is unreliable behavior and it would be better if the user had to explicitly arrow down, training the system in the process. Ideally corp sites would implement opensearch or some similar protocol that we could use to search them instead. Oct 05, 2009 chromium issue 20295 (Window buttons are two pixels too high) commented on - Primarily for visual balance. It'll help make the gap below the buttons less empty looking. Primarily for visual balance. It'll help make the gap below the buttons less empty looking. Oct 05, 2009 chromium issue 23823 (Report a bug or broken website should be in the menubar) commented on - help menu help menu Oct 02, 2009 chromium issue 22933 (OS X: Spell checker submenu looks different from other Cocoa...) commented on - this will look WAY better once the ACCEPTS languages stuff is implemented. It should only show english for most users. this will look WAY better once the ACCEPTS languages stuff is implemented. It should only show english for most users. Oct 01, 2009 chromium issue 17309 (Bookmark toolbar: Excessive vertical screen real-estate use ...) commented on - this is fixed. this is fixed. Sep 30, 2009 chromium issue 23268 (Browser actions: Implement badge) commented on - We should try a variety of fonts on each platform and pick the most legible. These are small enough that they all basically look the same. Badge overlay image attached. Just draw a round rect with corner radius 2 below this image. We should try a variety of fonts on each platform and pick the most legible. These are small enough that they all basically look the same. Badge overlay image attached. Just draw a round rect with corner radius 2 below this image. Sep 30, 2009 chromium issue 21444 (Tab image in "Press [Tab] to search" doesn't look Mac-ish) commented on - GRUMBLE, GRUMBLE... GRUMBLE, GRUMBLE... Sep 30, 2009 chromium issue 23268 (Browser actions: Implement badge) commented on - Updated image, better metrics to shoot for, basically 2px padding outside of text, and shorter strings tend to align to the left. If length is ever > 19px wide, I think we may want to center (otherwise it looks bad) Updated image, better metrics to shoot for, basically 2px padding outside of text, and shorter strings tend to align to the left. If length is ever > 19px wide, I think we may want to center (otherwise it looks bad) Sep 30, 2009 chromium issue 22178 (Tab close buttons look like lollipops that have fallen in di...) commented on - rather, use these, those were a bit too dark. rather, use these, those were a bit too dark. Sep 30, 2009 chromium issue 18438 (Text colors need to adapt to theme) commented on - The font coloring is correct. We are drawing the incorrect background behind inactive tabs. 1. Background tabs need to draw IDR_THEME_TAB_BACKGROUND as their pattern texture when themed 2. New tabs don't show the correct text color until the first redraw. perhaps we need another setNeedsDisplay: or check the setTextColor/binding? The font coloring is correct. We are drawing the incorrect background behind inactive tabs. 1. Background tabs need to draw IDR_THEME_TAB_BACKGROUND as their pattern texture when themed 2. New tabs don't show the correct text color until the first redraw. perhaps we need another setNeedsDisplay: or check the setTextColor/binding? Sep 30, 2009 chromium issue 23268 (Browser actions: Implement badge) commented on - I agree circle looks better, but a squarish badge won't look bad, I think it is better to have the character count. The min width should be the same as the height. I'm torn between centering or having it right aligned in that case. I agree circle looks better, but a squarish badge won't look bad, I think it is better to have the character count. The min width should be the same as the height. I'm torn between centering or having it right aligned in that case. Sep 30, 2009 chromium issue 23268 (Browser actions: Implement badge) commented on - Helvetica-Bold 10 Corners are rounded 2px Gradient: If we allow users to specify colors, we should take the color they give us and draw it at the top of the gradient. the bottom of the gradient can be a darker shade of the same Stroke: 1px, same as the bottom of the gradient color. Helvetica-Bold 10 Corners are rounded 2px Gradient: If we allow users to specify colors, we should take the color they give us and draw it at the top of the gradient. the bottom of the gradient can be a darker shade of the same Stroke: 1px, same as the bottom of the gradient color. Sep 30, 2009 chromium issue 23268 (Browser actions: Implement badge) commented on - Suggest the following treatment: allow positioning slightly outside the bounds of the button, allow color choice. I wish I had a bolder font, but we can experiment and decide what is best per platform. Suggest the following treatment: allow positioning slightly outside the bounds of the button, allow color choice. I wish I had a bolder font, but we can experiment and decide what is best per platform. Sep 30, 2009 chromium issue 23268 (Browser actions: Implement badge) commented on - sorry. meant round rect might be safer. sorry. meant round rect might be safer. Sep 30, 2009 chromium issue 23268 (Browser actions: Implement badge) commented on - I think the intent is to have an easy way for devs to put some dynamic content without worrying about a bunch of icon resources. If we simply give them control of a 3-5 character string value and color, you will be amazed with the unicode characters people come up with to provide meaning. I do think color is important for certain classes of notification (calendar upcoming meetings shouldn't be red, reader might want a more subtle notification). I think outline may be safer, but we'll need a thicker outer border. I think the intent is to have an easy way for devs to put some dynamic content without worrying about a bunch of icon resources. If we simply give them control of a 3-5 character string value and color, you will be amazed with the unicode characters people come up with to provide meaning. I do think color is important for certain classes of notification (calendar upcoming meetings shouldn't be red, reader might want a more subtle notification). I think outline may be safer, but we'll need a thicker outer border. Sep 30, 2009 blacktree-secrets r58 (display tweaks) committed - display tweaks display tweaks Sep 30, 2009 blacktree-secrets r57 (more icons) committed - more icons more icons Sep 28, 2009 blacktree-nocturne Glow.png (Glow background) file uploaded Sep 27, 2009 blacktree-secrets r56 (Dump caches when a new version is uploaded) committed - Dump caches when a new version is uploaded Dump caches when a new version is uploaded Sep 27, 2009 blacktree-secrets r55 (Changed icon loading) committed - Changed icon loading Changed icon loading Sep 27, 2009 blacktree-secrets r54 (fiddle with exporting) committed - fiddle with exporting fiddle with exporting Sep 27, 2009 blacktree-secrets r53 (fiddle with exporting) committed - fiddle with exporting fiddle with exporting Sep 27, 2009 blacktree-secrets issue 80 (new secrets not showing up) Status changed - Status: Fixed Status: Fixed Sep 27, 2009 blacktree-secrets r52 (Add icons) committed - Add icons Add icons Sep 27, 2009 blacktree-nocturne r17 (2.0.0) committed - 2.0.0 2.0.0 Sep 27, 2009 blacktree-nocturne Nocturne.2.0.0.zip (Nocturne 2.0.0 (10.5+)) file uploaded - Labels: Featured Labels: Featured Sep 27, 2009 blacktree-nocturne Nocturne.2.0.0.zip (Nocturne 2.0.0) file uploaded - Labels: Featured Labels: Featured Sep 27, 2009 blacktree-nocturne r16 (2.0.0) committed - 2.0.0 2.0.0 Sep 27, 2009 blacktree-nocturne r15 (remove old nib) committed - remove old nib remove old nib Sep 27, 2009 blacktree-nocturne r14 (2.0.0) committed - 2.0.0 2.0.0 Sep 22, 2009 chromium issue 18068 (MobileMe (me.com) shows blank page with the word "Unauthoriz...) commented on - works for me in 4.0.211.2 works for me in 4.0.211.2 Sep 21, 2009 blacktree-secrets r51 (add icons) committed - add icons add icons Sep 21, 2009 blacktree-secrets r49 (Updated informer for 10.6) committed - Updated informer for 10.6 Updated informer for 10.6 Sep 20, 2009 blacktree-secrets r47 (Updated appengine) committed - Updated appengine Updated appengine

issue 24349 (Single clicking in the address bar should not highlight all ...) commented on - I strongly believe click-to-select is the best approach for most users. The most common location bar action is entering an entirely new url. This is especially important as this is our search box as well. I do think we can (partly) find a middle ground. How about this: Mouse down: select Mouse dragged: select a region Mouse dragged down: select to end Mouse dragged up: select to beginning Click and dwell (0.25sec), insert cursor <-- new behavior Alternatively, click and dwell could be used for dragging. Currently you have to click, then click and dwell

I strongly believe click-to-select is the best approach for most users. The most common location bar action is entering an entirely new url. This is especially important as this is our search box as well. I do think we can (partly) find a middle ground. How about this: Mouse down: select Mouse dragged: select a region Mouse dragged down: select to end Mouse dragged up: select to beginning Click and dwell (0.25sec), insert cursor <-- new behavior Alternatively, click and dwell could be used for dragging. Currently you have to click, then click and dwell

Earlier this year