One of the things I have started to wonder about is hierarchical workspaces and if they are actually useful at all. It was one of my plans to include them, but I have started to think perhaps they might interfere with the intuition of using the window manager. How many workspaces will the average user need? Four, Five, Nine? Right now the maximum workspaces that fenestra can handle is nine, mainly because you could use WIN+(1-9) to switch between the workspaces, but also because of the way the code is structured (that could be changed though). Also, I am not really sure how I will implement the hierarchy, and if I do a massive chunk of the code will have to be heavily modified.

Another thing I have been looking into is something called Wayland, and it appears to be the future in terms of display servers. Right now, Wayland is a protocol between the compositor (the window manager) and its clients. Currently it could host multiple X servers to run X applications, and also native Wayland clients to be run along aside the X apps. Many distros have already announced intentions to use Wayland for their distro, Ubuntu and Fedora are just two. And I think it is something to look after, as this might very well be the future of window managers on Linux.

Design issues is something I never ran into before, probably because I never really worked on large scale project before. Something I have been coming across is how to write my code so that it anticipates future features. Future features, that at the present moment, I am not sure how I am going to implement quite yet. And so, it's this dangerous game of trying to prepare for future features while at the same time not being bogged down in creating this framework for them. Right now, I have been mainly working on getting fenestra working and then later, when I actually add a feature, I will go ahead and modify the code for the new feature to integrate with the old code. However, this is not what I did for the workspaces, and when I finally came along to adding workspaces, all of the structural code was there and allowed me to integrate them seamlessly into the codebase. So right now I am in a struggle of cleaning up the code for it to be more easily modified for future features and to try to reduce future bugs down the road. Hopefully, while I am cleaning the code I won't inadvertently add new bugs that will cripple the project unexpectedly later on. However, I guess that is what git is for.

So I am glad to say that fenestra is in a very good state, as in it's functional and very useable... Well, by my standards that is. I still have a long way to go with debugging some issues, adding more features, adding more support EWMH, and making sure others can use it (as in, it works for other people too, and not just for me). I am very pleased with it so far however, and in about only two days, everything came together. According to my plans, it'll be fully ready to go for the demonstration/presentation tomorrow.

Well this is really good news (to me), I have workspaces working perfectly smooth without almost any trouble. This should allow me to now actually work in fenestra, and use my own project to work on my project. I have been using XFCE4 lately, and perhaps no longer constantly taking my hands off the keyboard to move the mouse will increase my productivity. However, a few bugs have propped up in mapping windows and selecting windows, these bugs have been a pain to track down and are slowing my overall progress greatly.

I almost feel like the only thing that really is keeping me back in this project is simply trying to work with the library (Xlib), it is perhaps the single most frustrating component in this project. Any time I feel I have a handle on something, the library smacks me back down and says "listen, there's more to this than that." Maybe every project is like this, I am comfortable in my programming ability and with my understanding of the language, although there are many corner cases in C that I might fall trap to. However, fenestra is coming along fine and dandy and I hope to have some usable functionality next week.

One of the things I have been thinking about lately is what exactly does lightweight mean? Which one of my goals is to keep fenestra lightweight. Does it mean a simplistic, easy to use design? Or does it also mean light system resources? Or does it even mean a simplistic codebase that is easy to understand and build upon? I have been trying to keep all three of those points in my mind when coding fenestra. Perhaps my ultimate goal when making a lightweight window manager is to have it so simple to use, that even a child could learn it and use it, even without the use of the mouse. I recently read a blog of someone who was teaching his two kids Linux, and up until recently he never showed them a GUI, preferring to teach them using the command line only. And when he finally decided to show them a GUI, he chose xmonad as the window manager, xmonad being a tiling window manager like fenestra. He chose xmonad because it was a window manager in the purest form, it has no file manager, it has no desktop environment, it's simply a window manager.

I guess that's what I really mean by lightweight, a simple and usable tool that gets the job done every time. Any extra bells or whistles are unnecessary to me or even just another distraction to my workflow. If all I want to do is open up a text editor, a terminal and web browser for documentation, fenestra can easily do that in the most efficient way possible and without your fingers ever leaving the keyboard.

One of my major goals has been essentially completed, and that is that fenestra is a functional (but not necessarily practical just yet) tiling window manager. When a window is created, it automatically tiles it accordingly, you can also move the windows around in the tiling formation, close windows, change the focus and move the two window stacks on the screen. The design of the tiling is based on dwm, and in a way it is not completely 'powerful' in the sense that the user has absolute complete control over the tiling scheme. Instead the screen is split into two vertical stacks in which the windows will horizontally stack. I would like to make it so that there can be any number of vertical stacks with any number of horizontal windows in each vertical stack, however to make this possible I would have to rework pretty much all of the backend code that deals with the tiling and come up with a clever way for the user to control this. I might make this a long term goal of mine. Even then, the current tiling schema is more than adequate.

Right now I plan on adding the status bars and basic workspace functionality to fenestra before my first presentation next week, that way I have a usable and practical project to demo, and not just a prototype of "things to come." Unfortunately, I got behind this week due to some computer issues, but the project has been moving a long at a pace that I am happy with.

One of my short term goals has been completed, and that is the tiling of the windows. So right now, the user has the ability to create new windows and fenestra will automatically tile them onto the screen. The user can also change which window is the "head", essentially the head is the most important window (not always), and the user can change the focus to any window. Unfortunately, closing windows isn't as simple, if you close a window, fenestra should crash (feature not a bug...). Next week I should finish up the tiling features and get into adding workspaces and toolbars.

Progress has been slow, but steady, I have finally been able to settle down into a normal workflow after moving into my apartment. One of the great difficulties in creating a window manager is just the sheer complexity of Xlib, there's a lot of small but important details that I am just cutting my teeth on. Today, I am going to start working on probably one of the most critical components of fenestra, and that is the tiling of the windows. The format of the windows is going to be very similar to that of dwm, such that you have a 'stack' of windows, and the screen is split vertically (and in the future horizontally perhaps!). Therefore, you could have one window on the left side, with three on the right, or one on the right and two on the left, or even three on the right which would then occupy the whole screen. I might implement a tiling scheme similar to emacs as well, where you can split the currently focused buffer horizontally or vertically.

The other short term goal is to have functioning workspaces that can be created on the fly, and two toolbars on the top and bottom, such that you can tell what workspace you are in, what window is selected, and what windows currently exist in that workspace. I plan on having hierarchical workspaces, such that the programming workspace can open up into two or more other workspaces. So that you can have say a workspace for a text editor, another for documentation, another for a web browser, all devoted for programming. Until I can get normal workspaces working, this will be a long term goal.

At the beginning of every project there's at least one fundamental implementation question that must be decided upon. For me, it was between implementing fenestra utilizing XCB or Xlib, both allow for interaction with the X server, but ultimately function in very important and subtle ways. Xlib is the venerable library that has been around since the mid 1980's, while XCB is a rather 'new' creation that has been around since 2001. XCB was designed to be simpler and lighter than Xlib as well as being more direct to the X11 protocol, therefore XCB is lower level than Xlib. XCB, unlike Xlib, splits the request/reply action to the server into two components, this makes XCB radically faster than Xlib, as Xlib blocks until the reply for a request is received.

Despite all the advantages going for XCB, I decided that I would use Xlib instead, simply because the documentation for Xlib far outstrips the documentation of XCB. For now, fenestra will be coded using C and Xlib, but that doesn't rule out a future for fenestra using XCB.