从前看见有的程序用到glade,看了一下,发现是靠xml文件来描述程序界面的方法,当时就觉得不错。
这两天看着学校的tunet越来越不爽,linux/BSD下只有命令行版本。虽然有个叫qtunet的,但是貌似从来没人更新,界面巨烂,功能也很有问题。于是想到在tunet的基础上,做个GUI。
结果就动手写起gtunet。正好试试gtk编程,和glade这个工具。
试下来glade真的非常方便,弄完界面,和函数挂钩,相当于原来的一个一个控件建出来再signal connect,省力许多。所谓"界面和程序逻辑分离",这个是第一步吧。
其实写了一半的时候,觉得用PyGTK或者其他脚本语言来写,或许更方便。毕竟要和一个命令行的程序对话,用C来写并不是很方便。而且,有什么问题,改一下就可以看见结果。但是,我一直对PyGTK之类的东西没有好感,本来Gtk并不大,却要装一大堆的binding。
后来写到一半,发现大概还非得用C不可。tunet其实有个地方比较ws,它为了不让密码显示在控制台,是直接打开/dev/tty,然后可能靠ioctl来禁止回显。既然没有用stdin,我本来用popen打开的方法也不能输入密码。然后我也只好打开/dev/tty,然后用TIOCSTI这个ioctl来模拟键盘输入了。如果用脚本的话,这个估计就麻烦了……
今天添加了一个线程,把获取程序输出并显示的部分扔到了一个线程里。然后麻烦的事情就出现了…… 我还想让记录自动滚动,然后写了一些东西,结果运行的时候,冒出来各种各样的错误…… 简直就是每次的错误都不一样…… 我的线程是用pthread建的,后来觉得问题就出在这个上面,改成了gtk自己的thread库。现在好像稳定了不少,但有时候还是会有问题……
tunet很NB,我killall掉tunet的话,连我gtunet这个父进程也会收到一个SIGTERM…… 太NB了……
现在,大致这个东西勉强能够用了,不过还有很多能够改进的地方~
其实,貌似Gtk用类绑定之后,用起来会方便不少。但是,貌似用gtkmm这个库(C++绑定的Gtk)的程序很少,如果用了,还要额外装…… 算了吧。
这两天看着学校的tunet越来越不爽,linux/BSD下只有命令行版本。虽然有个叫qtunet的,但是貌似从来没人更新,界面巨烂,功能也很有问题。于是想到在tunet的基础上,做个GUI。
结果就动手写起gtunet。正好试试gtk编程,和glade这个工具。
试下来glade真的非常方便,弄完界面,和函数挂钩,相当于原来的一个一个控件建出来再signal connect,省力许多。所谓"界面和程序逻辑分离",这个是第一步吧。
其实写了一半的时候,觉得用PyGTK或者其他脚本语言来写,或许更方便。毕竟要和一个命令行的程序对话,用C来写并不是很方便。而且,有什么问题,改一下就可以看见结果。但是,我一直对PyGTK之类的东西没有好感,本来Gtk并不大,却要装一大堆的binding。
后来写到一半,发现大概还非得用C不可。tunet其实有个地方比较ws,它为了不让密码显示在控制台,是直接打开/dev/tty,然后可能靠ioctl来禁止回显。既然没有用stdin,我本来用popen打开的方法也不能输入密码。然后我也只好打开/dev/tty,然后用TIOCSTI这个ioctl来模拟键盘输入了。如果用脚本的话,这个估计就麻烦了……
今天添加了一个线程,把获取程序输出并显示的部分扔到了一个线程里。然后麻烦的事情就出现了…… 我还想让记录自动滚动,然后写了一些东西,结果运行的时候,冒出来各种各样的错误…… 简直就是每次的错误都不一样…… 我的线程是用pthread建的,后来觉得问题就出在这个上面,改成了gtk自己的thread库。现在好像稳定了不少,但有时候还是会有问题……
tunet很NB,我killall掉tunet的话,连我gtunet这个父进程也会收到一个SIGTERM…… 太NB了……
现在,大致这个东西勉强能够用了,不过还有很多能够改进的地方~
其实,貌似Gtk用类绑定之后,用起来会方便不少。但是,貌似用gtkmm这个库(C++绑定的Gtk)的程序很少,如果用了,还要额外装…… 算了吧。