Re: [webkit-dev] GDOM patch spam
webkit-dev-ow...@lists.webkit.org to me show details 10:12 am (10 minutes ago) You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at webkit-dev-ow...@lists.webkit.org. -- Forwarded message -- From: lkcl luke.leigh...@gmail.com To: webkit-dev@lists.webkit.org Date: Fri, 14 Aug 2009 03:12:00 -0700 (PDT) Subject: [webkit-dev] Completing the goal of Webkit DOM bindings [was Re: GDOM patch spam] Eric Seidel-6 wrote: I just closed out many of the GDOM bugs for patch spam after emailing the author of these patches. eric, it falls to me, because nobody else is going to do it, to hold up a mirror and to show you the implications of what you've just said. you have said, i just aggravated the process of achieving the goal of useful and useable webkit gobject bindings , by calling the combined contributions of many experienced developers 'Stupid Postings And Mailings' ... as you work for google, is that an official position of google, to insult martin soto's work, helmut's work, alp toker's work, my work, and many other contributors, by calling their contributions stupid? Eric Seidel-6 wrote: The proper process for getting code into WebKit does not involve uploading 15 unexplained patches at once. this again does not contribute to the goal. let's track it through. 1) david suggested that #16401 be split into smaller patches. 2) faithfully following the instructions and the process, you and i worked very well together to get several of those patches to an acceptable standard 3) you asked that one of them be split further. 4) faithfully following the process, i split them further, and created a series of patches, citing our conversation at the top of each of them. 5) having created the bugreports, i take the bugreport numbers and place them into the CHANGELOG entries, in order to comply with the process. 6) mark rowe ignores the link to the conversation and closes all of the bugs _before_ the attachments have been uploaded. how _exactly_ is this _not_ faithfully following the process, eric? this is not a rhetorical question. Eric Seidel-6 wrote: That tends to result only in annoying reviewers and getting you banned from the bug tracker. :) i know you think you are meaning well by adding a smiley, but in this instance it's not a good indication of your state of mind. firstly, quoting a very wise person i know: stress is where the mind compares the external view with the internal one; finds that the discrepancy is too great and seeks to place blame on the EXTERNAL world. so - let's translate what you've put: That tends to result only in the reviewers comparing their view of how the review process should be, against the way that it is being used in good faith, having a feeling of annoyance and the reviewers then BLAMING the submitter. in fact, the reviewers feel that it is SO important that their view of how the review process be rigidly adhered to that if anyone else causes them a feeling of annoyance, they will BAN that submitter from the bug tracker. i, eric seidel, find this to be very very funny and amusing. how, exactly, eric, is insulting contributors by calling their contributions stupid, and by declaring up-front that anyone who does not stick rigidly to a process ( a process which was never designed with such a comprehensive contribution in mind that requires a _dozen_ separate programming skills as well as the infinite patience of a saint ) - anyone not sticking rigidly to the process will be BANNED, how exactly is this funny? this is not a rhetorical question. much _much_ more importantly, how does such a statement _contribute_ to the completion of the goal? Eric Seidel-6 wrote: The GDOM binding patches have some history of trouble. translation: the attitude of some of reviewers has been shockingly disrespectful towards enthusiastic and highly skilled contributors, and they have sought to engineer ways in which the submitters can be blamed, outright, for absolutely everything. the reviewers consider themselves to be unimpeachable and above-board in every way. the contributors have been caught completely off-guard by the hostile attitude, and initially reacted very badly, but after consideration decided to continue - even in the face of absolutely shockingly bad attitudes of some of the reviewers, in the interests of free software and in the interests of completing the goal. summary: yeah. trouble. Eric Seidel-6 wrote: I think if anyone wants to work on GDOM patches they need to talk to one of the long-standing Gtk contributers and approach this one patch at a time. great. i will contact them, immediately. i trust that all contributors will be given the respect that should always go without saying, in working towards a common goal, and i trust
Re: [webkit-dev] WebKit partial rendering issue
https://bugs.webkit.org/show_bug.cgi?id=25696#c2 thanks to paul for the guidance and for the leading work / patches on which this is based, paul, the code that you sent me has a bug where the scrollbars on a frame will go blank and disappear when you move the mouse over them. the reason is that the empty rect causes the return out of the paint function, prematurely, i fixed this by allowing the scrollbars always to be painted. if anyone can think of a better way to do this other than to comment out code (even though it can be demonstrated as completely broken) that'd be great. testing this i used http://pyjs.org/showcase/Showcase.html then click on Frame (left-hand-side) and then shrink the browser window to 800 pixels to get a horizontal scrollbar in the frame as well. with the patch from the above link, everything's fine. paul, chris, your help was _really_ appreciated. the client will be well-'appy. l. -- View this message in context: http://www.nabble.com/WebKit-partial-rendering-issue-tp20721190p23564079.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit partial rendering issue
Paul Pedriana-3 wrote: The ScrollView::paint function seems wrong to me too. The function source is shown below. I don't understand why it uses context-clip(visibleContentRect()) without accounting for documentDirtyRect. Shouldn't it make a union of visibleContentRect and documentDirtyRect? I am writing my own graphics back-end and this lack of clipping is messing up the view drawing. paul, hi, there's a lot more corruption going on than just a few artefacts around buttons - see https://bugs.webkit.org/show_bug.cgi?id=25696 for more details but basically scrolling with mouse or keyboard _completely_ trashes the screen, with artefacts appearing in blue or black or from random memory areas. this is something of a showstopper for an embedded app project so if you or anyone else have any clues as to what needs to be done, fixing this, that would be great. paul if you have some patches already that would be great. l. -- View this message in context: http://www.nabble.com/WebKit-partial-rendering-issue-tp20721190p23487095.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Equivalent of WebKit/Qt's link delegation policy in WebKit/Gtk+?
Andrew S. Townley-3 wrote:
Hi,
I'm trying to work with the GTK+ WebKit from svn/trunk to do rendering
for my application. Unfortunately, I'm having some troubles.
Unlike the majority of users, I don't need WebKit to access URIs on the
Internet. I need to be able to intercept them and display custom HTML
content to allow navigation of some complex, in-memory data structures.
hi andrew,
so (summarising from previous posts) you need to support {makeupaurl}://
what that would tend to suggest, therefore, is that you create a customised
version of libcurl which supports your own formatted urls.
this brings me back to the issue i raised a few months ago of clean
library design - the one about vector-tables.
what webkit _should_ be doing is, instead of linking against curl (and thus
forcing people to use or rewrite curl) is to have a function which passes in
a pointer-to-a-struct-containing-pointers-to-all-of-curls-functions:
extern C {
/* whatever these are supposed to be, matching libcurl headers, make it so
*/
typedef (*curl_open_fn_t)(void* state_info, char *url, ...);
typedef (*curl_read_fn_t)(void*state_info, int len, char *buf);
struct libcurl_functions {
curl_open_fn_t *open_fn;
.
};
void WebKitInitCurlLibrary(struct libcurl_functions *vector_table);
} /* extern C */
doing things this way has the important side-effect of making all AJAX calls
go through the external (customisable) library, not just open a page.
in this way, it would be possible for example for pyjamas-desktop to add
python:// as a URL, or to provide a URL type where filesystem access to
/home/accountname/whatever was actually _allowed_ - for certain small
portions of allow.
also, it's rather inconvenient for a desktop-based loader, where the code is
loaded off of /home/username/source_file.html to then be banned from
accessing the internet, just because the source code for the application was
loaded from the user's desktop. especially when the access being done is
AJAX.
the rather daft workaround that has to be done is that the desktop-based
loader goes and loads the source_file.html from
http://127.0.0.1/workaround_appplication_url/source_file.html - with other
portions of http://127.0.0.1 doing ProxyPass Redirects!
which is all a bit ridiculous, involving Apache2 in the equation, when with
a tiny bit of effort, libcurl could be even be dropped-out at runtime and a
replacement dropped in (dso loaded).
l.
--
View this message in context:
http://www.nabble.com/Equivalent-of-WebKit-Qt%27s-link-delegation-policy-in-WebKit-Gtk%2B--tp20072050p22180940.html
Sent from the Webkit mailing list archive at Nabble.com.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] C++ API access to DOM tree [Win32]
Nirman Kumar wrote: Hi, how can I access the DOM from C++ APIs on Windows. Many methods like nirman, hi, if you don't mind it being a _little_ bit awkward, use the gobject c-based bindings: at least they're reasonably complete. i've just been sending samples to the list. https://bugs.webkit.org/show_bug.cgi?id=16401 make sure you use _both_ these patches: https://bugs.webkit.org/attachment.cgi?id=25618 https://bugs.webkit.org/attachment.cgi?id=25671 l. -- View this message in context: http://www.nabble.com/C%2B%2B-API-access-to-DOM-tree--Win32--tp20903906p20922151.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving forward with Gtk
Phoenix Revived wrote: I am trying to write a browser that uses a remote controller for input. I also need the DOM stuff working. If nothing hapens soon, I may have to abandon Webkit/Gtk and either use mozilla's crappy API or do my own home-brewed stuff. I have also been playing with Jonothan's webkitmmm, but without the underlying API in Gtk, that doesn't take me much further either. hi phoenix, the DOM manipulation - glib bindings - are available as a git repository, branch-snapshotted from webkit svn from about six weeks ago: http://github.com/lkcl/webkit/tree/16401.master this version i know works. auto-generating python bindings using codegen.py was a matter of minutes of work - literally. i would be terribly surprised if webkitmm bindings took more than a couple of hours of work. sadly, no funding has been made available to help advance the webkit-glib patch #16401, so i am leaving it alone, not having any (financial - direct by contracting or indirect by work-related project) incentive to actively work on it. much as i would like to see webkit-glib advance, the billion-dollar companies whose profits are increased through the improvement of webkit have got to learn that spongeing off of unpaid and highly skilled free software developers is not really acceptable. l. p.s. if, however, a truly free software project needs the benefit of webkit-glib bindings - one that isn't funded by large corporations (google, adobe, apple, redhat, novell etc.) who can pay for the work - and you're working on that truly free software project and reading this - please do contact me, and i will be more than happy to continue. -- View this message in context: http://www.nabble.com/Re%3A-Moving-forward-with-Gtk-tp20284608p20443812.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving forward with WebKit/GTK+
Gustavo Noronha Silva-5 wrote: The fact that WebKit/GTK+ doesn't go forward is starting to harm its momentum in the GNOME community, from my point of view - Epiphany is already having to decide if they take back the decision to move from Gecko to WebKit that would be most unfortunate. the webkit framework is blindingly quick, and, in my opinion, superior to gecko. I can think of various options; forking the tree and trying to advance it outside of the main repository being the one I like the least. What I not being funny or anything, but i believe that if you kept the gtk port separate from webkit, and webkit as a library was cooperative in this regard, that things would definitely improve. the core of webkit is port-independent. reliance on apple's infrastructure to advance the webkit-gtk port is clearly not going anywhere, as people believe that changes to the webkit-gtk infrastructure somehow blur over to impacting webkit-core, which... can't happen, but people believe that it might. by separating out the webkit gtk code into a separate project that has -lwebkit as a build dependency it makes it abundandly clear that there is no such impact, and, importantly, it would free the gtk port from apple's grasp. so - yep, i'd recommend that you go ahead, and fork _just_ the subdirectories that contain gtk/ in them. also, what's nice about that is that you no longer have to do #ifdef WEBKIT_GTK or other trickery. l. -- View this message in context: http://www.nabble.com/Moving-forward-with-WebKit-GTK%2B-tp20213879p20443597.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit core need to be cleanly separated from ports, behind a vector table
Paul Pedriana-3 wrote: While a COM or similar interface may result in a library which makes porting easiest for new platforms, it sometimes can be harder to develop and maintain. We've been there and I can say that in some cases an earlier reply mentioned also that the idea i suggested is COM-like, and, thus, if that is _believed_, then yes, absolutely, it will be found to be a complete nightmare. background: COM is an object-orientated layer that allows you to define objects. the COM part of Common Object Model is incredibly similar to what GLib / GObjects have become (right down to the horrible c macros, the object refcounting, the interfaces, the object inheritance, everything). COM is a stripped-down version of DCOM (distributed COM) where the much-hated windows 95 team got a hold of the much-better-trained windows nt team's code, and ripped it to shreds. what the windows 95 team took out was the D - DCE/RPC. DCE/RPC is a functional-programming style RPC system (and is a perfect candidate for building object-orientated technology, such as DCOM, on top of it). it is _this_ technology that is *purely* c-based and is RPC middleware, and it's unbelievably brilliant beyond belief. in DCE/RPC, there is support for interface versioning, where each interface can have a single 16-bit number - a version - associated with it. servers are expected to support all versions of interfaces, and thus you can upgrade the servers first, and the clients last. so, to cut a long story short, when the earlier poster said yes, you're suggesting that we implement a cut-down version of COM - no, not exactly, but close. all you do is shove a 16-bit number at the beginning of the struct, that says version 1. that's all. _definitely_ not drag in all the object inheritance, ref-counting. _god_ no. :) -- View this message in context: http://www.nabble.com/webkit-core-need-to-be-cleanly-separated-from-%22ports%22%2C-behind-a-vector-table-tp19982522p20167648.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit core need to be cleanly separated from ports, behind a vector table
Gustavo Noronha Silva-5 wrote: On Wed, 2008-10-15 at 08:04 +, Luke Kenneth Casson Leighton wrote: While I agree that it would be nice to have a separate library to which both the GTK+ and Qt ports could link, for instance, I believe this model would somewhat remove the agility the project has of refactoring and redesigning big parts of the code. API stability would be something to worry not only for the most outern layer (the port), and that would complicate matters. gustavo, thanks for responding. question: how so? [would it remove agility for refactoring and redesigning]? what is there about, for example, the apache2 vector table system, where you fill in 28 or so functions in a vector table and hand it back to the apache runtime, that makes refactoring and redesign difficult? extensions to the table can be done by having a union of structs, with an int at the beginning of the table saying i'm a version 1 or i'm a version 2. then, if you have a version 1-using-port that connects to a version 2 library, the extra functions that differ from version 1 and 2 will be NULL; the version 2 webkit library will go oh, these are NULL, so we're not providing version 2 functionality. far from making it _more_ difficult to do a redesign, such techniques would make it _easier_ i believe. you could add in refactored functions into the version 2, support both for a while, then, when sufficient time has passed, drop the version 1 functions. and, during the transition period, users would be able to mix-and-match version-1-using apps with version-2 of the webkit library, and not care in the slightest. ... am i missing something? l. -- View this message in context: http://www.nabble.com/webkit-core-need-to-be-cleanly-separated-from-%22ports%22%2C-behind-a-vector-table-tp19982522p19996413.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
