[chromium-dev] Context menu for title bar doesn't appear when a tab's context menu was open
The following is my reply on the Issue 5695 in the bugtracker. (http://
crbug.com/5695)
++
I think chrome browser lacks consistency in displaying context menu.
* Current State
context menu for the 'Tab' : Show up on right mouse button 'Release'
context menu for the 'App' : Show up on right mouse button 'Press'
This inconsistent concept (one by 'Release' and the other by 'Press')
is not natural (in the UI point of view) and can cause problems.
Currently, when the right mouse button is 'Pressed' on the title bar,
its handler seems to take following two steps in order.
1. Close the current context menu if it exists.
2. Create new context menu.
Processing two operations (Closing and Creating) at one time ('Press')
can cause conflict problems.
- If the current context menu is for an 'App', there's no problem. But
if it is for a 'Tab', it seems that above two steps come into the
conflict and doesn't work well.
*Suggestion *
So, Divide two operations (Closing and Creating) into seperate
handlers.
- Closing always on 'Press' and Creating always on 'Release'.
If this concept is applied, no conflict can occur.
- When the mouse button is 'Pressed', current (for a Tab or for an
App.)
context menu is closed and when the button is 'Released', new
context
menu is created.
And, it is natural that displaying context menu is always done by
'Release'
operation. (MS IE also uses this concept.)
* Suggested State:
context menu for the 'Tab' : Show up on right mouse button 'Release'
context menu for the 'App' : Show up on right mouse button 'Release'
++
I wanna know your opinions about this.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Context menu for title bar doesn't appear when a tab's context menu was open
The following is the reply written by me on bugtracker - Issue 5695.
http://crbug.com/5695
+++
I think chrome browser lacks consistency in displaying context menu.
* Current State
-
context menu for the 'Tab' : Show up on right mouse button 'Release'
context menu for the 'App' : Show up on right mouse button 'Press'
-
This inconsistent concept (one by 'Release' and the other by 'Press')
is not natural (in the UI point of view) and can cause problems.
Currently, when the right mouse button is 'Pressed' on the title bar,
its handler seems to take following two steps in order.
1. Close the current context menu if it exists.
2. Create new context menu.
Processing two operations (Closing and Creating) at one time ('Press')
can cause conflict problems.
- If the current context menu is for an 'App', there's no problem. But
if it is for a 'Tab', it seems that above two steps come into the
conflict and doesn't work well.
*Suggestion *
So, Divide two operations (Closing and Creating) into seperate
handlers.
- Closing always on 'Press' and Creating always on 'Release'.
If this concept is applied, no conflict can occur.
- When the mouse button is 'Pressed', current (for a Tab or for an
App.)
context menu is closed and when the button is 'Released', new
context
menu is created.
And, it is natural that displaying context menu is always done by
'Release'
operation. (MS IE also uses this concept.)
* Suggested State:
-
context menu for the 'Tab' : Show up on right mouse button 'Release'
context menu for the 'App' : Show up on right mouse button 'Release'
-
+++
I wanna know your opinions about this.
--~--~-~--~~~---~--~~
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: Context menu for title bar doesn't appear when a tab's context menu was open
On Fri, Jan 9, 2009 at 6:13 AM, DeArto20 sy3...@gmail.com wrote: The following is the reply written by me on bugtracker - Issue 5695. So... why are you mailing it to this list? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] The Process Question: How do we change WebKit code?
Dear People of Chromium, I've been thinking about the process of making changes to WebKit code in a logical and consistent fashion (note, that doesn't necessarily preclude sane). Until we've switched to the integration model, we are still in a vendor branch state and thus the process of tweaking WebKit code is not what you call a that-was-easy effort. Nevertheless, we must have a somewhat trivialized way of doing it. Here's what I've come up so far: A. If the change is to common code (WebCore proper, JavaScriptCore/wtf), make it upstream -- it will be picked up by our daily merges. B. If the change is to our port (platform/graphics/skia|chromium, etc.), you can do the following: 1) make the change downstream and make sure it doesn't break anything 2) submit the change upstream and get it reviewed/committed 3) reconcile any deltas that may have occurred during review process -- the merge custodian will thank you. The basic difference is making sure that the changes to our port work before they go upstream. It would certainly be more frustrating to wait for the daily merge to pick up your tweaks and find out that they were wrong. However, let's try to avoid situations where the change is stuck in WebKit review limbo or abandoned, leaving forked files in our vendor branch. I am not sure whether we need any special rules for these, aside from the occasional stark glare from the merge people. What do you think? Good rules, bad rules? Comments? Questions? Quirky and entertaining remarks? :DG --~--~-~--~~~---~--~~ 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: The Process Question: How do we change WebKit code?
http://sites.google.com/a/chromium.org/dev/developers/webkit-changes :DG On Fri, Jan 9, 2009 at 11:15 AM, Dimitri Glazkov dglaz...@google.com wrote: Dear People of Chromium, I've been thinking about the process of making changes to WebKit code in a logical and consistent fashion (note, that doesn't necessarily preclude sane). Until we've switched to the integration model, we are still in a vendor branch state and thus the process of tweaking WebKit code is not what you call a that-was-easy effort. Nevertheless, we must have a somewhat trivialized way of doing it. Here's what I've come up so far: A. If the change is to common code (WebCore proper, JavaScriptCore/wtf), make it upstream -- it will be picked up by our daily merges. B. If the change is to our port (platform/graphics/skia|chromium, etc.), you can do the following: 1) make the change downstream and make sure it doesn't break anything 2) submit the change upstream and get it reviewed/committed 3) reconcile any deltas that may have occurred during review process -- the merge custodian will thank you. The basic difference is making sure that the changes to our port work before they go upstream. It would certainly be more frustrating to wait for the daily merge to pick up your tweaks and find out that they were wrong. However, let's try to avoid situations where the change is stuck in WebKit review limbo or abandoned, leaving forked files in our vendor branch. I am not sure whether we need any special rules for these, aside from the occasional stark glare from the merge people. What do you think? Good rules, bad rules? Comments? Questions? Quirky and entertaining remarks? :DG --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Stabilization Effort Daily Report
*Report for 2009-1-8* As Eric pointed out, the progress we made was negated by new failures introduced by the most recent WebKit merge. This will likely continue to be a problem. If you have not yet resolved a layout test bug it would be good to take a break from the other bugs and tackle one. We are doing well on Purify and the other bugs but need to gain some ground on layout tests. A couple days focusing on layout tests would be really helpful I added a new chart to http://go/stable that shows the burndown for layout tests. It assumes we have until the end of the quarter. The rate of fixes needs to be about 9 a day if we are to hit our goal. If you are not fixing at least one a day then we are probably falling behind. It is a lot of work -- there just is no escaping the need to get these things fixed and the longer it takes us the more likely we are to be even further behind by the end of the quarter. I still need owners for these two bugs, please take one of these: Issue 5541 http://code.google.com/p/chromium/issues/detail?id=5541: REGRESSION: bad drop-shadow rendering Issue 5559 http://code.google.com/p/chromium/issues/detail?id=5559: REGRESSION: cannot select text in gmail compose using shift+click if scroll between clicks *Layout Tests* We had a net gain of 2 passing unit tests yesterday. We need to gain 9 each day to be on pace to complete by the end of March. Be sure to sign up at http://spreadsheets.google.com/ccc?key=pMwul3Seofg448Q1VFJjsJAhl=en if you are going to work on a layout test. We don't want to step on each other's toes. [image: All+Tests=76.5][image: Want+To+Pass=92.5] http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw [image: History of passing tests %]http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw All Tests is based on all available layout tests including those that we are currently not trying to pass. There are tests in this group which are known to be bad or relate to future technologies. Want to Pass is based on the tests that we need to be passing before we will ship a revision of the browser. Getting this number as high as possible is the goal of the stabilization effort. Some of these tests are failing due to subtle changes that require the test to be re-baselined. *Purify Bugs (Memory)* We have resolved 23 of the 42 Purify issues. We did not resolve a new Purify bug yesterday. *Regressions* We have resolved 13 of 25 regressions. We resolved one additional regression yesterday. *Other bugs* We have also resolved 18 of the 42 other bugs. We resolved one more since yesterday. So our bug burndown chart looks like this: As long as we keep the red line below the blue line we are on track for the bugs. Keep in mind that this does not include the work on Layout Tests. You will find a lot more information about the Stabilization effort on the Wiki at http://code.google.com/p/chromium/wiki/StabilizeTrunk --~--~-~--~~~---~--~~ 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: Context menu for title bar doesn't appear when a tab's context menu was open
I wanted know how others in this group think about my suggestion about above bug (issue 5695), If it is reasonable or not. On 1월10일, 오전1시49분, Peter Kasting pkast...@google.com wrote: On Fri, Jan 9, 2009 at 6:13 AM, DeArto20 sy3...@gmail.com wrote: The following is the reply written by me on bugtracker - Issue 5695. So... why are you mailing it to this list? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Stabilization Effort Daily Report
On Fri, Jan 9, 2009 at 11:32 AM, Jon j...@chromium.org wrote: Be sure to sign up at http://spreadsheets.google.com/ccc?key=pMwul3Seofg448Q1VFJjsJAhl=en if you are going to work on a layout test. We don't want to step on each other's toes. I just noticed Linux is on there. Has anyone else been working on Linux tests off of that sheet? I've just been fixing them directly and making my changes (and notes) on tests_fixable.txt. --~--~-~--~~~---~--~~ 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: Getting started, getting blocked...
I decided to start fresh, and downloaded the source tar-ball. Then
when I ran gclient sync, here is what I got:
$ gclient sync 21 | tee sync.log
running '/Users/mjaffe/Development/depot_tools/bin/../
platform/mac/bin/svn update' in '/Users/mjaffe/Development/Chrome/
chromium/src'
UDEPS
Updated to revision 7839.
running '/Users/mjaffe/Development/depot_tools/bin/../
platform/mac/bin/svn switch -r 7838 /trunk/deps/third_party/WebKit src/
third_party/WebKit' in '/Users/mjaffe/Development/Chrome/chromium'
svn: '/trunk/deps/third_party/WebKit' does not appear to be a URL
Error: failed to run command: /Users/mjaffe/Development/depot_tools/
bin/../platform/mac/bin/svn switch -r 7838 /trunk/deps/third_party/
WebKit src/third_party/WebKit
Odd that this works for everyone else but not me.
On Dec 19 2008, 4:21 pm, Marc-Antoine Ruel mar...@chromium.org
wrote:
You've been updated since svn: '.' is not a working copy is an
error I recently introduced on non-Windows platforms. You can safely
ignore it.
That's strange that you have svn version issues since we don't include
svn in the depot_tools on non-windows platform.
FYI, svn 1.4 can't read checkouts created by svn 1.5. You somehow got
a svn 1.5 checkout and are currently using a 1.4 svn client.
M-A
On Fri, Dec 19, 2008 at 7:16 PM, Jaff jaffe.m...@gmail.com wrote:
OK, now I cannot even use svn anymore, trying to do a new client
config yieds this error:
dhcp-172-19-240-54:~/Development/Google mjaffe$ gclient sync
svn: '.' is not a working copy
svn: This client is too old to work with working copy '/Users/mjaffe/
Development/Google/src'; please get a newer Subversion client
Traceback (most recent call last):
File /Users/mjaffe/Development/chrome_depot_tools/release/
gclient.py, line 1057, in module
result = Main(sys.argv)
File /Users/mjaffe/Development/chrome_depot_tools/release/
gclient.py, line 1052, in Main
return DispatchCommand(command, options, args)
File /Users/mjaffe/Development/chrome_depot_tools/release/
gclient.py, line 999, in DispatchCommand
return command_map[command](options, args)
File /Users/mjaffe/Development/chrome_depot_tools/release/
gclient.py, line 950, in DoUpdate
return client.RunOnDeps('update', args)
File /Users/mjaffe/Development/chrome_depot_tools/release/
gclient.py, line 834, in RunOnDeps
scm.RunCommand(command, self._options, args)
File /Users/mjaffe/Development/chrome_depot_tools/release/
gclient.py, line 444, in RunCommand
self.update(options, args)
I don't know what version of svn I should be using. Would not the one
in my local tools dir work?
Mark
On Dec 19, 1:30 pm, Jaff jaffe.m...@gmail.com wrote:
OK, here is the contents of .gclient
# An element of this array (a solution) describes a repository
directory that
# will be checked out into your working copy. Each solution may
optionally define
# additional dependencies (via its DEPS file) to be checked out
alongside the
# solution's directory. A solution may also specify custom
dependencies (via
# the custom_deps property) that override or augment the
dependencies
# specified by the DEPS file.
solutions = [
{ name : src,
url : http://src.chromium.org/svn/trunk/src;,
custom_deps : {
# To use the sandbox trunk instead, uncomment:
#sandbox: https://svn/chrome/trunk/sandbox;,
# To exclude the page_cycler from your working copy, uncomment:
#data/page_cycler: None,
}
}
]
On Dec 19, 1:09 pm, Mark Larson (Google) m...@chromium.org wrote:
On Fri, Dec 19, 2008 at 13:01, Jaff jaffe.m...@gmail.com wrote:
Well, this is too strange. It would seem as if some other file-system
mechanism is cacheing
data. I created a new directory and attempted a fresh checkout, and it
crashes/halts in exactly the same place. Complains about src/
third_party/WebKit:
svn: '/trunk/deps/third_party/web...@7278' does not appear to be a URL
It looks like a bad configuration in your .gclient. Can you post it?
I need someone to confirm they can do a fresh checkout on a machine
which did not have the code on it already.
Thanks,
me
On Dec 18, 1:17 pm, Marc-Antoine Ruel mar...@chromium.org wrote:
Probably my fault, let me confirm.
M-A
On Thu, Dec 18, 2008 at 3:34 PM, Jaff jaffe.m...@gmail.com wrote:
Hi,
I've been wanting to get into some contribution-mode, so I have
gotten
far enough to download the source and make my environment
compatible
(MacbookPro, 2.4GHz, 2Gb RAM). However, on Tuesday, the svn
repository
seemed to be offline for about an hour or so while I was trying to
get
sync'ed, then yesterday I seemed able to get source downloaded,
but I
only got this far:
A src/testing/gtest/Makefile.am
A src/testing/gtest/README
[chromium-dev] Re: V8Bindings_prebuild slowness
On Sun, Jan 4, 2009 at 5:44 PM, t...@chromium.org wrote: On Sun, 4 Jan 2009, Brett Wilson wrote: On Sun, Jan 4, 2009 at 1:23 PM, Darin Fisher da...@chromium.org wrote: This problem could also be solved by ignoring DerivedSources.make, and instead just add the source files to the vcproj. Then write a custom .rules file for each file type that runs the appropriate batch command to create the generated file. Then, dependency tracking would work just as it does for .cpp files. Well, but you'd still have the slowness of spawing perl hundreds of times. I'm not sure that would speed up the build at all (though it would improve the dependency management). But you would only pay it once. Using native vcproj files may get the dependencies right and maybe you wouldn't need to do a full rebuild after each sync then. Or maybe I put too much faith in MSVC's dependency management. Right. This is what I was thinking too. I do clobber builds primarily (only?) because of issues related to DerivedSources. Our DerivedSources.make is already so tremendously out of sync with the one upstream that there doesn't seem to be much point in using it. I agree. It's not used in the scons build which properly tracks dependencies so the files are only generated once. Would Incredibuild be able to parallelize the perl scripts or does it only know how to parallelize c++ compiles? That's a great question :) I suspect it only runs those locally. -Darin --~--~-~--~~~---~--~~ 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: V8Bindings_prebuild slowness
On Fri, Jan 9, 2009 at 3:37 PM, Darin Fisher da...@chromium.org wrote: On Sun, Jan 4, 2009 at 5:44 PM, t...@chromium.org wrote: On Sun, 4 Jan 2009, Brett Wilson wrote: On Sun, Jan 4, 2009 at 1:23 PM, Darin Fisher da...@chromium.org wrote: This problem could also be solved by ignoring DerivedSources.make, and instead just add the source files to the vcproj. Then write a custom .rules file for each file type that runs the appropriate batch command to create the generated file. Then, dependency tracking would work just as it does for .cpp files. Well, but you'd still have the slowness of spawing perl hundreds of times. I'm not sure that would speed up the build at all (though it would improve the dependency management). But you would only pay it once. Using native vcproj files may get the dependencies right and maybe you wouldn't need to do a full rebuild after each sync then. Or maybe I put too much faith in MSVC's dependency management. Right. This is what I was thinking too. I do clobber builds primarily (only?) because of issues related to DerivedSources. Our DerivedSources.make is already so tremendously out of sync with the one upstream that there doesn't seem to be much point in using it. I agree. It's not used in the scons build which properly tracks dependencies so the files are only generated once. Would Incredibuild be able to parallelize the perl scripts or does it only know how to parallelize c++ compiles? That's a great question :) I suspect it only runs those locally. Without an additional extension license, only locally. But if it only had to do it once, that'd still be a big help. Alternatively, if we find we still need to speed clobber builds and are willing to move away from DerivedSources.make, I'd expect that only launching perl once rather than 200+ times -- just move the do this for every file in this long list from make into perl -- would provide a dramatic speedup. - Pam -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
