WEBVTT

00:00.000 --> 00:13.600
Okay. Hello everyone. My name is Mihau or Saviq. I work at Canonical work on Ubuntu and I work

00:13.600 --> 00:20.160
on Mir and it's still not dead. But one of the things that we started doing recently

00:20.160 --> 00:29.600
was actually working on Flutter. Yes, 15 minutes. And it's like we're at Canonical

00:29.600 --> 00:35.280
using Flutter to develop some of our own apps and like the software store and the installer.

00:35.280 --> 00:41.040
But one of our kind of not very well hidden goals is to actually bring the Flutter community

00:41.040 --> 00:49.200
over to Linux so that we can enable all of those people to deliver apps for Linux. But what we

00:49.200 --> 00:56.400
actually really want is for them to deliver apps across platform. And Flutter on desktop

00:56.720 --> 01:03.760
it exists. You can run Flutter apps on desktop for a while now. But the biggest hindrance

01:03.760 --> 01:08.880
was that you could only do a single window for a long time. And you may think well that's okay

01:08.880 --> 01:12.800
that's you know a single window is fine but it's not actually just about a single window. It's a

01:12.800 --> 01:18.640
single surface. Like all of your menus, all of your dialogues, everything just had to go into a

01:18.640 --> 01:26.320
single window into a single surface. And in the marketing we see this problem kind of from the

01:27.200 --> 01:32.400
opposite side then the cookie developers. And Flutter was the perfect candidate for us to look at this

01:32.400 --> 01:39.040
because it didn't have any pre assumptions and it previously kind of points about this. So

01:40.480 --> 01:46.000
we was a perfect, it's a perfect candidate to make the conversation between the application

01:46.000 --> 01:51.600
developer, the application, fullcase and the composer be about the context rather than the behavior.

01:51.680 --> 01:58.240
So rather than the application just saying that you know this is a window that is positioned here

01:58.240 --> 02:04.080
and it's it's small to its parent. It will rather say that it's a dialogue and that's its parent.

02:04.080 --> 02:09.120
And its position is relative to its parent and then that that's relationship is maintained

02:09.120 --> 02:15.920
throughout through the lifecycle of the application. So our goal is to make Flutter a great platform

02:15.920 --> 02:22.880
to build cross-platform applications right built once run anywhere right that's from you know from

02:22.880 --> 02:30.000
mobile to floating tiling desktops. One of the big problems with how or usually things are built

02:30.880 --> 02:36.480
is that when you get when you get into a tiling window manager all of those behaviors kind of

02:36.480 --> 02:42.240
break because the tiling window manager actually has to theoretically understand what did the

02:42.240 --> 02:48.720
application, what did the toolkit mean by creating that new window. So having surveyed the behaviors

02:48.720 --> 02:55.120
of many desktops applications across platform we distill the language that describes the purpose

02:55.120 --> 03:02.560
of a window and that's not its behavior. So then it's the platform integration that will kind of map

03:02.560 --> 03:07.760
the what is the appropriate behavior for a window of that type on that platform.

03:08.720 --> 03:17.120
And we are all used to how dialogues work, how tooltips, menus work and there's just no point

03:17.120 --> 03:22.240
to kind of expose the application developer to those details because like it's been there for like

03:22.240 --> 03:28.560
five decades now right those behaviors are very well integrated into our minds and into into

03:28.560 --> 03:36.400
how applications on the desktop work. So depending on platform as much as possible of the original

03:36.480 --> 03:43.680
context we will be pushing down to the compositor. So for example again going back to the example

03:43.680 --> 03:50.000
of a tiling window manager it doesn't need to kind of you know think about what our

03:50.000 --> 03:54.080
or those windows properties but rather it just gets told. This is a dialogue for this window

03:54.080 --> 03:59.280
and you will place it over the original tile of the parent window rather than sometimes ending

03:59.280 --> 04:07.680
up as a separate tile and being a very weird experience. And so as part of the work we build

04:07.680 --> 04:14.000
a reference application that kind of lets you play with the whole toolkit that we are making

04:14.000 --> 04:21.920
available to widgets and to application developers and you can simulate how all of those behaviors

04:23.280 --> 04:28.240
work on in this particular case windows we started with windows because that's where most of the

04:28.240 --> 04:35.280
of the of the flatter community lives and it was and it was also like the furthest in even making

04:35.280 --> 04:42.160
this possible in terms of flatter being able to draw to multiple surfaces. So this you know when

04:42.160 --> 04:48.400
when you're when you design your app you can or working on a widget you can just see what kinds of

04:49.440 --> 04:56.720
things are available here. We a major concept in this is aligned with the exitual and positioner

04:57.600 --> 05:04.960
concept where again you don't just say that my tile window is at x, y of my parent but rather

05:04.960 --> 05:10.880
just describe the relationship like here's a button in a sense that will around which I want to

05:10.880 --> 05:15.040
place my let's say a combo box right so when you click that button there's a drop down opening

05:15.040 --> 05:21.280
a context menu from that but actually the composer gets the all of that information so if there's

05:21.280 --> 05:27.520
no space below then put it up put it above the button or if there's no space resize it so it's a

05:27.520 --> 05:33.520
reach language where where the application developer and the toolkit developer can describe the behaviors

05:33.520 --> 05:41.120
the app you know the desired behavior of each of those of each of those windows. The application

05:41.120 --> 05:46.960
again doesn't have to deal with screen dimensions or exclusive zones, docs, panels all of those

05:46.960 --> 05:52.240
things that the toolkits when when you're a for example on x 11 you just have to ask this

05:52.240 --> 05:58.480
place over can I draw here what's my this what's my you know display size is this at the boundary

05:58.480 --> 06:04.080
of the display so I can resize my things all of that can be can be easily moved and it's more

06:04.080 --> 06:10.240
appropriately handled at the composer side and that's kind of where we're coming from to to make this happen

06:11.200 --> 06:16.640
there's a lot so this is for example the UI of the of the positioner that modifies how does the

06:16.640 --> 06:27.040
child relationship parent-child relationship goes and all of that is actually it's actually the

06:27.040 --> 06:32.000
target for widget developers right generally because as an application developer you shouldn't

06:32.000 --> 06:37.200
need to be exposed to this you will be using a higher level concept of a drop down menu and that drop down

06:37.200 --> 06:44.000
menu will be using these features to basically behave as great as good as it can on that particular

06:44.000 --> 06:51.040
platform. One overarching goal for us is to improve the story of existing applications as well

06:51.600 --> 06:57.760
rather than just new use cases so we modified the material widgets which is one of the sets of widgets

06:57.760 --> 07:02.880
for flutter that's just one our first approach to make use of windows were appropriate and you can

07:02.880 --> 07:08.960
see here but that's before and after a situation where on the left you will see the menu as for example

07:08.960 --> 07:15.360
cropped at the bottom the tool tip has to be moved into the window because it can't be drawn outside

07:15.360 --> 07:20.800
so all of these things actually just happened by way of switching one billion and suddenly the

07:20.800 --> 07:28.240
behaviors are much more much more what we are used to on on this platform. It's then making you know

07:28.240 --> 07:33.520
much better use of screen real estate and the system's capabilities you get a proper dialogue you

07:33.520 --> 07:38.480
can move the dialogue away if you want to glance at what was in the parent in the parent window

07:39.280 --> 07:44.960
told it's our position better and at the extreme and that's going to come in a second in the video

07:44.960 --> 07:49.360
we can see that you know in currently you can't open a second window on it or toolbar

07:50.400 --> 07:55.920
in the current implementation but what we did is you can open a satellite and satellite is what we kind of

07:55.920 --> 08:00.800
came up with this is being the extreme kind of use case of having a toolbar so if you've ever

08:00.800 --> 08:06.560
opened gimp in multi window mode then it has all of those toolboxes on the side and it's a common

08:06.560 --> 08:15.120
platform across like complex test applications and we want to build that into the system and just be

08:15.120 --> 08:24.800
part of part of that whole of the whole story and but it's not all about desktop so again we were

08:24.800 --> 08:33.440
talking about about flatter and flatter is originally a mobile mobile toolkit and but mobile

08:33.440 --> 08:38.720
these days the game multitasking capabilities right you have foldable phones or you have you know

08:38.720 --> 08:42.960
phones that you can connect to to the external screens and kind of where we're making a

08:42.960 --> 08:48.080
mirror crime from and we're all about convergence and those kinds of use cases where you can build

08:48.240 --> 08:55.040
your up ones and it seamlessly you know it's a bus word but still kind of works across across all

08:55.040 --> 09:02.800
of that all of that ecosystem and when you use this this whole system that we did you try to use

09:02.800 --> 09:08.320
your you know you create you try and create a window a dialogue probably doesn't make sense on Android

09:08.320 --> 09:13.120
right so if you will get told that actually you know this platform doesn't support dialogues you

09:13.120 --> 09:19.760
have to bring it back into your menu I but even on Android and iOS today or you can create

09:19.760 --> 09:24.960
a multiple main windows so you can use the same API and if you connect that Android phone to

09:24.960 --> 09:30.880
the external screen again maybe it will gain you know desktop desktop capabilities where

09:30.880 --> 09:37.440
where those features will be again again available so it's all it's all about kind of supporting

09:37.440 --> 09:44.720
having a set of conversations or set of words to talk to the composer about it's probably not

09:44.720 --> 09:49.520
going to solve a hundred percent of the use cases out there but we are after the 95 percent right so

09:50.400 --> 09:55.920
very majority of of this the publications will be fine just using these concepts and not having

09:55.920 --> 10:03.120
to deal with the intricacies of that but it doesn't stop there as well right so we almost every day

10:03.120 --> 10:09.200
you see a new and you wait to interact with your computer and like when you the more context

10:09.200 --> 10:14.800
you give to the system about how you're how we want your application to behave the better it can

10:14.800 --> 10:21.840
make make use of that information so you know if it's a coming back to this relationship between

10:21.840 --> 10:27.040
parent and child if you have a virtual desktop on your you know VR headset there isn't a

10:27.040 --> 10:32.080
display per say right where where's X, Y, zero or whatever so you have to describe that

10:32.080 --> 10:38.560
that relationship between your windows in your application in a much much richer language so

10:38.560 --> 10:46.800
that then you can actually reason about it at the at the composer site and so yeah it's it's there

10:46.800 --> 10:54.000
we're hoping for for the first foundational bits of this to to land in the fatter within the next

10:54.000 --> 10:59.680
weeks for for windows to start with but we're also working on on this for Linux and for macOS

10:59.680 --> 11:06.320
initially and we'll continue to build it out if you know one of the points that we're trying

11:06.320 --> 11:11.840
to make here is you know can tell us we saw all of these behaviors and we thought that this

11:11.840 --> 11:17.280
is the language that that is going to be enough for solving most or you know many of those cases

11:18.000 --> 11:23.680
come come to the fatter community talk about anything that you might see that is not not yet covered

11:23.680 --> 11:29.920
maybe we maybe we come up with you know with a way to cover that use case in in the current language

11:29.920 --> 11:34.320
or maybe we need to extend that language because you know there's there's a major use case

11:34.320 --> 11:41.440
that that needs to be included here for maybe for the future or something so this will take you to

11:42.160 --> 11:47.440
the design document for for that API and from there there's all the information that you

11:48.240 --> 11:52.960
that you can follow and yeah that's it thank you so much