Skip to main content

Mustang Swing wishlist

39 replies [Last post]
carniz
Offline
Joined: 2004-02-09

I think it's about time that a couple of components/widgets are added to JFC/Swing, such as a date chooser widget for example. I was amazed the other day when I was about to write a small resource booking app in swing and realized that the Swing library does not contain a date chooser! Of course, there are commercial add-on components available such as JDatePicker but I'm not willing to pay $119 for a single component!! Sure, there is JCalendar as well, but I really believe a calendar/date picker widget is such a commonly used widget that it should be part of JFC.

Among other missing components is a font chooser, and that's also pretty strange. Fonts are such a basic thing in graphical programs, how can it be there's none in JFC/Swing?

A set of DB components (such as those in Delphi) would be nice as well, but that's probably not the easiest thing to implement (but it would probably make Java more popular with those who build "meat-and-potato db apps" for small to middle sized companies though)

For a good list of available add-on Swing components, check http://weblogs.java.net/blog/hansmuller/archive/2004/10/another_40_swin....

And now a poll: what kind of components would you like to see added to Swing in Mustang(Java 6)?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
zander
Offline
Joined: 2003-06-13

> The main point of my post was that dates(/times) in UIs are as common as muck. Can we agree on that? I'm not
> an analyst, but I'm getting the majority of "business" applications use dates in their UIs extensively.

Well, as another posted commented that he has not used one in years, and I personally have more applications without one then with one, I'm not going to agree on that one.

The rest of your post reports your situation and why you did indeed go ahead and create the thing yourself.
This is fine, and Sun will surely have very good reasons itself to not have spent time on this kind of component. But your reasoning is not relevant for this thread. This thread asks what people want Sun to spent time on in the future (limited to Swing). You already have a datepicker and you can still follow my advice to pick up a good datepicker from a 3th party.

I (actually, a collegue of mine) did follow the advice to put the companies work out as open source. You can download it and use it without ever consulting the licence-guard-dogs you say you fear. Please use that one and let Sun get back to fixing Swing bugs!
The data-picker which IS mature, free and al that is here:
http://uic.sf.net/index.phtml?target=product/DatePicker/view.phtml

jwenting
Offline
Joined: 2003-12-02

> > I've worked "permanently" for three companies.
> Guess
> > how many Java date pickers I have written or been
> > involved with?
>
> I hope none since you can look at various pickers
> that are either for sale or open source and free to
> use.
> Or are you one of those people that only see the
> products Sun gives you or you made yourself?
>
There's a lot of companies that for some reason or other don't allow the use of anything created outside the company.
Others have extremely arduous processes to get things authorised for use, so arduous in fact that it's often faster, easier, and cheaper to implement it yourself.

jessewilson
Offline
Joined: 2003-06-14

> You know what would be cool? If Swing were
> integrated with the Collections API

You can already get some of this behaviour with Glazed Lists. It allows you to use a List like a TableModel, ListModel or ComboBoxModel.
http://publicobject.com/glazedlists/

> and utilised things like Java's lovely new Generics
> and enum facilities.

This is a great idea. SwingConstants could be replaced with type-safe enums and layout managers could enforce appropriate contraints objects using generics.

mgrev
Offline
Joined: 2003-08-12

> JSpinner needs to suck less. I mean seriously, for something so simple, how can it be so badly implemented?

Because from a technical point of view it might be excellent. All custom editors, formatters, models and cool shit like that, all from the latest OO design patterns; but:

1) How do you set a different date format for the date jspinner? That should be SO simple.

2) Why does the date jspinner go bananas when you set a date format that doesn't include the year.

I know the answers of course, but they where way too hard to find.

Most things in Swing is made for getting high technical review retings. But the user friendlyness blows.

How do you check if a JComboBox has an item already?

Do you know the answer?

Cheers,

keithkml
Offline
Joined: 2003-06-10

I agree completely.

tackline
Offline
Joined: 2003-06-19

XAWT is included in Sun's Linux and Solaris version of 1.5. It's not the default for Solaris, but you can export AWT_TOOLKIT=XToolkit or -Dawt.toolkit=sun.awt.X11.XToolkit. XAWT is an AWT toolkit/peer implementation using xlib and the Synth engine, IIRC, (as used by the GTK PL&F) instead of using Xt and the Motif native library. See sun.awt.X11.XToolkit instead of sun.awt.motif.MToolkit.

http://java.sun.com/j2se/1.5.0/docs/guide/awt/1.5/xawt.html
http://servlet.java.sun.com/javaone/sf2003/conf/sessions/display-1999.en...

1.6 was, IIRC, going to do something similar for Windows. However, it (or 1.7) now looks as if both Windows and GTK PL&Fs will be using native rendering libraries. So presumably AWT will be implemented with lightweight components, but the actual drawing will be done by native libraries.

http://weblogs.java.net/blog/bino_george/

flozano
Offline
Joined: 2004-01-22

Forgot about other problems we Linux users have with Sun Swing and AWT that a new implementation based on GTK might solve if well done:

4. Accented characters. It's very hard to use international keyboard layouts with a Java app. Gnome itself and SWT has these problems on their first releases but they are long solved; Swing still has bad surprises specially when I try to get a "ç" (ç)

5. I talked about font rendering, but the key here is not exactly GTK but Xft.

s690716
Offline
Joined: 2004-03-04

> So, in short, why is it more important for Suns Swing
> developers to spent time on redoing whats other have
> already done an excellent job of providing then on
> fixing bugs ?

Counter question: Why there exists a framework like Swing, when other have already done (or do) an excellent job? Some catchwords: standard component, platform independence, "write once run anywhere", uniformity (ui).

Why Swing? All you need ist AWT... correct answer?

And now my wishlist (adopted from mfc, gtk, aqua and .net):

* data-binding (like implemented in ado)
* date picker, time selector
* font chooser
* directory chooser, network chooser
* print preview (and advanced printing)
* tree table
* advanced clipboard and drag 'n drop functionality
* ...
* only standard os widgets in a platform independant way (swt is a good example) - not more

rbair
Offline
Joined: 2003-07-08

> if thought jdnc was addressing the widgits for
> data-connectivity rather than purely ui widgits?

Actually, all of our widgets are pure UI widgets. The data-connectivity and binding code works irrespective of the UI widget. So, for example, there is a TextBinding for binding a widget that has a Document (like JTextField and JLabel) to a String property on a bean.

Richard

keithkml
Offline
Joined: 2003-06-10

I've been writing Swing applications for years and I've never once written an application which required a date picker. I have, however, come across dozens and dozens of Swing bugs which I had to spend time working around and sometimes reporting.

tackline
Offline
Joined: 2003-06-19

I've worked "permanently" for three companies. Guess how many Java date pickers I have written or been involved with? Okay, in one case it wasn't Swing as they'd written their own widget set (for goodish reasons). Putting in a little time to get together a generic, productised, PL&F-friendly date picker doesn't seem an unreasonable suggestion to me.

zander
Offline
Joined: 2003-06-13

> I've worked "permanently" for three companies. Guess
> how many Java date pickers I have written or been
> involved with?

I hope none since you can look at various pickers that are either for sale or open source and free to use.
Or are you one of those people that only see the products Sun gives you or you made yourself?

> Okay, in one case it wasn't Swing as
> they'd written their own widget set (for goodish
> reasons). Putting in a little time to get together a
> generic, productised, PL&F-friendly date picker
> doesn't seem an unreasonable suggestion to me.

Asking Sun to donate even more resources so you don't have to go out and find a datepicker from one of the dozens of providers does not sound unreasonable? I could also say that if you write one datepicker twice you could have said to one of those companies to do it in an open source manner so two companies can divide the costs for one component. That sound quite reasonable to me.

tackline
Offline
Joined: 2003-06-19

The main point of my post was that dates(/times) in UIs are as common as muck. Can we agree on that? I'm not an analyst, but I'm getting the majority of "business" applications use dates in their UIs extensively.

As a broader, secondary matter, should Sun enhance or take its desktop toys away, limiting involvement to maintenance. I'm sure Microsoft wouldn't be above welcoming Java developers into the ways of C#/.Net. (Un?)fortunately I'm not a Sun shareholder. However, I don't think it'd be in Sun's interest to get a reputation for cutting and running for the next shiny, like certain software companies. The JDNC project(s) might kind of give an indication which way desktop Java is heading.

Finally, the long personal bit, which is largely irrelevant as to whether Mustang should have a date picker (together with sidetracks) -

Date (time) widget I: I'm not entirely sure whether I looked for a buyable solution or not. In any case, after spending a year writing and getting into production a couple megs of code, I was given a very inexperienced VB programmer to help. Rather than launch him into the middle of the code base, the date-time widget gave him a self contained project to get up to speed with Java. In any case, I doubt there was much in the way of useful solutions available back in '98.

Date widget II: This is a little different in that widget set was built in-house because of the exact way it was required to work. That time ('99) I did waste sometime looking searching for what was available. What I did find was of low quality and not suitable. So I spent three weeks nicely factoring our combo box and implementing date editing. Actually it was quite interesting the way it fitted in with the programmers' model where date fields appear as type of text fields not combo boxes. Initially I tried to make it look and behave like the MFC version, which unfortunately has the appearance of an angry fruit salad. Sometime later I was browsing through the support database and found that one of the very few users phoned just to say how beautiful it was and much better than the MFC.

Date (time) widget III: This project I joined part way through as I had nothing else better to do, so didn't have the choice to go looking. Perhaps I could have done instead of straightening out and testing the code. Anyway, management decided they didn't want the project anymore.

Here's the problem: Most open source software is just plain bad. It tends to have really poor quality code, poor usability and productisation is for wimps. Not only do you have to clean up after someone else's dumb mess of dubious parentage, you then have to go through your company's bureaucracy to acquire and then sell it as part of a bigger product. If, by chance, the acquired software is maintained then you have the fun of observing and feeding that through. All for a small piece of code. Opening proprietary code isn't fun either. Not only is there costly bureaucracy, but you have the fun of people trying to contact you for support and slashdoters getting their knickers in a twist.

So, I'm happy to include pervasive third party products. Say, JUnit despite some rather poor code and Tomcat despite its past under-performance. I'm less happy about tiny weirdo projects found off of some search engine.

Forgot to look up an obvious encouraging URL:
https://jdnc.dev.java.net/source/browse/jdnc/swingx/src/java/org/jdeskto...

Message was edited by: tackline

mgrev
Offline
Joined: 2003-08-12

Here are some reasons why a date picker in Swing is quite the challenge to create:

(With date picker I mean both the popup type and the simpler "chained date part" -type)

* SimpleDateFormat can't parse a date string in the context of another base date. So if you have the pattern “MM/dd” you can't parse that in the context of the current year for instance, it defaults to 1970. There is actually no good way around this, setting the year to the desired after the parsing will for not work (leap years etc).

* JSpinners doesn't work unless the date string pattern parses a full unambiguous date. Same as above. This means that you can not chain multiple JSpinners to form one date (E.g. Year, Month, Day spinners to form a date). Not in a generic way anyway. You will have to have very specific knowledge about what part of the date a JSpinner represents. This is not possible in a generic API unfortunately.

* You can not subclass or decorate a JComboBox and customize it so that you show a popup date picker. The absolutely simplest case might work (but what I remember, it didn't), but more than that is simply not possible due to package private things that needs to be accessed.

* You can not in a platform independent way recreate the looks of a JComboBox so that the Date Picker looks like a normal combo box. For instance the drop down button is not possible to recreate or emulate.

* There is no DateRange class in the API. This means that a date picker has to resort to arrays of dates or some other obscure hack to represent date ranges. This might also work in the absolutely simplest of cases, but generally you want a DateRange class if you are going to pick dates (or hours, weeks, months or whatever). Creating a DateRange class is not as easy as it might first seem (inclusive/exclusive start/end time as well as optionally open ranges for instance)

*There is no DateGroup class that would take a number of “date part proveders” and make them represent a single point in time. The first two bullets make creating one hard as well.

Trust me when I say that we have invested a lot of time in this. When making the MiG Calendar component we had to work around all these things, and there are many more minor things to work around than I have mentioned here.

But it IS doable, it just takes a lot of effort.

Cheers,
Mikael Grev
http://www.migcalendar.com

schlm3
Offline
Joined: 2003-06-11

I am a Swing programmer from the very first hour on.
The really only wish I have is, that Sun fixes those many BUGs in Swing. Especially interested in fixing the JTextPane for HTML-Editing support.

keithkml
Offline
Joined: 2003-06-10

Yes, HTML support sucks, compared to modern browsers, and hasn't improved in a while. I think it would be great if Sun could make a full browser supporting all common standards. Maybe JDIC is where this will happen, but JDIC doesn't allow editing HTML in the browser window.

edburns
Offline
Joined: 2004-02-11

Maybe Sun will finally get around to filing a JSR for a java browser API. Hopefully, if they do, they'll look at http://www.mozilla.org/projects/blackwood/webclient/ Mozilla Webclient for API ideas.

Ed

luggypm
Offline
Joined: 2003-06-13

How about some XML mark-up system for GridBagLayout ? Something that lets you seperate out layout data from code ?

For example:

You'd initialise the layout with something like:

GridBagLayoutXML myGridbag =new GridBagLayoutXML(xmlElement)

and set a constraint with

myGridbag.setConstraints(myComponent,"name.label");

I've got a custom GridBagLayout subclass I've written for this, but found that the major problem is the initial overhead for parsing the XML (I'm using JDOM). So I'm now looking at some kind of system to translate the XML into a custom faster to read format.

tackline
Offline
Joined: 2003-06-19

What's stopping you separating layout from control creation now? Anything that can be done in XML can be done in Java (typically more easily).

I tend to have a View class with methods to create each component. Then the layout class does something along the lines of:

JComponent component = view.createNameLabel();
cons.gridx = 0;
cons.gridy = 0;
cons.gridwidth = 1;
cons.gridheight = 1;
cons.fill = NONE;
cons.anchor = EAST;
cons.weightx = 0.0;
cons.weighty = 0.0;
cons.insets = new Insets(2);
cons.ipadx = 0;
cons.ipady = 0;

If you really wanted to stick to using the component name property, it's easy enough to change the get method to call a method that retrieves the component from a container by name.

Because we are now in Java, we have more scope to use the power of a programming system (unless you're an XSLT die-hard).

Obviously multiple components changing constraints in details are easily handled. Using an enhanced version of the GridBagConstraints builder also cuts down on the clutter:

new Contraints()
.gridLocations(0, 0, 1, 1)
.fill(NONE)
.anchor(EAST)
.weight(0.0, 0.0)
.insets(2)
.ipad(0, 0)
.add(panel, view.createNameLabel())
;

markf
Offline
Joined: 2005-01-20

You know what would be cool? If Swing were integrated with the Collections API, and utilised things like Java's lovely new Generics and enum facilities.

Oh, that and the bug fixes... so many bug fixes.

We need a calendar component too. It's an embarassingly standard component, and every other windowing system has one.

JSpinner needs to suck less. I mean seriously, for something so simple, how can it be so badly implemented?

And a monkey! You should get a free monkey mailed to you whenever you install the JDK. For installing just the JRE, Sun could mail out a large beetle, or maybe a shrew. And if you download the complete Java source code, you could a full grown rhinocerous.

evickroy
Offline
Joined: 2004-07-23

Personally, I think the JGoodies Forms Layout, Binding, and Validation frameworks should all be included in the core Swing packages in Mustang. The Forms Layout greatly simplifies laying out the gui. The binding has been missing since day one for simplifying the building of data-centric apps. And the Validation framework is rather obvious as well.

cowwoc
Offline
Joined: 2003-08-24

My 2 cents:

Don't add any new components, except maybe the tri-state checkbox, and instead focus on fixing the thousand and one open Swing bugs. There are just waaaaaaaaaaay too many open Swing bugs that need to be fixed and many of them are pretty important. I'd rather feature-freeze until we get the majority of them cleaned up.

The only new feature I'm interested in is better native L&F for Windows -- this requires some new APIs for toggling things like the existence of the maximize, minimize buttons on the titlebar, etc.

Gili

Message was edited by: cowwoc

mgrev
Offline
Joined: 2003-08-12

+1

A man of infinite IQ, experience and exactly the right basic life values couldn't have said it better; cause it's true. :)

Cheers,
Mikael

flozano
Offline
Joined: 2004-01-22

Yes, I want new AWT peer based on GTK, Pango and other Gnome libraries and not on old Motiff anymore, besides following JFreeDesktop.org standards. This would provide a lot of benefits and make Java on Linux desktops viable:

1. Most Applets have to use AWT for compatibility with outdated browsers and jvms, and the motiff AWT widgets look terrible on Gnome or KDE

2. Try to cut-and-paste from a Java app (Say, NetBeans) to a non-Java app (say, Mozilla or OpenOffice). It simply doesn't work.

3. Font rendering. Recent Linux distros feature beautifull anti-aliased fonts, but Java can't use them and this alone makes even the System Look and Feel look amador

4. Fix the GTK Look and Feel. I could not see it work ok and look like the other desktop apps, either using 1.4.2 or 1.5, on Debian, Red Hat or Fedora. Simple things like menu separator aren't shown and toolbar buttons do not have a uniform look. This could be done without new peers, but I guess new peers and use of other Linux-specific libraries (that is, Gnome or KDE-specific libraries) would make the task much easier and the results much better

Today you simply can't convince a Linux desktop user to run a Java app. They look ugly and don't interoperate with the standard desktop. Using custom LAFs like JGoodies make they look better but don't solve clipboard and font problems.

zander
Offline
Joined: 2003-06-13

> Yes, I want new AWT peer based on GTK, Pango and
> other Gnome libraries and not on old Motiff anymore,

Ehm; doesn't XAWT do that already?

> 2. Try to cut-and-paste from a Java app (Say,
> NetBeans) to a non-Java app (say, Mozilla or
> OpenOffice). It simply doesn't work.

Since this is a question about Swing, I'll answer that copy/paste in Swing works good enough. Its far from mature, but good enough.

> 4. Fix the GTK Look and Feel. I could not see it work
> ok and look like the other desktop apps, either using
> 1.4.2 or 1.5, on Debian, Red Hat or Fedora. Simple
> things like menu separator aren't shown and toolbar
> buttons do not have a uniform look. This could be
> done without new peers, but I guess new peers and use
> of other Linux-specific libraries (that is, Gnome or
> KDE-specific libraries) would make the task much
> easier and the results much better

I respectfully disagree here; its useless to follow the GTK look&feel in a Swing implementation because of various issues. The fact that GTK is very configurable in look and feel is the major one. People say following the Windows L&F is a moving target, but GTK moves much faster.

> Today you simply can't convince a Linux desktop user
> to run a Java app. They look ugly and don't
> interoperate with the standard desktop. Using custom
> LAFs like JGoodies make they look better but don't
> solve clipboard and font problems.

I have been doing Java Swing for years and since 1.4.2 the clipboard problem is solved mostly.
The font problems seem to be solved in GNU CLasspath already; which is probably usable before Java 6.0 comes out.

flozano
Offline
Joined: 2004-01-22

> > Yes, I want new AWT peer based on GTK, Pango and
> > other Gnome libraries and not on old Motiff
> anymore,
>
> Ehm; doesn't XAWT do that already?

We were talking about Mustand, that is, Sun Java.

> > 2. Try to cut-and-paste from a Java app (Say,
> > NetBeans) to a non-Java app (say, Mozilla or
> > OpenOffice). It simply doesn't work.
>
> Since this is a question about Swing, I'll answer
> that copy/paste in Swing works good enough. Its far
> from mature, but good enough.

Never managed to get it to work, except a few times using the old X convention of middle button to copy the current selection, not the popular edit>cut and later edit>paste (or ctrl+c and ctrl+v) popular on Windows, Mac, Gnome and Gtk. I'll be happy with plain text, even if rich text and graphics continue not working.

> > 4. Fix the GTK Look and Feel.
>
> I respectfully disagree here; its useless to follow
> the GTK look&feel in a Swing implementation because
> of various issues. The fact that GTK is very
> configurable in look and feel is the major one.

Agree that GTK is a much more difficult target, but see the reaction to the new XP laf from 1.4.2 or the great work Apple did on Java for the MacOS X. For the "end user" standard desktop appearence, mouse and keybindings are very important.

> I have been doing Java Swing for years and since
> 1.4.2 the clipboard problem is solved mostly.
> The font problems seem to be solved in GNU CLasspath
> already; which is probably usable before Java 6.0
> comes out.

GNU Classpath uses GTK for it's AWT peers implementation, just the thing I am asking Sun to do on its own Java implementation. Sad I can't compile SableVM and GNU Classpath on Fedora out-of-the-box. :-(

robilad
Offline
Joined: 2004-05-05

> GNU Classpath uses GTK for it's AWT peers
> implementation, just the thing I am asking Sun to do
> on its own Java implementation. Sad I can't compile
> SableVM and GNU Classpath on Fedora out-of-the-box.
> :-(

Try JamVM 1.24 or Kaffe from CVS head. Hop on #kaffe on irc.freenode.org if you run into trouble.

cheers,
dalibor topic

markf
Offline
Joined: 2005-01-20

Maybe now that we're getting a units and metrics library, JSpinner could be updated to handle units and metrics. It would be handy for all kinds of things.

igor_ti
Offline
Joined: 2005-01-18

I developed a Swing App. and build some pretty components like DatePicker, MoneyField with built-in Calculator, DBCombobox, DBTable and DBTreeTable (data binding) through a very simple persistence engine that simplifies the db access for simple tasks.

Take a look on http://sf.net/projects/gfd

It's Open Source!

[]’s Igor

carniz
Offline
Joined: 2004-02-09

Looks good!

/Mikael

tsinger
Offline
Joined: 2003-06-10

Well, I would say, look promising ;)

Tom

zander
Offline
Joined: 2003-06-13

> Of course, there are commercial add-on components available [...], but I'm not willing to pay $119 for a single component!!
> Sure, there is JCalendar as well, but I really believe a calendar/date picker widget is such a commonly used widget that it should be part of JFC.

Please explain to us why you feel that both a commercially supported version as well as free (and pretty good working) versions don't work for you?

The JFC is pretty full and the Swing developers need all their time maintainting that and making sure those get to be pretty good for a next release. Asking them to take on more work when there are at least 10 calendar components out there just means less features others have asked for will get in the next release.

So, in short, why is it more important for Suns Swing developers to spent time on redoing whats other have already done an excellent job of providing then on fixing bugs ?

ps; I like this page:
http://wiki.java.net/bin/view/Main/SwingComponents

carniz
Offline
Joined: 2004-02-09

>Please explain to us why you feel that both a commercially >supported version as well as free (and pretty good working) >versions don't work for you?

Never said they don't *work*. JDatePicker is too costly, as I'm a poor developer trying to start my own business without any funding. JCalendar is ok, but I just think it's strange that swing doesn't provide a "complete" set of widgets for *most* applications. Look at Delphi or .net - they provide (for example) date pickers as well as a lot of other "standard" widgets out of the box. Sure, they don't have 3DFooBarBazComponentTypeA or 3DFooBarBazComponentTypeB, but those components are not very standard either ;-)

Another argument is that if swing provided "the components currently missing", you could count on them being 100% L&F compatible with the core L&F's. This is not the case sometimes, and you end up with one or more components in your app looking/behaving different than the others (making the app look very "unprofessional")

>So, in short, why is it more important for Suns Swing >developers to spent time on redoing whats other have >already done an excellent job of providing then on fixing >bugs ?

It's up to Sun to prioritize what's more important - I just do my request and let them decide what to spend resources on. There's a _lot_ of stuff to choose from (fixing bugs, reducing JVM footprint, etc) and I'm not in position to decide what's most important (I would probably vote for JVM footprint/startup time if asked) - BUT, if they have a minute or two ;-) to spend when everything else is fixed, I'm not totally unhappy if they decide to add some components to swing =)

zander
Offline
Joined: 2003-06-13

> if [Sun employees] have
> a minute or two ;-) to spend when everything else is
> fixed, I'm not totally unhappy if they decide to add
> some components to swing =)

A friend of mine made a date picker (see http://uic.sourceforge.net/index.phtml?target=product/DatePicker/view.phtml) and therefor I can tell you from experience that creating a good component takes weeks. Debugging it for different JVMs takes even longer.

I, personally, really dislike that Sun put the JSpinner in the standard release since its very buggy and lacks very lots of basic functionality (mouse-wheel for example).

Problem is that its become impossible to fix the thing since there are a host of applications depending on its behavior. If you ask me, I'd hate more widgets going into the core without it being an open source project for a while first with lots of peer review and possibility to change API if really needed.

That said; why can't you use one of these open source components and fix any issues you find with your favority L&F.
To get to your specific example; the datePicker from uic (as linked above) works fine under various L&Fs. Any bugs you find (or fixes you make) are very welcome, and will be acted upon. This in contrast to the JFC components which probably have similar problems, Sun engineers are not perfect, you know :)

pete_kirkham
Offline
Joined: 2003-06-20

> Of course, there are commercial add-on components available such
> as JDatePicker but I'm not willing to pay $119 for a
> single component!!

[url=http://javadesktop.org/jdnc/0_5/docs/api/org/jdesktop/swing/JDatePicker.html]This[/url] JDatePicker is free and licensed under LGPL.

The jdnc project is supposed to be addressing the more-widgets issue.

Pete

asjf
Offline
Joined: 2003-06-10

my vote would be for a JTristateCheckBox - there is a RFE for this in the bug database, but who knows if it will happen??

if thought jdnc was addressing the widgits for data-connectivity rather than purely ui widgits?

asjf

zander
Offline
Joined: 2003-06-13

> my vote would be for a JTristateCheckBox - there is a
> RFE for this in the bug database, but who knows if it
> will happen??
>
> if thought jdnc was addressing the widgits for
> data-connectivity rather than purely ui widgits?

Have you considered writing one yourself? I mean, from nothing (extending JComponent) and doing it correctly.

Beats waiting another couple of years :)

Alternatively; you could ask a professional swing programmer to do it for you if you don't have the time/expertise..

chbeer
Offline
Joined: 2003-08-12

I think there are a few nice widgets in SWT. Why not add them to Swing?
- Closeable-Tabs
- Improved Toolbars
- etc...

For my opinion, there are quite a few open-source libraries that have very nice widgets. Taking them all as standard-widgets in JSDK is a bit too much. Leaving them outside as add-on-librarys is the better way.

Christian

subanark
Offline
Joined: 2004-11-26

Closable tabs are in Netbeans. There is an entire library (jar) devoted to just that feature.