English
资源说明：An experiment to create a simple yet feature-rich, well-behaving window manager.
README for wmd - the window management daemon
1. Installation and usage
2. Introduction
3. Project priorities
4. Releases
5. Infrastructure
6. Licensing and copyright
7. Co-operation
8. Code style
9. Initial release schedule
10. Milestones
11. Contributing
12. Random thoughts
1. Installation and usage
=========================
From a repo: ./autogensh && ./configure && make && make install
From a tar-ball: ./configure && make && make install
Running: wmd --help
If it's not in --help, it's not in wmd. If it is, then someone got drunk,
wohoo!
See WIP (Work In Progress) for day-to-day changes. The content of WIP as it
was upon compile-time is usually printed upon startup.
The rest of this document is a README on the project as a whole, not wmd
functionality. As stated above (and below, for that matter), that sort of
documentation should be in-line, thus available through --help.
2. Introduction
===============
The Window Management Daemon (wmd), has been an idea growing over a number
of years during which I (Kristian) worked on Beryl/Compiz, and tried
various other window managers. It's currently an experiment trying to put
past experiences and ideas into practice, without being held back or
affected by an old code base and inherited muck.
As the observant reader will notice, documentation and planning has been a
key element from day 1 of WMD-development, and that is meant to be the key
factor that sets wmd apart from similar projects. This will serve as an
experiment to see if such a development strategy is suited for the "Bazaar
model" of free software development. Only time will tell.
There used to be a section about "other window managers", but instead I'll
just say this: I was inspired by Beryl, Compiz, WMii and Awesome. For
better or worse.
Initial development will be sporadic.
3. Project priorities
=====================
Summarized: Intuitive, stable and predictable.
wmd priorities should be, in somewhat prioritized order:
- Intuitive in every area
- Documentation
- Precise, concise, consistent and up to date.
- Document for efficiency and clarity, in that order.
- Do not distinguish between developer documentation and end-user
documentation.
- Never break
- Any pure window management bug should be fixed immediately and
included in a release, regardless of scope.
- Learn from the mistakes.
- Avoid compromises.
- Clean and lean over feature rich.
- Be a good free software and OS citizen.
- Follow established norms.
- Keep dependencies at a minimum, and make sure they are readily
available where necessary.
- Freedom
Project management is a strong focus, but should not get in the way of
developers and users.
The ultimate goal is a window manager that "just works" for the use cases
that it's aimed for (terminal-heavy usage), is easy to hack on and easy to
include in operating system distributions. And a healthy and self-going
community to go along with it.
4. Releases
===========
Summary: X.Y(-n): Errata for all wm-bugs and on popularly distributed
versions.
This is a preliminary release strategy, it's subject to change without
prior notice during the early releases. Hopefully, this will make
involvement with wmd easier.
Versions: x.y(-n)
X: Configuration incompatibilities and major refactoring
Y: Minor refactoring and configuration additions.
N: Bug fixes.
X: Major, Y: Minor, -n: errata
When wmd is reasonably usable and has gained a user-base, release
maintenance will commence. This means about three releases at a time will
be maintained with bug-fixing releases. The exact amount versions and
duration will be clearly stated, and input from packagers is encouraged.
ALL affected versions of a major-release will have errata releases for
window-management bugs if even a vague hint of a necessity arise. So let's
not have wm-bugs. An example of a wm-bug is a window being hidden when it
shouldn't be, size-hint related bugs, etc.
wmd version numbers should be human readable and logical; Not adjusted to a
packaging scheme or to have "unused" numbers that are used in the
development tree.
The errata (-n) portion of the version will be omitted for the original
release. Ie: When released, the release will be 1.5, and if an errata is
made, it will be 1.5-1, etc.
When a branch for a major version is created, no minor-releases for the
previous major-series will be made.
To avoid packagers keeping a significant amount of in-house patches, errata
releases will be made for any version that's used in a reasonably popular
distribution if the package maintainer wishes.
5. Infrastructure
=================
Do not repeat the mistakes of the past.
Documentation should be kept in the source tree - that's where developers
work. Documentation should never be duplicated but should be easily
available. Documentation is never automatically generated though converting
automatically from one format to an other (text in the source tree to html
on web) is good.
The software stack in the infrastructure should be free and reasonably easy
to migrate.
The infrastructure is as important as the rest of the project, but should
not be overdone. The official project should (in time) provide:
- A version control system, readable for all. Including web-based access
- A web page
- An issue tracker
These components do not have to be tightly integrated, but all the services
should be clearly visible.
The infrastructure should follow the same basic philosophy as the main
project. It should remain predictable, intuitive and stable over a long
period of time.
It should be noted that during the initial phase of development, the
infrastructure is very likely to change - until a certain momentum is
reached.
6. Licensing and copyright
==========================
Summary: You retain copyright, GPL2+, state the source of the code.
All contributions must be compatible with GNU GPL version 2 and include the
"or a later version"-clause.
The project will be released as GNU GPL version 2 until an equally readable
license is available to take it's place. Sorry rms. As a promise to my
fellow developers, I(Kristian) will not change the license on any code
copyrighted by me to anything besides a GPL-license. (No X-Chat sellouts,
in other words)
Copyright should be clearly stated. Whoever wrote the code will retain the
copyright. If code is borrowed, the original source, copyright and license
must be clearly stated (and compatible).
7. Co-operation
===============
Summary: Don't squabble over bs and let the people to whom it matter most
decide. "Meritocracy" is a bullshit word.
Any decision that affects the appearance of the project (web-design, name,
etc) should be decided by the most active contributors. If an obvious
decision can't be reached, then use what we got.
Respect your fellow contributors, even if they just joined the project.
Senior and junior contributors deserve the same level of respect and
consideration. On the other hand, some decisions affect the most active
contributors more than the less active, and in such cases, their needs
should be placed first.
In the end, reaching agreements is the key. Even when you disagree.
All discussions should be kept in the public. E-mail should always
be assumed to be public and copied to relevant mail lists. The
project language is English, there is no exception to this. Even if
you are alone in a chat-room, speak English. We can not have open
communication if everyone doesn't speak the same language.
All documentation should be in English. Internationalization is not
a priority, and will only be accepted if it does not get in the way of the
other priorities and can be verified by trusted sources to be precise.
Translations will be removed if they are not updated reasonably frequently.
8. Code style
=============
K&R, Linux-style.
Read the doc for Linux if in doubt.
Variable- and function-names should be easy to keep track of, regardless of
scope.
Modularize your code. Keep well-defined interaction points. Code for
readability and maintainability, not how fast you can type it or prototype
it. Perl is stupid, so let's make sure there's only one way of doing it.
Far easier to maintain.
Sanitize input proportional to how exposed the code is: a static function
you only intend and envision will be used from one or two points might not
require much (if any) input sanitizing, but the moment the same function is
no longer static, it must check basic input. If it's from a user, it must
check that the value of the input is valid.
Make sure the code is intuitive even if someone hasn't read all the
header-files.
9. Initial release schedule
===========================
This WILL change. But this is the initial plan:
0.1: PoC framework. Switch focus. Execute.
0.2: Tiling layout engine.
0.3: Floating windows.
0.4: Window context backend - tag engine.
0.5: "Maintenance" release. (Documentation and cleanup release)
0.6: Configuration PoC.
0.7: Refactor keybinding backend.
0.8: "Maintenance" release.
0.9: Stacked and max layout.
0.10: Configuration defaults rework.
0.11: "Maintenance" release.
0.12: Decoration refactoring.
0.13: "Maintenance" release.
0.14: Information-exposure tests ("menu"/"status"-bar? External?)
0.15: "Maintenance" release.
0.16: Configuration sanitization and minimzation (prep for a stable
configuration scheme)
0.17: "Maintenance" release.
0.18: ?
1.0: Feature-test release.
2.0: Multihead.
The 0.x-series is used to evolve the basic functionality needed and "Set
the tone". 1.x will be used to find the right way to go forward, and see if
we can discard some broken ideas. Rudimentary multihead should evolve
during 1.x, and be sane in 2.0. As the educated reader will surmise, the
initial releases will be quite unusable. The idea is to have a clear goal.
The schedule is subject^W guaranteed to change at any given time. There
will not be errata-releases for 0.x, while patch-releases are likely.
Build system is autoconf/automake and family until a real need for
something else arise. A switch of build system will require a new major
version after 1.0.
During development, the version in the tree will be the to-be-released
version, possibly with a -devel. Short story: -devel is not a guarantee for
a future version.
10. Milestones
==============
Summary: Development milestones will be set and tagged to clearly state
progress and state.
While releases happen frequently, milestones can happen earlier. The idea
is to add milestones and tag the tree thereafter before it's actually ready
for release, or before some other major work is about to begin.
For the 0.1 cycle, the following milestones are set:
"Non-wm basics": Basic parameter handling, configuration parsing, help
subsystems.
"XCB core": When the core XCB functionality is in place
"Focus switching": SSIA - Probably redundant.
"Binding configuration"
11. Contributing
================
Any and all contributions are welcome, though subject to moderation. The
easiest way to contribute during the early stages is probably to try it
out, look around at the code/ideas and tell me what you think. Even if wmd
doesn't really function as a window manager, it's better to fix the
fundamental misconceptions before the manifest in code.
Since the core infrastructure isn't finalized yet, most of the code is
likely to change. Still: Patches are _always_ welcome.
I'm also looking for potentially long-time contributors/developers. My only
request is that you know at least some C-coding. Other than that C is a
small language and ideas are more important than code.
12. Random thoughts
===================
To be able to be concise, I need to figure out a way to make the
inform-code not print 5 different variations of the same nested
error/warning. Example: setting an integer-option out of range. Though the
backtrace-like feel is sort of nice. I guess I could add a "stack-counter"
to inform() so the inner (original) error prints at #0, the second layer
prints at #0+1, the next at #0+1+1 and so forth? Ie: If you know what went
wrong, print at #0, if you inherrited the error print at #x+1?
An other concern is hooks. There are less than a dousin interesting ones.
Should be easy to deal with, though.
I also want wmd to be able to operate similar ot a normal window manager
(non-tiling) on certain work spaces. That way you can have a workspace with
stuff like gimp or openoffice without fighting too much with the wm.
And I have no qualms about making one virtual workspace for each physical
head - if configured to.
Things like tiling should always work on the concept of least possible
movement. So when "booting up" it should try to map the windows into a grid
similar to how they were to begin with. And if you do things like run
nvidia-manager to resize your screen, windows should remain were they were
as much as possible.
As far as layout-engines go, they should essentially be hooks too. And not
use global data structures, as they need to be able to seamlessly switch.
They should also be "re-entrant". Each window should be owned by a work
space, which in turn should have _one_ layout engine. This should make
windows stretching multiple physical screens reasonably easy to deal with.
本源码包内暂不包含可直接显示的源代码文件，请下载源码包。
