Add enable-app-launcher-shim to chrome://flags.

Add enable-app-launcher-shim to chrome://flags. 

Adds a flag for --enable-app-launcher-shim to chrome://flags. Enable to 
ensure an OSX app bundle for the App Launcher exists under the 
Applications folder. If the flag is not present any previously created 
app bundle for the App Launcher will be deleted on startup. 

BUG=138633
TEST=Tested enabling and disabling the flag in chrome://flags.

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

[tapted, 2013-05-29 06:27:40]

Ben, could you take a look. (I noticed an oopsie in the switches when checking
to see if the comment needed updating too..., but the change is effectively a
no-op as far as the compiler is concerned).

[benwells, 2013-05-29 06:33:38]

https://codereview.chromium.org/15675008/diff/1/chrome/browser/about_flags.cc
File chrome/browser/about_flags.cc (right):

https://codereview.chromium.org/15675008/diff/1/chrome/browser/about_flags.cc...
chrome/browser/about_flags.cc:1473: switches::kEnableAppListShim, "1",
I don't remember the windows one being so complicated. Why not imply disable
from lack of the switch?

[tapted, 2013-05-29 06:37:24]

https://codereview.chromium.org/15675008/diff/1/chrome/browser/about_flags.cc
File chrome/browser/about_flags.cc (right):

https://codereview.chromium.org/15675008/diff/1/chrome/browser/about_flags.cc...
chrome/browser/about_flags.cc:1473: switches::kEnableAppListShim, "1",
On 2013/05/29 06:33:38, benwells wrote:
> I don't remember the windows one being so complicated. Why not imply disable
> from lack of the switch?

The rationale for doing it this way is that it avoids a by-default post-task to
the file thread to ensure that it doesn't exist, on everyone's Chrome startup.

But, if we don't care about that, I'm happy to change it :D

[jackhou1, 2013-05-29 06:59:19]

https://codereview.chromium.org/15675008/diff/1/chrome/app/generated_resource...
File chrome/app/generated_resources.grd (right):

https://codereview.chromium.org/15675008/diff/1/chrome/app/generated_resource...
chrome/app/generated_resources.grd:7107: +      <if expr="is_macosx">
What's the convention for where to put these? Should it be after
ENABLE_RESET_PROFILE_SETTINGS_DESCRIPTION like in about_flags.cc?

[benwells, 2013-05-29 07:07:40]

On 2013/05/29 06:37:24, tapted wrote:
> https://codereview.chromium.org/15675008/diff/1/chrome/browser/about_flags.cc
> File chrome/browser/about_flags.cc (right):
> 
>
https://codereview.chromium.org/15675008/diff/1/chrome/browser/about_flags.cc...
> chrome/browser/about_flags.cc:1473: switches::kEnableAppListShim, "1",
> On 2013/05/29 06:33:38, benwells wrote:
> > I don't remember the windows one being so complicated. Why not imply disable
> > from lack of the switch?
> 
> The rationale for doing it this way is that it avoids a by-default post-task
to
> the file thread to ensure that it doesn't exist, on everyone's Chrome startup.
> 
> But, if we don't care about that, I'm happy to change it :D

I think we should change it. The flag is a temporary thing and this just makes
the flag confusing.

[tapted, 2013-05-29 07:11:12]

On 2013/05/29 06:59:19, jackhou1 wrote:
>
https://codereview.chromium.org/15675008/diff/1/chrome/app/generated_resource...
> File chrome/app/generated_resources.grd (right):
> 
>
https://codereview.chromium.org/15675008/diff/1/chrome/app/generated_resource...
> chrome/app/generated_resources.grd:7107: +      <if expr="is_macosx">
> What's the convention for where to put these? Should it be after
> ENABLE_RESET_PROFILE_SETTINGS_DESCRIPTION like in about_flags.cc?

An apt question. It's actually a horrible mess ;)

IDS_FLAGS_ENABLE_RESET_PROFILE_SETTINGS_DESCRIPTION is placed randomly in
generated_resources.grd -- it's not at the end of the list of about flags
strings.

The one before that, IDS_FLAGS_ENABLE_DRAGGABLE_MENU_BUTTON_DESCRIPTION, is
closer to the end. But it actually comes after a whole bunch of layout settings
for about://flags like IDS_FLAGS_DEFAULT_TILE_HEIGHT_VENTI -- not other flags.

So I aimed for ~"alphabetically". when trying to place this one. But I'm open to
better suggestions.

[tapted, 2013-05-29 07:19:52]

On 2013/05/29 07:07:40, benwells wrote:
> I think we should change it. The flag is a temporary thing and this just makes
> the flag confusing.

Done.

On 2013/05/29 07:11:12, tapted wrote:
> So I aimed for ~"alphabetically". when trying to place this one. But I'm open
to
> better suggestions.

I've moved the grd change to come just before the next section: <!-- Crashes
-->. On balance, I think this is the least evil place for it.

[jackhou1, 2013-05-29 07:21:42]

On 2013/05/29 07:11:12, tapted wrote:
> On 2013/05/29 06:59:19, jackhou1 wrote:
> >
>
https://codereview.chromium.org/15675008/diff/1/chrome/app/generated_resource...
> > File chrome/app/generated_resources.grd (right):
> > 
> >
>
https://codereview.chromium.org/15675008/diff/1/chrome/app/generated_resource...
> > chrome/app/generated_resources.grd:7107: +      <if expr="is_macosx">
> > What's the convention for where to put these? Should it be after
> > ENABLE_RESET_PROFILE_SETTINGS_DESCRIPTION like in about_flags.cc?
> 
> An apt question. It's actually a horrible mess ;)
> 
> IDS_FLAGS_ENABLE_RESET_PROFILE_SETTINGS_DESCRIPTION is placed randomly in
> generated_resources.grd -- it's not at the end of the list of about flags
> strings.
> 
> The one before that, IDS_FLAGS_ENABLE_DRAGGABLE_MENU_BUTTON_DESCRIPTION, is
> closer to the end. But it actually comes after a whole bunch of layout
settings
> for about://flags like IDS_FLAGS_DEFAULT_TILE_HEIGHT_VENTI -- not other flags.
> 
> So I aimed for ~"alphabetically". when trying to place this one. But I'm open
to
> better suggestions.

Ah I see. I have no preference then.

[benwells, 2013-05-29 07:23:40]

lgtm

[commit-bot: I haz the power, 2013-05-29 07:26:07]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/tapted@chromium.org/15675008/16001

[commit-bot: I haz the power, 2013-05-29 11:28:03]

Change committed as 202838