 I'm not sure that's a well-known project yet. The goals of the project, why we do all this, and how we start. The design, basically, comes in the details. I'll take two examples of the view we have of how the settings manager works. And I'll talk about the future as possible. What is a XSE? XSE is it yet another window manager that is already, probably, more dependent window managers available than it is today? So, is that yet another one? Yes, yes and no. Yes, there is a window manager in XSE, but XSE is just not just a window manager. There's a lot more than a window manager. Is that the new stuff? Well, maybe yes. But we are not going to go after no more KDE, it's not available. But it's a desktop too. Is that the development platform? Yes and no. It's not as rich as KDE or no more development platform, but we do provide libraries, and we do have APIs, not like that, that help making applications more accessible or independently. The setup tools, we definitely do provide tools. We do provide several applications into the basic task of a desktop. But we do not provide a mail or, I would say a text editor, but not for anymore. Maybe we do not provide all the great applications that we already find. We do not provide Office tool or stuff like that because, I mean, you know, in KDE, we really provide great tools for that, and we prefer to insist on the entire probability of tools rather than writing yet another set of tools that we do not necessarily use. How did all this start? Pretty simply, actually. Back in 1996, I was using RedX, and I was using FDWM. This had FDWM being the latest Windows monitor and probably the greatest at that time. I was really missing something to configure it easily because FDWM is very, very powerful. It uses configuration files, and it was not that easy for me to configure it. So I just started playing with Xforms, which was some kind of a close-nose toolkit, which was free for use if you are not paying commercial software, which was my case because what I was doing was all free. So we could use it for free, but we could not have access to the source code for a big problem. But when I started, I did not focus much on that problem. I just wanted to play with that. Just for my own use, I really did not start exactly with a great vision of what desktop can be. It's just a need I have for my own use. A bit later, I just took mostly FDWM2 and modified it for my own needs and built it with XFZ, which became XFZ2, which was basically the same as FDWM and XFZ, it was adding something more stuff for configuring FDWM2 directly from the XFZ setting panel. That's why I had to, I had to, I just took FDWM2 and modified it to achieve a better integration with this panel. But still, XFZ was closed source. It was not freely available and it was seen more and more as a problem by the users and some distribution could have included XFZ, but we would not do it because XFZ was not free at all. So we tried several times to convince the author of XFZ to open the source of his toolkits, but we did not manage to do it on time. So in 1999, we started XFZ from scratch, based on GDK 1.2 at the time and that was a lot of work, took me quite a few months. And after that, once we released XFZ3, all the developers, we got more exposure and more developer jobs and projects like Yasper, that's got China steering that time. GDK 2 came out and there was some pretty big changes in GDK 2 that were attracting our codes and best of all, we wound up not necessarily very happy with XFZ3 not even the way it looks nor the way it was designed internally. So Yasper started working on the version of the panel and quickly for that, I started working on how to do the version from the Winimager. We ended up doing XFZ4 in September 2004 and that was, yes, a lot more exposure for the project. People started talking about it, we started being included in some of the great major distributions by Fedora, I mean Gen2 and all this stuff. It was highly conformant to the 3D asset standards and that was made on GDK 2, so it was pretty much standard as long as it has the GDK as standard. And then we generally use the XFZ4.2, it has numerous improvements, new models, there's a pretty long list of things that are worth doing with the XFZ4.2 Usually it has improved a lot, it supports for anything like a lot of screens and stuff like that from the single part of the Winimager, it's a really interesting release. One of the goals, the goals are for us to keep it lightweight when possible it doesn't mean that we are looking for just a lightweight Winimager because if it were the case, we would not have all of the tools around it we should be making just a simple Winimager. So we wanted lights, but it's not the only goal. We wanted fast and simple, very simple and easy to use by the user. We are not looking for full feature of that stuff, but we wanted to keep it simple. My dinner, we want users to be able to take any module of XFZ and replace it with either KDE on-camping components you can use XFZ with KWIN or LSE, you can just kick it with XFZ, it's all work. And that's because we try to be as much as we can, combining standards knowing that sometimes standards could hurt, because if we are too complex or whatever, we may or may have to combine these standards after the greatest goals. So as I said, it's a module desktop, you have the panel, the taskbar, the desktop the desktop is the area, the program that manages the background area of the whole screen you have the window manager, the settings manager, which are the two tools you have a great session manager and you have a fine manager, that's a problem on itself. So I'll try to tell the first, the settings manager because I think it's a good example of what we want to do and what we mean by simple and simply use desktop. Design and setting manager is a centralized setting manager which is able to broadcast the user preferences to the running applications. It has to be kept very simple and it has to be compatible with the standard settings which is just actually an extension and a simple API. So how does it work? You have them, which are solid login, which looks for plugins in several places load those plugins and those plugins initiates some kind of channels such as main, multi-channel settings. Channels are then listened by applications which choose to listen or not to a channel and be notified of any change of the channels. So how it works? In fact, every channel is totally similar to the design of the settings. The values are stored in an Excel which is on the external source and for the programmer, the manager is able to load directly a channel from an XML file which means that once you have set up your plugin, at start it is able to load the XML file directly and initiate the channel automatically without any special programming. And as I said, the application makes sure to listen or not to the channels and eventually the plugins can have no channel at all. This can be used to run other settings and configurations. One good example of that is the plugin that managed the screen saver. So before I go any further, I'll try to show you what I mean by all this. So here is a very simple and basic plugin spent from Excel. You can here access the settings manager. So this window is managed by the demo I talked about first. Every icon is loaded as a plugin and the manager just looks for the plugins, loads the plugins and the icons are added automatically. So what I was saying for example is this plugin has no channel at all. All it does is run external server preference. That's why I'm here with the tutorial. If you look at the file, so here you see that we used the depth of the channel location. This is how it works. We have every option that is distant. Very simple, takes a little time. This is the name of the plugin and this is the corresponding value within time. The manager just loads that and initiates the channel automatically for that. Very simple design for packages. Because if you write some application that is meant for Excel 8, you just have to write your application, write your plugin and share the votes together. Once the application gets installed, the plugin is placed in the right place and the next time you log in, it's going to be picked up by the settings manager. So it's really, really easy. If you are using a backend tool, if you remove the application, the plugin deals with it and the channel does not get loaded the next time, so it's really, really easy. So as I said, it provides a very simple design, just one single process. You don't have several processes running. One single process manages all your settings. The problem is, you have one single process. So if somebody just puts a broken plugin, it breaks everything because it can crash the manager since it's simply download loaded plugins. And the biggest problem is not designed as a general critical key value database. This is not a company of Jay-con at all. It's really different. It's a one-way broadcast, and there's no way to change the value stored in the FedEx manager other than using the plugin I believe. That could be seen as a problem in some cases, but it's not the design that was chosen the first time. It doesn't mean that we cannot change that, which probably evaluates how we can use deep bass in such an architecture that we need to evaluate what the impact of changing that could have on our design. So that's our try to take another example with the window manager. The window manager is really the central application in the desktop, whatever you do with your desktop, you are going to use the window manager. So it has to be fast, it has to be light, it has to be stable too, and it has to comply with many, many reds and unreds in standards, and it must be with different applications. By standard I mean users are expecting some behaviors on the window manager, and if you don't follow these rules, it's not very good. The window manager, thanks to the ease design, is clearly a big source of raise conditions because you have three different processes trying to access the same thing, you can have the window manager running on a post, the big server running another one, and the final application running on yet another post. All this, thanks to the network, can have a raise condition. And today window managers, people are expecting a lot of graphics and shape windows rather than just to find that. The window manager must be easy to configure and it must provide an easy thing to make up. It's a pretty important thing. You have to provide a lot of things and it has to be easy to do because if you want people to contribute, then things can be really simple. I think it's better to not to put the code in the right time for the window manager. Other than work, in excess of the WM work, 10, 20, mostly of XBM files, just like many of the window manager files, I saw a lot of those now. XBM files are very interesting because it's a simple base-based format. You can open it in your favourites, test editor, and change the volumes. Almost any image application can load and maybe expand files. It supports transparency, so it's very useful for shape windows. And best of all, this is one, I think, a simple cross-execution table, which means that you can design your image, or you can make your icons and stuff like that and change the cards later as long as you associate the name with the card itself. And except the WM4 window is made of text maps, each text map can be reproduced many times just to fill in the frame. And things are made also of PNG files in excess of WM4.2, which can help adding nice effects on top of the XBM file. Big advantage of that is that it's better and forward compatible between XWM4 versions because if you use a theme that is made for a version of WM4.2 that uses PNG files, the PNG files are just ignored by the 4.0 version of XWM4. And if you are using the PNG files, it's not a problem either because they won't work. And these techniques are applying transparent PNG files on top of a no-pack window. It's pretty similar to what you do when you are using the GIMP. So I guess many people who use the GIMP can be familiar with that. So a small picture of how it works you just have this main file which gives a shape on the window and then you have the PNG file that adds some colors and shading on top of it. If you want to speed up the exhibition like that, for example, you can change the colors, you can just change the colors. You see, the colors has changed which means that the expand color table substitution has changed. And you see the light on top of the window that's made on the PNG file just white transparent PNG file to give that light effect on top of the window. So it's really easy in a few minutes once you it's really easy to design it. You need these decorations you need to apply that to the window themselves. So what XFWM Sport does is build the images once do the computation once and then copy that to the window models decorations. And there's a lot of catching in the window manager to help when you change focus in the middle window the actual frame is already rendered and cached. So if you do that on the window back there if you change focus on the other the decorations are already computed and loaded in the X server so it takes absolutely no time to switch between focus and focus decorations and it takes no network either because of just one it's a single X to tell to use all of the other fixed matter caching. But caching needs to be refreshed sometimes and it depends on the way you change the size of the window for example if you resize the horizon toy in your window you see that just the red part of the window needs to be refreshed title and about on the other way if you resize vertically just the size of the window is very recomputed so use such techniques to reduce computation and network loads bitmap files are computed as a set and an image of the whole area is computed and applied to the windows so when you move windows that's really more technique at all because it's fixed this is not the case here because we are using composite expansions what I would say in the general case it also has some mass pictures because it has its own compositing manager which is new with xbox 4.6.8 you're obscuring those nice events like the shadow around the window and the ability to make the window transparent when you do it the other time we can use that we have the window that has its own compositing manager and the code which is basically the same the one that provided my result or xbox 3.0 why why does it make sense to fit it in the window manager because you can have those nice effects if you move the window if you keep it outside on the window manager you cannot tell if the user is just moving the window or not the concept of dragging the window is really something on the window manager if you have a separate process just listening to the exhibits you cannot tell if the window if the user moves the window while the window has moved by itself that's why if you use it in the window manager you can't instantly tell what the user is doing because you know that you can make sure that all your elements are fit and sync with the window manager you just don't use you don't have to have to delay xfc who has joined the project and he is contributing with c++ rocker for dmk and xfc lives which means that you are available to run xfc applications or applications with xfc libraries with c++ which is a really great thing I'm really excited about that as I said the final object can be seen as a color by itself it's complex it's complex from the user final view and it's complex from developer final view we really need another final manager to replace xffm and yasper is already working on the new version of it now which is the which we will be able to use plugins as separate processes because today the panel can load plugins just like for the package manager if a broken plugin can read things badly in the panel leaving the user with the impression that xfc is still a little buggy I'll try to identify some rest too for xfc because I kind of set the goals to have aligned weights but simple and easy to use that stuff today we are seeing more and more things going into GTK it makes the game heavier and sometime maybe the concept of xfc will be irrelevant because if everything goes into the toolkit there would be no way to volume the weight of the toolkit even for like me that stuff another big risk is losing the focus on the goals because as much as we get exposure we get more users and users keep asking for stuff to be added and sometime people do provide some codes and patches and functionalities we must keep in mind what our focus are just to avoid being too relative not quite a fragmentation that's quite related to the previous one because if we it's like people starting to work on xfc on this side do stuff separately where a pretty small project quite a few it would be a problem if we were just starting over in our direction so that was pretty short that's what I feared so that if anybody has any questions about xfc if you want to see more things about xfc you're pretty far I'm sorry that we are using for normal users out of our company because that's for normal users not for developers in government we have some problems because we are not using this configuration manager thing we have some script it's not that important for a user but if I understood well you are using xfc but you don't want to use the settings manager right? oh ok you want to be able to change the configuration file without using the settings manager yes and we don't use xml and you are using xml you don't want to use xml is there any chance that we will have any kind of same way to interact with the computer on normal configuration files oh well I don't see any benefits in a variety of stuff for using a regular configuration files because on the other hand what's wrong with xml I mean the xml we use is really easy to pass and actually we don't even use the xml to pass it we just use our own browser it's really really basic xml very large yeah it's not ingenious it's already ingenious you don't need any other additional additional really really basic basic files I mean it's really I don't see much difference between using that kind of xml files and adding two-value form in a regular configuration file the only difference you may see is if you have the obligation pass directly with the configuration file which is just what the settings manager is about it's just not to avoid that I don't see the point in having the application being able to read its own configuration file it's not a special thing as I said the settings manager is not made for every kind of use it's not a general use so you could find the need for an application in its own configuration file of course but I don't see anyone removing the settings manager to add flat files because you need to pass it sorry I have a simple question about that I don't see much of a problem problem I'm sorry here you go what is xml when will we have an xfc I've done yes I think it's part I'm trying to repeat the question you are using dual head setup and you want to have two platforms on each screen with its own configuration for each screen I think it's part of the design of Yastres next panel it's what I said about a new magic panel with several panels it's one of the goals to be able to arrange several panels on different screens or even maybe one of the same screens the question is xlc is still sponsored I think most of it is thanks to the window manager because window manager uses a lot of caching and a server and actually the decorations are fixed amount being applied directly to the window used for the decorations which means that if you move the window you don't have to carry out the the decoration because it's not that for you so it's all in the server the server has done that all automatically and you don't have to care about that the other stuff is using caching so caching has a pretty funny side effect if you use for example a common one something like that the actual version of xlc is to demo is an RGD channel so it's basically an RGD window where the text may come back and the background may come back the problem I have with that is that the fixed maps are being loaded once for all the windows but the problem is that window doesn't share the same depth on the others because this is an RGD window so the fixed map will load it when we load it in town multiply it with that window because it's not the same depth so once I decided to use it as immediately inside the fixed map I wanted to to transform the fixed maps so they can apply to the depth and this is done at the time the fixed map is completed as usual and just before being applied to the window adjust I used XR to compute a random fixed map so it can be done but we should be a bit slower but it's not really in context which we did anyway this kind of thing is pretty CPU consuming so given the size of the decorations which are really small compared to the the whole window shouldn't make much difference but that's a good question we're using for example we're using the decision to ship with the competing which was pretty new at that time was made quite shortly before the two release we think that that's good because we found that it could be interesting to have such features and to ship them even if it's a little more than default on your regular build if you come after it when you come by it you won't get it but to be safe that's down to about the new features we shall use if it fits if it makes sense given the progress we're trying to have for example if you think that it doesn't make much sense but it's pretty good oh yeah sure yeah be fun for me thank you we shall have that up our room this afternoon so oh yeah I think I can talk about using XFCE internally this is a disk test station based on a processor it makes absolutely no noise at all and it's us to make disk rock memory disk and they use XFCE they have the kernel the next kernel plus XFCE and you build that in seconds and once you build it you can run the applications through the network we shall have that in the top of the room you're all welcome to come and visit us okay thank you