How sophomores their desktop environment wrote

It all started in the second year, at a time when human tablets just started to appear, and Android was still in the second branch. At that time, I was a big fan of the flexibility and customization of linux systems, so it’s not surprising that I had the idea to write my own desktop environment that allows me to run several applications at the same time, but adapted for small touch screens. This idea was shared by one of my classmates (Kirill), who already by that time had some experience in development on OpenGL.

Planning is the most exciting part in software development, and in such a large-scale task, it nicely dragged on for as long as a whole month. Although it is necessary to recognize that the choice of the name took a decent part of the time. It was decided to first write your 2.5D engine, and then modify it to a full-fledged composite window manager. It seemed to us to overload some toolkit as overkill, because it meant that the panels and menus would use the same drawing engine (as I did in Unity, as I understand it). Bicycling your file manager and player would be unwise, and, since we are independent of toolkits, let everyone use what is closer to him. There were practically no programs adapted for touch screens, so after the release it was planned to begin work on adapting the GUI of some popular projects and maintain the corresponding repository.

Development

It is time to revive the interface interface sketches, and I, gathering in a heap all my, frankly, poor knowledge of Web technologies, weakened a bit of an interactive prototype (traffic!):


')
As it seemed to us, the most important thing is to minimize the need to climb into the center of the screen, because the controls are located under the thumbs (if you hold the tablet with two hands). On the left panel, from top to bottom: the angle to switch to full-screen mode, the quick launch panel, the panel of running applications. Right tray, arrows to switch desktops, some service functions. The focus between the windows should have been moved by touch. Instead of window decorations, it was planned to use the control sphere located on the top right panel: when you click on it, it moves to the center of the active window, the words “close”, “minimize” appear next to it, perhaps something else. Of course, it’s already customary to do such things after a long press, and our decision looks a bit strange. The resolution was approximately like on my laptop, and in full-screen mode I really liked it. Well, if so, a desktop version was added to the plan, free from gigantism, and supported by a mouse. Further more. What else to add to the ideal dream dream?) We wanted a red-eyed window manager (WM) with advanced tiling capabilities. It was supposed to have two modes switching by hotkey / active corner:

• Mode of operation - you can freely move the usual floating-windows, tiled-windows are fixed.
• Setup mode - the grid of windows is highlighted, each face of which can be moved with the mouse.

Moving the extreme edge - add a cell, moving the middle one - change the size of the cells. It is possible to drag floating-windows into cells and back, and if several windows can be placed in the same cell, their headers are displayed in tabs. Of course, it sounds somewhat messy, I hope the example will be clearer:


Did we have enough imagination to add something else? :) Of course it was enough, who would doubt. I've always dreamed of transforming the environment for the task - this is how the concept of rooms appeared. This concept allowed for each type of activity to literally customize everything, starting from themes, and ending with the binding of a specific window to a specific cell of the desktop. Thus, the opportunity appeared in one click to create an atmosphere for work, or a minimal environment for games. Fuuh ... in the meantime, the semester began in earnest, and the work that was unfolding was extremely slow and frivolous. As a result, by the summer we already had some demos of the engine, a prototype of the application menu, an init system, I looked through heaps of concepts of desktop environments, there was a rough understanding of how all this should work in general. Over the summer, the engine was almost completed, a library was written to work with ini-like configuration files (according to the free desktop standard).

Autumn

The most dramatic moment in our history has come: at last they have begun to write WM! Cyril began work in the field of compositing, and I plunged into the fascinating world of the NETWM specification, which describes everything that a self-respecting window manager must be able to do. I wrote a binding for working with hints, downloaded and prepared the source codes of small task panels and WMs, started backend for my own. There was little experience, there was even less documentation and examples, but there were plenty of pitfalls. No wonder that the work went slowly, and gradually stalled, once again giving way to study. And then Wayland also seemed meaningfully on the horizon, promising the imminent displacement of XOrg'a, and the devaluation of our efforts to combat it. The temptation to write then immediately began to creep under him, becoming the first pure Wayland environment ... Who knows what this story would have ended if 100% of developers wouldn’t call to work in the spring, and OS X wouldn't work? The window manager, there, of course, is very mediocre, but everything else is more than worthy.
Did we realize the scale, trying to move the mountain? Perhaps not, we were full of optimism, inspired by the example of Linus, and some other personalities. Of course, today, starting such a project, we would definitely stop at Qt, which would save at least a year of development, start with a working prototype. But on the other hand, we don’t regret at all the time spent, because how else can one acquire so much experience and inspiration without trying to embrace the immense?