15

我想听听一些关于手动编写 GUI 的意见，就像在使用 Java 或 Qt 和 C++ 时通常所做的那样，而不是使用 gui-designer 工具？GUI 设计器工具的示例包括 MFC GUI-designer、Qt 设计器、Interface Builder (Apple)。

我曾经是手工编码的粉丝，但根据最近的经验，我已经改变了。我在手工编码中看到的问题是编写 GUI 相当快速和灵活，但是一旦您需要对很久以前编写的 GUI 进行更改，这可能会非常困难。在大面板中找到合适的元素可能很困难。

第二个问题是，在 GUI 创建和布局代码中添加大量逻辑太容易了。我经常不得不接管难以重用的 GUI 代码的维护，因为它的行为与其外观混合在一起，并且混合布局和行为常常使类变得非常大且难以理解。

在我看来，使用 GUI 设计器工具可以更清晰地分离外观和逻辑。

4

11 回答 11

16

在没有标准（或事实上的标准）GUI 标记语言（如）的情况下，我总是对 GUI 设计进行手工编码。这样做的原因是我发现使用 GUI 构建器设计工具会束缚您使用特定的 IDE。随着时间的推移，用于 GUI 设计和/或编写代码的最佳 IDE 将发生变化，每个开发人员都应该可以自由选择他们觉得最舒服的 IDE。Java

我现在工作的地方，我们有很多使用Netbeans Matisse GUI builder 编写的遗留 GUI（违背了我当时的建议 :-)。这些现在几乎无法维护，因为所有开发人员都更喜欢IntelliJ IDEA或Eclipse作为他们的 IDE。让开发人员启动 Netbeans 只是为了修改 GUI 布局是不现实的或不可行的（人们不会使 Netbeans 项目定义保持同步等）。

另一点是编写 GUI 布局代码的总时间可能只占给定项目总开发工作量的 5%。即使您自己编写代码需要两倍的时间，但这并不会在宏伟的计划中转化为太多的开销。为长期可维护性付出的代价很小。

只要您清楚将 GUI 布局逻辑从业务逻辑中分离出来，我相信不会因此而受到任何影响。这里没有人再使用 GUI 构建器了！

于 2009-03-08T15:18:13.243 回答
7

我是手工完成的，在应用程序中重新使用面板要容易得多（有些面板可以出现在多个地方）。

当你在一个团队中时，使用设计师工作，艺术家应该做 GUI。

在大面板中找到合适的元素可能很困难。

?? 我从来没有见过。

于 2009-03-08T15:26:28.980 回答
4

有趣的是，它对我来说正好相反。从 Winforms 的角度来看，设计师生成的代码非常嘈杂，可能有四分之一或一半的属性设置是真正需要的。与设计师合作时，制作相当大的控件也更具诱惑力。在 Winforms 设计器中更改某些控件层次结构在我看来是一场噩梦。

在我的上一个项目中，我创建了额外的 API 以声明方式在表单、dockmanagers、菜单、工具栏等中设置拆分器。这些使得它们将进一步强制分离关注点。

我还尝试更多地依赖自动布局功能，这些功能在 WPF 中确实要好得多，但也可以在 Windows 窗体中使用。

于 2009-03-08T15:05:35.910 回答
4

我强烈认为您应该使用界面构建器而不是手动编写 GUI。正如在问题中提到的那样，这是一个更清晰的分离，一旦必须编辑某些东西，它就会容易得多。

.uiQt 设计器有这个特性来从文件1)中创建一个类，但我认为不使用这个特性是最好的方法，因为这只会创建更多根本不应该存在的代码。从 -file 创建窗口的速度问题.ui可以忽略不计，因为窗口只需加载一次。

这是 PyQt，但在 C++ 中也有类似的东西：

class SelectDateDialog(QDialog):
    def __init__(self):
        QDialog.__init__(self)
        uic.loadUi("resources/SelectDate.ui", self)

本质上，这与将所有 UI 代码包含在方法中具有相同的效果__init__()，但 UI 几乎与代码完全分离。

1).ui文件是描述用户界面的 XML 文件

于 2009-03-08T16:11:24.160 回答
3

我强烈建议您在 OS X 上使用 Interface Builder。如果您想学习，手动操作是可以的，但是通过在实际项目中使用它可以省去很多麻烦。它确实非常强大。

至于 Java 和 C++，这取决于你在做什么以及在什么平台上。对于简单的应用程序，您可以从不看到 UI 代码。但是，对于复杂的应用程序和富客户端，您通常必须手动编写一些代码。

于 2009-03-08T15:07:44.517 回答
3

如果您正在设计一个包含大量输入表单和表格数据的业务应用程序，那么为您的 UI 编写代码比使用 UI 设计器更快且更易于维护。在这些类型的应用程序中，几乎不需要将一个元素精确地放置在屏幕上的预定义位置，而另一方面，有很多重复和设计约定可以简单地提取到单独的方法中。

以 Eclipse 或 OpenOffice 首选项对话框为例。有一堆类别和一堆不同的选项可以为每个设置。如果您必须制作这种尺寸的东西，那么手工设计每个屏幕是一项平凡的任务。更好的方法是编写代码，根据一些约定和默认值，从提供的域数据中即时生成 UI 元素。

鉴于您已经将业务逻辑排除在 UI 之外，我看不出使用设计器如何促进更好的分离，也看不出这种感知分离对任何事情都有什么帮助。

最后，如果您使用的是 Java，请务必查看MigLayout。它与 Swing 和 SWT 一起工作，它的语法非常简洁明了，并且它有一个非常有用的调试模式。

于 2009-03-08T17:28:07.767 回答
2

这取决于情况，真的。我认为两者都有自己的位置，我通常使用混合方法。

总有一些事情是 GUI builder 不能做的（例如在 Interface Builder 中将颜色设置为 UIColor 常量）。另一方面，大部分 UI 工作都非常普通（例如添加静态标签）。

我更喜欢在 GUI 构建器中做平凡的事情，而在代码中做更有趣的事情。

此外，我偶尔会发现自己手动编辑由 GUI 构建器（在我的例子中为 Interface Builder 和 glade）生成的 XML。

于 2009-03-08T15:03:37.600 回答
1

我倾向于认为正确的答案取决于目标平台的文化。在 OS X 上，Interface Builder 是工具链中不可或缺的一部分，因此很难避免。

在 Java（awt 或 swing）中，情况正好相反。对此没有工具链支持。

确实，您可以说的方式是工具产生输出的方式。Interface Builder 生成 .nib 格式的文件，这些文件特定于 Cocoa 在屏幕上放置控件的方式。它理解本质上是一种界面标记格式。Java没有类似的概念。一切都是编译的类，因此更难获得方便的结果。

GTK+ 与 glade 结合使用时，似乎在两者之间取得了合理的平衡。

于 2009-03-08T15:49:29.250 回答
1

没有什么能阻止混合这两种方法。我经常在 GUI 设计器中制作表单的主要布局（因为它很快并且您可以看到自己在做什么），然后在其中放置一个或多个面板，然后填充代码。这在 GUI 必须适应特定情况时特别有用 - 例如，如果 GUI 必须根据所连接的硬件进行更改。

在任何情况下，最重要的确实是将 GUI 和应用程序逻辑分开。

于 2009-03-08T15:50:36.130 回答
0

我对此的看法： 1. 手工编码的 GUI 代码更可重用 2. 设计师的布局问题更简单

于 2009-03-08T15:07:32.580 回答
0

如果您希望 UI 中包含一些非标准功能，则手动编码可能会很好。你有更多的灵活性，但你需要投入更多的时间来创建一个好的界面，因为 Java/C++ 语言并不意味着针对 UI 设计。

另外，如果您有修订控制，则可以查看更改历史记录，这是使用二进制格式或不支持 RCS 的 xml 格式的设计无法完成的。

如今，大多数用于可视化设计 UI 的可用工具都缺少一些功能。它们不够灵活，有些功能只能通过编码来获得。此外，在某些情况下，生成的代码对人类并不友好，如果您手动修改，您可能无法继续使用设计器。

但是如果设计简单的话，设计真的可以节省时间，我们可以希望未来设计师会有所改进，但我不会拘泥于广度。

我的结论是，如果您今天需要灵活性，则必须手动编写界面代码，如果您想要简单快速的东西，那么设计器是最佳选择。

也许未来设计师会更强大，或者可能会有专门用于 UI 设计的新语言更适合在 C++/Java 中使用，比如 XUL 或 XAML。

于 2009-03-08T17:24:49.430 回答