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

Question

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

到目前为止,我遇到过两个例子:

自定义小部件

我正在创建一个新的小部件:基本上是一个GtkDrawingArea,我用它来显示一些数据.我原本假设实现这个的最好方法是继承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结构时,我创建了GtkWindow gtk_window_new(),并初始化小部件/布局/等,并连接信号.[我可能最终会在更复杂的情况下使用.ui文件,但是现在窗口很简单.]

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

---

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

Answer 1

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

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

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

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

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