We're the video people.

Okay, we'll have one minute for me to start. So we have Russ, who's gonna be talking about the ESL toolkit. All right, hello everyone.

Thank you very much. First, I'd like to say thank you everyone for turning up. It's much better than an empty auditorium. Secondly, I have a really bad habit of speaking quickly. I'll happily go through all my slides in about 16 seconds

if you don't slow me down. So if I'm going too fast, someone just wave your hand in the air and go slow down. I will try and remember to go more slowly. If you have any questions during the presentation,

it's actually probably better that you ask the question at that time, otherwise you'll forget it by the end or something. If I have an answer for your question, I'll tell you the answer's coming in a few slides. So just if you have a question, put your hand in the air and wave it around and get my attention. Oh yeah, actually I'll just repeat the questions.

Yeah, so if you ask a question, I'll repeat it. So the recordings get it. So anyway, how many of you are new to Linux or open source? This is a new thing. Hands up. Wow, you're all old time, open source Linux-y people.

You should all have beards by now, shouldn't you? At least some of you do. At least you're down to the neck, that's where your beards should go. Anyway, I'm just filling in time, letting people come in. But I should actually start about now.

Okay, who here has not heard of EFL or Enlightenment? New, okay, so about 1%, okay. Some very small percentage of you don't know what it is. Who here does not have a mobile phone?

Wow, who here does not have a smartphone? Okay, all right, that's actually a fair number. I'll keep that in mind for the next few minutes. Anyway, I'm here to talk about EFL. EFL is the set of libraries that are behind Enlightenment.

A lot of people go, why do you guys don't release a new version of Enlightenment? Well, we had this thing where we got distracted into writing toolkits instead of writing window managers. So I'll get into that a bit later. But EFL is the toolkit behind Enlightenment and we've been working on it for quite a while now.

So let me launch into that. Anyway, before I launch into that, the last time I was at FOSDEM here was about 10 years ago at the very first FOSDEM and I'm actually very, very happy to be back. Haven't been back for a while, so thank you very much for having me. I, these days, hang out at a company, a small company some of you may have heard of before.

It's called Samsung. They make these little things like phones and televisions that like one or two people use. And one of the things they use now is EFL, so I'm there to help out and create lots of trouble. If you have any questions about that, go ahead and ask.

Anyway, what is EFL? For those who don't know, it's a bunch of libraries. It's not just one library. In fact, that's actually a bit of a marketing mistake on our part. The fact that we have so many libraries confuses people. So we end up calling them EFL. They are done by the same group of people.

Some of those people, to blame for EFL, are sitting right there in that little group there. So if you want to blame them for something, just throw like, rotten tomatoes and stuff about down there. I'll get out of the way so you don't have to hit me. So there's several sitting here. They were built for the purpose of working

on the next version of enlightenment, i.e. 17. And in the process, we got unfortunately a bit distracted and just started liking more and more and more libraries. It grew and grew. And the window manager kind of took a back seat to writing, it's actually a bit what happened to GTK and GIMP at some point, but it split.

We're still the same group. One of the things that we focused on that was very, very interesting was to make a set of libraries that were small and efficient and lean. Way, way back when dinosaurs roamed the earth and I was still working for a Silicon Valley startup

at the time, dot com boom, that thing. I realized that the future of Linux, despite the fact that every year for the last decade or almost two has been declared year of the Linux desktop, has not happened.

The year of the Linux desktop happened and I realized that the desktop wasn't going to happen because it was really a niche market. The place where Linux is strong and has strengths is in embedded. So as of that very day I was very interested in embedded, that things had to be small, lean and mean so they could run on these tiny little arm devices

and whatever else you had. And so that's why being small and efficient is very important to EFL, so we can do that. And unfortunately we also got distracted into just working on EFL, literally. The vast majority of our code in SVN is actually EFL and only a tiny little bit is the window manager

these days. And of course in trying to make a whole window manager and all its configuration tools and everything else along the way, the libraries tend to cover a very wide range of things. Not because they were designed to do it, just because they had to, it was a matter of necessity.

So they've been basically scratching itches, solving problems as they need solving rather than designing to be like a toolkit for everyone and everything. But in the process, they tend to solve the same problems that most programmers have in writing applications. These days, out of just the core EFL,

only about 26% is actual enlightenment, the rest is libraries. In fact, we actually have even more libraries beyond that that I'm not even covering. And even of that set, only about half the code in SVN is enlightenment plus core libraries. The rest of it is all sorts of other wondrous, interesting things

that will keep you interested for a while. So the actual history long back was back in 1996 when dinosaurs roamed the earth and I started writing stuff for Linux. Enlightenment was just that, it was just a window manager and nothing else.

At that time, I hated the library called libxpm, mostly because I just hated XPMs. They were horrible little text files that were meant to be images. And I started writing code to load other image formats and to render them much better than XPM. That code became ImLib, became a separate library

and then eventually became ImLib 2, which has actually been deprecated and we now do everything with Evers and Ecore and Edge and a whole bunch of other libraries. So these days in SVN on the right hand side, EFL is that big yellow blob. Enlightenment's the little blue one and really just the old legacy stuff, E16 is the rest.

We actually still do maintain E16. Kim Walders does actually an interesting job of working on that all the time, quite impressive. So we're actually quite old.

We've been around since 96. A lot of people may not have heard of the work we do, but we've been sitting in the background and actually creating a lot of things. That's kind of the, on the screen, the timeline. There's no point me reading it out. All the things we've done, but we have actually supported GNOME and GTK in the past.

We have written code that's generally usable. ImLib 2 has been used a lot in many places. And these days, EFL is being used increasingly in the embedded space, which is becoming very interesting. So a small list of libraries is there. We've got ENER, which apparently means tool in Spanish,

and Embryo, which is a small virtual machine. That actually is thanks to work done by a Dutch company on a program language called Small, or these days called Pawn, and that's P-A-W-N, with a W. And that was a small virtual machine

interpreting engine and compiler. We've got Dbus bindings to support free desktop and Linux standards, E-Thumb, Dbus-based thumbnail, Emotion is a whole video layer. It supports both, it supports Gstreamer, Xyn, and VLC as backends for doing the video.

And many, many other things. Elementary is, in fact, today the more interesting element because it is actually the widget set and toolkit. Everything else is lower-level libraries to help you build toolkits. So one of the core interesting things is Evis.

Evis is a scene graph canvas library. That means you don't draw anything, you create. So you create an image, you create a rectangle, a blob of text, and then you manipulate that. You move it, you resize it, show it, hide it.

You stack objects on top of each other, change their colors, fade them in and out. With this, you can actually create almost anything. The advantage of it being a scene graph is that the programmer doesn't actually have to know how to draw or render anything. He just puts the things together. The scene graph can optimize all your rendering

by throwing out lots of work that it just doesn't need to do because it has one big advantage over an immediate mode rendering system like OpenGL or Cairo or anything like that. It's because it has the whole scene in memory already before it starts rendering. So it knows what it has to do in future and therefore it can avoid doing work

it knows it's gonna throw out along the way. It supports software rendering. There is some code in there to support Pixman. There used to be a Cairo engine at one point. Unfortunately, that Cairo engine was a bit too slow to continue working on.

It was actually, benchmarks ran about 1 20th of the speed of Eversys software engine. So there was almost no point in working on it. But there is support for Pixman, which is the back end of both Cairo and XRender when doing software. In addition, it also supports OpenGL, desktop OpenGL,

GLX and EGL and OpenGL ES, which means if you have a GPU with an appropriate GL library, it will actually be accelerated. And it will actually accelerate everything through OpenGL. Rendering all text, rendering every rectangle, every image, everything will be rendered as a texture, as a set of triangles and polygons.

It actually has quite an interesting little engine to try and batch the vertices together in as few GL operations as possible. We also have a main loop library, Ecore. It also handles things like network connections, other abstractions, and it glues together Evers

and your display system to make life easier so you don't have to do it for you. Originally, Evers was written so it could actually work with any toolkit. It didn't have a main loop, linkage of its own. It had an abstracted rendering engine so you could render to any toolkit surface,

whether it's QT, GTK, Windows, et cetera. But these days, it mostly doesn't use that abstraction. Although the advantage is we actually also have ports to Windows. We have Windows CE, Win32, rendering, DirectFB. There used to be a Cutopia one as well that's been deprecated.

Yeah, OpenGL ES, X11. And for anyone turning up to the talk that's not after this, but the one after that, we in fact also now have Wayland support. We support both GL and software rendering in Wayland, so software via the shared memory buffers.

The EFL clients now also support client-side frames, so you'll actually get title bars and borders and you'll resize your windows. It'll actually work. And in fact, as of just recently, we also have Wayland compositor support in Enlightenment in the Window Manager. So Wayland clients should work inside of Enlightenment as well.

So we just added that. At this stage, I believe that the EFL port to Wayland is actually the most complete port of all the toolkits. So we actually have a lot of Wayland support happening. In addition, we have this cool little library called EAT. Nothing I know of is like EAT. It's basically a data structure serialization library.

It can take any data structure and memory from C or C++ and just walk through memory, dump it to disk as a portable blob of data, and it can do the reverse. It can read it back from disk, and it's extremely fast in doing it. This is in fact the backend that is used for Edge, which I'll talk about later,

that at runtime to build every single widget, you load a bunch of data from disk and then generate objects out of it, et cetera, and all of it's encoded and decoded using EAT. There's embryo, bytecode, virtual machine. Not that interesting, except it's actually extremely small. The core code for the VM is like 2,000 lines of C. It's like a 35 kilobyte shared library

in total for everything. So it's very, very small and sandboxed and very fast. Edge is the way you can store pre-designed graphics on disk in a very, very, very small, efficient way. A lot of you are probably familiar with HTML and CSS,

where you type out a bunch of XML-style stuff and a bunch of CSS, and you glue it all together, and you parse that, then you load a bunch of images, you refer to them, et cetera, et cetera. Edge is like that, except the source code, the text files are compiled into binary. All the source data is also put into the same file.

That means images, fonts, anything else you want. And when it's loaded, it's all sourced from the same single file. So it is in fact very, very small, efficient and fast. You just put one file on disk, and it just works. You don't have to unpack or download multiple things, et cetera.

We also support free desktop.org standards with Efreet, like desktop files, the free desktop.org menu standards, et cetera, et cetera. And Efreet is a library to help support that, to parse the files, et cetera. ENER is kind of a bit like a glib thing, which

does some basic data structures, and it's now adding some object model things, et cetera. It's really just a core to make it easier to write our code. A lot of these data structures used to exist actually inside of Evis, and they got removed and moved out. So that's why that exists. The Dbus integration library, the Dbus stuff.

We have asynchronous IO with EIO that's being added. We've got video playback with emotion, which is really simple. You just create an object, put it somewhere, say play, and it just sits there and plays. You don't have to do anything else. You can take that object and rotate it and do all sorts of other things with it. There is a UDEV support library

called Ease for trying to replace howl and stuff like that. We've got thumbnailing things for emotion. I'm sorry, thumbnailing from E-Thumb that supports the thumbnail standards from free desktop.org. And elementary, which is the really interesting bit, which is all the widgets, so lists, buttons, checkboxes,

scrollers, pop-up thingies, everything else that lives in elementary. And something that is actually of real interest coming on its way, and it is actually in SVN already, we've got elevate. Elevate is a JavaScript runtime. I guess you can think of it a bit like QML, or you can think of it as some kind of cross between Python

and the EFL bindings for Python. It allows you to write applications in JavaScript. You actually declare the user interface in JSON at the beginning of a JavaScript and just say, here, create my interface out of that, and it works. It's quite easy to use, but it's still on its way.

It's still a bit immature. So why does EFL matter? Why does anyone care? Why don't we just all use KD or just use QT? Well, on QT or GTK or GNOME or something else. The reason it matters is that at Samsung for a while,

we've been using EFL. The reason we're using EFL is we were using GTK at some point. This is before I joined. But apparently, the performance was not that good. And they tried EFL, and it just worked. Out of the box, performance was good. It was easy to use. And now, as a result, EFL is actually being used in Tizen.

Tizen is, as some people might think of it, a replacement for MeeGo. Who here knows about MeeGo? Wow, that's pretty good coverage for the MeeGo. Who here knows about Tizen? Wow, that's pretty good.

So EFL is the toolkit being used in Tizen because it supports OpenGL, OpenGL ES. It will work without OpenGL. If you just have pure software rendering, it'll work and actually be fast and usable. So it's being used because it actually delivers all of these things. It actually works out of the box and works well.

So seeing you all know what Tizen is, I don't have to really tell you much about that. But EFL is also open. Tizen is intended to be open. The source code was actually released in Git repositories recently. So you can actually get most of the code. And if you want to write native applications as opposed to web applications, EFL is going

to be your easiest way of writing those applications. Because otherwise, you'll probably have to write your own toolkit or include in your application. So all the APIs in EFL are C APIs, I guess, in that way, like GTK. That makes it easy to use from both C and C++.

So you don't have to particularly choose just C++ for your applications or just C. You can use either. That also makes it very easy to bind to other languages. There are already an extensive set of Python bindings for EFL that will allow you to use Python.

Although, at this stage, I know of no Python interpreter being added to the Tizen platform by default. So why do we need another mobilize? Who here has an Android phone? Who here would prefer their phone to, let's say, have a proper full Linux stack and not be Android?

I see. Very good. And that's why Tizen exists, to basically make a better open OS that uses a full Linux stack underneath, not just a kernel, glibc, dbus, x, blah, blah, blah, blah, blah. That's what Tizen is here for.

So you can have a proper open platform that you all know how to already program for and use and customize, et cetera, et cetera. Android is only partly open. The Android 3 series, the source code was not released by Google. So at their discretion, they chose

not to release it, which doesn't exactly make it open. Windows Phone 7, well, that's about as open as a brick. And the same with iOS. So the world really needs an open solution that will be open and will stay open. And it will not be at the discretion of the originator

just be closed up and not released. Of course, you don't want to. But why don't we just use Mer or some one of these open operating systems and stick them on phones? The reality is, unfortunately, in the hardware world, to put an operating system on an existing tablet or phone is extremely difficult, unless you are an OEM.

You will need access to drivers, to binaries, to things that you will not get in the open. So to ship something out of the box on a device needs OEM and telco support. And that's actually what Tizen has. It has the support of these entities. So there is a good capability of it actually

succeeding in future. So next. So who here actually doesn't know what's in Tizen?

OK, that's what's in it. Really, and I've heard lots of questions about it before. It's really just glibc, eglibc, which is the embedded variant of glibc. Standard dbus stuff, x, and so on, et cetera, et cetera. All of that stuff's in there, and there's

EFL floating around in there, which is one of the major components. In fact, in a recent look at most of the usable APIs in the Tizen platform, C APIs, EFL is like about 2-thirds of the APIs from the libraries. So it has a very, very, very vast number

of API calls available. So I've already explained that EFL is the core. We're using that because it works. The compositor and window manager's enlightenment, all of the applications, even the web browser, they use EFL to render and display and do

widgets, et cetera, et cetera. Everything is open or as open as it allows. Unfortunately, some things like GL drivers are not open. You'll have to talk to OEMs. Well, not to OEMs, sorry, to GPU vendors about those kind of things, et cetera.

If you want to write native apps, EFL is the easiest thing to do. And it will allow you to pretty much create anything you want from games through to things with lists and buttons, et cetera, et cetera. It has almost everything you need, and if you don't have it, you can always use some other library. It's designed to work with shared libraries

and with other libraries, not to totally wrap them and replace them at every opportunity. So a lot of people ask the question, is why EFL instead of GTK or QT? Since it's a common question, I'll have to answer it here.

GTK, in our experience when running on actual devices, just didn't end up being smooth. It didn't give the performance we wanted or needed. So we didn't really like that, and EFL was chosen to replace that.

Because before, we were using GTK, and we tried direct FB, and it just had no performance. Even without direct FB, it didn't work too well. EFL was fast without any GPU acceleration, with zero GPU, with just the CPU. It was already fast. And that's why it attracted attention.

The OpenGL support in EFL is actually pretty good. It's been around for a very long time, and it got extended to OpenGL ES, and it has actually proven to work on many, many platforms from desktop, Intel, NVIDIA, ATI, and everything else, all the way through to SGX and Mali

and all the embedded variants. And one of the things that's very important is that your applications will tend to work very, very smoothly. You'll be scrolling around at 60 frames a second. You know, your animations will stay smooth, and that actually works.

One of the other reasons is memory footprint. EFL has a fairly small memory footprint. Just as a very, very simple example, comparing Unity and Enlightenment, which actually do the same thing, there's about a 60-something megabyte difference

in memory footprint, and that really matters when you have phones that only have like 128 or 256 megabytes of RAM, when you have to pay such large prices for your footprint. And both of those have roughly similar features for that memory footprint.

So phones and tablets, they really don't have memory. They can't afford to have swap either. Swap is not something you can easily do on a device where if you write to disk more than a certain number of times, it breaks. And that's actually what swap does.

Yes, I know it did. Well, actually it had it as an option, I believe, right? I could've sworn it was an option you had to turn on, right? I could've sworn it was there in an option to turn on. Really?

Okay, so I swore it was an option in MIMO 5. No? It was an option. Maybe it was an option to turn it off then, though. I remember an option being there. Anyway, okay.

But that only had 128 meg of RAM. Was it? Maybe it was an early one with 128. Maybe. Or maybe it was, I'm just thinking, the N810. But anyway, I had an N800 and an N900 as well and I get confused which one was what. I can't remember anymore.

But yeah, with very little memory, you tend to begin to have problems. And so lowering your memory footprint makes the difference between a platform that can run your dialer and nothing else. You can make a phone call and do nothing versus you can do 20 different things at the same time. Of course, you really don't have the luxury of swap,

generally speaking. In theory, it's possible, but it's kind of difficult. So for everyone who likes block diagrams, here's a block diagram we created for you. I keep getting asked for block diagrams all the time. I don't understand why, but I made a block diagram it looks like that, or at least some of the components.

And reality is it looks more like that. With all these little things joining something else and something plugged into something else. This diagram's actually quite old. I did this diagram again when someone asked and I went, well, the block diagram's not right. This is correct. But yeah, it's much harder to understand. So EFL does look a bit like that

with everything interconnected. And generally speaking, if you were to equate it to QT, QT is just a big blob that is QT internally. Well, internally it's split up, but you'll see something. And GTK would be vaguely similar internally, but you tend to get one blob. Whereas EFL, we expose our internals.

So the real question is, if you have heard about EFL and you want to use it, where do you start? Well, several distributions package EFL. There's Bode, there's PC Linux OS. I think Gen 2 has had e-builds forever and a day,

Arch Linux and so on. If you look around, you'll find packages. Although I generally don't tend to use them, I just check the thing out of SVN and build it. Funny that, I write the code. So there's lots of information as to how to download it, where to get it from. You can use the tarball downloads. We actually have done releases of EFL.

Funny that. And you can compile it from there. That's not very hard. Configure, make, make install per thing. There's nothing really magic about it. You can check it out from SVN. It's pretty much the same. It's autogen.sh, make, make install. And someone nicely wrote a beautiful script there.

His name is More Linux, or More Linuxes. And he maintains that, and a lot of people use the EZ 17 shell script that goes and installs dependencies and other things for you and builds everything in correct order. So one of the things that's probably useful to know is how it all works.

One of the things that tends to be a bit mysterious is things magically display and render without you having to do anything. So to understand how that works, you've gotta know that there is a main loop and how that functions. So we have a main loop. The idea of a main loop is you keep all your applications state in the main loop. You try and avoid doing work in the main loop.

That means going and reading files from disk, parsing stuff, going and doing network things, or like doing complex calculations. You mostly try and keep your state in the main loop. That means you have one place where you have a consistent state machine. You can do small little bits of work,

but make sure they're small and they don't block. One of the big questions I keep getting asked is thread support. EFL is not thread safe. It is, in fact, actually kind of hard to make it thread safe because, well, not thread safe, but work really well threads, because there's a main loop that maintains state, and when you finish changing state, it renders. The question is, when a thread changes your state,

when does that finish? So you need to add things, like you have to add functions that wake up the main loop and say, hey, main loop, wake up, and please re-render and change your state because I changed things for you. And that makes the little bit more complicated in using threads. So we have actual primitives to help you do that, but they still run all the logic in the main loop.

But you can still do all your calculations and other stuff off of threads. And that's actually kind of useful, considering a lot of modern smartphones these days have like two processors. They're even coming out with quad cores now. But we do have a lot of support for the threads. The main loop looks something like that. It's pretty simple.

You just sit around and wait for something to happen. When it happens, you go and read data, generate events, handle your events, change your state. And just before you go to sleep, just before you finish changing the state of the world, you go and update all your screen. You do your rendering. So all the rendering happens there at just about go to sleep. Ecore, Ecore ever glues that in for you and sets it up.

This means you don't need to know about rendering ever. All you do is you sit there, you change your state, create your buttons, move your objects around, change your color, and magically everything updates because when you're finished changing it, it just goes and renders.

One of the things that is very important in making really good products and really good software is keeping things smooth. I have to say this is something that the Mac and iPhone developers really, really care a lot about. They go to a lot of efforts to make sure the applications are smooth. They don't always get it right, but they tend to do a very, very good job. It's something that most other developers

tend to spend less effort on. So one of the things that's gonna help you make sure you have smooth interfaces and a nice experience for users is to keep heavy IO work or heavy computation work outside of the main loop. Put it in a thread, go and put it in a child process,

wait till it's done, collect the results, and then update your UI. This also tends to lead to nicer design with your application where you will isolate certain work units into their own areas. If you use the Ecore thread and other things in Ecore

that are there to make that happen, this is actually very, very, very easy. You don't have to go and create your own threads with Pthread and create little Pthread conditions and have things block and wait and wake things up and mutex is everywhere. It actually tends to handle that all for you by piping things through file descriptors and waking the main loop up for you when a result comes in.

So by doing this, you also keep the state of the application consistent. So while something is busy off generating some new data or loading something from disk, downloading it from the network, your main state stays exactly the same. Nothing is half done. And when it's finished, it can send the results back to the main loop to update the UI.

EFL has an actual very interesting concept that I believe only got recently added to GTK, right? And to glib. It's the idea of an animator. From way back when, when I was doing work on Gnome and GTK, one of the things that was the only way to do animation

is you create a JIT timeout. And that means there's a little timer that continuously loops and runs again and again and again and then changes your animation. Generates a new frame, moves an object, changes the state of something. What actually happened was that people had to set the actual timeout themselves.

So you decide that this timeout will repeat at 30 frames a second or 60 frames a second or 40 or 10 or whatever. And everyone would generate a new timeout for each and every animation on the screen. EFL has one single way of doing this. It's called animators. With an animator, you just say, whenever you have to animate and generate a frame,

call this function. And it will animate at a given frame rate for the whole application. In fact, actually, E-Call will try and synchronize all applications to start their frames at exactly the same point in time. So even different applications will synchronize with each other. And this makes life a lot easier where you don't have to handle knowing different frame rates for different parts

of the application. But it also leads to much smoother and more synchronized animations at the same time. So use those instead of timers. It definitely helps. So if you want to use threads to try and offload stuff, it's really easy. EFL or E-Core has a, they're E-Core threads.

And E-Core threads are basically a worker queue. A lot of this really looks, there's entire big fat articles about the Mac OS Grand Central threading. The E-Core threading stuff is very, very similar in that way from an API point of view. Unfortunately, we don't have the same support at the kernel level for knowing how many cores are busy at any one time and scheduling appropriately

because it's being done off in user space. But if such information is made available from the kernel in a way that we can use it nicely, we could do that too. But the API hides all of that. So all you do is you put a job on a queue and all the worker threads happily go off and work at that. It'll actually allocate as many worker threads

as you have cores. So it tries vaguely to not overload your machine. So that's it. Now, here's a hello world thing in EFL if you want to write applications. It's not very hard. So if you start, you just include elementary.h,

create a main function. Yes, that little weird thing here, that thing there, that's actually a macro that allows you to compile your application as both a binary and as a shared library. So you can actually deal open the shared library and run it as an application. It allows you to run write applications at start faster.

Yes, you could compile a binary with minus PE or whatever it is to make it also execute while it's shared. You could do that as well. So it allows both of those methods. But the macro basically hides that and creates a new entry point over there. And so you just create a window, show it, and run.

It's really as easy as that. It's not very hard. So if you want to handle your window being deleted, just add a callback to handle a deal with the delete request and a function on a request to delete just to exit. Really, really easy.

And so now if we want to fill the window with something, just create a box, put a label in it, hello world. Pack it at the end of the box, because the box has nothing in the end, and just show it. And then if you want the button, again, create button, set text, put it at the end, show it.

And if you click on the object, call the onOK function, which is just to exit. I mean, that's as easy as it is. And compiling is also very easy. And you can do this in JavaScript, too. This is what elevate looks like. You just declare your window, a label. Hello is the title.

You put a background. In the previous example, there was no background. Of course, a utility function added it for you. You add a box. Resize means the resize object part of the window. You add an element, a label. You add a button, a label, and that's it. There is, in fact, no code to this program at all. Zero code. Well, actually, there is onClicked function.

But there's really no other code. You just declare your GUI. It looks a lot like HTML in that way. You create a bunch of divs and so on. It's very easy to do, very compact. And it's a good way to rapidly create applications. And running it, it's really easy, too. In fact, actually, you can put a hashbang user bin,

elevator, whatever at the top, and that will also work just like a shell. And that's it. So one of the things that EFL is very good at is not just regular interfaces. It's actually doing something interesting and fancy. Every single widget is an object. You can resize, rotate.

You can fade in and out. You can layer widgets on top of each other. So they can be stacked and semi-transparent, et cetera, et cetera. So this is an example of using an existing widget that does fancy things for you with widgets. So create a window, set a title on delete, handle exiting.

Now, this adds a custom background, which is, in fact, quite easy. You just tell it the JPEG, and it'll automatically scale it and size it. And we'll add a box with a little flip button in the middle, and you can see the preview up there. Then we'll add some text in there,

where it allows a bit of markup in your text. People have asked before, yes, the text all supports complex text. So you can do Hebrew and Arabic, as well as Hindi. So it'll do text composition and everything else. It uses half-buzz and freebitty and rearm, lib-line-break,

and all sorts of other funky things. Tom over there is to blame for that. He's done a lot of that work. So now we'll create a list and just put a bunch of items in the list. All these actually, these are just callbacks and parameters. The basic list widget is just designed to be very, very simple and easy to use, not very fancy.

So create a bunch of list items. And then if you click on the flip button, it'll literally flip like that. So it'll literally flip around a cube. It's that easy to do that. So you can just have two widgets flip between each other.

So that's really what the code looks like at the end of the day. It's not very much. Well, in UI terms, it's not very much. So a lot of people ask, well, what really is a scene graph? How do you work with this? One of the things you have to remember is that you don't draw.

You create. You position objects. One object can control the position and size and location of other objects. So you can pack them in each other. You just change properties. And when you finish changing the property, the canvas evaluates the current state of the world and renders the changes. So if actually nothing visually changed,

it actually goes and does nothing. It just says, oh, nothing changed and avoids rendering. It handles all the loading of fonts for you. It handles rendering those fonts to glyphs. It handles loading images and rendering all of those. It handles trying to remove rendering. So if you've got a big, solid object covering

another object and that object underneath moves or changes or fades in and out, it will actually do nothing. It'll convert that to a no op. So you can avoid doing that yourself. And because it's a very high-level abstraction, it makes it very easy for it to abstract to things like OpenGL. So that's why there is a full OpenGL back end that

puts everything for OpenGL, textures, everything textures, everything glyphs, a whole bunch of vertices, et cetera. So you don't have to know or care about that. And it handles that for you. So when you have a scene graph, OK, the reason why I originally started a scene graph

was actually thanks to Frederico, Frederico Mena from the GNOME team. He wrote a GNOME Canvas thing, and it was really kind of cool. And when I was writing a file manager way back when for Enlightenment that was meant to be for E17, I discovered that really a canvas was a much better

abstraction model for doing things like writing a file manager because really all your widgets were really a collection of icons and text and rectangles and so on on the screen that you just moved around and manipulated. So a canvas really is just an area in which you stick these objects and you move them, resize them, and manipulate them. Widgets are really just pre-made selections

of objects grouped together that are automatically organized for you. So generally speaking, a canvas looks something like that. You might have an icon, a label, like a big button widget here, et cetera, et cetera, and a scroll bar or whatever on the side in the background.

Canvas just is full of this stuff. So you put all these together, you can create anything. A button is really a background, some text, some overlay, a bit more shiny stuff on top. Unfortunately, LibreOffice does a really horrible job of interpolating colors there.

That's why the little black outline, that's a bug, should be fixed. And all of those put together, you end up with a button. That's a really poor, horrible representation of it. But you just place one object on top of the other, and you can make anything. This actually allows a lot of freedom. So designers and artists, if they can break up something

into many layers and place them together, which artists actually do. Most artists spend their days in Photoshop or GIMP, as we'd like them to spend their days. And they just divide all these UIs into all these layers of objects all put on top of each other. And every widget and every button and every checkbox and everything is just made up of these.

So for your artists to actually design new things is actually very easy. They work in the same paradigm they already work in. So one library that helps you make these pre-made objects is called Edge. It allows you to design these objects in a text file. Unfortunately, these text files were never really intended to be the ultimate expression

tool of a designer or artist. They were really an intermediate stage of us getting data into a file so we could do something. But unfortunately, they've stuck around. Just like most technology, you create something, it works, and everyone keeps using it. And they extend it and use it and extend it and use it.

And there's really just no end to it. But the Edge files might be a bit verbose, but they do allow you to design all of this into a data file. So all these data files have rules as to how this resizes, how it scales, where everything aligns and fits, and what happens when you set a different scaling factor, et cetera, et cetera.

You can even put in scripting in there. You can create the little circular dial things, which Raul down maybe. Where's Raul gone? Oh, there you are. He's gone and created little circular sliders. So there's a widget in elementary, a slider widget, which is like a horizontal slider. With just a change of the Edge file in the theme,

you can make a little circular dial out of the same thing. So one of our crazy French people did that, as all our French people are crazy, by definition. Yes, and they're proud of being crazy, which is actually kind of scary.

So anyway, all these Edge files store all of this in data files. So the entire look of your user interface, all your theme, is just a data file somewhere on disk. And you just point to it. It's not like 20 data files you've got to go hunting through. It's actually quite simple. It's very, very fast to load these files. They're designed for runtime speed.

They're designed for the idea that your designer can design your look of your user interface, not necessarily the exact layout of your applications, but what a button looks like, what sliders look like, how they behave. They can do that completely separately to the programmer. And later on, when you're ready, you just put the data files together and presto. At any point in time, the data files can be replaced.

Even by third parties as users, they can create their own themes and so on. It was specifically designed to make this easy. So your entire OS can look entirely different just with a theme file change. And it's very, very easy to do. Edge files look like this.

They look somewhere in between CSS, JSON, and I guess, HTML slash XML. It's really just a bunch of properties. You create a group. You can say what your resources are, a bunch of images, a background. This tells the background to have an aspect ratio of 1

by minimum, maximum aspect ratio. It allows a bit of fuzziness. And what drives the aspect or the sizing in the image. And then you put a text label on top and text. And then I can put a shadow thing. And your result is something like that.

You notice that the same file looks like this. But when it's small or horizontally, the background doesn't get stretched. It stays the correct aspect ratio. The text remains the same, but the shadow stretches. And exactly the same here. So one file can scale and resize to almost any state.

It also supports scalable UIs. So just by setting scaling factor, the text, because it was set to scale, will scale. And the other things won't change. So putting these all together in something like elementary, which uses edge for theming, you literally will get widgets.

The button looks like that versus button there. That's actually multiple different layers. This widget and this frame look different. The borders look different for the window manager, et cetera, et cetera, just with some theme changes. And scaling literally works like that. Interestingly, the button is always large,

because there's something else in elementary which enforces what's called finger size. And finger size is designed to always keep an element you're meant to touch with your finger or a mouse at least a certain size, so it's easy to hit. Elementary is the widget set that actually pulls this all together. It just enforces certain policies

to make things easier, to save programmers having to implement that policy again and again themselves. Sometimes programmers don't realize how much policy it implements and go and try and implement those policies themselves repeatedly. Unfortunately, it ends up conflicting with what elementary does. It means that all your applications use the same theme, same look.

Well, actually, you don't have to, but they can. It handles all the scalability set up, et cetera, et cetera, and gives you all the widgets by default, all the standard widgets you'd like to use. And it's actually touch screen and finger friendly out of the box. It also works with keyboard, mouse, and everything else. So that saves you a lot of work.

The good thing here is that suddenly, because everything is built on top of Evis and Edge and all these layers, your application will be able to render magically using OpenGL. You change zero lines of code, and suddenly your application uses OpenGL to render everything, because it's handled all the way to the bottom.

It enforces finger size and all the other things as well. Oh, look at that. Actually, I got to the end. I think I was meaning to put an extra slide at the end saying thank you, but I think I forgot. There was meant to be another slide at the end,

and it looks like I've got exactly my 50 minutes. Thank you very much. I missed my question and answer slide. I hope I didn't bore you too much. If you have any questions, go stick your hand in the air now. There will be an E17 release. We promised to release EFL, and we did.

We released EFL 1.0 last year in January. We released 1.1 only like about two months ago, and we even did a 1.0.1 in the mean. So we will do it, but we will not tell you when. It's meant to be magic. It's like a present. If everyone tells you when, it's going to happen. It's not a surprise. So it will happen.

Just trust us. But in the meantime, we do what we call rolling releases. In a rolling release, you do SVN, checkout, blah, presto. And every new release is just SVN update. Actually, but in all seriousness, it's something that most people don't understand about EFL development. Our SVN tends to be more stable

than a lot of open source releases, like release projects. So a lot of projects release tarballs. Our daily SVN checkouts and checkout anytime tend to be about the same level of stability. Yes, we do actually add bugs every now and again. It does happen. But they do actually get fixed fairly quickly

because all of us actually eat our own dog food. We live off SVN. We SVN checkout, rebuild, and we use that window manager. We use those libraries every single day. So if there's a bug that we suffer from, we fix it because it's bothering us. So our SVN tends to be very, very stable compared to a lot of people's trunk or head projects.

So anyway, it'll happen when it happens. We're working on it. Oh, yeah. Yes.

OK, question was about, should I elaborate on Samsung working on EFL and Tizen just to give the world an open phone? In what way? No, is it? OK, we're doing it because?

No, we're not doing it because Android is evil and closed. It's because we don't have many options in this world right now for an OS that is open. There's not very much. Android is partly open. It's open at Google's discretion. That's the reality of it.

They have done that as of Android 3. So Tizen is an opportunity to actually have a much more open platform. And reality is, choice is good. It is good for you, the consumer. It is good for the OEM. It is good for the manufacturer. If there is only one operating system and one software stack,

guess who controls the world and who tells you what to do? The people who run that. So having choice is good. It's good for everybody, no matter what. So yeah. It's good for us. It's good for you. Oh, here. So he was here first. Yes. Yeah. OK.

You can expect a Tizen device when it is publicly announced. No, I will never, ever tell you a product release date. I will tell you many things that are pertinent, and are technical, and are useful. You will never get a product release date out of me

until it's already been splashed out in the internet in public anyway. So yeah. All right. Well, I think we have about two minutes. Quick. No, they don't. The Elevate is very, very specifically written to make it look like JavaScript,

like JSON and JavaScript in a declarative setup. It's very, very specifically set up that way. The Python bindings use Cython. So it's a very, very, very different set of instructions. No, we don't have anything general. That is actually something someone has suggested, that we tag our APIs and everything else so we can auto-generate much more easily.

OK, all right. Quick. Yes, Embryo, the question is that he read on the Wiki page that Embryo is based on small. Yes, Embryo is based on small, which is actually

what it was called before it was called Pawn. And small is actually a derivative of what was originally a C interpreter. And it actually would interpret C. And yeah. Because it was really, really small. Actually, really, what I wanted is I want something that's small, didn't use much, was small in code, was small in memory footprint, and was completely

sandboxed out of the box. Small had zero access to anything at all in the system. It couldn't malloc memory. It couldn't load a file. It could do nothing unless you exposed that to it. So therefore, for security reasons, it means a theme can't do anything unless you expose that to the script.

So it's basically as secure as your bindings are, so to speak. I have spent like zero effort. It was already fast. As it came, it was already fast. So Embryo is just a fork of that where the original small code was not 64-bit clean.

It barely worked on Linux. It was basically pretty much a Windows-centric project. Anyway, thank you very much. Sorry.