> On Oct. 23, 2013, 4: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?
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). - Chusslove ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113402/#review42222 ----------------------------------------------------------- On Oct. 23, 2013, 4: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, 4: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
