[Webkit-unassigned] [Bug 26103] [GTK] Remove gtk/cairo/pango/freetype/fontconfig includes from the header files in WebCore

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Jun 1 19:12:32 PDT 2009


https://bugs.webkit.org/show_bug.cgi?id=26103





------- Comment #6 from zecke at selfish.org  2009-06-01 19:12 PDT -------
(In reply to comment #5)
> Disclaimer: I am not a WebKit developer.
> 
> First of all, sorry for misunderstanding the purpose of your patch.
> 
> But I do dislike your patch since it breaks the proper abstractions.
> An example:

Okay, I think you are slightly off again + my description not being too good.
My goal is to not have any glib/glib.h, cairo.h in WebCore header files as this
is increasing compile times (see this simple patch can save quite some time).

Way to get there include:
  - use forward declarations... and they are typesafe, e.g. if I declare
typedef struct _GtkEntry GtkWidget the compiler will shout at me.

  - do not use Glib types when not necessary. Using unsigned long long was a
bit too much to store the value 8192, so an updated patch will use unsigned.
See how I just didn't do typedef unsigned long gsize?

  - Create "convertable" types and this is where I expected discussion. :)


Why abstraction is not broken. The ResourceHandleClient::didReceiveData and
other parts using size in WebCore do not use gsize. So we already have a place
when going from gsize to int (and so far it is safe as we only read about to
8k), moving the frontier does not break the abstraction...


> But not on my x86 Linux machine (with a 64bit userspace it's "unsigned long",
> and with a 32bit userspace it's "unsigned int").

I assume you mean GNU/Linux and GNU userspace (gcc, glibc)?


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list