Okay. Hello everyone. My name is Mihau or Saviq. I work at Canonical work on Ubuntu and I work
on Mir and it's still not dead. But one of the things that we started doing recently
was actually working on Flutter. Yes, 15 minutes. And it's like we're at Canonical
using Flutter to develop some of our own apps and like the software store and the installer.
But one of our kind of not very well hidden goals is to actually bring the Flutter community
over to Linux so that we can enable all of those people to deliver apps for Linux. But what we
actually really want is for them to deliver apps across platform. And Flutter on desktop
it exists. You can run Flutter apps on desktop for a while now. But the biggest hindrance
was that you could only do a single window for a long time. And you may think well that's okay
that's you know a single window is fine but it's not actually just about a single window. It's a
single surface. Like all of your menus, all of your dialogues, everything just had to go into a
single window into a single surface. And in the marketing we see this problem kind of from the
opposite side then the cookie developers. And Flutter was the perfect candidate for us to look at this
because it didn't have any pre assumptions and it previously kind of points about this. So
we was a perfect, it's a perfect candidate to make the conversation between the application
developer, the application, fullcase and the composer be about the context rather than the behavior.
So rather than the application just saying that you know this is a window that is positioned here
and it's it's small to its parent. It will rather say that it's a dialogue and that's its parent.
And its position is relative to its parent and then that that's relationship is maintained
throughout through the lifecycle of the application. So our goal is to make Flutter a great platform
to build cross-platform applications right built once run anywhere right that's from you know from
mobile to floating tiling desktops. One of the big problems with how or usually things are built
is that when you get when you get into a tiling window manager all of those behaviors kind of
break because the tiling window manager actually has to theoretically understand what did the
application, what did the toolkit mean by creating that new window. So having surveyed the behaviors
of many desktops applications across platform we distill the language that describes the purpose
of a window and that's not its behavior. So then it's the platform integration that will kind of map
the what is the appropriate behavior for a window of that type on that platform.
And we are all used to how dialogues work, how tooltips, menus work and there's just no point
to kind of expose the application developer to those details because like it's been there for like
five decades now right those behaviors are very well integrated into our minds and into into
how applications on the desktop work. So depending on platform as much as possible of the original
context we will be pushing down to the compositor. So for example again going back to the example
of a tiling window manager it doesn't need to kind of you know think about what our
or those windows properties but rather it just gets told. This is a dialogue for this window
and you will place it over the original tile of the parent window rather than sometimes ending
up as a separate tile and being a very weird experience. And so as part of the work we build
a reference application that kind of lets you play with the whole toolkit that we are making
available to widgets and to application developers and you can simulate how all of those behaviors
work on in this particular case windows we started with windows because that's where most of the
of the of the flatter community lives and it was and it was also like the furthest in even making
this possible in terms of flatter being able to draw to multiple surfaces. So this you know when
when you're when you design your app you can or working on a widget you can just see what kinds of
things are available here. We a major concept in this is aligned with the exitual and positioner
concept where again you don't just say that my tile window is at x, y of my parent but rather
just describe the relationship like here's a button in a sense that will around which I want to
place my let's say a combo box right so when you click that button there's a drop down opening
a context menu from that but actually the composer gets the all of that information so if there's
no space below then put it up put it above the button or if there's no space resize it so it's a
reach language where where the application developer and the toolkit developer can describe the behaviors
the app you know the desired behavior of each of those of each of those windows. The application
again doesn't have to deal with screen dimensions or exclusive zones, docs, panels all of those
things that the toolkits when when you're a for example on x 11 you just have to ask this
place over can I draw here what's my this what's my you know display size is this at the boundary
of the display so I can resize my things all of that can be can be easily moved and it's more
appropriately handled at the composer side and that's kind of where we're coming from to to make this happen
there's a lot so this is for example the UI of the of the positioner that modifies how does the
child relationship parent-child relationship goes and all of that is actually it's actually the
target for widget developers right generally because as an application developer you shouldn't
need to be exposed to this you will be using a higher level concept of a drop down menu and that drop down
menu will be using these features to basically behave as great as good as it can on that particular
platform. One overarching goal for us is to improve the story of existing applications as well
rather than just new use cases so we modified the material widgets which is one of the sets of widgets
for flutter that's just one our first approach to make use of windows were appropriate and you can
see here but that's before and after a situation where on the left you will see the menu as for example
cropped at the bottom the tool tip has to be moved into the window because it can't be drawn outside
so all of these things actually just happened by way of switching one billion and suddenly the
behaviors are much more much more what we are used to on on this platform. It's then making you know
much better use of screen real estate and the system's capabilities you get a proper dialogue you
can move the dialogue away if you want to glance at what was in the parent in the parent window
told it's our position better and at the extreme and that's going to come in a second in the video
we can see that you know in currently you can't open a second window on it or toolbar
in the current implementation but what we did is you can open a satellite and satellite is what we kind of
came up with this is being the extreme kind of use case of having a toolbar so if you've ever
opened gimp in multi window mode then it has all of those toolboxes on the side and it's a common
platform across like complex test applications and we want to build that into the system and just be
part of part of that whole of the whole story and but it's not all about desktop so again we were
talking about about flatter and flatter is originally a mobile mobile toolkit and but mobile
these days the game multitasking capabilities right you have foldable phones or you have you know
phones that you can connect to to the external screens and kind of where we're making a
mirror crime from and we're all about convergence and those kinds of use cases where you can build
your up ones and it seamlessly you know it's a bus word but still kind of works across across all
of that all of that ecosystem and when you use this this whole system that we did you try to use
your you know you create you try and create a window a dialogue probably doesn't make sense on Android
right so if you will get told that actually you know this platform doesn't support dialogues you
have to bring it back into your menu I but even on Android and iOS today or you can create
a multiple main windows so you can use the same API and if you connect that Android phone to
the external screen again maybe it will gain you know desktop desktop capabilities where
where those features will be again again available so it's all it's all about kind of supporting
having a set of conversations or set of words to talk to the composer about it's probably not
going to solve a hundred percent of the use cases out there but we are after the 95 percent right so
very majority of of this the publications will be fine just using these concepts and not having
to deal with the intricacies of that but it doesn't stop there as well right so we almost every day
you see a new and you wait to interact with your computer and like when you the more context
you give to the system about how you're how we want your application to behave the better it can
make make use of that information so you know if it's a coming back to this relationship between
parent and child if you have a virtual desktop on your you know VR headset there isn't a
display per say right where where's X, Y, zero or whatever so you have to describe that
that relationship between your windows in your application in a much much richer language so
that then you can actually reason about it at the at the composer site and so yeah it's it's there
we're hoping for for the first foundational bits of this to to land in the fatter within the next
weeks for for windows to start with but we're also working on on this for Linux and for macOS
initially and we'll continue to build it out if you know one of the points that we're trying
to make here is you know can tell us we saw all of these behaviors and we thought that this
is the language that that is going to be enough for solving most or you know many of those cases
come come to the fatter community talk about anything that you might see that is not not yet covered
maybe we maybe we come up with you know with a way to cover that use case in in the current language
or maybe we need to extend that language because you know there's there's a major use case
that that needs to be included here for maybe for the future or something so this will take you to
the design document for for that API and from there there's all the information that you
that you can follow and yeah that's it thank you so much