Well then, when thinking back, I had many situations when I wanted a certain piece of software to exist which didnt exist and for which I had absolutely no time to create it. Some approaches of creating it are now collecting dust in my projects-Directory, sometimes its just a file with some URL’s for documentations I want to read, sometimes its a little more.
One of them is the trial of creating a platfom-independent Window-Management API. And in fact, this is a kind of software which really should exist imho.
One of the first things that are really getting on my nerves when having to switch between different OS’es is that the windows, taskbars, etc., are behaving in a completely different way. Though I can adapt Linux the way I want, sometimes I just want some feature that one OS has in some other. Fortunately, the X11-Policy allows Window-Managers to be created, and thus, you will always find a Window-Manager which fits your needs – or you can create a new one. This is very hard, but its possible.
On the other hand, also for Windows it is possible – though unusual – to change the look and behaviour of application windows – you can get the graphical surfaces and put them somewhere else, etc., as some Virtualizers can do with special guest extensions. And – of course – for Mac OS X, there are a lot of applications trying to add a reasonable WM.
So the question is, why not creating a portable WM-API, which can run on X11-Based UI-Systems as well as Windows, Quartz and other Systems? Maybe there is one, I couldnt find one so far.
Of course, there are a lot of problems with this. Making something portable often means to make a compromise with a lot of tradeoffs, which – dependent of how portable it really is – sometimes boils down to just provide the small set of features which can be provided under all of the Windowing Systems. For example, when you want to make something like Compiz Fusion portable, you will run into problems immediately, because it may not be easy to actually get the surfaces of the rendered Window-Contents in a portable way in every case – depending on the format of it, and depending on which Drawing-API is used. Of course, today, OpenGL should be a good choice for this, because every System supports it and every System supports 3d-Desktop-Effects, but just a few years ago this would have been a problem.
And still, today, we have differences like the centralized Main-Menus of Mac OS X, which can hardly be implemented in a portable way without a lot of hacking through several Windowing-Toolkits. And who knows what will be the future of Desktop-Environments.
But thats not the point. Such an API could – of course – just provide a small set of wrapper-functions and a general framework which makes it easier to write portable Window Managers, and with every completely new feature, there would be the necessity to extend the API – or simply not support it.
On the other hand, there is a portable VFS-API (FUSE), there are portable File-Access-Libraries, portable Graphic-Libraries and Windowing-Toolkits, which all have to handle basically the same problems.