brl/mutter
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Include reasons why gdk/gtk.h and core includes like display.h/window.h

Browse Source 
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.
This commit is contained in:
Elijah Newren 2006-04-14 17:36:17 +00:00 committed by Elijah Newren
parent 694a4352bc
commit 1dea155c8c
2 changed files with 29 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
ChangeLog
View File

@ -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

27
HACKING
View File

@ -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 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:
Files in the core (display.[hc], window.[hc]) are not supposed to include
gdk.h or gtk.h.
"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.