Re: [webkit-dev] Deployment of new EWS Non-Unified builder
If I may add, On Thu, 2022-09-08 at 02:27 +, Alexey Proskuryakov via webkit-dev wrote: > With non-unified EWS: > - many patches get rejected for breaking it; > - it's easy for the patch author to add the includes. - over time, by force of habit /less patches break/, as contributors become more aware of the need to check they add includes properly, in the same way that developers get used to follow coding style to avoid style errors. Claudio ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Deployment of new EWS Non-Unified builder
On Wed, 2022-06-01 at 16:39 -0700, Ryosuke Niwa via webkit-dev wrote: > One day per month for one beginner sounds like a really low > maintenance cost compared to having every WebKit developer fix non- > unified builds at all times. I'm sorry, but this is not about having "every WK developer fix non- unified builds at all times", it's about everyone making sure that their patches are correct. A patch that uses API in one file without making sure the required headers are included is not a correct patch and unified builds are only hiding the issues. I don't see how this can be controversial. Also, there is no pool of beginner developers who can be fixing missing includes all the time; even if we had spare manpower, it's more beneficial for the project (and themselves) if they spend that time doing gardening or fixing actual bugs. Claudio ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Reducing globals
On Thu, 2018-12-20 at 17:12 -0800, Alex Christensen wrote: > It’s been three weeks. Is anyone maintaining the soup or curl > loading code? If the main concern is the usage of NetworkProcess::singleton(), turns out that in the end this patch is all that is needed https://bugs.webkit.org/show_bug.cgi?id=193444 to stop using it in the soup code. Was there anything else that needs cleaning up? Claudio ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Reducing globals
On Thu, 2018-12-20 at 17:12 -0800, Alex Christensen wrote: > It’s been three weeks. Is anyone maintaining the soup or curl > loading code? I've started on the soup work locally but I've been swamped with other things and now it's time for the holiday break. I'll retake it in January. Claudio ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Reducing globals
On Thu, 2018-11-29 at 18:15 -0800, Alex Christensen wrote: > I am embarking on a journey to reduce the number of global variables > and singletons we use instead member variables on the proper > objects. Feel free to join! > > Specifically, I’m looking into reducing the number of members in the > NetworkProcessCreationParameters structure. Many of them need to go > to NetworkSessionCreationParameters instead. Could those maintaining > the libsoup and libcurl networking implementations please lend a hand > and move the members enclosed in USE(SOUP) or USE(CURL)? I have done > similar moves in https://trac.webkit.org/changeset/238654/webkit and > https://trac.webkit.org/changeset/238630/webkit if you would like a > pattern to follow. Thanks for the reference. I'll have a look at the libsoup members whenever I have some time. Claudio ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Clipboard API and events
Hi, It seems to me that this API is missing from WK. Is there a reason for this other than "nobody has stepped up yet"? Claudio ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Can we remove Notification.show()?
On Thu, 2013-02-07 at 13:55 +0100, Andrew Wilson wrote: > It should definitely not be necessary to call Notification.show(), > although I have not removed that API since I am busy with some other > tasks currently. What browser/WebKit revision are you using? You're right. It's a fairly recent master, though I am implementing web notifications support in the GTK+ port so I'm probably overlooking something in there, my bad. > What's the status of this? Apparently it is still necessary to > call Notification.show() after a notification is created. Are > you tracking this in a bug report? Just noticed https://bugs.webkit.org/show_bug.cgi?id=108066 . Claudio ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Can we remove Notification.show()?
On Mon, 2013-01-28 at 10:35 +0100, Andrew Wilson wrote: > So, we've recently landed some fixes to address permissions handling > for Notification.show(): http://trac.webkit.org/changeset/140927 > > Turns out, the notifications specification does not have a show() API > (the notification is automatically shown from the constructor > -- http://notifications.spec.whatwg.org/#api). Does anyone have any > objections to moving the show() API under the > ENABLE_LEGACY_NOTIFICATIONS flag to bring us under compliance with the > spec? What's the status of this? Apparently it is still necessary to call Notification.show() after a notification is created. Are you tracking this in a bug report? Claudio ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit2GTK+ breakage due to removal of WKPageResourceLoadClient
On Mon, 2013-01-21 at 15:27 +0100, Xan Lopez wrote: > On Mon, Jan 21, 2013 at 2:53 PM, Mario Sanchez Prada > wrote: > > Hi, > > > > (...) > > > > > If anyone could drop some light on this issue or provide some pointers to > > better understand the motivation of this change, I’d really appreciate that. > > I understand rolling r140285 might be not the best option at this point, yet > > I’d personally rather not keep the WebKit2GTK+ broken for too long. > > As has been discussed in the list (see > http://lists.webkit.org/pipermail/webkit-dev/2013-January/023255.html) > the new development model for WebKit2 basically means this can happen > at any time, and the broken pieces are for each port to keep and put > back together. So I doubt reverting the patch is an option (in fact > this is essentially the intended result of the new policy), we just > need to figure out how to deal with this as fast as we can (which I > think will be "too long" by any reasonably standard, but such is > life). For the time being it looks to me that the only sensible thing to do is to just remove the WK2 API so that the port builds and then find a way to provide a replacement. Not an elegant solution but this is the brave new world we live in! Claudio ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
