 So why is this very scary title? Actually, I wanted to advertise my latest development, but unfortunately I wasn't allowed to do that here. So I had to change slightly. This doesn't really fit. That should be a problem. So instead I will talk about what, in my opinion, is wrong with current paper graphics that it does. First of all, Inkscape. So there are a lot of Inkscape developers here. Sorry for that, but it's just not the way I want it to work. It's very subjective. And I also want to give some hints on how I think we can improve that. And maybe in the end we see that we better start off from scratch. Because Inkscape works the way it works, and that's fine for many people, but maybe some other people want to do it differently. So maybe that's good to have an alternative. So let's look at how Inkscape works. So first of all, this is the perspective of an not very expert Inkscape user. So I use it occasionally, but I'm sure there are better ways. But I think this kind of says how the average user uses it. So for example you want to make a pattern of shapes, like shown here. So you draw the shape, you edit the shape, you add some color, then you duplicate it, and then you select all your shapes, and you arrange it using the arranging tool, as you see here. And this kind of works. But it has some disadvantages. First of all, what happens if you, for example, want to replace the original shape? So if you want to replace this fancy rectangle with same ellipse, you have to start over again from beginning. You have to draw the shape, the ellipse, you have to edit its color, you have to duplicate it, you have to select all the duplicates, and you have to arrange it. Or if you want to change the arrangement, so if you just want to change the spacing, as shown here, you have to select all the shapes and arrange it again. So everything you did before was lost. Or it's lost. Another disadvantage is that many objects clutter the object tree. So I know that the object tree isn't very often used in the Inkscape world, because it doesn't really work well, I have the impression. But if you are used to work with an object tree, that's really a major drawback, because if you have four clones, then it isn't really that much of a problem. But if you have hundreds or thousands of clones, then you can imagine this doesn't really scale. One good thing I really like about it is that you cannot just copy-paste items, but you can actually clone them. So if you, for example, as I did here, draw the points of a shape, then all the clones are also affected. But unfortunately, this doesn't work if you exchange the whole shape. So what can we do better? I propose that we don't use a cloning tool, or a duplicate, or a range and pattern tool, as we have in Inkscape, but instead an object, a cloner object. And how it works is that you can interact with it in a very non-linear fashion. So you draw the shape, you edit the shape and color as before, but then you don't duplicate it, but you instead create a cloner object and put this shape you just have drawn into this cloner object. And the cloner takes the full responsibility of all the clones. So no matter how many clones you have, you just have two objects. And later on, so you edit your scene and you go on, and later on you can simply go back to your cloner object and manipulate whatever properties you want, for example the spacing, and it gets updated. So the actual semantics that you not have on the duplicates, which are by coincidence arranged in some certain pattern, is not lost, but it's inherently stored in the cloner object. And this is how it could look in practice. So as you see here, you only have a cloner object, and this is a rectangle. And the way this is implemented is with a child parent, a relationship, you anyway have the object tree. So everything which is a child of the cloner becomes cloned. Then you have these properties, for example, where you can set the count four times three, you could, for example, also clone them in a linear fashion just like you can do with the arranging pattern tool in Inkscape. I think in a nutshell, this paradigm can be called object oriented. So everything is an object rather than you have many tools like you currently have in Inkscape. And all the negative things I just mentioned now turn into positive things, because you can easily replace and modify the template object, you can just drag it out of the object tree and drag another object in, an ellipse, much more complicated object, a group of objects, whatsoever. You can edit the arrangement properties anytime. So even after saving, storing and loading the scene again, you can easily manipulate that. And you only have to handle two objects rather than n copies. And I propose not only to have one single generator object but a whole palette of generator objects. We have just seen the cloner object, but for example, there's also mirror object. I'm sure you can all imagine what this mirror object does. Many of the real world shapes are actually symmetric in some session. And also an instance, which is the cloner from Inkscape, basically. So you have not copy pasted, but if you change it, the clone also changes. One very important point here is that you not only can nest these generators, but you can also, you are encouraged to do so. And this allows you to generate very complicated shapes with very few objects, which are very handable, very maintainable, and you always have these nice overview of the object tree. So you directly see with one glimpse that the mirror is a child of the cloner and is actually made up by a path. So for example, for this nice drawing here, which took me about two minutes to do, we only need three points. And everything is editable and reachable within a second. So this idea is not new. In programming, we have these paradigms. We have functions, we have loops, we have recursion, and we have variables and a lot of other things, which we can use to structure our code and to reuse our code. And we have a plethora of paradigms. Most importantly, we have object orientation, which is also implemented here. And we have procedural programming, but we also have functional programming. We have so many paradigms, I don't want to list them all. And much more important, we have positive and negative principles. So I only listed the most important positive principles or patterns. This is, don't repeat yourself, try. So we don't want to copy-paste code, because if we want to change or want to fix bugs in one of these code blocks, then we also have to do the same thing in another block. So rather, we put it into a function and just call the function at two different points. And the case principle, keep it simple, stupid. Simple things are better than more complicated things. But we also have anti-patterns like spaghetti code and copy-paste coding, which we try to avoid, and which currently I have the impression that for designers and for people who use Inkscape, again, this doesn't really count. So copy-paste is, yeah, do it. There's not really an alternative to that and the alternatives are not encouraged enough. People use it and then in the end they get angry because they have a scene which is unmaintainable. This is also true for Lapeche and TIPS. You can also have macros and variables. So I really like these tools, but unfortunately you don't have immediate visual feedback, so this is also difficult for many people to use, including me. So yeah, I use it for some things, but for others it's just too much overhead. And in 3D modeling and animation, this is really common. So I don't know any 3D program where you don't do things like that. So is it Blender? It's quite well hidden in Blender, but in Cinema 4D, for example, it's very obvious and this is actually also where the motivation to start this project came from. I just want to mention Houdini, it's not open source unfortunately, but it's a completely procedural. So you see in 3D modeling and in 3D animation there are many, many of these paradigms and many ways to interact with it, but unfortunately it's not implemented in Inkscape, but it's also not implemented in Illustrator, it's not implemented in CoralTor as far as I know. So yeah, why is there no 2D? What you see is what you get in it, which is object-oriented, which is somehow structured or which is dry, don't repeat yourself. I have a few ideas. Maybe it's too complicated for artists, so they are used to do that and yeah, it works. So why should we do something else? And I think for many use cases this is true. As object-oriented programming is not the way to go for every programming task, there's why not use C for very simple or maybe even for more complicated things like dark table. So this works. And people who are used to it and who like this, yeah, they can continue to do that. But it works for 3D. So why do 3D artists can do this or want to do this but 2D artists don't want to do that? And I think this is because 3D is inherently more complicated so yeah, there's more that they want. How to express that? So for them it's not such a big step to get into more abstraction because they do it anyways. And many programmers I know they don't want to deal with these problems, they use what you see as what you mean instead, so they use large-ish antics and not perfect or work from their figures directly in Python and not plot-lib. Of course, they also don't suffer from these problems. So who is left who could use some of these paradigms? First of all, it's me. Because I want to do this, I'm really bothered with how things work currently. I don't want to work that way. I don't like it. But also those who like abstraction and are somehow accustomed to 3D or programming and who want to have immediate visual feedback. So they cannot use ticks because they have to compile their document every time they do change. And it's also for those people who want to sustain who don't want to sustain application and unstructured scenes and documents. And one thing Alex pointed out, I'm not sure if he's here, he promised to be here. Ah, he's there, great. This is great for animation. And this is something I will talk later about very briefly, but I think he's right. So this is, if you do animation, or if you don't do animation, if you just do a still-see, then it kind of works. What you have is what you see and it's pointed to PNG. No one cares about the structure anymore. Everything is a pixel. But if you have animations or interactions, then the relationships and the structure of the objects becomes very important because if you do an animation and the arm suddenly is another place as the body, then things become creepy. Okay, so let me talk briefly about my development I'm sorry, Ale. I promise not to do this, but I think I have a few more minutes. Six minutes. So I started this about six months ago. So the concept is already about four years old. So since four years, this topic is really bothering me. But this implementation is only six months old. I estimated about 1,000 hours of work and 800 commits and 40,000 lines of code. That gives you an impression of the size of the project and what does it do? It implements basically all the things I just mentioned. It is object-oriented, it is structured, it is non-destructive and you can interact with it in a non-linear fashion. And it also implements the first principle I tried to stick to as user-printliness. So it tries to give very low entrance burdens so you can just start and do nice things with it. And if I want to summarize it within just one sentence I would say you can, well, it's entirely 2D so you cannot do any 3D things with it but it tries to resemble the 3D workflow. So if you are accustomed to a 3D modeling suite like Blender or Cinema 4D or Maya or 3DS Max, this might really, you might really like this. One other principle is, so we stick to these many principles and paradigms but we don't want to sacrifice usability. Five minutes? We don't want to sacrifice usability. So we don't force people to do this but we encourage people to do this. So if you want, if you have this cloner that plants this tip around the shape you can simply press C or convert and you have these one, two, three, four, five, six... Yeah, six tips and you can track them around manually. Of course you shouldn't do this because then you lose all the nice properties but you could if you wanted. Another principle is transparency. I don't mean alpha channel. I mean that the program works in the way the user expects it and the user always sees what happens. One big reason or one big thing which implements this is the object tree. So the object tree always gives you the topological structure and tells you what you're seeing is looking like. Then you have all the standard things of vector graphic programs like rectangles, ellipse lines, procedural pathes, generators, I just talked about including outlines and text. And we have an image object which allows you to include pixel graphics and SVG or PDF graphics as one object so you cannot actually edit it but you can use it. And we have basically curves. We have some tools. I really want to keep the number of tools low because most of the things should be expressed by objects but it's not possible without tools, unfortunately. And one thing I find really interesting is it's scriptable. So you can use all the properties you see here. So for example, the mode, count, path, start and end point and script is using embedded Python. This is also used towards animation. And we have simultaneous editing. So whenever two properties are shared by two objects so for example if you select two ellipses both ellipses have the radius property then you can edit this radius property for all the ellipses at once. So this is, I think, also a very huge step towards usability. And this is not limited to two objects but you can have any number of objects. And we have flexible GUI with drag-and-drop dockable widgets and we can extend objects using text. You might also notice from other programs. So for example here we have a path and each of these tips have a path tag. So it is constrained to that path and you can just say I want it at 50% or 100% or whatever. And we have exhaustive undo redo. We have customized key bindings. We have internationalization. We can load and save to JSON. This is more or less arbitrary. We could also use some XML or binary thing but I found for debugging JSON is great. And we can export the pixel SVG and soonish to PDF. For the future I want to implement more generators, shapes and some more tools, not many. As I said, one big point is animation. So for motion graphics I think this will be the killer application. Also I want to add some modifiers. For example to add some random to the cloner or to bent or general paths and edges. I would like to improve the styles. I haven't talked about this unfortunately now but styling system is also very interesting. If you know CSS you will be very familiar with it but it's much less text like. It's much more intuitive and with drag and drop properties. I also want to do some small things and procedural world, add systems and fractals and of course some performance and work optimizations. So I think we got one minute left. I would like to do a live demo but I think it's not enough time so if you want to see a live demo please speak to me outside. I think after this talk there will be a break. So this is the perfect time and now just anyone have questions I would like to thank you for your mechanics.