This discussion has been archived.
No new comments can be posted.
Java Binding in KDE2.1
Related Links Top of the: day, week, month.
"Life begins when you can spend your spare time programming instead of watching television." -- Cal Keegan
Wouldn't everyone flip if... (Score:2)
-Karl
Re:Wouldn't everyone flip if... (Score:1)
So it must be good!
But this was my point. Why write in a platform that's suppose to be cross platform, but write stuff that can't be used with anything, only KDE.. Why not just stick with C++ or something?
--
Perhaps (Score:1)
The most annoying one being that konqueror tries to access a requested document on the previous site. It also occasionally will treat every request as a request for some page you've been just been to, as though every link was a back button.
And all this is in what they are calling "Final", not beta. Come on guys, you're gonna give linux a bad name! (no snickering out there)
--posting anonymously in anticipation of poor moderation
Re:Wouldn't everyone flip if... (Score:2)
While the Idea of Write Once Run anywhere (Or Write Once Debug everywhere) is really nice in a lot of cases you know that infact you will be using say Linux as the frontend and a specific server as the backend and all you need to do is get it to work in that context. It really depends on what you are trying to do.
Not really useful (Score:2)
What the Linux desktop really needs is something like Visual Basic.
Wait - hear me out.
I'm not saying that you should code in Visual Basic. I don't do it myself - that's one of the perks of being a systems programmer. All I'm saying is that there should be a language for the non-programmer to quickly design graphical applications that use pre-fabbed components and a minimum of glue code.
Java is object oriented. This makes it a mistake for a general purpose gui language. What you need is something that is object based like Visual Basic.
Any idiot should be able to create usable graphical apps for Linux. Unfortunately, currently even gifted C++ hackers can't make usable gui's for Linux - witness freeciv. Whether you like the language or not, you've got to admit that a language designed primarily for component reuse would be a good thing for linux - espescially for the corporate environment where rapid development is a must.
--Shoeboy
If anyone doesn't know this is a troll yet (Score:1)
cheers,
--
Re:Wouldn't everyone flip if... (Score:3)
This is good... and not... (Score:1)
Sure it could break the WORA promise of Java. This is the bad thing.
But used wisely, it could enable 100% Java application to integrate well with theire desktop environment. A well written application could easily abstract all the desktop integration feature they need and have implementation of these for each desktop environment they run on. If no desktop integration implementation is found then the Java application can still run, it will just not be interopperate nicely with the desktop.
Java is simply unusable on the desktop (Score:1)
Garbage collection, often touted as Java's biggest advancement over C++ makes Java completely unsuitable for a whole slew of applications. Even the "softest" realtime apps will get an unbearable penalty from the garbage collector spontaneously "kicking in" at more or less random intervals. Even a simple MPEG1 player app eperiences jitter and playback glitches due to garbage collection issues. The only place where java's performance is acceptable is server side apps because the memory footprint is less of an issue and because "the web is always slow" attitude that web users became used to.
Java does not have serious development tools. I've yet to find a reasonable Java debugger. The supposedly "excellent" Borland JBuilder cannot hold a candle to Visual C++ especially when it comes to debugging features.
Last but not least problem with Java is its image. Because of its simpler syntax it quickly became attractive to all kinds of rookies and cowboy programmers and underachievers trying to make big money "hacking" Java after having only marginal exposure to any other programming languages. Hence java programs usually exhibit very low quality compared to C++ based software. This gives the language a bad name to such an extent that many software shops won't even hear about writing anything in Java purely on the grounds of prejudice. Java is was a neat idea executed very badly.
Good day.
--
Ally ourb asear ebel ongt ous
Re:Wouldn't everyone flip if... (Score:1)
Mike.
Re:If anyone doesn't know this is a troll yet (Score:1)
You're a real moron.
Just because you're an obsessive
Most users on this site don't recognize user names other than cmdrtaco, hemos and signal 11.
They don't even see the qpt at the top and, if they do, it means nothing to them.
They certainly don't wast time stalking suspected trolls and posting worthless responses that are actually more damaging to the quality of discussions on
But don't let that stop you. Keep on doing what you're doing. Every response after a trollspotter appears is worth double.
--Shoeboy
Re:isn't KDE already a resouce hog (Score:1)
Re:If anyone doesn't know this is a troll yet (Score:1)
--
Oh the irony... (Score:2)
That's rather the point. Modulo GUI, java is rather fast nowadays [0]. Swing OTOH, is a bit of a bloaty pig, layering far too much code on top of the underlying (native) GUI.
ObFacts: the nightmare corel project was a long time ago in terms of java speed & functionality.
Mike.
[0] Relative to FORTRAN & C, not just relative to "old java"
Re:Not really useful (Score:1)
Yellow box is a development tool that was supposed to be running on NEXT but that never quite picked up with the box.
I saw it running on Rhapsody one of the little research OS by apple 4 years ago and I was flipping out. You just drag and drop and bind the elements toghether code is made for you.
Beside forte runs on Linux so I guess you could develop application with the look and feel of Q\t and KDE from java.
I dunno but I would like it
Specially if it solves the cut and paste problem
Yellow box [stepwise.com] or here [stepwise.com]
-------------------------------------
No no no (Score:1)
--
Non-meta-modded "Overrated" mods are killing Slashdot
Re:Not really useful (Score:3)
If its anyway simmilar to the excelent java/GTK bindings then they use JNI to call the GTK/QT/whaterver functions. Ok
if you want speed in java, use the IBM 1.3 JDK
Re:Not really useful (Score:1)
Re:Use Gnome? (Score:3)
1) Java removes so-called "powerful" functionality from C++ because while great for developing apps yourself those features generally result in morons shooting themselves in the foot. Have you ever built software applications in a large team environment with extremely tight deadlines and minimal time to track down bugs? No, I didn't think so.
2) Java has been massively successful because of the above. Think again. Primarily in backend server apps and web applications. Not in client applications or applets. This is an attempt to make it more viable in those areas because a fully cross platform library with graphically rendered widgets doesn't work well yet. If you think Java has failed you must not work in anything remotely related to enterprise software.
3) I love Gnome as much as the next guy. But it's neither clean, stable, nor intuitive. This gives away your troll because frankly KDE is generally more intuitive than Gnome, somewhat more stable (clean is arguable... and aesthetic, I think Gnome takes the cake).
GNOME already working (Score:4)
Mike.
Excellent news! (Score:5)
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.
Re:isn't KDE already a resouce hog (Score:2)
This is funny as hell. This is what is called a resource hog. And YES, gnome is a resource hog too. And Mac OS X also. And win32 too.
A NeXT machine was running fine (in 2.x) with only 8Mb of ram. A color station under 3.3 would run fine with 32Mb of ram. This means the OS + the workspace + edit + a few apps (real apps, like Mathematica or Improv)
And before that, Geoworks ran real fast in extremely low memory conditions.
Still below 40MB before having started any usefull application ? Nothing to be proud of...Of course adding java binding will make 40MB of bloat looking ridiculous...
Cheers,
--fred
Re:If anyone doesn't know this is a troll yet (Score:1)
Sigh....
You should also know ShoeBoy is another well known troll, just checkout the history. I would not be surprised if they are not both alter ego's of the same person.
Re:Why are they doing this? (Score:3)
Also, with respect to Java itself, there are free implementations of the Java compiler and the Java runtime environment as well. But using Sun's Java compiler and Java runtime IN NO WAY affects the licensing of code that has been compiled with it.
There is sometimes confusion over what "linking" and similar concepts referenced in some Free or Open Source licenses mean in the context of Java. I won't seek to open these arguments up here. I'm just pointing out that your points are completely off base and the two issues - Java bindings for KDE and Freeness are orthogonal to each other.
Replying to everyone at once.. (Score:5)
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 [gnu.org]? 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")
java-desktop integration (Score:2)
This became obvious for me when I used the Java version of ICQ which was not truly integrated with my desktop. I would have liked to switch to "away" state whenever the screensaver would kick in, just like in Windows. The java program cannot be aware of all the desktop properties and event. Maybe there should exist an API for this precise purpose.
There are also good Java hackers (Score:1)
Re:If anyone doesn't know this is a troll yet (Score:1)
--
Non-meta-modded "Overrated" mods are killing Slashdot
Re:Wouldn't everyone flip if... (Score:1)
Re:What's the point? (Score:2)
Re:This is good but..... (Score:1)
I have JDK 1.2.2 running on a Pentium III 450 mhz, 256 meg of RAM, and Windoze 2000. I would not call that a "wonderbox", but it's not a slow-poke either. Java applications run great on this system- and I mean applications not applets
I'm working on a rather complicated desktop mapping application, written completely in Java and using Swing. It's quite responsive and for most user operations, you would not be able to tell it was an interpreted application or one that was compiled to native code.
I'm quite happy with Java as a programming language and with it's perforance in both desktop and server-side applications.
When the users tested the app they were pleased with the performance as well. On older hardware, performance suffers, but even on a Pentium 166 with NT4 & 128 meg of ram, the application was useable.
Re: What's the point (Score:1)
--
It is about time (Score:2)
Now, if only Be Inc. would make it easy to program directly to BeOS using Java...
Re:Java is simply unusable on the desktop (Score:5)
> 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
Re:Excellent news! (Score:2)
Funny ... even though noone seems to read the articles, they get slashdoted.... how comes?
Re:Not really useful (Score:2)
Kylix (Score:2)
- Quickly design graphical applications
- use pre-fabbed components
- a language that every idiot can use
- a RAD (rapid application development) tool
You need: kylix [borland.com]I went to a free seminar a few weeks ago, and it looked really impressive.
--
Re:Java is simply unusable on the desktop (Score:1)
You rarely need a debugger? Well in that case I wouldn't offer you a job as a programmer. It should be mandated by LAW that every programmer steps through their own code at least once. If you don't do that you have no clue what your program really does. You're doing programming by coincidence.
Re:This is good but..... (Score:2)
Re:Java is simply unusable on the desktop (Score:5)
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.
Re:This is good... and not... (Score:1)
You are right, but I believe that there is a place for Java as a general purpose programming language in addition its platform-agnostic role. It's an easy language to use and you can put together applications in a fraction of the time it would take to develop in C/C++.
To the end-user the development language is pretty much immaterial. As long as you clearly specify the system & OS requirements, there's not a problem. if you write an application in Java that will only run under OS X or OS Y, just say so.
Re:This is good but..... (Score:1)
--
Re:Java is simply unusable on the desktop (Score:1)
Nonsense. Sometimes there is no logical way to filter certain items out. Sometimes it IS desirable to select one thing out of several hundred. Don't critisize the UI you haven't seen!
Re:More applications written in Java?!?! (Score:2)
While teaching myself java, my original web page had a 3d vector-ball animator for a pretty nice scroller implemented in java on it.
This app had explosion effects, vector trails, morphing, and of course all the 3d linear algebra crap for moving and rotating the objects on each axis.
Oh yeah, it used double-buffering for smooth animation too, so I was pushing 320x300 pixels in each and every frame. This was on a Tseng ET6000 video card. Nothing radical there.
On my Pentium 133, in a browser window, this used maybe 25% of my CPU tops.
Of course, this was under OS/2, which had a very good java integration with the OS and netscape (netscape for OS/2 used OS/2's system JRE by default, not its own).
Bottom line is a poorly written app, whether it be in java or any other language will be a CPU pig. Just because it's java doesn't make it so, however.
Re:Replying to everyone at once.. (Score:1)
Re:Java is simply unusable on the desktop (Score:2)
Thats good - because I wouldn't take it - especially if you only hire coders who code so badly that they need to use a debugger a lot
> It should be mandated by LAW that every programmer steps through their own code at least once. If you don't do that you have no clue what your program really does. You're doing programming by coincidence.
On the contrary. If you're just coding - and saying "ooh, it seems to be doing the right thing", you dont know jack. What you *should* be doing is a design, and then coding from it with test cases. If you need safety, you should generate a proof for the design and then derive the code automatically.
Needing to use a debugger frequently is a sign that something serious is wrong with your habits.
Mike.
Excellent Idea (Score:3)
I know that most of the slashdot readers are java haters and have the impression that java is unusable for GUI applications.
While it is true that most current java GUI programs are slow as hell, this does not mean that java (the language) is slow. Run something like a well written quicksort on a java 1.3 VM, and it will be as fast as a C++ implementation(1). Try it out for yourself before you flame me. The implications of this are huge: It means that bytecode languages like java or C# can be as fast or even faster as compiled languages! This will change computing forever, even if you don't like it.
Now if java is that fast, why are GUI applications written in Swing so slow? The reason is that all the 2D rendering is currently done in java using the CPU using an api called java2d. The main bottleneck is not that it is done in java, but that for the sake of platform independence and garbage collection, java 2d has no efficient way to access fixed position memory like the graphics card memory, and that all calculations like blitting are done by the CPU. This will supposedly change in the java 1.4 (merlin) release, but like every intelligent software developer, I believe it when I see it with my own eyes on my own machine
But sometimes you do not need platform independence. If you write a java application using KDE, it will run on all unix machines where you can compile KDE. And contrary to popular slashdot belief, java is a very good language even if you do not need "write once, run anywhere" style platform independence.
So to all you java haters: Stop wasting your time by flaming about java performance and instead run a simple non-gui java benchmark.
greetings,
Anonymous java nerd
(1) Depending on your choice of compilers/jvm you might not get identical performance. But you will get within a factor of 2.
(2) It would be nice if all the C# followers would have the same attitude instead of blindly believing microsoft promises.
Re:This is good but..... (Score:1)
Coincidently... (Score:1)
Re:Replying to everyone at once.. (Score:3)
Then you wouldn't need the bindings, stupid FUCK.
I see no reason to reply to this beyond the sheer joy of posting (and the fact that I'm bored at work), but you don't actually know what a binding is, do you, AC?
Or do you think that gcj is some sort of magic toolkit pixie that compiles all the Swing references in your Java code into calls to whatever toolkit library you happen to be using? (I hear that the next version will be able to guess which you prefer out of QT and GTK+ if both are installed!).
p.s. When you grow up, you'll realise that trolling is more fun than flaming. But it also takes more skill (even in an article involving Java and KDE!), so maybe it's out of your reach..
Re:Java is simply unusable on the desktop (Score:1)
Re:Java is simply unusable on the desktop (Score:1)
Re:Yet another first for KDE (Score:1)
--
Re:Oh the irony... (Score:1)
Umh, Swing is a lightweight GUI. The old AWT was the nightmare that built on top of native GUI's. Swing does away with the native GUI for 99% of its widgets. In fact, the only native widget it uses is a frame so that it can open a non-contained frame. That can be avoided for everything except the main frame of the application if you don't mind contained frames for dialogs.
I've not worked with Qt before, but IMHO Swing rocks for GUI construction. Now if we could just find a Java 1.3 native compiler I would be ectstatic.
Re:More applications written in Java?!?! (Score:1)
Re:Java is simply unusable on the desktop (Score:2)
If you think that the only way to determine what a program is doing, then you have only the weakest grasp of whatever language you are working with. Ofcourse, there is an exception to that general statement -- I find that exposure to Win32 makes people paranoid about whether code works like they think it should.
However, the types of large-scale programs I write (traffic planning systems, mostly) demand that the code be self testing to a large extent because the data structures are large and complex enough that we have been unable to find effective output/display mechanisms, but we *can* write algorithmic tests that we can trust because they are simple to state, even for complex data.
I say -- debug to dig out info about a misbehaving program, but that is no substitue for clearly written code, and a well thought out design. Do that, and you too will need your debugger less.
Re:Java is simply unusable on the desktop (Score:1)
--
Re:Java is simply unusable on the desktop (Score:3)
This wasn't even fresh when I was taught it all those years ago at school
Anyway, here's a quote from a book perhaps you might like to read: The Practice of Prgramming, Kernighan & Pike: "Debugging is hard and can take long and unpredictable amounts of time, so the goal is to avoid having to do much of it.[...] An ounce of prevention really is worth a pound of cure."
I couldn't agree more
Mike.
Re:If anyone doesn't know this is a troll yet (Score:2)
--
Re:And (Score:1)
Re:Java is simply unusable on the desktop (Score:2)
Remember -- code should follow design. Good code follows a Good Design. Good design handles boundary cases in a normal fashon. Good design is semantically clear. Debugging is a last resort when your code is not working right. Good code behaves in obviously correct ways. Good Designs are self-testing to a large degree.
To sum -- it is *you* who need to learn to design and program, my friend.
Re:Java is simply unusable on the desktop (Score:1)
I would agree, if you replace 'neat idea' by either 'dumbed down smalltalk' or 'sluggish objective-C'.
Cheers,
--fred
Re:Wouldn't everyone flip if... (Score:2)
Binding only reroute library calls (Score:1)
In the immortal words of Nelson... (Score:1)
Native compilers (Score:2)
QT AWT bindings? (Score:1)
This is good news, except that I would like to see QT (and GTK) peer implementations for the Java AWT. Currently, the blackdown Java implementation uses Motif, so apps built with it tend to be ugly. I know one can use JFC (swing) and use a prettier look and feel, but I'd much rather have a native widget that looks, responds, and acts like whatever desktop environment I have installed.
Just my 2 pennies.Re:What's the point? (Score:2)
ROTFL (Score:1)
Re:Not really useful (Score:1)
Unfortunately, currently even gifted C++ hackers can't make usable gui's for Linux - witness freeciv
Download IBM VisualAge for Java Entry Version for free here [ibm.com], quickly browse the first example in its tutorial, you could then start writing a pretty good GUI program without needing to write a single line of Java code, or have a slight knowledge Java language.
I can write an entire database access GUI front end without writing a line of code.
If I lied you can have my cat's first born child.
You might say it's all depending on the development program. Heck you can choose many other Java development programs but only Microsoft provide you with VB development program.
Re:Oh the irony... (Score:1)
You're confusing terms. Commonly: heavy==slow,large. light==fast,small. However, in terms of Java GUI components, heavyweight components are native (a la AWT), whilst lightweight components are rendered entriely by Java.
Thus, Swing, consisting of "lightweight" components layered on top of "heavyweight" components (native windows), is actually heavier than AWT, because swing is larger and slower.
When swing is a little lighter, better documented and more functional, I will think it rocks too
Mike.
Re:Replying to everyone at once.. (Score:1)
This is probably true. Of course, the statement "X is a good language and can be used for more than it is currently if people would just stop typecasting it." is true for many languages X./p?
Re: (Score:2)
Re:Java is simply unusable on the desktop (Score:4)
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
Re:Not really useful (Score:2)
A visual tool won't help you much when it comes to designing a usable interface though. Coming up with an interface that lets you use the program without getitng in your way takes a lot of thought and experience. Most of the interfaces I've seen designed by amateurs using such tools tend to be... bizarre.
Re:More applications written in Java?!?! (Score:2)
So somebody coded a bad applet that eats up all resources by not yielding or sleeping. What's your point? And.. that's on ONE virtual machine (Microsoft's since it's inside IE) so it could also be the case of a poorly implemented VM, though in this case, I would suspect it's the applet.
Re:Kylix (Score:2)
No, i dont work for 'em. (Tho i'd like to :)
-henrik
Re:What's the point? (Score:3)
The KDE bindings don't use AWT or Swing. They actually let you program using a Java variant of the actual QT/KDE APIs. Another big difference is that code written using these bindings can only be run on platforms that have the QT/KDE libraries and a JVM, while AWT and Swing programs can be run wherever there is a JVM.
Hope that makes sense.
.technomancer
Re:Java is simply unusable on the desktop (Score:2)
In addition to this, as soon as you start to write non-trivial code in Java you begin using threads, so single stepping becomes a pointless activity. The timing difference means the threads interact differently to the way they would in a real invocation. It's still a useful technique every so often of course, but not for anything bigger than a few classes.
Have you actually written any decent sized Java apps? I would guess you haven't from this comment.
Re:pointless? (Score:2)
This basically just allows people that want to to write KDE apps in Java. There are no legal issues here.
.technomancer
Re:Java is simply unusable on the desktop (Score:3)
Then I created one with 50000 (fifty thousand!) entries - this took a while to create the 50000 objects to put in the list, but as far as using it is concerned - it was just as fast.
Whatever problems you're having with this stuff, well, I'm not sure it's all down to Java...
Mike.
Re:Oh the irony... (Score:2)
Lets elaborate a little here. Java leaves the rendering to Java2D. On windows this means that your widgets are actually rendered using directdraw (i.e. hardware accelerated) since the Java2D rendering is just a layer on top of platform specific rendering. What AWT did was much more ugly, it tried to wrap native components in such a way that it would be platform independent, it was ugly, buggy and never really became a good solution for crossplatform GUIs. That, by the way is also the trouble with this KDE wrapper, it will look nice on linux, but what about other platforms? It sounds like AWT2 to me, I don't see how the problems AWT had are addressed in any way by the KDE wrapping. But then it probably never was intended as a crossplatform solution. So in short, the KDE2 wrapper has the same inherent problems the original AWT had, yet it is posed as an alternative to the much better (than AWT) swing solution.
Re:What's the point? (Score:2)
Re:What's the point? (Score:2)
Re:Java is simply unusable on the desktop (Score:2)
This is not an excuse not to handle it properly
I completely agree. It was the context and wording of the original post which caused me to suspect that there might be other poor design choices that were the culprit in the poster's perception of poor Java performance.
Hell, with you reasoning, we should suppress any kind of visualisation of log files, as those are basically list of thousands of items.
Begging your pardon, but I did not say or suggest that we suppress any kind of vusualisation of log files. I did not mention log files at all. Please don't distort what I said. Since you brought it up, I will, however, suggest that visualizing a log file in a drop-down list is perhaps a less than optimal design choice.
Again, I did not suggest that one prevent users from looking at data. Actually, I was thinking of drop-down lists as an optimized form of data entry, not visualization, so maybe we are not so much disagreeing as we are misunderstanding each other.
I can use list of 100K items if the list is sorted meaningfully.
This misses the point of the sheer awkwardness of manipulating a drop-down list that large. The list viewport is so small in relation to the total list size that movement in the list is very difficult. The scroll thumb moves tens or hundreds of items with the tiniest of mouse inputs, frustrating even the most dextrous user with overcompensated mouse movements. And often the arrows are either too slow for the size of the list or too fast to read as you scroll. Please understand that I am not suggesting that this is something one should never do. I am just pointing out the tradeoffs of the awkwardness ot manipulating the user interface.
Re:Oh the irony... (Score:2)
- The first difference from AWT is that this binding doesn't try to be platform independent - this means that it doesn't have to provide a lowest common denominator API.
- A second difference is that unlike the AWT this code is bound into the JVM under programmer control, so you can choose at run time if you want to load it. You could for example include a Swing binding in the same app as well as the KDE binding.
- A final difference is that if you stick to the Qt part of the binding then you gain a degree of platform independence anyway because both the JNI and Qt are multi-platform.
People also seem to have failed to understand that these bindings could be used to implement an AWT. I began a direct AWT port called QtAWT (see the KDE developer site for details) a while back, but I haven't touched it for ages. Now that the AWT side of things can be handled in Java with the Qt/KDE binding it would be much easier.The arguments about breaking Java's platform independence are also somewhat weak because of developments like Suns Java extension mechanism. This mechanism allows people to cleanly bind native code into their Java apps. There is no problem with including platform dependencies as long as you do it cleanly IMHO.
Re:What's the point? (Score:2)
.technomancer
Re:Oh the irony... (Score:2)
I don't understand your argument about binding code into the JVM. Of course you can create 2 GUIs for your app and choose dynamically which one to use. However, in practice this limits the way you can design your code and will cause you to write a lot of non trivial gluecode. And why write a second GUI if you have a crossplatform swing based GUI anyway?
Re:What's the point? (Score:2)
I do agree with you that a Look and Feel that automatically pulls and uses your KDE theme would be nice, as would a set of Qt/KDE AWT peers.
.technomancer
Re:Excellent news! (Score:2)
I am not trying to troll here, I am just pointing out something I've noticed...
Re:Oh the irony... (Score:2)
If you use a Swing UI then you also get the AWT bound into your JVM because the low level parts of Swing are build using AWT peer classes (look at the classes underlying the DnD interfaces for example). This increases the memory consumption etc. unnecessarily. The KDE binding allows you to choose what is loaded into the JVM.
It should actually be very easy to make both a Swing and a KDE binding to a Java app. The design philosophy of the two APIs (use of actions etc.) is similar so the glue is trivial. In addition you can still use the Swing model classes if you want to. In general, for well written Java code adding a new GUI is easy.
There are many reasons for writing a second GUI, the major one being to integrate well with the target environment. Swing is a decent enough programming API, but I have found that performance issues and the look and feel leave a lot to be desired. The Win32 look for example is close to, but not exactly like MFC and for many customers this is not good enough. A clean way to integrate with the native toolkit of the platform and to use platform independent code in the back end. In this situation Swing becomes a fallback rather than the primary UI toolkit for your app.
Interesting (Score:2)
If only this meant the end of Swing.... (Score:2)
If only we could get Sun to adopt this and replace swing with it, Java on the client side would gain SO much.
Cool. Now what we need.... (Score:2)
Seriously, right now there are only two major candidates for GUI building in Java: AWT and Swing. AWT is clunky and Swing produces the most incredibly bloated code you've ever seen. We need alternatives. Qt is one good alternative, but it has problems (read on). wxWindows is another alternative, not quite as extensive as Qt, but not with the same problems either.
Qt does have the most developed GUI tools I've seen short of those evil MFCs, in addition to some other cool stuff with sockets and XML. The problem is that your code is only portable to Win32 if you use Trolltech's commercial license. (I'm not slamming Trolltech's decision here...there is some delicious irony behind Trolltech contributing to an atmosphere where free software is easier to write for X than for Win32. I'm just saying that this violates Java's "write once run anywhere" philosophy.) Qt also won't work for Mac, at least not as far as I know. wxWindows has ports for Win32, GTK, Mac and Motif, and is distributed under the LGPL for all platforms. While you don't get all the goodies of Qt, you do retain all the flexibility of Java.
ObJectBridge [sourceforge.net] (GPL'd Java ODMG) needs volunteers.
he he he (Score:2)
Oh my, a VB troll. Spawn of Satan? You really overrate yourself. Oh well, at least you did not call that money sucking, point and click activity "programing". If you really do use VB, I'm supprised you could keep a browser stable long enough to post.
Re:Use Gnome? (Score:2)
1) Java removed actual powerful functionality from C and C++, and made the whole mess less maintainable , less useful, and far less efficient. No decent way to implement proper tail recursion, no macros, and a broken class/package protection model all spring to mind immediately.
2) I can list other massively successful products that have sucked as well. Success is not a guage of worth, efficiency, or really anything else besides marketing. Java sucks just as hard as Word 6.0 did when it came out. And using "Java" in the same breath as "enterprise software" is a pretty good indication that you have no idea what you're talking about, or are also trolling.
3) We really don't care about your opinions in the Gnome/KDE flamewar. Personally, I hate them both, but I'm not going to let you draw us all into a pointless "GUI War" argument. Just remember that KDE is generally modeled after Windows, so if you like their way of doing things, then maybe you'll find KDE intuitive. I find a command prompt to be more intuitive.
Appropriateness of tools (Score:2)
When all you have is a hammer, everything may look like a nail, but it isn't reasonable to expect that you can play a CD, cook a grilled cheese sandwich or mow the law by smashing it with a hammer just because it's the tool you thought to use.
- 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.
According to this "logic," if I want to use email as a transport for real-time streaming media, it's the fault of implementors of sendmail who are responsible for it not working?Just Set the Halt (Score:2)
I live In the VisualAge debugger. The ability to edit the source, hit save, have the changes linked into the running application, and immediately step over the code I just wrote to make sure it does what I want it to is pretty damn good. If you're unsure of exactly what to do with a method (say you're working with some unfamiliar API or toolkit), you can just leave it empty, set a breakpoint, and then be able to inspect all the objects available to you while you write the method in the debugger's source pane.
Just set the halt [xprogramming.com] contains some very, very good advice for working in this kind of environment. (Okay, it's about SmallTalk, but VAJava is really VASmalltalk with another language kludged onto it)
Charles Miller
--
Re:Wouldn't everyone flip if... (Score:2)
OTOH, the comments about this version being tied to Qt rather than any of the Java toolkits sort of limits the use. Maybe someone could write an awt binding to Qt?
OTOH, I really prefer languages that don't depend on single inheritance and type casting everything anyway, so no matter how Java (or C or C++) gets implemented I won't care too much. What I want is a good method of linking Python or Ruby to Ada code
Caution: Now approaching the (technological) singularity.
Re:Wouldn't everyone flip if... (Score:2)