What does this mean, well designed or consistent look and feel? It mostly means to look with the eyes of a user. To think as someone who has to use wyoDesktop as his tool and get his work done and not as one who develops it. It doesn't mean to just add features after features on user's requests, it means to add or drop features on the basis how well they are suited to get a users task done. It also means to consider the importance of features in a broader context, how well they fit in combination with other features. Therefore even good features aren't just added if the don't fit the context.
A desktop system as the user sees it is not only the plain desktop but all applications together. Well designed and consistent means any feature should act similar for analogue actions. That means all parts of a system have to work together that a consistent look and feel is possible. wyoDesktop can't do that alone, it can give hints and helps as with the wyoGuide guidelines. Also wyoDesktop tries to make it simple to integrate applications e.g. through the support of mime types or Linux bundle files.
A simple and easy to use desktop also means to take special care of the display system which is a very important part. Therefore wyoDesktop won't use X, instead it uses the Linux framebuffer through DirectFB. This certainly will also have a positive impact on the beauty of wyoDesktop.
To get a sound technical base environment wyoDesktop has the following corner stones:
Why graphical instead of a console? While with a console everything could be done as long as the right command and options can be found. But how to find them in this huge pile? Even if there are tools which help, an average user is always and a power user is sometimes overwhelmed by numerous amount of possibilities. A graphical solution has the advantage of easy showing the current context and limits the possibilities to recognizable amount. Of course this only works if the shown context is clearly understandable.
Why the framebuffer instead of X? While X is a network solution the framebuffer simply is just a graphical solution for drawing graphics. On a desktop a graphical solution is sufficient and avoids many obstacles. Also the framebuffer allows for better graphic effects when drawing on the desktop. During start-up the framebuffer can be used much earlier allowing to use the framebuffer even during start-up. BTW if drawing over a network is needed there are other possibilities i.e. DirectVNC.
Another reason to use the framebuffer instead of X is somewhere in the unknown future I want to have a system which uses the graphical display right from the start (the first shown message on the screen). X by design will never be able to accomplish this while the framebuffer just needs to get an earlier starting position within the Linux kernel. I've no idea if this ever will be possible but wyoDesktop will be ready then.
Why using the wxWidgets (wxGDK) framework? First it has to be said that wyoDesktop is in dependent of wxWidgets. The use of wxWidgets is nowhere enforced within wyoDesktop. Only since it's a nice cross platform tool and since it's best suited for what I have in mind, it will be used for any project internal tasks.
That doesn't mean any outside application also has to use wxWidgets. As soon as any necessary library is usable side by side with wyoDesktop, any framework or else will work. Of course to take advantage of the framebuffer (DirectFB) these frameworks have to support it.
Standards mean others have though about certain common tasks or features and tried to formulate them in an in dependent way. That doesn't mean each standard has succeeded in getting the best solution. Therefore standards will be closely studied and applied when they fit. Good standards can be easily recognized when they can simply be used, bad standards when they have to be enforced. See freedesktop.org.
The larger part of a usable desktop system depends on the usability of the applications. Since wyoDesktop can't create each application, application guidelines for others have to exist. wyoGuide fills this gap. wyoGuide will be used for all project internal tasks.
Application bundles are for the user just ordinary files while the system is able to "see" into them. A bundle is some kind of archive with a description so the system is able to determine what to do with it. A bundle contains all the necessary readonly files the application needs to run. Of course that doesn't include all the writable files since a bundle can't be changed by the application.
The mimetype library is somewhat special that it not only allows to get mimetypes but also write mimetypes. This is needed since each application should check and create its own mimetype during startup. That's the easiest way to care for a correct installed mimetype. IMO mimetypes (maybe with extended attributes) it the only way a desktop system can interact with the applications.
Linking libraries at runtime and checking their version is an important requirement for binary distributed applications.
Why a new project, why not enhance an existing? Good question, most of the above criteria's would suit any other project rather well. The difference probably lies only in the chosen priorities. IMO none of the currently used OpenSource desktops value the user's view as high as wyoDesktop will do, at least none seems to behave in this way. Eventually, no hopefully, this may change.
None of the current desktops uses the framebuffer as its central graphic output system. Again IMO the framebuffer is rather well suited as the default graphic system and will allow much better functionality and effects. Of course any other desktop may switch to the framebuffer but I doubt any will before wyoDesktop will show how well it looks.
While every desktop adhere in some ways to standards IMO none does it as wyoDesktop will do. Where ever wyoDesktop will try to apply standards when they fit. It won't when they aren't appropriate or are wrong. In any case wyoDesktop will make suggestions for enhancements if it makes sense and will create other necessary ones.
One very important reason for me to start the wyoDesktop project is to create opportunities which allow trying out new or even old kinds of user interaction (i.e. OpenDoc). wyoDesktop will certainly also have good features common in other environments but I tries to add new features to combined them into something more suited for the user.
To center the user into the middle means for developers, to think in views and context and feedback while still designing and coding applications or libraries. This hopefully will lead to better programs, simpler API's, easier to use tools.
A side-effect of the wyoDesktop project will be a wxWidgets port to the framebuffer. What others want to do with it nobody knows but I can imagine that game or art application developers using SDL might be very interested. Who knows maybe it even allows smoothing the transition of Windows application to Linux. Other welcomed side-effects are a window manager for the framebuffer or the login app might be useful by other desktop projects.
Depending on if and how far wyoDesktop will evolve the project itself may become a meeting point for new ideas how to improve any part of the OpenSource community. It's intended that wyoDesktop will become a point where anyone can look for ideas how to improve and enhance his own projects or even to get ideas for new projects.
You can feedback any comments, suggestions and remarks here.