23 Jan
2012
23 Jan
'12
3:51 a.m.
On 22 January 2012 14:52, E. Liddell <ejlddll(a)googlemail.com> wrote:
On Sun, 22 Jan 2012 10:48:36 -0800 (PST)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
Here is a complete list:
dcopc
dcopjava
dcopperl
dcoppython
kalyptus
kdejava
kjsembed
korundum
python
qtjava
qtruby
qtsharp
smoke
xparts
smoke and kalyptus are the Java/C# generating code, and korundum seems
to be part of the Ruby binding, FWIW.
Perl is less popular than it once was, and Java programmers generally aren't big on
using
platform-specific interface modules (it's counter to the philosophy of the
language).
It seems in the past that more were available. Objective C and C were
also available as of 3.2.3
http://websvn.kde.org/tags/KDE/3.2.3/kdebindings/
If anything I'd like to reinstate QtC :)
HOW CAN WE BUILD A QUALITY PRODUCT IF NOBODY
UNDERSTANDS IT. Tim even
mentioned he won't mess with it because he
doesn't use
those languages. I
think we have to be kidding ourselves if we are
trying
to provide a
"quality product".
Seems to me that we need to start by finding the answers to
these questions:
-Which languages are involved? Looking at the source
in GIT, I think I see
Java, Perl, Python, C#, C, Ruby, XPart (whatever
that is), and Javascript,
plus some other stuff (written mostly in Perl) that
appears to be
autogeneration/framework code for C# and Java. Does
anyone see
anything that I may have missed or be misinterpreting? -Which of
these languages do we have potential maintainers
for?
-Which of these bindings have actually been used for
creating software?
Frex, Amarok has a Ruby dependency--will we need this
interface to
maintain/further develop it?
I'm not qualified to make decisions. I can only offer that Java, JavaScript, Perl,
Python, and
Ruby are popular and not going away any time soon. DCop is important to controlling
Trinity
apps from external apps and scripts. To me, the important question is not which
bindings to maintain but compiling the package.
If somebody wants to use their favorite language to hook into Trinity, let them have fun.
Right now the big issue is why compiling is such torture. Seems right now I'm the
only
person trying. :)
Oh, ouch. I just looked at the KDE 3.5.10 ebuild for kdebindings and found this:
# Broken and package.masked.
# ~kde-base/korundum-$PV
# ~kde-base/qtruby-$PV
# Omitted: qtsharp, dcopc, dcopjava, xparts (considered broken by upstream)
So the bulk of the code was broken pre-Trinity and likely was never fixed,
which could explain why it isn't compiling now.
Furthermore, if those bindings have been broken for that long and no one
has complained, chances are that no code ever used them (or if anything
did, it's long since migrated elsewhere).
Python, Perl, Javascript, and the non-dcop parts of the Java binding might
still work, but we need to either fix or kick the remainder. Right now, I'm
leaning towards "kick", and it seems like most of the other people who've
weighed in do, too.
Given the manpower available and the general breakage level, I really do
think that focusing any effort that can be spared on the Python binding and
dumping the rest if/when they break (unless a brave volunteer steps up) is
likely the best way to go.