Java AWT / SWT / Swing：如何规划GUI？ [英] Java AWT/SWT/Swing: How to plan a GUI?

问题描述

我已经通过一个小的图形用户界面实现了一些应用程序。没有什么复杂的，但是我遇到了几个问题，组件不显示或只是没有按预期的方式。

现在我的问题：

你如何规划这些用户界面？当您需要进行更改时，您会做什么？如何调试奇怪的行为？

这适用于几乎所有类型的gui设计。当然，与微软的Visual Studio相比，你有一个很大的优势，因为你几乎可以得到你在设计师中看到的东西。

源代码（或免费软件）设计师存在AWT？已经环顾四周，没有发现任何真正的智能。

编辑：到目前为止，我还创建了我所有的GUI 。当然这是更干净的代码，但有时很难找到布局错误。如果Visual Studio由MS创建大致干净的代码，为什么不是其他的？

我听说过一些Eclipse Visual设计器。是否已经有生产准备？

---

/ p>

解决方案

我不是GUI制造商的大粉丝：他们通常会自动生成桶装的代码，然后锁定整个开发团队使用一个IDE。此外，此代码通常不可读（检查在Netbeans下使用Matisse时生成的代码）。

我对GUI设计/调试的建议是：

• 向每个面板（或顶级组件）实现添加一个 main 方法，允许其他开发人员轻松确定组件的外观。


• 喜欢使用 Action s ActionListener s并且每个 JComponent 的 ActionMap 注册这些操作。这允许它们被提取并添加到UI的其他部分（例如 JToolBar ），同时仍然由拥有 JComponent （即松散耦合）。


• 使用assert确保所有UI组件修改都发生在事件调度线程上;例如 c code code code code code code code code $ c $ $ b
• 集中捕获和报告工作流事件和异常。例如，我通常实现在我的UI状态栏中注册的 TaskManager 类。任何后台处理（在 SwingWorker s中执行）都将句柄传递给由任务 >任务管理。 （通过调用 setDescription（String）， setThrowable（Throwable）， cancel （））导致状态栏被更新。它还会导致玻璃窗格显示为全局任务，但这与所有SwingWorkers都解耦/隐藏。


• 不要使用观察者 / 可观察类，而是更倾向于 ChangeListener ， PropertyChangeListener 或您自己的自定义侦听器实现，用于传播事件。 Observer 传递一个 Object 作为事件，强制客户端代码使用instanceof检查类型并执行downcasts，使代码不可读，使类之间的关系不太清楚。


• 喜欢使用 JTable 超过 JList ，即使在表只有一列的情况下。 JList 在其API中有一些令人讨厌的功能，其中包括您需要提供一个原型值来正确计算其大小。


• 不要使用 DefaultTableModel ，因为它通常会导致您将模型数据存储在两个位置：在实际的业务对象中以及2D数组中 DefaultTableModel 坐在上面。相反，简单的子类 AbstractTableModel - 很容易这样做，意味着您的实现可以简单地委托到数据结构（例如列表）存储您的数据。

I've already realized some applications with a small graphical user interface. Nothing complex, but I've encountered several problems that components aren't displayed or just not behaving as expected.

Now my question:

How do you plan those user interfaces? What do you do when you need to make changes? How do you debug strange behaviours?!

This applies for nearly every type of gui-design. Sure, with Microsofts Visual Studio you have a big advantage because you nearly get what you see in the designer.

Does a good and open-source (or freeware) designer for AWT exist? Already looked around and didn't find anything really intelligent.

EDIT: Until now, I've also created all of my GUIs by hand. Sure it is cleaner code but sometimes it's very hard to find the layouting bugs. If Visual Studio by MS is able to create approximately clean code, why aren't the others?

I've heard about some Eclipse Visual designer. Is that one already production-ready?

---

regards

解决方案

I'm not a big fan of GUI builders: They typically autogenerate bucket-loads of code that then locks in your whole development team to using one IDE. Also, this code is often unreadable (check the code generated when using Matisse under Netbeans).

My recommendations for GUI design / debugging would be:

• Add a main method to each panel (or "top-level" component) implementation, allowing other developers to easily determine what a component looks like.
• Favour the use of Actions over ActionListeners and register these actions with each JComponent's ActionMap. This allows them to be "extracted" and added to other parts of the UI (e.g. JToolBar) whilst still having their state controlled by the "owning" JComponent (i.e. loose coupling).
• Use assert to ensure that all UI component modifications are occurring on the Event Dispatch thread; e.g. assert SwingUtilities.isEventDispatchThread().
• To debug strange layout behaviour consider painting a component's background in red!
• Centralise the capturing and reporting of workflow events and exceptions. For example, I typically implement a TaskManager class that is registered with my UI's status bar. Any background processing (performed within SwingWorkers) is passed a handle to a Task created by the TaskManager. Interracting with the Task (by calling setDescription(String), setThrowable(Throwable), cancel()) causes the status bar to be updated. It also causes the glass pane to be displayed for "global" tasks ... but this is all decoupled / hidden from the individual SwingWorkers.
• Do not use the Observer / Observable classes, but instead favour ChangeListener, PropertyChangeListener or your own custom listener implementation for propagating events. Observer passes an Object as it's event, forcing client code to check the type using instanceof and to perform downcasts, making code unreadable and making relationships between classes less clear.
• Favour the use of JTable over JList, even in situations where your table only has one column. JList has some nasty features in its API including the fact that you need to provide a prototype value for it to calculate its size correctly.
• Never use DefaultTableModel as it typically results in you storing your "model" data in two places: In your actual business objects and also within the 2D array that DefaultTableModel sits on. Instead, simply subclass AbstractTableModel - It's very easy to do this and means your implementation can simply delegate through to the data structure (e.g. List) storing your data.

这篇关于Java AWT / SWT / Swing：如何规划GUI？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！