[webkit-dev] Github mirror is not updating
Hi, I noticed that the github mirror at https://github.com/webkit/webkit is not getting the latest commits from WebKit (it is now about a month behind). Is that intentional? Thanks, -- Adrien / PulkoMandy ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Embedding Identifiers in Commit Messages
3 novembre 2020 00:10 "Ryosuke Niwa" a écrit: > On Mon, Nov 2, 2020 at 2:04 PM Jonathan Bedard wrote: > >> We appreciate everyone’s feedback on transitioning away from Subversion to >> Git, I’ll be releasing >> an expected timeline of up-coming changes in the next week before the >> contributors meeting. >> >> In the mean time, we’re preparing on adding identifiers to new commit >> messages, that work is >> tracked in https://bugs.webkit.org/show_bug.cgi?id=218407. At the moment, >> we’re likely going to be >> appending the identifiers to commit messages (as the current change >> proposes), but I wanted to >> provide a chance for folks to object to this change before it becomes >> canonical. > > I'm a bit confused here. It looks like the patch only affects commits > made via webkit-patch. Given there are a lot of people who don't use > webkit-patch land, I'm not certain this strategy is sound even in the > short term. Why don't we do this in post commit hook instead? Yes, if your reason for switching to Git is making things easy for people using Git to contribute, please try to use the standard Git commands as much as possible. Otherwise, from a developer experience point of view you are still doing your custom system, and it does not matter that the backend is Git. You can use an approach similar to the hook used for Gerrit: https://gerrit-review.googlesource.com/Documentation/cmd-hook-commit-msg.html Note that this hook runs locally on developer's machine, but you can additionally have a server-side hook that checks that the id is indeed present in the commit message, and rejects the commit otherwise (Gerrit also does this for its Change-Id). I think it is not possible to alter the commit message from server-side with a standard Git server, it would create confusion because the local branch from the developer machine would not match what's on the server. -- Adrien. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Transition to Git
> 3. Changelog > I don’t feel it's a big problem to write ChangeLog file. > Of course, this is tired thing but I don’t have a strong alternative > after reading this thread. > > However the current `prepare-Changelog` script does not fit with a > branch -based workflow on Git, I feel. There is a room to polish on > this Git migration. > > For example, I’d like to specify a branch as my working set in my > local machine, instead of commit or staged changes. > > Ordinary, I do these flows but it’s a bit tired…. (if you know more > good ways, could you tell me!): > > 1. Run `prepare-Changelog` > 2. Format ChangeLog file and remove duplicated entries added by _steps 1_. > 3. Fuse new changes into a single patch by `git add . && git commit > --ammend` or `git commit --fixup HEAD && git rebase master -i > --autosquash` > 4. Upload patches by `webkit-patch upload -g HEAD` > > I don’t have an objection that we merge a squashed patch into trunk to > simplify the history but we would have some chance to improve the script. > The original goal mentionned at the start of the thread was encouraging more people to contribute to WebKit. From that side, what's important is trying to retain a patch submission workflow that's standardized. That can be github/gitlab style pull requests, or Gerrit which is a different one. There are probably others. If the workflow for submitting patches requires writing a changelog file, or other similar custom operations, I think that's more likely to turn potential contributors away (I can only speak for myself, here, of course). Even if you automate it with a script, people will have to remember to use the script. Then it doesn't matter if you use Git or Github or some other tool under the hood: the patch submission process is a custom one. Starting from there, the question is more: Which of these existing workflows is more suitable? How much can we tweak them (with bots on Github, plugins on Gerrit, or pre-commit/pre-push hooks on developer machines, for example) to make them better fit the existing things that will probably be kept? (I guess Apple internal bugtracker, possibly bugzilla as well, maybe some parts of the existing build infrastructure and builder machines?). Can these changes to the workflow be done and documented so that existing Git (and Github/Gitlab/Gerrit/...) users can handle them easily? -- Adrien. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Transition to Git
> One thing to take into account is that WebKit's repository is big and > public GitHub/GitLab prevent creating large repository by default. This > means it might not be possible for contributors to actually fork > WebKit's repository on their account and then create a pull request > (which is the standard way IIUC). Instead, we would probably end up > doing like web-platform-tests and give contributors the permission to > create branches to the WebKit account and make Pull Request to the > master branch. Probably, we should forbid people to commit to the master > branch directly (I think someone broke WPT's master branch that way last > year)... > > Similarly, public GitHub/GitLab prevent very large files by default. > Hopefully, this does not happen in WebKit (we should definitely add a > hook to prevent someone to land a big file) but for example that mistake > happened in Chromium last year ( > https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/tSOmIfXAP2s/m/H07SmWIoCgAJ > ) and this broke the sync of their GitHub mirror. There is already a mirror of the existing WebKit repository on Github, and there are about 2000 forks of it already [1]. At least the Haiku version of WebKit is maintained this way, and had no problems with Github so far. So this shouldn't be a problem? [1] https://github.com/WebKit/webkit/network/members -- Adrien. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Transition to Git
On Sat, Oct 03, 2020 at 08:43:40PM +0300, Konstantin Tokarev wrote: > >> Gerrit accepts GitHub and other OAuth providers as well, so that's not a > >> problem. We have been using this for Haiku code reviews for a few years > >> now, and interestingly we got some complaints from people who don't want > >> to have a Github account (for various reasons) and won't use our code > >> review tool because of that. > > > > What are the reasons why people don't want to have a GitHub account? I > > wonder if that's somehow a different kind of barrier to entry to be > > concerned about. > > Maybe because it's owned by Microsoft, which is an enemy of all living things > and > basically are an embassy of Devil on Earth (no). Yes that's why I didn't elaborate much. Whichever tool you pick, there will always be people unhappy about it. In the case of Github, reasons I've heard of are (not that I agree or disagree with anything here, that's not the point): - It's not open source - It's owned by Microsoft - It has contracts with the ICE in the USA (https://www.theatlantic.com/technology/archive/2020/01/ice-contract-github-sparks-developer-protests/604339/) - It's too big and making a large part of open source work centralized in one place (mainly from people who already suffered from problems with Sourceforge or Google Code Project Hosting in the past, I guess) -- Adrien / PulkoMandy ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Transition to Git
On Fri, Oct 02, 2020 at 07:05:21PM -0500, Michael Catanzaro wrote: > > I realize that Gerrit might not integrate at all with hosting the repo > > on Github, but has any thought been given to this aspect of the > > transition? > > That sounds like it would be a significant barrier to contribution, and > frankly defeat the point of switching. If we have serious concerns with > GitHub's code review functionality (which, again, I'm not familiar with), > then we should just use GitLab and have everything in one place. (GitLab > accepts GitHub logins via OAuth, both on gitlab.com and self-hosted > instances, so the barrier to contributing remains low either way.) Gerrit accepts GitHub and other OAuth providers as well, so that's not a problem. We have been using this for Haiku code reviews for a few years now, and interestingly we got some complaints from people who don't want to have a Github account (for various reasons) and won't use our code review tool because of that. I think the integration referred to was rather in terms of having reviews synchronized between Gerrit and Github pull requests, which is also possible, but I think if the point is to use Github, it doesn't work this way: if your workflow is too different from the standard way to use Github, people will still be confused by it and it will still be a barrier to contribution. I think having to create an account on a website isn't the main thing preventing people to contribute anyway? It's more about having to use project-specific tools to prepare the patch for submission (in the case of WebKit, having to write the commit message in the Changelog file, for example). -- Adrien / PulkoMandy ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Transition to Git
> Github's code review UI has a couple of feature gaps in my opinion. It's > difficult to look at earlier versions of the pull request, in particular to > verify that issues found during code review have been fixed. I remember it > also being difficult to figure out whether all comments on earlier versions > have been addressed. > > Gerrit code review has worked well in my experience. It explicitly manages > different versions of the same patch set, and prominently shows whether all > code review comments have been addressed. > > I realize that Gerrit might not integrate at all with hosting the repo on > Github, but has any thought been given to this aspect of the transition? I agree, not only because I think Gerrit is a better tool for code review, but also because with Git, the tool you chose has a large impact on the way you work. Git provides a framework, and both Github and Gerrit use this tool to implement quite different workflows and way to manage code review and patches. I think that is possibly more important than picking an hosting place based only on its popularity, because if the tool doesn't match the way you want to work, you will workaround it and the situation will not be a lot better than it is now: you will end up with custom scripts to help sending patches the correct way, and for contributors it won't be anything like contributing to another github hosted repo anyway. That being said, in my case I can say that if the patch submission process is simplified by using standard git tools, I'm indeed more likely to consider trying to upstream the Haiku port or at least some parts of our changes. In the current situation it indeed seems easier to maintain our fork on our side instead. -- Adrien / PulkoMandy ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Introducing a minimum ICU version for WebKit
>Also, sadly ICU does not maintain a stable API or ABI. So every >application and library using ICU would need to be rebuilt and updated >at the same time. Then the update would break any custom software that >users have using the system ICU. Such an update would go badly... >probably would wind up in tech news once people notice the breakage. > Icu can be built with all its abi inside a different namespace for each version, so that multiple versions can live side by side and even be loaded in the same process without conflicts. Are Linux distros not packaging it that way? It makes updates easier as the transition can be made more gradually, at least. And it would make it possible to ship a newer icu with webkit, while not risking conflicts with the system provided one. -- Adrien. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving to Python 3
>I don’t think anyone is arguing that we’d eventually need to move to >Python3. I’m arguing that it’s not okay to require random WebKit >contributor to know some obscure python insanity to install Python 3, >or >have a script that installs Python 3 and breaks all other python >scripts in >the system. > > Python3 would normally install a "python3" executable that's independant from the "python" one from Python2? It's fairly common to have these side by side precisely because they are not compatible. -- Adrien. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Help regarding rendering in webkit2 port of haiku
On Mon, Jun 10, 2019 at 09:37:06AM +0300, Noam Rosenthal wrote: > ~ (reposting from webkit email) Hi, I should pprobably give a little more context here, as the maintainer of the WebKitLegacy port for Haiku. Our main concern, as Rajagopalan mentionned, is that Haiku does not have any rendering acceleration, it's all done in software. We do have OpenGL but it may not be the best choice for rendering, because of this. As a result, we had to find a way to get things working, in what is indeed a little unusual setup. Currently we have coordinated graphics disabled: Source/cmake/OptionsHaiku.cmake:add_definitions(-DUSE_COORDINATED_GRAPHICS=0) We do however have a software rendering version of texture mapper, that was removed from webkit long time ago but we kept because we didn't want to use the OpenGL version. I have not reviewed its use recently, maybe it is not needed anymore. Another limitation we hit on some websites is that it is not possible for us to create too many drawable offscreen bitmaps. There is a system-wide limit of 4096, which can be hit rather easily on Google Maps, for example. So we will probably need a way to limit the use of drawable bitmaps when possible. Maybe coordinated graphics would help here, if it allows to share a single drawing context and bitmap, rather than creating a separate one for each rendering layer. On the way drawing works for us: the drawing primitives are all implemented in our display server, there is no rendering done client side in webkit processes. This means the display server has a pointer to the bitmap data already, and ideally it would be able to pass this from one application to another without needing to copy all the data. We may need to make some changes to our display server to allow this, but that's fine (it's the nice thing about Haiku, if we need to change something in the OS, we can do that easily). Now we have to find out if coordinated graphics or some other way to do things makes sense, and for this we have to understand how the rendering work is split between web process and ui process, and what kind of data they expect to exchange between them. Especially in our case where the bitmap data is in fact already shared with the OS display server, so if UI process does not do any drawing by itself, it doesn't actually need to access the data. -- Adrien. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Queries regarding few Components in webkit
Hi, We are already in contact and the work will indeed be based on the Haiku fork. While I can mentor the Haiku side of the project, I think it is a good idea to rely on you all for the WebKit side of things. I hope this will allow us toget one second developer working on the Haiku port, so I can do more than just keeping our port up to date. On the current state of our port: the network backend is working, it's not perfect but we don't currently plan switching back to curl. The webkit2 work is only some very early steps and has stayed untouched for the past 4 years, so there may not be this much to recover from it. The Webkitlegacy parts are used in production, but we have not made them a public api, so that we can switch to webkit2 more easily (only our browser will need an update) Thanks for your support and answering Rajagopalan's questions! -- Adrien/PulkoMandy Haiku port maintainer ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Regarding problem in building webkit2
Hi, The Haiku ports uses its own implementation of HTTP, relying on the libraries provided in Haiku for that. We will probably not be switching back to curl. However, we have used only WebKitLegacy so far so it is expected that some parts of our network backend will be missing (everything that was not used by WebKitLegacy). -- Adrien. On Mon, Feb 25, 2019 at 06:30:11PM +, don.olmst...@sony.com wrote: > We've put a large amount of work on the cURL networking layer and are > continuing to improve it. It's used by both the WinCairo and PlayStation port > so it works cross platform. > > I'm not familiar with the stack on Haiku but it would require OpenSSL, we use > LibreSSL in both, nghttp2 for HTTP/2, and libpsl for Public Suffix List > support. You can also compile with brotli support as well for better > compression over zlib. > > -Original Message- > From: webkit-dev On Behalf Of > Konstantin Tokarev > Sent: Monday, February 25, 2019 4:25 AM > To: Rajagopalan Gangadharan ; > webkit-dev@lists.webkit.org > Subject: Re: [webkit-dev] Regarding problem in building webkit2 > > > > 25.02.2019, 14:06, "Rajagopalan Gangadharan" : > > Hello, > > > > I am trying to build webkit for haiku and I stumbled upon an error > > > > The error is in “Source\WebKit\UIProcess\WebsiteData\WebsiteDataStore.cpp” > > line 2080 says about missing platformSetNetworkParameters function and I > > saw it was defined for CURL and SOUP only. Should I use the function > > defined under them or should I write it to be haiku specific(platform > > specific) if so what should be the contents of it. Thank you! > > It depends on how your network stack works. In order to reduce maintainance > cost you should consider using network stack supported by upstream, i.e. soup > or curl > > -- > Regards, > Konstantin > ___ > 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Encoding and decoding ProcessID
On Sun, Feb 24, 2019 at 10:52:53AM -0800, Sam Weinig wrote:
> Hi Adrien,
>
> Would you mind adding the compiler output when this happens? I’d like to see
> exactly what the error you are seeing is.
Sorry, here is the compiler output:
http://paste.debian.net/1069971
In file included from
DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:5:0:
../../Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp: In static
member function 'static bool
WebKit::NetworkResourceLoadParameters::decode(IPC::Decoder&,
WebKit::NetworkResourceLoadParameters&)':
../../Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp:117:41:
error: no matching function for call to 'IPC::Decoder::decode(WTF::ProcessID&)'
if (!decoder.decode(result.parentPID))
^
In file included from
../../Source/WebKit/NetworkProcess/Downloads/DownloadID.h:30:0,
from
../../Source/WebKit/NetworkProcess/Downloads/Download.h:28,
from
../../Source/WebKit/NetworkProcess/NetworkLoadChecker.cpp:29,
from
DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:1:
../../Source/WebKit/Platform/IPC/Decoder.h:80:10: note: candidate: bool
IPC::Decoder::decode(bool&)
bool decode(bool&);
^~
../../Source/WebKit/Platform/IPC/Decoder.h:80:10: note: conversion of
argument 1 would be ill-formed:
In file included from
DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:5:0:
../../Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp:117:32:
error: cannot bind non-const lvalue reference of type 'bool&' to an rvalue of
type 'bool'
if (!decoder.decode(result.parentPID))
~~~^
In file included from
../../Source/WebKit/NetworkProcess/Downloads/DownloadID.h:30:0,
from
../../Source/WebKit/NetworkProcess/Downloads/Download.h:28,
from
../../Source/WebKit/NetworkProcess/NetworkLoadChecker.cpp:29,
from
DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:1:
../../Source/WebKit/Platform/IPC/Decoder.h:82:10: note: candidate: bool
IPC::Decoder::decode(uint8_t&)
bool decode(uint8_t&);
^~
../../Source/WebKit/Platform/IPC/Decoder.h:82:10: note: conversion of
argument 1 would be ill-formed:
In file included from
DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:5:0:
../../Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp:117:32:
error: cannot bind non-const lvalue reference of type 'uint8_t& {aka unsigned
char&}' to an rvalue of type 'uint8_t {aka unsigned char}'
if (!decoder.decode(result.parentPID))
~~~^
In file included from
../../Source/WebKit/NetworkProcess/Downloads/DownloadID.h:30:0,
from
../../Source/WebKit/NetworkProcess/Downloads/Download.h:28,
from
../../Source/WebKit/NetworkProcess/NetworkLoadChecker.cpp:29,
from
DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:1:
../../Source/WebKit/Platform/IPC/Decoder.h:84:10: note: candidate: bool
IPC::Decoder::decode(uint16_t&)
bool decode(uint16_t&);
^~
../../Source/WebKit/Platform/IPC/Decoder.h:84:10: note: conversion of
argument 1 would be ill-formed:
In file included from
DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:5:0:
../../Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp:117:32:
error: cannot bind non-const lvalue reference of type 'uint16_t& {aka short
unsigned int&}' to an rvalue of type 'uint16_t {aka short unsigned int}'
if (!decoder.decode(result.parentPID))
~~~^
In file included from
../../Source/WebKit/NetworkProcess/Downloads/DownloadID.h:30:0,
from
../../Source/WebKit/NetworkProcess/Downloads/Download.h:28,
from
../../Source/WebKit/NetworkProcess/NetworkLoadChecker.cpp:29,
from
DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:1:
../../Source/WebKit/Platform/IPC/Decoder.h:86:10: note: candidate: bool
IPC::Decoder::decode(uint32_t&)
bool decode(uint32_t&);
^~
../../Source/WebKit/Platform/IPC/Decoder.h:86:10: note: conversion of
argument 1 would be ill-formed:
In file included from
DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:5:0:
../../Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp:117:32:
error: cannot bind non-const lvalue reference of type 'uint32_t& {aka unsigned
int&}' to an rvalue of type 'uint32_t {aka unsigned int}'
if (!decoder.decode(result.parentPID))
~~~^
In file included from
../../Source/WebKit/NetworkProcess/Downloads/DownloadID.h:30:0,
from
../../Source/WebKit/NetworkProcess/Downloads/Download.h:28,
from
../../Source/WebKi
[webkit-dev] Encoding and decoding ProcessID
Hi there, We are finally starting to look into moving the Haiku port to WebKit2. We have hit one little problem I'm not sure how to solve. Our pid_t on 32bit Haiku is declared as a signed long integer (this is for legacy reasons and not something we can fix easily). Our uint32_t is a signed integer (not long). This creates a compilation error when using pid_t with IPC::Encoder, because none of the encode() functions match when trying to pass a pid_t in our case. Our options seems to be: - Cast pid_t to int32_t when encoding it. I fear this would break other platforms if they decide to use a 64bit pid_t, for example - Add an encode(pid_t) to the IPC::Encoder. I fear on other platforms it would complain that this is the same as encode(int32_t) and break the build - Define WTF::ProcessID as int32_t instead of pid_t, which I think could work, afte rfixing some compiler warnings (we will need to cast back to pid_t when passing it to OS functions, I think) What do you think about it? one example where encoding a pid is Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp -- Adrien. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit opengl
2017-08-02 14:43 GMT+02:00 Gustavo Sverzut Barbieri : >> 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. The Haiku port also uses no OpenGL. I have versions of CoordinatedGraphics and TextureMapper extracted from old verisons of WebKit which I maintain with the port (TextureMapperImageBuffer is the entry point for that): https://github.com/haiku/webkit/blob/rebased/Source/WebCore/platform/graphics/texmap/TextureMapperImageBuffer.cpp The commit which restores this may serve as a reference (but may not apply directly to current sources): https://github.com/haiku/webkit/commit/966df671f60cc716233952c5e80c5fd52d6ce785 -- Adrien Destugues / PulkoMandy http://pulkomandy.tk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?
> Some others I see: > > ENABLE_GEOLOCATION > ENABLE_INDEXED_DATABASE > ENABLE_CSS_SCROLL_SNAP > ENABLE_WEBGL > ENABLE_WEB_AUDIO At least these are still not implemented in the Haiku port. I know we are not an upstream port anymore and have little chance of being again as I'm slowly trying to catch up with the lates 1.5 years of development in WebKit. But having to implement all of these would delay my work even more. As usual, I don't want the Haiku port to pull WebKit backwards, and I do plan to implement some of these at some point. However, being able to disable them at least for some time lets me work on other, more important aspects of the port first. If the compile time flags are too annoying for that, maybe an alternative would be to provide stub implementations, but then support for these features should still not be advertised to webpages if the port really doesn't support them. -- Adrien Destugues / PulkoMandy http://pulkomandy.tk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
