Re: [webkit-dev] WebKit and Freetype

2008-11-17 Thread Oliver Dole
Hello,

Of course that's possible. You can find a sample implementation here:
http://www.sand-labs.org/owb/browser/trunk/BAL/WKAL/Concretizations/Fonts/Freetype
Just replace SDL calls by some cairo calls in draw_glyphs() method and that
should be ok.

Regards

On 11/17/08, haithem rahmani [EMAIL PROTECTED] wrote:

 Hi all,
 Please forgive me if my question has been already discussed.

 To show Text is it possible, for platforms with freetype backend, to call
 the freetype api directly instead of using the cairo_show_glyphs api?

 regards.

 haithem.



 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




-- 
Olivier DOLE
Pleyo
Software Engineer
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] webkit

2008-08-28 Thread Oliver Dole
Hello,

On 8/28/08, nishit sharma [EMAIL PROTECTED] wrote:
 Hi All,

 i have posted this before but didn't get the reply thats why i am posting
 again.

 After running WebKit i am stucking at
 WebKitWebView* webView =
 WEBKIT_WEB_VIEW(g_object_new(WEBKIT_TYPE_WEB_VIEW, NULL));
   function whose defintion i am not getting in the source code and due to
 this i am unable to do any progress.
 The function called after this are never called because WebKit hangs in this
 function.
Well 2 possibilities:
- first: that's due to WEBKIT_WEB_VIEW macro which in fact simply
calls G_TYPE_INSTANCE_GET_PRIVATE macro from glib.
- second: that's due to g_object_new which is also a glib function.
So in every case, it does not seem to be a specific webkit issue, but
a glib one. So if you want more info about why it hangs, you will have
to recompile glib in debug mode.

Regards,


 Somebody please help me in telling where is the definition available so that
 i can move ahead this stucked point.

 Thanks and Regards
 Nishit Sharma

 ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




-- 
Olivier DOLE
Pleyo
Software Engineer
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving away from qmake

2007-11-12 Thread Oliver Dole
Hello,

Here is my experience with cmake, so I hope it may help you to decide
which build system is the best for you.
Its first advantage is that it is cross platform. So you can imagine
in a long term approach to have a unified build system between
GTK/Qt/Wx/Win and mac.
Another advantage is that it is from my point of view quite simple to
understand and to use for basic stuff like adding a library dependency
to the build. Moreover there are many ready to use macro to ease this
work. As an example, if you want to add a dependency with JPEG
library, use FindJPEG module and it will store useful info in
variables like JPEG_LIBRARIES.
About documentation, well simply have a look at
http://www.cmake.org/HTML/Documentation.html page, it should convince
you.
Another feature I like are curses interfaces for your project
configuration (you can switch options, compiler flags and even
compiler). And of course you do not have to rebuild the whole project
each time you modify things. And if things are done correctly you do
not even have to rebuild the whole project when you add a new feature.
Imagine that you have built WebKit/GTK without SVG support and you
want to add it. It can simply recompile svg missing .o and of course
redo linking. Of course that's not true if you switch from a debug
build option to a release build.
Of course from time to time you may have to rebuild the whole project
because you have modify things in cmake config files.
Another insteresting features is that cmake allow you to create a
build directory where will be stored all your object files. So your
source tree remains clean.
About drawbacks, the main is about cross-compilation. I know that
cmake guys work on this issue but currently I still have to do ugly
things when I cross compile webkit because of dftables. As a matter of
fact dftables is also cross-compiled and when you try to run an ARM
dftables exec on a x86 arch, it cannot work. But I hope I will be able
to fix this soon. The more people are involved in Cmake process, the
more we get chances to overcome these little issues.
The other drawback you can have is that you will have to
compile/install cmake when you are in a scratchbox environment.
And if you want to give a try to cmake alternative, let me know, I can
provide you files to compile WebCore/JavascriptCore with cmake. And I
can also try to help you to meet your goal.

Regards,

 De : Alp Toker [EMAIL PROTECTED]
 Date : 12 novembre 2007 04:34:48 HNEC
 À : [EMAIL PROTECTED]
 Objet : [webkit-dev] Moving away from qmake

  The existing qmake-based build system is shared by the GTK+ and Qt ports.

 Until recently, this arrangement has not been too problematic for the
 GTK+ porters, with the idea being that qmake makes life easier for
 developers at the expense of a little inconvenience for users (in the
 sense of application developers rather than end users).

 However, it has recently become clear that qmake is actually making life
 more difficult for developers. It turns out that the existing qmake
 build system fails to do basic dependency tracking, leaving both
 developers and users with crashy builds, with the only way to get a
 stable build being to do a full clean and rebuild after every update.

 In the last week I've had to explain why people's builds are crashing to
 maybe half a dozen people on WebKit and GNOME-related channels.

 Mark and I have attempted to fix the dependency tracking a number of
 times, but we've both found qmake to be poorly documented, and our
 attempts to fix it ended up breaking the build even more in certain
 configurations. My informal attempts to get assistance from the
 Trolltech guys doing the Qt port have gone unanswered. I have no doubt
 that we would be able to fix these issues in a matter of minutes using a
 better understood or documented build system.

 Moreover, it has turned out that the qmake build dependency is more than
 just a little inconvenience for users. It makes the GTK+ port
 inaccessible to a lot of developers. Using anything but the latest Linux
 distributions, including cross-compilation frameworks like Scratchbox,
 you have to build the whole of Qt just to get qmake, which takes over an
 hour and almost a gigabyte of disk space for me. That's at least 5 times
 as long as it takes to build the whole of JavaScriptCore, WebCore and
 WebKit. Even in distributions that ship a recent binary of qmake, it is
 often bundled into the same binary package as the rest of Qt, making it
 a seriously large dependency.

 Now that the GTK+ port is getting attention from beyond a core team of
 developers, I think such a heavy build dependency is no longer acceptable.


 If either the Wx or Qt porters are willing to share a new build system
 with the GTK+ port, they should speak up now. We're willing to consider
 any build system that does not incur a huge dependency (ruling out
 qmake) and that is actively maintained and does not have verbose XML
 makefiles (ruling out Bakefile and