并非是 screenlets 的错
screenets 是现在 linux 桌面最具可用性的一种类 widget/desklet 实现,最早接触它是在 feisty 的时候。
印象中似乎是从 screenlets 升级到 0.0.10 的时候,在我的机器上就突然不能用了,当时不以为意,以为是 screenlets 在更新过程中出了什么问题,就一直弃而不用,想着过阵子说不定自己就好了。
直到我的 gutsy 重新开启了 compiz fusion,有了类似 OSX 的单独的 F9 显示 widget 页的功能,这才决心折腾一下 screenlets,毕竟这东西还是有实用价值的。
直接安装使用的结果,竟然连自带的 clock 都无法启动。用 console 看输出,最有价值的是这条信息:
回头看了看 screenlets 的官方 FAQ,说 screenlet 本身依赖很多 python 的库,虽然官方文档中提到的库我一个不少,但是还是觉得有可能是这个问题。
apt-cache search python dateutil,还真有个库叫 python-dateutil。apt-get 之,问题解决。
看来这么久以来一直错怪了 screenlets,并非它本身有什么问题,而只是少了一个库而已。或许之后 screenlets 在打包的时候应该加上对 python-dateutil 的依赖,这样会更友好些。
印象中似乎是从 screenlets 升级到 0.0.10 的时候,在我的机器上就突然不能用了,当时不以为意,以为是 screenlets 在更新过程中出了什么问题,就一直弃而不用,想着过阵子说不定自己就好了。
直到我的 gutsy 重新开启了 compiz fusion,有了类似 OSX 的单独的 F9 显示 widget 页的功能,这才决心折腾一下 screenlets,毕竟这东西还是有实用价值的。
直接安装使用的结果,竟然连自带的 clock 都无法启动。用 console 看输出,最有价值的是这条信息:
No module named dateutil.tz
回头看了看 screenlets 的官方 FAQ,说 screenlet 本身依赖很多 python 的库,虽然官方文档中提到的库我一个不少,但是还是觉得有可能是这个问题。
apt-cache search python dateutil,还真有个库叫 python-dateutil。apt-get 之,问题解决。
看来这么久以来一直错怪了 screenlets,并非它本身有什么问题,而只是少了一个库而已。或许之后 screenlets 在打包的时候应该加上对 python-dateutil 的依赖,这样会更友好些。
评论