GLArea.has-alpha defaults to false, which makes it impossible for a Flutter app to be transparent.
The additional change to glClearColor is to prevent a black flash when the application starts, before Flutter widgets become visible. This will also affect applications that aren't transparent, by showing the default GTK background color instead of black. This will not make the window transparent, because the developer currently has to add some code to their `linux/my_application.cc` to support transparency.
Fixes flutter/flutter#152154
Transparent windows were possible before #50754. Would it be ok to add a test for this to prevent breaking transparency again in the future?
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
The name was confusing, as it only provided one type of backing store.
FlBackingStoreProvider sounds more like an interface that the
FlFramebuffer would implement if we had multiple backing stores.
Use OpenGL types for values.
Fix cases where this was sometimes called a texture.
Improve documentation.
Remove the use of GdkRectangle for dimensions - the framebuffer only has
a width and a height. There was code that was using the x,y values which
would always have been zero - this has now been removed.
This is API that will be required when we get multi-view support on
Linux. While this internal API is not currently used, I've made a PR so
it can be more easily reviewed.
The Linux embedder had a number of handlers for Flutter channels that
were named plugin/handler/manager. Rename these all to handler to be
consistent and reduce confusion with Flutter plugins (which these don't
use the infrastructure for).
Due to changes in the renderer in fc560d4 the engine was created once a
widget is realized, not when the widget is created. If a Flutter
application changed the default my_application.cc template to show the
Flutter widget after plugins are run then these plugins would not be
able to access the engine.
Solved by removing the GdkWindow from the renderer constructor and
setting in later when the widget is realized. This works because the
renderer is not used until the widget is realized.
Fixes https://github.com/flutter/flutter/issues/144873
Add `SemanticsAction.focus`. This PR just adds the new enum value without any logic. Adding the enum value first to unblock work that needs to be done on both the engine and framework side that will actually implement all the necessary logic.
This is PR 1 out of ~3 for https://github.com/flutter/flutter/issues/83809
This patch addresses the missing implementation of
`platformDispatcher.views` on Linux. It checks the refresh rate of the
renderer's window and returns the value. Without this implementation,
`WidgetsBinding.instance.platformDispatcher.views.first.display.size`
would throw an exception on Linux, preventing safe usage.
Related: https://github.com/flutter/flutter/issues/144230
Refactor GL rendering to prepare for GTK4
- Remove FlGLArea - we can just use GtkGLArea directly
- Stop using gdk_cairo_draw_from_gl, it's not available in GTK4.
- Rename FlRendererGL to FlRendererGdk, this was implying that
FlRenderer could be something other than OpenGL which is not the case
currently.
- Remove unnecessary virtual methods in FlRenderer, just implement them
as standard methods.
Related: https://github.com/flutter/flutter/issues/143408
This PR changes the format check on CI to use the command added in
https://github.com/flutter/engine/pull/50747.
Additionally, while making this change, I noticed that the CI check was
not checking the formatting of all files, and that as a result, files
were present in the repo with incorrect formatting. I have fixed the
formatting and fixed the check to always check all files.
The existing code worked, but it cleared the objects before calling
init_keyboard. This made it look like init_keyboard might leak the
existing values. If a third case was added later where init_keyboard was
called it would leak if the caller didn't clear the objects before
calling it.
Generated by https://github.com/flutter/engine/pull/48903 (`dart ./tools/header_guard_check/bin/main.dart --fix`).
As discussed with @cbracken and @jmagman, the guards are not technically needed on the Mac/iOS code, but they (a) do not hurt and (b) still provide value if for some reason `#include` is used instead of `#import` (though I suspect we could try to add that to the tool in the future as well).
