Showing messages 1 through 148 of 148.

• sag.StellentSagPollTask - Error
  2004-06-08 11:57:29 vmjoshi
  
  All,
  
  I received the following error message. Can someone provide insight on why this is happening?
  
  Thanks,
  
  vmjosh
  
  'Access Denied. Either you entered invalid credentials or you sent a request to access this resource from a non-trusted host. Requester IP Address received: '123.29.4.120'.'
  2004-06-01 16:41:23,928 [Thread-0] FATAL sag.StellentSagPollTask - Error fetching tasks.
  Error Code 1000
  
  I am using Applet-Servlet combination with JRUN App Server

• Higher Level = Ease of Use
  2004-06-02 23:36:04 scheide
  
  To attract those former VB coders that Sun is seeking, a higher level of abstracton for the most common tasks needs to be set, and more common components, as stated below, need to be created.
  
  JTable, for example, while extremely flexible, should have default renderers and editors of the most common components. There should be, for example, a StringCellRenderer and StringCellEditor so you can not only call setCellRenderer (new StringCellRenderer) but also have common methods to set the alignment, font, etc. These base renderers of common components then can be easily understood and subclassed by developers.
  
  In addition, simple methods like setCurrentRow/Column and getCurrentRow/Column would be nice. A simple event like Before and AfterRowColumnChange (passing the current row/col and the moving to/moved from row/col) would also be nice. Better default support of validation within cells is necessary.
  
  A tool to create Synth Look And Feels (showing a tab of components that reflects colors in real time as you set them) could be part of the JDK. Well, maybe I'll look into that one later myself.
  
  In summary, I wouldn't remove any of the flexibility provided by the current Swing APIs but a good look at VB with its high-level approach would attract many developers to Java if an equivalent high level API existed for newbies. For those anti-VBers, please realize it was the most popular language with millions of developers that permitted quick development and those people are seeking a new home. Those languages that permit them to feel at home will gain their adherence.
  
  Simple is good, where possible.

• Just a few of my thoughts
  2004-06-01 06:57:56 wgauvin
  
  I'm really a J2EE developer, and haven't had much experience in rich clients, but for some of my own little projects at home I've tried to use Swing.
  
  Of the IDE's i've used (JBuilder6 and NetBeans) the GUI Editing has a lot to be desired, which requires one to dig through JavaDoc to find something that might work. Netbeans has a serious lack of 'non-visual' components. I remember way back when I played with VB that things like timers and that could be added to a form in a visual way, even though they were non-visual (things like AbstractActions would be a good example). Perhaps other IDE's do this, but I'm trying to point out that just the GUI editors have some serious gaps that could help with 'ease-of-development' (which is Tiger's catch phrase).
  
  This may have been thrown around, but Sun needs to split the client/gui stuff in to a sub-edition of Java, like J2EE is built off J2SE there should be something like J2CE (Client Edition). Majority of Swing is in the javax package structure, which was introduced for the ability to backport things like Swing to Java 1.1. Perhaps if AWT/Swing and any other GUI model is given a dedicated 'edition' and expert group within the JCP, then better tools and support would come of it

• highlevel HTML rendering widget
  2004-05-31 12:14:56 ivar
  
  I'd just like to say the HTML rendering in swing leaves something to be desired for those interested in modern CSS design. Having SWT/JFace use mozilla gecko as it's rendering engine is a huge incentive to use that toolkit set.
• highlevel HTML rendering widget
  2004-06-01 03:35:40 guidoamabili
  
  I think a new java official native look_and_feel should be created and detached from the swing framework., focusing on ease and speed.

• Brainstorm for an open letter
  2004-05-28 13:10:02 jonathansimon
  
  

  There has been a lot of good discussion about the direction of Swing on this forum. So far, the suggestions break down into two categories: suggestions for the community at large, and suggestions for the Swing team and Sun.

  Joshy started a wiki page for Swing information that I think is a good starting point for us getting together as a community to make Swing development easier. I think there are a number of places we can go from there -- but it's still a good starting point.

  I think we are at a point where we could write an open letter from the Swing community to Sun. This could lead to a a more formalized dialog with the Swing team and Sun with regards to prioritization of enhancements and bugs one step up from the "Bug Parade." An open letter may bring the issue to the forefront with Sun the same way we have discussed it publicly these past few weeks on this forum.

  I'd like people to respond in this thread with suggestions that the Swing team can do as well as what we can do as a community. Next week, we will have a vote and I will post the letter on this forum with the results. After comments and suggestions to the letter, we'll post it on java.net.

  -jonathan

• Brainstorm for an open letter
  2004-06-01 12:11:07 markswanson
  
  Here's my 2 cents:
  
  I think what Sun and individual Swing developers are missing out on is a patch/fix/enhance community. I can't help but draw parallels between the Swing open source community and the Linux open source community.
  
  In the Linux case folks can participate by sending in bug fixes/patches/enhancements.
  
  I maintain this is virtually impossible with Sun's bug reporting system.
  
  In the Linux case folks can get feedback _from_ the authors/maintainers and other members of the _community_ on patches/fixes to various components of the kernel.
  
  This channel does not seem to exist with the Swing developers, though I don't know how to get the patches/fixes to them in the first place... (and no community exists so no feedback from them is possible)
  
  In the Linux case folks can send feedback _to_ the authors/maintainers and other members of the _community_ about patches/fixes to various components.
  
  Currently the Swing team accepts a feedback email or you can post to the forums, but I don't know of a parallel way (central location preferrably at Sun) to discuss these ideas with the _community_. Folks just don't seem to be doing this in the forums.
  
  Any project that suffers from lack of feedback from its core users will wind up not delivering, and over time will likely "get lost in the weeds". (As other Java packages certainly have, dig...).
  
  I believe there are a good number of knowledgeable Swing developers out there who are dependent on Swing and who would be capable of providing valuable feedback, patches, and fixes. I think the Swing team would enjoy such feedback and find it useful (as would the folks participating).
  
  From my perspective, it seems that any and all possible suggestions/fixes/patches/feedback hinge on a single point: the method of communication.
  
  An open source project like Swing that has a large number of developers should be benefitting from its community - like other open source projects do.
  
  The only reason I can see Sun not wanting to do this is because of a perceived cost in time and resources to participate, and a low return on investment (low signal to noise ratio).
  
  If a (Swing internals) mailing list and patch monkey was set up how bad could the s/n ratio be? It simply _can't_ be that bad, and even if the Swing team had low participation it will let the community develop. New ideas will foster there. It will grow to be a valuable part of the Swing team/developer community, and it will be fun.
  
  Cheers.
• Brainstorm for an open letter
  2004-05-31 11:57:50 swapnonil
  
  Complete text at http://navycut.blogspot.com
  
  I have been reading the forum discussion taking place at java.net over the last couple of days, and here is a summary of what I think a lot of us Swing developers want.
  
  1. For Swing components to be more usable, it seems that they, not only have to emulate the look of native components, but also the feel of native components as well. A case in point is this..This is where I think Sun's current implementation of Swing lacks in.
  
  2. More "Out of Box" the components. If you go through this list of Swing components page you will find that there at least 5 implementations of a Calendar Dialog, a Font Chooser and numerous other implementations of Wizard frameworks. With so many open source projects cropping up, we developers tend to choose implementaion of components on our own whims and fancies as most of the listed implementations are stable. Now this creates a situation where every John on this planet gets presented with a new type of Calendar Dialog while using any swing gui. If Sun could provide more out of box widgets this will go a long way towards gui standardisation, which in turn would benefit application users by cutting out the surpsrise element situation.
  Other ideas for "Out of Box" widgets are A>A professional property sheet. B> An enhanced Datagrid (like the ones provided by JClass etc)
  
  3. Change in the JInternal Frame behaviour. When you place a JInternal Frame inside desktop pane, you would expect that, when you maximise this internal frame the close,minimise and maximise/restore button group would appear to the extreme right of the menubar of your application. Instead they appear in the extreme top-right corner of the desktop pane. This is irritating .The internal frames (top components as they call it) inside the Netbeans 3.6 IDE corrects this problem and I think there is no reason why Sun cannot adapt this solution into the Swing's JInternalFrameUI.
  
  4. Adopt and Add widely used open source layout managers like TableLayout, JGoodies Forms layout etc into the layout package.
  
  5. Last but not least please give us an Application Development Framework over Swing API. I talking about exactly the same features that JFace adds over the SWT API.

• What are your thoughts on documentation?
  2004-05-25 09:19:48 joshy
  
  I personally learned a great deal about Swing by just reading the Swing Trail in the Java tutorial. It never seemed complete though. I eventually bought the O'Reilly Swing book that fleshed out most everything (though there's always the odd thing you have to just google for). What would you like to see happen with regards to documentation?
  
  If we ever have a blueprints and large sample app I think that should be in the standard docs. My other big complaint is that most people have to use the JavaDocs. The api for JButton or JComponent is huge, even though most of the time you never need more than about 5 methods. Would it be possible to create a second set of Javadocs containing only the most frequently used methods, with links to the full set? Maybe this is a use for the new metadata in 1.5.
  
  - Joshua
• Better documentation for key functionality
  2004-05-26 17:10:20 mgrev
  
  This is the documentation for setPreferredSize() in JComponent:
  
  "Sets the preferred size of this component. If preferredSize is null, the UI will be asked for the preferred size. "
  
  I sais what it does but not what it is used for. For newbees it would be of greater value to have a doc that goes something like this:
  
  "If not null this value overrides the preferred size that the UI delegate provides. This value will be read by the layout managers during layout and adhered to in different degrees depending on which layout manager is used. Note that just setting this size wont actually change the size, that will be done during the next layout cycle".
  @see LayoutManager
  @see LayoutManager2
  @see LayoutManager
  @see ComponentUI#setPreferredSize()
  @see JComponent#revalidate()
  
  
  I know I had some problems with swing's layout / resizing agorithms when I started, and it was very confusing since I didn't understand how powerful it was, and thougt it was broken as best.
  
  I short: The documentation should target a little more than just what the methods/classes does, it should give some hints of how to use it as well.
  
  Cheers,
  Mikael
• What are your thoughts on documentation?
  2004-05-25 12:39:07 k_mccarthy
  
  

  The java doc don't help you to use the classes well, because they lack context. Many methods need to be used at the right time, not any old time.

  examples help provide some of that context. The ones found in the tutorial or most Swing books are limited, though. They show you how to use one widget in a toy setting. This teaches how to use the widget but not how to build an app. In addition, examples usually lack any discussion of design. Knowing why we structure some code one way helps teach how to handle other widgets in similar circumstances

  I think Swing needs something like "Core J2EE Patterns" - a book which discusses complicated examples and explains the hows and the whys.

  Kevin

• Where does Sun's responsibility end and our's start?
  2004-05-24 17:12:43 ashleyherring
  
  There have been lots of really good points raised in this discussion forum. Lots of suggestions of where Swing can be improved - better layout managers, better font management, wider range of UI components, etc. All good info.
  
  My question is - are these really Sun's problems or should us, as the Java developer community take some responsibility for making Swing better?
  
  I'm not necessarily talking about working through the JCP here either. The Swing API is designed such that most of these issues raised can be addressed by building customised extensions to what already exists. It's one of the things I really love about Swing, it is so highly open and customisable.
  
  So, what I'm getting at is with Java + Swing we are already being provided, for free, with a pretty solid foundation for writing good user interfaces. If something we need is missing, well fire up your IDE and start coding! .... And do us all a favour, open-source it, so as a community we can start building up a repository of really useful Swing extensions.
  
  There already exist several projects that are doing just that. To give one example, plenty of people here have complained about Metal being too out-of-date. Well, write your own LAF and stop whining! Or if that is too big a job, download one of the many freely available LAF implementations and move on.
  
  At the end of the day, Swing is a very open API. The source code is there, it has been designed from scratch to be highly extensible and customisable. What more do we expect Sun to do for the good of the community? Isn't it time we, the development community, picked up the ball on this one?
  
  javadesktop.org is probably a good a place as anywhere to start.
• Where does Sun's responsibility end and our's start?
  2004-05-26 06:22:50 pulse1014
  
  "Where does Sun's responsibility end and our's start?"
  
  Forgive me but did Sun just make swing open like swt? If not, how does our responsibility start when swing still isn't open source?
• Where does Sun's responsibility end and our's start?
  2004-05-26 18:49:38 rickcarson
  
  Open Source:
  (1) I can view the code
  (2) I can get a running implementation for free (as a direct result of #1 if nothing else)
  (3) I can change the code
  
  ------ Is Java Open Source? --------
  
  (1) is true (if you download the jdk)
  (2) is true (the jdk is free)
  (3) is true.
  
  #3 is true *because Java is an OO language*!!!
  
  Hello McFly! *whack* Its OO!!! *whack* If you want to change it, just subclass it!!! *whack* Use inheritance!!! *whack* *crack*
  
  Darn, my LART just broke.
  
  I move that saying "Java is not Free/Open Source" be classified as trolling with intent to bait, and summarily banned.
  
  All those in favour....?
• Where does Sun's responsibility end and our's start?
  2004-05-28 05:46:03 pulse1014
  
  You cannnot change Java - and have your changes distributed as the reference api. Subclassing a class does not mean that you are actually changing it.
• Java _is_ open source (since 1999 at least)
  2004-05-26 09:01:21 markswanson
  
  Code is either open (you can easily download it and look at it) or it is closed (not much chance of ever seeing it).
  Sun has opened the code. You can freely download it and look at it.
  Perhaps folks can argue over which open source license is better, but I don't see how anyone can argue it isn't open.
  
  http://wwws.sun.com/software/communitysource/j2se/java2/download.html
• Java _is_ open source (since 1999 at least)
  2004-05-26 13:14:08 pulse1014
  
  There's a difference between viewable code and open code. I can't really do much, nor have much responsibility if I all I can do is look. I would like to be able to look and fix things. Coding separate work arounds over a problem instead of actually tackling the root of the problem is ussually not an ideal solution.
  
  Swing is viewable - not open.
• Java _is_ open source (since 1999 at least)
  2004-05-26 15:51:49 ashleyherring
  
  Err... here is a revolutionary idea - email Sun your fix! If there is something terribly broken and you can see a way to fix it, then send them the fix. I sure they aren't going to dismiss it out of hand - who know's it'll probably end up in the next JDK release?
  
  I find it curious how many people in this forum seem to be of the view that Sun "owes" them something, as if they had bought a product off them.
  
  Java is pretty open - the language spec, the VM spec, the java.xxx library source code etc. is all there for everybody to read. There is nothing to stop people from writing their own GUI libraries in Java or any language they want and providing JNI bindings. Hence, IBM and their SWT toolset - they didn't like Swing so they built their own.
  
  Take Java3D for example. A lot of people creating 3D programs thought is sucked.... what they wanted was Java bindings for OpenGL. So rather than complain about Sun not providing them as part of the Java APIs, they wrote JOGL.
  
  At the end of the day, you haven't purchased an expensive suite of developement tools of Sun by wanting to use Java. If you don't like the tools it comes with - use something else. If you don't want to move off Java, then either write or use another GUI library.
• Java _is_ open source (since 1999 at least)
  2004-05-26 17:05:29 pulse1014
  
  Once again - a program being viewable != the program being open source. If that were the case then a lot Microsoft's stuff would be "open" too - (atleast in my case).
  
  "Err... here is a revolutionary idea - email Sun your fix!... then send them the fix. I sure they aren't going to dismiss it out of hand - who know's it'll probably end up in the next JDK release?"
  
  Unless you're one of the dev's working on the Swing api - you can't guarantee that. I would rather not work on a fix (or maybe even a feature) and waste my time working on something that may or may not be overlooked.
  
  I don't feel that I am owed by Sun anything. I just have the realization that even though Sun has some of the best and brightest in the world working on Java and Swing - that:
  1) they are only human
  2) there are only so many of them
  3) they only have so much time
  
  therefore they can't give the world every little thing (fixes and features) that the world wants. Instead why not let the world put in what it needs and wants and off load some of the work? Does Sun even make licensing revenue from Swing?
• Where does Sun's responsibility end and our's start?
  2004-05-25 21:33:02 confusionary
  
  I'd love to see Sun develop some kind of reference application for Swing. Something that incorporates all of the best Swing development patterns and practices, kind of like the J2EE Pet Store app (only better). Not only would this give everyone an idea of how to write a good Swing app, it might help the Swing team figure out what's busted and what could be better.
  
  [Some ideas for the app: IM (Jabber) client, RSS feed reader, e-mail client, web browser (no, seriously), PIM app, or media (audio/photo/video) manager.]
  
  Also, I see on the 1.5 JSR that the 'Swing Skins Look and Feel' is a higher priority than printing support. Are you kidding me? The stupid WinAmp skin-everything-that-moves fad is several years over, and even if it weren't skinning would still be a terrible idea and a waste of time. Printing support has only been missing since the very beginning, I'm sure no one really wants it, especially in the corporate world.
  
  If that's an accurate reflection of Sun's priorities for Swing, I think the user community is going to have to step up and fix things themselves, because Sun either doesn't know what we want or doesn't care.
• Where does Sun's responsibility end and our's start?
  2004-05-25 10:35:33 charliehubbard
  
  Sun's client side offerring is closed to competitors. You cannot plugin Swing implementations or Java2D implemenations like you can Servlet Containers. Would software developers be open to paying for a client side offering from a other than Sun? If Sun wants the community's help then we should have a JSR for the client side like we do for the server side.
• Where does Sun's responsibility end and our's start?
  2004-05-26 03:50:13 zander
  
  | Sun's client side offerring is closed to competitors.
  
  Why do you say that? There are plenty of solutions that are either free to distribute (only per-developer fee's needed) or are completely free because they are open sourced.
  
  To put it simply; just ship another jar your GUI uses and you're done.
  
  I know lots of our users do it; I manage the http://uic.sf.net uicompiler project.
• Where does Sun's responsibility end and our's start?
  2004-05-26 07:58:57 charliehubbard
  
  

  Why do you say that?

  
  
  Read the rest of the post to find out why.
• Where does Sun's responsibility end and our's start?
  2004-05-26 12:09:14 zander
  
  Naturally I read the rest of your post; and I still asked the question.
  Your post said "You cannot [...]". I don't understand why you say that, a reason would be nice.
  
  Additionally I gave examples of people actually doing the thing you say we can't do.
  
  Opinions stated as fact need evidence; or they should be clearly posted as opinions.
• Where does Sun's responsibility end and our's start?
  2004-05-25 08:49:18 charliehubbard
  
  From someone who has done a lot of those modifications to Swing I have to say it ain't easy. If Sun is going to ask the community to make Swing better then Sun will have to make it easier to change Swing! The Basic plaf classes are the bulk of Swing's code. If you ever plan to modify a components behavior here is where it happens. But, these classes are extremely difficult to extend. It is usually a whole sale replace if you want to make the tiniest change.
  
  For example, when JTree initiates a drag you have to select the node first then click and drag it again for it to recognize the drag gesture. This is not the same behavior as in Windows, and my QA department has submitted bug after bug about this. If I extended BasicTreeUI I could possibly fix it, but the defaultDragRecognizer field is a private static final. Now you have to try an override installListeners which references inner classes that your extended BasicTreeUI can't reference. There is no easy way to change that behavior in JTree. The problem is most developers would have quit a long time ago. Why can't there be a setDragRecognizer() method on BasicTreeUI? Wouldn't that be easier?
  
  Another example, I wanted to create a calendar combobox for selecting dates. Similiar to date choosers in Windows. At first glance it seemed like I could subsitute the popup comopoent when the user clicked the down arrow to my calendar component. It seemed like changing BasicComboUI.popup field to use a ComboPopup class that popped up by calendar popup would do the trick. However, ComboPopup interface assumes a JList implementation. There is no way of doing with with a ComboBox. The solution was to use a JTextField and Button placed directly next to it to try to simulate the look of a combo box. That was no easy task either because we had to get the setup just write for it to look like the combo box button.
  
  I have found bugs in JTree and JTable that prevented me from working, and the only way to fix them is extending the Basic plaf classes and try to rewrite significant portions of code to fix two lines so there is a null check or something mundane like that. When we have to ship products to market within 6 months we can't wait for Sun, or even pay Sun, to release an updated version to the JVM. Sun's VM cycles are long taking more than 2 years to finish. This isn't helpful for people who just want bugs fixes.
  
  I also feel that if the community is the one to extend Swing into a usable platform for wider acceptance then they should have greater control over the core of the platform. The problem I see with community extended strategy is that newbies learning Swing will first learn it the wrong way then have to retrain to understand how the community has extended the platform. This is not a good of-the-box expierence and it will only lead to more developer disillusionment than acceptance of Swing.
  
  This already happens today to a large extent. When a newbie goes and buys a book from the bookstore. They'll be learning Swing without the community extendsions. LayoutManagers is a great example of this phenomena because the books discuss Sun's LayoutManagers and the newbie doesn't realize there are better LayoutManagers out there that are easier to work with. So he learns Sun's LayoutManagers first then either gets disillusioned with Swing or eventually graduates to better ones out there. I think there are more disillusioned developers than there are acceptance developers because its easier to give up than it is to learn something new.
  
  If Sun wants the community's help then they either have to let the community control Swing and or fix it themselves. The current state of affairs the control rests solely in Sun's hands. In order for the community to take ownership in this they need greater control over bug fixes and release dates. Swing needs to release more often. Right now the community can only do so much in the present state of affairs.
• Where does Sun's responsibility end and our's start?
  2004-05-26 03:57:25 zander
  
  I largely agree with you; the Swing problem can't be fixed from the outside.
  
  I have done a LOT in various projects, but there are plenty of bugs in the Swing codebase that prevent me from adding features. You named a few, so I won't name another set, that would get boring.
  
  What I don't agree with is that Sun has to ask for the communities help. If there are clear bugs in the implementation and Sun refuses to fix it, I start to work on the open-source implementation of the Java Spec. http://www.gnu.org/software/classpath/
  I'm pretty sure that these bugs will be fixed there in a shorter timeframe then Sun has shown itself capable of.
• Where does Sun's responsibility end and our's start?
  2004-05-25 08:09:51 jonathansimon
  
  

  My take is that Sun has to do what only sun can do - and they need to do it fast!

  For example, bugs in the core Swing and AWT objects have to be fixed by Sun. Even if the community got together and fixed those bugs, we wouldn'y be legally allowed to distribute them. Other popular topics like increasing performance, decreasing startup time, improving deployment, all fall under this category as well.

  On the other hand, things like creating better documentation or examples, we can do. We can also create a Swing wrapper if we really wanted to. We could also make other components like a really happening JTreeTable if we wanted.

  Dont get me wrong -- in my perfect world, Swing would come out of the box with all of the components I need that do everything I want, with the grooviest documentation imaginable.

  Its really a question of priorities -- and I think sun should start by doing the stuff that we cant.

• Where does Sun's responsibility end and our's start?
  2004-05-25 06:03:50 joshy
  
  I agree completely. That's one of the reasons for this forum. I want to href="http://wiki.java.net/bin/view/Main/BetterDesktopJava">collect these ideas and come up with a plan to implement some of them. I'd like to see the community develop a suite of useful addons that
  clean up the niggling little issues we all run across. Pretty much just drop essential-addons.jar into your classpath and you are done.
  
  - Joshua
• Where does Sun's responsibility end and our's start?
  2004-05-27 10:26:11 markswanson
  
  Ok, I posted a problem with GridBagLayout (the major factor in Swing's perceived slowness) and a potential high-level solution to your wiki. My first wiki post...
  
  http://wiki.java.net/bin/view/Main/WishList
  
  Comments welcome.
• Where does Sun's responsibility end and our's start?
  2004-05-24 17:38:59 mgrev
  
  I think you are trying to break an open door here. The course you a suggesting is already there and everyone think it's great. Swing is easy to extend etc.etc. This is fine for people sitting at home on their spare time codeing with no or little time constraints and where hours doesn't cost $200 a piece. It also works for R&D projects.
  
  The problem is that developing a new L&F is a hard sell for any IT-company on a tight budget (which goes for all except MS i guess).
  
  If you are buying a car that car is evaluated as is. Of course, you CAN tear averything out and mod it to a much better car, but then it it easier and cheaper to buy a better car to start with. The really passionate will rebuild their cars anyway, but the main market need good stuff out of the box. And the main market is where the numbers are.
  
  You and I can rebuild everything to fit our needs, or get a free (not GPL though) component that does. 80% of the developrs are result/hour driven though, and they are looking for results that looks and feels good in the least possible time with as low risk as possible.
  
  Buying a BMW you know you get a car with a certain functionality and X quality. Buying an Volvo and rebuilding it to a BMW is a high risk project and probably more expensive.
  
  That is why Sun has to do it, or outsource it, since they are the ones building and selling (for free though) the car.

• Native vs. Cross Platform L&Fs
  2004-05-21 11:29:49 jonathansimon
  
  

  Im particularly interested to see how people feel about this topic.

  As I've already said here, I always consider the fact that my users dont know my application is Java based to be a strong point. I think that a cross platform application should act appropriately in whatever environment it's running in, not necessarily identical across platforms. This may mean slight modifications in functionality between operating systems.

  This gets back to the question of whether native L&F's are more important than Java specific L&F's in general. It also is central to the point of heavyweight vs. lightweight components.

  So. I come from the native-L&F's-should-be-perfected-and-Java-L&F's-are-secondary camp. Where does everyone else stand?

  -jonathan</>

• Native vs. Cross Platform L&Fs
  2004-05-25 22:30:35 confusionary
  
  I think that given the choice, users will always choose an app that behaves the way they expect over one that has a lot of subtle differences. Unfortunately, I don't think a lightweight UI implementation can ever do that, at least not without the kind of effort and attention that Sun has not shown to Swing so far.
  
  I think the lightweight, pluggable L&F was a cool idea, but it's been six years and it's still not there yet. I think it's time to stop trying to emulate an entire UI and revisit the idea of letting the OS do most of the heavy lifting.
• Native vs. Cross Platform L&Fs
  2004-05-26 05:37:02 tommi_kuenneth
  
  IMHO we should distinguish more clearly between "lightweight" and "pluggable". Swings concept of a pluggable look and feel has always been a very good idea - and still is! I quite appreciate the possibility to specify how my program looks and feels, especially as there are cool L&Fs like Ken Arnolds NapkinLAF, for example.
  
  Certainly, these are "lightweight". Today, the Windows L&F is "lightweight", too. But this need not be the same for ever. There could be a pluggable L&F which does use the routines of the underlying host environment, and then it definitely is no longer lightweight.
  
  Again, I am glad to have a choice. And maybe someone can do another Windows L&F that does use Windows routines. To me, the the best solution. But then again, just some humble thoughts...
• Native vs. Cross Platform L&Fs
  2004-05-24 00:24:36 aaime
  
  There a situation where even the most perfect emulation is just... well, emulation.
  Think for example about the file chooser: there are applications (on windows) that plug into the native file chooser and extend it somehow, providing bookmarks or some other functionality.
  Think about the user that realize that the native file chooser is a fully functional explorer in which by right clicking you can do many things...
  In this case there is no emulation that can really fit... IMHO things like file chooser, print dialog, directory chooser and the like should be truly native, not emulated, since there is no way you can fully emulate the native version...
• Native vs. Cross Platform L&Fs
  2004-05-22 05:14:43 mgrev
  
  If you have a really good product, it can stand on its own feet from the beginning, making a new standard in a positive way. Say if Metal would have been anything like OS X.
  
  Now, that's not the case here, metal was OK when released and sub-par at present time. Ocean barely catches up to present, though much better than metal. As far as my tase goes anyway.
  
  Now if the native L&F isn't better or equal to the native (users perspective: Normal) standards, it has to earn it's place in some other way. Right now there is nothing that makes metal worth it for the user. It looks uglier (my view here) and there are no positive sides. Yes, there are plenty of advantages for the developer, but that doesn't translate to the user.
  
  Ocean will be in the exact same position in a couple of years.
  
  That is why using a native L&F is better in my oppinion. Simply because Metal/Ocean doesn't add anything in itself, and only hurts Java in general, since it is slower (but not TOO slow) and not as good looking as XP or OS X.
  
  So, make native L&F the default and tune those to the max. Then make som kick-ass widgets (outsource it please!! ;-) that makes ocean worth using and come back with a vengence in 1.5.1 o 1.6 presenting "Sea Breeze" - the new cool L&F with extra everything!
  
  I've never worked with an API that is so good as Swing are (six years now), but frankly; you need some advice when it comes to design. Please take that the right way.
  
  Cheers,
  Micke
• Native vs. Cross Platform L&Fs
  2004-05-21 18:10:51 tackline
  
  For mass-market Windows, if you want acceptance, I think you have to go for a high-fidelity look and feel. There's a certain degree of latitude. They tell me Word tends to be non-standard and changes between each release.
  
  If it's an application that people are going to be using continuously, without switching to others, I don't see that it matters at all.
  
  For myself, I always choose Metal if I possibly can. Even on Windows I prefer it. Certainly on Linux and Solaris, Motif, Gtk and Qt (themes) look distinctly amateurish in comparison (IANAGD).
• Re: Native vs. Cross Platform L&Fs
  2004-05-21 13:22:03 zander
  
  Using Windows XP for a couple of days and I found the whole has-to-be-native thing to be quite unimportant.
  Many people that want to try something and get to use my machine for an our or so even learn that I have my close-window button on the left (I happen to think that the Mac did that correct!).
  
  I have seen absolutely no proof that a (good) native look and feel makes the user accept the application faster. Only when other things were wrong I heard arguments that included L&F issues.
  
  It is my experience that if the L&F is good enough users won't mind.
  
  Let me illustrate that; I had feature requests about people using tab to go from textbox to textbox. They wanted the text to be selected on entry. [1]
  This is a good question and means that user was used to a native widget.
  The solution was to create that feature and make that part of the L&F so our Linux/Mac users would benefit as well. This solution was what everyone wanted. As you see this (and probably many others) problem has nothing to do with native L&F, but just about good standards.
  
  [1] can be found in UICompiler (http://uic.sf.net) uic.widgets.UICTextField
• Re: Native vs. Cross Platform L&Fs
  2004-05-22 16:05:42 markmc
  
  "They wanted the text to be selected on entry" - Isn't this a perfect example of users wanting native look and feel? It seems to me you had to spend time fixing a problem that wouldn't have come up if you'd used native components.
  
  As a user, I very much prefer native WinXP controls to Swing or Metal.
• Re: Native vs. Cross Platform L&Fs
  2004-05-23 12:25:09 zander
  
  | | "They wanted the text to be selected on entry"
  | Isn't this a perfect example of users wanting native look and feel?
  
  That is why I choose it. The answer to your question is: "No" Its a perfect example of the user wanting native feel, not always native look.
  If this feature would have to be implemented in a native L&F then it would have to be done in Windows, WindowsXP, Linux and Mac L&Fs. Naturally that is a lot more work then implementing it one time in a cross-platform L&F.
  As I said; the user was happy with the result.
  
  The native L&Fs are overrated, a good L&F with a native feel is needed.
  Fortunately the native feel is very cross-platform nowadays so you can do with one L&F.
• Native Feel, Decent Look
  2004-05-25 13:10:41 uncle_alice
  
  I agree completely. With skinning so prevalent, looking like a native app is just not that big a deal anymore. It's much more important that the look be polished and attractive. But common controls should work the way users expect them to, and it shouldn't be up to the developer or the UI designer to make that happen.

• Font handling
  2004-05-21 06:23:28 dbecker
  
  My biggest gripe with Swing is how it handles fonts. One point in Swing is not equivalent 1/72 of an inch on my laptop LCD screen. When I run Swing apps I either have to push the point size of the font up (which many apps won't allow me to do), or I have to put my face against the screen. To me this is the complete opposite of device independence. Why can't Swing just honor the DPI of its display device?
  
  Derek
• Re: Font handling
  2004-05-23 21:54:34 kws
  
  I agree, font handling is bad. My main gripe with fonts is anti-aliasing. Without it, so many swing apps look clunky and horribly unprofessional. It is easy to add via Java2D, but why wasn't it added automatically to all the font-rendering Swing components when 2D was added to J2SE?
  
  Someone mentioned defaults, like having a window close when you click the X, without having to write code for it. Sounds good - maybe purists don't like it, but Swing hasn't really taken off, now has it?
  
  What really matters is productivity, and VB runs circles around Swing for delivering a working thick client quickly. Swing ain't pretty, it ain't fast, and it ain't easy to program -- three strikes for most decision makers. Don't get me wrong, if you want to develop an application that does networking, iterfaces with a database or other enterprise system, middleware, web apps, any kind of good OO design -- Java is the way to go IMO. I'm just saying thick client development has a lot of room for improvement.
  
  With VB, there was always the win32 api and C++ to turn to when you ran into a wall. It followed the 80/20 rule well, and was and is a huge success.
  
  Perhaps a simplified, more VB-like drag and drop WYSIWYG toolset without layout managers and without Swing's MVC architecture would be a good addition. You could then use Swing or 2D to create the equivalent of custom ActiveX controls. Make the layouts external to the code, like in VB - a separate [standard] resource file would simplify the work that IDEs would have to do, and make the design time view the same as the run time view.
  
  This new GUI toolkit wouldn't have to be pretty, in fact a Java-native LaF would be ok, so long as it was:
  1) productive and
  2) consistent on multiple platforms.
  
  As for performance, I agree with another post that said a lot of what the user perceives as a fast, responsive application is really smoke and mirrors. Why not provide some mechanism for fast splash screens and build in proper thread dispatching into the components? When you update the model, the display updates, and the component takes care of the worker thread. Make a message-box like progress bar: something easy to call on when an action takes a while to complete, and that lets the user know the program didn't hang.
  
  Give it a different name: 'Simple Java GUI Toolkit '. Keep it distinct from from Swing, but let Swing and 2D be the way to build customized components. Provide well defined data model interfaces so that custom components would be as easy to use, and wouldn't expose their internal models or cell renderers, etc.
  
  Don't provide a super-flexible table with arbitrary content cells -- just make it handle text via a simple API. Make the column headers easier to set.
  
  I don't think Swing will or should be deprecated; but I don't think that Swing's shortcomings can be fixed without throwing away a lot of it. Therefore, keep it, and re-address the problem by making something new, easier to program, and built on top of it.
• Font handling
  2004-05-21 15:40:21 joshy
  
  Swing could definately have better font handling. In fact, the issue of resolution independent UIs isn't handled at all. The odd thing is, all of the hooks are there. The use of Layout Managers and custom L&Fs would allow for a completely scalable UI. As screen resolutions increase something that's truely scalable will become more important. I'd like to see Java provide that answer.
  
  Oh, and I'd also like to see an application wide setting to turn on anti-aliasing.
  
  - Josh
• Font handling
  2004-05-25 10:03:10 charliehubbard
  
  "the issue of resolution independent UIs isn't handled at all"
  
  FormLayout actually is the only LayoutManager that I know of that handles this. http://www.jgoodies.com.
  
  The other side to this is a vector based rendered UI like flash or M$ Avalon framework. Vector based UI are resolution independent. Swing should have a vector based UI to compete with M$ Avalon framework. I know there is an Open Source project working on it, but I don't know how active it is.
• Re: Font handling
  2004-05-21 13:13:21 zander
  
  You are right; the funny thing is that there are no L&Fs that scale your (for example) checkbox when you make your font bigger. Everything is hardcoded.
  
  Ok, there is one; and I created much of it, so this is sort of a plug for an open source project. But since its free, I hope you won't mind :)
  See http://uic.sf.net/demo/demo.jnlp and use the config dialog to alter your GUI properties.
• Re: Font handling
  2004-05-24 22:42:29 xhq
  
  Situations are more worse in a CJK localized system.
  
  The default font is just not readable for a CJK glyph. So people offen set the font like this in their applications:
  
  if (windows) ...
  else if (osx)...
  ...
  
  This is how "cross platform GUI" works. sigh
  
  I ever opened a bug for this. But sun just close it cruelly.
• Re: Font handling
  2004-05-26 04:05:52 zander
  
  What is a CJK glyph?
  
  Anyway; maybe you will find it usefull to know that a L&F I created makes the fonts configurable. The user can select them from a GUI, or you can ship a properties file in your project.
  I'm pretty sure that solves your problem.
  
  See the config dialog part of the demo: http://uic.sf.net/demo/demo.jnlp
• Re: Font handling
  2004-06-01 19:13:34 xhq
  
  By CJK glyph I mean a CJK character. Under today's display resolusions, A CJK character may look ugly if they are set to a size in which ASCII letters in proper font look pretty good.
  
  From your demo, the CJK character looking is acceptable. It seems they are AA.
  
  The demo is pretty good. Thank you. If only JFileChooser and others were designed like that!

• Ease of use for database frontend
  2004-05-20 01:45:53 aaime
  
  Why has been Visual Basic so successful? Because it is easy, yes, of course, but also because most people just create database front end apps, and it's easy and fast to get up a stupid CRUD application with VB.
  
  What we lack in Swing is this respect is:
  * data binding and related wizard, aka "I want to build an interface to a record eding or a master detail form in 5 minutes and have something working"
  * a table control that is as flexible as a flex grid. Why is so complicated to have row headers? Why I have to build yet another table model for result sets and the like?
  
  That last one is huge: the FlexGrid control may have a really studip interface, API wise, and it's not scalable at all, but you can create a table with the most common functions in minutes...
  
  Having programmed both in VB and Swing I have to say that what Swing lacks is polish and proportionality... it's too difficult to make simple thing, and most people don't care if you can do with Swing thing that you could not even image in VB. It's all about productivity, that API does not help you to be productive with simple things. In this respect SWT is better than Swing, because at least it make simple things simpler than with Swing.
  
  Swing provides all the building blocks for building something easier to use, but we need more powerful controls and more consistency, without removing the ability to dig deeper and play with the more flexible Swing API when needed.
  
  And yes, I also agree that this should be done the open source way, by setting up a project that builds on top of Swing... I'd leave to Sun the native look and feel problems (they should be solved, too) and have the community build a better API on top of Swing... and something is already moving, see for example the plastic look and feel or the l2fprod common components (http://common.l2fprod.com/)

• Broken layout, simple things are hard
  2004-05-19 20:58:20 peterbecker
  
  I've been using Swing for some visualization tools since 2001, coming from a background of using Qt. After the beauty of Qt I found using Swing a rather painful experience, and three years of using it haven't really taken out too much pain.
  
  One of the major complaints I have (if not the major one) is that the layouting is completely broken. Most of the layout managers work only in particular situations, and the only one I actually find useful (GridBag) is a pain to use. I must admit I haven't really tried SpringLayout, but it doesn't really occur to be easy either.
  
  And the main issue seems to be way deeper. I could of course write my own layout manager, but my impression is (correct me if I am wrong), that there is no proper implementation of minimum, preferred and maximum size in Swing. Esp. the minimum aspect bugs me -- it is rather impossible to create dialogs that disallow changing size below the sensible amount.
  
  Call me spoiled, but in Qt these things just work. Work in the sense that you don't notice until you miss them. And that applies for many other things, like having sensible default behaviour (e.g. windows should close on close, with a hook to override) and default initializations (what the heck is the story with the JTree() constructor?).
  
  And while the Swing event model is quite powerful (some of my code tends towards something resembling functional programming using anonymous inner classes), it is not expressive/explicit enough. Qt's signal-slot approach makes it way more explicit, a statement reading this:
  
  connect(button, clicked(), this, close());
  
  is just easier to understand than the nested structure used in Swing.
  
  Other parts of Swing just seem hacks generalized half-way. JTable for example seems to be made for displaying row sets from a DB. There are nice bits (the cell editors), but others are lacking (row headers, D&D of columns). I tried to use it for a spread-sheet like system, but then I decided against it.
  
  And what about z-order? Is there any decent way to handle that? Other than removing and readding? And why do things get put at the bottom instead the front? That doesn't seem intuitive or useful to me.
  
  And why do I have so many things to initialize layout? Why can't layouts just work? Why can't I just nest HBoxLayouts into VBoxLayouts and vice versa (without the explicit panels)? Pain, pain, pain :-(
  
  My life in Swing got easier in some parts after I wrote my own Canvas class with my own CanvasItems and event model, but while that might be sensible for someone doing visualizations, it was still far harder than expected (BTW: why doesn't Swing know about double-clicks? Or at least tell you what the system setting for the double click timing is?). Many of the features should be in Swing itself since I think many people might use that. Or a generic extension for such purposes, something nicer than JGraph. Something with the power of Java2D on one hand should have some power in the canvas controls, too.
  
  I better stop here, even though I probably miss complaints. The pure mention of Swing always puts me on a ramble, and I am really looking for something new. SWT doesn't really seem to be an option, due to the deployment issues. Some of the XUL stuff sounds interesting.
  
  For anyone of you who wonders why Swing doesn't get accepted: I'd say it is just not good enough. Nice features here and there, but in the end painful to use. Maybe I am too stupid , but I often stumbled and sometimes failed on things I consider trivial. If you think Swing is cool: try Qt, that'll raise your standards. While I love being away from C++ I sometimes feel regret about having moved to Java. And there are mostly two reasons for that: Swing and the container classes.
  
  Of course that is just my 2c.
  
  Peter
  
  
  PS: another good thing for Swing (and the rest of Java) would be getting rid of the old crap. Declaring things deprecated does help only that far. Someone should tell the marketing department that having thousands of classes is not a feature. But I guess someone should tell the customers, too :-(
• Broken layout, simple things are hard
  2004-05-26 08:33:15 charliehubbard
  
  

  And why do I have so many things to initialize layout? Why can't layouts just work? Why can't I just nest HBoxLayouts into VBoxLayouts and vice versa (without the explicit panels)? Pain, pain, pain :-(

  
  
  Is this something that QT allows? Can you give examples of this in QT? I think everyone is well aware that LayoutManagers are difficult to work with. We need you to help Sun and the community understand how they could work better. We need to know the "How." I'm very interested in hearing how QT API works with Layout.
  
  There are other implementations, like FormLayout from JGoodies, that are awesome. So while Sun's LayoutManagers are in general a serious pain, I see other implementations that work beautifully. Not to mention with FormLayout people are building GUI builders written in Swing.
  
  I did a little expirement to find out if there really is any difference between the LayoutManagers. To illustrate how easy FormLayout vs. GridBag and Spring Layout. Say you want to layout 5 textfields in a column with 5 labels on the left hand side. All the textfields left edges should line up and all of their right edges should line up. The labels should also line up next to each field and align themselves vertically to the left or right. The only layouts you can accomplish this with is GridBag and SpringLayout in Sun's layout managers.
  
  I coded this layout with each LayoutManager here is the results:
  
  GridBagLayout: 78 lines
  SpringLayout: 95 lines
  FormLayout: 19 lines
  
  One note was that I couldn't get SpringLayout to be 100% accurate to the other layouts without using the code provided in Sun's tutorial. I tried hand coding it, and it just wouldn't do what I wanted to do. So there is a utility you can copy from their tutorial to make SpringLayout easier. My big question is why didn't they include this with the JDK??? But, even with the helper code it still took 95 lines with SpringLayout.
• Broken layout, simple things are hard
  2004-05-26 18:19:27 peterbecker
  
  I actually found a chapter of a Qt book online, which describes some of the aspects of layouting. It might give you a good idea of how it works -- feel free to ask for more if not :
  
  book chapter on Qt's layout (PDF, 264kb)
  
  Also check out Qt's Designer (visual GUI tool) -- I normally hate these things, but this one is pretty good (a similar one would be Glade for GTK).
  
  I'm sure someone has an extra comment on that last one :-)
• Layout code size/complexity
  2004-05-26 16:27:49 tackline
  
  If you take 78 lines to do that with GridBagLayout, I suspect you are taking a distinctly suboptimal. Show us ya code! Apart from which, it's a very simplistic example. If you did this regularly you'd write a method to, say, add and perhaps create a label and field - just 1 (one) line a pair.
  
  I'm not keen on JGoodies FormLayout. It uses cryptic strings, rather than the Java language. I would attempt to avoid that elsewhere in any application. I don't see why GUI layout, an absolutely trivial part, should be special.
• Layout code size/complexity
  2004-06-02 05:49:12 charliehubbard
  
  I know I can write helper methods, but that's not correct comparison. I wanted to compare what you got out of the box with each layout.
  
  
import com.jgoodies.forms.layout.FormLayout;
import com.jgoodies.forms.builder.DefaultFormBuilder;

import javax.swing.*;
import java.awt.*;

public class CodeSizeComparison {

public JPanel createFormLayout() {
JTextField name = new JTextField(20);
JTextField phone = new JTextField(20);
JTextField fax = new JTextField(20);
JTextField email = new JTextField(20);
JTextField address = new JTextField(20);

FormLayout layout = new FormLayout("left:pref,4dlu,pref:grow", "");
DefaultFormBuilder builder = new DefaultFormBuilder( layout );

builder.setDefaultDialogBorder();

builder.append( "Name:", name );
builder.append( "Phone:", phone );
builder.append( "Fax:", fax );
builder.append( "Email:", email );
builder.append( "Address:", address );

return builder.getPanel();
}

public JPanel createGridbagLayout() {
JTextField name = new JTextField(20);
JTextField phone = new JTextField(20);
JTextField fax = new JTextField(20);
JTextField email = new JTextField(20);
JTextField address = new JTextField(20);

JLabel nameLabel = new JLabel("Name:");
JLabel phoneLabel = new JLabel("Phone:");
JLabel faxLabel = new JLabel("Fax:");
JLabel emailLabel = new JLabel("Email:");
JLabel addressLabel = new JLabel("Address:");

GridBagConstraints cc = new GridBagConstraints( 0, 0, 1, 1, 0.0, 0.0, GridBagConstraints.EAST, GridBagConstraints.BOTH, null, 0, 0);
Insets labelinsets = new Insets(5, 0, 0, 0 );
Insets fieldinsets = new Insets(5, 4, 0, 0 );

JPanel panel = new JPanel( new GridBagLayout() );

cc.insets = new Insets( 0, 0, 0, 0 );
panel.add( nameLabel, cc );

cc.weightx = 1.0;
cc.gridx = 1;
cc.insets = new Insets( 0, 4, 0, 0 );
panel.add( name, cc );

cc.gridx = 0;
cc.gridy = 1;
cc.weightx = 0.0;
cc.insets = labelinsets;
panel.add( phoneLabel, cc );

cc.gridx = 1;
cc.gridy = 1;
cc.weightx = 1.0;
cc.insets = fieldinsets;
panel.add( phone, cc );

cc.gridx = 0;
cc.gridy = 2;
cc.weightx = 0.0;
cc.insets = labelinsets;
panel.add( faxLabel, cc );

cc.gridx = 1;
cc.gridy = 2;
cc.weightx = 1.0;
cc.insets = fieldinsets;
panel.add( fax, cc );

cc.gridx = 0;
cc.gridy = 3;
cc.weightx = 0.0;
cc.insets = labelinsets;
panel.add( emailLabel, cc );

cc.gridx = 1;
cc.gridy = 3;
cc.weightx = 1.0;
cc.insets = fieldinsets;
panel.add( email, cc );

cc.gridx = 0;
cc.gridy = 4;
cc.weightx = 0.0;
cc.insets = labelinsets;
panel.add( addressLabel, cc );

cc.gridx = 1;
cc.gridy = 4;
cc.weightx = 1.0;
cc.insets = fieldinsets;
panel.add( address, cc );

panel.setBorder( BorderFactory.createEmptyBorder( 10, 10, 10, 10 ) );

return panel;
}

public JPanel createSpringLayout() {
JTextField name = new JTextField(20);
JTextField phone = new JTextField(20);
JTextField fax = new JTextField(20);
JTextField email = new JTextField(20);
JTextField address = new JTextField(20);

JLabel nameLabel = new JLabel("Name:");
JLabel phoneLabel = new JLabel("Phone:");
JLabel faxLabel = new JLabel("Fax:");
JLabel emailLabel = new JLabel("Email:");
JLabel addressLabel = new JLabel("Address:");

SpringLayout layout = new SpringLayout();
JPanel panel = new JPanel( layout );

panel.setBorder( BorderFactory.createEmptyBorder( 10, 10, 10, 10 ) );

panel.add( nameLabel );
panel.add( name );
panel.add( phoneLabel );
panel.add( phone );
panel.add( faxLabel );
panel.add( fax );
panel.add( emailLabel );
panel.add( email );
panel.add( addressLabel );
panel.add( address );

makeCompactGrid( panel, 5, 2, 0, 5, 5, 5);

return panel;
}

private SpringLayout.Constraints getConstraintsForCell(
int row, int col,
Container parent,
int cols) {
SpringLayout layout = (SpringLayout) parent.getLayout();
Component c = parent.getComponent(row * cols + col);
return layout.getConstraints(c);
}

public void makeCompactGrid(Container parent,
int rows, int cols,
int initialX, int initialY,
int xPad, int yPad) {
SpringLayout layout;
try {
layout = (SpringLayout)parent.getLayout();
} catch (ClassCastException exc) {
System.err.println("The first argument to makeCompactGrid must use SpringLayout.");
return;
}

//Align all cells in each column and make them the same width.
Spring x = Spring.constant(initialX);
for (int c = 0; c < cols; c++) {
Spring width = Spring.constant(0);
for (int r = 0; r < rows; r++) {
width = Spring.max(width,
getConstraintsForCell(r, c, parent, cols).
getWidth());
}
for (int r = 0; r < rows; r++) {
SpringLayout.Constraints constraints =
getConstraintsForCell(r, c, parent, cols);
constraints.setX(x);
constraints.setWidth(width);
}
x = Spring.sum(x, Spring.sum(width, Spring.constant(xPad)));
}

//Align all cells in each row and make them the same height.
Spring y = Spring.constant(initialY);
for (int r = 0; r < rows; r++) {
Spring height = Spring.constant(0);
for (int c = 0; c < cols; c++) {
height = Spring.max(height,
getConstraintsForCell(r, c, parent, cols).
getHeight());
}
for (int c = 0; c < cols; c++) {
SpringLayout.Constraints constraints =
getConstraintsForCell(r, c, parent, cols);
constraints.setY(y);
constraints.setHeight(height);
}
y = Spring.sum(y, Spring.sum(height, Spring.constant(yPad)));
}

//Set the parent's size.
SpringLayout.Constraints pCons = layout.getConstraints(parent);
pCons.setConstraint(SpringLayout.SOUTH, y);
pCons.setConstraint(SpringLayout.EAST, x);
}

public static void main(String[] args) throws Exception {
UIManager.setLookAndFeel( UIManager.getSystemLookAndFeelClassName() );
CodeSizeComparison comp = new CodeSizeComparison();

JFrame frame = new JFrame("Form Layout");
frame.setContentPane( comp.createFormLayout() );
frame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
frame.pack();
frame.setVisible( true );

JFrame gridFrame = new JFrame("Gridbag Layout");
gridFrame.setContentPane( comp.createGridbagLayout() );
gridFrame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
gridFrame.pack();
gridFrame.setVisible( true );

JFrame springFrame = new JFrame("Spring Layout");
springFrame.setContentPane( comp.createSpringLayout() );
springFrame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
springFrame.pack();
springFrame.setVisible( true );
}
}

• Layout code size/complexity
  2004-06-04 12:48:27 tackline
  
  Obviously this comparison is weighted to show the conciseness of FormLayout. In real life you'd have say an OK button that spoils the pattern and almost certainly fields that don't precisely fit the label-field scheme.
  
  You seem to be counting blank lines, which doesn't really strike me as useful. In addition to recounting your code, I've made two derived versions. They concentrated on code quality rather than line count tricks such as adding all the labels first followed by all the fields. One thing grid bags doesn't attempt to handle is PL&F dependent spacing, which is a pity IMO.
  
  Form layout: 16 lines (includes one line in domain specific language)
  Your grid bag: 64 lines
  Single method grid bag: 40 lines
  Naive grid bag: 16 lines + 15 helper = 31 lines
  
  Single method grid bag: It seems to me unfair to have the labels as local variables when using grid bag, but not using the FormLayout. The documentation for the mammoth GridBagConstraints constructor points out that rather obviously it isn't designed for human readable code. I assume the use of EAST was deliberate. Clearly there are two distinct sets of constraint data for this layout, so it's perverse to rewrite many fields instead of using two instances. Switching insets to alter the border width is also perverse. Using my generic extension of GridBagConstraints would pull the code size down to 30 lines.
  
  Naive grid bag: I'd expect even the most Junior of VB programmers to realise copying and pasting code was not a good thing. So for what I consider to be a naive implementation, I've put in a method to add a line to the form. The method is of course applicable wherever you have this sort of layout. The great thing about this method is that now you have an opportunity to do more interesting things to bring it up to a minimum standard. For instance, labels should be looked up from a resource file (or similar). Also there's giving the labels mnemonics (from resources) and setting their label-for property to associate the text field. Perhaps tooltips. Possibly other things specific to the application.
  
  public JPanel createOneMethod() {
  JTextField name = new JTextField(20);
  JTextField phone = new JTextField(20);
  JTextField fax = new JTextField(20);
  JTextField email = new JTextField(20);
  JTextField address = new JTextField(20);
  
  JPanel panel = new JPanel(new GridBagLayout());
  panel.setBorder(BorderFactory.createEmptyBorder(8, 8, 8, 8));
  
  GridBagConstraints labelCons = new GridBagConstraints();
  labelCons.gridx = 0;
  labelCons.gridy = 0;
  labelCons.anchor = GridBagConstraints.EAST;
  labelCons.insets = new Insets(3, 2, 2, 2);
  
  GridBagConstraints dataCons = new GridBagConstraints();
  dataCons.gridx = 1;
  dataCons.gridy = 0;
  dataCons.weighty = 1.0;
  dataCons.fill = GridBagConstraints.HORIZONTAL;
  dataCons.insets = new Insets(3, 2, 2, 2);
  
  panel.add(new JLabel("Name:"), labelCons);
  ++labelCons.gridy;
  panel.add(name, dataCons);
  ++dataCons.gridy;
  panel.add(new JLabel("Phone:"), labelCons);
  ++labelCons.gridy;
  panel.add(phone, dataCons);
  ++dataCons.gridy;
  panel.add(new JLabel("Fax:"), labelCons);
  ++labelCons.gridy;
  panel.add(fax, dataCons);
  ++dataCons.gridy;
  panel.add(new JLabel("Email:"), labelCons);
  ++labelCons.gridy;
  panel.add(email, dataCons);
  ++dataCons.gridy;
  panel.add(new JLabel("Address:"), labelCons);
  ++labelCons.gridy;
  panel.add(address, dataCons);
  
  return panel;
  }
  
  public JPanel createNaive() {
  JTextField name = new JTextField(20);
  JTextField phone = new JTextField(20);
  JTextField fax = new JTextField(20);
  JTextField email = new JTextField(20);
  JTextField address = new JTextField(20);
  
  JPanel panel = new JPanel(new GridBagLayout());
  panel.setBorder(BorderFactory.createEmptyBorder(8, 8, 8, 8));
  
  int gridy = 0;
  gridy = addLine(panel, gridy, "Name", name);
  gridy = addLine(panel, gridy, "Phone", phone);
  gridy = addLine(panel, gridy, "Fax", fax);
  gridy = addLine(panel, gridy, "Email", email);
  gridy = addLine(panel, gridy, "Address", address);
  
  return panel;
  }
  private int addLine(
  JPanel panel, int gridy, String label, JComponent component
  ) {
  GridBagConstraints cons = new GridBagConstraints();
  cons.insets = new Insets(3, 2, 2, 2);
  cons.gridy = gridy;
  cons.anchor = GridBagConstraints.EAST;
  
  cons.gridx = 0;
  panel.add(new JLabel(label+':'), cons);
  
  cons.gridx = 1;
  cons.weighty = 1.0;
  cons.fill = GridBagConstraints.HORIZONTAL;
  panel.add(component, cons);
  return gridy+1;
  }
  
  Apologies for the long code...
• Layout code size/complexity
  2004-06-02 05:45:14 charliehubbard
  
  Layout is not trival! If it were trival we wouldn't have this topic discussing it. It would've been a non-issue.
  
  FormLayout uses strings because it's very compact way of representing the layout. GridBagLayout uses the Java Language, and it forces the user to enter too many parameters. Using the Java language for layout causes it to become extremely terse. Programming languages are suitable for describing behavior, not visual layout.
  
  GridBagConstraints c = new GridBagConstraints( 4, 5, 2, 3, 1.0, 0.0, SwingConstants.WEST, SwingConstants.HORIZONTAL, new Insets( 5,5,5,5), 4, 3 );
  
  Which parameter is the internal padding for x? Which parameter is controlling the how many rows a component is spanning? Is this any less cryptic? Now do this for every component you need to create and layout.
• Layout code size/complexity
  2004-06-04 13:00:01 tackline
  
  As I noted above, the documentation states that that GridBagConstraints constructor is not supposed to be used other than by machine generated code.
  
  The internal padding fields are rarely used. I don't remember having done so.
  
  Setting the fields explicitly (possibly "reusing" code) it all becomes very obvious. You can even use standard techniques such setters that return.
  
  You certainly shouldn't be creating a new constraints object for each component (it gets cloned).
  
  Using GridBagLayout is really quite trivial. You can of course write bad code to do anything. In this instance repeating and failing to separate code is common. The fault there clearly lies with the programmer (and wherever they picked their bad habits up from).
• Broken layout, simple things are hard
  2004-05-26 12:15:55 zander
  
  | To illustrate how easy FormLayout vs. GridBag and Spring Layout. Say you want to layout 5 textfields in a
  | column with 5 labels on the left hand side. All the textfields left edges should line up and all of their
  | right edges should line up. The labels should also line up next to each field and align themselves vertically to
  | the left or right.
  
  In NaturalLayout this takes 11 lines. (10 widgets, 1 new for the layouter).
  
  Its clear you like FormLayout; you mentioned it in several places in this thread already. I just want to inform you that there are several others as well; everyone has its place, and all are better for certain uses.
• Broken layout, simple things are hard
  2004-06-02 18:09:10 charliehubbard
  
  And thank you, Zander for plugging your project again! The difference in my recommendation is I do not write, benefit, or have any affliation with FormLayout. I'm well aware that there are other LayoutManagers out there. I have not found one as comprehesive as FormLayout. I think the Java community should be aware of it since this was a discussion on how to improve Swing. I think this thread is about finding good examples and making the community aware it. This thread is certainly not about plugging your own projects.
  
  I think you should post your code for NaturalLayout since I'm not familiar with it. But, with one constraint. Construction must be kept seperate from layout. Construct all your objects before you use them in layout. That's how I structured my code because it shows how many lines it takes just for layout. We'd all be interested in seeing your project at work.
• Broken layout, simple things are hard
  2004-06-03 05:29:42 zander
  
  > And thank you, Zander for plugging your project again!
  
  Ehhm.. I read my post twice, but the project name is nowhere to be seen.. Just the name of a layout manger, which is one class of hundreds in the project you call mine. Its not even like I am the sole committer on the project I will delightfully not mention here :)
  
  Don't go over the top here, please.
  
  And since you asked:
  
  JTextField sOne = new JTextField(20);
  JLabel lOne = new JLabel("one");
  JPanel panel = new JPanel(new NaturalLayout(2,5));
  panel.add(lOne);
  panel.add(sOne);
  
  I guess you can multiply this if you want.
  
  ps. I would myself have written things like:
  panel.add( sOne = new JTextField(20);
  taking the 11 lines I described above.
  
  ps2. If I would have made a plug; it would have been that the excellent Gui Builder makes sure you never have to write such code anymore :)
• Broken layout, simple things are hard
  2004-05-26 08:16:32 charliehubbard
  
  

  Other parts of Swing just seem hacks generalized half-way. JTable for example seems to be made for displaying row sets from a DB. There are nice bits (the cell editors), but others are lacking (row headers, D&D of columns). I tried to use it for a spread-sheet like system, but then I decided against it.

  
  
  What do you mean by D&D of columns? In Swing I can click on a column header and drag it around to re-order my table by default.
• Broken layout, simple things are hard
  2004-05-26 18:20:40 peterbecker
  
  That's what I meant. I thought that was one of the issues we had and which caused us not to use it, but I guess I was wrong. Mea culpa.
• Broken layout, simple things are hard
  2004-05-26 12:16:36 zander
  
  I guess he failed to put the JTable in a scrollpane.
• Broken layout, simple things are hard
  2004-05-26 18:22:26 peterbecker
  
  That wasn't the point I was talking about, but that is actually another good one: why do I have to put things into scrollpanes myself? That's annoying, since I can't really see how they are supposed to be useful without. Having an option to turn of some scrollbars (e.g. the horizontal one for JList) makes sense, but displaying only half your content instead of scrolling seems a Bad Idea (tm), independent of what you are doing.
• Broken layout, simple things are hard
  2004-05-25 09:06:52 charliehubbard
  
  Z-Ordering is what CardLayout is for. Changing Z-Order is really easy when you use CardLayout.
• Broken layout, simple things are hard
  2004-05-25 20:35:25 peterbecker
  
  Admittably CardLayout does solve the problem in some way, but again in a way that I personally couldn't agree with for my particular application, which is visualization with lots of objects. CardLayout would need an explicit layer for each object, which seems a bit overkill to me.
  
  Of course Swing can't serve any purpose, and maybe my particular interests are quite specific. I have fixed the problem by writing my own little Canvas and CanvasItem class for having a bunch of shapes on a plane (think CorelDraw or SVG and you get the idea -- I do different things in the end, but same requirements). But somehow it felt like reinventing the wheel.
  
  If Swing would deliver some things well, that would be ok. But what actually is easy to do in Swing? Layout: no. 2D visualization: no. DB controls: no. It is all possible, but nothing is easy. Most of it should be.
• Broken layout, simple things are hard
  2004-05-26 08:08:44 charliehubbard
  
  

  
  And what about z-order? Is there any decent way to handle that? Other than removing and readding? And why do things get put at the bottom instead the front? That doesn't seem intuitive or useful to me.
  

  
  
  This sounds like you are asking about using JPanel's or some JComponent and have them on top of each other. But, in your next post you say that your doing 2D visualization which makes me think square, triangle, circle, SVG, but certainly not
  JComponents. That means CardLayout would certainly not work. In that case this sounds like it is something completely different than your original post. It also sounds like it's highly specific to what your doing. I doubt anything in Swing will statisfy your needs.
  
  JLayeredPane provides Z-Ordering, but it's absolute layout which means no layout managers. It's a lot of work to use, but it gives you total control over your object placement. It contains other JComponents so like I said it probably doesn't meet your needs anyway, but I thought I might post for education.
• JLayeredPane and LayoutManagers
  2004-05-26 16:26:06 tackline
  
  The docs to JLayeredPane says:
  
  "Note: that these layers are simply a logical construct and LayoutManagers will affect all child components of this container without regard for layer settings."
  
  Layout managers work just fine with JLayeredPane. The thing is as a convenience, adding a JComponent to JLayeredPane sets the component's layer client property (other Components have the layer property stored in a dictionary within JLayeredPane, but make sure they are lightweight). All we have to do in the general case is to instead set the layer property (again through a convenience method) before adding the component to the pane.
  
  Here's some code I prepared earlier. This is from a subclass of GridBagConstraints.
  
  public Constraints addToLayer(
  javax.swing.JLayeredPane container,
  int layer,
  javax.swing.JComponent component
  ) {
  javax.swing.JLayeredPane.putLayer(component, layer);
  container.add(component, this);
  return this;
  }
  
  For drawing programs I would suggest an API for handling widgets is a suboptimal approach. See the javax.swing.text package's discussion on use of View/Element instead of JComponent.
• 2D Canvas
  2004-05-26 18:29:05 peterbecker
  
  

  For drawing programs I would suggest an API for handling widgets is a suboptimal approach. See the javax.swing.text package's discussion on use of View/Element instead of JComponent.

  
  
  You are right. I should have complained about the lack of a powerful 2D canvas, not the ordering of components.
  
  I know some of you must be sick of me mentioning Qt all the time, but still:
  
  Qt's docu for the canvas module
  
  Also note the quality of the documentation. Many methods do describe not just what they do, but also how to use them.
• Defaults
  2004-05-22 17:17:10 tackline
  
  A problem with defaults is there isn't necessary any sensible default. For frame closing, do you really want it just to close? Shouldn't it dispose also? Often there's going to be some other kind of action, so mixing that with the default is going to be a bit confusing. Most often, I guess, the application should quit (although a disused AWT thread no longer keeps the JVM alive).
  
  Perhaps I'm just not a fan of defaults in general. They hide what is intended and smell of programming by coincidence.
• Defaults
  2004-05-23 18:11:27 peterbecker
  
  In a certain sense there is always a default behaviour. At the moment the default behaviour is to provide a button that does nothing. What a useful little piece of design :-)
  
  If Swing would not provide that button and I'd have to enable it with something like this:
  
  window.addCloseOperation(new CloseOperation() {
  public void close() {
  ....
  }
  }
  
  then it would make more sense. But providing the button and no functionality is only confusing people.
  
  Swing should have a notion of an application window, whose close operation gets mapped to the close button of its frame and to wherever it should be else (e.g. File->Exit on Windows, other places on other OS).
  
  Re disposal: wouldn't it be possible to hide that from the programmer as much as memory management is hidden? That's not a rhetorical question -- I do not know the answer, but I wish it would be.
• Automatic disposal
  2004-05-23 20:01:38 tackline
  
  I think there's a problem in that some window managers keep additional state for frame windows. It'd be a bit confusing if state got carried over between random windows, or sometimes a window would lose state if hiden.
• Broken layout and connecting events to actions
  2004-05-20 17:54:13 tackline
  
  Layout: Certainly GridBagLayout is the one that does more or less everything. It's a matter of taste whether you use it in place of simpler managers for consistency. SpringLayout is hopeless. Minimum sizes are generally not useful. Put everything is a scroll pane which only comes in to play when necessary. The inability to intercept window bounds changes is a bit poor.
  
  You might want to look at java.beans.EventHandler (from 1.4). The equivalent of
  
  connect(button, clicked(), this, close());
  
  is something like
  
  button.addActionListener(EventHandler.create(
  ActionListener.class, window, "hide"
  ));
  
  A bit more verbose and weakly^Wdynamically typed, but it avoids the inner class notation. Not sure why there isn't a version that add directly the the event source, removing the duplication of listener type. If only Java was enhanced to allow something like:
  
  button.addActionListener(new {{ window.hide(); }});
• Broken layout and connecting events to actions
  2004-05-20 18:37:46 peterbecker
  
  Re layout: it is not that I didn't try using the simpler ones, but it failed for me. BorderLayout works for some particular designs, but is extremely limited to those. FlowLayout is rarely what I want -- I do not think that users think of buttons as a linear composition that can linebreak. Moving a button from the far right to the left on the next line creates a new layout which the user will not quickly recognize. And BoxLayout is something I never got to work at all. Seems extremely broken to me. GridLayout had problems, too -- although I must admit I forgot them. Anything left to try?
  
  And I do believe in minimum sizes for certain parts of my program. Of course there is an assumption that the minimum size will fit on the user's screen, but in many cases that seems ok. And after all: Swing's default components do not have that approach either: ever tried to put a large string into a JOptionPane? Would you really want a message box to have a scrollbar? Would you really want a file dialog with scrollbars? I think scrollbars are good for documents, tables and similar pieces of large content, but if your dialogs need scrollbars your design is broken. Break the dialogs down instead of creating virtual screen real estate.
  
  Re action listeners: admittably I didn't know the EventHandler approach, but I won't use it either. You mentioned the problems: it is still very verbose (close to the anonymous inner class) and it is not statically typed anymore. I don't mind anonymous inner classes as such (although there are better ways to get the same feature -- see functional programming languages), and if I wouldn't like static typing I wouldn't use Java.
  
  The important thing for me in coding (even in the general sense) is to make things explicit. That's the beauty of static typing for me: you tell people what you want and what you return in terms of (hopefully) types they can relate to (I deliberately avoid using "semantics" here). One of the main criticism I have about Java the language itself is that it doesn't do a good job in typing. As a C++ programmer I learned that casting is generally bad. Sometimes you have to since someone else screwed up, but if you forced yourself into casting, you should fix it. Java forces you into casting all the time, not only through the lack of genericity, although through the "basic types are not objects" approach (you can call it Autoboxing, I call it casting).
  
  But I am drifting off. The point is that the Qt connect statement is something extremely hard to misunderstand, even if you do not know any Qt at all. You could confuse sender and target, but the order is standard and signals are usually quite different beasts to the slots (the Qt lingua for the methods called). Compare that to the Swing approach, where you first have to understand the notion of a Listener (most Design Patterns are IMO excuses for not having done things right in the first place), and you have to know about anonymous inner classes and how to use them. The EventHandler approach is even worse: to understand that you have to understand the AIC way as well as reflection.
  
  The syntax you propose is better, but still flawed: to use it you get still exposed to implementation details of the event model. Maybe it is my Qt training, but I like to think of GUI development in terms of Event-Action schemes: something happens somewhere, so something else has to react. I don't care how that works and I don't want to. I suppose Qt has some Observer pattern on QWidget, or maybe they use some event broker to implement publish/subscribe. Why should I care? It works in a way I can easily use it.
  
  And that is the whole difference between a nice tool (as Qt) and a painful one (Swing): one works in a way that I can easily use it, the other exposes me to things I'd rather not care about. And you have to care about many such things in Swing. I never measured it, but I am quite sure when I am creating dialogs etc. I spend far more time on fighting Swing than on the actual problem itself. That's why I so strongly dislike it: it keeps getting in my way.
  
  Peter
• Minimum sizes and event listening
  2004-05-21 18:12:17 tackline
  
  I'd prefer not to have any message boxes, let alone one with an enormous string in it. Switching to minimum sizes often makes a panel look daft. I'd prefer a scroll bar to that. Often you want the pack size of a window to be bigger than the minimum preferred. For instance, a list box can be smaller than you'd ideally like if that avoids scroll bars on the window. You can arrange to only use the minimum size of some components or add a fudge factor.
  
  IMO, the new AWT event model (I started with 1.0.2, bleurgh) is preferable to the pointer-to-method idioms of some other systems. There's an extra layer of indirection between source and target. You can write code in there to translate from event to actions. The only real problem is the verbose syntax. I said I'm adding an ActionListener, why do I need to state that the anonymous inner class is an ActionListener? ActionListener only has one method, if I only implement one method, can you guess which it is?
• Minimum sizes and event listening
  2004-05-23 18:23:46 peterbecker
  
  Of course message boxes are something that should be avoided in many cases (although not all), and they should not contain long text. That was the point: if you go with the design proposed and add scrollbars, you just give an easy way out for a problem that should get a real solution.
  
  And yes: minimum size is not prefered size. To take the list box example: I'd probably think of minimum height in the range of 2 lines and prefered with something like 5-6 lines. The default layout (Swing's pack(), Qt's default behaviour without fuss) should be prefered size if enough space is available. Minimum size should be used to find a minimal sensible size when resizing. Swing's windows can be resized to pretty much nothing, which is not helpful. If you want to hide contents, add a rollup-button. I sometimes minimize (modeless) dialogs but want to keep everything visible. Swing makes that hard.
  
  Re events: I want that extra layer of redirection -- I call it decoupling. Admittably it makes debugging a bit harder (mostly since no tools support debugging the different event models), but it creates better design IMO. I can get close in Swing if my listening component provides something like getActionListener(), which I then can connect to all components that allow attaching ActionListeners, but not to other things.
  
  And I do also think that there is no need to expose the observer pattern on the source side in the way Swing does. What I want to say is something like this: "if X happens on A get B to do Y". That maps directly into Qt's signal/slot approach, but in Swing I have to do: "tell A to notify something that X happened, then make that thing call B's Y". Useless conceptual overhead. And it turns A into something active in that scenario, which is might be implementation-wise, but I don't think it should be on the conceptual level.
• Re: Broken layout and connecting events to actions
  2004-05-21 12:59:19 zander
  
  I started GUI development on Qt as you seem to have, and I'm not a full-time Java Swing programmer. I can follow each of your problems; I had them too.
  
  The slot-signal approuch seems quite nice, but is not really possible in Java without reflection. I have created the best compromise I could think of in the open source package UICompiler. The actions package there will probably satisfy your needs :)
  
  What you should understand is that Swing is multithreaded from the start, which makes it a lot harder to do all this correctly; Qt, in contrast, has no knowledge of multithreading at all. This distinction might be why it took so long before a good framework on actions arrived at the scenes..
  
  On the layouters thing; I fully agree and I never use the awt or swing layout managers (except for cardlayout) they are all useless for good layout. I personally use the UICompilers NaturalLayout which is based on ideas from Qt.
• Re: Broken layout and connecting events to actions
  2004-05-22 05:20:51 luano
  
  When did Swing become multithreaded?
  
  According to Sun documentation (http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html) Swing is single threaded.
• Re: Broken layout and connecting events to actions
  2004-05-23 12:30:20 zander
  
  When? The day that multiple threads could use and change your widgets and events.
  
  You seem to misunderstand the implemenation of swing with the usage of swing. (we are talking about the latter).
  
  Usage of swing is multithreading; as the referenced doc supports, if only becuase of its existance.
  Usage of Qt is single-threaded; in Qt button-handling code will ALWAYS block the gui from redrawing. This makes things a lot easier to grasp; but not really nice too look at :)
  
  Naturally C++ can do multithreading; but Java just makes it practicle to the extend that most people actually do it.
• Broken layout and connecting events to actions
  2004-05-21 05:49:20 asjf
  
  hi,
  
  picking up on one specific point - the layout managers. I don't think anyone would disagree that Swings in built ones are not very useful, but was wondering how Qt's horizontal and vertical layouts differ from flowlayout?
  
  also there doesn't seem to be the same distinction between a panel and its layout in Qt - you just have the layout?
  
  since the min, pref and max sizes of a component are used only at the discretion of a layoutmanager it surely wouldn't be a big task to clone the horizontal and vertical layoutmanagers that Qt uses?
  
  although i am interested to hear how they form a useful basis (am not doubting they do, but cannot immediately see it?)
  
  thanks,
  asjf
• Broken layout and connecting events to actions
  2004-05-21 13:06:47 zander
  
  1) FlowLayout ignores min/max sizes. The Qt versions do not.
  
  2) There are GridLayout and Grid widget. The latter is a panel with the layouter already applied. You can simply create a panel and set the Layout later, but the QGrid class does that for you.
  A strategy that in Qt4 will be removed.
  
  3) No it wouldn't. Use the NaturalLayout from UICompiler, it does that to a large extend out of the box already.
  
  The Horizontal and Vertical layout managers are quiet usefull; the point here is that you rarely see the grouping of a complex dialog on layouter level. In many cases a dialog will use between 3 and 6 layout managers. Many of those will be simple horizontal or vertical ones. Doing it like that has various advantages, understanding what the dialog does before you code it being the largest.
  
  A flowlayout can't be used in this fashion since it puts things on the next line if they don't fit. A strategy I NEVER actually saw as a benefit.
  
  Hope that helps.

• Swing thoughts
  2004-05-19 15:52:46 ashleyherring
  
  I've been using Swing for several years and have worked on both polished UI projects and unmitigated disasters that used Swing.
  
  My view is that Swing contains everything you need to put together a polished, fast, responsive user interface. However, it also comes with miles of rope for the uninitiated to hang themselves with.
  
  Swing's main strength and weakness is it's sheer flexibility (something that comes from using lightweight components) - it provides developers with the power to change, modify or rewrite any gui component they like. Don't like how JTree works? Extend the class and write your own - or implement a new LAF implementation etc.
  
  This freedom however, comes at a price - by not forcing developers into one set simple way of putting together UIs, it allows hideous designs to be written. I've seen things like performing unit conversions and complex calculations being written inside table cell renderers, to give but one example. This is analogous to the strength and weakness of powerful, uber-flexible languages like C++.
  
  I for one, like this power of Swing, it is what will continue to set it apart from things like SWT (although for straightforward GUIs where you do not want to tinker too much, SWT has it's place). However, perhaps in terms of making Swing more usable, what is required is a layer ontop of Swing (yes, yet another layer) that provides a simplified view of Swing, making it easier for newbies to knock together solid Swing UIs without making all the common coding mistakes.
• Swing thoughts
  2004-05-21 08:53:21 kdenehy
  
  Thank you for so eloquently summarizing my thoughts so that I don't have to. :)

• Swing is easy - Get a good book.
  2004-05-19 15:19:53 zuluimpi
  
  I never found Swing too difficult, perhaps because compared to other UI frameworks I used it seems logical and quite consistent.
  But after reading "Swing" by Vorbiev and Robinson, many of the more subtle details made sense to me.
  It would be nice if Sun would buy the rights to this book (or any other that is as good) and put it online. A perfect companion to the tutorials.

• Too many loose ends: 2 examples
  2004-05-19 12:42:18 k_mccarthy
  
  

  I started working in Swing about 9 months ago. I've found the learning curve steep, but not impossible. But there are a lot of loose ends in Swing, and it reduces your productivity because you have to work around them. Couple that with the fact that most business users have Windows machines, and it is hard to make a persuasive pitch to use Swing instead of Visual Studio

  Here are two examples of what I consider loose ends: a strategic problem - lack of an application framework. The MVC for individual widgets is great, but there is little help for stringing an entire application together. The examples dodge this issue because they are so small a nd simple. But figuring out how to translate an accelerator key into a context sensitive action is not trivial. Some of the open source app frameworks are starting to look good, but it is rather late in the day. a tactical problem - I create a basic dialog - "Save this before exit? Yes No". The dialog is easy to create, but the Y and N keys don't do yes and no like they should in windows. Can I create a custom dialog that does the right things with the keystrokes? Yes. But I shouldn't have to. Kevin

• How About A "Core Swing Patterns" Book
  2004-05-19 09:55:36 weiqigao
  
  

  One way to make Swing easier is to have something like the J2EE Blueprints program for Swing.

  I've blogged about my desire for a guidance book for Swing a few months back.

  Just an idea.

• How About A "Core Swing Patterns" Book
  2004-05-19 11:18:29 jonathansimon
  
  

  Sadly, I've talked to several publishers about an advanced Swing book and they were all convinced there is no market for it. I do think there is a huge need for this, whether there is a market or not is a whole nother question...

• How About A "Core Swing Patterns" Book
  2004-05-20 14:01:56 nderwin
  
  How about having it published electronically, for example as a .pdf, that could be downloaded for a small fee?
• How About A "Core Swing Patterns" Book
  2004-05-19 12:44:47 k_mccarthy
  
  

  I have looked for an advanced Swing book and would have bought it in a second. But I can see the publishers point of view. Here in the Boston area, there are few job postings which list Swing as a desired skill. (well, there a few postings, period. But this was true a 2 years ago as well)

• How About A "Core Swing Patterns" Book
  2004-05-19 11:14:18 rabbe
  
  Absolutely! A book of best practices that show trade offs on speed/functionality would be great.

• so why this discussion again?
  2004-05-19 04:23:39 asjf
  
  hi,
  
  i'm a little surprised that this has come up again. There are plenty of threads about this (lots on this site) and in forums, and they all seem to say the same things.
  
  "Swing is slow" -> "well it was, but its not slow now just slower than a true native application. "
  
  "Swing is slow" -> "Startup time is still a problem though"
  
  "Swing is slow" -> "It still wouldn't harm anyone if more optimisations are possible..."
  
  "Swing is complicated" -> "either adapter API or RAD tools are needed, relying on opensource projects isn't working although they are in early stages. Maybe adopt one, develop and distribute it"
  
  "Swing is complicated" -> "only for VB programmers who are fairly degenerate anyway. A tool that catches 80% of what they want to do would be a good start."
  
  "Swing doesn't look native" -> "ok, but it looks native enough for now? I think we should just grin and bear it. More work is possible of course but if developer resources are limited then its not at the top of the list"
  
  i'm not saying this is exhaustive, but i do think these discussions are generating fewer new/interesting points these days
  
  it would be very interesting to collect them up and see what the Swing team have to say, otherwise it feels like we're all shouting into a black hole!
  
  thanks,
  asjf
• so why this discussion again?
  2004-05-19 10:15:51 rufwork
  
  Great summation! Those are certainly the three main problems with Swing -- perceived performance for whatever reason, API complexity (aka, tools that aren't quite up to the task), and Native looks.
  
  I'd add one thing for number three: Sun really needs to decide if the great goal of Swing -- to provide consistent GUIs in every way, regardless of OS -- hasn't failed.
  
  Take a look at this page:
  http://java.sun.com/developer/community/chat/JavaLive/2004/jl0330.html
  
  In the chat, " Ian Formanek, who is chief of technology for the NetBeans project at Sun Microsystems", says:
  
  

  "3.6 focused on 2 major things: the use of Windows L&F on Windows 2000 and XP (and updating the NetBeans design to look cool under those L&Fs), and introducing a brand-new window management system to streamline the way the IDE fits into the natural workflow of development."

  
  
  If half of Sun's own most popular GUI'd app written in Java is spending half their time making Swing look and perform well on one OS, well, the xplat L&F has absolutely failed. Hey, I love the Napkin Look & Feel as much as anyone (a great idea) -- and therefore pluggable L&Fs -- but in the grand scheme, it's wasted effort.
  
  If Swing's "Java look" is so bad that not even Netbeans users (aka, Java developers) can ignore Swing apps that don't look native, hasn't it failed miserably? I mean, nobody should be more capable of ignoring quirks and understanding why having a Java look and feel that acts exactly the same, regardless of platform, is a laudable goal. If not even the evangelists have faith, why not go ahead and sell out to SWT (or at least start AWT development back up) now?
  
  (And that's likely where part of the black hole comes from -- what a Swing expert to do if feature Swing development's scrapped? The context of the discussion is, "How do we fix Swing?" right now, not, "Is Swing irrepairably broken?")
• so why this discussion again?
  2004-05-21 04:54:43 ttran
  
  I lead the team which designed and implemented this part in NetBeans 3.6. For the record what we did was
  
  (1) new windowing system
  (2) turn on native L&F on Windows and Mac OS X
  
  Most of the effort was spent on the new windowing system. Turning on native L&F is trivial as you can imagine. The only L&F specific thing we did was optimizing several custom components we have to match the L&Fs. This is logical regardless which GUI toolkit you use. We've been working on this for several months, four engineers at its peak plus one UI designer.
• so why this discussion again?
  2004-05-19 12:38:31 jonathansimon
  
  

  Even though the context of this discussion is how to fix Swing -- saying that it can't be fixed is a perfectly valid response. IMHO, its not the case, but its certainly up for discussion.

• so why this discussion again?
  2004-05-19 07:12:40 jonathansimon
  
  One of the main reasons for this forum is to try to get everything in one place. You are right -- there are a lot of forums and blogs with grips about Swing and Sun and so on. One of the goals of this is to centralize the feedback on Swing and come up with some difinitive issues and hopefully get some awareness of those issues by Sun and the community at large.

• More defaults
  2004-05-19 04:01:12 mgrev
  
  I think that what isn't a property, and thus can't simply be changed in a RAD-tool, will not be used by 90% of the developers.
  
  This is why we need sortable JTables and such. I know it is very simple to extend AbstractTableModel and make it yourself, but the risk in doing that is that the time needed for doing it, is hard to estimate for a novice developer. It's easy to get stuck for hours on a simple snag.
  
  So my vote goes to more simplicity, especially in the form of sortcuts. The shortcuts has to be well documented though, but that goes for everything.
  
  When I browse the SDK source code I often find places where another feature would be as simple as adding some "three line" method. Unfortunately the same feature is much harder or impossible to implement by extending the class, since some of the required information is private or package private. GradientPaint and GeneralPath are two classes that could be made MUCH more feature rich with simple means, and they are virtually impossible to extend, in a decent way, since the data fields are hidden from extending classes.
  
  Also it eludes me why there is no font chooser and why the native L&F isn't the default one. But that's a another story.
  
  Cheers,
  Micke
• More defaults
  2004-06-08 06:58:36 phidias
  
  Table sorting was implemented in 1.4. http://java.sun.com/docs/books/tutorial/uiswing/components/table.html#sorting
  
  Are you saying you don't like the sorting mechanism and you want some other mechanism?
• Table sorting
  2004-06-08 23:58:47 tackline
  
  That tutorial just gives an example of how to use table models. Unless I've missed something (not unheard of) then there is no direct support for sorting tables within J2SE. You can't just write something along the lines of: table.setSortable(true);

• Conceptual problems
  2004-05-19 02:05:17 mattlarge
  
  I have over the last year had to learn Swing pretty quickly without much help. We do mostly server side coding, so no one here had any real Swing experience.
  
  I think the main problem I had was conceptually understanding how and whe components are rendered and where it is safe to add logic code when extending a component. There were many times when I would alter a setting in a component and not be able to get that change to render.
  
  There are good swing overview articles, but no many about the issues when extending components, which, as mentioned before in this forum, is required as Swing does not provide the number of components that people want. p.s. Thanks to the Swing team for the JSpinner, it took a while but my boss loves them :)

• Programmers must get it
  2004-05-18 19:20:13 tackline
  
  The only way I can see for programmers to get it is through documentation and brief example code, but it needs to be documentation that they will actually get read.
  
  If you want great software, there's no point in removing the power for simple programmers. A simple programmer is an unproductive programmer. Programmers, whatever they are doing, need to take it on themselves not to be beginners. Although obviously if you're selling a development tool on a per seat basis, you want to be selling to the most unproductive programmers you can. For great software from competent programmers Swing needs to be fleshed out. At the moment we have a moth-eaten rush-job that's been left in a corner for the last six years.

• Any thoughts on the component set?
  2004-05-18 12:30:04 joshy
  
  I have often felt that the default Swing component set is a bare minimum of what's expected of a modern gui toolkit. Perhaps it was good enough in the mid ninties but today our applications demand more. It doesn't even have a built in font-chooser. Any ideas on what components Swing should have but doesn't?
  
  Where are the holes?
• Any thoughts on the component set?
  2004-05-18 17:09:15 markswanson
  
  I often find myself subclassing components for things that could have been provided. I realize that not everyone has the same needs but I strongly suspect that if Sun had a place where developers could "openly" present wishlist items (and collaborate on them, like a true community) I think a _lot_ of ideas would wind up there and the good ones could be voted for. Perhaps the most popular ones could then be submitted as an RFE.
  
  Maybe it's just me, but I think that the developers who are living and breathing Swing would come up with a pretty good list. At the very least, give some focused feedback to the Swing team. Struggling to accomplish this with the current bug submission system (or even the forums) seems to me like it's disabling or working against the powerful sense of community that is present in other great open source projects.
  
  Maybe a forum strictly for Swing API enhancements? I don't know, but I think a lot of people would happily contribute thoughts on the component set given some time and the right place.
  
  Cheers.

• Make it easier to provide feedback
  2004-05-18 11:44:03 markswanson
  
  Projects that are vastly larger than Swing (F.E. the Linux kernel) have public mailing lists where anyone is able to subscribe and participate with folks who are interested as well as the _authors_ of the various components.
  
  I feel disheartened when I send out a bug report to java.com with a perfect small 15 line program that shows the exact error and it takes 11 months, 20 days (my current record) to receive the response, "Hello, sorry for the late response. Are you still seeing this?".
  
  Maybe the forums are read daily by the Swing engineering team - but I have no indication that they _ever_ read them. I suspect some of them do, but why hide behind an anonymous account if you do? If I post feedback to the swing feedback email address or the forums I'm really not sure it's read or even understood.
  
  Sometimes folks are extremely helpful and post info in the forums that can only be gleaned by spending time reading through the Swing source code. I'd like to capture gems like this and forward it to the Swing documentation folks but I have no faith in any of the existing communication mechanisms. BTW, this isn't a problem to Swing, but to a lot of other Sun APIs.
  
  A good example of how it should be done is the mailing list Florian Bomers (Sun) set up for the Java Sound API. I think a lot more valuable feedback would make it back to the swing team with this approach.
  
  Cheers.
• Make it easier to provide feedback
  2004-05-23 12:50:40 jdinkins
  
  Hi -
  
  I'm the manager of the Swing team.
  
  The entire Swing team reads everything posted here:
  
  http://javadesktop.org/forums/forum.jspa?forumID=2
  
  - jeff
• Make it easier to provide feedback
  2004-05-26 09:24:21 markswanson
  
  Thanks for posting that - it's good to know. It had seemed to me that no lines of communication existed between the Swing team and the public.
  
  I wish I would have known this years ago as I would have submitted many patches and notes about the limitations I was facing while extending components.
  
  I think the form should have a header that states something like, "THE SWING TEAM HANGS OUT HERE." so people know.
• Make it easier