[Webkit-unassigned] [Bug 16401] [GTK] GObject/C DOM binding
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Dec 31 07:52:27 PST 2008
------- Comment #117 from lkcl at lkcl.net 2008-12-31 07:52 PDT -------
(In reply to comment #91)
> (In reply to comment #88)
> > (In reply to comment #87)
> > > [DontEnum] DOMString toString();
> > > #endif
> > >
> > > worry about.
> > i do keep explaining - but it's been a while so i will explain it again:
> > one-for-one, concept-for-concept, function-for-function, class-for-class,
> > attribute-for-attribute equivalence (as closely as possible).
> In that case, your objective is not the same as the objectives of the DOM
> bindings in WebKit. As I have stated, they are designed to wrap the standard
> compatibility with other browsers.
and, logically by extension, webkit being a browser engine, all applications
without fail and without exception on _all_ bindings, such that all
applications work from the same "standard".
even if it's a damn stupid one that's dictated by real-world stupidity
rather than a clean design from W3C.
i'm fully aware of that. however, that has nothing to do with the
DOM _standard_ being over-ridden by IE5, IE6, IE7, IE8, Firefox, Mozilla
all getting that DOM standard completely wrong, thus forcing the
be subtly different.
> I don't think the argument that a developer expects
well the fact that you don't see that means that the pyjamas-desktop project
must be terminated, as there is absolutely zero point in proceeding to use
webkit (the best and currently only reasonable and viable option to providing
python bindings to a fully-functioning DOM model).
so - thank you: the fact that you are unable to see that means that apple
is responsible for destroying the progress of free software development.
> We've had no complaints of this nature, about the Objective-C DOM
> bindings in the many years that they have been part of the project.
i would consider that to be an indication that no serious objective-c
DOM project has ever been developed - certainly not one that covers
almost 100% of the functionality of the DOM model.
the pyjamas-desktop project covers quite literally absolutely every
corner of the DOM model: when porting pyjamas to pyqt4, that failed
because of limitations in pyqt4. when porting it to pygtk2, that failed
even quicker, due to more significant limitations. when porting it to
python-pykde, _that_ turned out to have really subtle limitations
(c++ RTTI has been disabled, and the equivalent of the HashMap in
JSBindings.cpp and GDOMBindings.cpp utterly relies on RTT) and so _that_
port failed as well.
due to the nature of what pyjamas-desktop is, it squeezes every corner of
its underlying technology until the pips squeak.
> > the same thing goes for the "constructors" (if i can get my head round why
> > they're used).
> Are you seriously arguing that you must have something that you don't
> for other DOM bindings.
> > the same thing also goes for the suggestion that you made that i should
> > provide only "integer" input to setWidth() and other functions, because that's
> > what ObjC does.
> > the answer's "no - absolutely not". people who expect to pass in "3em",
> > "10px", "50%" will get a nasty shock.
> As I have already stated, people that try and set .width or .height "3em" will
> that it does.
the _same_ nasty shock from the gobject bindings _great_.
bug-for-bug. feature-for-feature. nasty-shock-for-nasty-shock.
as the guardians of webkit, it's not our job to "care" what happens.
> > and yes, i really really _do_ need toString() because it's actually _used_ in
> > the pyjamas-desktop DOM.py module.
> This argument doesn't carry much weight, as it could be used to get *any*
> change in to WebKit.
i don't know how to respond to this.
you seem unable to accept reasonable real-world usage as justification
for providing specific functionality, without which the project i'm working
on - the only example and _the_ leading free software example - is dead.
gecko's language bindings provide toString.
python-pykde, KHTMLPart's language bindings provide toString.
why are you "dictating" that the webkit gobject bindings should _not_ have
toString, when you are being _specifically_ told that a project _needs_ that
> It can be generalised to: "I've written some code in
> another project that depends on my work-in-progress patch, therefore you have
> to accept this change in to WebKit in order to not break that code."
it's not about "breaking" that code - that "code" is DEAD without it.
> native DOM methods to return the same data.
> Applications using the native DOM
> bindings can simply use the appropriate methods to retrieve this information.
so, i must write some code, "if in pyjamas-desktop, the library being used
equals webkit, and the object does not have a toString function, then detect
what type it is and then from there work out the quotes appropriate method
quotes' else if the library being used is python-gecko, call the toString
function, else if the library is python-pykde, call the toString function".
not going to happen.
please ask the gecko developers to remove toString from their language
bindings, and see how far you get.
please also ask the KDE KHTML developers to remove toString from their
language bindings, and see how far you get.
> > into DIRECT and IDENTICAL function calls (in python) that end up calling the
> > webkit-glib bindings.
> > if i get *any* discrepancies (such as not having toString), then all of a
> > sudden i'm screwed, because there's a difference between the pyjamas code
> I think you need to keep in mind that DOM bindings in WebKit do not exist
> solely for the benefit of your project.
i'm well aware of that.
> Your project, as the first user of the
> DOM bindings, certainly influences what the initial cut will support, but it in
> no way defines what they *must* support.
you are being dictatorial, unreasonable, and deliberately obstructive.
why do you _care_ whether there is a toString function that some NONEXISTENT
projects may or may not use, ESPECIALLY when the ONLY project - that obviously
happens to be the first - is TELLING you it needs that function, and is TELLING
you that all OTHER language bindings provide that function?
why do you _care_ about _deliberately_ sticking to the W3C DOM standards, when
you're being told that to do so will result in failure of a project?
is there something that you're not telling us? are you being _paid_ or being
instructed by your employer to be deliberately obstructive, and to delay or
otherwise scupper the usefulness of the gobject DOM bindings? because that's
the only possible explanation that i can think of that makes any sense.
the other possibility is that you're being obstructive just for the sake of
it, to gain some feeling of power or something.
instead of dictating what should or should not be in the gobject bindings,
which you have _no_ experience of using and the use of which is _not_ in your
area of expertise, you should be encouraging this first project that uses them
to be successful, as the leader and pathfinder.
i am perfectly happy to listen to your advise and to learn from your expertise
in the inner workings of webkit - your expertise and knowledge of the
ref-counting and other technical areas has been absolutely invaluable, and in
many other areas as well.
however, for you to respond to reasonable justification for specific features
with "that could be a justification to put _anything_ into webkit" is
it's called "moving the goalposts", so that you "win".
you want to "win" - and be a bully while you're at it.
i'm sorry to have to be pointing these things out - i really wish i didn't
have to be the one to draw these conclusions. but anyone reviewing these
records will be able to draw the same conclusions, and likewise wonder why
you're being unreasonably obstructive.
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the webkit-unassigned