summaryrefslogtreecommitdiffstats
path: root/ash/accelerators/focus_manager_factory.h
Commit message (Collapse)AuthorAgeFilesLines
* Standardize usage of virtual/override/final specifiers.dcheng2014-10-271-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Google C++ style guide states: Explicitly annotate overrides of virtual functions or virtual destructors with an override or (less frequently) final specifier. Older (pre-C++11) code will use the virtual keyword as an inferior alternative annotation. For clarity, use exactly one of override, final, or virtual when declaring an override. To better conform to these guidelines, the following constructs have been rewritten: - if a base class has a virtual destructor, then: virtual ~Foo(); -> ~Foo() override; - virtual void Foo() override; -> void Foo() override; - virtual void Foo() override final; -> void Foo() final; This patch was automatically generated. The clang plugin can generate fixit hints, which are suggested edits when it is 100% sure it knows how to fix a problem. The hints from the clang plugin were applied to the source tree using the tool in https://codereview.chromium.org/598073004. BUG=417463 R=derat@chromium.org Review URL: https://codereview.chromium.org/680153002 Cr-Commit-Position: refs/heads/master@{#301490}
* replace OVERRIDE and FINAL with override and final in ash/mostynb2014-10-031-3/+3
| | | | | | | | BUG=417463 Review URL: https://codereview.chromium.org/621133002 Cr-Commit-Position: refs/heads/master@{#298040}
* Ensure that keystrokes sent to desktop chrome AURA don't make their way into ↵ananta@chromium.org2013-06-051-1/+2
| | | | | | | | | | | | | | | | | | | | | | | accelerator handling in ASH. ASH registers a focus manager factory which creates focus managers for top level widgets with a FocusManager::Delegate interface implementation which is used to process accelerators. We allow only one focus manager factory to exist at any given time, which means that the focus manager factory for ASH gets notified for subsequent focus manager creation requests, some of them from the desktop. This results in keystrokes for desktop widgets making their way to the ASH focus manager delegate. Fix is to pass in a bool flag desktop_widget in the NativeWidgetDelegate::OnNativeWidgetCreated method which is implemented by the Widget class. This flag when true causes the ASH focus manager to default to the default focus manager behavior, which is to create focus managers with a NULL delegate. BUG=246821 R=sky@chromium.org Review URL: https://codereview.chromium.org/15882009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@204331 0039d316-1c4b-4281-b951-d872f2087c98
* Remove #pragma once from ashajwong@chromium.org2012-07-111-1/+0
| | | | | | Review URL: https://chromiumcodereview.appspot.com/10693135 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@146075 0039d316-1c4b-4281-b951-d872f2087c98
* Let Chrome app handle Ash accelerators first if the app is launched as a window.yusukes@chromium.org2012-05-171-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, Ash accelerators are handled at a very early stage, right after a native key event is received by aura::RootWindowHost. This CL change the way of handling Ash accelerators as follows to make it more App friendly: 1. If no window is focused, handle an Ash accelerator immediately in ash/accelerators/accelerator_filter.cc in the same way as before. 2. Otherwise, do not handle it in ash/accelerators/accelerator_filter.cc but let a custom views::FocusManager handle it (see ash/shell.cc). There are 3 types of scenarios here depending on the type of the focused window: 2-a. If the focused window is a browser, and the browser is not for an app, let the custom focus manager pre-handle Ash accelerators before passing it to the browser (see PreHandleKeyboardEvent() in chrome/browser/ui/views/frame/browser_view.cc). 2-b. If the focused window is a browser, and the browser is for an app, let the app handle Ash accelerators first (see chrome/browser/ui/views/frame/browser_view.cc). If the accelerator is not consumed by the app, let the custom focus manager handle it. 2-c. If the focused window is not a browser, let the window handle Ash accelerators first. If the accelerator is not consumed by the window, then let the custom focus manager handle it. This means a WebView without the chrome/browser/ui/ layer can handle Ash accelerators first whenever needed. Other changes: chrome/browser/ui/views/frame/browser_view.cc: Support ET_KEY_RELEASED accelerators in BrowserView::PreHandleKeyboardEvent(). ui/views/focus/focus_manager.cc: Support ET_KEY_RELEASED accelerators. Also fix code for handing VKEY_MENU so that the Shift+Alt+ET_KEY_RELEASED accelerator for Ash could be handled correctly. This CL depends on http://codereview.chromium.org/10377158/ (by jochen), https://chromiumcodereview.appspot.com/10388023, http://codereview.chromium.org/10389035/, and https://chromiumcodereview.appspot.com/10332051/, and should not be submitted until the 4 CLs are landed. BUG=123856 TEST=ran aura_shell_unittests TEST=manual; launch Chromoting app as a window, connect to a Chromoting server, focus Chrome on the remote machine, press Ctrl-n, confirm a new window is opened on the remote machine. Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=135791 Review URL: https://chromiumcodereview.appspot.com/10134036 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@137629 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 135791 - Let Chrome app handle Ash accelerators first if the app is ↵yusukes@google.com2012-05-091-43/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | launched as a window. Currently, Ash accelerators are handled at a very early stage, right after a native key event is received by aura::RootWindowHost. This CL change the way of handling Ash accelerators as follows to make it more App friendly: 1. If no window is focused, handle an Ash accelerator in ash/accelerators/accelerator_filter.cc in the same way as before. 2. Otherwise, do not handle it in ash/accelerators/accelerator_filter.cc but let a custom views::FocusManager handle it (see ash/shell.cc). There are 3 types of scenarios here depending on the type of the focused window: 2-a. If the focused window is a browser, and the browser is not for an app, let the custom focus manager pre-handle Ash accelerators before passing it to the browser (see PreHandleKeyboardEvent() in chrome/browser/ui/views/frame/browser_view.cc). 2-b. If the focused window is a browser, and the browser is for an app, let the app handle Ash accelerators first (see chrome/browser/ui/views/frame/browser_view.cc). If the accelerator is not consumed by the app, let the custom focus manager handle it. 2-c. If the focused window is not a browser, let the window handle Ash accelerators first. If the accelerator is not consumed by the window, then let the custom focus manager handle it. This means a WebView (without chrome/browser/ layer) can handle Ash accelerators first whenever needed. Other changes: chrome/browser/ui/views/frame/browser_view.cc: Support ET_KEY_RELEASED accelerators in BrowserView::PreHandleKeyboardEvent(). ui/views/focus/focus_manager.cc: Support ET_KEY_RELEASED accelerators. Also fix code for handing VKEY_MENU so that the Shift+Alt+ET_KEY_RELEASED accelerator for Ash could be handled correctly. BUG=123856 TEST=ran aura_shell_unittests TEST=manual; launch Chromoting app as a window, connect to a Chromoting server, focus Chrome on the remote machine, press Ctrl-n, confirm a new window is opened on the remote machine. Review URL: https://chromiumcodereview.appspot.com/10134036 TBR=yusukes@google.com Review URL: https://chromiumcodereview.appspot.com/10384074 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@135978 0039d316-1c4b-4281-b951-d872f2087c98
* Let Chrome app handle Ash accelerators first if the app is launched as a window.yusukes@google.com2012-05-081-0/+43
Currently, Ash accelerators are handled at a very early stage, right after a native key event is received by aura::RootWindowHost. This CL change the way of handling Ash accelerators as follows to make it more App friendly: 1. If no window is focused, handle an Ash accelerator in ash/accelerators/accelerator_filter.cc in the same way as before. 2. Otherwise, do not handle it in ash/accelerators/accelerator_filter.cc but let a custom views::FocusManager handle it (see ash/shell.cc). There are 3 types of scenarios here depending on the type of the focused window: 2-a. If the focused window is a browser, and the browser is not for an app, let the custom focus manager pre-handle Ash accelerators before passing it to the browser (see PreHandleKeyboardEvent() in chrome/browser/ui/views/frame/browser_view.cc). 2-b. If the focused window is a browser, and the browser is for an app, let the app handle Ash accelerators first (see chrome/browser/ui/views/frame/browser_view.cc). If the accelerator is not consumed by the app, let the custom focus manager handle it. 2-c. If the focused window is not a browser, let the window handle Ash accelerators first. If the accelerator is not consumed by the window, then let the custom focus manager handle it. This means a WebView (without chrome/browser/ layer) can handle Ash accelerators first whenever needed. Other changes: chrome/browser/ui/views/frame/browser_view.cc: Support ET_KEY_RELEASED accelerators in BrowserView::PreHandleKeyboardEvent(). ui/views/focus/focus_manager.cc: Support ET_KEY_RELEASED accelerators. Also fix code for handing VKEY_MENU so that the Shift+Alt+ET_KEY_RELEASED accelerator for Ash could be handled correctly. BUG=123856 TEST=ran aura_shell_unittests TEST=manual; launch Chromoting app as a window, connect to a Chromoting server, focus Chrome on the remote machine, press Ctrl-n, confirm a new window is opened on the remote machine. Review URL: https://chromiumcodereview.appspot.com/10134036 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@135791 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-19 06:45:51 +0000