何时定义GTK类，何时使用信号？

Question

我是GTK的新手，我正在搞乱我的第一个“严肃的”GTK（gtk + -3）应用程序。 我想借鉴别人的经验，了解何时适合定义新的GTK类，或者只使用“vanilla”GTK类，并通过信号处理程序实现行为。

到目前为止，我遇到过两个例子：

自定义小部件

我正在创建一个新的小部件：基本上是一个GtkDrawingArea，我用它来显示一些数据。 我原先假设实现这个的最好方法是使用G_DEFINE_TYPE ，并提供我自己的绘制回调：

static void mywidget_class_init(MyWidgetClass *klass)
{
    GTK_WIDGET_CLASS(klass)->draw = mywidget_draw;
}

但是，看起来我可以在不定义新类型的情况下实现完全相同的功能，只需创建一个vanilla GtkDrawingArea，并在初始化期间连接相应的信号。

[我的自定义窗口小部件最终将提供的不仅仅是绘制回调，因为它需要是交互式的，但后来会......

应用程序Windows

我的应用程序包含几个不同的窗口，目前是vanilla GtkWindows：

struct myapp_somewindow {
    struct myapp *app;
    GtkWindow    *window;
    GtkWidget    *some_label_that_is_updated;
    /*... other window-specific fields */
}

初始化myapp_somewindow结构时，我使用gtk_window_new()创建GtkWindow，并初始化小部件/布局/等，并连接信号。 [我可能最终会在更复杂的情况下使用.ui文件，但是现在窗口很简单。]

这可以通过定义GtkWindow的新子类来完成，但我不确定定义新类的代码开销何时变得有价值。

---

我知道对于采用哪种方法可能没有严格的规则，但在做出这些设计决策时是否有任何一般指导原则？ 这两种方法都有任何重大缺陷吗？

Answer 1

我使用GTK +和Clutter参与了一些公平的项目，并且我总是大力推广使用通用小部件/演员的子类化到更具体的小部件。

按照惯例，您可以为每个类创建一个新文件，因此，如果您将与窗口小部件关联的行为和状态机制引入子类，则会将该代码拉入单独的文件中。 这有助于更轻松地构建代码，并在其他人想要访问并阅读时提供帮助。

子类化策略还可以帮助您将封装强制实施为代码库的良好实践。 如果您的小部件及其关联的状态和逻辑被很好地封装，那么这可以帮助重用。

使用这种子类策略的项目的一个很好的例子是任务，特别是它的内部帮助库： http ： //git.gnome.org/browse/tasks/tree/libkoto这意味着当我们想要移植时应用到新平台或提供关于数据的不同视图，将现有小部件和树模型以不同方式粘合在一起非常容易。

如果您想使用C并且您发现子类化有点乏味，那么您可以尝试使用此工具： http ： //git.gnome.org/browse/turbine/以帮助自动创建子类。

Answer 2

当你需要为窗口小部件保存一些状态时，我会使用定义新类的准则。 否则，您将最终创建保持该状态的自定义结构作为用户数据传递给信号处理程序，从而使您的代码更加复杂并为内存泄漏创造更多机会。

这表明，对于您的第二个用例，应用程序窗口，您应该始终定义一个新类。

这样做的一个原因是你的小部件可能开始很简单，你可以用信号处理程序完全实现的行为，但后来可能会变得更复杂。 例如，假设您要将后备存储添加到绘图区域。 将简单小部件重构为类的“感知成本”很高，但它会使您的代码比处理它更清晰。

另一个优点是类可以具有属性。 您可以将这些属性绑定到其他类的属性或GSettings键，这是一个非常强大的机制，可以使您的代码非常简单。

如果您不喜欢所有类样板，请考虑在Vala中编程。