There is an in depth article about Java SWT GUI toolkit. Author discusses the pros-cons of Swing and SWT and myths surrounding them.
A Critic of SWT
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I am shocked by his lack of fan boyism. This will never do.
verdict for swing: good execution doesn’t fix wrong strategy.
This is what I call intresting read! I’m now a Java newbie (I’m not at UI stage yet) so I value this detailed post.
At first, red flags went up for me when he said how long his experience with Swing was, but he gave a very reasoned critique of sWT.
Two things though. One is that Swing fonts are still a disaster (Mustang supposedly fixes this), and the Swing API has been criticized for being overly “academic”, which seems to be a general criticism of the Java APIs themselves.
I’ve noticed that in .NET, there tends to be little helper methods that make stuff like opening and reading a file a lot less convoluted than with Java.
“I’ve noticed that in .NET, there tends to be little helper methods that make stuff like opening and reading a file a lot less convoluted than with Java.”
What’s so convoluted about reading a file in Java? (sorry about the spaces)
import java.io.*;
public class MyFileReader {
String fileName = “MyFileReader.java”;
String lineIn;
BufferedReader in;
public void readFile() {
try {
in = new BufferedReader(new FileReader(fileName));
} catch (java.io.FileNotFoundException e) {}
try {
while ((lineIn = in.readLine()) != null)
System.out.println(lineIn);
} catch (java.io.IOException e) {}
try {
in.close();
} catch (java.io.IOException e) {}
}
public static void main(String args[]) {
MyFileReader fr = new MyFileReader();
fr.readFile();
}
}
I meant to add: Good article. I was also a bit skeptical after reading about how much time the author had been working in Java and Swing, but the article presented a good, mostly non-biased point of view.
I personally have no problem with Swing, and I don’t find it slow, even on my 533 MHz Celeron computer. Like anything else, a lot of the percieved speed problems come from bad design and/or implementation of the program’s UI.
When we’re talking about Java has to do with excessive allocation of objects.
Like any performance problem, profile, profile, profile!
You can eradicate a lot of swing’s slowness by making sure excesses of allocations are kept in check.
Especially with loops, setting up reinitialization instead of recreation is a huge performance increase.
I have a friend who opens and closes program windows on demand. If he wants to use notepad, he will open one notepad window. Instead of leaving it open in case he wants to use it again, he will close the window as soon as he appearently does not need it anymore. He does the same for every window in his Windows XP. Now he has 900 MBs of RAM, and he still does it.
When I’m talking to someone in an IM window, I leave it open while we are chatting, but he is always closing his windows, even the IM ones. He probably runs 1 window 90% of the time he uses the computer. 🙂
I’m contrary to that. I can leave 5 to 10 open windows anytime. Right now I have 5 on Linux Ubuntu. If all of them were Swing apps, I wonder how much memory this system would be using right now. 🙂 Would I become like my friend who closes one to open the other? 🙂
Eat your own dog food, it’s what I say.
Too bad that trolltech has no interest in Java (instead they try to position qt and c++ as an alternative to the java platform).
It could be a pretty good match. A fast, flexibel and object oriented toolkit and a language that offers a balances between readability, development speed and execution speed.
I really don’t see the reasoning for SWT other than native look (not and feel). I’ve never minded the Swing look that much, and the 1.5 look is a lot less crappy; but then again I’m a programmer and the article does talk about programmers aesthetic reasoning skills…
I’ve using Swing, it’s not hard to learn. Sometimes it felt a little unwieldy to use, but all in all it wasn’t bad. It has good documentation…
A friend of mine told me about his grandma the other day:
She didn’t know the taskbar and minimize functionality existed. She’d literally close word and open IE, then close IE and open Word back to the same document. Her grandson showed her the minimize button and she was astonished.
Usability experts my ….
“Swing programmers will be used to the strict use of MVC by JTable and JTree enabling them to use any JComponent they like to render the nodes in trees and the cells in tables. They will find that trees and tables in SWT offer nowhere near the flexibility and power of their Swing counterparts. In particular, tables in SWT are generally problematic.”
That’s sort of false…
JFace exists to bring this MVC’ness to SWT.
http://www.eclipse.org/articles/treeviewer-cg/TreeViewerArticle.htm
http://www-106.ibm.com/developerworks/java/library/os-ecjfw/
At least with SWT/JFace, you have the code to work with.
Cheers,
~ Chris
I’ve used Java 7+ years and been involved with Swing development for around 4 years. I’d heard about how great SWT was, but have yet to spend any time on it. Now I know better and will not waste a single second on it. Hey, there are so many technologies to learn there is no point in learning yet another one that is a hack design – and his comments clearly indicate that it is just that. I have no time for hacks.
BTW – I don’t really like Swing either, but once you get the goals of the MVC design the API is reasonably well thought out.
At least the developers seem to like Cococa best. Swing is a second citizen there, even though it’s one of the best supports of Swing to date. 🙂
Tables and Trees in Swing are much much easier to program and implement because Sun has adhered to the MVC model very very strictly (sometimes too much so). JFace is not a strict MVC implementation and thus you have to understand exacly how the table widget works sometimes. While in Swing you mostly have to implement TableModel and plop your data into the table. With SWT you have to spend much more time to get the same effect.
Swing is almost always faster to get the same effect IME.
I’d be really curious to see a comparison of this to, say, Tk, Fox, wxWidgets, GTK+, QT, FLTK and any other gui toolkits. Mostly in the academic versus practical design aspects.
How about this in C#
using System.IO;
class MyFileReader {
static void Main() {
string buffer = File.ReadAll(“MyCSharpFile.cs”);
Console.WriteLine(buffer);
}
}
note that it’s a static method, plus ReadAll will open, readin the file, and close the file. Also, note that i’m not forced into checked expections. Of course you could’ve just declared throws in your methods, but still..
Too bad that trolltech has no interest in Java (instead they try to position qt and c++ as an alternative to the java platform).
It could be a pretty good match. A fast, flexibel and object oriented toolkit and a language that offers a balances between readability, development speed and execution speed.
Well I maintain the java bindings in the KDE kdebindings module, which has been regenerated for Qt 3.3.4 for the current KDE 3.4 release. That Qt to Java binding is exactly as you describe – see kdebindings/qtjava and try it out..
I won’t debate the academic vs. practical aspects of those toolkits vs SWT, but I will note one difference is that SWT is Java only…that I know of. There was a C# SWT port in the works at one time, but it seems to have died.
With JFace you implement a
– ITreeContentProvider
– ILabelProvider
I don’t see how this is different from a TableModel. You have your model in your ITreeContentProvider.
Here’s how you could implement C#’s readAll in Java. (It’s pretty straight forward):
public static String readAll(String filename) throws IOException
{
File file = new File(filename);
byte[] bytes = new byte[(int) file.length()];
InputStream inputStream = new FileInputStream(file);
inputStream.read(bytes);
inputStream.close();
return new String(bytes);
}
The problem with this is that it leaves you to deal with linefeeds on your own. I often work with data that’s stored in various text formats, with each line representing a row of data. I really want to deal with one line at a time, not as a big chunk where I have to figure out whether the line feed is ‘
‘ ‘
‘ or ‘
‘ so C# readAll(), while interesting, isn’t terribly useful for me.
Actually, adding alot of convience methods means that folks on a team might actually end up throwing in cludges…(e.g. I used readAll to ingest a file, beacuse that’s how I kow to read a file. Now I have to figure out how to right a line feed parser, whcih means folks that inherit my code have to figure out what the heck I’m doing)
Now if it was more pythonesque like this:
input = open(‘somefile.txt’, ‘r’)
for line in input.xreadlines():
….print line
input.close()
well that would save me some typing 😉
Java/Qt bindings was exactly what I was thinking about while reading the article, only I didn’t remember that it already exists thanks to kde
SWT has the huge disadvantage of being a mess to maintain, as each supported platform is a separate implementation, and requires explicit resource management.
Swing doesn’t integrate well with the native look and feel (I disagree with the article’s author there, desktop integration is important), and despite what all java fanboys says, I’m not convinced regarding performance and memory footprint.
A third solution, namely a good cross-platform C++ toolkit that does the task of providing a consistent api and a well-integrated, native look and feel, and java bindings to that, would have the downside of neither of the two preceeding alternatives.
The problem, of course, would that a lot of java developers would not like it for religious reasons as it would not be a pure java toolkit
A constat critique is that programmers dont have aestaticall sense.
That is wrong, in particular it may be like that, but in general … answer this : who doesnt like the macosx aqualicious menus&buttons ? what kind of programmer doesnt like that ?
I honeslty liked verry much the light LCD gnome 1 theme verry much.
I am a programmer, all the extra components for .net (from known companies) have verry good looks, i like office xp looks, and also office 2003 looks.
They are all verry eye catching and ergonomic.
So dont tell me programmers dont have aeastetic feeling!
Hehe, obviously you can write your own ReadAll, but that wasn’t the point.
My C# doesn’t have File.ReadAll under System.IO. I must be missing something.
I normally write a generic library function like this:
public static string ReadFile(string path)
{
string fileBuffer = null;
try
{
System.IO.StreamReader streamFile = new System.IO.StreamReader(path);
fileBuffer = streamFile.ReadToEnd();
streamFile.Close();
}
catch (Exception e) { // do something here }
return fileBuffer;
}
I’m using framework 1.1.4322. Note that you can write almost the exact same code in java using it’s various readers.
> Hehe, obviously you can write your own ReadAll, but that wasn’t the point.
It’s the real point though. You can make your own abstractions any time you want.
Your read all is dangerous in that it can easily suck up unlimitted memory, ithas no latency bound, and has no way of canceling it.
Well I maintain the java bindings in the KDE kdebindings module, which has been regenerated for Qt 3.3.4 for the current KDE 3.4 release. That Qt to Java binding is exactly as you describe – see kdebindings/qtjava and try it out.
I’ve never seen the point in the way bindings are done with KDE. Everyone seems to have this bizarre idea that Java should be bound directly on to Qt classes, and Mono and C# should strictly bound on to Mono/p.net etc. classes leaving question marks as to how to get signals/slots/events/delegates to work together. You simply can’t have an exact one-to-one mapping of these things, and then your still bound by Qt’s license as you’re using Qt as a whole. That’s absolutely fine for Qt itself, but if you’re attracting other languages and toolkits it doesn’t do much at all.
Since kdelibs is LGPL’d then I think there should be an SWT port using kdelibs – after all, it’s been done with GTK. Don’t feel the need to map everything exactly on to Qt classes and ways of doing things. Java isn’t mapped exactly on to MFC and Win32 classes, and I don’t see any reason why that should be the case for KDE, Java or any other language or toolkit.
Hehe, obviously you can write your own ReadAll, but that wasn’t the point.
No, I understand. My point is that convience methods aren’t nescessarily good things because programmers may write code to deal with side effects of convience methods. In this case, my example was that it forces a programmer to deal with line feed issues.
Your read all is dangerous in that it can easily suck up unlimitted memory, it has no latency bound, and has no way of canceling it.
True but if you’re using agile methods, then you can write a simple method like ‘ReadAll’. Then you put in (or have already written) a unit test for the cases that you’re applying it to. If your test fails you can modify the code until your test passes. First rule: keep it simple. 99% of cases may not need to worry about canceling, bounds , or memory. Don’t add that code unless you need it. [Stepping off soap box now…]
I’m not sure how any novice GUI designer can become a SWT fanboy! Eclipse (it’s at version 3, remember!) has the very obvious flaw of not providing a way to automatically produce a SWT or JFace app, complete with necessary JNI libraries and native-GUI (Carbon, GTK etc) libraries. The programmer has to do this manually.
Also, the Mac version does not launch as normal from the Dock. When loading Eclipse itself, a separate dock icon appears with the caption “java_swt”, and the same happens with any SWT app you write.
Oh, and Eclipse takes ages to load.
Since we are doing meaningless comparisions of how simple it is to read a file…
Reading a file line per line:
#include <fstream>
#include <iostream>
using namespace std;
int main( int argc, char** argv )
{
ifstream file;
file.open( “whatever” );
while( file.good() )
{
string s;
getline( file, s );
cout << s << endl;
}
}
Reading a whole file:
void readAll( const char* pFilename, string& s )
{
ifstream file;
file.open( pFilename );
istream_iterator< char > begin( file ), end;
s.assign( begin, end );
}
(sigh, there goes my formatting… betrayed by the preview window. [] are chevrons.)
#include [fstream]
#include [iostream]
using namespace std;
int main( int argc, char** argv )
{
ifstream file;
file.open( “whatever” );
while( file.good() )
{
string s;
getline( file, s );
cout << s << endl;
}
}
Reading a whole file:
void readAll( const char* pFilename, string& s )
{
ifstream file;
file.open( pFilename );
istream_iterator[ char ] begin( file ), end;
s.assign( begin, end );
}
“She didn’t know the taskbar and minimize functionality existed. ”
Nobody would _ever_ guess Alt-Tab if they were not told.
Windows (and the other platforms) should come with a printed manual. None of the GUIs is anything like obvious.
Eclipse (it’s at version 3, remember!) has the very obvious flaw of not providing a way to automatically produce a SWT or JFace app, complete with necessary JNI libraries and native-GUI (Carbon, GTK etc) libraries. The programmer has to do this manually.
Well no. Eclipse gives you nothing, except frameworks to build other GUI builders on top of! Eclipse is really just a non-existant IDE so that people and companies can sell you all kinds of ridiculous non-sensical extensions. Consequently, people install Eclipse and don’t know what on Earth to use. How difficult would it be to produce a proper visual editor?
‘ve never seen the point in the way bindings are done with KDE
It is a different goal. Bindings enable developers to use a platform, in this case KDE, from a different language than the one the paltform’s main API is written in.
In other words the Java bindings let you develop KDE applications in Java.
This is what’s – it translates like this to Smalltalk:
Object subClass: ‘FileReader’
instanceVariableNames: ‘fileName’.
(FileReader new fileName: ‘MyFileReader.st’)
readFile.
readFile
IOError
handle:
[|str|
str:=fileName asFilename readStream.
str atEnd whileFalse:[Transcript show: str readLine]]
do: [^self]
And before someone says it’s one line in PHP, it can be in St too. And no, you needn’t close the file.
The new JVM shares classes across java apps currently running, which means you have a one time cost for loading libraries.
If the JVM was more integrated into the OS, for instance, if OS’s provided a lot of the runtime features for Java, there would be less duplication and things would run faster and with a smaller footprint, but that’s not the case so. =(
*gets ready to break out the “fscanf” don’t make me do it.
For crying out loud, the guy admits to having been made to shut up in his workplace. He obviously simply can’t stand SWT, and the fact that he says that politely doesn’t eliminate the bias.
SWT is what AWT should have been. Swing has improved a lot, but it’s just not there yet. To be honest I don’t think either is a technical marvel. Yet, both have progressed faster than Widgets themselves. He’s correct to point out that many UIs are horrible because of who designs them.
So follow the advice. Get someone to design a clean UI, and then choose the toolkit that can match it better.
One of the problems with SWING UI is that it´s so easy to do custom interfaces. Like custom Tables, custom Trees, custom Menus etc.
No 2 SWING apps look alike; most don´t even share the basic UI concepts of the OS (Take Netbeans 4.1 RC1: A right click will get you nowhere in a lot places (on Windows)).
The article is quite good, and his criticism of the SWT development being Eclipse centered is probably a very core problem. Still I think it´s more of an “Cons” article. A lot of SWT problems arise from bad documentation. In all he doesn´t really point out the “Pros” in SWT (Take the Formlayout e.g.).
SWT was always meant to be limited. It was never meant to be a full SWING replacement. It offers far more than AWT ever did, and offers IMHO the better user experience. Swing fans tend to think that all you have to do make an application “native-looking” is change a couple of dialogs, change some borders + colors (so that´s themes as a whole).
Moreover apps like Winamp are a prime example of absolute crap UI (especially Winamp before V4) (Tiny fonts, non standard configuration).
Azureus is a good example of a Java SWT app that is fit for the desktop (if only more people had the Sun JRE). Maybe that had a lot of frustration, maybe things don´t always work that well – but you have to love systray integration and the hovering download bars.
Swing is an idealistic beauty, Swt is a pragmatic approach. MS history is full of pragmatic solutions (like WFC), and they don´t fare that bad with those.
This article is rather grasping at straws. SWT obviously isn’t complete or perfect, but the notion that users don’t notice how Swing applications look is just total wishful thinking and denial. He shows his total lack of experience there, and he is obviously a developer who is not exposed to users. He even claims that SWT’s native look and feel was motivated by developers!
In my experience, many users don’t even notice these minor discrepancies, and those that do only have a vague awareness that something is a bit different about the application, but they’re not quite sure what.
I’m afraid they do, which is why many people have been abandoning Java client application development in their droves. They know it looks different because it looks damn awful, and native applications that in some cases do exactly the same job don’t look the same way and the certainly look much, much better.
Further indication of the separation of platform fidelity and usability is the success of applications such as iTunes, QuickTime, Winamp and the Firefox browser.
Well, Firefox fits in natively, Winamp uses a different interface but fits in natively. iTunes and Quicktime look good enough, and they fit the purpose for which they’re intended. This is very weak.
When users upgrade from one version of Windows to another, say from 2000 to XP, there are numerous cosmetic differences in the interface presented, but do they suddenly find themselves lost and unable to use previously familiar applications and OS facilities? No, of course not.
No, because it’s familar and it doesn’t look god-awful – not enough, anyway.
And what should we make of the popularity of skin-able UIs? Since WinAmp, the idea of customizing an application’s UI has been well received as a way of personalizing the user experience.
Absolutely not relevant. These are different applications that work well that way for their particular purpose (and that do actually use native look and feel for dialogues etc.). We’re talking about a general purpose toolkit, look and feel for developing all applications. Anyone who has ever been with users using Java applications knows it does matter. That’s why Sun’s desktops and desktop attempts over the years have ended up looking so damn awful, and surprise, no one actually uses them.
There’s some good arguments here, SWT is by no means perfect, but the points he comes up with in response to why SWT was initially developed are very, very weak indeed.
In an enterprise environment today, with .Net and others as competitors, you simply cannot put a Swing application down in front of anyone and expect to be offered a contract or even to be taken seriously. That’s been the case for around seven or eight years since Swing was conceived, and it hasn’t changed.
It is a different goal. Bindings enable developers to use a platform, in this case KDE, from a different language than the one the paltform’s main API is written in.
You need to differentiate between KDE and Qt. They’re not the same, and it is perfectly possible to integrate pretty reasonably with a desktop environment without having to bind to everything. People do it all the time with Windows.
In other words the Java bindings let you develop KDE applications in Java.
That’s not what I’m talking about, nor do I really see the point in that at all. How many KDE/Java applications are there?
You should be able to develop a Java application (and use Java applications) and have it integrate fairly reasonably with KDE. There’s a great deal more mileage in doing that than feeling the need to create bindings to absolutely everything. That’s been a failing so far with such attempts, and has contributed to the widely believed (now universal) myth that a KDE port of SWT, and integration of Java applications, cannot happen.
>True but if you’re using agile methods, then you can
> write a simple method like ‘ReadAll’. Then you put
> in (or have already written) a unit test for the
> cases that you’re applying it to.
This is called generalized behaviour. You don’t know exactly which files in the future you will be asked to read. You do know what characteristics they can have. They can get rather large. In that case they will have the properties i mentioned. A unit test doesn’t help you in anyway here, unless people are required to only read the files you use in your unit test.
>First rule: keep it simple.
No, it’s use your brain.
> 99% of cases may not need to worry about canceling,
> bounds , or memory.
And people wonder why swing apps are slow. Hey, we don’t need to do this work outside the gui thread. Are unit test that did absolutely nothing ran fine. What could possibly go wrong? Apparently we don’t ask those questions anymore.
Yeah, SWT has plenty of flaws (table api). So does swing (7 years and fonts still look like cr*p). This article in no way tried to fairly compare the two – it’s pure propaganda written by a juvenile (he calls SWT fans newbies, zealots, desperate, ridiculous, etc.) hard-core swing fan (7 years experience) bent on trashing a toolkit he doesn’t seem to understand well (4 months experience).
For what it’s worth, I built a fairly complex GUI app in swing, and found it to be a nice developer toolkit. But on delivering it to end users I found out the not-quite-right look and feel annoyed the heck out of people. I quickly rewrote the interface parts in SWT and got a hugely improved reaction.
SWT apps have that hard-to-define “rightness” that swing apps don’t, no matter how hard the Swing partisans want to pretend otherwise. It’s too bad, because swing is everywhere and is nice to program (if a bit baroque). If swing improves as much in the next iteration as it did in the 1.5 release, it’ll be worth looking at again.
void *MMapReadFile(char *filename, size_t &len)
{
int fd = open(filename, O_RDONLY);
len = lseek(fd, 0, SEEK_END);
lseek(fd, 0, SEEK_SET);
void *ptr = mmap(0, len, PROT_READ, MAP_PRIVATE, 0);
close(fd);
return ptr;
}
No, I understand. My point is that convience methods aren’t nescessarily good things because programmers may write code to deal with side effects of convience methods. In this case, my example was that it forces a programmer to deal with line feed issues
Sun is good at propaganda such as you don’t need this, we know what’s best for you. Sun said the same thing about enums and other stuff. I’m not buying it, and considering Sun’s actions lately, neither are many other people.
Once people start telling me “it’s dangerous” and “you don’t need it”, I start questioning if they are really being just defensive if their pet language.
You can say the same things about pointers in C#. But to me it’s just the same old Sun propaganda that I ignore. Native code integration is an order of magnitude easier in C# than Java.
Did you even RTFA? He pointed out that he spent 76 hours just working around bugs in SWT.
And I’m hardly a defender of Swing. I think it’s been a disaster, with the horrible fonts being the number one reason.
Qt’s dual GPL/commericial licensing doesn’t work with the SWT/Eclipse license, CPL, which is more BSD-like. Bottom-line is, because of the GPL linking restrictions, a free version of SWT running on “free” GPL QT is not possible from a legal perspective. I used to work for OTI/IBM back and have dealt with this issue/Trolltech.
GTK is LGPL on the other hand, which pretty much solves the library linkage problem. Thus, GTK was chosen for the Linux SWT ports.
It’s not a question of being possible to do a direct SWT port technically.
Did you even RTFA? He pointed out that he spent 76 hours just working around bugs in SWT.
I seriously question that figure, especially coming from someone who obviously didn’t want to use SWT in the first place. You have to look at the context of the article. This guy doesn’t like SWT period, and his arguments against SWT’s native look and feel and the reasons why it was done are weak to none-existant.
I’ve done a reasonable amount of development with SWT on Java projects simply because a lot of Java developers I’ve worked with are desperate for it. They can’t afford to use Swing, have applications that look like total arse and lose out on major projects. It’s a killer reason (has been ever since people started developing client Java applications), and it is absolutely unbelievable that after all this time he paints over this as a non-issue. I think this is just wishful thinking, and quite frankly, Gosling and the Sun guys are once again closing their eyes and hoping these client issues and SWT will just go away.
As an aside, all things considered, I think the way that Qt gets this balance between non-native but easier to maintain cross platform development (looks like crap – Swing) and native cross platform development (looks much better, but is hellish to maintain between platforms) is dead right. It’s the age old problem in cross-platform development, and it keeps coming up.
Anyway, I’ve never spent the amount of time he’s quoting working around bugs in SWT and we’ve developed some reasonably complex interfaces in the past – although I won’t pretend there haven’t been bugs. Hell, there’s bugs in Win32 and .Net GUIs, particularly surrounding focus. The next few months will be interesting as I’ll be doing a fair bit of staggered .Net/Java/SWT/Qt development, so queue the swearing at various programming tools. Maybe I should keep a diary and write a review………
Given that Eclipse is a complex GUI, and is actually more complex than most people will ever design and program, the bugs you come across are actually few and far between in most applications. I don’t buy that argument in this article, and I don’t buy the argument that your application has to be close to Eclipse functionally to actually be useful. You can mould SWT and the Eclipse stuff into just about anything – it is just a GUI after all.
I think this article has highlighted just how desparate the Swing people are now, and how desparate Sun are over the whole issue. Whinging and squealing about it certainly isn’t going to help them.
GTK is LGPL on the other hand, which pretty much solves the library linkage problem. Thus, GTK was chosen for the Linux SWT ports.
Nice try – try reading previous posts.
This may be an issue for using Qt, unless you buy a license of course
, but it isn’t an issue for KDE. As has been pointed out, the core kdelibs are LGPL’d therefore a port of SWT is perfectly possible to KDE itself. This is what has made it possible for GTK applications to use KDE look and feel when run under KDE.
Yes, I read TFA. From start to end. Where do you think I found out they made him shut up in his workplace?
This ‘article’ is nothing more than a poorly based rant. About the only thing he actually points out is that SWT’s widgets aren’t as featureful as Swing’s. The rest is garbage. Not a single meaningful comment on either toolkit.
SWT has bugs? 76 hours? How many hours did he lose with Swing’s bugs in his first 4 months with it? WONTFIX? Java (and Swing) is Wontfixland. At least Wontifixuntilsomeone pulls a much more elegant thing and threatens eroding the platform.
Or do you think one couldn’t write books on Swing’s shortcomings?
The funny thing when hearing about SWT’s ‘zealots’ is that I have yet to find one. I don’t go looking for them, but I don’t go looking for Swing zealots either, and they do pop up. Like the article guy.
In fact, all the people I’ve found using SWT seem to use it by reasoned decision. Like in weighing their situation. For Swing it’s usually SWTwhichinevermasteredisadeadendswingroolz. Like the article guy.
I don’t think anyone who needs to decide between one or the other will learn anything from this article.
The author spends a lot of time ranting and raving at a high level about heavyweight vs lightweight widgets. This argument really doesn’t belong in the discussion of the various merits of detractors of SWT. We’re told that the author has spent a long time on a lot of problems, but we’re not exposed to what they actually are. In the reference I’d appreciate links to the dozens of bugs he claims to have created or tracked. Instead he gives a single anecdotal example of a vertical favorites bar. Where are the bugs related to this favorites bar implementation?
Its hard not to read this as the rantings of an anti-SWT zealot. I want to give him credit for being in-depth; however most of the depth is superfluous hatred toward being forced to learn something new.
> This may be an issue for using Qt, unless you buy a license of course
, but it isn’t an issue for KDE.
Yes, I never mentioned KDE in my comment, I specifically referred only to the QT port. I appreciate the clarification though I don’t appreciate the condescending “read previous posts” remark. Not that I don’t expect it in a computing forum.
The real question there becomes, does porting SWT to KDElibs really buy you anything? I’m interested in a real discussion about this, rather than just “it can be done”. If GTK can already use the look-and-feel of KDE, by extention, Eclipse can use it as well.
Swing looks bad. Every user I’ve shown it too has complained about how it looks. Big things like crappy fonts. Mid sized complaints of widgets looking like they support features which they don’t. Tiny things like the expanders on tree widgets.
And Bugs. I don’t know if SWT claims to have a HTML editing widget or not, but Swing does. Claim it does that is. The thing is so useless. I’ve seen several projects that have belatedly supported what they call HTML editing using Swing. I’ve been forced to write one myself and the fact is, it doesn’t understand HTML, requires no end of customisation to get any functionality in it at all. It’s still crap even after you replace almost every component of it just to fix bugs, add in all the missing features etc. It produces output that even it can’t display, meaning you can’t even edit content created with it. And did I mention how bad the fonts the look.
Netbeans basically looks like a badly rendered java app with ugly fonts no matter when you run it. It seems like quite a nice IDE apart from that. At least Eclipse looks sort of okay. Thus far as a user I’d rather use Eclipse than Netbeans.
I understand a bit why AWT and Swing look so bad. It predates many GUI efforts. When I first used it (before it was even stable), I was impressed with its breadth, but it looked a little backward even then. I think that it’s unforgiveable that Sun ignored the client side for 7 or 8 years. While every other desktop (except possibly CDE on Solaris) was making strides in desktop usability and appearance, Java was still looking like the state of the art in 1994. While 1.5 made improvements in some aspects, nothing has changed in others.
Sun needs better font rendering and it needs to use better default fonts. Even the editor in IntelliJ IDEA looks like yet another crap java editor.
Yes this counts as putrid bile from a Java developer. Compared to Java apps, GTK on a Mac looks a bazillion dollars. No wonder most java devlopers I know are solely server side web developers.
This is in response to David and Bleyz.
If you’ve been following the goings on of Mustang, you’ll note that Sun is getting into the “native” game again.
SWT has to emulate certain things and work around platform specific idiosyncracies.
Swing went overboard with the “give me a handle to a brush and we’ll do everything ourselves”. It seems that they’ve learned their lessons.
Personally, I could care less about Platform L&F as much as the horrid fonts that are in Swing.
I look forward to seeing how Mustang turns out.
By the way, does anybody know if current Mustang snapshots have fixed the font problem?
I haven’t done any Swing programming in a while. Does it still default to Metal? If so, that is incredibly stupid.
SWT bindings just for KDE are beyond useless and obviously the Qt license wasn’t going to fly.
Too bad that IBM didn’t buy Trolltech years ago.
am using netbeans 4.0 in windows xp and I don’t noticed any of the “bad” fonts that you guys keep on mentioning, although I would agree if I was using netbeans in linux.
Let me guess…you’re using a CRT as your monitor?
the author works for English-speaking boss and produce pure English applications right? See how many languages eclipse support through swt and gtk!
I like the paragraph about jface, and the months’ work dealing with bugzilla. It seems the author’s team had a very good opptunity of contributing to eclipse, and open source movement. Not everyone has the chance of touching swing source code in any cvs or so.
SWT bindings just for KDE are beyond useless and obviously the Qt license wasn’t going to fly.
I think KDE SWT bindings would be useful if it meant you could have a version of Eclipse with KDE widgets and file dialogs and so on – that would be quite nice. But IBM’s CPL isn’t compatible with the GPL, and so that is that really.
It isn’t possible to bind just the KDE api without also binding the Qt api – KDE programs use a lot of the Qt calls. And any language bindings for Qt or for KDE *must* be GPL’d. The kdelibs are only LGPL’d because of a special agreement with Trolltech.
That doesn’t stop someone with a commercial Qt license from developing a binding with a dual license scheme as long as they wrap the Qt api, rather than build another api altogether such as SWT. That is what has done with PyQt, and I believe the commercial version has sold several hundred copies.
Trolltech would regard a Qt based SWT as a threat to their business as it is a cross-platform toolkit competitor, whereas a binding like QtJava or PyQt complements the C++ version of the toolkit. There has never been sufficient demand to produce a dual licensed version of QtJava though, unlike PyQt.
Too bad that IBM didn’t buy Trolltech years ago.
I disagree, that would have been a disaster.
t is perfectly possible to integrate pretty reasonably with a desktop environment without having to bind to everything
Absolutely true, but I was referring to the bindings and also tried to tell you that the very idea about bindings is to offer as much as possible of the bound API.
That’s not what I’m talking about, nor do I really see the point in that at all
Yes, that’s teh different between a KDE or Qt based implementation of a Java toolkit and KDE or Qt bindings.
However latter might be a way to implement first.
How many KDE/Java applications are there?
I don’t know any. Java, as a language, doesn’t seem to be attractive enough for development if you bind to a desktop API.
You should be able to develop a Java application (and use Java applications) and have it integrate fairly reasonably with KDE.
I fully agree. I guess anyone interesed could provide such integration code to the JDIC project.
Anyway, you wondered about the idea or concept behind the Java bindings and I tried to explain that using Java to develop a KDE application and integrating an otherwise independent Java application with KDE through some wrapper toolkit are two different use cases for Java.
because of the GPL linking restrictions, a free version of SWT running on “free” GPL QT is not possible from a legal perspective
Isn’t this a inconvenienc that could have been avoided by a better CPL?
Usually other widget toolkits in any languages aren’t licenced in a way that makes using them in GPL programs impossible.
I mean GPL is fairly common for applications, not having that option when using SWT sounds like a major restriction for me.
Isn’t this a inconvenienc that could have been avoided by a better CPL?
How about a better GPL
Usually other widget toolkits in any languages aren’t licenced in a way that makes using them in GPL programs impossible.
You’re completely confused. SWT is a toolkit. Qt is a toolkit. SWT uses other toolkits for it’s native layer. The fact that Qt is GPL makes it completely unnacceptable for use with SWt.
I mean GPL is fairly common for applications, not having that option when using SWT sounds like a major restriction for me.
SWT is a toolkit library, not an application and you’re right, the GPL is restrictive. Why do you think all the major players (RedHat, Novell, and Sun) chose gtk+/Gnome as the basis for their desktops?
If you’ve been following the goings on of Mustang, you’ll note that Sun is getting into the “native” game again.
Well yes, quite. This is obviously in response to what SWT is doing, so quite what this article is going on about I have no idea.
It’s probably going to be too little too late for Sun on this issue. People have been complaining about it since Swing, and AWT, were started many, many years ago.
How about a better GPL
Would be an option as well, but AFAIK the GPL was already in use when the CPL was created, so it explicitly contains something to make it GPL incompatible.
You’re completely confused
Hmm, I don’t think so.
I said that other toolkits, at least the one I know of, like Qt, GTK+, wxWidgets, FOX, FLTK, etc can be used in GPL licenced applications.
I just find it odd that SWT seems to be the only toolkit that can’t.
SWT is a toolkit library, not an application
Come on, I didn’t write anything like that.
I wrote that GPL is a common licence for applications, actually a quite popular one, very likely the most popular one for free software applications.
If, for whatever reason, an author wants thair application licenced under GPL, SWT is automatically not an option due to its licence.
Why do you think all the major players (RedHat, Novell, and Sun) chose gtk+/Gnome as the basis for their desktops?
I think Sun chose gtk+ because they don’t like C++ much and prefer C, rather than for licensing reasons. They aren’t promoting writing apps in the gtk+ api directly, only in Java Swing. So I don’t think the gtk+ license comes into it much for them, and the GPL vs LGPL issue is a bit of a red herring.
AFAIK Novell haven’t chosen Gnome or KDE as the basis for their desktops, and they support both in their various products.
You might have a point about RedHat though.
Trolltech would regard a Qt based SWT as a threat to their business as it is a cross-platform toolkit competitor, whereas a binding like QtJava or PyQt complements the C++ version of the toolkit.
I’m not particularly interested what Trolltech considers as a threat. It is actually important for KDE (and Qt and Trolltech) to grow the platform that they use in different ways and different areas. Java support is one of them. Microsoft has realised this quite successfully by allowing people to create development tools that even compete with their own, because they support Windows. That’s a bit of a problem for the future of KDE, although it’s probably the best option technologically out there. You need a certain amount of flexibility there.
That doesn’t stop someone with a commercial Qt license from developing a binding with a dual license scheme as long as they wrap the Qt api, rather than build another api altogether such as SWT.
Yes, but you’re writing Qt applications in another language there. KDE would need to support other languages and toolkits without imposing Qt on people.
I disagree, that would have been a disaster.
So do I, very much so. It is extremely doubtful that Qt would have been improved as much as it has if Trolltech was bought, and as much as it will move into the distance and out of sight of anything else on any Unix/Linux platform when Qt 4 comes out pretty soon. Everyone, and everything, else will have a lot of catching up to do which I don’t think they’ll be able to do.
It’s a dilemma, and there’s no easy answer whatever option you choose.
SWT is a toolkit library, not an application and you’re right, the GPL is restrictive. Why do you think all the major players (RedHat, Novell, and Sun) chose gtk+/Gnome as the basis for their desktops?
1. Sun looked at Gnome and GTK and the technology around it (i.e. written in C, and their darling, CORBA) and made the decision there and then. In fact, when they saw CORBA support within Gnome that made their mind up there and then.
2. Novell doesn’t use GTK for the parts of their business that makes money. The desktop used for OES is KDE and the front-end for YaST that they use is written with Qt for KDE. Inside Novell at the moment GTK is pretty irrelevant, however much people want to paint a picture otherwise.
3. Yes, when Red Hat started Qt was too restrictive for them (and not cost effective enough for them – probably would be now though) and so they used GTK. I agree there.
no am using a laptop, it looks ok to me, didn’t notice anything “bad” bout it
Yes, I understand that people want to be in denial that Qt licensing issues had NOTHING to do with Sun choosing Gnome, and Novell basing all their desktop efforts on Mono/Gtk+/Gnome.
Richard, you work on the KDE language bindings so I understand your motivations. David knows I’m right but because of his intense hatred of Mono, Gnome, Ximian, and just the fact that Novell bought Suse, he won’t admit it. David, we’ve been through this same song and dance many times before and I still haven’t figured out why you have such a strong allegiance to KDE/Qt when you try to portray yourself as someone that is above the zealot fray and actually understands business motivations.
To suggest that Trolltech owning all copyright and having the dual-license scheme was NEVER brought into consideration is naive at best and disengenous at worst. I’m sure Novell and Sun’s marketing and legal departments had NO opinion whatsoever on the subject (rolls eyes).
Let’s face facts, KDE has a better framework and Qt is a better toolkit, but if glibc had the same license as Qt it would have to be rewritten.
This looks like a job for a Perl oneliner.
Printing the contents of a file
perl -pe “undef $;” filename.txt
Can’t get much cleaner 🙂
Back on topic: What I miss is a a free RAD tool like Delphi or Visual Basic for Java. I think that would be the killer app.
hmm… the backslash was removed
Should be “perl -pe “undef $[BACKSLASH];” file.txt
perl -pe “undef $\;” file.txt
Yes, I understand that people want to be in denial that Qt licensing issues had NOTHING to do with Sun choosing Gnome
Nope they didn’t – see above. If you think Sun, and other companies, are concerned about licensing issues then by that rational they should be able to open source all of Solaris because all of it is under their control. Here’s the cluestick – they don’t and it isn’t.
Companies like Sun cross-license and license from other companies all the time. It’s highly unusual when they don’t, and when they found out the full horror of Gnome development many felt that they should have taken that option.
and Novell basing all their desktop efforts on Mono/Gtk+/Gnome.
Here’s another cluestick – they’re not. Have a look at what makes the money at Novell and you get rather a different picture. However, I know you like to swallow that one whole with a nice big glass of water, so we’ll leave it.
Novell, like most companies, actually base the vast majority of their desktop effort around Windows, but we’ll suspend reality for just a bit longer.
David knows I’m right but because of his intense hatred of Mono, Gnome, Ximian, and just the fact that Novell bought Suse, he won’t admit it.
Blah, blah, blah………………..yawn.
David, we’ve been through this same song and dance many times before and I still haven’t figured out why you have such a strong allegiance to KDE/Qt when you try to portray yourself as someone that is above the zealot fray and actually understands business motivations.
Yer – because I’m right. There’s been ample evidence as to why I’ve taken the views I have, and they’re not difficult to figure out.
I’m sure Novell and Sun’s marketing and legal departments had NO opinion whatsoever on the subject (rolls eyes).
I think you grossly overestimate the importance of such issues to these companies. They may appear to be important on OSNews, but not elsewhere. I’d be highly surprised if Sun and Novell’s legal, or especially, marketing departments were ever primarily involved in any choices. Sorry, but Gnome, open source desktops and insignificant little toolkits like GTK and, yes, even Qt are not top of their priority list unless they bring in cash. Considering that KDE, Qt and YaST does and will do for things like OES at Novell, you be the judge.
I doubt whether many marketing or legal people at Novell have ever heard of Mono or know what it is, and I shouldn’t think they give two straws. None of these companies like Novell are ever the united, steady ship and strongly bonded team many idiots around here think they are.
…but if glibc had the same license as Qt it would have to be rewritten.
Glibc is nowhere near the complexity of a toolkit like Qt, nor are there the same user-facing demands placed on it. Amusingly, if glibc was like that then I’m afraid you would have to put up with restrictive licensing because that’s what would be required to make it good enough.
A toolkit like Qt needs to be developed further, needs maintained and needs to have adequate first-rate up-to-date documentation to get anywhere in the real world. Nothing less will do. That needs to be funded, and needs a stable source of funding. If the open source community doesn’t have the resources to be able to do that themselves for a desktop toolkit, and then develop all the open source applications on top of it, (and it is now becoming very clear that it doesn’t) then it needs to be funded in some other way. With Qt, KDE has that other way, and it is paying more dividends for them than some of the hurdles it might represent.
Quite frankly, if some software isn’t good enough then it doesn’t matter how liberal its licensing is, and that’s what we’re seeing materialising today. SWT or no SWT port, when Qt 4 comes around (and with some suitable development time) KDE will be off over the horizon and out of sight of anything else (GTK and Gnome 3 will be vapourware for quite some time). Even then, that may not be enough to actually get anywhere.
I thought you were in denial, but maybe you are just clueless about many things.
Nope they didn’t – see above. If you think Sun, and other companies, are concerned about licensing issues then by that rational they should be able to open source all of Solaris because all of it is under their control. Here’s the cluestick – they don’t and it isn’t.
Companies like Sun cross-license and license from other companies all the time. It’s highly unusual when they don’t, and when they found out the full horror of Gnome development many felt that they should have taken that option.
You just don’t get it, do you. It has nothing to do with Sun or Novell themselves guying a Qt license for a particular project. It has to do with passing on a straight GPL’d toolkit to their customers. Until you get that through your head, then there’s really no hope for you in understanding these things.
Here’s another cluestick – they’re not. Have a look at what makes the money at Novell and you get rather a different picture. However, I know you like to swallow that one whole with a nice big glass of water, so we’ll leave it.
Novell, like most companies, actually base the vast majority of their desktop effort around Windows, but we’ll suspend reality for just a bit longer.
Here’s a heads-up. Novell is not making any money on Suse or Ximian or anything else linux-related at this point. They’re hoping in the long run to, but not yet.
David knows I’m right but because of his intense hatred of Mono, Gnome, Ximian, and just the fact that Novell bought Suse, he won’t admit it.
David: Blah, blah, blah………………..yawn.
Yeah, I know that one hurts you, and it was best for you to just avoid the issue all together.
I think you grossly overestimate the importance of such issues to these companies. They may appear to be important on OSNews, but not elsewhere. I’d be highly surprised if Sun and Novell’s legal, or especially, marketing departments were ever primarily involved in any choices. Sorry, but Gnome, open source desktops and insignificant little toolkits like GTK and, yes, even Qt are not top of their priority list unless they bring in cash. Considering that KDE, Qt and YaST does and will do for things like OES at Novell, you be the judge.
I doubt whether many marketing or legal people at Novell have ever heard of Mono or know what it is, and I shouldn’t think they give two straws. None of these companies like Novell are ever the united, steady ship and strongly bonded team many idiots around here think they are.
Wow, you really are clueless about how business works aren’t you. I’m really surprised on this one. Let me clue you in once again. Legal and Marketing is ALWAYS involved in decisions regarding software development – especially when the software is outside open source. But I’m sure Sun’s legal department had no clue when Sun decided to ditch CDE for Gnome (rolls eyes). And Novell’s legal department was supposed to clarify the Mono situation – and hasn’t yet, but once again you’re wrong on that point too.
As far as your tangent comments about “united, steady ship and strongly bonded”, I guess that’s your way to meander offtopic in order to weasle out of the topic on-hand.
Glibc is nowhere near the complexity of a toolkit like Qt, nor are there the same user-facing demands placed on it. Amusingly, if glibc was like that then I’m afraid you would have to put up with restrictive licensing because that’s what would be required to make it good enough.
I’m not going wc -l on glibc or Qt or discuss the relative complexities of either, because I don’t think either of us is qualified to. I will point out that though even Stallman was rational enough to put glibc under LGPL or GPL with linking exceptions (whichever one it is). I’ll also point out that people have been doing gui toolkits for a long time, and it’s not exactly rocket science. Yeah, some are better than others, but it’s no rocket science and at this present point in time it doesn’t really matter, but companies like RedHat, Sun, and Novell are betting on the future.
Gtk+ is already being funded by Novell, RedHat, and Sun. So I don’t know what your comments regarding funding are all about.
SWT or no SWT port, when Qt 4 comes around (and with some suitable development time) KDE will be off over the horizon and out of sight of anything else (GTK and Gnome 3 will be vapourware for quite some time). Even then, that may not be enough to actually get anywhere.
The irony of your statement is that it doesn’t really matter how great KDE 4 is. It’ll always be hampered by the current Qt license. That’s just fact, and you just don’t want to admit it.
Now even Swing (in Java 6) will be using more and more of gtk+ for it’s underlying drawing, thus marginalizing Qt even more.
To reiterate, the issue has nothing to do with Sun forking over 10-20k to Trolltech, but passing on a viral license to its customers. These things don’t really matter now, and who knows, maybe Linux on the desktop will never take off, but Sun, RedHat, and Novell is sure hoping that’s not the case.
By the way, you might want to check out this article by Nicholas Petrley http://linux.sys-con.com/read/32764.htm, who on numerous occasions has praised the consistent desktop of KDE.
There’s another article of his that talked about top Sun engineers looking at Gnome/Gtk+ code and saying it was crap, but the point is that Sun would buy Trolltech before passing on a viral license to its customers.
P.S. I know you’re from the UK, but you sure act like one of those dipt-dialiners when it comes to these issues. And we all know what their motivations are.
I thought you were in denial, but maybe you are just clueless about many things.
Zzzzzzzzzzzzzzzzzzzzz…………………
It has to do with passing on a straight GPL’d toolkit to their customers. Until you get that through your head, then there’s really no hope for you in understanding these things.
Linux obviously must be a problem then. Many, many Linux and Unix companies pass on GPL’d software in their products every day. When it comes to KDE it suddenly, and very amusingly, becomes a problem.
Here’s a heads-up. Novell is not making any money on Suse or Ximian or anything else linux-related at this point. They’re hoping in the long run to, but not yet.
Guess where that ROI will come from, if it does?
Yeah, I know that one hurts you, and it was best for you to just avoid the issue all together.
Yaw….Zzzzzzzzzzzzzzzzzzz
Legal and Marketing is ALWAYS involved in decisions regarding software development – especially when the software is outside open source.
If you’d ever been in a company the size of Sun or Novell you’d know that there is no conceivable way that legal and marketing people are involved in every single activity and project that goes on. People in the company use what they want to use, especially technology-wise, with some guidance when it becomes necessary.
Only Slashdrotters think like that, because they think everything is a magical well-oiled machine. They’ve never been in a company of any size. You obviously haven’t.
As far as your tangent comments about “united, steady ship and strongly bonded”, I guess that’s your way to meander offtopic in order to weasle out of the topic on-hand.
Weaselling – good one
. Way off-base and totally clueless – see above for yet another explanation. You fully understood what was written, and if you didn’t, then honestly – why post on such issues and embarrass yourself even more? I’ll assume you’re impervious to embarrassment by now.
But I’m sure Sun’s legal department had no clue when Sun decided to ditch CDE for Gnome (rolls eyes).
Technology drives decisions in software companies, not legal issues. Why do you think Novell/Suse uses KDE (they’ve certainly never sees it as a problem) and Red Hat/Sun and others use Gnome? They are idealogical decisions based on what they like technologically.
You’re stirring around all the gears trying to find something license related, but unfortunately there’s no drive.
And Novell’s legal department was supposed to clarify the Mono situation – and hasn’t yet
Yer, and?
but once again you’re wrong on that point too.
Can’t remember mentioning Mono in that way, but I do remember mentioning one diddy little department at Novell saying they would clarify the issue and they haven’t. So what’s new?
I’m not going wc -l on glibc or Qt or discuss the relative complexities of either, because I don’t think either of us is qualified to.
What was that about weaselling?
I will point out that though even Stallman was rational enough to put glibc under LGPL or GPL with linking exceptions (whichever one it is).
Stallman, Stallman, Stall……………..Zzzzzzzzzzzzzzzzzzz. It depends on whether the software can be funded adequately to be LGPL’d. You’ll notice there’s a correlation between that and how complex and user-facing said software is
.
I’ll also point out that people have been doing gui toolkits for a long time, and it’s not exactly rocket science.
Making one that’s good enough for users and developers with documentation that is good enough is.
Gtk+ is already being funded by Novell, RedHat, and Sun. So I don’t know what your comments regarding funding are all about.
If you don’t know how software of different kinds has its development funded by different methods, then honestly, don’t bother.
The irony of your statement is that it doesn’t really matter how great KDE 4 is. It’ll always be hampered by the current Qt license.
Only little Slashdrotters care about whether a little piece of software is LGPL’d or not. Real people in the real world care about software being good enough, regardless of the license it is published under. In the case of Qt, if they don’t want to use the GPL then they’ll buy a license if necessary – happens every day of the week in normal organisations.
Open source people have to be realistic about what they can do, what they need help with and what they can’t do in order to achieve software that is good enough.
Now even Swing (in Java 6) will be using more and more of gtk+ for it’s underlying drawing, thus marginalizing Qt even more.
Since the vast majority of Java development in the world is done on Windows, I hardly think so. If they’re going to use GTK on Windows……….
Anyway, since Java with GTK doesn’t support about 60% of all the Linux and Unix desktops out there (those running KDE that is), are they marginalising themselves?
There’s another article of his that talked about top Sun engineers looking at Gnome/Gtk+ code and saying it was crap, but the point is that Sun would buy Trolltech before passing on a viral license to its customers.
Nicholas Petrely ended up buying some of that misinformation because desktop Linux had never taken off. It just isn’t cost-effective to buy development tools because there’s no market, and as such people look at what they can develop for nothing. When there is that market, people will buy development tools like Qt for Linux.
As I’ve mentioned, Sun and other companies pass on the GPL to their customers all the time – no problem there. They’re in the business of managing licenses and all of that so you don’t have to
. The license issue is passed off as a reason, but it’s obviously technological preference and wanting their own pet technologies.
P.S. I know you’re from the UK, but you sure act like one of those dipt-dialiners when it comes to these issues. And we all know what their motivations are.
Yaw……Zzzzzzzzzzzzz………My goodness, is that the time?!
I’ve noticed that there is not a single second reply on hacknot when the editor’s argument is being rebated. I’ve proposed Mr. Ed to include a little manifesto which will go well with the whole philosophy of the Site:
1. The world is NOT full of fascinating problems waiting to be solved.
2. EVERY problem should ever have to be solved twice.
3. Boredom and drudgery are GREAT.
4. Freedom is EVIL.
5. Attitude is GREAT substitute for competence.
Now I’ll post the reply I was denied on HackNot:
—
I’ll first look at two assumptions you make at the beginning and will continue rebating *all* your conclusions.
>>Limited Functionality
Right. Just like Eclipse.
>>Bugs & Enhancement Requests
This is a problem with software development. Everybody makes mistakes. Open Source just makes solving bugs much faster than traditional software development does.
Now to the conclusions.
>>If you believe that the greater platform fidelity of SWT will make for a more usable application, what actual evidence do you have to support that conclusion?
This is the reason why Linux doesn’t take off. This is the reason why Windows will stay.
>>It’s hard to find good GUI developers. Finding good GUI developers with SWT skills is even harder.
It’s hard to find good developers. It doesn’t matter the language, focus,…
>>Taking a Swing developer and giving them SWT is like taking someone used to riding a Harley Davidson and giving them a Vespa motor scooter.
Eclipse devs have managed to *make a space rocket out of a vespa*.
>>How close is your target GUI to the Eclipse GUI? Be aware that every time you step even a little way beyond the functional demands of Eclipse, you are on your own.
You don’t need at all Eclipse to develop SWT GUI. You can go way beyond Eclipse. Just because you don’t know how to doesn’t mean you can’t.
>>Due to the bugs and shortcomings in SWT, your developers will be working with a lowered productivity, and so you should expect project delays and/or increased resource requirements. Can your organization justify this extra investment?
Your organization probably is using Eclipse, obviestly because it lowers productivity.
>>Before deciding that Swing applications are slow and ugly, take the time to look at products like Netbeans or any of those listed at the Swing Sightings site. I have heard people voice these opinions, having not looked at Swing since the days of AWT.
Did you know that awt is faster than swing because it is closer to native than swing is? Did you know this is the reason why web start is done with awt? Did you even know that Swing sits on top of AWT? Quoting James Gosling: “and if you look at the SWT architecture, it’s almost exactly the same as AWT. It has all the AWT problems: it’s way simple, it doesn’t port very well”. I wouldn’t say it’s got the same problems as it is faster and more responsive… You can read it from: http://www.builderau.com.au/program/work/0,39024650,39176462,00.htm… All arguments against SWT are spurious like yours.
>>Let me suggest you subscribe to the SWT newsgroup1 and mailing list 2 where you will get the perspective of those who have been struggling with it for a longer period of time
Problems arise with *all* technologies, including Java. Joining dev-lists helps solving them.
>>Is consistent cross-platform performance important to you? This might lead you away from SWT, as it appears to be experiencing real performance issues on some non-Windows platforms.
I use eclipse on GTK and it goes just fine. Better trying than listening to what others say.
Finally I’ll give you a few companies that totally agree with your views, that’s why they joined the eclipse foundation:
*BEA, Borland, Computer Associates, Intel, Scapa Technologies, Sybase, Inc., Wind River, Strategic Consumers, Hewlett Packard, MontaVista Software, SAP AG, Serena Software*
If you want to debate you can disagree but I don’t think it’s very wise to use sentences like the following, specially if it is you who wrote the article:
>>Now run along and play elsewhere. If, through some heroic effort, you should ever develop reasoning skills beyond those taken for granted by the average five year old, come on back.
It doesn’t seem like you’ve got it clear enough.
And remember, ignorance is the root of all evil.