Check-in [3f11394238]
Not logged in

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Updated design notes.
Timelines: family | ancestors | descendants | both | dev1.x
Files: files | file ages | folders
SHA1:3f11394238f47333f6c0c753a5128351c22b2517
User & Date: manuv 2013-08-04 08:43:29
Context
2013-08-04
09:28
Added rectangle to minx.layout.full constructor. Leaf check-in: 49f4a20229 user: manuv tags: dev1.x
08:43
Updated design notes. check-in: 3f11394238 user: manuv tags: dev1.x
2013-08-03
01:51
Updated milestones to reflect current idea of how to proceed. check-in: 38c4e0baf0 user: manuv tags: dev1.x
Changes

Changes to wiki/design.wiki.

3
4
5
6
7
8
9
10
11
12
13
14
15

16
17
18
19
20
21
22
23
..
24
25
26
27
28
29
30
31
32
33
34

35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

50
51
52
53
54
55
56
57
58
59
..
67
68
69
70
71
72
73
74
75
76
77
78

79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
...
108
109
110
111
112
113
114

















115
116
117
118
119
120
121
...
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154







155
156
157
158
159
160
161
<h1>Design and Implementation Notes</h1>

The following diagram shows a high-level view of the different classes
and roughly how they're connected to each other.

<img src="img/object_diagram.png" width="900" height="337"/>

The <tt>minx.core</tt> classes are written in Python whereas the
<tt>minxlib</tt> classes are written in C++ and exposed to <b>Minx's</b>
Python core.

The organization of the code mirrors the above diagram. All the
<tt>minx.core</tt> classes are in the <em>minx/core</em> directory and

the <tt>minxlib</tt> classes are in the <em>minx/minxlib</em> directory.

<hr>

<h2>minx.core</h2>

<h3>minx.core.wm</h3>

................................................................................
This class is the main window manager object that end-users will create.
It maintains all the necessary state and provides the interface for
customizing the window manager.

When you create a <tt>wm</tt> object, you can supply a <tt>config</tt>
object to its constructor to customize various attributes such as the
border colors. To further customize Minx's responses to various events,
you can add your own hook functions to the <tt>wm.hooks</tt> object.
After these setup steps, call <tt>wm.start()</tt> to run the window
manager.


The <tt>start()</tt> method connects to the X server by creating a
<tt>minxlib::display</tt> object, performs some initialization so as to
receive various window management related events, and then enters the
event loop. The actual event handling is delegated to the
<tt>minx.core.xevents</tt> object, which has the necessary event handler
callbacks.

X errors are handled by <tt>minx.core.wm</tt> as part of its event loop.

<h3>minx.core.hooks</h3>

This class implements a mapping between strings and corresponding
function lists. The string keys identify different events. For example,
all X events are of the form "x_something" (x_map_request,
x_create_notify, etc.). Most end-user hooks are of the form "some_hook".

Key bindings are also handled as hooks (their names are not of the form
"some_hook"; they follow a different
[/doc/ckout/wiki/key-bindings.wiki|pattern]).

All objects within the system that have a reference to the <tt>wm</tt>
object can get at the hook map and add functions to it. This map is
meant to be used inside the window manager itself as well as by
end-users (for customizing Minx).

<h3>minx.core.xevents</h3>
................................................................................
constructor creates an <tt>xevents</tt> object, passing it a reference
to itself. Through this reference to <tt>wm</tt>, <tt>xevents</tt> is
able to add its handlers to <tt>wm.hooks</tt>.

Now, when <tt>wm</tt> gets events from the X server, it triggers the
appropriate handler in <tt>xevents</tt> via its map of hooks.

<h3>minx.core.window and minx.core.focus_list</h3>

The <tt>minx.core.window.window</tt> class is used to represent
top-level windows, which are created by <tt>xevents</tt> in response to
the "x_create_notify" event.


The <tt>minx.core.window</tt> module maintains an internal list to keep
track of all extant top-level window objects. When a top-level window is
destroyed, its object is removed from the above-mentioned internal list.

When a <tt>minx.core.window.window</tt> is created, <tt>xevents</tt>
passes it a reference to the <tt>wm</tt> object. Thus, all top-level
window objects have access to the window manager's <tt>hooks</tt>. On
creation, <tt>window</tt> installs some relevant X event handlers for
itself in the system <tt>hooks</tt>. Among other things, these hooks
are responsible for changing the window's border color on focus changes.

Not all top-level windows can be focused. For example, the GNOME and
XFCE terminal programs create a couple of hidden top-level windows.
Therefore, only a subset of the <tt>window</tt> objects maintained by
the <tt>minx.core.window</tt> module can actually receive input focus.
These windows are put in the <tt>focus_list</tt> by the <tt>xevents</tt>
object. This usually happens when the X server sends a
<tt>MapNotify</tt> event for a top-level window to Minx. When
<tt>minx.core.wm</tt> receives an <tt>UnmapNotify</tt> for a top-level
window, <tt>xevents</tt> will remove the corresponding <tt>window</tt>
from the <tt>focus_list</tt>.

<h3>minx.core.config</h3>

This class allows end-users to effect simple customizations such as
changing the window border colors and sizes. End-users will have to
instantiate this class and change its attributes to get the desired
customizations. The resulting <tt>config</tt> object should be passed to
................................................................................
the <tt>minx.core.wm</tt> constructor. Any object that has a reference
to the <tt>wm</tt> object can then get at its <tt>config</tt> instance
to access the different settings.

If end-users do not create a custom <tt>config</tt>, Minx will use
default values for all its supported customizations.


















<hr>

<h2>minxlib</h2>

minxlib is a small C++ library that provides a high-level,
object-oriented API to Minx's Python core for interfacing with Xlib. We
could have used [http://python-xlib.sourceforge.net/|python-xlib]
................................................................................
[http://wayland.freedesktop.org/|Wayland] whenever that becomes the
preferred means of talking to the video hardware.

Note that minxlib is not a thin wrapper around Xlib. It provides an API
that the rest of Minx actually needs. That is, the primary goal of
minxlib is not to wrap around all of Xlib but only that part of it that
we actually need for Minx. Moreover, minxlib provides a high-level API
that goes beyond the primitive one implemented by Xlib.  For example,
minxlib has a function to return a list of all the root windows across
all screens. Thus, the Python parts of Minx don't have to deal with the
low-level Xlib functions to enumerate the root windows one-by-one.

<h3>minxlib::display</h3>

The <tt>display</tt> class encapsulates the connection to the X server.
It provides the conduit for retrieving events from the server and for
converting X errors into exception objects that Minx's Python core can
handle.

<h3>minxlib::window</h3>

This class encapsulates an X window. Note that whereas
<tt>minx.core.window</tt> is for top-level windows,
<tt>minxlib::window</tt> represents any kind of X window. The
<tt>minxlib::window</tt> class takes care of the details of specifying X
event masks. It also provides various window-related operations such as
showing, hiding, resizing, moving, focusing, etc.








<h3>minxlib::event and minxlib::exception</h3>

These two classes provide an object-oriented interface to X events and
errors.  Different types of events are converted into instances of
subclasses of <tt>minxlib::event</tt>. Similarly, different kinds of
errors are converted into instances of classes derived from







|
|
|


|
>
|







 







|
|
|

>
|
|











|
|
>
|
<
|







 







|

|
|
|
>

<
|
<

<
<
<
<
<
<
<
|
|
<
|

|
|
|
|
|







 







>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







 







|











|

|
|
<
<
|
|
>
>
>
>
>
>
>







3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
..
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

54
55
56
57
58
59
60
61
..
69
70
71
72
73
74
75
76
77
78
79
80
81
82

83

84







85
86

87
88
89
90
91
92
93
94
95
96
97
98
99
100
...
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
...
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160


161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
<h1>Design and Implementation Notes</h1>

The following diagram shows a high-level view of the different classes
and roughly how they're connected to each other.

<img src="img/object_diagram.png" width="900" height="337"/>

The <tt>minx.core</tt> and <tt>minx.layout</tt> classes are written in
Python whereas the <tt>minxlib</tt> classes are written in C++ and
exposed to Minx's Python core.

The organization of the code mirrors the above diagram. All the
<tt>minx.core</tt> classes are in the <em>minx/core</em> directory, the
<tt>minx.layout</tt> classes in <em>minx/layout</em>, and the
<tt>minxlib</tt> classes are in the <em>minx/minxlib</em> directory.

<hr>

<h2>minx.core</h2>

<h3>minx.core.wm</h3>

................................................................................
This class is the main window manager object that end-users will create.
It maintains all the necessary state and provides the interface for
customizing the window manager.

When you create a <tt>wm</tt> object, you can supply a <tt>config</tt>
object to its constructor to customize various attributes such as the
border colors. To further customize Minx's responses to various events,
you can add your own hook functions to the <tt>wm.hooks</tt> object. For
layouts, you can deal with the <tt>wm.layouts</tt> object, which is an
instance of the <tt>minx.core.layman</tt> class.

After these setup steps, call <tt>wm.start()</tt> to run the window
manager. The <tt>start()</tt> method connects to the X server by creating
a <tt>minxlib::display</tt> object, performs some initialization so as to
receive various window management related events, and then enters the
event loop. The actual event handling is delegated to the
<tt>minx.core.xevents</tt> object, which has the necessary event handler
callbacks.

X errors are handled by <tt>minx.core.wm</tt> as part of its event loop.

<h3>minx.core.hooks</h3>

This class implements a mapping between strings and corresponding
function lists. The string keys identify different events. For example,
all X events are of the form "<tt>x_something</tt>"
(<tt>x_map_request</tt>, <tt>x_create_notify</tt>, etc.). Most end-user
hooks are of the form "<tt>some_hook</tt>". Key bindings are also handled
as hooks (their names are not of the form "<tt>some_hook</tt>"; they

follow a different [/doc/ckout/wiki/key-bindings.wiki|pattern]).

All objects within the system that have a reference to the <tt>wm</tt>
object can get at the hook map and add functions to it. This map is
meant to be used inside the window manager itself as well as by
end-users (for customizing Minx).

<h3>minx.core.xevents</h3>
................................................................................
constructor creates an <tt>xevents</tt> object, passing it a reference
to itself. Through this reference to <tt>wm</tt>, <tt>xevents</tt> is
able to add its handlers to <tt>wm.hooks</tt>.

Now, when <tt>wm</tt> gets events from the X server, it triggers the
appropriate handler in <tt>xevents</tt> via its map of hooks.

<h3>minx.core.layman</h3>

This class implements a layout manager, which keeps track of the
different layouts. The <tt>layman</tt> class maintains a list of layout
objects and provides an API for adding layouts, looking for them, and so
on.


<h3>minx.core.focus_list</h3>









Not all top-level windows can be focused. For example, the GNOME and XFCE
terminal programs create a couple of hidden top-level windows. Therefore,

only a subset of the top-level windows can actually receive input focus.
These windows are put in the <tt>focus_list</tt> by the <tt>xevents</tt>
object. This usually happens when the X server sends a <tt>MapNotify</tt>
event for a top-level window to Minx. When <tt>minx.core.wm</tt> receives
an <tt>UnmapNotify</tt> for a top-level window, <tt>xevents</tt> will
remove the corresponding <tt>minxlib::window</tt> from the
<tt>focus_list</tt>.

<h3>minx.core.config</h3>

This class allows end-users to effect simple customizations such as
changing the window border colors and sizes. End-users will have to
instantiate this class and change its attributes to get the desired
customizations. The resulting <tt>config</tt> object should be passed to
................................................................................
the <tt>minx.core.wm</tt> constructor. Any object that has a reference
to the <tt>wm</tt> object can then get at its <tt>config</tt> instance
to access the different settings.

If end-users do not create a custom <tt>config</tt>, Minx will use
default values for all its supported customizations.

<hr>

<h2>minx.layout</h2>

<h3>minx.layout.base</h3>

This is a base class for all Minx layouts. For the most part, it contains
empty implementations for most events and other functions that are meant
to be overridden by subclasses. Additionally, the
<tt>minx.layout.base</tt> module contains a few event handlers for
various bits of layout related functionality.

<h3>minx.layout.full</h3>

This layout implements a policy of showing one window at a time, resizing
all the windows it manages to occupy the entire area available to it.

<hr>

<h2>minxlib</h2>

minxlib is a small C++ library that provides a high-level,
object-oriented API to Minx's Python core for interfacing with Xlib. We
could have used [http://python-xlib.sourceforge.net/|python-xlib]
................................................................................
[http://wayland.freedesktop.org/|Wayland] whenever that becomes the
preferred means of talking to the video hardware.

Note that minxlib is not a thin wrapper around Xlib. It provides an API
that the rest of Minx actually needs. That is, the primary goal of
minxlib is not to wrap around all of Xlib but only that part of it that
we actually need for Minx. Moreover, minxlib provides a high-level API
that goes beyond the primitive one implemented by Xlib. For example,
minxlib has a function to return a list of all the root windows across
all screens. Thus, the Python parts of Minx don't have to deal with the
low-level Xlib functions to enumerate the root windows one-by-one.

<h3>minxlib::display</h3>

The <tt>display</tt> class encapsulates the connection to the X server.
It provides the conduit for retrieving events from the server and for
converting X errors into exception objects that Minx's Python core can
handle.

<h3>minxlib::window and minxlib::root_window</h3>

This class encapsulates an X window, taking care of the details of
specifying X event masks and setting up key bindings. It also provides


various window-related operations such as showing, hiding, resizing,
moving, focusing, etc.

The <tt>root_window</tt> class is derived from <tt>minxlib::window</tt>
and provides an encapsulation of X's root windows, taking into account
support for Xinerama. Minx provides one <tt>root_window</tt> for each
physical screen. If Xinerama is active, there'll only be one logical
screen; however, Minx will return multiple <tt>root_window</tt> objects,
each with the same X ID but different geometries.

<h3>minxlib::event and minxlib::exception</h3>

These two classes provide an object-oriented interface to X events and
errors.  Different types of events are converted into instances of
subclasses of <tt>minxlib::event</tt>. Similarly, different kinds of
errors are converted into instances of classes derived from

Changes to wiki/home.wiki.

1
2
3
4
5
6
7
8
9
10

11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

39
40
41
42
43
44
45
46
<title>Home</title>

<h1>About Minx</h1>

Minx is a tiling X window manager. Here are some of its main features and design
goals:

  *  <b>Minimalism:</b> Minx does not put any decorations on or around top-level
     windows except for a simple border. It also does not support task bars,
     panels, icons, menus, etc. All it does is implement window layout policies

     that can be tailored to meet personal tastes.

  *  <b>Customizability:</b> Minx provides hooks into each and every aspect of
     its operation so that end-users can alter its behaviour to match their
     exact workflow.

  *  <b>Extensibility:</b> Functionality not in the Minx core can be added with
     minimal effort. For example, the bookmarks feature (aka workspaces),
     although part of the core distribution, is, in fact, implemented by taking
     advantage of Minx's ability to add arbitrary state to the window manager
     object. In a similar vein, new layouts are quite straightforward to
     implement.

  *  <b>Ease of use:</b> The default configuration (hopefully) provides a
     reasonable out-of-the-box experience (albeit different from full-blown
     desktop environments such as GNOME or KDE and, of course, subject to the
     constraints imposed by the desire to remain minimal). However, changing the
     defaults is easy.

  *  <b>Keyboard centrism:</b> All of Minx's actions can be accessed from the
     keyboard, including window resizing and moving with as few as 4-5
     keystrokes. The mouse, however, is supported.

  *  <b>Documentation:</b> Minx has no [#documentation|dark corners]. For users,
     there are plenty of how-to's explaining common as well as not-so-common
     configuration tasks. For developers, the code contains comments explaining
     intent, rationale, etc. There are also Wiki pages providing design
     overviews, explaining how the code is structured, why it is that way, and,

     also, the development methodology (branching policy, etc.).

Enjoy.

<h1>News</h1>







|
|

|
|
|
>
|

|
|
|

|
|
|
|
|
|


|
|
|
|

|
|
|

|
|
|
|
|
>
|







1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
<title>Home</title>

<h1>About Minx</h1>

Minx is a tiling X window manager. Here are some of its main features and
design goals:

  *  <b>Minimalism:</b> Minx does not put any decorations on or around
     top-level windows except for a simple border. It also does not
     support task bars, panels, icons, menus, etc. All it does is
     implement window layout policies that can be tailored to meet
     personal tastes.

  *  <b>Customizability:</b> Minx provides hooks into each and every
     aspect of its operation so that end-users can alter its behaviour to
     match their exact workflow.

  *  <b>Extensibility:</b> Functionality not in the Minx core can be
     added with minimal effort. For example, the bookmarks feature (aka
     workspaces), although part of the core distribution, is, in fact,
     implemented by taking advantage of Minx's ability to add arbitrary
     state to the window manager object. In a similar vein, new layouts
     are quite straightforward to implement.

  *  <b>Ease of use:</b> The default configuration (hopefully) provides a
     reasonable out-of-the-box experience (albeit different from
     full-blown desktop environments such as GNOME or KDE and, of course,
     subject to the constraints imposed by the desire to remain minimal).
     However, changing the defaults is easy.

  *  <b>Keyboard centrism:</b> All of Minx's actions can be accessed from
     the keyboard, including window resizing and moving with as few as
     4-5 keystrokes. The mouse, however, is supported.

  *  <b>Documentation:</b> Minx has no [#documentation|dark corners]. For
     users, there are plenty of how-to's explaining common as well as
     not-so-common configuration tasks. For developers, the code contains
     comments explaining intent, rationale, etc. There are also Wiki
     pages providing design overviews, explaining how the code is
     structured, why it is that way, and, also, the development
     methodology (branching policy, etc.).

Enjoy.

<h1>News</h1>



Changes to wiki/img/object_diagram.dot.

29
30
31
32
33
34
35
36
37
38
39
40

41




42
43
44

45
46
47
48
49
50




51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66





67
68
69
70
71
72
73
*/

//----------------------------- DIAGRAM --------------------------------

graph minx_main {
    // minx.core objects
    wm          [label = "minx.core.wm"         ]
    window      [label = "minx.core.window"     ]
    focus_list  [label = "minx.core.focus_list" ]
    xevents     [label = "minx.core.xevents"    ]
    hooks       [label = "minx.core.hooks"      ]
    config      [label = "minx.core.config"     ]






    // minxlib objects
    minxlib_display     [label = "minxlib::display"  ]
    minxlib_window      [label = "minxlib::window"   ]

    minxlib_event       [label = "minxlib::event"    ]
    minxlib_keymap      [label = "minxlib::keymap"   ]
    minxlib_exception   [label = "minxlib::exception"]
    minxlib_logging     [label = "minxlib::logging"  ]

    // Connections between minx.core objects and also to minxlib objects




    wm -- hooks
    wm -- config
    wm -- focus_list -- window -- minxlib_window
    wm -- xevents -- window
    wm -- window
    wm -- minxlib_display

    // Internal connections inside minxlib
    minxlib_display   -- minxlib_event
    minxlib_display   -- minxlib_window
    minxlib_display   -- minxlib_exception
    minxlib_window    -- minxlib_keymap -- minxlib_event
    minxlib_display   -- minxlib_logging
    minxlib_window    -- minxlib_logging
    minxlib_event     -- minxlib_logging
    minxlib_exception -- minxlib_logging





}

//----------------------------------------------------------------------

/**********************************************/
/* Editor config:                             */
/**********************************************/







<




>

>
>
>
>

|
|
>
|
|
|
|

|
>
>
>
>


<
<
|
<


<
<
<
<
<
<
<
|
>
>
>
>
>







29
30
31
32
33
34
35

36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61


62

63
64







65
66
67
68
69
70
71
72
73
74
75
76
77
*/

//----------------------------- DIAGRAM --------------------------------

graph minx_main {
    // minx.core objects
    wm          [label = "minx.core.wm"         ]

    focus_list  [label = "minx.core.focus_list" ]
    xevents     [label = "minx.core.xevents"    ]
    hooks       [label = "minx.core.hooks"      ]
    config      [label = "minx.core.config"     ]
    layman      [label = "minx.core.layman"     ]

    // minx.layout objects
    base [label = "minx.layout.base"]
    full [label = "minx.layout.full"]

    // minxlib objects
    display     [label = "minxlib::display"    ]
    window      [label = "minxlib::window"     ]
    rwindow     [label = "minxlib::root_window"]
    event       [label = "minxlib::event"      ]
    keymap      [label = "minxlib::keymap"     ]
    exception   [label = "minxlib::exception"  ]
    logging     [label = "minxlib::logging"    ]

    // Connections between minx.core, minx.layout, and minxlib objects
    wm -- layman -- base -- full
    wm -- display --event
    wm -- xevents -- base -- window
    wm -- focus_list -- window
    wm -- hooks
    wm -- config


    wm -- rwindow


    // Internal connections inside minxlib







    display -- window -- rwindow -- logging
    display -- exception
    window  -- keymap -- event -- logging
    display -- logging
    window  -- logging
    keymap  -- logging
}

//----------------------------------------------------------------------

/**********************************************/
/* Editor config:                             */
/**********************************************/

Changes to wiki/img/object_diagram.png.

cannot compute difference between binary files

Changes to wiki/process.wiki.

1
2
3
4
5
6
7

8
9
10
11
12
13
14
15
16

17
18
19
20
21

22
23
24
25
26
27
28
29

30
31
32
33
34
35
36
37
38
39
40
41
42

43
44
45
46
47
48
49
50
51
52
53
54
55
56

57
58
<title>Development Process</title>

<h1>About this Page</h1>

Minx is not a large project. In all likelihood, I will be the only developer and
its only user (well, there may be at most a handful of others who might use it).
Given that, the project is not well-served by a heavy-duty process and nor does

it have one. However, there is some method to the madness...

<hr>

<h1>Development and Branching Policy</h1>

<b>dev1.x</b> is the main development branch. Usually, development will proceed
linearly on this branch. However, if there are others contributing to the
project and/or there is a major feature that will continue for a while, we will

create feature branches off off <b>dev1.x</b>. When the feature is done, the
branch will be merged onto <b>dev1.x</b> and then, usually, closed.

<b>rel1.x</b> is the release branch. When we are ready to make a release, we
will merge from <b>dev1.x</b> and then tag (after tweaking as required).


<h2>Release-only Artifacts</h2>

There are certain things that live only on the release branch. For example, the
version numbering API, the changelog, release notes, and so on. These things are
never merged into the development branches. Consequently, no development ever
occurs on the <b>rel1.x</b> branch. We only merge to <b>rel1.x</b>, never from
it to <b>dev1.x</b> or some other branch.


<h3>Hotfixes</h3>

If we find a bug on <b>rel1.x</b> that needs an urgent fix, we will branch off
off <b>dev1.x</b> at the point where that particular release was made, apply the
fix on this "hotfix" branch and then merge the hotfix branch to both
<b>dev1.x</b> and <b>rel1.x</b> (tagging the release by increasing the version
number's patch level).

Although this approach is a little more complicated and results in a slightly
messier revision history, it allows us to maintain certain release-only items
(changelog, version numbering API, etc.) solely on <b>rel1.x</b> without
accidentally getting them onto a development branch (where they do not belong).


<hr>

<h1>Making a Release</h1>

  #  Merge from <b>dev1.x</b> to <b>rel1.x</b>.
  #  Build and test.
  #  Build API docs and check-in.
  #  Replace all <em>ckout</em> in docs with <em>rel1.x</em>.
  #  Update <em>wiki/changelog.wiki</em> and <em>wiki/relnotes.wiki</em>.
  #  Update <b>News</b> section of <em>wiki/home.wiki</em> plus any other docs
     that need updating.
  #  Update version number in <tt>minxlib/version.cc</tt> and commit --tag as
     vA.B.C (where major number A, minor number B, and patch level C all match

     the new version number assigned in <tt>minxlib/version.cc</tt>).
  #  Push to [http://chiselapp.com|chiselapp].




|
|
|
>
|





|
|
|
>
|
|

|
|
>



|
|
|
|
|
>



|
|
|
|
|

|
|
|
|
>










|
|
|
|
>
|

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
<title>Development Process</title>

<h1>About this Page</h1>

Minx is not a large project. In all likelihood, I will be the only
developer and its only user (well, there may be at most a handful of
others who might use it). Given that, the project is not well-served by a
heavy-duty process and nor does it have one. However, there is some
method to the madness...

<hr>

<h1>Development and Branching Policy</h1>

<b>dev1.x</b> is the main development branch. Usually, development will
proceed linearly on this branch. However, if there are others
contributing to the project and/or there is a major feature that will
continue for a while, we will create feature branches off off
<b>dev1.x</b>. When the feature is done, the branch will be merged onto
<b>dev1.x</b> and then, usually, closed.

<b>rel1.x</b> is the release branch. When we are ready to make a release,
we will merge from <b>dev1.x</b> and then tag (after tweaking as
required).

<h2>Release-only Artifacts</h2>

There are certain things that live only on the release branch. For
example, the version numbering API, the changelog, release notes, and so
on. These things are never merged into the development branches.
Consequently, no development ever occurs on the <b>rel1.x</b> branch. We
only merge to <b>rel1.x</b>, never from it to <b>dev1.x</b> or some other
branch.

<h3>Hotfixes</h3>

If we find a bug on <b>rel1.x</b> that needs an urgent fix, we will
branch off off <b>dev1.x</b> at the point where that particular release
was made, apply the fix on this "hotfix" branch and then merge the hotfix
branch to both <b>dev1.x</b> and <b>rel1.x</b> (tagging the release by
increasing the version number's patch level).

Although this approach is a little more complicated and results in a
slightly messier revision history, it allows us to maintain certain
release-only items (changelog, version numbering API, etc.) solely on
<b>rel1.x</b> without accidentally getting them onto a development branch
(where they do not belong).

<hr>

<h1>Making a Release</h1>

  #  Merge from <b>dev1.x</b> to <b>rel1.x</b>.
  #  Build and test.
  #  Build API docs and check-in.
  #  Replace all <em>ckout</em> in docs with <em>rel1.x</em>.
  #  Update <em>wiki/changelog.wiki</em> and <em>wiki/relnotes.wiki</em>.
  #  Update <b>News</b> section of <em>wiki/home.wiki</em> plus any other
     docs that need updating.
  #  Update version number in <tt>minxlib/version.cc</tt> and commit --tag
     as vA.B.C (where major number A, minor number B, and patch level C
     all match the new version number assigned in
     <tt>minxlib/version.cc</tt>).
  #  Push to [http://chiselapp.com|chiselapp].

Changes to wiki/todo.wiki.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

15
16
17
18
19
20
21
22
23
24
25
26



<title>TODO</title>

<h1>Current TODO List</h1>

To get to [/doc/dev1.x/wiki/milestones.wiki#v01x|version 0.1.6], the
following tasks have to be completed:

<h2>DONE</h2>

  *  To make key bindings more Emacs-like, add support for treating 'A'
     as short-hand for ALT and 'M' as META.

  *  Move focus changing logic from <tt>minx.core.xevents.on_key_press()</tt>
     to <tt>minx.core.wm.focus_next()</tt> and <tt>focus_prev()</tt>.


  *  Remove hard-coded <tt>F1</tt> for focus cycling and test defaults
     (i.e., M1-Tab and S-M1-Tab). Also: customize key bindings (F1 and
     S-F1 for focusing instead of defaults).

  *  There should be a way to disable/replace existing/default key
     bindings.

  *  Document this unholy mess: Doxygen for code, HOWTO describing
     key bindings, updated FAQ, etc.

<h2>PENDING</h2>







|




|
<

<
<
>

<
<
<
<
<
<
<
<
<
<

>
>
>
1
2
3
4
5
6
7
8
9
10

11


12
13










14
15
16
17
<title>TODO</title>

<h1>Current TODO List</h1>

To get to [/doc/dev1.x/wiki/milestones.wiki#v02x|version 0.2.0], the
following tasks have to be completed:

<h2>DONE</h2>

  *  Update design notes.




  *  Update home page.











<h2>PENDING</h2>

  *  Add rectangle to full constructor. Test by leaving some space on the
     right on the right monitor of a dual-monitor test.