summaryrefslogtreecommitdiff
path: root/HACKING
diff options
context:
space:
mode:
authorElijah Newren <newren gmail com>2006-04-14 17:36:17 +0000
committerElijah Newren <newren@src.gnome.org>2006-04-14 17:36:17 +0000
commit1dea155c8c7b18366ee38c25224066df67f63049 (patch)
tree8b8e1493a4a15fc03726526b501d3577592445e3 /HACKING
parent694a4352bc9fe04608a7f457d53fe676026b9748 (diff)
downloadmetacity-1dea155c8c7b18366ee38c25224066df67f63049.tar.gz
metacity-1dea155c8c7b18366ee38c25224066df67f63049.tar.bz2
Include reasons why gdk/gtk.h and core includes like display.h/window.h
2006-04-14 Elijah Newren <newren gmail com> * HACKING: Include reasons why gdk/gtk.h and core includes like display.h/window.h must be kept separate. Taken from a private email from Havoc.
Diffstat (limited to 'HACKING')
-rw-r--r--HACKING29
1 files changed, 24 insertions, 5 deletions
diff --git a/HACKING b/HACKING
index 3887ac7..6f3bf25 100644
--- a/HACKING
+++ b/HACKING
@@ -197,11 +197,30 @@ Debugging information
of window without launching a full desktop.
Technical gotchas to keep in mind
- 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.
+ 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. Reasons:
+
+ "Basically you don't want GDK most of the time. It adds
+ abstractions that cause problems, because they aren't designed to
+ be used in a WM where we do weird stuff (display grabs, and just
+ being the WM). At best GDK adds inefficiency, at worst it breaks
+ things in weird ways where you have to be a GDK guru to figure
+ them out. Owen also told me that they didn't want to start adding
+ a lot of hacks to GDK to let a WM use it; we both agreed back in
+ the mists of time that metacity would only use it for the "UI"
+ bits as it does.
+
+ Having the split in the source code contains and makes very clear
+ the interface between the WM and GDK/GTK. This keeps people from
+ introducing extra GDK/GTK usage when it isn't needed or
+ appropriate. Also, it speeds up the compilation a bit, though this
+ was perhaps more relevant 5 years ago than it is now.
+
+ There was also a very old worry that the GDK stuff might have to
+ be in a separate process to work right; that turned out to be
+ untrue. Though who knows what issues the CM will introduce."
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.