Make FlApplication class

[robert-ancell]

Move all the current behaviour of the Linux template into FlApplication. An app can now be:

#include <flutter_linux/flutter_linux.h>

#include "flutter/generated_plugin_registrant.h"

static void register_plugins_cb(FlApplication *app, FlPluginRegistry *registry)
{
  fl_register_plugins(registry);
}

int main(int argc, char** argv) {
  g_autoptr(FlApplication) app = fl_application_new(APPLICATION_ID, G_APPLICATION_NON_UNIQUE);
  g_signal_connect(app, "register-plugins", G_CALLBACK(register_plugins_cb), nullptr);
  fl_application_set_default_window_title(app, "flutter_application_test");
  fl_application_set_default_window_size(app, 1280, 720);
  return g_application_run(G_APPLICATION(app), argc, argv);
}

With this simplified, we can now build multi-window behaviour without having to modify the template much in the future.

This change is similar to what was proposed in #50868, but instead it only contains the current behaviour that we can build off.

Fixes flutter/flutter#142920

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group.

[robert-ancell]

cc @jane400

[cbracken]

Overall this looks great; @loic-sharma or @goderbauer should probably give the final lgtm on this, API-wise. I'm assuming this will be followed by an update to the templates in the tool?

I'm almost ashamed to admit it, but I'm growing fonder of GTK with time.

[robert-ancell]

Yes, there will be a follow up PR to change the template to use this. However, since we're changing the template I figured we should also do flutter/flutter#153812. I'm also going to have more of a play with the multi-window changes to FlApplication first so we don't end up changing the template more than we have to.

[loic-sharma]

Hello, thanks for sending this excellent patch!

I'm also going to have more of a play with the multi-window changes to FlApplication first so we don't end up changing the template more than we have to.

We were considering doing something very similar as part of the multi-window effort to clean up macOS's and Windows's runner APIs, especially since these runner APIs are very inconsistent across all our platforms.

However, I was concerned that the multi-window effort would require large amounts of API churn. We decided to punt the macOS/Windows runner API clean up until after the dust settles from the multi-window effort. This would let us have a stronger understanding of multi-window's requirements for each platform. In the meantime, we retrofitted existing APIs to add multi-window capabilities. See: https://flutter.dev/go/desktop-multi-view-runner-apis

I worry that this is too early to revamp Linux's runner APIs, and I worry that this makes Linux's runner APIs less consistent with macOS and Windows. Sorry for being a downer. I'm not necessarily against this change, I just wanted to make sure I aired my concerns.

@goderbauer what are your thoughts on this?

[robert-ancell]

The initial idea behind making FlApplication is to take pretty much all of the code out of the template and make it internal to FlApplication. I would expect most Linux Flutter applications would not need any modification beyond that (if we can move the window size and title into Dart code then there's really nothing the app is doing). All the new multi-window behaviour is then internal to FlApplication. Do you think macOS / Windows would end up in the same place or is that less possible on those platforms?

Initially I thought we could just leave FlApplication in the embedder and wait for updating the template, but #54703 is the sort of change that would make use of it. I'm fairly confident that if we switched the template now we're not going to paint ourselves into a corner with future changes given how little the app is doing.