 I would like to not keep you too long, so I keep it reasonably short. I added a GTK3 VCL plug there last year for support of GTK3, which gives us whale and support and gives us touchscreen support and things like that. That's in addition to a whole pile of other VCL plugs and cell instances. I'll brief over that. Every platform has to implement a cell instance, and a cell instance is your hook to allow you to create all the other things you need to make VCL work. You have to provide an invitation of a cell frame, which is a top-level window, a printer, and then your virtual device, which is your off-screen buffer that you render to and then copy to your final cell frame. Under X cell frame maps to an X11 window and a PIX map for the virtual devices. They all have to implement a whole pile of stuff, so the idea is that basically that you just have to implement this for every platform for every different cell instance, and you've got your stuff like your drawing, line drawing, and your rectangle drawing, or a part of your cell graphics, which is part of this whole process. So give a little picture of what it looked like before the GTK3 one. Your cell instances has one for every platform, so you've got one for windows, you've got one for quarts for Mac OS X, and then under Linux, we can actually dynamically load each particular one, in which case we call it a VCL plug. So you have a generic one, which is just for X11. Next to nobody actually sees the generic one anymore, unless something goes wrong with your system, or you explicitly use it because we default using the GTK2 one in the absence of everything else. There is a KD4 one. There was a KD3 one. The KD3 one is basically removed, but there is a TDE one, which is effectively still the KD3. So that's the way it was before I brought in the GTK3 one. The GTK2 implementation inherits, as in that previous diagram, from the X11 one. So in a lot of cases we didn't write anything specially for GTK2, we just reused the X11 one. What's particularly of note is that we reused the old cut and paste code and reused the old drag and drop code that all comes from the shared X11 base, and the printing is all shared as well. When we did the GTK3 one, while there was some overlap with GTK2, we could reuse a lot of the GTK2 code again, but because the underlying infrastructure has all changed, especially for the case of Wailand, we had to actually re-implement the drag and drop stuff. We had to re-implement the cut and paste stuff, basically using APIs that also existed in GTK2, but we never bothered to use them because we could reuse the X11 implementation. So now we have a full implementation in native GTK of drag and drop and cut and paste. Also then we could no longer use the virtual device support for using, which is, in GTK2 case, was inherited from the X11 and used PIX maps. We had to replace all that as well. What we replaced them from, basically, we re-used the code in the headless backend. The headless backend, or the SVP, the starview portal backend, previously existed as a headless mode that could be used, especially for converting documents. As time has gone on, this has been repurposed to become basically the basis for the Android port and the LibreOffice kit port as well. The tile rendering will render to effectively this headless backend. That is a full VCL plug, but most things were stubbed out in the headless one. There are no true top-level frames. The frames don't get resized and issues like that. What that implements, and what we reuse especially, is that virtual device bitmap that you can render things to off-screen and then move them around. So what we ended up with there for the GTK3 is that we still have the generic X11 one. We inherited from that for the TDE and the KDE4 one. We inherited from that for the GTK2 one. We have this headless one that I briefly described there, and we inherited from that. The GTK3 one is an unholy Frankenstein of reusing the GTK2 code from GTK2, filling in all the blanks with new code, and then bringing in all of this headless rendering code from the headless backend. Then we added a whole pile of stuff to the headless backend to make it render pretty, which has improved both the GTK3 support and the headless support, and the Android and the online case as well. As an aside, and as context for where I'm going next, is that originally for text layout, we would have a whole pile of text layout implementations spread across VCL. So originally there was a simple layout for Linux text. Then there was a ICU one using the ICU libraries, which was for complex text. That's all been replaced under Linux for quite a while now with a half-buzz single one for both simple and complex text. There still exists a layout engine for graphite fonts, one especially generic for all platforms, and then one specific one for graphite fonts under Windows. Outside of that, under Windows for font layout, we have a Uniscribe one for complex text, and we still have a simple one for non-complex text. And back under MacOS X, we have a core text layout. One of the Google Summer Code projects this year, we're hopefully kind of just here someplace, and will be tomorrow, is to unify all that text layout in together under half-buzz for all platforms, and looking forward to seeing that. I don't think we actually have the resources to split our energies over that number of font-shaping libraries. We really should runifying one. Similarly, I don't really think that we have the same ability to spread our efforts over this many number of ECL plugs. I'm maintaining GTK31 because I have to, because it's where we are, and I'm pretty much one of the few people that can spend all my time doing that. I don't really have the time to invest in looking after GTK2 ones or generic ones. Under text rendering, we also had a similar situation. We had multiple text renders. For text layout, we're going the direction of one text layout. For text rendering, under Linux, we've gone the direction of one text renderer. So I don't have the problem with multiple text rendering under different platforms. What we have under graphic rendering, then, is that that SVP, that headless backend, which is used by GTK3, pretty much all of that has now been re-implemented to render its graphics with Cairo. This is the 2D rendering, the simple rendering, the fallback if you don't have OpenGL, like in the previous case. And in our case, with GTK3, we haven't even implemented any of the OpenGL stuff yet, let alone the optimized cases there. So that's the graphic rendering. SVP is rendered with Cairo. And then the generic graphics, the X11 ones, are rendered with X calls, except some cases where you can render with Cairo and then all that OpenGL stuff that was described in the previous case where some of the stuff is rendered with OpenGL, the fallback being X. So what I'd like to do, where I'm thinking of what I'm proposing, is that the top-level X1, the GenVCL plug, that we stop supporting that is something that you can actually explicitly instance it. So either you have GTK3, or you have KDE4, or you have GTK2. If you have raw X11, you just have to install GTK2 at least. So you default to GTK2 in the absence of anything else, and that's as far down what we support. This TDEVCL plug, if we had never implemented KDE3 support, I don't think the TDE support would exist. So I'm suggesting that the TDE stuff is really a dead-end, and that's not going anywhere, and that we should actually just drop the TDE support. A lot of guys are thinking, what is TDE? So that leaves us with the TDE1 gone. We have the X11-based Gen1 that still exists, but you can't instance it, and it stays as the base for the KDE4 and the GTK2 one in that case. So that's pretty much the same picture. Then all that drawing stuff I described in the X111, the direct Xlib drawing stuff, we would take the existing and hopefully okay stuff that we're using under GTK3 and the Android, all that chiro drawing. So we reuse all that chiro drawing for our X drawing case as well. So we remove all of the old X drawing stuff and replace it with the chiro drawing stuff for that ultimate fallback. I'm leaving outside completely the OpenGL stuff there that can continue as it is without any change. This is just your base level bitmap drawing. That gives you a structure like that. You have a shared chiro rendering for the graphics. That simplifies a lot of graphics cases and hopefully gives us pretty much similar graphics drawing for Linux case under all of those supported VCL plugs. I'll draw it the same way. As I described earlier, is that when the GTK2 implementation was done, it just inherited a whole pile of stuff from the X implementation because it didn't need to do anything else. When I went to do the GTK3 one, I had to implement all the cut and paste and drag and drop and all that stuff. So I would suggest that we would try and decouple the GTK2 stuff from the X implementation. All that stuff that implemented for GTK3, that uses APIs that still exist in GTK2, that we would just use those as well. That would mean that the GTK2 implementation and GTK3 implementation of cut and paste and drag and drop would be the new native GTK implementations that would then remove GTK from that hierarchy of X there. There would be some stuff left behind, but in general that's the conceptual model. It would look pretty much like this. So you have your top level drawing, which is just chiro everywhere under Linux. No more X drawing. Then you come down here and you have a GTK base, all the shared GTK stuff. Then they have the GTK2 stuff, the GTK3 stuff. Both of these then are sharing the same drag and drop and the same cut and paste. Your headless stuff is unchanged. Your X11 stuff is unchanged, but it's no longer used by anything except KDE4. KDE4 will inherit from that. I'm not working on KDE4. I'm just saying that that does leave KDE4 as a bit of an outlier there. It's the thing that's using X directly. It's the thing that's inheriting from that X11 base. That's not my concern. I'm just saying that's the way to be left. I'll just leave the KDE thing alone, but any of that X11 stuff that's left over, that's only used by KDE, that just gets moved into KDE directory and it becomes whoever wants to maintain KDE, it becomes KDE's problem in that sense. So it probably is the case that somebody in the KDE world who has an interest in keeping the office working on KDE, would really want to invest some time in that directory and port over all the bits to direct KDE APIs and avoid doing like we're doing in GTK2 at the moment, inheriting from this shared X11 base. So I'm claiming. I'm claiming it as a gain here. I'm claiming the gain is that there's one very, very simple underlying graphics rendering layer for Linux. It is just this currently GTK3 headless case becomes a default case for drawing graphics. And there's a whole bunch of little advantages there where there are optional VCL rendering paths that are tried first before falling back to underlying ones. They'd become always available. So there's a whole lot of code gain for all these. If these can't be done, try some terrible old way of doing it. That can all go. So you have one set of drawing there. The same rendering path for all of those implementations that's less code, less complexity. And that cut and paste and drag and drop that I've implemented for GTK3 would be effectively used on GTK2. And while I know there are some bugs in that, it would, of course, force me to fix those bugs and there'd be the same problems on GTK2 and GTK3. And it could also help finding out that a lot of us developers that are just developing right now in Linux will get the GTK3 experience by default. That's what you're looking at every day. But then when people are installing the install sets from the testers, they are seeing the GTK2 experience the whole time. So we're beginning to divert. So our testers and our users are going down, and our daily users are going down one path and the developers are going down another path. I'm trying to bring this back together again. All right, so that's... I'll summarise at the end what I definitely want to do, what I'm doing. I'm going to just put some other stuff in here to make this sound less scary because this is like stuff that won't happen. But just saying that what could also be done is that for the daily builds and the eventual cases that you could end up deploying the whole thing maybe as a flat pack. All right, and then you don't exactly like that. That means that you can delete all the VCO plugs except the GTK3 one. The GTK3 one is in part of your flat pack. That gives you another solution of that kind of problem for the diverging experience. You can go to whole hog and you can port the whole thing to GTK3 on all platforms and spend your efforts on making GTK3 teaming work better under Mac OS X or Windows. That's another approach. You could do that. You could keep the file pickers. That's like your fundamental experience and the rest of it, you try and get away with teaming. I can summarise then the smaller stuff that it will probably do. Is that what you'd end up doing is that that gin back end, that wouldn't work anymore. Directly. The X drawing would go away and be replaced by the Cairo drawing that's been tested for, suppose a year or so in the other GTK3 and headless back ends. That would move from taking the GTK2 away from that existing excellent implementation of drag and drop and cut and pay especially and other things like that. All the bits that are missing from GTK2 a lot of it can be re-propos from the GTK3 port and then that we definitely drop the TD sport as well and then anything that remains unused after we run our usual process of finding unused code, anything that remains used by a single VCL plug of KDE4 gets moved over into KDE4 and becomes part of that. That's my proposal. I don't know if anybody has any strong views against that but that's the way I'm thinking and in the absence of any major complaints that's probably what I'll do over the next 12 months. Thank you. Any questions?