微波EDA网,见证研发工程师的成长!
首页 > 硬件设计 > 嵌入式设计 > 基于GTK+和X-window的GUI在嵌入式Linux中的应用

基于GTK+和X-window的GUI在嵌入式Linux中的应用

时间:04-05 来源:互联网 点击:

,使用面向对象的方法,来继承窗口Widgets的特性,作为子类也是一个有效的方法。

  三、GtkWindow

  GTK+总是假定一个窗口里面包含了另一个窗口,它们就是嵌套关系。但对于我们经常会碰到的有软键盘的应用时,就不完全正确了。软键盘虽然是属于一个窗口的,但却会超出那个窗口。所以为了突破这个假定,需要对GtkWindow增加一些特性,将软键盘处理成一种特殊的子窗口。

  软键盘所在的窗口,需要处理软键盘的按键事件,并将按键转发给软键盘工具条。当软键盘按下,软键盘的回调函数就被注册到原始窗口上,这样软键盘就会响应按键事件。在GtkWindow上增加接口,可以创建,响应按键。

  在小屏幕的嵌入系统中,可以将滚动条做得更简化些,去掉边框,使用单个滚动条。这些都更适合嵌入系统。

  字体管理系统

  在字体管理方面,要找到一个轻型的机制来在嵌入式系统显示各种字体,并不是那么简单,困难在于GTK+ 的大型的 Widget 风格与 X 系统的老式的字体管理机制的结合所引起的问题。

  前面提到的,主题引擎方式的GTK+ 是用来控制窗口的样式与外观的。在一个窗口显示之前,它会得到一个式样对象,GtkStyle,它可以是一个指向父窗口的式样对象指针,或者是一个新的类型,这些式样对象将被应用到这个窗口及它的子窗口。这个式样由缺省值、rc 文本文件、应用来确定。

 要改变一个窗口的字体,你必须克隆窗口的式样,并使用X字体加载一个新的字体,类似adobe-helvetica-bold-r-normal--12-*-*-*-p-*-iso8859-1。

  但实际中会有些问题,GtkStyle是一个大的对象。如果一个屏幕上有很多种不同字体大小的多个窗口,每个都有一个唯一的GtkStyle对象,我们就会浪费大量的内存。到最后,X系统就不能支持类似字体的各种变化了。你甚至不能使X完成让某个字体变粗的操作,因为X系统是将不同外型的字体作为不同的字体的。X系统是假定你会硬编码一个希望的字体或者分析出一个字体名,改变字体及验证结果都将在字体服务器上。

  还可以使用一个更好的方法来完善字体管理系统,即包装GtkStyle,这样开发者就可以通过属性来获得一个窗口的字体,这比直接使用 X 系统字体的名字要更灵活。比如要显示一个比基本字体要大一号,并且是黑体字就可以调用:

gtk_widget_set_FONT_bold (widget, TRUE);
gtk_widget_set_FONT_enlarge (widget, 1);

  这是通过在 GtkWidget 结构中加入一个 GdkFont * FONT 来实现的,GtkWidget 是所有窗口类的父类。如果设置widget->FONT 那么就使用它,否则就使用widget->style->FONT。

  窗口管理

  在嵌入系统GUI中,还需要建立一个窗口管理器。我们可以选择一个开放代码的,轻量级的X管理器,Aewm。在嵌入系统中,我们会将最上层的窗口设置为获得焦点,并且只有对话框能移动,能显示其标题栏。

  窗口管理器是一个交互端,它可以管理内部与外部的应用程序的窗口。每一个应用程序的窗口,都会建立一个 socket 连接,并取一个名字。一个应用可以把请求将自己放在窗口堆栈的最下面,或者将一个命名的应用往上移。如果一个对话框要在最上层的窗口上打开,那么窗口管理器就将告诉这个最上层的窗口它将不再获得焦点,而新对话框将获得焦点。

  整体尺寸大小

  经过一系列的改进后,我们就得到了一个稳定的,功能和性能都能满足嵌入系统要求的GUI了。在ARM系统下,得到的尺寸大小为:

  其中 GTK+ 里面仍然还有不需要的代码,可以将其再去除。如果再简化一下的话,GTK+ 可以做到850KB,总体大小可以到 2.8M。

  运行性能

  将修改过的 GUI 运行在一个 ARM7 的系统上,CPU 为 100MHZ,运行时的效果还不错,窗口响应用户操作的速度很迅速,新的画面创建与显示的速度都能接受。

 但是,启动时的时间却有些问题,比较慢。在这个 CPU 上,应用程序画面加载与显示的时间需要 2.4秒,其中 1.5 秒是花在了建立与显示 UI 上。

在较慢的 CPU 上,这样的启动速度是 GTK+ 运行在 X,X 再写到 framebuffer 上导致的。我们需要分析具体的瓶颈在什么地方。在深入的调试中,当使用PC机来运行我们的应用,而在ARM设备上显示时,初始化和显示的时间几乎可以忽略不计。同样,将应用运行在ARM设备上,而在PC机上显示时,性能也很好。所以数据包的传输,framebuffer上的显示及GTK+的运算速度都不是问题所在。速度慢的原因可能是这几个因素的先后顺序引起的。而且内存的占用上也存在问题。在初始阶段,GTK+构造了大量的对象,GTK+和X是使用共享内存来通讯的,X写到framebuffer,framebuffer也是不变地写到显存上。这些都是发生在一个较窄总线

Copyright © 2017-2020 微波EDA网 版权所有

网站地图

Top