 Let's start another talk after coffee break and the stage is yours. Okay. Can you hear me? Okay. Thank you for coming to this session because in a world full of mobile phones and cloud services, actually, few people are interested in this type of environments. So really, thank you for coming and my name is Hongran Yu and people used to call me because that's my nickname. And now we are going to talk about old fashioned desktop environments that are still useful. Yeah. Okay. And self introduction. Where am I? I'm the creator of the LSD desktop environment. And also I'm one of the main developers of the new LSD, LSD cute desktop environment project. And I'm a Linux user, especially Debian Linux since 2004. And now I'm working for an AI startup company named Epicure in Taiwan. But previously I was a physician working in the hospital for six years, but I love software. So then I changed my data switch for my career and now I'm here. So yeah. Okay. So what's LSD? Some of you might have heard of this desktop environment, but some of you may not so familiar with it. LSD stands for Lightweight X11 Desktop Environment. And it used to be the default desktop environment with Raspberry Pi, but now they use their own desktop. But their own desktop is actually a derivative of LSD, so we can say they still use our desktop. And also it's the default desktop environment of the Lubuntu distribution. And the project was born in 2006, and actually the project is born here in Taiwan. And but few people know that. Yeah. And the design philosophy of this project, why we start such a project in 2006? Because there are already many desktop environments, but why yet another desktop environment? Because we have some different design philosophy. For example, we want the system to have low memory footprint, and it has minimal LSD design, and also it's GTK plus based. But the most different thing is the whole desktop environment is loosely coupled. And they are loose coupling between the different components and its modular. That means most of the component in the desktop environment can be used outside the desktop environment. So that's a big difference with others. But some people may argue that you just put a bunch of independent program together and call your desktop environment if they are not so integrated while it's called the desktop environment. But we want to challenge this kind of view. But actually, it turns out that the project went pretty well previously. And this also shows that Conway's law is somewhat correct. And the software, just the organization of the software system will be reflected by the structure of the organization that developed the software. Yeah. So we are a bunch of loosely coupled volunteers without a centralized organization or any company behind us. Yep. So it looks like this streamlined old-fashioned. But I prefer the term classic. It's not old, it's just classic. Yeah. So simple and fast. And yep, just like Unix. OK, but during the years, it has been there for 12 years. And we currently face many challenges. For example, in a world full of mobile devices, actually, desktop and laptops now have less than half market share. And also, as you know, most of them are actually running Windows. And in the small fraction that runs Linux, only a very, very small fraction are using our desktop environment. And also, the impact is not as huge as before. And also, we suffer from a fragmentation of the technical stack. For example, Katie and Genoa are two very different camps. And also, some are more mobile-friendly. And some are more desktop-centric. And also, we have X11, Wayland, GTK2, GTK3. And GT4 is going to be released in the near future. And we have Qt45, QWidget, and QML, a lot of different toolkits to support. And also, we have a lot of different Linux distribution and this BSD flavor. So you have to make sure you work for all these kind of combination. It's getting more and more difficult. And also, given the technical difficulty and the technical fragmentation and the small market share, it's actually more and more difficult to get new developers to build up a new community. And also, more slow become a problem for us because being lightweight is not as important as before because more slow solve the problem. It's not us to solve the problem. It's more slow. So actually, you can claim that my desktop memory only need 100 megabyte of RAM. But that doesn't matter because your browser needs 2 gigabytes. So this used to be the problem we were solving in the past. But it cannot be the only focus for our project right now. Yeah. It is still very important for a business like MIPS or Raspberry Pi for those kind of stuff. So it is still values. Thank you for mentioning this. That's why we are still alive. Yes. But another unfortunate trend is if you type this into the Google search trend, you will find that GTK Plus VSQt. Actually, less people are interested in GTK Plus nowadays. And the overall trend is just declining. So it's really not so easy to find new developer for this kind of desktop project nowadays. So we really need some changes. Then we tried to address this issue in 2013. We tried to pour some core component to Qt, tried to see how it works. As you might know, LSD was GTK Plus based desktop environment. But we tried to pour some of the core components like the desktop file manager to Qt with the source code we written in C++. And of course, some of the KDE developed helpers during the process, especially wheels difference. We want to thank KDE developer for their help. So the initial experiment showed that actually porting the application to Qt from their GTK source code is possible. It's not easy, but it's possible. And later we found that there was another Qt-based desktop environment that showed the same design principle with us. It's named ReserQt. So we started talk to see if we can collaborate more. And later we found that the fact is simple. We have a desktop. We want to change the Qt, but we don't have enough of engineering resource. And they have a Qt code base, but they lost the momentum to continue the development. So then a historic event happened. And after some more collaboration, we decided to just merge two projects into one. So we formed a new project and then Qt. And this is why I say it's historic because this is rarely seen in the free software community. Every day you see new folks, but you can hardly see successful merges. There were merges, but most of them failed. Yeah, but our merge went out pretty well. So actually, we proved that it's possible for two projects with totally different tech stack merged together. So now in the jungle of desktop environment, we have a unique position. Because we come from the GTK Plus world and they came from the Qt camp. And there are also a lot of different desktop environment. But now we are sitting in the center of this desktop environment jungle and try to make everyone happy. But of course, that's very difficult. But we will try our best to make sure that we can still stay with our original goals but become more flexible. OK, so of course, we don't have LSU-Qt conf like this. But when I visit Paris, I try to find our team member there. So we had a dinner together. You can call that LSD conf. OK, so what about the new LSU-Qt desktop environment? And it still has the class UI. When I say class, it means more Windows-like. The UI that normal people will want to use. But it becomes Qt-based and we still stay with the same design printable as the original LSD and still being lightweight and quick response of the UI. That's very important. That's the core value of this project. It should be very fast, even on slower machine without such powerful hardware. But of course, it's not only for the ancient hardware. I keep mentioning classic desktop environment. It's not for all hardware that will be retired soon. So that's the whole point of this project. And still, we want to make every component modular so they can be used outside LSU-Qt. So even if you don't like the desktop environment, you can still use some of the component freely without problems, such as the file manager and archiver, image viewer, something like that. And we implement a Qt platform plugin that made the Qt program work better with Linux desktop. And that plugin can actually be used outside LSU-Qt. So other Qt program can also use that. And that's one of our core value. And also, we don't force you to use any window manager. You can choose whatever you want. And we actually encourage users to do this. But if you ask me, my personal recommendation will be Openbox. But you can use K-Wing, whatever you want. Most of them will work. So now it looks like this. Pretty similar to LSD. Or you can say pretty similar to Windows. Yep. But there's one thing that makes our project pretty unique because you can really see a project that uses so many different technologies from totally different cameras. Because as many people know, that the test back in Linux desktop is pretty much in a mess. And if you are supporting KDE and you are supporting GNOME, you might end up using totally different development tools. Library, the whole stack will be different. But we try to blend them together well and work without problems. So the main graphical user interface is implemented using Qt 5. And for some core system services, we are using KDE Taiwan libraries, like K-Windows system, to interact with the window manager. And we use KScreen to better handle your screen resolution adjustment, something like that. Because it's really hard to do with row XCB. Or if you want to support Wayland, you will become very difficult. So we try to reuse other people's work. And in some places, we use KDE Solid from work for the hardware discovery. And about the file system abstraction, the virtual file system, how to enable application from using accessing remote file system, we try to use GNOME file system. So we use GIO, GNOME GIO, Glib GIO, and GVFS. It's kind of unfortunate that this project has the prefix K or G. But actually, they are desktop independent libraries. But when people say, gee, they will say, no, you are using GNOME libraries. And no, you are pulling the KDE stack in your desktop. But no, they are just normal libraries, simple and independent. So we mix them together. And for the window manager part, instead of developing our own window manager, we actually encourage our user to just use their own favorite because there are already too many window managers. And but the default we will recommend is OpenBox or K-Win. They work the best, but you can choose whatever you want. And we have a config option for you to change the window manager easily. And we have a core library named Qtxtg. It's a free desktop spec implementation done by our project. And this library is actually used by some of other similar projects. So we use others work. And our work is used by others. And I think this is what free software should be like. And it's not like you are GNOME, I am KDE. You do yours, I do mine. We do ours, but things should not be like that. So we try to mix the good parts from different camps. And actually, we reuse some code from different projects. Of course, the file manager is ported from the GTK version of PC-MEM-FM-Qt. It's a file manager. Of course, FM means file manager, and PC-MEM is here. So it's actually pretty good to start your own project because you can name the software after your name, just like Debian, Linus. Yeah, so it's PC-MEM-FM. And it's ported from the GTK version. And also, recently, we have our own file archiver to handle a compressed file. And you may be surprised that it's implemented using Qt. But actually, it's ported from GNOME file roller, a totally different GTK program. But we show that it's possible. You can actually reuse the source code, the code, the library, everything from different projects. They are not so different. Only the UI and user experience should be different. But the underlying technology should be shared. That's our core value. And also, we provide the configuration tool for an open box and even a post-audio mixer. It's also ported from its original GTK version. And also, we reuse some code from KDE as well. The terminal emulator actually used some code from KDE console. And our config tool used some UI classes developed by KDE. And we mixed them together. And they worked pretty well without problems. Actually, there were some problems. There are still some caveats that need to be handled with care. For example, you can integrate with glib main loop inside Qt programs. And that is officially supported by Qt. But it's buggy. But most of the time, it worked pretty well. But if you are trying to emitting Qt signals within the g-object signal handler, that will not work. And it's a known bug for quite a long time without any fixes. And if you are doing multi-thread programming and do asynchronous IO with both libraries, and they have slightly different threading models. So if you are doing multi-thread asynchronous IO, which is the case of file manager, you will be in trouble. So this need to be handled with care. Otherwise, you will have some weird bugs. And also, in Qt, there is an environment variable. And then Qt, no glib. You know what it means. You can turn off glib integration. And if your program depends on glib and the user specifies this environment variable, your application will be broken in some ways. And we actually have some bug report related to this. Yeah, so there are still some caveats. And also, this one is very interesting. When you are mixing the C libraries and C plus library, you will find that in some C libraries, they will name their variable or function delete. But this is a keyword in C plus plus. So this code cannot be compiled together. And this really happened. It happened in the source code of FileRoller. So when I'm trying to pull that piece of code, it failed to compile until I see that, oh, the function name is delete. And I renamed that and it worked beautifully. And also, in the source code of glib and GIL, there are some functions named like variable named signal. But signal is a Qt keyword. So if you are trying to include this header file in your Qt program, you will have problems. So you need to disable the Qt macro with some compiler definition. Then this will fix the problem. And the other problem is, although Qt enabled faster development for us because the library is pretty easy to use, troubleshooting become more difficult. Because it's the form, many different platform and source code of Qt is pretty complicated. And when migrating from Qt 5, Qt 5.9, Qt 5.9, 5.11, we encounter some regression bugs frequently. And in most of the time, we will receive the bug report from our users, things like DND, drag and drop doesn't work, or screen resolution went wrong, something like that. And we will take a look and find out it's not our bug. Then we try to read Qt source code and help the upstream developer to fix them. We do this and cooperate with KDE developers and the Qt developers to get this issue fixed. Okay, and another pretty big issue is, it's really very, very difficult to have a consistent look and feel for your desktop environment because there are too many different UI tools, too many different configurations. You will have GTK2, GTK3, Q4, Q5, and some pure X11 programs and they will use maybe some use XFT settings and you have to also support S-Cursor, a lot of things, otherwise they just look different. And even if you try to support all of these, GNOME programs do look different. They are using client-side decoration and you have no option to turn it off. So it's pretty hard. And we try our best to support most of the things that are common, like font setting is actually not desktop independent. Not desktop dependent, it should be shared among different applications. So in our configuration tool, we try to accommodate this incompatibility and try to update a setting for different toolkit properties so they can look more or less unified. It's not really possible to make them has a similar look and feel, but we can try our best. At least don't make them look like aliens. Yeah, but that's not an easy task. And also in Qt, things become more difficult because now Qt file rely on some Qt platform plugin and each desktop need to develop their own plugins to support some better desktop integration. And some of the features are not provided by Qt by default. So we try to cultivate our own plugin and to support a better file dialogue or better theming, things like that. Yeah, but in GNOME GTK handles most of this, but in Qt you have to handle this yourselves. Okay, so what about the final result? The UI looks mostly similar with the original LSD, but people will say, no, no, don't use Qt, Qt is bloated. Why you use Qt? But actually it's not that bloated. Okay, it's somewhat bloated, but it's not that bloated. You can see that the end result, we did this experiment on Debian. And Debian Stretch, the current stable version and after code boot, okay, the experiment is done in virtual box because nowadays it's really hard to find such a limited hardware. But I set it to two CPU cores and give it 500 megabytes RAM and the screen resolution is set to this. And then I do code boot and then open a terminal emulator and the default file manager provided by the desktop. Because if you don't do this, you're only testing how much RAM will be needed by rendering the wallpaper. So you need to open some application and I just opened the default file manager for every desktop environment. But because open box window manager does not bring its own file manager. So in the experiment, I did not open any app in open box. So you can see that after code boot, if you're only looking with a bare bone window manager open box, your system will, the whole system will take 71 megabytes of RAM. And if you add on LSD, you will take 100. And for LSD, okay, I admit that it takes more memory, but it's not that much compared to the current standard. You can see other, actually the memory usage of the current else Qt is very similar to that of SFCE. So you can know that Qt is not really that bloated. And the whole desktop environment still used half of the memory usage of KDE Plasma. But of course KDE is much more feature rich. So it's just trade-off. It's not, any one of this is superior or inferior. It's just trade-off, different design philosophy. Yeah. So after all of the migration to Qt and adding new features, porting all of the code to C++, actually the resource usage is very similar, at least on the same scale as the original. But after all this, we got the same UI or no, similar UI with more memory usage and what was the benefit of doing this? Yeah, I will talk about what's the benefit later. But also finally, Lubuntu is going to switch from the GTK plus LCE to the new LSTQt in the upcoming release. Yeah. So, and sorry, I skipped this previously. Oops. Yeah, actually by doing this, now we have a much more active community because as I mentioned previously, it's now really hard to find someone who want to write C code with GTK plus and especially it's already hard to find someone interested in desktop project. It's even harder if you want to find someone who is interested in desktop, but the guy is not interested in KDE or GNOME or others. And the guy is interested in our desktop environment and then the guy's willing to writing C code with GTK plus, the probability is pretty low. So it's really hard to find new developer, but with all the new changes, new toolkit, C++, and all of the reusing technology from using project, now we have a quite active community and the core development team has about more than 15 developers and doing the development actively. And also our community become more active because of this. So I think that's the, and we only increase the memory usage by 50 megabytes. I think that's pretty cheap. So after all of this hard work, I think it's quite worthy because now we have a much more healthy community and development can still continue. It's much more active nowadays. And also our work can be reused by other Qt projects. Yep, so what about the future? The top one problem is the way to support because, but when can we have good way to support is still an open question because it's like chasing a moving target. Wayland is changing rapidly and some of the original free desktop specs are not yet designed for Wayland. So the old migration will take some time, but because we are reusing the K-Windows system library from KDE, I think it will make things much easier because we don't have to do all this low level stuff ourselves and we can reuse what has been done by other projects. So that's one of the reason we introduce library from other project and not do it on our own. It's pretty important to not waste the deep development resource to rebuild the same pool every time. Yeah, but, and also we are trying to improve the user experience because if you have very low memory footprint but the user interface is pretty bad, it doesn't make sense. Otherwise you can use a terminal emulator. It has the lowest memory footprint. Yeah, but to make a desktop environment it should have better user experience and this is what we did not do pretty well at the moment and we are trying to improve that. So any feedback on this one is really appreciated because we are not driven by any company and we don't have a foundation, something like that. So we don't have our own designers. We're just a bunch of volunteers. So it's more difficult to get the same level of design like some commercial solutions. But actually the code base itself is good but the UI just not look as polished. So we should improve this part. But we want to keep this experience classic. That means we are not going to hide every menu or we are not going to remove button you used to click. Yeah, we will keep the classic experience. That's the whole point of the project. And not make everything look like mobile phone. Yeah, and then we will still make sure the project is still, the desktop is still lightweight and fast and when you click anything it should respond quickly and that's pretty important. And but being lightweight is still important but it's not the only focus nowadays thanks to more slow, yeah. But I agree that it's still important for embedded system and also I think it's a very good desktop for devices like Raspberry Pi. But I rarely see people using that on Pi but actually it works pretty well. So if you have a Raspberry Pi, give it a try please. Yep, and we are going to do more application and make it more polished. So that's the current plan. But there's one thing I need to clarify here is the original LSD is not dead. It's still being developed and actively maintained thanks to our team member. Yeah, because the original plan was a full migration to a Qt and let LSD replace the original LSD desktop. But we realized that many users still prefer the original one and some of the developers are still willing to work on the old GTK code base. So now we keep two different product lines. So while the new feature are adding to LSD, LSD is still being actively developed. Just the development is not as fast as before but it's still being developed and maintained and now it's GTK3 ready. So if you are still using LSD, don't worry about that, you can continue using that. It will not be dead pretty soon. It will be, I think unless GTK itself is dead, LSD will be there. Yeah, so thank you for listening but I think we still have some time. So let's take a look at some, some, maybe show you some of the applications. Yep, this is the file manager and of course his name, yeah. Oh, okay, okay, maybe we can have some Q&A right now. Do we have some questions? Yeah, please. Okay, I have two comments and the first is just for your reference. The first one is that another successful example of project merging in free software is that it's SchoolLinux and the Debian EDU, okay, they merge together because they are doing the same thing. So because I have studied that for some time, okay. And the second is that actually, lightweight desktop environment is, they are still, the requirement is always there. And what we are doing now, maybe you know that is that to make old computers alive. And for example, just today, there will be a group of students that will be known to be information volunteers and the computers there are very old, 32-bit and actually currently only LSD works on such machines. So we are still, I made a version of the customized, customer error bound for them. But currently I have a problem is about the, you talk about the XDG implementation. And what confused me is about the XDG manual, XDG manual. Actually for KDE, for GNOME, the XDG manual implementations are actually, they, I have to say they don't follow the spec. And the XDE follows the specs, but I have a problem is that the underline in the manual is gone. You know, our physical project, we use underline to separate the tag and the application. But in the, I tried the newest error bound to 18.4, the problem is still there, it's just the underline is gone. Okay, I'm not sure if you have re-implemented. You mean the underline in the manual? In the manual, yeah. Manual items? Yeah, yeah, yeah, yeah. If the name contains the underline, it's, it will be gone. That's probably related to the implementation of like GTX. Yes, because only XDE has this problem. Oh, okay. Okay, KDE, GNOME, and XFCE, they all, the underline are okay, only XDE has this problem. Okay, I think it's not related to the XDG spec because in XDE we are actually using the project provided by GNOME. Yeah, but I have to say that GNOME does not follow the spec, very, very, very easy. But I know that you must reuse some of the component of that, but at least this is so far what I have tried. But I haven't tried LXQt. Okay, we can check that, but I would encourage you to try LXQt. Yeah, yeah, because so far, I'm also waiting for the L1 to 18.10. Yeah, because I need to make the live ISO, you know. So if I need to remove the XDE and push the LXQt again, it's not so easy. So just the two comments for you. Okay, thank you. Hi, I have a comment and also open question for everybody. So thank you, Pistons years effort to make this lightweight environment for us. But I want to point out one thing, the most role is not the limitation, it's challenging also the niche. For example, when I start to use the PC, I work on with Stackware using, let's say, 44, 45 floor piece. People, all guys probably remember that time. And still in, it's how many, 20 years later, we still have this problem because you have a new in-base system, let's say, Raspberry Pi or something like, say, Apple Watch. Still, we still have a low-end hardware. We won't have some kind of GUI on top of this. The question is now, we want to reproduce the experience on desktop into the new things. Is how can we create a new ecosystem which I think is very important for open source. How can we bring this kind of computational environment to some people, especially young people which cannot afford to have a PC for their own in the past to a new generation? In my case, I'm kind of an apology. So I'm the few people who play with the PC and the BitNet, but not that everybody can discuss it, but not for the young people and for the rural people. How can we bring this kind of thing to them? It's a new challenge. I don't have an answer, but I'm thinking this, I want to indicate this way to show this kind of thing. I still have an Apple PowerPC G4 which I cannot run anything but the Rubang 2. And so I'm thinking, I mean, if I can donate this computer to some young kid who don't afford to buy a new computer, I'd like to. And I think this is something we as the community of open source can think about. How can we give this kind of abandoned things from the old technology so that everybody, not just for some kind of engineer or some kind of rich guys in the city, we can also, we can all have this computing power to use these kind of work things. Thank you. Thank you. Yeah, we will keep trying to try our best to make sure it's still work for all the hardware. I just mentioned that it's not the only focus to stay lightweight. You still have to care the user experience. Hello, my name is Andreas Tiller. I just want to make a little remark that you joined two free software project. I really applaud this because it's so rare and you cannot mention it frequently enough that that's a good move because we have so many desktop environment but in principle we only need one good one. Thank you for this. Thank you. Hi, my name is Catherine Sutter. I want to thank you very much for your work. I've been using LXD for many years. Oh really, thank you. Yeah, thank you, nice to meet you. Right now I've been working on... I have a DD friend who is very angry at me for not making bug reports for LXD and I promise I will try to do better as a user. In terms of features, there are some practical things that I think might make it easier to use on a very tiny screen. I have used it in a Cherute on Nokia N900 which is a small Nokia phone that I think had Mego or something and they used Matchbox derivative. And I thought I made LXDE work on that but then I would have to do very frustrating things like find an alt key and click, something equivalent to an alt key and right click to move the window so I could find the button to click. So obviously those things would be tricky but I think they would make LXDE portable to many small arm boards that are coming out. Another one that I made it work on was the pocket chip. Their effort, they did a modified Debian install on that as well and I got on the user forums and called myself Debian user on the pocket chip forums. And again, Matchbox looked like it worked a little better because they did full screen but I don't know if I can help with these things in the future, but it'd be nice. Thank you very much. Actually it's a big headache for us because we actually encourage people to try different window manager but although they all claim to support NetWM protocol, most of them work totally different. When you plug in another window manager, you will get many problems here and there but you don't know the root cause. It should work but most of the time you just get some problems here and there but you don't know why. So I think that's one of the reasons why the project keep doing their own window manager. But I think it's better to let the user choose whatever they want. Yeah, but not all of the combination work. Yeah, so yeah, agree, agree. When you go to a new desktop and right now I have installed Cinnamon because I felt that it's a good effort, I should try it and I like it overall but it's slow and I have to click five, seven things just to do something I used to be able to do with one, you know. Yeah, if you have some bug report that cannot be handled, you can. Yeah, it's actually better to use the bug tracker but if you, yeah, if you want, yes. Do we have more questions? We still have five minutes of time. Or we can just take a look at. And then let's see demo or something. Actually from the, sorry. Actually, can you tell if this is a Qt program or GQt program, that doesn't really matter. Yeah, this is the final manager and it just looked like the original GQt version and quick responsive, I closed it and yep. Oh, whoops, move to another screen. Yeah, but okay. It's kind of frustrating with my window. Oops, doesn't work, never do that demo. Yeah, but there's one thing I want to show. This is our new file archiver and it's for a graphical user interface for you to handle compressed files and does anybody find that the UI look very familiar? It's ported from GNOME file router to Qt, yeah. And it just used the same way as the GTK version. Of course, we don't have client-side decoration but it's pretty similar and this is the file dialog. You can see that it's actually not a default file dialog provided by Qt, it's much more feature-rich and it looked pretty similar to the GTK file chooser but it's implemented in Qt and backed by our file manager. So we try to do better integration and make sure everything is still fast and responsive. Yep, and yeah, the overall user experience did not change that much by just changing your UI toolkit. Yeah, so if you feel frustrated with the older LSD, maybe you can try the new one. Any more questions? If not, then let's thank speaker and we have coffee break. Okay, thank you.