Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Java Programming

Resource-Based GUIs Vs. Code Generators In Java 164

Posted by kdawson from the gooey-java dept.
Java Fan writes, "There is a good debate about GUI generation tools for Java going on at theserverside.com: 'Almost every platform has a visual designer that serializes the GUI to resources (some XML, some proprietary binaries) and then attaches it to the controller at runtime. Apple has had this for years with Interface Builder, Vista has a similar philosophy now as well. Java developers though are left with either hand coding of GUIs or potentially messy and brittle code generators. Neither of which promote good MVC separation. In fact they tend to encourage violations unless you are a very disciplined coder.' Personally, I am partial to BuoyBuilder as a great solution to this issue."
This discussion has been archived. No new comments can be posted.

Resource-Based GUIs Vs. Code Generators In Java More

Resource-Based GUIs Vs. Code Generators In Java

Comments Filter:

  • Gee, what a deal! (Score:5, Informative)

    by JanusFury ( 452699 ) <kevin...gadd@@@gmail...com> on Thursday November 30, 2006 @11:51AM (#17049848) Homepage Journal
    300 bucks for a crappy UI builder that adds multiple layers of abstraction on top of Swing! That sure is cheaper than Visual C# Express, Interface Builder, SharpDevelop, wxWindows, Visual Basic, or any of the GUI builders available for Eclipse!

    Wait, no, sorry. It's not.

    Nice slashvertisement.

    • Re: (Score:1)

      by 94west ( 957350 )
      It is also available as Open Source, where it's free as in software.

    • Re: (Score:1)

      by WWWWolf ( 2428 )

      300 bucks for a crappy UI builder that adds multiple layers of abstraction on top of Swing!

      Uh... the page says the program is under OSL licence.

      id Software licences their crappy, outdated Quake 1 3D engine for bazillion dollorz. Are they evil too?

      (Granted, the licence appears a bit problematic. You generally can't claim copyright on the output of your program, if the stuff it generates is based on the user input... Otherwise, pencil makers would be really rich. And limiting the field of use is (AFAI

      • Actually, if you check the website, id sells Quake 1 for $10,000 per title - flat rate. Thats actually a pretty good deal when you consider all the crap you wont have to do, even if you have to improve the rendering engine. Its also GPL'd if you want to use it for your own private purposes.

  • The Difference Between Theory and Practice (Score:5, Insightful)

    by anomalous cohort ( 704239 ) on Thursday November 30, 2006 @11:58AM (#17049948) Homepage Journal

    In theory, I'm not against the use of a GUI builder as long as it provides a way to use all of the layout managers that are available. I've just never seen one that could scale in complexity to the needs of a real world application. Sooner or later, the functionality requirements drive GUI elements to be created based on configuration settings and/or business rules. That is where you hit the wall with the GUI builder.

    • Re: (Score:2, Insightful)

      by zhiwenchong ( 155773 )
      In theory, there is no difference between theory and practice. But, in practice, there is. - Jan L.A. van de Snepscheut

      Sorry couldn't resist.

    • Re: (Score:1)

      by fitten ( 521191 )
      Yes, but that's mostly only when you use the GUI builder tool. The concept of using a 'GUI renderer' (one that takes, say, XML and renders the GUI from that XML description) is very powerful. For some advanced things, you may have to generate your GUI programatically at runtime by building the XML (or portions of it) at runtime, which is a bit more work than just click-click-click on a GUI builder tool and shipping that XML description as a part of the deliverable (static and unchanging).

    • Re: (Score:2)

      by misleb ( 129952 )
      I don't know about other interface builders, but Apple's allows you to create as many GUI elements programatically as you want. It is can be a pain specifying and later changing the parameters for said elements, but you can do it.

      -matthew
      • It's worth noting that Interface Builder is a really bad name for Apple's tool. It actually allows you to create serialised object graphs, which you can then restore later. This means that you can insert an instance of various controller classes in the same graph as the views. For document driven applications, it is typical to insert an entire model-controller-view graph into a single file, and restore a copy of it at runtime when the user creates a new window. This is a particularly useful way of worki

    • Re: (Score:2, Informative)

      by Anonymous Coward
      A good GUI builder will allow you to mix and match between resource-based controls and code-built controls. Interface Builder on the Mac is a great example of this. I can use it to build extremely nice and functional windows, but when I run up against the wall of what it can do then I am free to mix in code for whatever is necessary. Normally the code I have to write is small, and put together the whole thing is vastly simpler than laying out everything in code just so I can get a little more power.

  • XMLEncoder/XMLDecoder (Score:5, Informative)

    by AKAImBatman ( 238306 ) * <akaimbatman@gmaYEATSil.com minus poet> on Thursday November 30, 2006 @11:58AM (#17049954) Homepage Journal
    Almost every platform has a visual designer that serializes the GUI to resources (some XML, some proprietary binaries) and then attaches it to the controller at runtime.

    Anyone who's interested in this issue should look into the java.bean.XMLEncoder [sun.com] and java.bean.XMLDecoder [sun.com] classes. These classes are able to serialize and deserialize complete GUIs. In the past, I've used the Netbeans GUI Builder to develop throw-away GUI frontends, then serialized them to a file rather than using them directly. I then built a framework that used the little-known "Name" property on AWT/Swing components to attach actions.

    The results were quite good. Not only was the GUI decoupled from the code, but development was actually accelerated as minor GUI hiccups had no effect on the rest of the codebase. The downside was that the XML occasionally had to be tweaked to perfection as the XMLEncoder class was not 100% perfect in serializing some of the finer details.

    A few years ago I spoke with one of the Netbeans developers about making the XMLEncoder format the standard for Netbeans. The idea was met with some resistence, seemingly because there was no actual Java-standard framework to target. The JVM base libraries have the Encoder/Decoder routines, but all the rest of the work must be done by the programmer. (Such as attaching the actions to the components.)

    Neither of which promote good MVC separation. In fact they tend to encourage violations unless you are a very disciplined coder.

    Train yourself to use Swing Actions. It seems like you're creating hundreds of little objects, but what you're really doing is encapsulating actual actions in the system away from their physcial controls on screen. So if you have a button, a menu item, and a toolbar item that all do the same thing, a single action can control all three widgets. This helps smooth out issues like keyboard shortcuts, which can get quite confusing when coding a Swing application.
    • That's a pretty good point.
      I've run into issues like that with NetBeans in the past, and it was a serious headache - I never tried the technique you mention.

      My biggest issue with Java GUI development, however, is that there is no common codebase for it - if I write a project with Borland JBuilder or whatever, I have to totally redo the GUI in NetBeans or Eclipse. At least, this has been true in my experience with Borland (which was short and negative). Xcode also has this issue.

      Can we get something more lik

      • Re:XMLEncoder/XMLDecoder (Score:5, Informative)

        by AKAImBatman ( 238306 ) * <akaimbatman@gmaYEATSil.com minus poet> on Thursday November 30, 2006 @12:21PM (#17050312) Homepage Journal
        Can we get something more like GTK or something with a nice cross-platform *standard* GUI toolkit?

        The problem isn't the toolkit. It's the lack of a standard serialized form. In the Windows world, the standard format is known as a "resource file". Since all GUI editors target this resource format, there is no compatibility issues across IDEs. Similarly, GTK+ standardizes on GladeXML from the Glade Interface Designer [wikipedia.org]. So there's no question about what format an IDE should support when adding a GUI Designer.

        Swing is one of the few GUI technologies that doesn't have a standard serialized format. The XMLEncoder technology took a step toward solving this, but didn't follow through. The result was that we had a format, but no library to actually wire up a deserialized GUI! (e.g. GladeXML is decoded by libglade) This oversight was rather massive, but ended up being ignored as the focus continued to shift toward server-size J2EE development.
        • So basically there is a format to use, but you're on your own to create the actual document? Like writing XML by hand, kind of thing?

          -WS

          • So basically there is a format to use, but you're on your own to create the actual document?

            Sort of. In my case, I serialized a running GUI to get the file. I could have hand coded it, but that would have been a pain. Instead, I created it in Netbeans, and ran the class through java.bean.XMLEncoder.

            Again, the REAL problem is attaching the actions. (i.e. events, keymappings, etc.) If you think about it, you can't attach an event listener inside an XML file, because the XML file is decoupled from your code. S

            • Re: (Score:2, Informative)

              by 94west ( 957350 )
              BuoyBuilder uses XMLEncoder/XMLDecoder. And it also lets you persist actions, so you don't need the glue code to set up actions after loading the UI. You can do this in one of two ways: (1) you can actually include the object that is the target of the action in the XML file (by making your class available to BuoyBuilder) or (2) you can provide a proxy to the object that will be the target, and provide the instance when loading the UI (or more properly the persisted object graph).
      • Xcode also has this issue
        Not entirely true. The (relatively) new XML NIB format is supported by GORM, and so can be used for cross-platform development.
    • That is all good solid advice, but currently way beyond anyone new to Swing. I really hope that JSR-296 will make this the easiest path to follow.

    • XStream (Score:2, Insightful)

      by MikkoApo ( 854304 )

      I use XStream [codehaus.org] which is very nice xml serialization utility library. XStream has very nice aliasing abilities, so you can trim the xml to very close to absolute minimum ( 2 minute tutorial [codehaus.org]).

      Currently I'm planning on externalizing website validation objects as xml so they can be updated more easily and dynamically. It's basically the same thing you describe and I can easily see how it would help with GUI programming. To get around the "attaching actions to the components" problem you can use the MVC design

      • Re: (Score:3, Informative)

        by AKAImBatman ( 238306 ) *

        I use XStream which is very nice xml serialization utility library.

        I have played with XStream a bit. It's nice, but it has the disadvantage of (at least when I tried it) not being able to correctly serialize a Swing GUI. The Java Bean libraries are tweaked to understand Swing classes, so they correctly serialize the GUI in nearly all cases. (Minus a few of the fine details I was mentioning.) Deserialization is a minor issue in comparison.

        he XML-serialization has a few problems though:
        * Versioning, what if t

    • Re: (Score:2)

      by curunir ( 98273 ) *
      Another option for creating XML-based GUIs in java is XSWT [sourceforge.net]. I've found that it makes laying out a GUI no harder than laying out an HTML document (or it would be no harder if they'd improve their docs...grr), yet it still gives you the ability to manage all behvavior in Java.

      However, it's not Swing, which may be a problem for some (I personally like SWT better than Swing, but understand that some believe the opposite).

  • GINAC (Score:4, Interesting)

    by lieven_dekeyser ( 644644 ) on Thursday November 30, 2006 @12:01PM (#17049990)

    We started a project along the lines of Interface Builder with a Java Swing implementation for our master's thesis in 2005. It's called GINAC, as in GUI Is Not Application Code [ugent.be].

    As I really hate designing GUI's in code, I've started working on it again lately, currently implementing something along the lines of cocoa bindings. If anybody is interested in helping out, let me know!

    • Re: (Score:3, Informative)

      by fireboy1919 ( 257783 )
      Okay! Here's some help.

      You've joined the ranks of Mozilla Firebird, and Jetty, the Tads Virtual Machine [drizzle.com] by trying to make a new project with exactly the same name as an already existing, extremely popular project.

      How about you rename it to something that isn't taken?

      GINAC=>GINAC is not a computer algebra system [ginac.de]

      Step #1 of picking a name for any OSS is looking for it on Google.
      • Yep we should have googled.. Oh well, we had to come up with a name fast, and an acronym sounded like fun :-)

      • Re: (Score:2)

        by julesh ( 229690 )
        Step #1 of picking a name for any OSS is looking for it on Google.

        Step #1 of naming *anything* is looking it up on Google.

    • Re:GINAC (Score:5, Funny)

      by computational super ( 740265 ) on Thursday November 30, 2006 @12:52PM (#17050866)

      You should just go the extra few feet and call it "Visually Activated GUI Is Not Application Code".

    • Re: (Score:2)

      by chochos ( 700687 )

      I thought about this a few years ago. It is technically feasible and if I'm not mistaken, someone at Sun was working on this when Swing first came out, but it never materialized for some reason. I was discouraged from doing anything like this because of that big ugly disclaimer in Swing:

      Warning: Serialized objects of this class will not be compatible with future Swing releases. The current serialization support is appropriate for short term storage or RMI between applications running the same version of

  • Huge oversight on Sun's part (Score:4, Insightful)

    by xtal ( 49134 ) on Thursday November 30, 2006 @12:09PM (#17050106)
    I'm not sure how they released without some sort of GUI building tool. I haven't used Java in awhile, but I remember coming up with Shakespearean-esque curses to describe what I thought of GridLayout and their buddies.

    Is there an accepted good builder now? The article seems to imply this is far from a solved problem. (10 years later!)

    • Re: (Score:2)

      by _xeno_ ( 155264 )

      There's Netbeans [netbeans.org] which has a GUI builder. (Which, IMHO, sucks. Or at least did the last time I used it.)

      Eclipse [eclipse.org] also has plugins (the Visual Editor) to allow creating GUIs graphically. (Which is, IMHO, worse than Netbeans's.)

      So, there are GUI building tools. They just suck. (IMHO, of course.)

      Personally I'd like to see something like XUL where the GUI is specified using a markup language. Which is why I started writing one and then never released it.

    • Re: (Score:1, Insightful)

      by Anonymous Coward
      Netbeans has had a GUI builder for quite some time. It is a Sun product, and can downloaded as a bundle with the JDK: http://java.sun.com/j2se/1.5.0/download-netbeans.h tml [sun.com]

      Whoever modded your post "Interesting" clearly has a sense of humor.

    • Re: (Score:3, Informative)

      by chroma ( 33185 )
      Take a look at the videos that demonstrate Netbeans 'Matisse' GUI builder. I use it all the time, and find it quite handy:
      http://www.netbeans.org/kb/articles/matisse.html [netbeans.org]

    • Is there an accepted good builder now? The article seems to imply this is far from a solved problem. (10 years later!)

      Yes [jformdesigner.com]

      It supports many layout models [jformdesigner.com] including the JGoodies FormLayout, which is far superior to the old GridLayout system.

      I've been using it for the last few years and it works marvelously.

    • Re: (Score:1)

      by DimGeo ( 694000 )
      Strange, I thought GridBagLayout was teh roxorz. Anyway, it's probably just me, and I don't do Java anymore here in the northwest.

    • Re:Huge oversight on Sun's part (Score:5, Interesting)

      by VGR ( 467274 ) on Thursday November 30, 2006 @03:30PM (#17053780)
      I haven't used Java in awhile, but I remember coming up with Shakespearean-esque curses to describe what I thought of GridLayout and their buddies.

      I'm guessing you really mean GridBagLayout, since GridLayout is a different and very very simple layout.

      I realize GridBagLayout is hard to learn, but over the years I've learned that you cannot avoid it.

      Sun has tried [sun.com] three [sun.com] times [sun.com] to make a "simple" replacement for GridBagLayout. Each attempt utterly fails as a replacement (but each is useful for some other rare types of layout needs).

      I've tried to make my own "simplified" version of GridBagLayout too. In fact, I suspect nearly every intermediate Java GUI programmer tries this at some point; it's almost a rite of passage. And it's always a failure. The reason is that UI layout simply is that complicated, and there's no way around it. If you think it's simpler, then you probably aren't aware of all the issues involved.

      A UI builder won't make it any simpler. It will just make it easier for you to ignore the issues. The usual result of such "freedom" is that the resulting UI looks acceptable, but doesn't have acceptable behavior. For instance, to pick a simple case, a scrolling list doesn't resize when the window containing it resizes.

      • Well said.

        In fact, my First Rule of Java GUI Development is that any given layout, whether it starts off using a BorderLayout, FlowLayout, or whatever, will eventually get rewritten to use a GridBagLayout. None of the other LMs is sufficiently flexible or powerful, and you always end up hitting one of their limits.

        People bemoan the complexity of GBL, but as you say, it's irreducible complexity. (With the possible exception of internal padding, which I never use.)

        If there's a problem, it's with Sun's

        • Re: (Score:2)

          by VGR ( 467274 )
          • If it can't lay out everything at its preferred size, it completely ignores preferred sizes and lays everything out based on their minimum sizes. This sounds logical, but means that layouts suddenly 'jump' when resized below the preferred size, and can look very strange at small sizes. Instead, it should scale components down smoothly from their preferred to minimum size, taking both into account.
          • It does very stupid things if it can't even give everything its minimum size (e.g. giving some components neg

      • Re: (Score:2, Informative)

        by nodrogluap ( 165820 )
        Speaking of GridBagLayout, this is the funniest animation I have ever seen...

        http://madbean.com/anim/totallygridbag [madbean.com]
    • JGoodies Forms [jgoodies.com]. It's what GridBagLayout should have been.

      --Rob

  • Faces in the Crowd (Score:4, Interesting)

    by Doc Ruby ( 173196 ) on Thursday November 30, 2006 @12:11PM (#17050148) Homepage Journal
    Possibly Java's greatest strategic feature is the classloader that can dynamically retrieve classes across the network at runtime and safely instantiate them. If Java had a standard API and data format for de/serializing UIs that accommodated their remote contexts, applets could become much smaller and dynamically bound to the UI facilities of their arbitrary runtime platforms. If these mobile UIs were componentized with a consistent internal API, applets could share UI elements among themselves on the same host. That architecture would not only reduce distribution size and increase flexibility, but it would promote reuse of the same UI components across applets, increasing user productivity with fewer learning curves.

    If those APIs don't already exist, reusing an existing one, especially Flash, would offer possibilities for reusing existing components or patterns already populating the Net.

    Java could increase its stature among distributed architectures. And make our lives easier.
    • > Possibly Java's greatest strategic feature is the classloader
      > that can dynamically retrieve classes across the network
      > at runtime and safely instantiate them.

      It's kind of interesting how this feature conflicts with Java's static typing system. I mean, if you're receiving a bytestream across the network you need to have some sort of way to unmarshal it into objects, and doing that in Java involves a fair bit of casting and exception catching. You see the same sort of issues with XML to object
      • Typing the incoming class doesn't seem to be a big problem. Maintaining consistent namespaces can be a problem, but that's a reason the classes have a single namespace ensuring global uniqueness and identity, <FQDN>.<FQCN>. Why cast to a type, when you can just use the original type, called by name to the classloader?
        • Right, but aren't there a flurry of ClassNotFound exceptions and whatnot to catch? Also, I guess what I'm thinking about are things like:

          person = readFromNetworkSocket(); # reads in a Person
          puts person.age; # yay, we're calling methods

          where you don't have a predefined Person type; instead, the data gets read from the stream and a new type is defined at runtime.
          • There will be ClassNotFound exceptions when the loaded class is instantiated without classes to which it refers not being either preinstalled or downloaded at runtime. Both design flaws by the applet programmer, not the language. What's the alternative? Other than resolving symbols across the network, which is a job for a future runtime platform, and a future network with much less latency (like a quantum entangled one ;).

            I'm not sure how you declare the Person class before you instantiate it from the class
            • > I'm not sure how you declare the Person class before
              > you instantiate it from the class loaded by the network.

              Right, exactly - since Java is statically typed, the type needs to be declared somewhere - probably via an existing interface or base class or some such. That's kind of the beauty of dynamic typing - types don't need to be declared in advance.
              • Yes, but I'm just claiming ignorance. That doesn't mean there is no facility for declaration, against which (among other specs) the classloader (or the VM) validates the class on instantiation. Since the classloader would be useless without such a facility, it must exist, because it's used enough to indicate usability. Someone else must know, even though I don't.

                QED, pronounced "talking the talk, not walking the walk".
                • > QED, pronounced "talking the talk, not walking the walk".

                  Hehe, so true, I feel that way so often! Well, back to reading the Rails 1.2 upgrade notes...

              • Using XML micro-formats is a more dynamic and flexible approach than persistent objects. Your data is much too important to tie it directly to the internal implementation of one particular version of one particular class.

                The approach that OpenLaszlo [openlaszlo.org] takes is XML data binding and declarative constraints. You design XML "micro formats" for your data, and then you can write many different views and editors of the same data, by binding different OpenLaszlo classes to the XML data with XPath constraints and

    • OpenLaszlo [openlaszlo.org] is a great way to write "AJAXian" dynamically downloaded componentized data driven applications, that run in the Flash player and DHTML/JavaScript browsers (and eventually the J2ME Java VM [openlaszlo.org]).

      For many years, I've been building distributed data driven scriptable user interfaces, and evangelizing what's now called the "AJAX" architecture. Here are some old articles I wrote about X, NeWS and TCL in the 80's and 90's. Note that in this context "server" means window server (your desktop: once called

      • I've been watching OpenLaszlo for a couple of years. I almost attended one of their (paid) tutorial seminars, but the price was too steep without knowing the value of the dev platform.

        Can I really write a GUI app in OpenLaszlo that compiles cleanly to Java and Flash applets that run close to the same in respective VMs on PCs and mobiles/phones, as well as native apps? Or is it a meta version of Java's "Write Once, Test Everywhere", made intractable by the complexity of target platforms?

        Which IDE is best, th

        • You can certainly learn the value of the platform without paying for a seminar. The development platform is free since it's open source, and it doesn't cost anything to read the online documentation, the wiki [openlaszlo.org], and get involved with the community [openlaszlo.org].

          Of course there are differences between the capabilities of different platforms. OpenLaszlo is most mature on Flash, which runs identically on all platform and browsers, and has great graphics and multimedia capabilities. The DHTML/JavaScript version of OpenLasz

  • Never heard of Matisse eh ? (Score:5, Informative)

    by Anonymous Coward on Thursday November 30, 2006 @12:15PM (#17050206)
    Java developers though are left with either hand coding of GUIs or potentially messy and brittle code generators.

    Whenever it comes to Java it always amazes me how many people have very outspoken opinions about it while its almost immediatly obvious that they hardly know what they're talking about. Then again, when reading the article its becoming obvious that when he's talking about GUI's (since when do you code in a GUI? I use an IDE for that) he actually means to say Eclipse. Don't get me wrong: I'm not dissing Eclipse here, but do question his bias.

    When it comes to building GUI's Java really allows itself to be used by code generators IMO simply because Java is very modulair build. The only problem you might face here are the somewhat limited layout managers. For the non-Java people amongst us: these basicly define the "interface" between the GUI you're building and the way it behaves. For example; when it comes to resizing or placing of the objects then you're dealing with a layout manager.

    Now... When it comes to Java IDE's two names immediatly spring out: NetBeans [netbeans.org] (my personal favorite) and Eclipse. Now that he has commented on the latter let me comment on the first. From NetBeans 5.0 and up it comes with a fancy GUI builder codenamed "Project Matisse". Its official name is now NetBeans Swing GUI builder [netbeans.org]. After taking a closer look at that I wonder if he still thinks that there are no decent GUI builders available for Java.

    The real problem here isn't so much the GUI builder but the underlying layout manager which needs to keep things in check. I think that also explains why there isn't much of this available as it looks to me as if there aren't many people about who manage to come up with decent Java coded tools which can be used and adopted by many other coders. NetBeans has solved all this by introducing a layout manager of their own, the so called Absolute Layout. Pro's are its extreme extensiveness, the con's are that if you wish to use it you'll have to ship it with your software because its not part of the standard Java Runtime Environment (JRE).

    If you wish to see a demo of Matisse in action then check out the NetBeans flash demos [netbeans.org], especially the first part of "Why NetBeans?". Personally I'd recommend another approach, namely simply downloading NetBeans [netbeans.info] and trying it out for yourself. Its available for Linux, Solaris, Windows and I think even OS X.

    • Re: (Score:2)

      by mark-t ( 151149 )

      Uhmm.... Matisse sucks. I like netbeans... but I really do hate their GUI builder.

      The GroupLayout that they have bundled with it seems to crap out all the time, as previously placed components suddenly go zooming off to one side. or sometimes even out of the bounds of the component entirely, when all I did was add one more component to the parent. The number of headaches this has caused me in the past is enough to make me not even _try_ using it anymore... I now almost always use either gridbaglayout o

    • Absolute layout considered harmful because the resulting GUI looks very unprofessional when the containing window is resized. It is difficult and very challenging to create a GUI builder that does not rely on absolute layout, however, it is not impossible.

      What I find interesting is the psychology in perceiving different types of GUIs. We don't expect the contents of a web page to resize when we resize the browser window because we view the browser window as a window on the web page document and not the p

  • Interface Builder (Score:3, Interesting)

    by David Off ( 101038 ) on Thursday November 30, 2006 @12:15PM (#17050214) Homepage
    > Apple has had this for years with Interface Builder

    Presumably NeXT has had it for even longer, a couple of decades or there abouts. IB was written by a brilliant French coder as I recall... he was a friend of a colleague. Short of firing up my NeXTBox does anyone remember more of the history?

    • Re: (Score:3, Informative)

      by 0racle ( 667029 )
      No, but like many things, you only need to know where to look [wikipedia.org]:

      Interface Builder first made its appearance in 1988 as part of NeXTSTEP 0.8. It was one of the first commercial applications that allowed interface elements (such as widgets and menus) to be placed in an interface using a mouse.
      • Yes but they don't say who the author(s) is.

        Anyway I was right about the French connection Jean-Marie Hullot [rixstep.com] and Bertrand Serlet [wikipedia.org] are the authors. Bertrand worked at Inria in the offices next to mine when I was an engineer at the OSF. It is interesting that Simon Patience is director of Engineering at Apple and also worked in the same office block in downtown Grenoble city. I believe their are others too.

      • HyperCard [wikipedia.org] was originally released with System Software 6 in 1987.

        HyperCard was more advanced than NeXTStep in 1987, and in many important ways it is still is more advanced than Cocoa in 2006. In all the 18 years since the release of NeXTStep, it STILL does not let users edit their user interfaces the way HyperCard did. It has none of the user-customizable run-time flexibility, which was one of the most important features of HyperCard: it enabled anyone (even kids) to construct their own user interfaces.

  • I find that the code generators/visual dev environments never create truly maintainable code that adheres to good coding conventions/standards when working with a reasonably complex user interface design.

    My approach is to use the GUI designers to quickly prototype the UI and for fast proof of concept. Once I am pretty close to the requirements, it is time to refactor to good coding standards.

    With regard to Java, the only approach that I have seen that is flexible and maintainable is to provide the cor

  • Just Use Swing (Score:3, Insightful)

    by mrcparker ( 469158 ) on Thursday November 30, 2006 @12:25PM (#17050356)
    XML-based Swing GUI tools are really a dime a dozen, and always seem to add an extra layer of complexity to Swing-based apps. Swing is a really nice component system, and pretty much every object is easily extendable. Personally, I have tried a good deal of the XML-based systems, and really using Swing as it was intended is the way to go. Build your own components, extend them, combine them. I know that there is this idea that you hand over the frontend to a designer, but we all know that most of the time it is the developer hacking on the frontend.

    I can understand why people think they need XML-based systems. So much Swing-based code sucks ass. Putting all of your buttons and frames in a big-ass method is nasty and hard to maintain. Well-thought-out componentized Swing code is easy to maintain and nice to look at. Plus, once you are finished with your project, you can re-use any components you built. Swing is a great library - more people need to just learn it.

  • IBM's AUIML (Score:1, Interesting)

    by Anonymous Coward
    I find IBM's AUIML to be an amazingly good solution. You can design the GUI with a visual tool and write code that runs in Swing as well as in a web server (as a web or portal application). Here's a link to AUIML page on AlphaWorks: http://www.alphaworks.ibm.com/tech/auiml [ibm.com] Download seems to be outdated at this time. Look for version 6.x if you want to give it a try.
  • I've been developing a lot of applications lately with J2EE (thus Webbased). There are some cool things happening there, for example good integration with JSF and Dreamweaver. This lets designers use Dreamweaver while the programmers are programming the back-end.

    Also one thing that might be worth looking into is Apache's Velocity, templating at a whole new level.

  • Glade (Score:4, Interesting)

    by RichiP ( 18379 ) on Thursday November 30, 2006 @12:53PM (#17050890) Homepage
    The Java-Gnome Project [sourceforge.net] uses Glade [gnome.org] to build a serializable (to XML) GUI.
  • I see nothing wrong with this.

    Hand coding may not promote a clean separation of concerns, but it does nothing to preclude it. Interface generation does not ensure a clean separation of concerns. In fact I doubt that it does anything significant to promote it.

    The problem is that the controller tier is still a user interface component, which many engineers don't seem to understand. The achilles heel in most MVC programs are bloated, unmaintainable controllers. You still end up with important assumptions

  • IntelliJ (Score:2, Informative)

    by sproketboy ( 608031 )
    IntelliJ's designer does exactly that. I saves the UI code in XML files and you only need to code the specific business logic in a seperate class. The designer itself is quite nice as well.
  • It can be used opensource (GPL) as well as commercially. Here is the link to the tech preview. [trolltech.com]

    I have to say, I'm pretty impressed so far.

  • Every single application I build these days, either for business or for personal use are based on a web UI. Java has incredible MVC frameworks for building web based applications from Struts, Spring, Tapestry, etc... Honestly, if someone is building a Swing based GUI, I'd have to ask: WHY?

    • Re: (Score:2)

      by twehrle ( 580963 )
      Anyone writing internal applications that want a rich user interface. Not everyone writes blogging/email/im/forum/newsfeed software.

    • Re: (Score:3)

      by VGR ( 467274 )
      Maybe I'd like my application to have a menu bar which can be navigated with the keyboard.

      Maybe I'd like drag-and-drop of files or images or custom data.

      Maybe I don't care for the cardinal UI sin of having scrolling areas inside other scrolling areas.

      Maybe I want a context menu.

      Maybe I want something HTML doesn't provide, like a table with selectable rows.

      Maybe I don't want to worry about disabling the "Back" button.

      Maybe I don't want to worry about a user double-clicking a form submit button.

      If UI librarie
  • I've always wondered why simply serializing a GUI wasn't used more in Java. Perhaps because Swing is so easy to use. Most java programmers I've known in the past shunned any type of GUI development tool in favor of hand-coding swing because it's so much more straight forward.

    Also, it's difficult to get reuse out of a GUI editing tool, but very easy to get it by hand-coding. I generally write factory-type code that handles generating menus, buttons and linked Actions together, in a GUI tool you will often
    • I would rather deal with Mac's interface builder any day, than deal with complexities of some of Java's Layout Managers. Sure it could be down to my incompentance, but dealing with things like GridBagLayout is a nightmare.
      • GridBagLayout is intended for use by GUI builders only. Not understanding that fact emphasizes your point about a lack of experience (competence is a little much).

        Every java programmer I've known nests BorderLayout and other common layouts that fit the need.

        But I understand the Mac interface builder is pretty good. So is the VB one by the way. When either works for all platforms and allows the GUI to be manipulated by code as easily as with java, I may re-evaluate it. (For instance, I used to use VB and
  • it was in 1984 that we already had ResEdit [wikipedia.org] which abstracted the whole GUI from the code -- it did such a good job, that end users could open a shipping application executable, and go in and change bitmaps, menu keyboard shortcuts, dialogue texts, and sounds -- so long as they kept the same resource ID, the app would keep on working.

    this system was eminently useful in getting mac applications translated into languages other than english, as any user could open the shipping application with resedit, start tra

  • having trouble digesting this... (Score:3, Insightful)

    by geekschmoe ( 244913 ) on Thursday November 30, 2006 @02:49PM (#17052930)
    Neither of which promote good MVC separation. In fact they tend to encourage violations unless you are a very disciplined coder.

    I don't mean to sound all high and mighty, but if you aren't a disciplined coder, then you're not very serious anyway. You can pre-plan the MVC design to your hearts content, but it takes discipline to stay within the boundaries of the original design. Especially since if you don't then you create one of the worst anti-patterns ever, making you wish you'd just written one monolithic chunk of procedural code because bugs/changes would be doable.
  • If you use Qt for your interface, their GUI builder is pretty good. And it's free. And it generates C++ that you can inspect, modify and understand.
  • So what good resource based GUI builders are there for Java? This is the one thing I have been hunting for, after having developed for the Mac and Windows. I can't stand code generators, since the code is usually large and ugly, and usually require some hand tweaking because the code generation has limitations. I once saw a solution that was written to use XML for the resources, but it ended up almost being as large and monstrous as the Java code it was meant to be replacing.

    Maybe using Microsoft's GUI XML
  • If you haven't used Interface Builder (IB), then you are really missing out. Many people have a difficult time wrapping their brain around the concepts of Interface Builder, but I assure you it is across the board the best GUI builder paradigm yet invented. For a very brief introduction to its concepts, see Hold Me, Use Me, Free Me http://www.stepwise.com/Articles/Technical/HoldMe. html [stepwise.com].

    In fact, IB should have been named "Object Connector" because it is not a "builder" at all. All IB does is let you inst
  • I like the way Qt (v4) Designer does it. The output of Designer is an XML file, and during the build stage uic (ui compiler) generates a form class. This class is not a widget (as it was in v3), but a very minimal class that's only one step away from being a legitimate POD class or struct. All it essentially contains is the form's component widgets as public data members, aand setupUi() function to layout the form in the widget you pass it. It doesn't inherit from anything.

    This gives you a lot of flexibilit

Slashdot Top Deals

Without life, Biology itself would be impossible.

Close