Linux Aura: Use system title bar is now set by preference, not flag.

chrome/browser/ui/browser_view_prefs.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "chrome/browser/ui/browser_view_prefs.h"
 
 #include "base/prefs/pref_registry_simple.h"
 #include "chrome/common/pref_names.h"
+#include "components/user_prefs/pref_registry_syncable.h"
 
 namespace {
 
 // How long do we wait before we consider a window hung (in ms).
 const int kDefaultPluginMessageResponseTimeout = 25000;
 
 // How frequently we check for hung plugin windows.
 const int kDefaultHungPluginDetectFrequency = 2000;
 
 }  // namespace
 
 namespace chrome {
 
 void RegisterBrowserViewPrefs(PrefRegistrySimple* registry) {
   registry->RegisterIntegerPref(prefs::kPluginMessageResponseTimeout,
                                 kDefaultPluginMessageResponseTimeout);
   registry->RegisterIntegerPref(prefs::kHungPluginDetectFrequency,
                                 kDefaultHungPluginDetectFrequency);
 }
 
+void RegisterBrowserViewSyncablePrefs(
+    user_prefs::PrefRegistrySyncable* registry) {
+  // TODO(mgiuca): Decide on this default depending on the window manager. See
+  // BrowserWindowGtk::GetCustomFramePrefDefault.
+  bool custom_frame_default = true;
+
+  registry->RegisterBooleanPref(
+      prefs::kUseCustomChromeFrame,
+      custom_frame_default,
+      user_prefs::PrefRegistrySyncable::UNSYNCABLE_PREF);

[msw, 2014/02/06 00:50:27]

nit: why is the function called RegisterBrowserView*Syncable*Prefs if this pref
is an UNSYNCABLE_PREF? Can you clarify the syncability?

[Pam (message me for reviews), 2014/02/06 10:31:27]

It's because the method takes a PrefRegistrySyncable, because of how and when
it's called. We could in principle reorganize browser_prefs.cc a bit to allow
classes that only need UNSYNCABLE_PREFs to make that self-evident by using a
PrefRegistrySimple instead, but right now this is the consistent way to register
profile prefs, even if they don't want to be synced.

Naming this RegisterBrowserViewProfilePrefs, and renaming
RegisterBrowserViewPrefs to RegisterBrowserViewLocalPrefs, would make it all
clearer.

[Matt Giuca, 2014/02/11 04:57:43]

Are you saying I should do that renaming now?

It's a little unclear to me. What is a "local pref"? Is it the same thing as a
SimplePref? Why not call it RegisterBrowserViewSimplePrefs (instead of
LocalPrefs).

A SyncablePref is not necessarily a pref that is synced, it's a pref whose
syncability is customizable. Once you understand what a SyncablePref is, it
doesn't seem like RegisterBrowserViewSyncablePrefs is an inappropriate name.

[msw, 2014/02/11 19:32:59]

Can't you just use the existing RegisterBrowserViewPrefs above to register this
un-syncable pref with the PrefRegistrySimple interface?

[Matt Giuca, 2014/02/12 01:09:18]

I assumed that the simple pref registry would cause it to be synced by default.
I was just copying the code for the existing GTK implementation, which
explicitly uses PrefRegistrySyncable to register this as an unsyncable pref.

Maybe pam can elaborate; I'm not too familiar with the pref registry system.

+}
+
 }  // namespace chrome