Check-in [d8eada88df]
Not logged in

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

Overview
Comment:Replaced ckout with rel1.x in documentation prior to 0.2.0 release.
Timelines: family | ancestors | descendants | both | rel1.x
Files: files | file ages | folders
SHA1:d8eada88dfb15395bfa3133da3857fb2c776e899
User & Date: manuv 2013-08-04 19:39:34
Context
2013-08-04
21:30
  • Updated changelog, release notes, home page, and version.
  • Tagged as v0.2.0.
Leaf check-in: 006f915258 user: manuv tags: rel1.x, v0.2.0
19:39
Replaced ckout with rel1.x in documentation prior to 0.2.0 release. check-in: d8eada88df user: manuv tags: rel1.x
10:54
Added new documentation to version control. check-in: 8561cd9213 user: mvnathan tags: rel1.x
Changes

Changes to wiki/design.wiki.

47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

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>







|







47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

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/rel1.x/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>

Changes to wiki/hooks-list.wiki.

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
...
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
Minx triggers these hooks to allow end-users to customize how the window
manager responds to different events.

<a name="init_hook"></a>
<h2>init_hook</h2>

When you start Minx (by calling the
[/doc/ckout/api/classminx_1_1core_1_1wm_1_1wm.html|wm] object's start
method), it goes through the following sequence of steps:

  #  Connect to the X server
  #  Configure X event masks and key bindings
  #  Trigger the init hook
  #  Manage existing windows
  #  Initiate the X event loop
................................................................................

The intent of the init hook is to allow you to insert some custom
initialization before Minx starts managing windows and processing events
but after it has obtained a valid X connection. When the init hook is
called, you can be sure that the <tt>wm</tt> object's <tt>display</tt>
and <tt>root_windows</tt> attributes are available to you. The
<tt>display</tt> attribute is an instance of the
[/doc/ckout/api/classminxlib_1_1display.html|<tt>minxlib::display</tt>]
class and isn't something you would usually need to deal with directly.
However, <tt>wm.root_windows</tt> is almost certainly an attribute of
interest: it contains a list of
[/doc/ckout/api/classminxlib_1_1root__window.html|<tt>minxlib::root_window</tt>]
objects, one for each physical screen you have.

Typically, in the init hook, you will create layouts for each screen as
shown below:

<verbatim>
    #!/usr/bin/env python
................................................................................
    wm.start()
</verbatim>

The above example returns a new gimp layout for the first Gimp window and
reuses that layout for subsequent windows that Gimp creates. For all
other window types, it returns nothing, which makes Minx use its default
policies for layout selection (read all about that on the
[/doc/ckout/api/classminx_1_1core_1_1layman_1_1layman.html|layout
manager's API page]).

Please note that there is no gimp layout. Thus, the above code won't
actually work; it is only meant to illustrate how the receptive layout
hook is meant to be used.

<hr>







|







 







|



|







 







|







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
...
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
Minx triggers these hooks to allow end-users to customize how the window
manager responds to different events.

<a name="init_hook"></a>
<h2>init_hook</h2>

When you start Minx (by calling the
[/doc/rel1.x/api/classminx_1_1core_1_1wm_1_1wm.html|wm] object's start
method), it goes through the following sequence of steps:

  #  Connect to the X server
  #  Configure X event masks and key bindings
  #  Trigger the init hook
  #  Manage existing windows
  #  Initiate the X event loop
................................................................................

The intent of the init hook is to allow you to insert some custom
initialization before Minx starts managing windows and processing events
but after it has obtained a valid X connection. When the init hook is
called, you can be sure that the <tt>wm</tt> object's <tt>display</tt>
and <tt>root_windows</tt> attributes are available to you. The
<tt>display</tt> attribute is an instance of the
[/doc/rel1.x/api/classminxlib_1_1display.html|<tt>minxlib::display</tt>]
class and isn't something you would usually need to deal with directly.
However, <tt>wm.root_windows</tt> is almost certainly an attribute of
interest: it contains a list of
[/doc/rel1.x/api/classminxlib_1_1root__window.html|<tt>minxlib::root_window</tt>]
objects, one for each physical screen you have.

Typically, in the init hook, you will create layouts for each screen as
shown below:

<verbatim>
    #!/usr/bin/env python
................................................................................
    wm.start()
</verbatim>

The above example returns a new gimp layout for the first Gimp window and
reuses that layout for subsequent windows that Gimp creates. For all
other window types, it returns nothing, which makes Minx use its default
policies for layout selection (read all about that on the
[/doc/rel1.x/api/classminx_1_1core_1_1layman_1_1layman.html|layout
manager's API page]).

Please note that there is no gimp layout. Thus, the above code won't
actually work; it is only meant to illustrate how the receptive layout
hook is meant to be used.

<hr>