Some folks pointed out an
interview on
Dot.KDE with Richard Dale. Richard is the author of the code which adds bindings to KDE and Qt for Java. What does this mean? Well, the interview has more details, but the simple answers is "KDE/Qt apps written in Java". Hopefully this means more programs.
Slashdot Mirror
The same idea is already underway for GNOME
Mike.
Tales from behind the Lagom Curtain
What is it with people on Slashdot lately? Did anyone READ the article, or did you all just denounce it as "evil" before you lost patience waiting for the (now slashdot'd) server to go down? Seriously!
v em ber/msg00481.html
x _h tml
This article has been up on dot.kde.org for a few days now, and (while I initially wasn't too excited about the idea) is a very interesting read. What the author has basically done is lay the foundations for good solid bindings for any language. His initial cut was for Objective-C , and now Java.
There are no licensing issues here, as these are simply language bindings that allow you to use KDE and the very capable Qt to write GUI apps that integrate well with the rest of KDE. As was pointed out at the dot, this is meant for java the language, not java the platform. As was also pointed out, the possibility of gcj+kde bindings could eventually make for a fast compiled app in an easy to write for language.
Oh, and for the record, this was started for Gnome back in 1998:
http://mail.gnome.org/archives/gtk-list/1998-No
http://news.gnome.org/gnome-news/961253384/inde
One of the things that Gnome-toting Slashdotters often criticize QT and KDE for is the lack of language bindings. Well, now they have Python, Java, Objective-C, C, Perl (in some state) and more on the horizon. So now that this has been addressed you feel you have to blast them for doing precisely this?
The page also praises GTK for it's portability. When was the last time you read a Gnome page that made reference to anything done by KDE in a good light?
Come on, everybody needs to grow up here. KDE doesn't suck, Gnome doesn't suck, Java doesn't suck. They all have their place. Java is a fun language to program in. A nice compromise between C and SmallTalk. Be nice here.
Why would you add Qt/KDE bindings to Java? Doesn't that just limit the crossplatformness of Java?
(a) Some people see merit in Java beyond its crossplatformness. Some people think it is a nice language, easy to develop in, easy to write maintainable code in. (b) Objectively, the existence of bindings for any language is a good thing for any toolkit. The absence of such bindings is a bad thing. Hence this is good.
can you say sludge? I would imagine the speed of these apps running on anything less than a Wonderbox would be like watching snails.
You are aware that Java code can be compiled to a native executable, using a compiler such as gcj? You are also aware that much of the blame for slow Java applications has been placed upon the Swing toolkit, which you wouldn't be using if you were using QT?
Why not just stick with C++ or something?
Perhaps because you are a Java programmer who is not experienced with C++ (or who doesn't like C++), and yet still wish to develop for KDE
this is all we need, kde apps that need to start a jvm to run.
Not if they're compiled to native executables..
What was the KDE developement team thinking..
Maybe that.. oops! nearly replied to a qpt troll!
KDE has had problems in the past with licensing issues..
oops! nearly replied to an Ananova troll!
Disclaimer: I'm not a Java programmer, or a KDE developer. I actually get paid for writing VB (OK, feel free to moderate me -1, "Spawn of Satan")
Just to correct a few points:
;-)
> Java is simply unusable on the desktop
No. Badly written Java is unusable on the desktop, especially if it uses Swing. Swing is definately a pig. OTOH I run JBuilder every day on a P2-350: it's very usable.
Debuggers: Check out visual age, it is meant to be excellent. However, having used both VC and JBuilder, I don't find any limitations in the java debugger. Why? Because I spend much less time using it. In fact I rarely need it at all.
Image: I don't see that as a problem at all, and I doubt this you can back up this line: "Hence java programs usually exhibit very low quality compared to C++ based software." with anything other than "in my experience". It's rather FUDish.
I guess if you're used to seeing so many low quality unusable Java programs maybe you should start to mix with better programmers
0.02, Mike
Tales from behind the Lagom Curtain
Even simple dropdown lists will not scale beyond several hundred items...
A drop-down list with (several) hundred items is sheer lunacy. Lists, drop-down, scrolling or whatever, are inappropriate GUI elements for selecting from hundreds of items. Indeed if you find the user having to select from an unfiltered set of that many items, then you probably need to reexamine the design of that portion of the application. Just going on this one clue, it appears that your more fundamental problem might be immature abilities in your designers.
> A drop-down list with (several) hundred items is sheer lunacy
This is not an excuse not to handle it properly. (I don't know why, but this recall me the mswindows combox boxes where you have about 3 of 4 lines of avalaible data, probably because someone decided that using a combo with a few dozen of lines would be 'sheer lunacy')
> Indeed if you find the user having to select from an unfiltered set of that many items, then you probably need to reexamine the design of that portion of the application.
Nonsense. You have a number in the interface. You click on it, and want to drill through. Unfortunately, there are 6000 facts hidden behind it. The user *want* to see them, probably because he want to sort them and find a particular one. Sure, he could do a quety for that, but scanning in a list is sometimes easier/more confortable. I can use list of 100K items if the list is sorted meaningfully. There are user hitting the 65K lines limit in excel spreadsheet every day ?
Hell, with you reasoning, we should suppress any kind of visualisation of log files, as those are basically list of thousands of items.
> Just going on this one clue, it appears that your more fundamental problem might be immature abilities in your designers.
Nope. Its problem is that he is using a toolkit that doesn't scale to the user needs. Sure, and application that _requires_ the user to dig into list with hundred of elements is severly ill-desgined, but one that _prevent_ a power user to look at its data is plain broken.
If a developer want to make anything resonable (like a scroll list with 1000 items sorted by date), he should not be prevented because the toolkit implementors are using o(N^2) algorithms.
Cheers,
--fred
1 reply beneath your current threshold.