Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?
On Tue, Aug 1, 2017 at 7:54 PM, Maciej Stachowiak <m...@apple.com> wrote: > Chromium Embedded Framework is an obvious comparison project for use cases > like that. CEF is arguably more popular as a bundled engine than WebKit, so > we probably don't need more flexibility than they provide. Does CEF let you > compile out video support? not sure, but they do offer the video pipeline internally via ffmpeg... thus it's not spread across ports as we do. Similar cases come from rendering system, they force one and thus remove some options because all ports will implement a feature, unlike here where most features are port-dependent. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN, GTalk, FaceTime: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (16) 99354-9890 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit opengl
On Tue, Aug 1, 2017 at 6:44 PM, Michael Catanzaro <mcatanz...@igalia.com> wrote: > > On Tue, Aug 1, 2017 at 9:13 PM, Nagendra K <pingnagen...@gmail.com> wrote: > > Hi Dean, > > Thanks for the reply. > I actually have a embedded device with opengl es 1.1 and WebKit which is 7 > years old, now requirement is to update the WebKit using the same opengles1.1 > i.e. no option to update opengles1.1. > So as you said we need opengles2 or opengl4 to upgrade WebKit as WebKit has > dependencies with opengl for some features. Is this correct? > Do I any other option to do this. > > Thanks and Regards, > Nagendra > > > Hi Nagendra, > > You are not going to get WebKit working with OpenGLES 1.1 unless you have an > experienced engineer making large modifications to the source code. Instead, > you should just turn off OpenGL/OpenGLES support. Just build with > -DENABLE_OPENGL=OFF. It is optional, you just lose hardware acceleration. You > should hopefully have no trouble with this. > > If you have a requirement to use OpenGLES regardless, then you may need to > reevaluate the feasibility of your project. Indeed... we did such port for a customer based on WebKit-EFL (now out-of-tree) and it worked, but was a major pain to get there due CoordinatedGraphics and TextureMapper being heavy on GL calls... however in our case it was software rendering only, no GL at all. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN, GTalk, FaceTime: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (16) 99354-9890 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] EFL port?
On Wed, Feb 15, 2017 at 12:48 PM, Konstantin Tokarev <annu...@yandex.ru> wrote: > > > 15.02.2017, 17:18, "Gustavo Sverzut Barbieri" <barbi...@profusion.mobi>: >> On Wed, Feb 15, 2017 at 3:19 AM, Gyuyoung Kim <gyuyoung@webkit.org> >> wrote: >>> Hi, >>> >>> If there is no other active maintainer for EFL port, unfortunately I have >>> to >>> agree to drop EFL port in mainline >>> because EFL port should not be an obstacle. I will maintain WebKitEFL like >>> the QT port in >>> https://github.com/Gyuyoung/ewebkit and http://www.ewebkit.org. >> >> Okay, we can continue based on that. >> >> Just a small observation for your fork is to avoid releases to remove >> non-EFL port files like was done for 1.18, instead keep just our >> patchset on top and if you want to produce smaller archives just use >> git-archive ignore files (which can be in the git repo)... likely good >> to produce smaller downloads without layouttests and the likes. > > There is small but very useful script, Tools/gtk/make-dist.py. It allows to > remove > unwanted files by using patterns, listed in manifests file (like > Tools/gtk/manifest.txt.in) > > For Qt port I use this script both to make release tarballs and for snapshots > repo [1]. > This allows me to have full-fledged main repo with all tests and sources, and > users > can clone small snapshots repo to get latest updates. > > [1] https://github.com/annulen/qtwebkit-snapshots well, cpack could do that kind of stuff, no? I recall the first port of cmake used that. I'm not sure why Gyuyoung did that approach, likely to get the tarballs-from-git-tags feature of github in a lightweight mode... then using git-archive features may do (it's kinda of simple to blacklist tests stuff and slim the tarball to 50mb or so) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN, GTalk, FaceTime: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (16) 99354-9890 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] EFL port?
On Wed, Feb 15, 2017 at 3:19 AM, Gyuyoung Kim <gyuyoung@webkit.org> wrote: > Hi, > > If there is no other active maintainer for EFL port, unfortunately I have to > agree to drop EFL port in mainline > because EFL port should not be an obstacle. I will maintain WebKitEFL like > the QT port in > https://github.com/Gyuyoung/ewebkit and http://www.ewebkit.org. Okay, we can continue based on that. Just a small observation for your fork is to avoid releases to remove non-EFL port files like was done for 1.18, instead keep just our patchset on top and if you want to produce smaller archives just use git-archive ignore files (which can be in the git repo)... likely good to produce smaller downloads without layouttests and the likes. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN, GTalk, FaceTime: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (16) 99354-9890 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] EFL port?
yes, Sad, but as no big company is using the webkit-efl port at the time, we have no (or few?) guys paid to hack on it full time. My company is rather small, so we need backing customers to continue our work... like the current patchset to come. Not ideal, but if we could at least keep WebKit-EFL build bots and try to keep them green would be of great help for smaller users like us. On Tue, Feb 14, 2017 at 1:01 AM, Gyuyoung Kim <gyuyoung@webkit.org> wrote: > Hi, > > I agree that we should have enough people to keep EFL port on upstream. > > Unfortunately I guess there will be no enough people to maintain EFL port > even If I've done my internal work. > So, If other maintainers or volunteers put their hand up for EFL port, it > seems to me that EFL port has a time to go downstream. > > Gyuyoung. > > > On Tue, Feb 14, 2017 at 3:35 AM, Alex Christensen <achristen...@apple.com> > wrote: >> >> Are there enough people working on EFL that we could ping someone with a >> desired architecture improvement and have them do significant code redesign >> in a reasonable amount of time? We can add stubs and do minor things >> blindly, but sometimes bigger tasks require cooperation. For example, >> https://bugs.webkit.org/show_bug.cgi?id=167096 should also be done on the >> EFL WebGL implementation. >> >> On Feb 13, 2017, at 3:08 AM, Gustavo Sverzut Barbieri >> <barbi...@profusion.mobi> wrote: >> >> Hi guys, >> >> I have a small team working with WebKit-EFL as well, we're working on >> a different platform supported by EFL but not WebKit-EFL, so it's a >> series of minor patches to allow WebKit-EFL to run on Fbdev and >> without GL stack. >> >> Patches will reach bugs.webkit.org soon. >> >> >> On Sat, Feb 11, 2017 at 2:10 AM, Joonghun Park <sypjh0...@hotmail.com> >> wrote: >> >> Hi, Anders. >> >> >> You could count me as a member of EFL port too. >> >> I couldn't get in touch with EFL port because of some internal works, >> >> but I'm planning to work in it. >> >> >> Some other people of EFL port is in the same situation, but I think >> they'll >> get back sooner or later. >> >> >> >> - Joonghun (jh718.p...@samsung.com) >> >> >> >> >> >> From: webkit-dev-boun...@lists.webkit.org >> <webkit-dev-boun...@lists.webkit.org> on behalf of Anders Carlsson >> <ander...@apple.com> >> Sent: Friday, February 10, 2017 6:21 PM >> To: Gyuyoung Kim >> Cc: WebKit-Dev Development >> Subject: Re: [webkit-dev] EFL port? >> >> Hi, >> >> Are you the only one working on the EFL port? >> >> - Anders >> >> On Feb 10, 2017, at 1:40 AM, Gyuyoung Kim <gyuyoung@webkit.org> wrote: >> >> Hello, >> >> To be honest, very few people have worked for EFL port recently. In my >> case >> it was hard to maintain EFL port because of internal work. >> However I have a plan to improve EFL port after I finish the work. Even I >> opened a website for EWebKit. http://www.ewebkit.org. >> Besides I released EWebKit 1.18 version[1] for EFL 1.18 official release. >> Could you give me more time for EFL port ? >> >> Gyuyoung. >> >> >> [1] EWebKit 1.18 release announcement. >> >> >> https://phab.enlightenment.org/w/efl_and_elementary_1_18_release_announcement/ >> >> EWebkit >> >> Together with this release we are happy to announce that the EWebkit team >> is >> doing a >> release with their work matching the efl 1.18. >> It contains various webkit core as well as EWebkit specific enhancements. >> See the >> NEWS file for details and the http://www.ewebkit.org page for further >> instructions on >> building. We hope to keep future releases of EWebkit aligned with the EFL >> release schedule. >> >> >> >> >> >> >> >> On Fri, Feb 10, 2017 at 9:42 AM, Anders Carlsson <ander...@apple.com> >> wrote: >> >> >> Hello, >> >> Looks like the EFL port isn’t really being worked on anymore. Is this >> true? Can we rip it out? >> >> - Anders >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev >> >> >> >> >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >&g
Re: [webkit-dev] EFL port?
Hi guys, I have a small team working with WebKit-EFL as well, we're working on a different platform supported by EFL but not WebKit-EFL, so it's a series of minor patches to allow WebKit-EFL to run on Fbdev and without GL stack. Patches will reach bugs.webkit.org soon. On Sat, Feb 11, 2017 at 2:10 AM, Joonghun Park <sypjh0...@hotmail.com> wrote: > Hi, Anders. > > > You could count me as a member of EFL port too. > > I couldn't get in touch with EFL port because of some internal works, > > but I'm planning to work in it. > > > Some other people of EFL port is in the same situation, but I think they'll > get back sooner or later. > > > > - Joonghun (jh718.p...@samsung.com) > > > > > > From: webkit-dev-boun...@lists.webkit.org > <webkit-dev-boun...@lists.webkit.org> on behalf of Anders Carlsson > <ander...@apple.com> > Sent: Friday, February 10, 2017 6:21 PM > To: Gyuyoung Kim > Cc: WebKit-Dev Development > Subject: Re: [webkit-dev] EFL port? > > Hi, > > Are you the only one working on the EFL port? > > - Anders > > On Feb 10, 2017, at 1:40 AM, Gyuyoung Kim <gyuyoung@webkit.org> wrote: > > Hello, > > To be honest, very few people have worked for EFL port recently. In my case > it was hard to maintain EFL port because of internal work. > However I have a plan to improve EFL port after I finish the work. Even I > opened a website for EWebKit. http://www.ewebkit.org. > Besides I released EWebKit 1.18 version[1] for EFL 1.18 official release. > Could you give me more time for EFL port ? > > Gyuyoung. > > > [1] EWebKit 1.18 release announcement. > > https://phab.enlightenment.org/w/efl_and_elementary_1_18_release_announcement/ > > EWebkit > > Together with this release we are happy to announce that the EWebkit team is > doing a > release with their work matching the efl 1.18. > It contains various webkit core as well as EWebkit specific enhancements. > See the > NEWS file for details and the http://www.ewebkit.org page for further > instructions on > building. We hope to keep future releases of EWebkit aligned with the EFL > release schedule. > > > > > > > > On Fri, Feb 10, 2017 at 9:42 AM, Anders Carlsson <ander...@apple.com> wrote: >> >> Hello, >> >> Looks like the EFL port isn’t really being worked on anymore. Is this >> true? Can we rip it out? >> >> - Anders >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev > > > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN, GTalk, FaceTime: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (16) 99354-9890 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebCore/platform standalone library
On Thu, Jan 12, 2017 at 7:11 PM, Alex Christensen <achristen...@apple.com> wrote: > If PAL were a shared library in a CMake build, then it wouldn’t build > successfully if there were layering violations. I think we should do > something like that to enforce good design, even if the Mac Xcode projects > treat it as a static library or even just a part of WebCore. Actually for development it would make lives much easier to keep it as shared library, reducing compile time and help to segment the symbols in a different space (linkers, gdb) what if it becomes shared by default on Debug builds, static by default in Release? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN, GTalk, FaceTime: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (16) 99354-9890 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?
Guessed so from Qt port... Now we need to do that for both soup and curl, or write an abstraction for elf with some backend outside webkit On Saturday, July 24, 2010, Darin Adler da...@apple.com wrote: This is a matter for the networking layer in your particular port rather than for WebKit itself. It does not require changes to WebKit. The Mac OS X WebKit networking layer, NSURLConnection, has this feature. It’s done by creating a custom NSURLProtocol object. -- Darin -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?
On Thu, Jul 22, 2010 at 11:07 PM, Darin Adler da...@apple.com wrote: On Jul 22, 2010, at 2:12 PM, Gustavo Sverzut Barbieri wrote: Sorry to disturb this already dead thread, but we're (webkit-efl) thinking of letting applications/browsers register new protocol handlers to provide contents themselves. A co-worker, Flávio Ceolin, will send more details in another thread, but do you have any idea on the path to have them generically in WebCore? WebKit on Mac OS X already supports this and most other ports as well. Adding it to a platform does not require any changes to WebCore. The frame policy functions in FrameLoaderClient are the hook for this sort of thing, specifically dispatchDecidePolicyForNavigationAction. WebKit looks at the URL and decides it’s something an application can handle based on the OS-specific system for handling such things. Then if it does want to handle it, it calls the frame policy function with the action ignore, which prevents WebCore from doing anything with the link, and then passes the URL on to the other application. Hi Darin, Thanks! But not what I actually need... maybe I lacked an use case, but my usage is not just to handle an URL, rather to provide actual data to webkit based on them. For instance, if I want to access an web archive in tar/zip/rar without uncompressing, I'd like to be able, from my app, to load some data with the base uri being tar:// or maybe something that identifies that file (tar://bla.tar.gz), and then all the relative paths would be prepended tar://, so I could trap it, access the file inside the tar and then feed it back to webkit so the images are shown, css are used, etc... Maybe it is something else completely different? Ideas? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?
Sorry to disturb this already dead thread, but we're (webkit-efl) thinking of letting applications/browsers register new protocol handlers to provide contents themselves. A co-worker, Flávio Ceolin, will send more details in another thread, but do you have any idea on the path to have them generically in WebCore? IMO, the logics would require the network backend to delegate to WebCoreSupport the unsupported KURL before failing, that could return some instance to handle the job. This class/instance to handle the job is not abstracted right now, but could be done in a way that we could use it in soup/curl (webkit-efl supported backends) and also in qt. For instance, Qt always delegate access using QNetworkAccessManager and can do what we said, but it is port-specific. As we have 2 network backends (we will likely remain with curl later), having a generic alternative is better, but we could just reuse our code in both backends. Any help is appreciated. Regards! On Thu, Jul 8, 2010 at 3:27 PM, Dmitry Titov dim...@chromium.org wrote: Thanks to all, the bug is here: https://bugs.webkit.org/show_bug.cgi?id=41878 I've added link to tracking Chromium bug as well. Dmitry On Wed, Jul 7, 2010 at 7:59 PM, Jeremy Orlow jor...@chromium.org wrote: That would be the standard thing to do. The sooner someone gets started on the feature, the easier it'll be to revert the patch that removes the code. :-) J On Thu, Jul 8, 2010 at 10:55 AM, David Levin le...@chromium.org wrote: On Wed, Jul 7, 2010 at 5:24 PM, Peter Kasting pkast...@google.com wrote: On Wed, Jul 7, 2010 at 5:00 PM, Dmitry Titov dim...@chromium.org wrote: I'd lean to the removal, unless there is a port that has work ongoing or planned soon for those implementations. Does anybody vote for #ifdefs? I vote against removal if only because Chromium has really wanted these badly for a long time and simply hasn't been able to find someone to implement them. Perhaps I could make it worth your while to implement rather than remove the stubs? :) Even if someone to implement them for chromium, it doesn't seem to fix the overall problem. Dmitry indicated that the presences of these is breaking feature detection in browsers using WebKit (-- which is something being heard from web developers). A simple solution is to remove them. Later, any port (including chromium) who gets someone to work on them could re-add these methods back properly under ifdef's. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Add WebKit EFL component on Bugzilla
On Wed, Jun 30, 2010 at 4:08 PM, Leandro Pereira lean...@profusion.mobi wrote: Hi. Could anyone please add a WebKit EFL component on Bugzilla? Anyone could handle this? (I see that people requested WebKit2 component, so the one doing it could do EFL as well?) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)
On Thu, Jun 17, 2010 at 6:24 PM, Matt 'Murph' Finnicum mattf...@gmail.com wrote: On Thu, Jun 17, 2010 at 4:19 PM, David Hyatt hy...@apple.com wrote: On Jun 17, 2010, at 2:45 PM, Gustavo Sverzut Barbieri wrote: David, it's bit more than annoying, it's fragmenting memory for no good. In the long run on systems will small memory it does make a difference :-/ I'd like to see some option, maybe compile-time, to strip these useless whitespaces. As Alexey points out, this is a compatibility issue though. People write code assuming the whitespace nodes are there. If you remove them, you'll see Web site breakage. dave (hy...@apple.com) Do people write code assuming the content of the whitespace nodes? That seems very unlikely to me. If not, we could collapse them and be much more efficient about things (such as a simple flag in their parent node that represents their existence) Same experience on my side, most JS libs that handle whitespace, do it just to ignore the nodes... running through strip and then checking for emptiness. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit-EFL finally merged, pay attention to CMake build system!
On Sat, May 15, 2010 at 2:06 PM, Adam Barth aba...@webkit.org wrote:
On Sat, May 15, 2010 at 9:14 AM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
I'm glad to say that WebKit-EFL was finally merged as the last but
definitely bit, the build system, was merged into tree today. Many,
many thanks to all the friends that helped with this painful task,
including Eric Seidel, Adam Treat, Kenneth Christiansen, Gustavo
Noronha and possible lots of others.
Now a warning: when renaming files, pay attention to CMakeLists*.txt
files in tree! The generic files are stored in CMakeLists.txt, while
the port specific goes into CMakeLists${PORT}.txt I just noticed that
another patch went in that moved WebGLArray and now we're in tree but
cannot compile as the old file we refer is not there anymore.
Next step is trying to setup a build server so we can participate into
the regular EWS checks. But until there, remember to do that manually
as you already do for GNUmakefile.am, *.gyp, etc..
If you'd like to run an EWS bot, you can add your port to this file:
http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/common/config/ports.py
and then make a new subclass of AbstractEarlyWarningSystem in this file:
http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/tool/commands/earlywarningsystem.py
Yeah, first we need to find out a machine that can keep the required
pace, setup EFL in it and etc.
Thanks and best regards,
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKit-EFL finally merged, pay attention to CMake build system!
Hi all,
I'm glad to say that WebKit-EFL was finally merged as the last but
definitely bit, the build system, was merged into tree today. Many,
many thanks to all the friends that helped with this painful task,
including Eric Seidel, Adam Treat, Kenneth Christiansen, Gustavo
Noronha and possible lots of others.
Now a warning: when renaming files, pay attention to CMakeLists*.txt
files in tree! The generic files are stored in CMakeLists.txt, while
the port specific goes into CMakeLists${PORT}.txt I just noticed that
another patch went in that moved WebGLArray and now we're in tree but
cannot compile as the old file we refer is not there anymore.
Next step is trying to setup a build server so we can participate into
the regular EWS checks. But until there, remember to do that manually
as you already do for GNUmakefile.am, *.gyp, etc..
BR,
PS: We'd welcome more ports to come to CMake! Adam Treat is trying to
move one port to it, and we should help with GTK when time allows.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Help with review of EFL CMake patches?
On Fri, May 7, 2010 at 5:50 AM, Patrick Roland Gansterer
par...@paroga.com wrote:
Hi,
The idea of a Options${PORT} file is to put only the port-specific
checks and defaults there.
When we now have a CMake buildsystem we can get rid of port-thinking. We
can switch to has-feature-thinking.
You should check for different features instead of doing sth for a spezial
port.
E.g. ICU is used in more than one port: If you check for ICU you only need
to define the ICU stuff once and the different ports can use it.
An other example is the win32 an wince port, where many files are shared:
You would create a port-file for win32 and wince then a general windows
port-file?.
Only one port file isn't applicable everywhere.
Hi Patrick,
Of course, but the problem is that ports diverge radically in features
they support, and even the same port diverges when it goes to
different platforms. Last but not least, a single port on a single
platform may toggle features and dependencies, this is what happens
with Gtk port: you can compile with or without ICU, you can choose to
disable html5 video, then gstreamer requirement is gone.
The ${PORT} file is there to solve this, as Leandro explained. If
later on we detect some parts are shared, then we can just create a
third file that is included by these. Much like we already do with
code in WebKit.
BR,
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Help with review of EFL CMake patches?
Just a friendly ping, if someone could help us get this merged, say
it. If you see a big blocker after my last comment, say it.
Meanwhile, Leandro is working on generic webkit option, to be more
generic than my initial {ADD,DEL}_FEATURE().
BR,
On Mon, May 3, 2010 at 6:32 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Mon, May 3, 2010 at 6:09 PM, Patrick Roland Gansterer
par...@paroga.com wrote:
Hi,
On Mon, 3 May 2010 17:33:45 -0300, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
Did you see this new version? Leandro did the work on top of yours.
However he removed the .h from the source list, he did it before he
read that it may be useful to get some IDE to show it. If mandatory we
can add them back.
Yes, I've seen it. He did a great job, but there a some parts which are
not good for a general buildsystem.
E.g. INCLUDE(Options${PORT}) doesn't support different ports well, since
ports share some parts. (There some other points too; I'll post them on the
bug)
My vision is that the root CMake file will do all the WTF_USE_* stuff.
It has to decide all port specific stuff. All other CMake files should
only use this defines. This will provide a central to switch the
different implementations (e.g. switch between pthread and native threads
on windows).
The point is to split this off to some ports as these things are
likely to get huge. As said we did some for GTK and EFL, although they
share a lot, the checks became big to make the file a PITA to read.
Although CMake does provide if() and indentation, the branches tend to
be quite long.
also, each folder, like JavaScriptCore/CMakeLists.txt have a
port-specific file included, that may be used to filter or extend the
lists, or to change some variables. This way we can turn on *core
libraries as shared objects and have libJavaScriptCoreGtk.so and
libJavaScriptGtk.so installed. This is not so useful for deployment,
but definitely useful for development where link times tend to be
quite long if you don't have lots of RAM for linking.
Also, this is done in a way that we don't need to anticipate all kind
of different platform behaviors, they can just change the behavior as
intended.
I already run in some problem with my JavaScriptCore CMake files, but I
hoped for some feedback I didn't get.
Well, the bits you did were quite unchanged, except by delegating the
options to their own files due the above reasons. So consider these
patches as feedback that works (in the sense of you can try it)
My big question is if CMake should be added as a universal buildsystem (to
get rid of some other buildsystems) or if it is only for the EFL port?
I think this depends on ther progress in the CMake vs. GYP discussion. The
last post on the mailing list was [1].
- Patrick
[1] https://lists.webkit.org/pipermail/webkit-dev/2010-April/012662.html
As I said, I really want to get out of the universal thing otherwise
it will not be merged. IMHO it is a much saner approach to do one
example and passively convert those that are willing to use CMake (ie:
Xan said if Gtk works without loss, then he'd be fine to use it).
Alternatively, if moving to GYP will make our build system be accepted
more easily, then just say and we'll take the burden of going that
route. We just want to have all we need in SVN, say to users get svn,
type this and it is done. Also, maintaining the build off tree proved
painful over the last weeks when files were moved and we had to play
catch up (to fix this we need stuff in svn AND a build bot, i know...
but we'll get there).
BR,
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Help with review of EFL CMake patches?
Hi all, As some of you know, the EFL port is almost all merged, we just lack a build system in SVN by now. We initially started with automake, sharing with GTK, but it was quite slow and the Gtk guys had the willing to get it clean before any changes were made, in order to avoid it to get worse. We did an initial cleanup, but then we figured out CMake would be a better option. By the time we were almost done with CMake build system, this mail list started discussing build systems and CMake was one of the considered options, making us quite happy at the time. We got the system done, but then people just started to move files in SVN making our lives quite hard these last weeks. Fortunately things are calm now and the system compiles quite well. We did the patches splitting the common and EFL specific parts, so people may add new ports with minimum effort. Of course as more systems are added, we should rearrange things that we overlooked at first, but that should be easy. What we need know is someone to review https://bugs.webkit.org/show_bug.cgi?id=37945 and land it to SVN. Note that we're trying to get EFL to build with SVN, not to build the most perfect CMake build system ever. So let's be reasonable with comments and suggestions, particularly those to make it generic as we consider that these should come when people start moving their ports to CMake. We surely can help with such tasks, we have a partially working GTK port that we may finish one day and suggest to webkit-gtk the move to it. BR, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Help with review of EFL CMake patches?
On Mon, May 3, 2010 at 5:21 PM, Patrick Roland Gansterer par...@paroga.com wrote: Hi, the file from Gustavo are mainly for the EFL port. It's not a general buildsystem and some parts are not real CMake style in the moment. I did some cleanup for the JavaScriptCore files already, but for the WebCore and WebKit parts it is a bigger task. As I already wrote at [1] I will help creating a general, not EFL specific, CMake buildsystem, but I didn't get any responses until now. - Patrick [1] https://lists.webkit.org/pipermail/webkit-dev/2010-April/012599.html Patrick, Did you see this new version? Leandro did the work on top of yours. However he removed the .h from the source list, he did it before he read that it may be useful to get some IDE to show it. If mandatory we can add them back. BR, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Help with review of EFL CMake patches?
On Mon, May 3, 2010 at 6:09 PM, Patrick Roland Gansterer
par...@paroga.com wrote:
Hi,
On Mon, 3 May 2010 17:33:45 -0300, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
Did you see this new version? Leandro did the work on top of yours.
However he removed the .h from the source list, he did it before he
read that it may be useful to get some IDE to show it. If mandatory we
can add them back.
Yes, I've seen it. He did a great job, but there a some parts which are
not good for a general buildsystem.
E.g. INCLUDE(Options${PORT}) doesn't support different ports well, since
ports share some parts. (There some other points too; I'll post them on the
bug)
My vision is that the root CMake file will do all the WTF_USE_* stuff.
It has to decide all port specific stuff. All other CMake files should
only use this defines. This will provide a central to switch the
different implementations (e.g. switch between pthread and native threads
on windows).
The point is to split this off to some ports as these things are
likely to get huge. As said we did some for GTK and EFL, although they
share a lot, the checks became big to make the file a PITA to read.
Although CMake does provide if() and indentation, the branches tend to
be quite long.
also, each folder, like JavaScriptCore/CMakeLists.txt have a
port-specific file included, that may be used to filter or extend the
lists, or to change some variables. This way we can turn on *core
libraries as shared objects and have libJavaScriptCoreGtk.so and
libJavaScriptGtk.so installed. This is not so useful for deployment,
but definitely useful for development where link times tend to be
quite long if you don't have lots of RAM for linking.
Also, this is done in a way that we don't need to anticipate all kind
of different platform behaviors, they can just change the behavior as
intended.
I already run in some problem with my JavaScriptCore CMake files, but I
hoped for some feedback I didn't get.
Well, the bits you did were quite unchanged, except by delegating the
options to their own files due the above reasons. So consider these
patches as feedback that works (in the sense of you can try it)
My big question is if CMake should be added as a universal buildsystem (to
get rid of some other buildsystems) or if it is only for the EFL port?
I think this depends on ther progress in the CMake vs. GYP discussion. The
last post on the mailing list was [1].
- Patrick
[1] https://lists.webkit.org/pipermail/webkit-dev/2010-April/012662.html
As I said, I really want to get out of the universal thing otherwise
it will not be merged. IMHO it is a much saner approach to do one
example and passively convert those that are willing to use CMake (ie:
Xan said if Gtk works without loss, then he'd be fine to use it).
Alternatively, if moving to GYP will make our build system be accepted
more easily, then just say and we'll take the burden of going that
route. We just want to have all we need in SVN, say to users get svn,
type this and it is done. Also, maintaining the build off tree proved
painful over the last weeks when files were moved and we had to play
catch up (to fix this we need stuff in svn AND a build bot, i know...
but we'll get there).
BR,
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fwd: CMake WebKit-EFL: initial preview
On Mon, Apr 19, 2010 at 11:34 PM, Patrick Roland Gansterer par...@paroga.com wrote: Hi, Gustavo Sverzut Barbieri: Find attached 2 patches. ? ?- WebKit-EFL-CMake_All-Missing-Patches.patch is a bundle that implements CMake support for WebKit-EFL and also adds the missing patches to make it compile (but runs with some bugs, needs updating to some api changes). Apply it if you want to compile the port (also get EFL from svn, see http://svn.enlightenment.org/) ? ?- WebKit-EFL-CMake.patch is just the CMake support, a single CMakeLists.txt and support *.cmake modules Please take a look if you are interested in CMake for WebKit-EFL. If you know CMake already, review it and send comments. My team just started with CMake some days ago. Can you please post the patch at bugs.webkit.org. will do as soon as we get the .pc generated and installed, otherwise the external programs cannot know how to link to it. Maybe you can split it into a CMake and a other stuff part. (Was it already before you merged it?) It is already, the patch is at http://people.profusion.mobi/~gustavo/WebKit-EFL-CMake.patch I'd like to give you some feedback at the bug comments. The CMake file should be split into different projects for example. Hum... I saw everywhere that it was common to split in multiple directories, particularly for JavaScriptCore and WebCore. But given that I wanted to keep it simple, I forced it to be one single file to make merge into SVN easier. I was also worried about the propagation of settings and flags to the sub-folders. But yes, I notice that it will make easier to use INCLUDE_DIRECTORIES() as we'd just have one target per directory. Our primary goal is not to join into the recent GYP x CMAKE discussion, but we need our EFL port fully landed to avoid the overhead we're doing now. We were using the GTK autotools, as we were more familiar with it, but given it is slow and messy, the GTK guys did not want to merge our patches right away, requesting a cleanup of existing code first. We did part of the cleanup and CMake in parallel, but CMake worked out quite nice and we don't plan to use GTK's autotools anymore (but we did send the cleanup we achieved until now). That is to say that making it simple to be merged is our first aim. One more thing I'd like to kindly ask you is if you can also post patches to the CMake files. This is because our team is already suffering to match the latest WeKit changes (we have already a huge queue waiting to be merged, and now patches have to be rebased and so on). So the more help, the better! :-) BR, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Clean way to allow delegates for PopupMenu?
On Fri, Apr 16, 2010 at 10:30 AM, Luiz Agostini
luiz.agost...@openbossa.org wrote:
2010/4/15 Gustavo Sverzut Barbieri barbi...@profusion.mobi
Hello all,
I'm part of the EFL port team and we're implementing the PopupMenu,
however EFL is a different platform as for our port it is just a
state-full canvas, not relying on any widget set/toolkit, we do not
have the concept of a menu at all!
Looking at all existing implementations, they all go straight to
native platform menus. But we can't as we want to avoid such
dependencies. What we'd like to have is a delegate, that WebCore calls
the ChromeClient that is overloaded in WebKit, giving our View user a
callback with all data.
The good news is: we did it and it works quite well.
The bad news is: we cheated and include WebKit/efl/WebCoreSupport from
PopupMenuEfl.cpp, what a shame! (although some ports *cough qt*
include in WebCore defines from WebKit)
In Qt we have an abstract class for popup delegates in WebCore/platform/qt
and we do the actual popup delegate implementation in
WebKit/qt/WebCoreSupport. The delegates are implemented in WebKit layer and
PopupMenuQt has no knowledge about any specific delegates. The only reason
to include WebKit/qt/WebCoreSupport in PopupMenuQt is to make the call that
creates the delegate object. It could be avoided adding a method to Chrome
but at the time I was working on it it was decided that it was not needed.
Yes, it is kinda similar to our, since we looked at your
implementation before doing our. But the problem here is you still
include WebKit files from WebCore. For *me* it looks like a hack, but
if people do not complain then I can kindly keep it as is, after all
it is working already :-)
In order to have a clean design, we'd like to know the general opinion
on how to do it. From what I see Mac already defines a similar call in
ChromeClient.h:
#if PLATFORM(MAC)
...
virtual void willPopUpMenu(NSMenu *) { }
#endif
in our case, we'd need:
#if PLATFORM(EFL)
virtual void showPopupMenu(const IntRect rect, FrameView*
view, int index) { }
virtual void hidePopupMenu() { }
#endif
so our PopupMenuEfl.cpp will just proxy to these calls.
However, although Mac does that it may not be the best solution, so to
avoid endless patches to be discussed at bugzilla I'd like to know
your opinion on the best way so our patch is right from beginning.
I think that we could add methods to Chrome and ChromeClient to create the
delegates. For example:
PopupMenuDelegate* Chrome::createPopupMenuDelegate(PopupMenuClient* c) {
return m_client-createPopupMenuDelegate(c); }
virtual PopupMenuDelegate*
ChromeClient::createPopupMenuDelegate(PopupMenuClient*) { return 0; }
Each port could then provide its typedef for PopupMenuDelegate and
override ChromeClient::createPopupMenuDelegate.
Well, as I said we just need methods to show/hide to keep it done, but
if you want to implement another class PopupMenuDelegate to do it,
then we could do such work as well. We'd like to avoid this delegate
class as our port is C, so we'd need to do it all in C++ plus what we
have done in C already, just to proxy it.
BR,
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Clean way to allow delegates for PopupMenu?
On Fri, Apr 16, 2010 at 11:21 AM, Luiz Agostini
luiz.agost...@openbossa.org wrote:
2010/4/16 Gustavo Sverzut Barbieri barbi...@profusion.mobi
On Fri, Apr 16, 2010 at 10:30 AM, Luiz Agostini
luiz.agost...@openbossa.org wrote:
2010/4/15 Gustavo Sverzut Barbieri barbi...@profusion.mobi
Hello all,
I'm part of the EFL port team and we're implementing the PopupMenu,
however EFL is a different platform as for our port it is just a
state-full canvas, not relying on any widget set/toolkit, we do not
have the concept of a menu at all!
Looking at all existing implementations, they all go straight to
native platform menus. But we can't as we want to avoid such
dependencies. What we'd like to have is a delegate, that WebCore calls
the ChromeClient that is overloaded in WebKit, giving our View user a
callback with all data.
The good news is: we did it and it works quite well.
The bad news is: we cheated and include WebKit/efl/WebCoreSupport from
PopupMenuEfl.cpp, what a shame! (although some ports *cough qt*
include in WebCore defines from WebKit)
In Qt we have an abstract class for popup delegates in
WebCore/platform/qt
and we do the actual popup delegate implementation in
WebKit/qt/WebCoreSupport. The delegates are implemented in WebKit layer
and
PopupMenuQt has no knowledge about any specific delegates. The only
reason
to include WebKit/qt/WebCoreSupport in PopupMenuQt is to make the call
that
creates the delegate object. It could be avoided adding a method to
Chrome
but at the time I was working on it it was decided that it was not
needed.
Yes, it is kinda similar to our, since we looked at your
implementation before doing our. But the problem here is you still
include WebKit files from WebCore. For *me* it looks like a hack, but
if people do not complain then I can kindly keep it as is, after all
it is working already :-)
In order to have a clean design, we'd like to know the general opinion
on how to do it. From what I see Mac already defines a similar call in
ChromeClient.h:
#if PLATFORM(MAC)
...
virtual void willPopUpMenu(NSMenu *) { }
#endif
in our case, we'd need:
#if PLATFORM(EFL)
virtual void showPopupMenu(const IntRect rect, FrameView*
view, int index) { }
virtual void hidePopupMenu() { }
#endif
so our PopupMenuEfl.cpp will just proxy to these calls.
However, although Mac does that it may not be the best solution, so to
avoid endless patches to be discussed at bugzilla I'd like to know
your opinion on the best way so our patch is right from beginning.
I think that we could add methods to Chrome and ChromeClient to create
the
delegates. For example:
PopupMenuDelegate* Chrome::createPopupMenuDelegate(PopupMenuClient* c) {
return m_client-createPopupMenuDelegate(c); }
virtual PopupMenuDelegate*
ChromeClient::createPopupMenuDelegate(PopupMenuClient*) { return 0; }
Each port could then provide its typedef for PopupMenuDelegate and
override ChromeClient::createPopupMenuDelegate.
Well, as I said we just need methods to show/hide to keep it done, but
if you want to implement another class PopupMenuDelegate to do it,
then we could do such work as well. We'd like to avoid this delegate
class as our port is C, so we'd need to do it all in C++ plus what we
have done in C already, just to proxy it.
I did not suggest a class for PopupMenuDelegate: Each port could then
provide its typedef for PopupMenuDelegate.
Remember PlatformWidget? :-)
yes, but we still need the hide to get it hidden :-)
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Clean way to allow delegates for PopupMenu?
Hello all,
I'm part of the EFL port team and we're implementing the PopupMenu,
however EFL is a different platform as for our port it is just a
state-full canvas, not relying on any widget set/toolkit, we do not
have the concept of a menu at all!
Looking at all existing implementations, they all go straight to
native platform menus. But we can't as we want to avoid such
dependencies. What we'd like to have is a delegate, that WebCore calls
the ChromeClient that is overloaded in WebKit, giving our View user a
callback with all data.
The good news is: we did it and it works quite well.
The bad news is: we cheated and include WebKit/efl/WebCoreSupport from
PopupMenuEfl.cpp, what a shame! (although some ports *cough qt*
include in WebCore defines from WebKit)
In order to have a clean design, we'd like to know the general opinion
on how to do it. From what I see Mac already defines a similar call in
ChromeClient.h:
#if PLATFORM(MAC)
...
virtual void willPopUpMenu(NSMenu *) { }
#endif
in our case, we'd need:
#if PLATFORM(EFL)
virtual void showPopupMenu(const IntRect rect, FrameView*
view, int index) { }
virtual void hidePopupMenu() { }
#endif
so our PopupMenuEfl.cpp will just proxy to these calls.
However, although Mac does that it may not be the best solution, so to
avoid endless patches to be discussed at bugzilla I'd like to know
your opinion on the best way so our patch is right from beginning.
Regards,
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit meeting notes] build systems
is also important, be them xml/txt/whatever, but something that we can say EFL supports DATABASE, ..., but not VIDEO, new options would trigger a warning to help developers, the options would be generated based on the port support. BR, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Thu, Apr 8, 2010 at 3:01 PM, Anders Carlsson ander...@apple.com wrote: Hello everyone, This is a heads-up that we will shortly start landing patches for a new WebKit framework that we at Apple have been working on for a while. We currently call this new framework WebKit2. WebKit2 is designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process. This model is similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients to use it. Some high-level documentation is available at http://trac.webkit.org/wiki/WebKit2 Currently WebKit2 is available for Mac and Windows, and we would gladly accept patches to add more ports. We're more than happy to answer any questions you might have, and we hope that this will be a topic of discussion at the WebKit Contributors Meeting. Please, please consider making every call non-block, particularly those that requires interaction with user, avoiding nested main loops and bugs that come from these[1]. For instance, these could call user that is later responsible to call another function, providing the continuation based on some shared token/context. [1] https://lists.webkit.org/pipermail/webkit-dev/2010-March/011845.html -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing new port: EFL
On Wed, Apr 7, 2010 at 3:01 AM, haithem rahmani
haithem.rahm...@gmail.com wrote:
Hi,
Just a simple question:
- It seems that the EFL port of webkit is based on EFL/X11 api.
is there plans to support other EFL backends especially directfb ?
WebkitGtk is doing that with (--with-target=directfb) option.
Yes, there are other peers interested in such support, including SDL,
FrameBuffer and DirectFB.
However we're focused on getting the patches merged into SVN first.
Any reviewer attention can help, we're almost there, just some files
pending. They are:
Pending Review:
https://bugs.webkit.org/show_bug.cgi?id=35915 Add FrameLoaderClientEfl.{cpp,h}
https://bugs.webkit.org/show_bug.cgi?id=35918 Add EditorClientEfl.{cpp,h}
https://bugs.webkit.org/show_bug.cgi?id=35932 Add ewk_view.{cpp,h}
Reviewed r-, but the answers were replied however no further review:
https://bugs.webkit.org/show_bug.cgi?id=36317 Add EFL-specific code to Widget.h
Needs GTK+ people to check it, as it will shared the same autotools system:
https://bugs.webkit.org/show_bug.cgi?id=36761 Modify the autotools build system
Simple, just need to decide where the file should go to:
https://bugs.webkit.org/show_bug.cgi?id=36405 Move
AccessibilityObjectEfl.cpp from page to accessibility
We want to get these patches in first, as they are the base for
further work. For instance, we have a huuuge number of patches to
expose various APIs that were missing, like frame loader policy,
delegates for ContextMenu, PopupMenu and so on.
BR,
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] parallel painting
On Sat, Apr 3, 2010 at 9:32 PM, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote: Hi, I am working on a parallel painting feature for WebKit (bug id: 36883). Basically it records the painting commands on the main thread, and replay them on a painting thread. The gain would be that the recording operation is cheap. Currently it is Qt specific, but I could make it more platform independent if other ports are interested. EFL port would be interested in this. Could you provide more details on the implementation? Is the painting thread a single thread, or is it being split to N cores? Did you consider the alternative that is isolate webkit layout in another thread as well? From our environment tests (embedded systems), re-layout process can take few seconds without any paint... that being done in the main thread hurts the whole experience as the event processing of menus, animations and others are blocked. In an ideal world WebKit would never block, it would just proxy input and output events to its thread (hard, error-prone... :-/), there it would layout, render and when ready release the main thread to use the painted contents (maybe tiles as the Qt port now enables). BR, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [Fwd: Re: Announcing new port: EFL]
Hi all, sorry about the post to forward, possibly breaking the mail thread, but I was not subscribed to the list. Find below some comments: On Tue, Feb 23, 2010 at 5:09 PM, Leandro Pereira lean...@profusion.mobi wrote: -- Forwarded message -- From: Leandro Pereira lean...@profusion.mobi To: webkit-...@lists.webkit.org Date: Tue, 23 Feb 2010 14:44:24 -0300 Subject: Re: [webkit-dev] Announcing new port: EFL Eric, On Mon, 2010-02-22 at 11:19 -0800, Eric Seidel wrote: I have a few questions (and I assume others are curious to the answers as well): - Who maintains this port? (Samsung I assume.) ProFUSION and Samsung. - Is this an active port? (Are there plans for the EFL contributors to work upstream?) Yes, we want to work directly with upstream. ProFUSION itself will keep working on it even if contracts are over, as it is a great component for EFL and we invest a good amount of work in EFL-related technologies as it is part of our service offerings. I am doing the cleanups required by the upstream task, merge of GTK+'s and EFL's build system, and will do further works on unifying both GTK +'s and EFL's codebases. There are other people working on this port, however: - Rafael Antognolli antogo...@profusion.mobi, working on the port since August last year, did a great amount of work to get optimizations and fixes. - Gustavo Sverzut Barbieri barbi...@profusion.mobi, core developer of EFL, rewrote the WebKit/efl/ based on initial port by INdT. Is now the manager and internal ProFUSION reviewer. - Lucas De Marchi lucas.demar...@profusion.mobi, working to fill the gaps, like missing APIs in WebCoreSupport. - Raphael Kubo da Costa k...@profusion.mobi, worked on alternative backing store scaling to speed up zooming in mobile systems. - Does the EFL port have a DumpRenderTree implementation? (And if so, can it run the LayoutTests? What percentage pass?) Not yet, but we'll surely add it in future as we want to have automated tests just like Qt. I'm quite sure Samsung people will step in and confirm their commitment to the success and continuation of the EFL port, as they are already doing with the core EFL itself. Browser engine, as we are all aware, is a critical component of any modern system and thus of high interest to them. But Samsung is not alone in this port. I can say about ProFUSION and Enlightenment, as I'm both owner of former and core developer of later. Enlightenment developers always liked and supported the WebKit-EFL port, even the first public release did by INdT got patches and applications developed around it. For one, we got ewww browser from Calaos guys, then I created eve based on it -- it lived in E SVN for a while, just dropped recently as we ended changing the public API completely (and for good). After WebKit-EFL lands completely, it is planned to have Elementary (our widget set/toolkit, http://trac.enlightenment.org/e/wiki/Elementary) widget encapsulating it... that will likely boost its usage. ProFUSION is about development and services, with the differentiation factor being EFL support. Our plans regarding WebKit-EFL are quite longstanding, even before being contracted by Samsung to do this port we planned to have a WebKit-EFL component in EFL. Of course Samsung's support helps supporting it, but even without them we do plan to continue investing manpower in this port as it is a key technology for our developments and services. I hope this are bit more clear now. This is not a drop-and-run ;-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
