Comments on: Java bindings?

By: Arno

Arno — Fri, 13 Aug 2010 13:38:49 +0000

We’ll split the Qt-only part of the bindings off kdebindings after the git transition of KDE has completed, so then everyone who wants to contribute can create a personal clone on gitorious (or whereever it’ll be hosted) and file merge requests, or even gain access to the main repository.

So it’s not that much for control. Everyone is invited to help developing the bindings. But *my* focus (which is not necessarily the focus of the project, if/when other developers join) is KDE – and if there are no users of the bindings in KDE, I don’t see a reason why *I* should develop the bindings any further.

By: James Mansion

James Mansion — Fri, 13 Aug 2010 12:25:50 +0000

Is there anything you would be prepared to do that might make it easier for those of us who care about Qt primarily and KDE only tangentially to help maintain it and widen its audience? (Not that I’m making an offer really; I can achieve my near-term objectives in Python)

I guess the issue is: do you want control, KDE focus, and no users? Or less control, less KDE focus, and more users?

By: Arno

Arno — Wed, 11 Aug 2010 14:36:12 +0000

This is exactly my point. My main target platform is KDE/Linux – if that would have a reasonable user base, I wouldn’t mind putting some more effort into making it work on Windows, OS X, Solaris or whatever.
However I don’t like coding only for some corporations who are then happy to have a cross-platform toolkit for free, without having any support from the community that I really care about.
Sorry if this sounds a bit harsh, but that’s just how it is.

By: 'non

'non — Wed, 11 Aug 2010 13:55:26 +0000

As a C# developer targetting the big three platforms I am desperate to use Qyoto, simply because Qt actually maintains native look & feel (well, more or less) across all of them.

Qyoto is currently easy to build on Linux, difficult to build for Mac (although thanks to a KDE-experienced friend we managed to get it working), and impossible to build for Windows.

As it stands, it seems Qyoto is just meant for people writing KDE apps. Is this true? Gtk might be crappy but at least Gtk# works everywhere… If I didn’t care about portability, I’d be writing System.Windows.Forms c# applications…

By: Fabian Koehler

Fabian Koehler — Mon, 09 Aug 2010 21:40:53 +0000

+1 for java bindings. i’m not saying i’ll use them but if you are interested in putting effort into any binding i’d recommend java since it’s widely used. maybe we could more easily provide scala, groovy and other jvm languages bindings then as well?

By: James Mansion

James Mansion — Mon, 09 Aug 2010 12:03:24 +0000

I think the problem with C# uptake is as much to do with never seeming to get to a 1.0 release that’s good and stable and has some documentation — and some marketing.

There are lots of Windows devs writing C# – its not really a question of whether existing KDE devs would use it (they are C++ devs, after all) but whether some of the resources currently spent on winforms on Windows could be diverted at Qt and thus the code could port away from Windows to other Qt platforms. It would take time – but while I’ve been almost working full time on UNIX for two decades I can honestly say that the amount of UNIX-based GUI development has gone down in the businesses I’ve been working for, most of which were Motif and/or SunView shops at some point.

Qt is a nice library: if you want to look at things solely from a KDE point of view then fine, but its a niche and will stay a niche while that’s a view that is widely shared. I think that can be changed if you view things from the point of view of a corporate developer who must target Windows and might like to have portability to UNIX (and might like Qt goodness over Microsoft’s own offerings). But you’ll have to move on from a KDE mindset to be successful as that – and it will not happen overnight. I would have thought that Meego would be able to sponsor some effort and Intel cetainly have money, but you might need to free SMOKE from KDE and make it standalone in the swig space.

By: MONONONO

MONONONO — Mon, 09 Aug 2010 11:30:09 +0000

Stay away from c#, please. I don’t want KDE applications to be so sluggish like gnome applications. F-spot, tomboy, banshee make desktop to crawl! Compare tomboy (a simple note taking program; yeah, right) to Firefox and tomboy consumes about the same amount of memory (it’s enough to open three or four notes). There’s enough ms and novell people trolling at planet gnome to realize there’s something bad with mono. Apps written in mono are sluggish and the situation with patents is not clear. I don’t like java, but it’s not product made by our rival and afaik java is free to use the way you like.

By: Diederik van der Boor

Diederik van der Boor — Mon, 09 Aug 2010 08:22:57 +0000

> So I’m asking the community directly before I start putting too much work into a project that noone really wants

If I had asked people what they wanted, they would have said faster horses. – Henry Ford

I think Java bindings open KDE to new communities like Groovy, Scala and Jython too, which can all interop with Java classes as their “assembly language”. Worth considering I think.

By: Cidre

Cidre — Mon, 09 Aug 2010 08:11:48 +0000

I am not so sure whether Java bindings will find that much users. Jambi never really took off (in terms of license sales). Although a lot of people I know (including me) thought there would be a market for a decent UI toolkit (i.e. not Swing or SWT), maybe there isn’t… Java isn’t that big on the desktop after all.

By: Roman Taycher

Roman Taycher — Mon, 09 Aug 2010 06:07:35 +0000

Also Shotwell is written in vala:from wiki pedia
“Vala is a programming language created with the goal of bringing modern language features to C, with no added runtime requirements and with little overhead, by targeting the GObject object system. It is being developed by Jürg Billeter and Raffaele Sandrini. The syntax borrows heavily from C#. Rather than being compiled directly to assembler or to another intermediate language, Vala is compiled to C which is then compiled with a platform’s standard C compiler.”