Rename ShellWindow* classes

Rename ShellWindow* classes
ShellWindow* -> AppWindow*
NativeShellWindow -> AppBaseWindow
Split AppWindowViews common code into AppBaseWindowViews

BUG=none

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=170212

[stevenjb, 2012-11-27 00:18:22]

I did the renaming based on the email thread.

I did not touch "ShellWindow" itself - there are a lot of places in the code
that refer to ShellWindow, so renaming them to AppWindowController, (and
AppWindowRegistrey?), etc. should be done separately I think. In the meanwhile,
"App Window" at the UI layer and "Shell Window" at the controller layer seems
like a reasonable separation.

[jeremya, 2012-11-27 04:51:45]

names LGTM

https://codereview.chromium.org/11280173/diff/1020/chrome/browser/ui/cocoa/ex...
File chrome/browser/ui/cocoa/extensions/app_window_cocoa.h (right):

https://codereview.chromium.org/11280173/diff/1020/chrome/browser/ui/cocoa/ex...
chrome/browser/ui/cocoa/extensions/app_window_cocoa.h:145:
scoped_nsobject<AppWindowController> window_controller_;
If we're thinking about renaming ShellWindow to AppWindowController, perhaps
this needs a new name?

[Ben Goodger (Google), 2012-11-27 16:45:34]

I'm confused by AppBaseWindow. Is it a subclass or superclass of AppWindow?

We have a convention in a lot of UI code of calling the Native interface
NativeFoo. e.g. NativeWidget. I'd tend to go for NativeAppWindow. It clearly
implies whoever subclasses is platform-specific code.

[stevenjb, 2012-11-27 17:24:26]

On 2012/11/27 16:45:34, Ben Goodger (Google) wrote:
> I'm confused by AppBaseWindow. Is it a subclass or superclass of AppWindow?
> 
> We have a convention in a lot of UI code of calling the Native interface
> NativeFoo. e.g. NativeWidget. I'd tend to go for NativeAppWindow. It clearly
> implies whoever subclasses is platform-specific code.

So then:

BaseWindow
NativeAppWindow
NativeAppWindowViews (code shared by AppWindowViews + AppPanelWindowViews)
AppWindowViews | AppPanelWindowViews
?

[stevenjb (google-dont-use), 2012-11-27 23:47:02]

On Tue, Nov 27, 2012 at 10:56 AM, Ben Goodger (Google) <ben@chromium.org>wrote:

> I'm not asking you to rename BaseWindow, I'm just asking that it not be
> used for inspiration for anything.
>
Fair enough


>
> ShellWindow->AppWindow
>
OK, this will be done separately (we were going to use AppWindowController,
but I am fine with just AppWindow)


> native interface-> NativeAppWindow
>
That's ClassA (AppBaseWindow in the current CL). I will change that.


> ShellWindowViews->NativeAppWindowViews et al.
>
So, we still need ClassB which contains the common implementation across
default and panel windows. I would propose either:

a) NativeApp[Default|Panel]WindowViews : NativeAppWindowViews :
NativeAppWindow : BaseWindow
or
b) NativeApp{Panel}WindowViews : NativeAppWindowViewsCommon :
NativeAppWindow : BaseWindow

I think that a) is more clear. Most of the code will deal with the
NativeAppWindow
interface, so this naming is a bit less critical.

Thanks,
-Steven


> -Ben
>
>
> On Tue, Nov 27, 2012 at 10:52 AM, Steven Bennetts <stevenjb@google.com>wrote:
>
>> I'd like to defer any renaming of "BaseWindow" for the moment (which
>> exists because the extensions code needs a common interface
>> for BrowserWindow, Panel, and app windows).
>>
>> I'm not sure what your suggesting for "AppWindow." Here's a better
>> description of the class hierarchy:
>>
>> 0. BaseWindow (common interface class for BrowserWindow, Panel, and app
>> windows)
>> 1. ClassA (common interface class for all native app window
>> implementations)
>> 2. ClassB (Views specific implementation common to both normal (shell)
>> app windows and app panels)
>> 3. [Native?]AppWindowViews | [Native?]AppPanelWindowViews (shell / panel
>> specific Views implementations)
>>
>> Note: There is no need for "ClassB" for OSX or Gtk (yet) since we do not
>> (yet) support app panels on those platforms, i.e. [Native?]AppWindowCocoa
>> derives directly from ClassA
>>
>> So:
>> 1. What should we name ClassA?
>> 2. What should we name ClassB?
>> 3. Should we prefix AppWindowViews, AppPanelWindowViews, AppWindowCocoa,
>> and AppWindowGtx with Native?
>>
>>
>>
>>
>>
>> On Tue, Nov 27, 2012 at 9:51 AM, Ben Goodger (Google)
<ben@chromium.org>wrote:
>>
>>> Oh. You're referring to BaseWindow a la BaseWindow that is the base
>>> interface of BrowserWindow?
>>>
>>> Yeah I don't like that interface name either, or the fact that app/panel
>>> windows inherit from an interface in chrome.
>>>
>>> What's wrong with AppWindow and NativeAppWindow (with NativeAppWindowFoo
>>> per-platform)./
>>>
>>>
>>> On Tue, Nov 27, 2012 at 9:24 AM, <stevenjb@chromium.org> wrote:
>>>
>>>> On 2012/11/27 16:45:34, Ben Goodger (Google) wrote:
>>>>
>>>>> I'm confused by AppBaseWindow. Is it a subclass or superclass of
>>>>> AppWindow?
>>>>>
>>>>
>>>>  We have a convention in a lot of UI code of calling the Native
>>>>> interface
>>>>> NativeFoo. e.g. NativeWidget. I'd tend to go for NativeAppWindow. It
>>>>> clearly
>>>>> implies whoever subclasses is platform-specific code.
>>>>>
>>>>
>>>> So then:
>>>>
>>>> BaseWindow
>>>> NativeAppWindow
>>>> NativeAppWindowViews (code shared by AppWindowViews +
>>>> AppPanelWindowViews)
>>>> AppWindowViews | AppPanelWindowViews
>>>> ?
>>>>
>>>>
>>>>
https://codereview.chromium.**org/11280173/<https://codereview.chromium.org/1...
>>>>
>>>
>>>
>>
>

[stevenjb, 2012-11-28 00:16:01]

Latest patch has the following naming:

NativeAppDefaultWindowViews : NativeAppWindowViews : NativeAppWindow :
BaseWindow

PTAL

[stevenjb, 2012-11-28 20:44:52]

ping?

[stevenjb, 2012-11-29 00:25:07]

OK, I un-extracted NativeAppDefaultWindowViews, so we only have 3 levels of
hierarchy.

separate CL  I will add Panel support to NativeAppWindowViews by extracting the
non-panel frame code into its own file, and making NativeAppWindowViews support
either panel or non-panel behavior.

PTAL

[Ben Goodger (Google), 2012-11-29 00:59:25]

lgtm

[commit-bot: I haz the power, 2012-11-29 02:09:35]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/stevenjb@chromium.org/11280173/2008