summaryrefslogtreecommitdiff
path: root/HACKING
blob: d89dddb5d9995add636997c61b30469069bb83d0 (plain)
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
65
66
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
Making a release
===

To make a release of metacity, do the following:

 - check out a fresh copy from CVS

 - increment the version number in configure.in, 
   see the comment above the version for the next fibonacci number

 - update the file NEWS based on the ChangeLog

 - add a ChangeLog entry containing the version number 
   you're releasing ("Released 2.5.4" or something)
   so people can see which changes were before and after
   a given release.

 - "make distcheck" (DO NOT just "make dist" - pass the check!)

 - if make distcheck fails, fix it.

 - once distcheck succeeds, "cvs commit"

 - if someone else made changes and the commit fails, 
   you have to "cvs up" and run "make distcheck" again

 - once the commit succeeds, WITHOUT cvs updating, "cvs tag
   METACITY_X_Y_Z" where
   X_Y_Z map to version X.Y.Z

 - scp the tarball to master.gnome.org

 - run install-module on master.gnome.org to install the tarball 
   on the ftp site

Misc stuff
===

Don't commit substantive code in here without asking me,
hp@redhat.com.  Adding translations, no-brainer typo fixes, etc.  is
fine.

The script src/run-metacity.sh is useful to hack on the window manager. 
It runs metacity in an Xnest. e.g.:
 CLIENTS=3 ./run-metacity.sh
or 
 DEBUG=memprof ./run-metacity.sh
or
 DEBUG_TEST=1 ./run-metacity-sh
or whatever.

The tool metacity-message can be used as follows:
 metacity-message reload-theme
 metacity-message restart
 metacity-message enable-keybindings
 metacity-message disable-keybindings

metacity-window-demo is good for trying behavior of various kinds of window
without launching a full desktop.

src/window.c is where all the guts of the window manager live. This is
basically the only remotely scary file.

src/frames.c is the GtkWidget that handles drawing window frames.

src/core.h defines the interface used by the GTK portion of the window
manager to talk to the other portions. There's some cruft in here
that's unused, since nearly all window operations have moved out of
this file so frameless apps can have window operations.

src/ui.h defines the interface the plain Xlib portion of the window
manager uses to talk to the GTK portion.

Files that include gdk.h or gtk.h are not supposed to include
display.h or window.h or other core files.

Files in the core (display.[hc], window.[hc]) are not supposed to
include gdk.h or gtk.h.

src/theme.c and src/theme-parser.c have the theme system; this is
well-modularized from the rest of the code, since the theme viewer app
links to these files in addition to the WM itself.

When hacking, remember that you can have multiple screens. The code is
also written to support multiple displays, but this is useless, since
you can just run two copies of the WM. Also, an XKillClient() or
shutdown on any display causes Xlib to exit the app, so it would be
broken. So the multi-display thing is mostly just for code
cleanliness.  Multi-screen on the other hand is important for some
people.

Remember that strings stored in X properties are not in UTF-8, and
they have to end up in UTF-8 before we try putting them through Pango.

If you make any X request involving a client window, you have to
meta_error_trap_push() around the call; this is not necessary for 
X requests on the frame windows.

Remember that not all windows have frames, and window->frame can 
be NULL.

The code could use cleanup in a lot of places, feel free to do so.