On 1/3/06, Kent Sandvik <[EMAIL PROTECTED]> wrote: > On 1/2/06, Mike Emmel <[EMAIL PROTECTED]> wrote: > > > Yep that will be intresting. I've also been doing a bit of campaining > > to get XUL ported to WebKit which offers another viable approach > > to rich xml apps. Also Nokia ported support for Mozilla plugins this is > > supposed > > to go open source soon if not already. I need to look a little deeper > > at dashboard. > > I looked at the soundbird project, trying to build something like > iTunes using XML, and I'm not that impressed with all the hacks they > had to do to get it working. > I can't find a link for this project so not sure what to say without looking at it.
> > Its still pretty large I've not seen the numbers now but considering > > the time factor for the port > > its got to be similar to the open GTK port around 6 meg footprint. > > The biggest size issue is it as and extensive QT emulation layer > > still. Intresting if your want to support QT on top of GTK but not > > really needed. I don't think this will last forever its one of the big > > things apple want to remove and one of the main reasons that WebKit > > and KHTML are now different projects. > > The QT layer is not that big, and as you said Apple is working on removing it. > > > I personally think WebKit is quite a viable browser today and its much > > smaller then Mozilla. > > Having trashed using LiTE for mozilla. For WebKit I think it would be > > a good project. > > I think I can get the current gtk port of Webkit to work very quickly > > under directfb probably just a few days it not a big project. > > The earlier GTK-Nokia port is indeed up on their CVS depot, but I > suspect you need to work on things in the WebKit layer as their port > happened months ago, and the code base has moved on. > True but it should be fairly easy to bring in the newer code as needed. The same as I do for gtk right now. It basically a 2-5 days of work every 3-4 months to stay current. > I still think we should bypass the whole GTK level, it's a proof of > concept but not a viable solution for an embedded system (Glib, memory > hog, too many objects). --Kent > I agree for WebKit its small enough that removing gtk is a viable option. I'm going to go ahead and get the WebKit gtk port running under gtk/directfb I think I can do it in less then a day plus it will be a good debug app for gtk :) I'll check it in once I get it to work. We can move all the core rendering to directfb and cairo. You might be able to make it work without cairo but there a quite a few graphics operations not supported I think by plain DirectFB in any case the can be resolved after you have the Cairo port. In any case we would need to look in detail at what qcanvas provides and what is actually used. It would be nice to have a basic qcanvas that works without cairo then have the cairo based one optional. Once the browser is rendering without gtk then the lite port can start working. For the gtk port the browser directfb window can be wrapped using the api to create a gdk window from and existing directfb window. I assume it would be easy to do the same in lite. WebKit already gets its widgets from a factory so that should not be a problem. > _______________________________________________ > directfb-dev mailing list > [email protected] > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
