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.

2 files changed, 30 insertions, 5 deletions

diff --git a/ChangeLog b/ChangeLog
index 60fcff3b..22b7b853 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+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.
+
 2006-04-13  Alejandro Andres <fuzzy.alej@gmail.com>
 
 	* README: Fixed broken links.  #333303
diff --git a/HACKING b/HACKING
index 3887ac76..6f3bf25f 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.