> On Oct. 23, 2013, 2:40 p.m., Chusslove Illich wrote: > > I can only say that whatever is the proper fix here, it is fine with me. > > Since non-installed headers are being used, maybe ki18n is using KJS in a > > way which became deprecated somewhere along the way? If so, I've nothing > > against fixing that instead. > > > > Aleix Pol Gonzalez wrote: > Well the thing is that ki18n was using private API (since it was in the > same module, kdelibs). > > Aurélien: what about installing these headers in a private/ directory? > > Chusslove Illich wrote: > If I recall, when implementing that I mimicked what khtml was doing. > And apparently is still doing. > > > Aleix Pol Gonzalez wrote: > khtml is in kdelibs as well, nobody has tried to build it standalone just > yet, I guess. > > Chusslove Illich wrote: > Right, but, how is then KJS supposed to be used in a different way? Are > these private headers really private, or actually necessary to use KJS as > a > JS interpreter in random client code? > > > Aurélien Gâteau wrote: > The ideal solution would be for ktranscript to only use public headers, > but I assume there is no way to do so (I haven't taken the time to study > ktranscript enough to understand what it does), Chusslove, it would be > awesome if you could have a look at it. > > If it is definitely not possible, then I am going to update my changes to > install to a private/ directory, like Aleix suggests. > > Aurélien Gâteau wrote: > Actually, the even more ideal solution would be for ktranscript to use > QtScript instead of KJS. In the future we will have more and more > applications developed with QtQuick, so they will already link to QtScript, > loading another JavaScript interpreter sounds wasteful to me. Do you think > this is doable? I would be quite interested in helping making it happen. > > Aurélien Gâteau wrote: > Mmm, actually I am wrong, QtScript is provided for Qt 4.x compatibility, > QtQuick uses the QJS* classes from QtQML, so this is what we should be using. > > Kevin Ottens wrote: > I would definitely welcome such a port... I remember asking ktranscript > to be ported away from KJS. Would also make ki18n tier 1. > > Aurélien Gâteau wrote: > I started diving into this today. No change for now, but I wrote some > unit tests for ktranscript, so that a qjs port can be evaluated. Patchset is > here: http://agateau.com/tmp/ki18n-qjs.patch but it's missing loads of tests > for now. Chusslove: would you be interested in extending the test coverage? > > Chusslove Illich wrote: > Yes, I most certainly would be interested in extending the test coverage. > But I intended to do it "full-range", that is starting from test PO files > (which are already there), once I get to it. And first I need to document > it > better :) Currently all there is is this wiki page: > http://techbase.kde.org/Localization/Concepts/Transcript > > As for the port away from KJS, I have to state again that I see no value > in > that. Having ki18n be tier 1 is of no use: if someone is so tight on > dependencies that using a tier 2 framework is a problem, then ki18n is the > first thing to dump in favor of built-in Qt translation system, tier 1 or > not. Note that ki18n also brings into play all the Gettext tools, as > opposed > to self-contained Qt translation tools. The only possible advantage of > ki18n > in tier 1 is that it can be used by tier 2 frameworks, of which there is > not > much by my estimate (and between tier 1 and tier 3, I also fail to see the > reason for existence of tier 2). > > > Aurélien Gâteau wrote: > There is value in both full-range tests and tests exercising smaller > parts of the code as well IMO. > > Thanks for the link, I am going to look at it. > > Regarding the port to QJSEngine, I see the following advantages to it: > - It solves the build issue I have been trying to fix with this request: > no need for uninstalled headers anymore. > - The code is going to be simpler: from what I read of QJSEngine and KJS, > exposing an object using QJSEngine is simpler than with KJS: no need for > lookup tables or things like that, just a QObject with slots. > - I expect QJSEngine to be better maintained than KJS, given that it is > the backbone of QtQuick. > - Having ki18n in tier1 would make it more attractive to Qt developers > since it brings superior translation support. Right now the cost of dragging > in a separate JavaScript interpreter, can be perceived as a burden especially > for QtQuick developers.
Yes, it's not only about the tiers (it's just a nice side-effect). But it's clear that at that point ktranscript is built on top of something huge and unmaintained. It'd be safer built on top of something with proper maintenance if possible. - Kevin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113402/#review42222 ----------------------------------------------------------- On Oct. 23, 2013, 2:30 p.m., Aurélien Gâteau wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113402/ > ----------------------------------------------------------- > > (Updated Oct. 23, 2013, 2:30 p.m.) > > > Review request for KDE Frameworks. > > > Repository: kdelibs > > > Description > ------- > > KI18n depends on KJS to build the ktranscript plugin. This plugin requires an > internal KJS Perl script as well as headers which were not installed. > > This is a 3-commit patches, which does the following: > > 1. Install kjs headers > > 2. Install wtf headers, using wtf/ and kjs/ in include directives (because > some kjs headers includes wtf headers) > > 3. Fix KI18n: > - Format top-level CMakeLists.txt according to CMake template > - Duplicate KJS create_hash_table script > - Add call to find_package(KJS) > > Individual patches available from > http://agateau.com/tmp/ki18n-standalone.patch > > > Diffs > ----- > > superbuild/CMakeLists.txt 5cdec94 > tier1/kjs/src/CMakeLists.txt 8629716 > tier1/kjs/src/kjs/CMakeLists.txt 9523e89 > tier1/kjs/src/wtf/CMakeLists.txt 83b4417 > tier1/kjs/src/wtf/FastMalloc.h 29a72a5 > tier1/kjs/src/wtf/HashCountedSet.h be3c387 > tier1/kjs/src/wtf/HashFunctions.h f665447 > tier1/kjs/src/wtf/HashMap.h ba2971c > tier1/kjs/src/wtf/HashSet.h e84b349 > tier1/kjs/src/wtf/HashTable.h 0b2c22c > tier1/kjs/src/wtf/HashTable.cpp e08d09a > tier1/kjs/src/wtf/HashTraits.h 4d01726 > tier1/kjs/src/wtf/ListRefPtr.h 0a704d8 > tier1/kjs/src/wtf/OwnArrayPtr.h 3b77871 > tier1/kjs/src/wtf/OwnPtr.h 188a1dc > tier1/kjs/src/wtf/PassRefPtr.h 25b9906 > tier1/kjs/src/wtf/RefPtr.h 493ab05 > tier1/kjs/src/wtf/Vector.h 9b0f38a > tier1/kjs/src/wtf/VectorTraits.h 31ae028 > tier2/ki18n/CMakeLists.txt 4cc8e30 > tier2/ki18n/src/CMakeLists.txt 7f8259b4 > tier2/ki18n/src/create_hash_table PRE-CREATION > > Diff: http://git.reviewboard.kde.org/r/113402/diff/ > > > Testing > ------- > > Builds within kdelibs and standalone. > > > Thanks, > > Aurélien Gâteau > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
