This message is a response to the GUIs in Clojure thread from last October (2008). There were "Reply to Author" links, but no "Reply" links. Is that because of its age? The thread I'm referring to is:
http://groups.google.com/group/clojure/browse_thread/thread/22e4696550b6c4fa/fbccbe56dd45c80c?lnk=gst&q=swing or http://snipurl.com/bfqn6 Hello, all. Interesting thread. Sorry I'm late. ;) I've read all the messages on the thread and have some thoughts... A GUI, by design, is mutable. Its purpose is to enable the user to perform actions on it that change its state, and for the program to be able to mutate the display or other state in response to the user. Why is this a problem? V. Quixote said: "It sounds like all we really need is a single clojure thread which handles all access to Swing/AWT/Whatever." The SwingUtilities invokeLater and invokeAndWait methods effectively post actions to a queue which are executed sequentially by the event dispatching thread. So this problem is solved, isn't it? Why is there also a need for some kind of Clojure thread to coordinate this? Pinocchio's swing macro is interesting because it enables the same action to be called either by the event dispatching thread or another thread, and uses the invokeAndWait when appropriate. (In some cases you might want invokeLater but I suppose you could call invokeLater explicitly rather than using the macro.) I can imagine this would be helpful, for example, to trigger a refresh of the UI; but be careful to honor model/view/controller design, which usually means calling a model's fire method rather than telling a view to refresh itself, because there could be multiple listeners on a model, and the model's listener management would notify them all for you effortless and automatically. For example, if you had data displayed in a table, and wanted to trigger the table to update itself, you would call the table's model's fireTableDataChanged() or the like. And, for example, if you had a "Number of Rows" label above the table, and it had registered itself as a listener to that table model, then it would be notified too. * * * Martin DeMello said: "In particular the developers of Monkeybars (JRuby/Swing) project have come out and said that manually laying out widgets in code is counterproductive." In a substantial GUI app, it is extremely important for visual consistency, maintainability, reliability, and extensibility for as many components as possible to be coded once and reused (i.e. DRY). Pretty much any repeating pattern is eligible for this, be it a special kind of label, an entire window, or anything in between. A problem with the use of designers is that often, because it is so easy to create things on the fly, that reuse is often ignored. This becomes a huge problem when something needs to be changed across the application (e.g. adoption of user interface guidelines, or internationalization). True, this abuse can also occur when hand coding, but the repetition is harder to ignore. Another problem with the use of designers is that, the last time I checked, which was admittedly a very long time ago, it was difficult or even impossible to use code to build the GUI. For example, have all standard borders be of size OurGUIStandards.BORDER_SIZE, or use the screen size calculated at runtime for a window's size and placement. Although hand coding Swing components is tedious, there are economies of scale. The additional effort in keeping the code DRY pays for itself many times over. As more reusable code is created, the marginal cost of an additional window diminishes. * * * Frameworks for simplifying Swing programming can be quite useful, especially to exploit the language's flexibility. Both Clojure and Ruby provide ways to specify Swing code much more concisely, for example, via lambdas and literal collection instances. However, sometimes a framework's simplicity is provided at the cost of functionality and flexibility. So that's something to watch out for. - Keith --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
