Expectations- the window

There's a lot of continuous noise about the variations available in Linux, and the pros and cons of such a range of choice. I recently had the privilege of watching a video called Revolutions OS, and learning something about the origins of Linux, and the variety of perceptions, frameworks, and determination by a gifted few to evolve a UNIX based system to new heights of technical structure, visionary digital steps into the unknown, and ultimately, the acceptance that us ordinary users would want an OS, in all it's variations, that we could use without requiring a degree in coding.

In any group of people there's a common truth. Some will go left, some will go right, others down the middle, and those who wander from direction to direction having a look at what the others are doing, and making their choices from what they see. The Linux community is no different, and particularly so, imho, in the Linux audio community. A disparate collection of individuals coming together to build something new, share ideas, express personal views, often passionately, and develop tools for a particular task. And in this particular blog, is the choice of Window Manager, as a visually understandable manager of those tools. As passionately as coder and user communities discuss features, and potential tools of use, and the form of their implementation, the choice of Window Manager can bring quite a degree of heated discourse as to which WM serves the purpose most efficiently.  

So what do we want from a Window Manager?

That's a huge question, as the requirements of users and coders alike is so individual as to negate the question as a "generic" entity in the first place. For the Open Octave Project, i did nearly 2 years of research, trying different Wms, including gnome, kde, and variations of these, xfce, lxde, and assessing the pros and cons of each one.

To do this, i had to examine what it is i wanted in the first place, and i would say frankly here users often have little idea of what they want, as they don't examine their own needs as closely as they examine through demand a feature, or tool set they "think" they need. There's a responsibility on dedicated users here to understand their own workflow, and what's required, in a realistic and practical sense, to achieve the task at hand. It's been my experience that developers in our community are a lot more receptive if they recognise a well thought out feature request from a user who has put in the time and effort to examine the request first, and be sure it offers a rich addition to the toolset of the application, and can present that request in a manner that shows the inherent usefulness, not just for today, but going into the future.

Choosing a WM is part of this user task, and in our professional/fulltime use case, we had a list of requirements.

1.) It must be light and efficient.

2.) It has to be highly tweakable, and enable the user to more completely define its function.

3.) It should encompass multi-workspace capability.

4.) In a dedicated linux audio/midi/video rig, it should,where possible, chew the minimum of system resource, leaving said resource for the important tasks of recording, playback, etc..

5.) It should NOT add any additional kits, daemons, fontsets, and themes as compulsory, nor should it rely on an endless stream of dependencies, for apps we're not going to use, or have an interest in using.

6.) In a lean and powerful system based purely on performance, where icons are not included, the WM should have a rich and varied collection of keystroke based tools, components, and options, that where possible, negate the need for a mouse only option, as a function of speedier daily use through keyboard based use.

That's quite a list based on a real use case, and daily operation, but there are candidates for users who  are willing to learn to use a slim window manager that is driven by practical use, and not nice themes or colours, mouse use as a default, or icon based navigation and operation. The WM candidates that go close to fitting this bill are well known, and information can be browsed for, with numerous forums, tutorials, and ircs, to enable a user to make a more educated choice, provided the user is willing to make the effort.

My choice, based on the above list, is Fluxbox, and it works well not only for the above requirements, but has additional opportunities for the user to exploit, when building a DEDICATED linux audio setup. Fluxbox, imho, does what it says on the tin, and "presents" the applications i use in OOP, in a practical and efficient framework, devoid of unwanted guff and chaff.  The ability to apply keystrokes to just about every command you can think of when navigating in a WM, build macros of key commands to perform repetitive task combinations, and the infinite multi-workspace component makes Fluxbox very powerful indeed. Over half the apps in OOP can be run as backends from a terminal, saving resource that would be wasted on GUI requirements. It doesn't make sense to employ a big complicated WM, replete with colours, icons, themes, and unwanted services running in the background, when building a box to be as efficient and powerful as possible. At least it doesn't to me.

To all those people who pointed me to Fluxbox in the first place, and took the time and patience to walk me though the initial build and function, thank you. For what i do, and for our project, Fluxbox covers the most bases, and gives me what i want, to a higher percentage than any other WM i've used, for a DEDICATED box, built to a specific purpose. 

I finally "get" it, in other words.

Some others to keep an eye on are blackbox, openbox, xfce for those fond of a mouse, etc..

Before i go onto the next part of my journey, i'll answer an unrelated question that keeps coming up, and Chris and I keep getting hammered with. Just to make things absolutely clear.

The answer is NO.

We are intent on building our project up as a complete solution from A through to Z, and we're NOT interested in coding, or compiling, or creating .debs, rpms, or any other derivation of an autoload app, and having to deal with the subsequent dependencies.

We use Gentoo, and the proaudio overlay, and any mods we make will be with that as the priority, based on our original Project intent. If anyone wants anything we build or modify to work in debian, ubuntu, or any of the other distros, you'll have to do it, but more importantly, you'll need to "service" any requests, or problems. for anything you build. We're NOT going to end up as an answering service for a distro build we don't support, didn't build, or have any interest in building. From our project perspective, we expect we might end up with 100, or less, dedicated users for whom our profile is the most viable option for them in an orchestral and filmscore related format, that has nothing to do with mainstream distros, and everything to do with workflow.

We are NOT doing generic, just because someone else thinks we should, and the idea that a generic mainstream distro, and their particular app installation method, has some priority in our decision making process is completely without foundation. 

Up until now, the majority of linux audio frameworks has been distro based, and more for domestic use. (with the odd exception.) Those efforts have also been focused in the main on more modern musical forms, and until now there's been no dedicated setup for those of us looking to use linux audio tools in a different genre, and by it's nature, far larger and more complex framework. It's our intent, and our project goal to address this, from start to finish in the process, including careful choices of kernel, WM, apps that work, and have the toolset we want, etc.

If you'd like to use anything we make or modify for distros, then go right ahead, we're not stopping you at all. If you make this distro based choice, then you can manage it, and service complaints or challenges. We won't be.

We have far more important work to do.

Just to be absolutely clear.

Alex.