1
00:00:06,320 --> 00:00:11,499
[Music]

2
00:00:15,839 --> 00:00:19,199
hi everyone welcome back hope you're all

3
00:00:18,320 --> 00:00:22,400
still

4
00:00:19,199 --> 00:00:24,240
full of energy and excitement um towards

5
00:00:22,400 --> 00:00:26,480
the end of the day i didn't think i

6
00:00:24,240 --> 00:00:29,679
would be but somehow all of these lovely

7
00:00:26,480 --> 00:00:33,600
talks are keeping me going

8
00:00:29,679 --> 00:00:35,120
next up we have emmanuela bassey

9
00:00:33,600 --> 00:00:36,399
telling us about a year in the life of

10
00:00:35,120 --> 00:00:39,760
gtk

11
00:00:36,399 --> 00:00:42,000
so emanuela has been working on gtk and

12
00:00:39,760 --> 00:00:44,079
gnome for over 15 years both as a

13
00:00:42,000 --> 00:00:46,399
volunteer and on commercial products

14
00:00:44,079 --> 00:00:49,280
based on gnome technologies like memo on

15
00:00:46,399 --> 00:00:49,280
nokia hardware

16
00:00:49,680 --> 00:00:56,399
he will be taking questions at the end

17
00:00:52,559 --> 00:00:58,879
so please use the um chat in

18
00:00:56,399 --> 00:01:01,840
point that way in venus not the chat the

19
00:00:58,879 --> 00:01:03,199
questions tab above the chat um to ask

20
00:01:01,840 --> 00:01:06,400
your questions and i will pass them on

21
00:01:03,199 --> 00:01:09,760
to emmanuella at the end um so thank you

22
00:01:06,400 --> 00:01:13,439
very much all over to you

23
00:01:09,760 --> 00:01:14,799
hi and thank you and thanks everyone for

24
00:01:13,439 --> 00:01:17,520
joining me

25
00:01:14,799 --> 00:01:20,080
in this uh presentation and also thanks

26
00:01:17,520 --> 00:01:21,119
for to lca for

27
00:01:20,080 --> 00:01:23,280
uh

28
00:01:21,119 --> 00:01:26,479
giving me the chance to talk about gtk

29
00:01:23,280 --> 00:01:26,479
uh in this conference

30
00:01:26,880 --> 00:01:29,520
so

31
00:01:27,759 --> 00:01:32,079
we're going to talk a little bit about a

32
00:01:29,520 --> 00:01:36,640
year in the life of the gtk project

33
00:01:32,079 --> 00:01:36,640
since we the gta project has been

34
00:01:36,880 --> 00:01:42,079
doing a major release

35
00:01:38,799 --> 00:01:45,280
for the first time in nearly 10 years so

36
00:01:42,079 --> 00:01:47,520
stuff has changed uh in the year before

37
00:01:45,280 --> 00:01:49,840
that and in this year

38
00:01:47,520 --> 00:01:52,560
is changing again uh there's there's

39
00:01:49,840 --> 00:01:55,040
lots of stuff to cover so

40
00:01:52,560 --> 00:01:55,920
let's start

41
00:01:55,040 --> 00:01:58,719
so

42
00:01:55,920 --> 00:02:02,000
i am part of the gdk development team

43
00:01:58,719 --> 00:02:02,799
and i've been working on gtk and gnome

44
00:02:02,000 --> 00:02:05,600
for

45
00:02:02,799 --> 00:02:07,040
about 15 years now

46
00:02:05,600 --> 00:02:09,599
i'm mostly involved in a core

47
00:02:07,040 --> 00:02:10,479
application development platform

48
00:02:09,599 --> 00:02:11,840
so

49
00:02:10,479 --> 00:02:13,840
core libraries

50
00:02:11,840 --> 00:02:14,800
but i also work with

51
00:02:13,840 --> 00:02:16,879
the

52
00:02:14,800 --> 00:02:19,360
developer documentation

53
00:02:16,879 --> 00:02:22,560
the documentation team

54
00:02:19,360 --> 00:02:24,720
i maintain the odd application and i

55
00:02:22,560 --> 00:02:27,280
collaborate with other gnome maintainers

56
00:02:24,720 --> 00:02:30,400
in the release team

57
00:02:27,280 --> 00:02:33,840
my contributions have been part of

58
00:02:30,400 --> 00:02:36,000
both my literal job for years

59
00:02:33,840 --> 00:02:37,840
but i also worked on gnome and gtk on my

60
00:02:36,000 --> 00:02:38,720
spare time so i

61
00:02:37,840 --> 00:02:40,560
i'm

62
00:02:38,720 --> 00:02:43,040
usually able to appreciate the use of

63
00:02:40,560 --> 00:02:45,360
gtk and gnome technologies

64
00:02:43,040 --> 00:02:48,000
as a downstream developer as well as a

65
00:02:45,360 --> 00:02:48,000
volunteer

66
00:02:49,680 --> 00:02:55,840
gdk is a very old project

67
00:02:52,319 --> 00:02:57,440
these days it's nearly 25 years old um

68
00:02:55,840 --> 00:02:58,400
it's been in continuous development

69
00:02:57,440 --> 00:03:01,920
since

70
00:02:58,400 --> 00:03:03,680
roughly 1995 1996.

71
00:03:01,920 --> 00:03:05,599
uh when it was written as part of the

72
00:03:03,680 --> 00:03:08,319
new image manipulation program to

73
00:03:05,599 --> 00:03:11,120
replace motif which was the toolkit used

74
00:03:08,319 --> 00:03:14,319
at the very beginning

75
00:03:11,120 --> 00:03:17,519
over the past 25 years gtk has seen

76
00:03:14,319 --> 00:03:22,159
three major version bumps from gtk 1 to

77
00:03:17,519 --> 00:03:23,920
2 from 2 to 3 and now from 3 to 4

78
00:03:22,159 --> 00:03:27,360
and has been used and deployed to

79
00:03:23,920 --> 00:03:30,959
millions of devices all around the world

80
00:03:27,360 --> 00:03:32,959
the last major release of gtk gtk4 is

81
00:03:30,959 --> 00:03:35,200
probably

82
00:03:32,959 --> 00:03:38,640
the biggest leap in terms of the toolkit

83
00:03:35,200 --> 00:03:41,280
internal design since the 2.0 days

84
00:03:38,640 --> 00:03:44,319
and it was a change driven both by the

85
00:03:41,280 --> 00:03:46,879
evolution of windowing systems on linux

86
00:03:44,319 --> 00:03:48,959
and by the challenges and

87
00:03:46,879 --> 00:03:50,480
the realities of maintaining a

88
00:03:48,959 --> 00:03:53,439
volunteer-driven

89
00:03:50,480 --> 00:03:54,640
free software toolkit with no central

90
00:03:53,439 --> 00:03:59,799
authority

91
00:03:54,640 --> 00:03:59,799
and very minimal corporate backing

92
00:04:00,319 --> 00:04:05,120
so today i'm going to talk to you a

93
00:04:03,360 --> 00:04:08,560
little bit about the changes that led to

94
00:04:05,120 --> 00:04:10,319
gtk 4.0 in 2020

95
00:04:08,560 --> 00:04:15,239
and what happened to the project and

96
00:04:10,319 --> 00:04:15,239
around it in the years since then

97
00:04:17,919 --> 00:04:22,880
um

98
00:04:19,519 --> 00:04:25,280
in 2016 the main topic of discussion

99
00:04:22,880 --> 00:04:28,240
about gdk was whether we could improve

100
00:04:25,280 --> 00:04:30,080
the rendering pipeline for gtk3 which

101
00:04:28,240 --> 00:04:34,080
was the major version at the time

102
00:04:30,080 --> 00:04:36,080
without breaking the api contract

103
00:04:34,080 --> 00:04:37,919
the fact of the matter though was that

104
00:04:36,080 --> 00:04:40,800
we had been changing the internals of

105
00:04:37,919 --> 00:04:43,680
the toolkit a lot more than we

106
00:04:40,800 --> 00:04:45,600
did back in 2006

107
00:04:43,680 --> 00:04:47,040
when we introduced cairo in the

108
00:04:45,600 --> 00:04:49,040
rendering pipeline

109
00:04:47,040 --> 00:04:50,800
and we moved away from the internal

110
00:04:49,040 --> 00:04:54,479
drawing api that

111
00:04:50,800 --> 00:04:56,160
mimicked and wrapped xlib

112
00:04:54,479 --> 00:04:58,720
we're also looking at the transition

113
00:04:56,160 --> 00:05:01,600
period in which we'd say uh goodbye to

114
00:04:58,720 --> 00:05:03,600
x11 and hello to wayland

115
00:05:01,600 --> 00:05:05,280
and on the other side of things we were

116
00:05:03,600 --> 00:05:08,080
seeing the adoption of a high dpi

117
00:05:05,280 --> 00:05:10,720
density displays on both laptops and

118
00:05:08,080 --> 00:05:13,919
desktops as well as dedicated graphical

119
00:05:10,720 --> 00:05:17,120
hardware with 3d acceleration

120
00:05:13,919 --> 00:05:19,039
during the gtk 3 stable cycle we did

121
00:05:17,120 --> 00:05:20,000
change a lot of the rendering pipeline

122
00:05:19,039 --> 00:05:22,000
worked

123
00:05:20,000 --> 00:05:24,479
to allow proper transparency between

124
00:05:22,000 --> 00:05:27,919
widgets for instance or implementing

125
00:05:24,479 --> 00:05:30,479
things like css borders and shadows that

126
00:05:27,919 --> 00:05:33,759
extended outside the widgets area and

127
00:05:30,479 --> 00:05:33,759
blended with the background

128
00:05:34,160 --> 00:05:40,800
these changes required little to

129
00:05:36,880 --> 00:05:41,600
no updates in idiomatic code

130
00:05:40,800 --> 00:05:43,840
which

131
00:05:41,600 --> 00:05:46,080
is good in general

132
00:05:43,840 --> 00:05:48,960
but there was a lot of a non-idiomatic

133
00:05:46,080 --> 00:05:52,400
code in applications that were highly

134
00:05:48,960 --> 00:05:55,759
ported from gtk2 to gtk3 back when we

135
00:05:52,400 --> 00:05:57,360
release gnome 3.0

136
00:05:55,759 --> 00:05:59,520
um

137
00:05:57,360 --> 00:06:01,440
this is a time when we did not make

138
00:05:59,520 --> 00:06:04,800
ourselves any friends with application

139
00:06:01,440 --> 00:06:05,759
developers that consume the platform

140
00:06:04,800 --> 00:06:07,440
and

141
00:06:05,759 --> 00:06:10,000
especially the ones that were consuming

142
00:06:07,440 --> 00:06:12,160
the platforms three years at a time by

143
00:06:10,000 --> 00:06:13,840
updating their development

144
00:06:12,160 --> 00:06:17,520
uh machines

145
00:06:13,840 --> 00:06:22,400
uh using long-term releases

146
00:06:17,520 --> 00:06:22,400
from the distributions like ubuntu

147
00:06:24,240 --> 00:06:29,600
our main problem was effectively cairo

148
00:06:27,919 --> 00:06:32,560
cairo is

149
00:06:29,600 --> 00:06:34,960
was still is a high quality vector-based

150
00:06:32,560 --> 00:06:37,520
2d rendering api

151
00:06:34,960 --> 00:06:40,400
while it introduced this high quality

152
00:06:37,520 --> 00:06:43,199
rendering to graphical user interfaces

153
00:06:40,400 --> 00:06:44,800
it was limited by its design which

154
00:06:43,199 --> 00:06:48,160
reflected the area in which it was

155
00:06:44,800 --> 00:06:50,479
developed so the early 2000s

156
00:06:48,160 --> 00:06:53,680
thanks to cairo we were able to move gtk

157
00:06:50,479 --> 00:06:56,639
to a css based drawing state just like

158
00:06:53,680 --> 00:06:58,960
web rendering engines

159
00:06:56,639 --> 00:07:00,720
like those web branding engines

160
00:06:58,960 --> 00:07:02,800
soon discovered

161
00:07:00,720 --> 00:07:05,199
it is effectively easier to take

162
00:07:02,800 --> 00:07:06,800
whatever state cairo has blow it away

163
00:07:05,199 --> 00:07:09,599
and replace it entirely with the state

164
00:07:06,800 --> 00:07:12,639
of the css machinery that is held

165
00:07:09,599 --> 00:07:14,160
client-side in the toolkit

166
00:07:12,639 --> 00:07:16,000
and this is especially true if you're

167
00:07:14,160 --> 00:07:20,080
running something that looks like a lot

168
00:07:16,000 --> 00:07:22,080
like a gui as opposed to a vector image

169
00:07:20,080 --> 00:07:24,960
another problem at the core of cairo was

170
00:07:22,080 --> 00:07:27,680
its reliance on fast read back pipelines

171
00:07:24,960 --> 00:07:29,759
between the cpu and the system memory

172
00:07:27,680 --> 00:07:34,479
which is something that just does not

173
00:07:29,759 --> 00:07:34,479
exist in modern systems using a gpu

174
00:07:34,720 --> 00:07:38,720
finally the maintenance status of the

175
00:07:36,560 --> 00:07:40,240
project had been in question ever since

176
00:07:38,720 --> 00:07:43,199
intel approached the two people

177
00:07:40,240 --> 00:07:45,599
responsible for maintaining the library

178
00:07:43,199 --> 00:07:48,639
one after the other first uh kyle worth

179
00:07:45,599 --> 00:07:51,120
and then chris wilson

180
00:07:48,639 --> 00:07:52,639
in the end cairo is an api that makes

181
00:07:51,120 --> 00:07:54,720
sense as an internal detail of the

182
00:07:52,639 --> 00:07:58,879
toolkit

183
00:07:54,720 --> 00:08:01,680
sadly we exposed it as part of our api

184
00:07:58,879 --> 00:08:04,240
to application and library developers

185
00:08:01,680 --> 00:08:06,639
and that made it necessary to write

186
00:08:04,240 --> 00:08:08,560
wrappers around it to represent a full

187
00:08:06,639 --> 00:08:11,759
set of rendering operations

188
00:08:08,560 --> 00:08:14,319
in order to hide the fact that

189
00:08:11,759 --> 00:08:17,360
the car api didn't actually

190
00:08:14,319 --> 00:08:19,360
work the way we wanted

191
00:08:17,360 --> 00:08:21,599
but at that point though why would you

192
00:08:19,360 --> 00:08:23,520
be using cairo at all when

193
00:08:21,599 --> 00:08:25,280
cairo didn't give you access to the most

194
00:08:23,520 --> 00:08:27,840
efficient graphical hardware on your

195
00:08:25,280 --> 00:08:27,840
system

196
00:08:28,319 --> 00:08:34,959
well because sadly the actual api that

197
00:08:31,840 --> 00:08:36,560
lets you access the hardware is opengl

198
00:08:34,959 --> 00:08:40,000
which has been known to be a disaster

199
00:08:36,560 --> 00:08:42,000
zone for years especially in linux

200
00:08:40,000 --> 00:08:44,959
luckily the introduction of mainstream

201
00:08:42,000 --> 00:08:48,320
x11 compositors using opengl like

202
00:08:44,959 --> 00:08:50,880
compies in the mid-2000s and gunam shell

203
00:08:48,320 --> 00:08:53,040
in 2011

204
00:08:50,880 --> 00:08:55,279
at the effect of improving the gl driver

205
00:08:53,040 --> 00:08:57,360
support which in turn pushed more people

206
00:08:55,279 --> 00:08:58,959
to make use of gl for applications and

207
00:08:57,360 --> 00:09:00,640
games

208
00:08:58,959 --> 00:09:02,640
and that

209
00:09:00,640 --> 00:09:04,880
it was coupled with improvements in the

210
00:09:02,640 --> 00:09:07,680
gl standard api

211
00:09:04,880 --> 00:09:11,279
which deprecated at first and then

212
00:09:07,680 --> 00:09:14,560
jettisoned the old craft from the 90s

213
00:09:11,279 --> 00:09:17,279
and basically pushed for um

214
00:09:14,560 --> 00:09:19,519
using the gpu as a programmable resource

215
00:09:17,279 --> 00:09:22,320
instead of a completely opaque state

216
00:09:19,519 --> 00:09:24,000
machine

217
00:09:22,320 --> 00:09:26,560
a gl based css

218
00:09:24,000 --> 00:09:29,680
state render is much more tractable than

219
00:09:26,560 --> 00:09:31,519
implementing a fully generic vector api

220
00:09:29,680 --> 00:09:34,320
and you can get a lot of mileage out of

221
00:09:31,519 --> 00:09:36,720
small shaders to do things like shadows

222
00:09:34,320 --> 00:09:39,760
borders

223
00:09:36,720 --> 00:09:43,600
this was demonstrated by projects like

224
00:09:39,760 --> 00:09:45,440
mozilla servos web render

225
00:09:43,600 --> 00:09:47,839
which acted as an inspiration for the

226
00:09:45,440 --> 00:09:49,839
gtk rendering pipeline

227
00:09:47,839 --> 00:09:51,920
for instance once you have a full tree

228
00:09:49,839 --> 00:09:54,399
of rendering operations you can decide

229
00:09:51,920 --> 00:09:57,200
what changed from a previous frame

230
00:09:54,399 --> 00:09:59,600
what didn't and what to remove from the

231
00:09:57,200 --> 00:10:01,120
graph of operations since it will never

232
00:09:59,600 --> 00:10:02,959
be visible

233
00:10:01,120 --> 00:10:04,399
at that point you can re-render

234
00:10:02,959 --> 00:10:07,519
everything

235
00:10:04,399 --> 00:10:10,160
and do it faster than just caching

236
00:10:07,519 --> 00:10:14,320
intermediate states and then

237
00:10:10,160 --> 00:10:14,320
figuring out how to expire that cache

238
00:10:15,279 --> 00:10:20,480
suddenly

239
00:10:16,880 --> 00:10:23,440
by doing this the rendering step of each

240
00:10:20,480 --> 00:10:25,920
frame is not the bottleneck anymore and

241
00:10:23,440 --> 00:10:28,720
that gives you much more time to do

242
00:10:25,920 --> 00:10:31,680
um layout at 60fps

243
00:10:28,720 --> 00:10:34,959
or whatever frame per second is your

244
00:10:31,680 --> 00:10:34,959
screen refresh rate

245
00:10:35,519 --> 00:10:39,360
and also gives more time

246
00:10:37,760 --> 00:10:41,200
to

247
00:10:39,360 --> 00:10:44,079
application logic to

248
00:10:41,200 --> 00:10:44,079
do its own thing

249
00:10:45,360 --> 00:10:52,240
um speaking of pushing at 60fps um

250
00:10:48,959 --> 00:10:54,480
the task of doing so becomes really hard

251
00:10:52,240 --> 00:10:57,440
when um

252
00:10:54,480 --> 00:10:59,440
you're dealing with large resolutions

253
00:10:57,440 --> 00:11:02,480
your cpu

254
00:10:59,440 --> 00:11:04,000
back in the day of the early 2000s

255
00:11:02,480 --> 00:11:06,959
late 90s even

256
00:11:04,000 --> 00:11:10,720
your cpu could deal with pushing 800 by

257
00:11:06,959 --> 00:11:12,240
600 pixels or even 1024x768

258
00:11:10,720 --> 00:11:15,360
per frame

259
00:11:12,240 --> 00:11:17,600
but once you get to 1080p

260
00:11:15,360 --> 00:11:20,560
2k 4k 8k

261
00:11:17,600 --> 00:11:23,120
uh or even multiple displays uh with

262
00:11:20,560 --> 00:11:24,800
very large resolutions then you

263
00:11:23,120 --> 00:11:26,839
definitely need something more powerful

264
00:11:24,800 --> 00:11:31,680
than your cpu

265
00:11:26,839 --> 00:11:34,720
and uh hi idpi displays also require

266
00:11:31,680 --> 00:11:37,279
changing the nature of pixels uh from

267
00:11:34,720 --> 00:11:38,160
something that is physical so it's an

268
00:11:37,279 --> 00:11:39,360
actual

269
00:11:38,160 --> 00:11:40,160
like

270
00:11:39,360 --> 00:11:42,160
uh

271
00:11:40,160 --> 00:11:43,760
point of light on your screen to a

272
00:11:42,160 --> 00:11:45,600
logical unit

273
00:11:43,760 --> 00:11:47,519
so you don't accidentally turn your

274
00:11:45,600 --> 00:11:49,680
desktop into the most challenging level

275
00:11:47,519 --> 00:11:52,399
of mine sweeper ever

276
00:11:49,680 --> 00:11:53,920
and you'll need a magnifying glass to

277
00:11:52,399 --> 00:11:56,880
hit uh

278
00:11:53,920 --> 00:11:58,320
like ridiculously small buttons or three

279
00:11:56,880 --> 00:12:00,639
very very

280
00:11:58,320 --> 00:12:02,959
small text

281
00:12:00,639 --> 00:12:05,200
this requires changing how you load

282
00:12:02,959 --> 00:12:08,079
image assets in your application i use

283
00:12:05,200 --> 00:12:10,480
size windowing system surfaces and how

284
00:12:08,079 --> 00:12:12,639
you align every ui element to the pixel

285
00:12:10,480 --> 00:12:16,399
grid especially text

286
00:12:12,639 --> 00:12:16,399
otherwise you get a blurry mess

287
00:12:20,240 --> 00:12:24,800
alongside the changes in the lower

288
00:12:22,399 --> 00:12:26,639
layers of the stack that impact directly

289
00:12:24,800 --> 00:12:30,639
the hardware

290
00:12:26,639 --> 00:12:33,279
starting from the early 2010s the clock

291
00:12:30,639 --> 00:12:34,800
began ticking for display the old

292
00:12:33,279 --> 00:12:37,519
display server technology available on

293
00:12:34,800 --> 00:12:40,160
linux which is x11

294
00:12:37,519 --> 00:12:42,160
over the years toolkits have moved away

295
00:12:40,160 --> 00:12:43,360
from submitting rendering commands to a

296
00:12:42,160 --> 00:12:45,600
server

297
00:12:43,360 --> 00:12:49,279
and instead they started to send

298
00:12:45,600 --> 00:12:52,240
complete frames generated client side

299
00:12:49,279 --> 00:12:54,320
the x server usually stood in the way of

300
00:12:52,240 --> 00:12:57,200
making applications reliably present

301
00:12:54,320 --> 00:12:58,480
windows to the users for years

302
00:12:57,200 --> 00:13:01,360
um

303
00:12:58,480 --> 00:13:03,760
even though we introduced uh well not me

304
00:13:01,360 --> 00:13:06,320
personally but the x11 developers

305
00:13:03,760 --> 00:13:08,560
introduce extensions like the composite

306
00:13:06,320 --> 00:13:10,000
extension

307
00:13:08,560 --> 00:13:12,240
weyland

308
00:13:10,000 --> 00:13:14,880
as a display server technology promised

309
00:13:12,240 --> 00:13:18,480
to make every frame of painting with no

310
00:13:14,880 --> 00:13:21,200
interference by the display server

311
00:13:18,480 --> 00:13:23,600
sadly gtk 3

312
00:13:21,200 --> 00:13:25,839
just like gtk2 was still very much

313
00:13:23,600 --> 00:13:28,800
designed on top of xlib which meant that

314
00:13:25,839 --> 00:13:31,519
every one of its back ends

315
00:13:28,800 --> 00:13:34,800
was re-implementing the same xlib design

316
00:13:31,519 --> 00:13:36,959
on other windowing system and gdk

317
00:13:34,800 --> 00:13:38,880
exposed a lot of ostensibly independent

318
00:13:36,959 --> 00:13:41,519
api that

319
00:13:38,880 --> 00:13:44,399
only ever made sense or even worked when

320
00:13:41,519 --> 00:13:44,399
using x11

321
00:13:47,440 --> 00:13:52,880
in terms of portability as i was saying

322
00:13:50,000 --> 00:13:54,560
gdk basically re-implemented xlib on

323
00:13:52,880 --> 00:13:56,240
every single platform

324
00:13:54,560 --> 00:13:59,680
um since the

325
00:13:56,240 --> 00:14:02,639
gtk 2.0 release in 2001.

326
00:13:59,680 --> 00:14:05,519
uh the ability to

327
00:14:02,639 --> 00:14:07,360
run a gdk application on different

328
00:14:05,519 --> 00:14:09,360
platforms and different environments was

329
00:14:07,360 --> 00:14:11,199
never meant to be used at ways to do

330
00:14:09,360 --> 00:14:13,839
like cross-platform

331
00:14:11,199 --> 00:14:16,560
write once run anywhere development

332
00:14:13,839 --> 00:14:17,839
it was a way to port gtk applications

333
00:14:16,560 --> 00:14:20,639
from linux

334
00:14:17,839 --> 00:14:23,760
and other unix-like systems to windows

335
00:14:20,639 --> 00:14:23,760
and mac os

336
00:14:24,639 --> 00:14:27,760
and

337
00:14:25,600 --> 00:14:29,440
as i said i was saying this amounted for

338
00:14:27,760 --> 00:14:31,839
implementing x11

339
00:14:29,440 --> 00:14:31,839
everywhere

340
00:14:32,000 --> 00:14:36,800
while this minimized the changes to

341
00:14:33,920 --> 00:14:39,040
application code because after all

342
00:14:36,800 --> 00:14:41,519
everything looked like x

343
00:14:39,040 --> 00:14:44,800
it made everything more complicated to

344
00:14:41,519 --> 00:14:46,079
maintain and to fix and to test inside

345
00:14:44,800 --> 00:14:47,839
the toolkit

346
00:14:46,079 --> 00:14:51,120
every new functionality will need to be

347
00:14:47,839 --> 00:14:54,079
obstructed in ways that didn't always

348
00:14:51,120 --> 00:14:56,320
make sense or they would be just left

349
00:14:54,079 --> 00:14:58,480
unimplemented

350
00:14:56,320 --> 00:15:00,160
plus very very few people could

351
00:14:58,480 --> 00:15:02,399
understand how the back ends actually

352
00:15:00,160 --> 00:15:05,360
worked a simpler windowing system

353
00:15:02,399 --> 00:15:08,880
protocol like weyland would fit in a lot

354
00:15:05,360 --> 00:15:08,880
better within these constraints

355
00:15:11,440 --> 00:15:17,279
so we come to 2016 and the internal

356
00:15:14,959 --> 00:15:19,279
changes that happened during the gtk 3

357
00:15:17,279 --> 00:15:22,160
cycle um

358
00:15:19,279 --> 00:15:22,160
basically just

359
00:15:22,720 --> 00:15:25,360
were not

360
00:15:24,160 --> 00:15:27,760
really

361
00:15:25,360 --> 00:15:30,079
for free anymore

362
00:15:27,760 --> 00:15:33,279
of course most people only remember the

363
00:15:30,079 --> 00:15:35,120
theming issues at the time um

364
00:15:33,279 --> 00:15:37,920
themes which were never under any

365
00:15:35,120 --> 00:15:40,000
stability guarantee the

366
00:15:37,920 --> 00:15:42,880
issues were mostly the result of

367
00:15:40,000 --> 00:15:44,720
downstream distributions of themes

368
00:15:42,880 --> 00:15:46,959
as packages

369
00:15:44,720 --> 00:15:48,880
without any additional qa process that

370
00:15:46,959 --> 00:15:51,519
would tie them to release of the toolkit

371
00:15:48,880 --> 00:15:53,519
they were ostensibly targeting

372
00:15:51,519 --> 00:15:55,360
so people got broken

373
00:15:53,519 --> 00:15:57,120
desktops because they were using a theme

374
00:15:55,360 --> 00:15:59,199
that was not tested with a version of

375
00:15:57,120 --> 00:16:02,720
gtk they was

376
00:15:59,199 --> 00:16:04,240
in theory using

377
00:16:02,720 --> 00:16:05,519
the main impact for application

378
00:16:04,240 --> 00:16:06,560
developers

379
00:16:05,519 --> 00:16:08,480
were not

380
00:16:06,560 --> 00:16:10,160
themes where the changes in the drawing

381
00:16:08,480 --> 00:16:13,279
api especially for applications

382
00:16:10,160 --> 00:16:16,480
supported in the early days of gtk3

383
00:16:13,279 --> 00:16:19,120
uh to avoid that happening again uh just

384
00:16:16,480 --> 00:16:21,120
before of the gtk4 development process

385
00:16:19,120 --> 00:16:24,639
we decided to lay down some fundamental

386
00:16:21,120 --> 00:16:26,720
guarantees for application developers

387
00:16:24,639 --> 00:16:28,639
first and foremost that once the 4.0

388
00:16:26,720 --> 00:16:30,160
release was done the toolkit would be

389
00:16:28,639 --> 00:16:32,079
feature frozen

390
00:16:30,160 --> 00:16:34,000
new api and new features could be added

391
00:16:32,079 --> 00:16:36,160
of course but existing functionality

392
00:16:34,000 --> 00:16:37,680
would never change including the css

393
00:16:36,160 --> 00:16:39,680
selectors

394
00:16:37,680 --> 00:16:42,560
so it's a little bit more strong than an

395
00:16:39,680 --> 00:16:44,320
avia api compatibility

396
00:16:42,560 --> 00:16:46,720
additionally the new development cycle

397
00:16:44,320 --> 00:16:48,000
will contain a roadmap for future major

398
00:16:46,720 --> 00:16:49,680
api work

399
00:16:48,000 --> 00:16:52,560
as well as the support window for

400
00:16:49,680 --> 00:16:54,399
existing stable releases to shorten the

401
00:16:52,560 --> 00:16:57,440
development cycle while providing a

402
00:16:54,399 --> 00:16:57,440
reliable schedule

403
00:16:58,399 --> 00:17:02,560
so

404
00:16:59,759 --> 00:17:06,240
feature-free is one stable

405
00:17:02,560 --> 00:17:08,400
just adding small widgets

406
00:17:06,240 --> 00:17:10,480
uh freeze the theme

407
00:17:08,400 --> 00:17:14,640
shorter api cycles

408
00:17:10,480 --> 00:17:19,280
and to support the api versions um for

409
00:17:14,640 --> 00:17:21,520
a window of to support the api versions

410
00:17:19,280 --> 00:17:22,880
so this is kind of a

411
00:17:21,520 --> 00:17:25,839
graph of

412
00:17:22,880 --> 00:17:28,559
our policy you can see that we have the

413
00:17:25,839 --> 00:17:32,559
gtk3 branch that goes on

414
00:17:28,559 --> 00:17:35,200
um it was we had to release gdk320

415
00:17:32,559 --> 00:17:37,360
to um

416
00:17:35,200 --> 00:17:41,280
ease off the porting window but

417
00:17:37,360 --> 00:17:43,919
basically from 324 we jumped to the 390

418
00:17:41,280 --> 00:17:46,160
development process release four

419
00:17:43,919 --> 00:17:49,200
and then from four we're gonna release

420
00:17:46,160 --> 00:17:50,799
we're gonna start the 490 development

421
00:17:49,200 --> 00:17:54,400
cycle in

422
00:17:50,799 --> 00:17:55,600
uh probably three years time

423
00:17:54,400 --> 00:17:58,000
but as

424
00:17:55,600 --> 00:18:00,240
as soon as gtk

425
00:17:58,000 --> 00:18:02,559
5 is going to be released gtk3 is going

426
00:18:00,240 --> 00:18:04,320
to be end of life and

427
00:18:02,559 --> 00:18:06,400
the only

428
00:18:04,320 --> 00:18:09,120
two supported stable release

429
00:18:06,400 --> 00:18:12,240
versions will be gta 4 and gta 5

430
00:18:09,120 --> 00:18:15,360
and then when gtk 6 is released gta 4

431
00:18:12,240 --> 00:18:17,039
will be end of live so it's much more

432
00:18:15,360 --> 00:18:18,320
explicit

433
00:18:17,039 --> 00:18:19,840
instead of

434
00:18:18,320 --> 00:18:22,799
just being random

435
00:18:19,840 --> 00:18:22,799
whatever we want

436
00:18:25,200 --> 00:18:31,760
so in terms of gtk

437
00:18:28,720 --> 00:18:34,400
internal and api design

438
00:18:31,760 --> 00:18:36,559
the version the major version number

439
00:18:34,400 --> 00:18:38,799
three was still heavily influenced by

440
00:18:36,559 --> 00:18:40,559
the model of a deep object-oriented

441
00:18:38,799 --> 00:18:42,480
forest of types

442
00:18:40,559 --> 00:18:45,120
this design encouraged developers to

443
00:18:42,480 --> 00:18:46,880
inherit from existing complex widgets

444
00:18:45,120 --> 00:18:49,120
which add the side effect of locking

445
00:18:46,880 --> 00:18:51,200
some internal state to avoid breaking

446
00:18:49,120 --> 00:18:53,360
expectations

447
00:18:51,200 --> 00:18:55,520
for gdk4 instead the design mantra has

448
00:18:53,360 --> 00:18:57,520
been to favor composition and delegation

449
00:18:55,520 --> 00:18:59,200
instead of inheritance

450
00:18:57,520 --> 00:19:00,960
we made it easier to create your own

451
00:18:59,200 --> 00:19:03,440
custom composite widgets without

452
00:19:00,960 --> 00:19:05,919
exposing their internals

453
00:19:03,440 --> 00:19:08,400
you can do that with object orientation

454
00:19:05,919 --> 00:19:10,799
and use xml

455
00:19:08,400 --> 00:19:14,240
to describe your ui and

456
00:19:10,799 --> 00:19:15,919
bind it to the uh class structure

457
00:19:14,240 --> 00:19:16,799
automatically so you don't have to deal

458
00:19:15,919 --> 00:19:20,240
with

459
00:19:16,799 --> 00:19:23,440
uh the fiddly bits of um

460
00:19:20,240 --> 00:19:25,600
loading uh uh loading xml yourself and

461
00:19:23,440 --> 00:19:28,080
then assigning pointers and stuff like

462
00:19:25,600 --> 00:19:30,400
that there are a bunch of macros and a

463
00:19:28,080 --> 00:19:32,799
bunch of api that will deal with that

464
00:19:30,400 --> 00:19:32,799
for you

465
00:19:35,520 --> 00:19:39,120
um

466
00:19:36,400 --> 00:19:42,799
another thing that we looked at a little

467
00:19:39,120 --> 00:19:45,520
bit later than we wanted but it was hard

468
00:19:42,799 --> 00:19:47,520
to find uh resources and funding for

469
00:19:45,520 --> 00:19:50,880
that sadly

470
00:19:47,520 --> 00:19:52,480
um was accessibility

471
00:19:50,880 --> 00:19:55,919
like

472
00:19:52,480 --> 00:19:59,039
prometheus gifting humans with the uh

473
00:19:55,919 --> 00:20:00,799
with fire the sans accessibility team

474
00:19:59,039 --> 00:20:04,480
gifted the free and open source software

475
00:20:00,799 --> 00:20:06,799
world with 80 spy back in 2000 2000

476
00:20:04,480 --> 00:20:08,559
2001.

477
00:20:06,799 --> 00:20:11,120
and

478
00:20:08,559 --> 00:20:12,960
alongside it is by gtk acquire all

479
00:20:11,120 --> 00:20:15,760
accessibility api

480
00:20:12,960 --> 00:20:19,120
first as an out of three model

481
00:20:15,760 --> 00:20:19,120
because of dependencies

482
00:20:19,520 --> 00:20:24,000
the legacy of that gift

483
00:20:21,919 --> 00:20:26,080
made things much more complicated over

484
00:20:24,000 --> 00:20:28,400
the following 20 years

485
00:20:26,080 --> 00:20:29,520
the original design was heavily based on

486
00:20:28,400 --> 00:20:32,240
corba

487
00:20:29,520 --> 00:20:35,120
which is many things but a nimble ipc

488
00:20:32,240 --> 00:20:36,880
mechanism isn't one of them

489
00:20:35,120 --> 00:20:39,360
additionally the accessibility stack was

490
00:20:36,880 --> 00:20:42,080
heavily tied to x11 with application

491
00:20:39,360 --> 00:20:44,080
broadcasting the old internal state

492
00:20:42,080 --> 00:20:45,200
and allowing other applications to take

493
00:20:44,080 --> 00:20:48,480
them over

494
00:20:45,200 --> 00:20:51,280
on unsecured sockets

495
00:20:48,480 --> 00:20:52,799
and unprivileged assistive technologies

496
00:20:51,280 --> 00:20:55,039
were able to

497
00:20:52,799 --> 00:20:58,159
get and inject windowing system events

498
00:20:55,039 --> 00:21:00,320
across the whole desktop

499
00:20:58,159 --> 00:21:02,480
this design also by layering the api

500
00:21:00,320 --> 00:21:04,320
across multiple components you add the

501
00:21:02,480 --> 00:21:06,960
toolkit

502
00:21:04,320 --> 00:21:09,840
with which provide an implementation

503
00:21:06,960 --> 00:21:11,840
then you add the set of abstract types

504
00:21:09,840 --> 00:21:14,000
as a separate library

505
00:21:11,840 --> 00:21:15,520
since it they could be theoretically

506
00:21:14,000 --> 00:21:18,960
implemented by multiple toolkits and

507
00:21:15,520 --> 00:21:21,440
libraries except it never happened

508
00:21:18,960 --> 00:21:21,440
well if you

509
00:21:21,760 --> 00:21:25,520
yeah it never actually happened

510
00:21:26,080 --> 00:21:30,000
and

511
00:21:27,760 --> 00:21:33,120
on the other side you had the actual low

512
00:21:30,000 --> 00:21:36,000
level library that sat at both ends of

513
00:21:33,120 --> 00:21:39,440
the ipc wire

514
00:21:36,000 --> 00:21:42,080
on top of that there were there was

515
00:21:39,440 --> 00:21:44,320
sun scaling down the accessibility theme

516
00:21:42,080 --> 00:21:46,640
oracle acquiring sun and basically

517
00:21:44,320 --> 00:21:49,679
killing the entire thing

518
00:21:46,640 --> 00:21:52,080
um and the pool of people working on

519
00:21:49,679 --> 00:21:54,960
making the linux desktop accessible to

520
00:21:52,080 --> 00:21:57,200
people with disabilities

521
00:21:54,960 --> 00:22:00,159
yeah

522
00:21:57,200 --> 00:22:02,799
it got smaller and smaller um

523
00:22:00,159 --> 00:22:04,799
the more time passed

524
00:22:02,799 --> 00:22:07,120
in the meantime web browsers are where

525
00:22:04,799 --> 00:22:08,640
the action is these days which meant

526
00:22:07,120 --> 00:22:11,919
having a whole new accessibility

527
00:22:08,640 --> 00:22:14,640
specification to follow the w3c aria

528
00:22:11,919 --> 00:22:14,640
specification

529
00:22:15,919 --> 00:22:22,080
so for gtk4 we decided to follow that

530
00:22:19,280 --> 00:22:23,760
instead of to eliminate all the layers

531
00:22:22,080 --> 00:22:26,880
uh and just

532
00:22:23,760 --> 00:22:28,159
speak the 80 spy protocol directly and

533
00:22:26,880 --> 00:22:30,799
implement

534
00:22:28,159 --> 00:22:35,200
from an api perspective the

535
00:22:30,799 --> 00:22:35,200
w3c specification for accessibility

536
00:22:38,080 --> 00:22:44,159
so what's new in gdk4

537
00:22:42,080 --> 00:22:46,320
we have a new deferred mode rendering

538
00:22:44,159 --> 00:22:48,480
infrastructure uh instead of being an

539
00:22:46,320 --> 00:22:50,159
immediate mode with cairo so you don't

540
00:22:48,480 --> 00:22:52,640
submit you don't draw directly you

541
00:22:50,159 --> 00:22:54,880
submit rendering commands and then gtk

542
00:22:52,640 --> 00:22:56,960
will take them and

543
00:22:54,880 --> 00:22:59,120
structure them in ways that make more

544
00:22:56,960 --> 00:23:01,360
sense

545
00:22:59,120 --> 00:23:02,480
we use opengl by default and cairo is a

546
00:23:01,360 --> 00:23:04,240
fallback

547
00:23:02,480 --> 00:23:07,520
we use weyland by default even the

548
00:23:04,240 --> 00:23:11,200
design of the api is based on weyland

549
00:23:07,520 --> 00:23:13,039
we have much more simpler backends

550
00:23:11,200 --> 00:23:16,640
so they are easy to

551
00:23:13,039 --> 00:23:18,880
test fix and maintain

552
00:23:16,640 --> 00:23:22,640
we have a reliable release policy and a

553
00:23:18,880 --> 00:23:25,600
stable feature set for every single

554
00:23:22,640 --> 00:23:27,600
new major release of gtk

555
00:23:25,600 --> 00:23:29,280
we use delegation instead of inheritance

556
00:23:27,600 --> 00:23:32,159
making the

557
00:23:29,280 --> 00:23:36,520
api more reliable

558
00:23:32,159 --> 00:23:36,520
and we have a new accessibility api

559
00:23:36,880 --> 00:23:41,520
of course we also have to document all

560
00:23:39,039 --> 00:23:41,520
this stuff

561
00:23:41,840 --> 00:23:46,159
gdk

562
00:23:43,440 --> 00:23:49,440
started off in 1997

563
00:23:46,159 --> 00:23:51,200
with um handwritten tech info pages for

564
00:23:49,440 --> 00:23:52,480
the api reference

565
00:23:51,200 --> 00:23:54,240
and then

566
00:23:52,480 --> 00:23:56,880
the project was migrated to a custom

567
00:23:54,240 --> 00:23:58,960
documentation generator that would take

568
00:23:56,880 --> 00:24:03,039
comments from the source code and turn

569
00:23:58,960 --> 00:24:05,440
them into dot book xml first and then

570
00:24:03,039 --> 00:24:08,559
that turned into html

571
00:24:05,440 --> 00:24:10,880
uh the tool was called gtk doc and it

572
00:24:08,559 --> 00:24:13,279
served the gnome project as all well

573
00:24:10,880 --> 00:24:15,760
enough to be reused for all other

574
00:24:13,279 --> 00:24:18,240
libraries

575
00:24:15,760 --> 00:24:20,080
sadly gtk dock was written in pearl and

576
00:24:18,240 --> 00:24:22,320
its maintenance cost

577
00:24:20,080 --> 00:24:24,240
kind of followed the curve of every

578
00:24:22,320 --> 00:24:26,640
other pearl

579
00:24:24,240 --> 00:24:29,279
project

580
00:24:26,640 --> 00:24:31,039
and at some point since pearl

581
00:24:29,279 --> 00:24:34,720
fell from grace

582
00:24:31,039 --> 00:24:36,720
it got progressively less maintained

583
00:24:34,720 --> 00:24:38,559
there was a last-ditch attempt to port

584
00:24:36,720 --> 00:24:41,120
gtk dr python

585
00:24:38,559 --> 00:24:43,520
as well as trying to reduce the dog

586
00:24:41,120 --> 00:24:45,279
books performance bottleneck

587
00:24:43,520 --> 00:24:47,039
but

588
00:24:45,279 --> 00:24:48,720
basically building the api reference for

589
00:24:47,039 --> 00:24:51,039
gtk took

590
00:24:48,720 --> 00:24:51,919
as much as building the actual toolkit

591
00:24:51,039 --> 00:24:54,559
so

592
00:24:51,919 --> 00:24:57,919
500 000 lines of c

593
00:24:54,559 --> 00:25:01,760
uh plus examples plus demos

594
00:24:57,919 --> 00:25:02,720
uh on our ci pipeline take about

595
00:25:01,760 --> 00:25:04,640
um

596
00:25:02,720 --> 00:25:06,880
six to seven minutes

597
00:25:04,640 --> 00:25:10,799
and generating documentation for that

598
00:25:06,880 --> 00:25:14,600
took the exact same amount of time

599
00:25:10,799 --> 00:25:14,600
uh it was untenable

600
00:25:15,520 --> 00:25:19,520
in the meantime though

601
00:25:17,360 --> 00:25:22,080
since 2010-ish

602
00:25:19,520 --> 00:25:24,320
every gnome library started providing a

603
00:25:22,080 --> 00:25:25,520
machine-readable description of its c

604
00:25:24,320 --> 00:25:28,159
api

605
00:25:25,520 --> 00:25:29,440
as well as the documentation for the for

606
00:25:28,159 --> 00:25:32,159
that api

607
00:25:29,440 --> 00:25:34,480
in form of introspection data generated

608
00:25:32,159 --> 00:25:36,159
at build time

609
00:25:34,480 --> 00:25:37,919
the typical consumer of this data

610
00:25:36,159 --> 00:25:40,320
language bindings

611
00:25:37,919 --> 00:25:42,880
they can use it both at runtime as a

612
00:25:40,320 --> 00:25:44,799
memory mappable binary blob

613
00:25:42,880 --> 00:25:49,120
and they can also use

614
00:25:44,799 --> 00:25:49,120
an xml description for code generation

615
00:25:50,159 --> 00:25:54,159
the xml description contains the

616
00:25:51,919 --> 00:25:56,960
documentation associated to every public

617
00:25:54,159 --> 00:26:00,720
type and symbols and it's possible to

618
00:25:56,960 --> 00:26:04,000
use it to generate an api reference

619
00:26:00,720 --> 00:26:04,000
much more efficiently

620
00:26:04,159 --> 00:26:07,679
the

621
00:26:05,840 --> 00:26:09,520
it also has another advantage of using

622
00:26:07,679 --> 00:26:12,320
the introspection data

623
00:26:09,520 --> 00:26:14,960
the generated api will match as much as

624
00:26:12,320 --> 00:26:15,840
possible the actual api that will be

625
00:26:14,960 --> 00:26:17,520
used

626
00:26:15,840 --> 00:26:18,960
by the

627
00:26:17,520 --> 00:26:21,600
language bindings

628
00:26:18,960 --> 00:26:23,600
so you you'll get something that is a

629
00:26:21,600 --> 00:26:26,640
lot

630
00:26:23,600 --> 00:26:29,679
easier to map between

631
00:26:26,640 --> 00:26:29,679
programming languages

632
00:26:32,000 --> 00:26:35,520
so

633
00:26:33,039 --> 00:26:36,640
i wrote this tool called gi doctrine

634
00:26:35,520 --> 00:26:39,120
which take the introspection

635
00:26:36,640 --> 00:26:42,240
documentation and the introspection data

636
00:26:39,120 --> 00:26:46,480
and generates the documentation and and

637
00:26:42,240 --> 00:26:46,480
creates an uh html website

638
00:26:47,919 --> 00:26:52,000
it's

639
00:26:49,360 --> 00:26:54,720
really fast it takes about a minute to

640
00:26:52,000 --> 00:26:55,600
build the entire thing

641
00:26:54,720 --> 00:26:58,320
and

642
00:26:55,600 --> 00:26:59,600
we publish it as part of our ci pipeline

643
00:26:58,320 --> 00:27:03,360
alongside the

644
00:26:59,600 --> 00:27:06,720
reference for other libraries so gtk

645
00:27:03,360 --> 00:27:08,799
gio pango for text gdk big spot for

646
00:27:06,720 --> 00:27:10,880
image loading

647
00:27:08,799 --> 00:27:14,320
it has stable links

648
00:27:10,880 --> 00:27:16,799
it allows cross linking of symbols using

649
00:27:14,320 --> 00:27:19,440
javascript so you can

650
00:27:16,799 --> 00:27:20,480
tweak the cross linking for the remote

651
00:27:19,440 --> 00:27:21,440
and the local

652
00:27:20,480 --> 00:27:24,320
case

653
00:27:21,440 --> 00:27:26,159
and it makes it easier to update to fix

654
00:27:24,320 --> 00:27:29,039
the documentation because every single

655
00:27:26,159 --> 00:27:31,120
type and every single symbol has a link

656
00:27:29,039 --> 00:27:33,120
to the source code

657
00:27:31,120 --> 00:27:35,679
that defines it so you can literally

658
00:27:33,120 --> 00:27:39,200
jump into the gitlab web ui

659
00:27:35,679 --> 00:27:42,320
and then edit the documentation um

660
00:27:39,200 --> 00:27:44,960
straight from the web browser

661
00:27:42,320 --> 00:27:46,799
uh it also has

662
00:27:44,960 --> 00:27:49,039
client-side searches

663
00:27:46,799 --> 00:27:50,399
on an index that is generated at build

664
00:27:49,039 --> 00:27:51,120
time as well

665
00:27:50,399 --> 00:27:53,919
so

666
00:27:51,120 --> 00:27:57,440
uh you never send your queries to i

667
00:27:53,919 --> 00:27:57,440
don't know google or whatever else

668
00:27:59,760 --> 00:28:04,640
on top of that we also revamped the gta

669
00:28:02,640 --> 00:28:07,120
well i say we i revamped the gtk

670
00:28:04,640 --> 00:28:08,159
documentation website the gnome

671
00:28:07,120 --> 00:28:10,960
developer

672
00:28:08,159 --> 00:28:12,960
documentation there

673
00:28:10,960 --> 00:28:14,320
it's been rebuilt from scratch

674
00:28:12,960 --> 00:28:16,480
we moved from

675
00:28:14,320 --> 00:28:18,559
python to django

676
00:28:16,480 --> 00:28:19,840
kind of haddock uh

677
00:28:18,559 --> 00:28:23,919
application

678
00:28:19,840 --> 00:28:26,799
that literally took html out of the

679
00:28:23,919 --> 00:28:28,240
release tarbles and instead we switched

680
00:28:26,799 --> 00:28:29,440
to

681
00:28:28,240 --> 00:28:31,919
sphinx

682
00:28:29,440 --> 00:28:34,559
which is a python

683
00:28:31,919 --> 00:28:36,880
documentation generator

684
00:28:34,559 --> 00:28:39,200
this lets us do things like

685
00:28:36,880 --> 00:28:41,840
cross-linking automatically

686
00:28:39,200 --> 00:28:43,120
searches and everything else

687
00:28:41,840 --> 00:28:45,039
it's um

688
00:28:43,120 --> 00:28:47,679
also a lot easier to build the

689
00:28:45,039 --> 00:28:50,399
documentation locally and test it before

690
00:28:47,679 --> 00:28:52,720
sending it to gitlab for a merge request

691
00:28:50,399 --> 00:28:54,640
and then we use gitlab

692
00:28:52,720 --> 00:28:57,360
this is the gitlab ci pipeline to

693
00:28:54,640 --> 00:29:00,000
generate the entire documentation and

694
00:28:57,360 --> 00:29:02,720
website and publishing it

695
00:29:00,000 --> 00:29:05,120
so it's a lot easier to contribute there

696
00:29:02,720 --> 00:29:05,120
as well

697
00:29:07,760 --> 00:29:12,080
and outside of the content of the

698
00:29:09,760 --> 00:29:13,120
developer documentation we also added

699
00:29:12,080 --> 00:29:16,960
new

700
00:29:13,120 --> 00:29:20,960
from the old set of tutorials that were

701
00:29:16,960 --> 00:29:23,840
kind of out of date most of the time

702
00:29:20,960 --> 00:29:25,919
we added them to we added more content

703
00:29:23,840 --> 00:29:28,799
there and we also adding beginners

704
00:29:25,919 --> 00:29:32,960
tutorials to go from the human interface

705
00:29:28,799 --> 00:29:35,600
guidelines to the api references

706
00:29:32,960 --> 00:29:39,039
and speaking of interface guidelines

707
00:29:35,600 --> 00:29:41,520
the same website all hosts them

708
00:29:39,039 --> 00:29:43,760
and they are generated using the same

709
00:29:41,520 --> 00:29:43,760
tool

710
00:29:45,840 --> 00:29:55,000
so what happened in

711
00:29:48,720 --> 00:29:55,000
this last year from december 2020 to now

712
00:29:56,480 --> 00:30:01,840
we work on stabilization the main goal

713
00:29:58,559 --> 00:30:03,520
of gdk now becomes bug fixing and

714
00:30:01,840 --> 00:30:05,279
handling feedback from application

715
00:30:03,520 --> 00:30:09,120
developers that are currently porting

716
00:30:05,279 --> 00:30:12,240
their applications to gtk4 from gtk3 or

717
00:30:09,120 --> 00:30:12,240
even from gtk2

718
00:30:13,600 --> 00:30:18,000
but also we want to ensure that gtk4 can

719
00:30:16,480 --> 00:30:19,679
be used by virus environments and

720
00:30:18,000 --> 00:30:22,640
platforms so it's possible to easily

721
00:30:19,679 --> 00:30:24,559
port applications between them we have

722
00:30:22,640 --> 00:30:26,880
aggressively simplified improve our

723
00:30:24,559 --> 00:30:29,279
build system thanks to mison and it's

724
00:30:26,880 --> 00:30:31,679
possible to go from cloning just the gtk

725
00:30:29,279 --> 00:30:34,480
repository to a full build including the

726
00:30:31,679 --> 00:30:37,039
library dependencies on both mac os and

727
00:30:34,480 --> 00:30:38,960
windows and we test that on our ci

728
00:30:37,039 --> 00:30:40,240
pipeline

729
00:30:38,960 --> 00:30:42,880
there are still some issues here and

730
00:30:40,240 --> 00:30:45,679
there especially some core dependencies

731
00:30:42,880 --> 00:30:50,279
on macos but we are much more confident

732
00:30:45,679 --> 00:30:50,279
about the state of the toolkit there

733
00:30:50,559 --> 00:30:54,640
um

734
00:30:51,679 --> 00:30:56,880
the ci pipeline for windows also

735
00:30:54,640 --> 00:31:01,120
um we have two pipelines for windows one

736
00:30:56,880 --> 00:31:03,440
using msys2 so using a gcc tool chain

737
00:31:01,120 --> 00:31:06,320
and then we have a

738
00:31:03,440 --> 00:31:08,799
microsoft uh visual c

739
00:31:06,320 --> 00:31:13,039
uh native tool chain

740
00:31:08,799 --> 00:31:14,000
and then we generate the dlls as um

741
00:31:13,039 --> 00:31:16,480
uh

742
00:31:14,000 --> 00:31:19,039
build artifacts so people can literally

743
00:31:16,480 --> 00:31:22,640
download them from uh for a merger quest

744
00:31:19,039 --> 00:31:24,320
to test if the fix was um

745
00:31:22,640 --> 00:31:26,399
was correct

746
00:31:24,320 --> 00:31:28,880
without having to rebuild the library

747
00:31:26,399 --> 00:31:28,880
locally

748
00:31:29,279 --> 00:31:32,480
but another thing that we kind of worked

749
00:31:31,120 --> 00:31:34,640
on is

750
00:31:32,480 --> 00:31:36,480
trying to make it easier to write

751
00:31:34,640 --> 00:31:38,559
platform libraries

752
00:31:36,480 --> 00:31:41,039
since gtk is used by multiple

753
00:31:38,559 --> 00:31:43,039
environments as a foundational toolkit

754
00:31:41,039 --> 00:31:44,960
we wanted to make it more environment

755
00:31:43,039 --> 00:31:47,919
agnostic

756
00:31:44,960 --> 00:31:50,559
elementary xfc are based on gtk and they

757
00:31:47,919 --> 00:31:53,600
provide their own platform libraries for

758
00:31:50,559 --> 00:31:55,840
writing integrated applications

759
00:31:53,600 --> 00:31:58,080
by making gtk less beholden to gnome

760
00:31:55,840 --> 00:31:59,440
design patterns those libraries can now

761
00:31:58,080 --> 00:32:01,120
avoid

762
00:31:59,440 --> 00:32:03,679
undoing

763
00:32:01,120 --> 00:32:05,679
some of the token internal state

764
00:32:03,679 --> 00:32:08,880
or write completely custom widgets to

765
00:32:05,679 --> 00:32:08,880
replace gdk zone

766
00:32:09,600 --> 00:32:16,799
and since gnome is still based on gtk

767
00:32:12,840 --> 00:32:20,320
and it needs a way to implement

768
00:32:16,799 --> 00:32:23,519
its own ui design patterns for their own

769
00:32:20,320 --> 00:32:23,519
for its own applications

770
00:32:24,880 --> 00:32:30,000
we worked on a library called libadvita

771
00:32:27,760 --> 00:32:32,480
which implements the

772
00:32:30,000 --> 00:32:34,799
gnome interface guideline patterns and

773
00:32:32,480 --> 00:32:38,640
widgets

774
00:32:34,799 --> 00:32:38,640
it will also follow the gnome

775
00:32:39,360 --> 00:32:44,799
schedule essentially so it will

776
00:32:42,399 --> 00:32:46,480
cycle through api a little bit faster

777
00:32:44,799 --> 00:32:47,360
than gdk

778
00:32:46,480 --> 00:32:49,519
um

779
00:32:47,360 --> 00:32:50,559
but also theme changes and things like

780
00:32:49,519 --> 00:32:53,519
that

781
00:32:50,559 --> 00:32:57,640
not every six months but it has uh

782
00:32:53,519 --> 00:32:57,640
definitely a shorter lifetime

783
00:32:58,399 --> 00:33:03,039
uh libat waiter was recently released

784
00:33:00,960 --> 00:33:07,519
libavita 1.0 was recently released

785
00:33:03,039 --> 00:33:10,559
alongside gtk 4.6 and will be available

786
00:33:07,519 --> 00:33:12,960
with gnome 42 when drum 42 is released

787
00:33:10,559 --> 00:33:12,960
in march

788
00:33:14,720 --> 00:33:20,559
so i have a few

789
00:33:18,159 --> 00:33:24,799
resources here

790
00:33:20,559 --> 00:33:28,320
this is the gtk documentation website

791
00:33:24,799 --> 00:33:31,200
and the new developer dot num.org for

792
00:33:28,320 --> 00:33:34,720
the developers documentation

793
00:33:31,200 --> 00:33:35,919
this is the api reference for libadvita

794
00:33:34,720 --> 00:33:39,120
as you can see

795
00:33:35,919 --> 00:33:40,240
most of these apis will are

796
00:33:39,120 --> 00:33:42,159
generated

797
00:33:40,240 --> 00:33:45,279
on git lab using the ci pipeline so

798
00:33:42,159 --> 00:33:45,279
they're always up to date

799
00:33:46,320 --> 00:33:51,600
the job gene introspection documentation

800
00:33:49,519 --> 00:33:53,919
and the documentation for the

801
00:33:51,600 --> 00:33:56,080
documentation generator using job j

802
00:33:53,919 --> 00:33:57,840
introspection

803
00:33:56,080 --> 00:33:59,279
and also we have the gtk development

804
00:33:57,840 --> 00:34:02,080
blog where we

805
00:33:59,279 --> 00:34:02,080
try to

806
00:34:02,480 --> 00:34:06,720
explain some of the internals of the

807
00:34:04,240 --> 00:34:09,839
toolkit and outline changes in the

808
00:34:06,720 --> 00:34:13,119
toolkit that are coming or

809
00:34:09,839 --> 00:34:13,119
they that are planned

810
00:34:13,200 --> 00:34:18,960
and we also have a discourse instance so

811
00:34:15,679 --> 00:34:24,159
you can talk to us without having to

812
00:34:18,960 --> 00:34:24,159
open random bugs on on gitlab and then

813
00:34:24,240 --> 00:34:28,480
filling up the

814
00:34:25,679 --> 00:34:28,480
issue tracker

815
00:34:30,480 --> 00:34:34,480
you can follow me on twitter

816
00:34:33,040 --> 00:34:36,000
and on twitch

817
00:34:34,480 --> 00:34:38,639
on twitch i do

818
00:34:36,000 --> 00:34:40,000
regular streaming where i

819
00:34:38,639 --> 00:34:42,560
document i

820
00:34:40,000 --> 00:34:45,200
either write documentation

821
00:34:42,560 --> 00:34:47,280
like the beginner's tutorials for the

822
00:34:45,200 --> 00:34:50,879
gnome developer documentation

823
00:34:47,280 --> 00:34:50,879
or i work on gtk

824
00:34:51,359 --> 00:34:56,639
so i guess

825
00:34:53,839 --> 00:34:59,680
it's time for me to thank you

826
00:34:56,639 --> 00:35:01,200
and thanks uh the lca organization for

827
00:34:59,680 --> 00:35:03,920
having me again

828
00:35:01,200 --> 00:35:05,760
to talk to you about gdk

829
00:35:03,920 --> 00:35:08,400
and i guess if you have any questions

830
00:35:05,760 --> 00:35:10,800
now would be the time

831
00:35:08,400 --> 00:35:14,079
thank you emmanuel that was like a

832
00:35:10,800 --> 00:35:15,200
really interesting behind the scenes

833
00:35:14,079 --> 00:35:17,920
look into

834
00:35:15,200 --> 00:35:19,839
gtk and what's been going on and um i

835
00:35:17,920 --> 00:35:22,880
appreciated the history

836
00:35:19,839 --> 00:35:24,720
lesson as well like i mean i i

837
00:35:22,880 --> 00:35:25,440
obviously um

838
00:35:24,720 --> 00:35:26,800
i

839
00:35:25,440 --> 00:35:28,720
i used

840
00:35:26,800 --> 00:35:30,720
just had a pronunciation discussion in

841
00:35:28,720 --> 00:35:34,560
the chat so i'm going to say both gnome

842
00:35:30,720 --> 00:35:36,000
and gnome um myself a fair bit but i've

843
00:35:34,560 --> 00:35:37,680
never really thought too much about how

844
00:35:36,000 --> 00:35:39,760
it works sorry the cat is just having a

845
00:35:37,680 --> 00:35:41,920
bit of a scratch behind me there

846
00:35:39,760 --> 00:35:43,680
um

847
00:35:41,920 --> 00:35:45,920
so yeah that was that was really

848
00:35:43,680 --> 00:35:48,320
eye-opening for me thank you

849
00:35:45,920 --> 00:35:50,320
so we've got a few questions

850
00:35:48,320 --> 00:35:52,240
um

851
00:35:50,320 --> 00:35:54,160
let's start with

852
00:35:52,240 --> 00:35:56,079
what are your top bits of advice for

853
00:35:54,160 --> 00:35:58,000
people building and maintaining other

854
00:35:56,079 --> 00:36:00,720
libraries and apis based on what you've

855
00:35:58,000 --> 00:36:04,240
learned with gtk

856
00:36:00,720 --> 00:36:04,240
this is a very complex question

857
00:36:04,560 --> 00:36:09,040
the

858
00:36:05,520 --> 00:36:12,560
the main thing i'd say is

859
00:36:09,040 --> 00:36:14,079
not trying to please everyone

860
00:36:12,560 --> 00:36:16,000
try to

861
00:36:14,079 --> 00:36:18,079
use

862
00:36:16,000 --> 00:36:20,960
try to limit yourself

863
00:36:18,079 --> 00:36:22,480
give you constraint writing api is

864
00:36:20,960 --> 00:36:25,200
almost like

865
00:36:22,480 --> 00:36:28,720
painting or doing any other form of art

866
00:36:25,200 --> 00:36:28,720
more than technology

867
00:36:29,119 --> 00:36:34,000
the trick is in the either in the

868
00:36:31,680 --> 00:36:36,480
negative space or in the limits that you

869
00:36:34,000 --> 00:36:39,599
set your to yourself

870
00:36:36,480 --> 00:36:40,960
the important thing i think is to allow

871
00:36:39,599 --> 00:36:43,680
people to do

872
00:36:40,960 --> 00:36:46,480
complicated things

873
00:36:43,680 --> 00:36:48,400
but not

874
00:36:46,480 --> 00:36:51,119
try to second guess

875
00:36:48,400 --> 00:36:53,040
where they will go

876
00:36:51,119 --> 00:36:54,400
um

877
00:36:53,040 --> 00:36:56,079
and

878
00:36:54,400 --> 00:36:58,320
there's always time to add convenience

879
00:36:56,079 --> 00:37:00,240
api at some point

880
00:36:58,320 --> 00:37:02,640
the other thing that is incredibly

881
00:37:00,240 --> 00:37:05,040
important and i think is fundamental to

882
00:37:02,640 --> 00:37:06,720
everything else is

883
00:37:05,040 --> 00:37:09,040
documentation documentation

884
00:37:06,720 --> 00:37:10,880
documentation always write more

885
00:37:09,040 --> 00:37:13,119
documentation than you will actually

886
00:37:10,880 --> 00:37:13,119
need

887
00:37:13,200 --> 00:37:17,520
i think those are the two main main

888
00:37:15,680 --> 00:37:21,119
lessons that i learned

889
00:37:17,520 --> 00:37:22,640
yeah um i mean i my own experience i

890
00:37:21,119 --> 00:37:25,040
agree and i really like the way you

891
00:37:22,640 --> 00:37:27,599
phrased that um

892
00:37:25,040 --> 00:37:29,680
yeah and definitely i could definitely

893
00:37:27,599 --> 00:37:32,800
hear the years of experience and

894
00:37:29,680 --> 00:37:35,119
thinking about those issues behind there

895
00:37:32,800 --> 00:37:37,280
okay next question

896
00:37:35,119 --> 00:37:39,359
so you're trying to move away from xlib

897
00:37:37,280 --> 00:37:40,640
does that make it easier for the windows

898
00:37:39,359 --> 00:37:45,280
port

899
00:37:40,640 --> 00:37:49,040
yes the windows back end in gtk4 is

900
00:37:45,280 --> 00:37:51,359
incredibly simpler than it used to be

901
00:37:49,040 --> 00:37:53,440
we have more people contributing to it

902
00:37:51,359 --> 00:37:56,400
for that reason

903
00:37:53,440 --> 00:37:58,640
we have more people

904
00:37:56,400 --> 00:38:00,480
filing issues and

905
00:37:58,640 --> 00:38:03,839
helping out

906
00:38:00,480 --> 00:38:05,839
because we reduce the internal surface

907
00:38:03,839 --> 00:38:07,359
and the concepts are a lot easier to

908
00:38:05,839 --> 00:38:09,040
deal with

909
00:38:07,359 --> 00:38:10,720
the whale on backhand is also a lot

910
00:38:09,040 --> 00:38:14,160
easier to deal with because you know i

911
00:38:10,720 --> 00:38:16,240
have to implement weird x11 isms here

912
00:38:14,160 --> 00:38:18,240
and there

913
00:38:16,240 --> 00:38:20,800
the main thing that changed for instance

914
00:38:18,240 --> 00:38:23,200
is the clipboard uh and the

915
00:38:20,800 --> 00:38:25,200
copy and paste api

916
00:38:23,200 --> 00:38:28,640
and that

917
00:38:25,200 --> 00:38:30,160
went from being a weird protocol based

918
00:38:28,640 --> 00:38:32,880
on top of xlib

919
00:38:30,160 --> 00:38:33,839
the xdnd and the selection stuff

920
00:38:32,880 --> 00:38:35,920
to

921
00:38:33,839 --> 00:38:38,720
being uh

922
00:38:35,920 --> 00:38:40,400
passing file descriptors around

923
00:38:38,720 --> 00:38:43,119
that was

924
00:38:40,400 --> 00:38:45,520
incredibly that allows us to make the

925
00:38:43,119 --> 00:38:47,200
api a lot simpler as well for

926
00:38:45,520 --> 00:38:50,320
application developers

927
00:38:47,200 --> 00:38:53,040
people routinely now come to the

928
00:38:50,320 --> 00:38:55,760
matrix channel saying

929
00:38:53,040 --> 00:38:57,359
i replace the entire clipboard handling

930
00:38:55,760 --> 00:38:59,599
that i had in my application with like

931
00:38:57,359 --> 00:39:02,079
three lines of code it cannot possibly

932
00:38:59,599 --> 00:39:04,480
be this simple and we're like no no it

933
00:39:02,079 --> 00:39:06,960
is it is the simple it works oh that's

934
00:39:04,480 --> 00:39:09,200
wonderful

935
00:39:06,960 --> 00:39:11,680
that that that's

936
00:39:09,200 --> 00:39:14,400
a joy to imagine it must make you really

937
00:39:11,680 --> 00:39:16,480
happy to see people say that yeah it

938
00:39:14,400 --> 00:39:18,880
does

939
00:39:16,480 --> 00:39:21,280
okay next question is

940
00:39:18,880 --> 00:39:22,640
css support was a bold move do you think

941
00:39:21,280 --> 00:39:25,040
it'll keep up

942
00:39:22,640 --> 00:39:26,000
or meet the browsers ever

943
00:39:25,040 --> 00:39:28,400
um

944
00:39:26,000 --> 00:39:31,760
we kind of followed the

945
00:39:28,400 --> 00:39:35,280
css specifications as much as we as much

946
00:39:31,760 --> 00:39:38,000
it makes sense for a desktop toolkit

947
00:39:35,280 --> 00:39:42,720
so whenever in doubt on how to implement

948
00:39:38,000 --> 00:39:44,160
the css feature we follow the w3c specs

949
00:39:42,720 --> 00:39:47,520
but

950
00:39:44,160 --> 00:39:50,000
the gtk css is not a web css

951
00:39:47,520 --> 00:39:52,160
you cannot influence layout for instance

952
00:39:50,000 --> 00:39:54,160
using gtk css

953
00:39:52,160 --> 00:39:56,400
because we cannot

954
00:39:54,160 --> 00:40:00,400
allow people to turn every single

955
00:39:56,400 --> 00:40:01,920
application into the css zen garden demo

956
00:40:00,400 --> 00:40:04,160
uh it would be

957
00:40:01,920 --> 00:40:07,359
terrible for documentation purposes or

958
00:40:04,160 --> 00:40:10,640
for accessibility or for

959
00:40:07,359 --> 00:40:12,960
general like reliability

960
00:40:10,640 --> 00:40:13,920
it would be pretty pretty bad

961
00:40:12,960 --> 00:40:16,960
um

962
00:40:13,920 --> 00:40:19,599
but to be fair the css

963
00:40:16,960 --> 00:40:20,800
implementation gave us enough freedom to

964
00:40:19,599 --> 00:40:22,560
do

965
00:40:20,800 --> 00:40:26,400
a lot more

966
00:40:22,560 --> 00:40:28,400
uh interesting user interfaces than

967
00:40:26,400 --> 00:40:31,520
the plain blocky

968
00:40:28,400 --> 00:40:32,880
style of um

969
00:40:31,520 --> 00:40:35,359
uis

970
00:40:32,880 --> 00:40:37,839
i don't know we will probably never

971
00:40:35,359 --> 00:40:41,839
catch up to the web in the sense that it

972
00:40:37,839 --> 00:40:41,839
doesn't always make sense to follow that

973
00:40:45,599 --> 00:40:50,240
the next question is

974
00:40:48,240 --> 00:40:53,200
really interesting to see your revamped

975
00:40:50,240 --> 00:40:55,040
documentation workflow any specific tips

976
00:40:53,200 --> 00:40:56,880
or lessons learned for other projects to

977
00:40:55,040 --> 00:40:59,280
ensure docs are both easy to use and to

978
00:40:56,880 --> 00:41:00,960
contribute to

979
00:40:59,280 --> 00:41:02,240
treat documentation as you treat your

980
00:41:00,960 --> 00:41:03,599
code

981
00:41:02,240 --> 00:41:06,160
if you

982
00:41:03,599 --> 00:41:08,240
make it super easy to contribute code to

983
00:41:06,160 --> 00:41:11,440
your project you should make it equally

984
00:41:08,240 --> 00:41:12,560
easy to contribute documentation

985
00:41:11,440 --> 00:41:16,000
so

986
00:41:12,560 --> 00:41:17,760
if you're generating code from

987
00:41:16,000 --> 00:41:19,599
your source code if you're generating

988
00:41:17,760 --> 00:41:20,960
documentation for your source code

989
00:41:19,599 --> 00:41:22,480
link the

990
00:41:20,960 --> 00:41:24,720
document the

991
00:41:22,480 --> 00:41:27,040
place where that happens from the

992
00:41:24,720 --> 00:41:29,760
documentation itself

993
00:41:27,040 --> 00:41:32,079
you can look at how rust does their

994
00:41:29,760 --> 00:41:35,040
documentation and

995
00:41:32,079 --> 00:41:38,400
i mean it i took liberal inspiration

996
00:41:35,040 --> 00:41:40,640
from ra stock and from cargo uh for the

997
00:41:38,400 --> 00:41:41,920
gtk documentation website

998
00:41:40,640 --> 00:41:44,720
um

999
00:41:41,920 --> 00:41:46,480
definitely definitely follow that again

1000
00:41:44,720 --> 00:41:48,880
if you make it easy to contribute to

1001
00:41:46,480 --> 00:41:50,319
your code there is no reason whatsoever

1002
00:41:48,880 --> 00:41:52,640
you should make it easier to convert

1003
00:41:50,319 --> 00:41:54,960
documentation that way

1004
00:41:52,640 --> 00:41:55,839
so follow the same

1005
00:41:54,960 --> 00:41:58,160
um

1006
00:41:55,839 --> 00:42:00,319
the same practices there

1007
00:41:58,160 --> 00:42:03,520
allow people to easily open a merge

1008
00:42:00,319 --> 00:42:05,440
request with the documentation fixes

1009
00:42:03,520 --> 00:42:09,760
especially if you can do that without

1010
00:42:05,440 --> 00:42:09,760
leaving the web browser for instance

1011
00:42:10,319 --> 00:42:14,400
thanks for that okay we have time for

1012
00:42:12,560 --> 00:42:18,319
one more question

1013
00:42:14,400 --> 00:42:22,960
how well does gnome slash gnome for work

1014
00:42:18,319 --> 00:42:24,640
over a network uh for example ssh-x

1015
00:42:22,960 --> 00:42:26,560
um

1016
00:42:24,640 --> 00:42:29,359
well if you're using x11 it works

1017
00:42:26,560 --> 00:42:30,720
exactly the same if you're using weyland

1018
00:42:29,359 --> 00:42:32,160
then

1019
00:42:30,720 --> 00:42:34,960
we actually

1020
00:42:32,160 --> 00:42:37,680
do remoting using

1021
00:42:34,960 --> 00:42:39,440
rdp slash vnc

1022
00:42:37,680 --> 00:42:42,079
we have an entire

1023
00:42:39,440 --> 00:42:44,000
new um

1024
00:42:42,079 --> 00:42:46,160
new layer that does that inside the

1025
00:42:44,000 --> 00:42:47,520
inside tonum shell that lets you do

1026
00:42:46,160 --> 00:42:50,160
screen sharing

1027
00:42:47,520 --> 00:42:52,160
uh so basically you send

1028
00:42:50,160 --> 00:42:53,839
complete frames and then you have

1029
00:42:52,160 --> 00:42:55,119
protocols that do

1030
00:42:53,839 --> 00:42:57,280
you can either

1031
00:42:55,119 --> 00:42:58,960
you can either have dumb protocols that

1032
00:42:57,280 --> 00:43:00,720
literally take the

1033
00:42:58,960 --> 00:43:01,920
the output and just send it over the

1034
00:43:00,720 --> 00:43:04,240
wire

1035
00:43:01,920 --> 00:43:06,319
with or without compression otherwise

1036
00:43:04,240 --> 00:43:07,760
you have smarter protocols that can do

1037
00:43:06,319 --> 00:43:10,800
diffing so

1038
00:43:07,760 --> 00:43:12,400
what you send is smaller than that

1039
00:43:10,800 --> 00:43:14,400
but in general

1040
00:43:12,400 --> 00:43:17,119
um

1041
00:43:14,400 --> 00:43:19,680
the x11 approach is actually the least

1042
00:43:17,119 --> 00:43:22,079
efficient possible way to do things

1043
00:43:19,680 --> 00:43:24,720
because it the

1044
00:43:22,079 --> 00:43:27,680
nobody uses x11

1045
00:43:24,720 --> 00:43:30,160
draw commands anymore um unless you're

1046
00:43:27,680 --> 00:43:31,440
using application from the 80s or early

1047
00:43:30,160 --> 00:43:32,240
90s

1048
00:43:31,440 --> 00:43:35,119
um

1049
00:43:32,240 --> 00:43:37,119
and the other thing is that it's very

1050
00:43:35,119 --> 00:43:40,319
bandwidth and efficient

1051
00:43:37,119 --> 00:43:42,720
it sends a lot of data anyway

1052
00:43:40,319 --> 00:43:46,160
interleaved with commands

1053
00:43:42,720 --> 00:43:48,400
so if you're using protocols like vnc or

1054
00:43:46,160 --> 00:43:51,599
rdp it's usually much more efficient

1055
00:43:48,400 --> 00:43:51,599
because they can do compression

1056
00:43:51,760 --> 00:43:54,960
or even you don't even need to do that

1057
00:43:53,440 --> 00:43:57,680
gtk has a

1058
00:43:54,960 --> 00:43:59,359
html backend that literally runs your

1059
00:43:57,680 --> 00:44:01,520
application

1060
00:43:59,359 --> 00:44:04,160
on the server and then

1061
00:44:01,520 --> 00:44:06,800
sends the

1062
00:44:04,160 --> 00:44:10,960
the structure of the ui and various

1063
00:44:06,800 --> 00:44:13,599
assets to using websocket from a server

1064
00:44:10,960 --> 00:44:15,760
to the web browser pointed at a specific

1065
00:44:13,599 --> 00:44:19,280
url and port

1066
00:44:15,760 --> 00:44:21,520
it literally works as a remoting api and

1067
00:44:19,280 --> 00:44:25,040
i know of people using it in production

1068
00:44:21,520 --> 00:44:25,040
which scares the hell out of me

1069
00:44:25,359 --> 00:44:30,400
but it has that functionality as well

1070
00:44:28,240 --> 00:44:32,240
and people use it so

1071
00:44:30,400 --> 00:44:34,480
it's not just

1072
00:44:32,240 --> 00:44:38,079
that is definitely more efficient than

1073
00:44:34,480 --> 00:44:38,079
using x by ssh

1074
00:44:38,319 --> 00:44:41,599
all right well thank you we there was

1075
00:44:39,760 --> 00:44:44,880
one more question but um we're out of

1076
00:44:41,599 --> 00:44:48,560
time so we will transfer that question

1077
00:44:44,880 --> 00:44:53,520
over to the post talk chat kaya theater

1078
00:44:48,560 --> 00:44:55,200
channel in venulis um for you to have a

1079
00:44:53,520 --> 00:44:57,280
bit of a chat with emmanuella after the

1080
00:44:55,200 --> 00:44:58,560
talk if that's all right with you

1081
00:44:57,280 --> 00:45:00,800
absolutely

1082
00:44:58,560 --> 00:45:03,359
great um so

1083
00:45:00,800 --> 00:45:05,839
thank you very much emanuela for that

1084
00:45:03,359 --> 00:45:06,560
really interesting talk um

1085
00:45:05,839 --> 00:45:08,319
and

1086
00:45:06,560 --> 00:45:10,800
yeah um

1087
00:45:08,319 --> 00:45:12,880
your approach to all of this redesign

1088
00:45:10,800 --> 00:45:14,960
work and so on is is

1089
00:45:12,880 --> 00:45:16,960
um quite nice to hear about

1090
00:45:14,960 --> 00:45:19,599
um before we

1091
00:45:16,960 --> 00:45:22,240
um close off the stream for the day

1092
00:45:19,599 --> 00:45:26,400
um so this is the end of our normal

1093
00:45:22,240 --> 00:45:27,839
talks for today for linuxconfeio

1094
00:45:26,400 --> 00:45:32,000
um but

1095
00:45:27,839 --> 00:45:32,800
there is there is one more so if you are

1096
00:45:32,000 --> 00:45:34,800
a

1097
00:45:32,800 --> 00:45:38,160
professional or contributor ticket

1098
00:45:34,800 --> 00:45:40,000
holder remember to join us from 6 30

1099
00:45:38,160 --> 00:45:42,160
conference time

1100
00:45:40,000 --> 00:45:44,319
in venulis it'll be in a different stage

1101
00:45:42,160 --> 00:45:46,960
to what we're looking at right now for

1102
00:45:44,319 --> 00:45:48,560
the professional delegates networking

1103
00:45:46,960 --> 00:45:50,640
session and a really interesting

1104
00:45:48,560 --> 00:45:53,760
presentation from anthony green on

1105
00:45:50,640 --> 00:45:56,640
election analysis um so if

1106
00:45:53,760 --> 00:45:59,119
you are such a ticket holder um or a

1107
00:45:56,640 --> 00:46:02,240
speaker and you are going to that don't

1108
00:45:59,119 --> 00:46:04,160
miss it it's tonight um and

1109
00:46:02,240 --> 00:46:05,440
for those who are going to that and

1110
00:46:04,160 --> 00:46:07,599
those who aren't

1111
00:46:05,440 --> 00:46:10,319
have a lovely evening and we'll see you

1112
00:46:07,599 --> 00:46:11,530
back here tomorrow

1113
00:46:10,319 --> 00:46:14,689
bye

1114
00:46:11,530 --> 00:46:14,689
[Music]