 In this video, I want to talk about some of the plans going forward that I have for DTOS because right now DTOS, this is DTOS. This is DTOS with the Xmonead Window Manager is kind of my customized Xmonead desktop environment. But why limit ourselves to the Xmonead Window Manager when sometimes I like playing around in Qtile? What if I want Qtile as a Window Manager option in DTOS? Well, that's kind of where I think I'm going to go next. And what if you prefer going a more suckless route? Maybe you want DWM as part of DTOS. And maybe eventually we add other things. Obviously, the awesome Window Manager makes a lot of sense, one of my favorite Window Managers. And of course, we could explore other options down the road as well. Now, as I add more and more features to DTOS as it becomes more complex, I need to do a better job with outlining, note taking, obviously being an Emacs user. I need to spend more time with things like org mode and really making sure that I get done the things that I need to get done to actually accomplish my goals. So I actually created this org document earlier in the week to kind of guide me along with some of the work that I've been working on. So this is the DTOS roadmap. And before discussing anything else, I really wanted to be clear up front. Exactly who is DTOS for? Well, being that it's built around tiling Window Managers and kind of nerdy stuff. It's all about flexibility. It's all about customization, configuration, DTOS, who is it primarily for? I would say it's primarily for the ricer. Ricers are people that love customizing their desktop to fit their workflow, to fit their needs, or sometimes just to try to make their desktop look extremely sexy, look attractive so they can take a really cool screenshot and post it over on the r slash Unix porn subreddit. That's what a ricer is. And I think that is a big focus of what DTOS is going to be about. So I think the reason it's going to really suit the ricer is because DTOS, Window Managers. Window Managers I plan on shipping with DTOS are going to include, of course, Xmone, Qtel, Awesome, just to name three. Those offer almost unlimited customization and configuration options. Anything you want to do with those particular Window Managers, you can do. And of course, each Window Manager that comes installed with DTOS will already be customized or already be configured for you. So if you install DTOS, Xmone, add DTOS, Awesome, DTOS, Qtel, you're actually going to get a customized configuration. It's not just going to be a bare bones configuration like you would typically get with Arch Linux. And of course, I'm going to make some, what I consider, sensible choices with some of the defaults. Also, one of the things I want to do is I want to make sure that color schemes are a really big component of DTOS as far as already, I have 10 color schemes that are available in DTOS as far as with Xmone, add my current Xmone, add desktop environment where you have an option of 10 different color schemes to choose from. I'll have a demon you script that you can choose any of these 10 color schemes. And when you hit enter, you know, it will actually switch Xmone, add Xmobar, Khaki, Trayor, Doom, Emax, the Alacrity terminal level, change the color scheme for all of those in one go. And right now I've got 10 color schemes, but I may add more in the future because I think that's important again for customization just for the rising effect. I think DTOS is going to be attractive for power users because I'm going to include a suite of applications, fast, efficient, powerful programs, obviously Emax is going to be a huge focus that's going to probably be the centerpiece to all of these particular desktop environments, these window managers that I install. But if you're not an Emax user, don't worry, Vim will also be a first class citizen here. I'll probably package up some kind of Neo Vim config that has some sensible choices in it as well. Another big thing for me is I love playing around with different shills in Linux. So we're going to have multiple shills installed. And of course, we're going to have a lot of terminal based applications, a lot of 2E programs. So that really kind of caters to the more power user. Now it's also going to be for developers because one of the things I'm thinking about with choosing these window managers is I want a different window manager written in a different language configured in a different language. So obviously when you're working in Xmonad, you get to learn a little bit with Haskell. You get to program a little bit with Haskell when you play around with Xmonad. In Qtile, you'll get to play with Python. In DWM, you'll get to play with C. And awesome, you'll get to play with Lua. Obviously a lot of what I do with DTOS, especially the D menu scripts, all of that is done in Bash. Bash scripting will be heavily used in DTOS. Also DTOS will encourage participation from users to help in its development and that hopefully will encourage aspiring developers, people that are maybe new to scripting and programming and creating packages, maintaining packages and things like that. Because really I think one of the primary focuses with DTOS I want to focus on will be education. So the other user block that I think will be attracted to DTOS is those wanting to learn Linux. So if you want to learn how to create and maintain a package for DTOS, I'll teach you. So I'll make sure that anybody that wants to learn how to create an arch package, right? I'll show you exactly how to do that. I'll do that on video. Of course, one of the things is having my YouTube channel, I have this video platform where I can put all this information out. But we may also schedule some events, maybe like on a matrix chat or a jitzy chat or something like that, where I'll walk brand new users through creating an arch package. Because ultimately I see the primary focus of DTOS being to educate and to help building that next generation of Linux enthusiasts. Because right now I don't think Linux as a whole, the Linux community as a whole, I don't think we do a good enough job educating that next group that's going to come behind us. And then I created what I thought was a sensible choice of five window managers written in five different languages, again, for the developer theme, for the education theme. I'm thinking initially what I want to focus on are these five window managers as part of DTOS. And this will be optional. You'll have the option to install any or all of these during the DTOS installation. Obviously, Xmonad's already there. I'm working right now on packaging Qtile and DWM. And I will eventually get to awesome. I'm thinking about doing EXWM for again, there's Emax is going to be such a central focal point of DTOS. It makes sense kind of to have Emax as a window manager option as well. And that's what EXWM is. It's essentially an Emax plugin that allows you to log into Emax as a window manager. Now each of these are going to have some challenges as I start packaging them. Obviously, Xmonad and Haskell are challenging strictly for you guys. The user, I've already done a lot of the work on that window being that I've been working on this one here for probably nearly a year now. The next one I'm going to work on is Qtile. Qtile really is a much easier Xmonad. It mimics Xmonad a lot. The difference is it's written in an easier language, which is great because Python is a lot easier to work in, especially if you're a new user. The problem is Qtile is under heavy development. It's got a lot of people working on it and they're pushing out new updates on a pretty regular basis. So breakages could happen. So a config that's working in this version may not work exactly right in the next major release of Qtile, so I'll have to be on top of my game as far as monitoring the new releases for Qtile. DWM doesn't have that problem because it sees really no new releases that often and even if it does, you don't really update DWM through your package manager, right? I would actually go and grab the source code and rebuild it and repatch it and all of that. So breakages shouldn't happen with DWM as long as what you started with was working. Now the problem with DWM is the patching. It requires heavy patching and system trays. If you want a system tray as part of your bar, like I have Trayer here, as part of XMO bar here in Xmonad. System tray options kind of suck with DWM, so I made that note there because I know that's going to be a bit of a problem. With Awesome Window Manager, the only real challenge is it's extremely customizable. It's got the most customizable Window Manager out there and because of that, you do have an overabundance of possible choices with the customization. It could be confusing. Like in some ways, Awesome does a lot and it's rather easy to get into, but then you could be overwhelmed by the amount of power and flexibility that Awesome does give the user. And EXWM has a major challenge in the fact that I would have to create a Emacs config just for EXWM and I would have to have another one for all the other Window Managers because I can't have my Emacs config load EXWM if you're not actually logging into EXWM. So that's going to be a little bit of a tricky situation with that particular Window Manager. So those are the five that I'm thinking about focusing on immediately. Others I may consider in the future. I'm not sold on any of those, but I wouldn't say that it's out of the ram of possibility that I wouldn't eventually include maybe one Floating Window Manager just for people that want a Floating Window Manager, but still want some of my configuration options for other programs. So I'm not against eventually maybe adding OpenBox or even something like ISWM, which is another Floating Window Manager, kind of similar to OpenBox. And of course, there's several other Tiling Window Managers I could eventually configure and add to DTOS, LeftWM and Spectrum. They're Exmonad clones. Both of those are exact clones of Exmonad pretty much, and they're in much easier to use syntax languages. They're not obviously written in Haskell, right? And they're not configured in Haskell. So, but I'm again, I'm not sure because I already have essentially two Exmonad clones, well, Exmonad and Qtile. I mean, do we want to make every single Window Manager just another Exmonad clone because they're all going to essentially do the same thing? I'm not really that sold on either one of them in DTOS, but I may keep it as an option in the future. And then, of course, we've got all of the manual tileers. You guys know I like Dynamic Tiling Window Managers, the manual tileers, BSPWM, I3WM, HerbsLift. I'm not a fan of them because I'm not a fan of them. I wouldn't spend much time in them. I don't want to add Window Managers. I know I'm really never going to use to DTOS because if I'm never really logging in and using them, things could break and go unnoticed for days or even weeks at a time or something like this. So I'm probably not going to package any of these three anytime soon. And I'm definitely not going to package Sway because it's for Wayland. I don't use Wayland because I have to use X for what I do with this video work as far as the YouTube channel and things like that. I have to check out Sway probably in a VM anytime I wanted to check it out. And it's an I3 clone. I don't like I3 that much. It just doesn't make sense for me to even think about Sway. Plus, if we want a Wayland option, the good thing is of these five Window Managers up here, one of them already has some support for Wayland Qtile, already has Wayland support. When you install Qtile, you actually get two options in your login manager. You have Qtile, and then you get Qtile and then in parentheses, Wayland. So if you want to explore Wayland, Qtile will be an option for you. Then I mentioned I wanted to have multiple shells installed. I may not install them all out of the box. I'm kind of debating that. But for me, I have all of these installed on my system. Bash, Fish, ZSH, Newshell, Conch, and then of course in Emacs, you get an extra Emacs Lisp shell called the E-shell that is amazing. So I want to make it easy to have multiple shells available on the system. And I'm going to of course make it very easy for you to change your default user shell. So if you want to switch from Bash to Fish to ZSH or whatever, as your user shell, I'll make that very easy. I'll probably create some kind of GTK application that'll make that process as easy as picking a shell out of a menu and clicking a button and boom, you're done. Now, some other stuff I've been thinking about because I know people that use DTOS have asked me about this. D menu and especially my DM scripts package are a big focal point of DTOS and the DM scripts package that is going to be if I do Super P H4 DM Hub, the DM Hub script actually lists all the other individual DM scripts and there's 26 currently packaged as part of DM scripts. And I have had people tell me that they love the DM scripts, but they would rather use Rofi than D menu. And there actually is a rather easy way to do this. DM scripts is already set up this way. There's a config file that typically goes in your home directory dot config slash DM scripts. You'll find a config file in that directory or if you don't, you'd have to create one. But there's a variable in that config, I believe it. The variable is just D menu all caps and that actually specifies exactly what the D menu command is. For example, I have the D menu command with the flags dash L for vertical lines. I think I have it dash L 20. So you get a preview of 20 lines. If it's longer than 20 lines, of course you'd have to scroll down a little bit, but you can change that D menu variable in the DM scripts config to just whatever Rofi command you want. And magically all the DM scripts will launch with Rofi, so that really is just one line and one config. And it would immediately change from D menu to Rofi for all the DM scripts. And again, I'll probably will automate that. Again, I'll do some kind of GTK application as part of some welcome screen probably or some settings manager. So one of the biggest things I've been working on here in the last few days is I need consistent key bindings across all window managers because one of the things right now is these window managers, some of them I log into on a regular basis. Some of them I don't log in that often. And then I spend so much time customizing each one, but not all at the same time. And I've developed different key bindings for some of these window managers. And sometimes the key bindings are different for doing the same actions. And it's kind of confusing. It's confusing to me sometimes when I log into some of my other window managers, right? So I want all of these window managers to be as consistent as possible with their key bindings. So the key binding to open a terminal is the same in all of them. The key binding to close a program is the same in all of them. The key binding to open D menus, the same. The key binding to open Emacs is the same yada, yada, yada. So three or four nights ago, I spent quite a bit of time actually working on my Qtile config to make it as consistent as possible with my Xmone ad config as far as the key bindings. I've also spent a little bit of time working on DWM to do the same thing. And eventually way down the road, I would like to develop more of a custom suite of applications, more of a proper desktop environment that can be used with any of these window managers. But I want to create eventually a DTOS welcome application, a DTOS settings manager, something I've been thinking about because I think it would be rather easy to eventually do this to create my own login manager, right? So instead of using something like SDDM, which is what DTOS uses now, that's a cute application and I'm doing more with GTK, but I don't want to do something like a GTK login manager like GDM, which is GNOME's display manager because it's complicated as hell. I guess a lot going on with that application. I just want something minimal, simple GTK. So I'm thinking about just creating my own login manager. I don't think that would be as difficult a project as what many people would think. And of course the big part of DTOS is that all of my custom configs, all of the custom applications that I create, we're gonna have of course a DTOS repository of software. I already have that. It's DTOS dash core dash repo. And of course you'll find that over on my GitLab. And then I created this to-do list that I was working on this week. So obviously the very first part of the to-do list here is make a video on the DTOS roadmap. So if I go into this empty pair of brackets here and in DOOM Emacs, if I do space MX for mark that as done. So you can think of space M for mark and then X to mark it. You see it changes the color. So I've already made the video on the new DTOS roadmap. That's what I'm doing right now. The other major change that actually required many hours of work this week was this item here. Instead of using one big repo for all of your configs, DTOS dash config, split them up for each individual program. So right now I have package builds to build all of the binary packages for DTOS. And most of those individual package builds will pause from one of my GitLab repos, DTOS dash configs. And this hosts all of my configs. Of course the problem is that this is gonna be a rather large repo if I stuff every single config file for every program that DTOS is gonna use in this one repository. Just for efficiency that just didn't make any sense. So like my bash config is one file, the dot bash RC but I have to clone this entire repository to get that one file when I'm creating the package DTOS dash bash. For example, same thing with my fish config or with Xmonad I only need the dot Xmonad directory. I don't need the directories in here for the Alacrity config and SXIV and Kube browser and things like that. So just doesn't make sense again for efficiency. So I split all of my configs up into individual packages into individual repositories. Let me show you what I'm talking about here. If I go to my GitLab at gitlab.com slash DWT1 and if you go to groups, you will see I created this DTOS group a couple of weeks ago. I did a video when I created this new group that way my DTOS projects and my personal projects are separate. I have DTOS dash configs again where I kind of stuff all of my configs that they go in slash etsy slash DTOS and then from here you can think of this as being kind of like your home folder, right? So you got dot cache dot config dot local dot Xmonad your dot bash or C file if you go into dot config you'll have the config folders for various programs. So I was stuffing everything into this one repo DTOS dash configs. I created this new subgroup within the DTOS group. I called it etsy because it makes sense. This is where all of those slash etsy slash DTOS config files go. And now I split it up to where they all have their own repo. That way, for example, when you're installing DTOS dash alacrity which is really just my alacrity config file that's all that is. Now you just get slash etsy slash DTOS dot config slash alacrity which is a folder that has alacrity dot yaml in it, right? Before building that package required you to get clone the entire DTOS configs repository again for one file and that just didn't make any sense. So now I have these, I don't know 15 or 20 new repositories for everything that gets placed in slash etsy slash DTOS. So let me go back to my org document here. I think I can go ahead and I could go ahead and tick that off as well. And again, that took several hours because I had to split the one big repository into like 15 different repositories. I also had to go and change all of the package builds for all of those DTOS related programs that would normally pull from DTOS configs. Now I had to go into each one of those package builds and specify the new repositories that they should pull their configs from. So that was actually a ton of work. Now the next thing, the major thing I wanna work on is getting these window managers straight. So right now still, Xmonad is the only window manager that is installed during the DTOS installation. But in the next week or two, I want to have at least these three window managers packaged up as packages that you can install from the DTOS core repo. I want obviously to package DWM Qtile and awesome. You can see here, I've already kind of got DTOS dash DWM packaged up. It's not public yet, so you guys can't go get it, but I'm pretty close to being done with this one. Matter of fact, I'm close enough. I would almost consider that one done. Qtile, I've got a pretty good start to it. I still wanna work a little bit on the key bindings. There's still some key bindings that are a little different than the Xmonad key bindings. Again, for consistency, but Qtile is really close too. I haven't started doing a DTOS awesome package yet. And that's gonna require quite a bit of work. I actually think my awesome configuration is broken the last time I tried to log in to awesome window manager on my machine. I noticed all I got was a black screen. So there was probably a major update to awesome that my config no longer works for, which again, is gonna take me some work. And then of course I made another note about making the key bindings match. Again, I'm getting pretty close to that. And then I need to make DTOS dash color scheme work for Qtile, DWM and awesome. So what DTOS dash color scheme is, is if I do super PC, this is this D menu script where if I choose the Nord color scheme, for example, it's gonna change to the Nord color scheme for XMobar and for Traer and for Kaki, which is on another monitor and for Alacrity is now using the Nord color scheme. Everything except Dumeemax, but I could do space HT and choose Nord here. But right now I haven't had that set up for any other window manager except Xmonad. So I need to make sure that it also changes the appropriate color scheme for Qtile, DWM and awesome. And of course eventually I want to incorporate in the DTOS installation script a way for the user to choose an option for a window manager. That way you can install or not install Xmonad or Qtile or DWM or awesome. Obviously you should probably install at least one, but if you don't want all of them, you don't have to get all of them. If you want all of them, you can get all of them. And how this is going to work, let me switch this terminal to this screen here. What I'm thinking about doing is just adding to the DTOS script these while loops. So while true, read this prompt. Do you wish to install Xmonad? Yes or no. And of course if the user chooses yes, I'll have it run a command sudo pacman dash s Xmonad, Xmonad contrib, Xmobar, you know all the programs that need to be installed to have your Xmonad desktop. Same thing with Qtile, same thing with DWM. Same thing with awesome eventually. If I show you that little test script in action, you can see this is just a mockup of how it might look. Do you wish to install Xmobar if I choose Y for yes? It'll run the installation for Xmobar, but then it would eventually do the while loop here where it asks me, do I want to install Qtile? Maybe I don't want to install Qtile, so I'll choose no for it. And then it's going to ask me, well, do you wish to install DWM? And maybe I do, so I'll choose yes for it. And yada, yada, yada. So that's how that will eventually work when I incorporate that into the installation script. No need to even start worrying about that yet because I still don't have the packages packaged up. I still don't have any of these in the repository, so this will be one of the last things I do and it will be rather simple to accomplish that. And finally, I want to get started on some of these GTK applications that I've kind of worked on, but I need to finish. I have a welcome program I've been working on for weeks, months even, for DTOS and GTK application written in Haskell that allows the user to choose color schemes and default shills and auto-start programs and things like that. It's pretty well fleshed out for the most part. I just need to actually spend some time, like set aside, you know, like a week to get some of this stuff done. And, you know, that's hard sometimes because I've got so many pokers in the fire, right? So many things pulling me in all kinds of different directions, but I eventually need to finish the welcome application for DTOS and then I may eventually package up that bye-bye program, the logout program that is just, let's see if it'll actually launch here. No, I don't have the binary here for bye-bye, but you guys saw that. It's a little logout program where you can choose to logout, shut down, reboot your screen, little GTK application. I made a video about that just a couple of weeks ago. So there you have it, that's my current DTOS roadmap and it shows you a little bit of what I've been doing here with my time in the last week. Part of the reason I haven't made as much content here in the past few days, or the content I've made has typically been content that didn't require a whole lot of time and effort on my part because I was really focused on getting these GitLab repositories straight and redoing all of my DTOS package builds and all of that stuff. So I'm really excited about this because this is stuff I needed to get done for a while. I've just kind of been putting it off because I knew it was gonna be a lot of work. Sometimes I just don't like work. And of course, as I build this thing out, you guys are gonna get content about it because especially here in the next few days, you're probably gonna get content about either DWM or Qtile, whichever one I get packaged up first. As soon as I get it packaged up and ready for installation for DTOS, of course, we're gonna be running through some installations on camera. And you guys are gonna get to see my new Qtile configs or DWM configs or whatever it happens to be. And I think that's gonna be interesting too because we need more tiling window manager content on this channel. Here lately, it's been Xmoned all the time because it's been my focus because of DTOS. And now when I have other things packaged as part of DTOS, it's gonna force me to use these other window managers as well, which is great for you guys that want more content about things like Qtile and awesome and DWM. So if you're interested in that kind of content, stay tuned to this channel. Before I go, I need to thank the producers of this episode. And of course, I'm talking about Dustin, Gabe, James, Matt, Maxim, Michael, Mitchell, Paul, Wes, Wanya, Bald, Homie, Alan, Armored, Reagan, Chuck, Commander, Angry, Dio, Kai, Dylan, Mars, Drum, Erion, Alexander, Peace, Archon, Vador, Polytech, Realiteats, Phyllis, Red Prophet, Steven, Tools, Devler, and Willie. These guys, they're my highest tiered patrons over on Patreon without these guys. This episode about the future of DTOS would not have been possible. The show is also brought to you by each and every one of these fine ladies and gentlemen. All these names you're seeing on the screen, these are all my supporters over on Patreon because I don't have any corporate sponsors. A corporation wouldn't sponsor me or anything depending on you guys, the community. If you like my work, when I see more videos about Linux free and open source software in DTOS, subscribe to DistroTube over on Patreon. All right guys, peace.