chromeos: Refactor system tray Wi-Fi connect dialog so it works with mash

ash/mus/network_connect_delegate_mus.h

Index: ash/mus/network_connect_delegate_mus.h
diff --git a/ash/mus/network_connect_delegate_mus.h b/ash/mus/network_connect_delegate_mus.h
new file mode 100644
index 0000000000000000000000000000000000000000..1cd5a2786a19b964080b61d40b78440a24ee1c97
--- /dev/null
+++ b/ash/mus/network_connect_delegate_mus.h
@@ -0,0 +1,37 @@
+// Copyright 2016 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.
+
+#ifndef ASH_MUS_NETWORK_CONNECT_DELEGATE_MUS_H_
+#define ASH_MUS_NETWORK_CONNECT_DELEGATE_MUS_H_
+
+#include "base/macros.h"
+#include "ui/chromeos/network/network_connect.h"
+
+namespace ash {
+namespace mus {
+
+// Routes requests to show network config UI over the mojom::SystemTrayClient
+// interface.
+// TODO(mash): Replace ui::NetworkConnect::Delegate with a client interface on
+// a mojo NetworkConfig service. http://crbug.com/644355

[stevenjb, 2016/10/14 20:08:26]

This is a little different from what is so far discussed in
http://crbug.com/644355.

This delegate specifically exists to show UI elements and should be a separate
interface from any network configuration (which actually does the
configuration).

This may be easier to discuss in person.

[James Cook, 2016/10/14 20:50:22]

Yeah, it might. The issue is that the underlying network connect code will
occasionally need to ask for a piece of UI to be created. The typical way to do
this is to have an interface like:

interface NetworkConfig {
  SetClient(NetworkConfigClient client);

  TryToConnectToNetwork();
}

interface NetworkConfigClient {
  ShowDialogAskingForCredentials();
}

Ideally this service lives in //chromeos/network (but it can't right now due to
code in //ui/chromeos/network).

Then when chrome starts up it connects to the NetworkConfig service and sets
itself as a client.

So that's what I mean by "a client interface on a mojo NetworkConfig service".

Either way, though, I need to implement this delegate if I want to be able to
show a password input dialog.

[stevenjb, 2016/10/14 22:33:38]

Maybe just for now word this something like like:
// TODO(mash): Replace this with a mojo service to handle network config UI
requests. See crbug.com/644355.

+class NetworkConnectDelegateMus : public ui::NetworkConnect::Delegate {
+ public:
+  NetworkConnectDelegateMus();
+  ~NetworkConnectDelegateMus() override;
+
+  // ui::NetworkConnect::Delegate:
+  void ShowNetworkConfigure(const std::string& service_path) override;
+  void ShowNetworkSettingsForGuid(const std::string& network_id) override;

[stevenjb, 2016/10/14 20:08:26]

Ugh. I'd really kind of like to clean these up first, but we can live with it I
guess. Having both 'service_path' and 'network_id' (guid) in the interface is
super confusing.

[James Cook, 2016/10/14 20:50:22]

Yeah. Frankly, I don't really know much about when you would have one over the
other. It's hard to tell when running on desktop if the stub ids are
representative of what's on the device (for example, the "ForGuid" method
receives strings that are not guids when running on desktop). So I just kept
what we had.

[stevenjb, 2016/10/14 22:33:38]

service_path is the Shill name for the network. The UI code shouldn't care about
that detail. 'network_id' is the unique identifier for the network and is what
the UI should use.

I'll plan to clean this up in the delegate. Fixing these at the same time will
be no big deal.

+  bool ShowEnrollNetwork(const std::string& network_id) override;
+  void ShowMobileSimDialog() override;
+  void ShowMobileSetupDialog(const std::string& service_path) override;
+
+ private:
+  DISALLOW_COPY_AND_ASSIGN(NetworkConnectDelegateMus);
+};
+
+}  // namespace mus
+}  // namespace ash
+
+#endif  // ASH_MUS_NETWORK_CONNECT_DELEGATE_MUS_H_