On 22 January 2012 14:52, E. Liddell ejlddll@googlemail.com wrote:
On Sun, 22 Jan 2012 10:48:36 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
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?
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.
-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.
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).
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.
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 :)