-
Notifications
You must be signed in to change notification settings - Fork 6k
Draft: Move the FlApplication from the template into the linux embedder. #50868
Conversation
This introduces the class FlApplication, which handles the passing of command line arguments into dart and bringup of a GtkWindow embedding the FlView with for e.g. desktop specifc quirks.
It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact "@test-exemption-reviewer" in the #hackers channel in Chat (don't just cc them here, they won't see it! Use Discord!). 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. |
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
/cc @robert-ancell for thoughts. @jane400 is this still something you're looking into? If so, unfortunately policy requires a signed CLA from contributors as mentioned in the bot reply above. Info in the failed invocation link above. |
The CLA check shouldn't fail with the next reinvocation/update of the MR. I saw during the creation of this MR, that there were multiple MRs introducing Multi View support into flutter, hence put this MR in my backlog.
Also waiting for an opinion for this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this!
I think this can be a bit simpler and more GTK style, and the usage would be more like this:
#include <flutter_linux/flutter_linux.h>
#include "flutter/generated_plugin_registrant.h"
static void activate_cb(FlApplication* app, gpointer user_data) {
fl_register_plugins(FL_PLUGIN_REGISTRY(fl_application_get_view()));
GtkWindow* window = fl_application_get_window(app);
gtk_window_set_title(window, "{{projectName}}");
gtk_window_set_default_size(window, 1280, 720);
}
int main(int argc, char** argv) {
g_autoptr(FlApplication) app = fl_application_new(APPLICATION_ID, G_APPLICATION_NON_UNIQUE);
g_signal_connect(app, "activate", G_CALLBACK(activate_cb), nullptr);
return g_application_run(G_APPLICATION(app), argc, argv);
}
// like signaling the application that it should show itself again. | ||
// This only stops the same instance of GApplication creating multiple | ||
// windows/views. | ||
if (priv->activated) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see why this is required - activate() is only ever called once isn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the application is guaranteed to be unique (by not giving GApplication the flag non-unique) a second instance will send the argv to the main instance over the dbus and run activate there again. The gtk4 template in gnome-builder can be used to reproduce this.
Other things can also activate it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at all existing GTK apps I can find they don't seem to do this - if you call activate a second instance of the main window is shown, which is what Flutter applications do as well. I think we should match the existing behaviour and propose this as a second change if it's required.
|
||
gtk_widget_grab_focus(GTK_WIDGET(view)); | ||
|
||
g_signal_emit (G_OBJECT (self), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This shouldn't be necessary - a Flutter application can just override the activate method (chaining up to the FlApplication implementation) or connect to the GApplication::activate signal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been thinking how this would work for multi-window. I think the user needs the ability to create the window themselves in this signal, as a multi-window app might have special windows that use GTK widgets. Since this is complicated and needs to be well thought out let's drop this from this PR and resolve in follow up PRs.
I got a chance to actually read the Multi-view runner APIs design documents. Regarding: static void activate_cb(FlApplication* app, gpointer user_data) {
fl_register_plugins(FL_PLUGIN_REGISTRY(fl_application_get_view()));
GtkWindow* window = fl_application_get_window(app);
gtk_window_set_title(window, "{{projectName}}");
gtk_window_set_default_size(window, 1280, 720);
} We could go for this, but I would still rather provide a custom signal, where we give the initial view to the user. Especially as g_application_activate can be called multiple times with certain G_APPLICATION_FLAGS. But one could also make the case that FlApplication should constrain itself to a single window, then this API is perfectly fine, and multi-view users should just use GApplication directly and override |
I've been thinking about this in regards to multi-window and also delaying the view until the first frame is shown (flutter/flutter#151098). It's clear we want FlApplication to handle all this for most Flutter applications rather than making the template more complicated. I propose this PR is simplified to just do the current behaviour of the template, and then we build from that (as noted in the review comments). @jane400 are you happy to update this PR to that? Thanks. |
(PR Triage): What is the status of this PR? |
(triage): I am going to close this one since it looks stale. If you find the time to work on this again feel free to open a new PR. Thank you. |
This introduces the class FlApplication, which handles the passing of command line arguments into dart and bringup of a GtkWindow embedding the FlView with for e.g. desktop specifc quirks.
Changes:
This now allows the flutter linux template to be more simple:
I think this is a pretty API, which should be forward compatible with multi view/window flutter applications. Suggestions welcome! :)
I would like to also include titlebar changes in this PR. My plan is to listen for the env variable
XDG_CURRENT_DESKTOP
equalsGNOME
instead of assuming GNOME implicitly withuse_headerbar = TRUE
on all wayland platforms. Should I include this here or make a new PR?List which issues are fixed by this PR. You must list at least one issue.
flutter/flutter#142920
If you had to change anything in the flutter/tests repo, include a link to the migration guide as per the breaking change policy.
Pre-launch Checklist
I didn't run the testsuite yet, and this probably needs new tests (unless someone tells me otherwise :) ). Will have to look into that.
Not all clang-format suggestion are applied, as I disliked some of them. (I'm coming from a GObject dev background and tried to keep some GObject style as outlined in the linux-embedder Exception)
///
).Currently getting SEC_ERROR_OCSP_SERVER_ERROR, will try later, signed)If you need help, consider asking for advice on the #hackers-new channel on Discord.