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