| |
| http://www.liquidx.net/pytagger/pytagger is a ID3 tag reader and writer implemented purely in Python. It supports all the current ID3 tag implementations including ID3v1, ID3v1.1, ID3v2.2, ID3v2.3 and ID3v2.4. | |
|
| http://www.sagehill.net/docbookxsl/FOprocessors.htmlXSL-FO processors are really typesetting engines. An XSL-FO file is a mixture of text from your XML source document and XSL-FO tags that suggest how the text should be formatted. It is the XSL-FO processor that actually creates the typeset lines of text and lays them out on pages. An XSL-FO processor typically generates a PDF or PostScript file which can be fed to a printer to produce hardcopy output. ( Read more... ) | |
|
| 可爱 bbbush要找的小东西 memprof - Memory profiler and leak detector valgrind - A memory debugger and profiler python-profiler - deterministic profiling of any Python programs electric-fence - A malloc(3) debugger lam-runtime - LAM runtime environment for executing parallel programs memprof - Memory profiler and leak detector Memprof is a tool for profiling memory usage and detecting memory leaks. It can be used with existing binaries without need for recompilation. ( Read more... ) | |
|
| 从 vex 里搞到的,这就可以直接用 html 浏览器查看 docbook 了, 但是 html 编辑器编辑呢? 大概直接替换对应的 html 标签足够了, 连 xhtml 解析都省掉。 ( css 代码 ) | |
|
| http://freshmeat.net/articles/view/928/This article is aimed at Unix developers who already have some experience with programming languages and want to start developing GUI applications (mainly for The X Window System, though portability is discussed). It may also come in handy if you have used a particular GUI toolkit for some time and want to know whether others might suit your needs better. The main focus is comparison and introduction, but it serves as a bit of tutorial, as well. ( Read more... )gtkmm FAQ http://www.gtkmm.org/docs/gtkmm-2.4/docs/FAQ/html/index.html | |
|
| http://www.bitsun.com/documents/gittutor cn.htm
( Read more... ) | |
|
| http://www-128.ibm.com/developerworks/cn/linux/l-k26initrd/index.htmlLinux 的 initrd 技术是一个非常普遍使用的机制,linux2.6 内核的 initrd 的文件格式由原来的文件系统镜像文件转变成了 cpio 格式,变化不仅反映在文件格式上, linux 内核对这两种格式的 initrd 的处理有着截然的不同。本文首先介绍了什么是 initrd 技术,然后分别介绍了 Linux2.4 内核和 2.6 内核的 initrd 的处理流程。最后通过对 Linux2.6 内核的 initrd 处理部分代码的分析,使读者可以对 initrd 技术有一个全面的认识。为了更好的阅读本文,要求读者对 Linux 的 VFS 以及 initrd 有一个初步的了解。 cpio-initrd 的处理流程1. boot loader 把内核以及 initrd 文件加载到内存的特定位置。 2. 内核判断initrd的文件格式,如果是cpio格式。 3. 将initrd的内容释放到rootfs中。 4. 执行initrd中的/init文件,执行到这一点,内核的工作全部结束,完全交给/i nit文件处理。 cpio-initrd的制作#假设当前目录位于准备好的initrd文件系统的根目录下 bash# find . | cpio -c -o > ../initrd.img bash# gzip ../initrd.img | |
|
| This stylesheet converts OpenDocument text files to XHTML. vnd.oasis.opendocument.text.xsl ( Read more... ) | |
|
| http://www.javaworld.com.tw/roller/page/qing?entry=2006_4_18_Google_Programminghttp://www.javaworld.com.tw/roller/trackback/qing/Weblog/2006_4_18_Google_ProgrammingGoogle時代的程式撰寫 最近愈来愈觉得网路时代的程式撰写工作变得极端的快速多了。原先想将这个题目订为「网 路时代的程式撰写」,但稍加想想,似乎少了Google这个威力无穷的搜寻引擎,这样 子的速 度提升又办不到,故以此题为名。 Google时代的程式撰写,在那些面向上能带来速度的提升呢?首先是学习的速度的提 升。过 去我们接触新的程式撰写知识,除了同侪之间的交流外,最主要的途径还是透过书籍或是杂 志。可能遇到的问题是,不知道是否能找到自己所关心主题的书籍或杂志;找到相关的主题 后,不知道是否能找到自己所需的项目。有了网路的存在,发表的型式变得极端简化,无数 的论坛或个人的blog,充满著和各种主题相关的文章,而透过Google的搜寻,可 以轻易又准 确的搜寻到这些散落在世界各地的文章。此外,专门的教学网站也提供各种不同的教学文章 与范例程式,都大大的助益了新的技术的学习。例如我常造访的 http://www.codeproject.com就是一个很好的例子。 再来是错误排除的速度也大大的提升了。最简单的错误形式就是compiler error message, 像Microsoft的IDE时常会给出一些令人难以理解的compiler error message。而我最常使用 的解决方法,就是把message直接复制丢给Google,通常在前一两个页面,就 会得到自己想要的解答,因为世界如此之大,你会犯下的错误,通常在世界各地的论坛上,往 往就会出现解 决该问题的答案。除了compiler error之外,程式或程式库所得到的各种错误代码或错误情 况,直接丢给Google,通常也都会有令人满意的结果。相较起来,在过去一个简单的 错误, 很有可能阻碍程式撰写十分漫长的时间,在这个过程中,可能充斥著不断的错误尝试、遍览 群书或偏询同侪而不可得等等的活动。提升错误排除的时间,自然大大的加快了程式撰写的 脚步。而类似MSN Messenger之类通讯软体的普及,与朋友或伙伴之间建立绵密的人际沟通网络,彼 此交换心得或询问错误排除方法的速度也变快许多。 除了文章的取得变得多样化又快速之外,另一个很大的型态转变,是基于开放原始码的精神 普遍而生的。由于原始码开放的程度日益普及,网路上散布著解决各种问题的原始码。但除 了介面定义良好的原始码程式库之外,即使是以开放的型式存在,能直接重复利用的程度并 不高。但经过适当的拆解与重组,这类的程式码还是可堪重用。于是,程式员开发的型态, 就起了很大的转变。在过去,程式员可能大量的自己重新撰写所有自己所需要的程式码,顶 多倚靠自己或团体中已经建构良善的程式库。但是现在,以随手可得的程式码为基础,许多 心力都可以节省下来,但程式员需要的技能却改变了!在过去,也许程式员不需要太多读懂 程式码,拆解程式码的能力,但在现在,一名具备良好追踪原始程式码、拆解原始程式码能 力的程式员,却极有可能在撰写速度上胜过撰写程式码能力相同的程式员。 在过去,对程式员的训练也许不甚重视追踪原始码以及拆解原始码。大家重视的是如何撰写 可读性高的程式,以及设计出具弹性、重用性高的程式。但在开放原始码的世界中,有太多 的程式不仅可读性低,而且不具弹性、重用性也不高―往往只是为了专门的需要而hack。如 果具备了追踪程式码的能力,除了可以透过现成的程式码学习新的技术之外,也可以做为拆 解 程式码的基础设施。而要拆解程式码的第一步,自然是看懂程式码,看懂之外,要进一步判 断那些是自己要的,那些不是,同时评估怎么调整这些程式码的架构,可以去除掉自己不要 的部份,保留自己要的部份,又毋需对现有程式码做过大幅度的更动。 具备了上述的两项能力,程式撰写就不再只像是重新建构,或适度组装自己已有的元件。而 像是找寻和自己所需元件相像的元件,经过适当的理解之后,施以最小幅度的裁切,将其介 面修缮成自己所需的介面,淘汰掉其内容中多余的组成,最后将重新赋予生命的元件与其他 无论是自己既有的,或是同样回收自开放原始码元件的元件组装在一块,就得到自己想要的 东西。 重新思考这整个过程,倘若没有开放原始码的帮助,程式员得先花上一段时间学习新技术, 然后重新撰写全新的程式,但在这个时代一切可都不同了。 无论是追踪原始码或拆解程式码都需要特别的一套技巧。有时间我想分享一下。但我的确认 识一些人,有程式撰写的老手也有新手,彷佛都有这两项技巧的天份,这实在是一件很神奇 的事情。 | |
|
| [Huahua] [Huahua] hello Riddell [Huahua] may it write a kcontrol module in python [Riddell] hello Huahua [Riddell] Huahua: if you wish, see kde-guidance for how it’s done [_Sime] Huahua: There are even docs about how to write kcontrol modules. http://www.simonzone.com/software/pykdeextensions/en/index.html[Huahua] _Sime: thanks | |
|
| 用 fontforge 玩字体,搞的 Attempt to allocate memory failed 了 hua@vgh:1$ nice -n 10 fontforge WenQuanYi\ Bitmap\ Song48.sfd Attempt to allocate memory failed. 已放弃 hua@vgh:1$ ll 总计 51M -rw-r--r-- 1 hua hua 5.3M 2006-02-24 11:19 wenquanyi_12pt.bdf -rw-r--r-- 1 hua hua 35M 2006-02-24 20:40 wenquanyi_48pt.bdf -rw-r--r-- 1 hua hua 11M 2006-02-24 22:08 WenQuanYi Bitmap Song48.sfd hua@vgh:1$ 幸好有 autosave hua@vgh:1$ nice -n 16 fontforge Copyright (c) 2000-2005 by George Williams. Executable based on sources from 12:08 5-Dec-2005. Recovering from /home/hua/.FontForge/autosave/auto002b60-1.a sfd... Done hua@vgh:1$ hua@vgh:1$ ll 总计 92M -rw-r--r-- 1 hua hua 5.3M 2006-02-24 11:19 wenquanyi_12pt.bdf -rw-r--r-- 1 hua hua 35M 2006-02-24 20:40 wenquanyi_48pt.bdf -rw-r--r-- 1 hua hua 41M 2006-02-25 11:11 WenQuanYi Bitmap Song48.sfd -rw-r--r-- 1 hua hua 11M 2006-02-24 22:08 WenQuanYi Bitmap Song48.sfd~ hua@vgh:1$
附:使用fontforge进行矢量汉字制作的说明 http://wenq.org/index.cgi?fontforge_GBK | |
|
| http://sourceforge.net/mailarchive/forum.php?forum_id=39351&max_rows=25&style=nested&viewmonth=200501
From: George Williams <gww@si...>lcom.com>
Re: convert BDF to TTF
2005-01-07 06:46
On Fri, 2005-01-07 at 03:03, Atom “Smasher” wrote:
> i“m trying to convert a BDF font to TTF and i”m not having any success. is
> there a how-to for this?
It depends on what you want to do, your question isn“t specific enough.
Do you want a bitmap only ttf file? (only supported by Apple & Linux)
Open the BDF file
File->Generate Fonts
Select ”No Outline Font“ (should already be selected)
Select either ”sbits only (dfont)“ or ”OpenType Bitmap“
[Save]
Do you want to convert a bitmap font into outlines? If so the quality
will be extremely poor unless you have a very large pointsize
Create a New font
File->Import
Format ”BDF“
[*] As Background
[Import]
Edit->Select All
Element->AutoTrace
File->Generate Fonts
You will need to download a copy of either autotrace or potrace to do
this.
I don”t really recommend this, it doesn“t work at all well on most
inputs.
From: KANOU Hiroki <kanou@kh...>dd.net>
Re: convert BDF to TTF
2005-01-08 19:21
> using auto trace on a BDF font gives me a remarkably ugly result. is there
> a quick way to trace the entire outline, and get a chunky pixelated font?
> or do i have to edit by hand?
Do you mean a font in which each pixel is converted into a square?
I suggest you to magnify your BDF before traced.
1) get ”bdfresize“ from
http://openlab.jp/efont/dist/tools/bdfresize/bdfresize-1.5.tar.gz
2) Apply this patch and compile (If SWIDTH is scaled, imported glyphs
will have wrong widths).
--- bdfresize-1.5/charresize.c.orig Tue Dec 12 20:18:14 2000
+++ bdfresize-1.5/charresize.c Sun Jan 9 11:50:14 2005
@@ -118,7 +118,11 @@
}
+#if 0
newwx = WRESIZE(arg1);
newwy = HRESIZE(arg2);
sprintf(linebuf, ”SWIDTH %d %d“, newwx, newwy);
+#else
+ sprintf(linebuf, ”SWIDTH %d %d“, arg1, arg2);
+endif
put_line();
}
3) Scale your BDF to 400% or larger. For example, to scale ”8x16.bdf“,
type ”bdfresize -b 1 -f 4 8x16.bdf > 32x64.bdf“
(”-f“ is scale factor and ”-b 1“ is needed to keep pixels square).
4) My description is for potrace because I prefer it.
If you try to use autotrace, consult with your manual for an
appropriate command line.
4-1) Install potrace.
4-2) Create a new font with ”fontforge -new“.
4-3) Open File->Preferences dialog and select [Apps] Tab.
Select ”PreferPotrace <*> On < > Off“.
Set AutotraceArgs as ”-z white -a -1“
(this will split diagonal pixels and suppress conversion
from polygons to curves).
[Ok].
5) Open ”File“->”Import“ dialog and import the magnified BDF
as background.
6) Select All glyphs with Ctrl-A and trace with Ctrl-Shift-T
(”Element“->”Autotrace“).
7) You will want to remove redundant midpoints with Ctrl-Shift-M
(”Element“->”Simplify“->”Simplify“).
8) ”Edit“->”Clear Background“ and save your SFD file.
| |
|
| zh2utf8.py 这个 python 模块会检测字符编码,统一转换为 utf8 或 unicode 字符串
#!/usr/bin/python
# -*- coding: UTF-8 -*-
# -- zh2utf8.py ---
# Author: Huang Jiahua <jhuangjiahua@gmail.com>
# Last modified: ?
# LGPL
"""Auto converter encodings to utf8
It will test utf8,gbk,big5,jp,kr to converter"""
#测试的编码类型
encc=‘’
def zh2utf8(stri):
"""Auto converter encodings to utf8
read string , return utf8str
It will test utf8,gbk,big5,jp,kr to converter"""
global encc
for c in (‘utf-8’, ‘gbk’, ‘big5’, ‘jp’, ‘euc_kr’,‘utf16’,‘utf32’):
encc = c
try:
return stri.decode(c).encode(‘utf8’)
except:
pass
encc = ‘unk’
return stri
def zh2unicode(stri):
"""Auto converter encodings to unicode
read string , return unicode str
It will test utf8,gbk,big5,jp,kr to converter"""
global encc
for c in (‘utf-8’, ‘gbk’, ‘big5’, ‘jp’, ‘euc_kr’,‘utf16’,‘utf32’):
encc = c
try:
return stri.decode(c)
except:
pass
encc = ‘unk’
return stri
if __name__==”__main__“:
# 命令行测试
import sys
## sys.setappdefaultencoding(‘unicode’)
if len(sys.argv) > 1:
stri = sys.argv[1]
else:
stri = sys.stdin.read()
## print zh2utf8(stri).encode(‘utf8’)
print zh2utf8(stri)
print ‘encc:’,encc
| |
|
| http://glc.sourceforge.net/下载 http://www.serve.com/ballen/glc/glc.py不过这个相当旧了,只能 Gtk1.X 而且一般也推荐用 libglade
Glade Python Code Generator
Abstract
|
Python is proving to be a popular scripting language for implementing system functions for the linux operating system. GTK is the toolkit used by the Gimp and a number of other programs including GNOME. Glade is a GUI builder that allows for rapid GUI prototyping for GTK. James Henstridge has produced python bindings for GTK as well as a runtime library for glade xml files. The python code generator is a compile time approach to the same end. It parses a glade xml file and produces runnable python code that uses the python bindings for GTK. This code is freely distributed under the GPL.
|
Usage
|
python glc.py test.glade test.py
Takes test.glade as an input file and produces test.py as an output. Additionally, if signals are defined it will produce a file named by concatenating the name of the top level widget and “Handlers.py”. Thus if the top level widget is window1, a file called “window1Handlers.py” will be produced if it does not already exist. As each handler is encountered, the handler file will be searched for a handler of the given name. If found, nothing more is done. Otherwise, if not found a function of the proper signature that does nothing will be produced. One can thus implement each signal handler in the handlers file. This implementation will never be overwritten. Click here for details on signal handling.
|
Requirements
|
More or less in the order given.
|
Notes on this implementation
|
- 0.2 3-Nov-1999
- Many new widgets are handled. Many new glade directives for the
handled widgets are handled fully. Has been field tested by a number of people.
- 0.1 30-Aug-1999
- Many widgets are not yet handled. I have been implementing them
on an as needed basis. Styles are not handled. I have yet to figure out how to create one using pygtk.
Bug reports, patches, and requests for new widgets will also be gladly accepted by Bill Allen (ballen@mail.serve.com).
|
Download
|
You can download the python glade code generator here.
|
Installation and testing.
|
The download is simply a python script. This can be placed anywhere on your system that you like to place python scripts. To test your installation, you can try the glade files found in the examples directory of the pygtk distribution. You will also find glade.py in that directory which uses James’ runtime approach.
For example,
python glc.py test.glade test.py
will produce test.py and window1Handlers.py. You can run the resulting files with
python test.py
window1Handlers.py should look like:
from gtk import mainquit
def mainfunc(window1Widget):
window1Widget.window1.connect(“delete_event”, mainquit)
def close_window(widget, mainObj):
pass
def on_hscale1_state_changed(widget, mainObj):
pass
Note that you may freely add code or edit any of the existing handlers. In subsequent runs the code generator will never overwrite or edit any existing code in the handlers file even if changes are made to the glade file. If you remove widgets you must hand remove the handlers from the handlers file, since the code generator won’t touch existing code.
|
| |
|
| ReSTWord 是一个所见所得的 ReST 文档编辑器 我先把她放在 pycds 的空间里 http://pycds.sourceforge.net/restword/ReSTWord is a WYSIWYG ReST Document Editor. ReST is Python documentation Utilities. The purpose of the Docutils project is to create a set of tools for processing plaintext documentation into useful formats, such as HTML, XML, and TeX. | |
|
| http://www.w3.org/TR/REC-CSS2/generate.html#before-after-content12.1 The :before and :after pseudo-elements Authors specify the style and location of generated content with the :before and :after pseudo-elements. As their names indicate, the :before and :after pseudo-elements specify the location of content before and after an element’s document tree content. The ‘content’ property, in conjunction with these pseudo-elements, specifies what is inserted. 类似
h1:before{
content: “h1”;
color: blue ;
font-size: 5px ;
}
看了 deepestsender 这个 写 LJ 的 firefox 扩展 在 ~/.mozilla/firefox/at04mvi1.default/exte nsions/{B9DAB69C-460E-4085-AE6C-F95B0D85 8581}/chrome/deepestsender.jar 里的 skin/classic/protocols/livejournal/livej ournal.css 里看到
.ljuser, .ljcomm {
font-weight: bold;
}
.ljuser:before {
content: url(chrome://deepestsender/skin/images/ljuser.png);
vertical-align: bottom;
border: 0px;
}
.ljcomm:before {
content: url(chrome://deepestsender/skin/images/ljcomm.png);
vertical-align:bottom;
border: 0px;
}
.DS_lj-cut_Title {
font-weight:bold;
text-decoration: underline;
color:#000000;
}
span.DS_lj-cut_Title {
cursor:pointer;
}
.dssmall {
width: 20px;
height: 20px;
margin-left: 5px;
margin-right: 5px;
} | |
|
| 在 mozilla/firefox 的 里建立一个 user.js 写上
pref("capability.policy.default.Clipboard.cutcopy", "allAccess"); pref("capability.policy.default.Clipboard.paste", "allAccess");
mozilla/firefox 就可以复制粘贴了
对 gtkmozembed 也一样
BTW: gtkmozembed 用 gtkmozembed.set_profile_path 设置 profile_path 如 gtkmozembed.set_profile_path("/home/hua/.restword/","gtkmoz")
表示目录 /home/hua/.restword/gtkmoz | |
|
| 让错的程式看得出错http://www.joelonsoftware.com/articles/Wrong.htmlhttp://chinesetrad.joelonsoftware.com/Articles/Wrong.html
好啦, 到目前为止我已经提到三种程式师的成就层级:
- 你不知道乾净和脏有什么分别.
- 你对乾净有粗浅的认知, 主要以是否符合编程规范为准.
- 你开始能嗅出藏在表面下不对劲的蛛丝马迹. 你会察觉这是问题并且找出来修正.
不过其实还有更高的层次, 而这也就是我真正要说的:
- 你有计划地架构程式码, 藉助能察觉问题的灵眼让程式码更正确.
我们现在回到恶名昭彰的匈牙利命名法. 匈牙利命名法是微软程式设计师Charles Simonyi发明的. Simonyi在微软做的主要计划是Word; 事实上他还主持了世界上第一 个所见即所得的文书处理器(在Xerox Parc名为Bravo计划). 在所见即所得的文书处理中会用到可卷动的视窗, 所以座标值有两种意义:相对于视窗或相对于处理页. 两种座标的差异很大, 所以好好安排是非常重要的. 我猜这正是Simonyi开始采用某些之后被称作匈牙利命名法的原因之一. 它看起来像匈牙利文, 而Simonyi是从匈牙利来, 所以 以匈牙利为名. 在Simonyi版本的匈牙利命名法中, 每个变数都会加一个小写的字首, 表示变数内容的种类. 我是故意用种类(kind)这个词, 因为Simonyi在他的文章中误用了型别(type), 结果好几世代的程式师都误解了他的意思. 如果你仔细读Simonyi的文章, 就会发现他所讲的和我之前范例所用的命名规范是一样的, 在我的范例中把us和s分别定义为不 安全字串和安全字串. 这两者的型别都是字串. 如果你把某种字串指派另一种, 编译器并不会给任何警告, Intellisense也不 会说些什么. 可是他们的语意是不同的; 他们解读和处理的方式都不同, 要把两种字串互相指派时还要某些转换函数做转换, 否则就会有执行时期的问题. 祝你好运. 微软内部称Simonyi对匈牙利命名法的原始概念为应用匈牙利命名法, 因为它用于应用程式部门, 也就是Word及Excel. 在Excel的原始程式码里有大量的rw和col, 你看到这些字首就知道它们指的是行(row)和列(column). 没错, 它们都是整数, 可是两者 间的转换完全没有意义. 有人告诉我说Word的程式码里有大量的xl和xw, xl代表相对于排版页面的水平座标, 而 xw则代表相对视窗的水平座标. 两者都是整数但却是不能互转的. 两个程式里都有很多cb, 意思是位元组的个数. 没错, 这也是整数型别, 不过光看变数名就可以得到更多资讯: 这是位元组的个数, 也就是缓冲区的大小. 另外如果你看到xl = cb就可以拉警报了. 这显然是错的程式, 虽然xl和cb都是整数, 可是把以像素为单位的水平位移设成位元组个数绝对是疯了. 在应用匈牙利命名法中字首可以用于函数和变数. 因此虽然我真的没看过Word的原始码, 我还是敢打赌Word里一定有个叫YlFromYw的函数, 可以把垂直方向的视窗座标转成垂直方向的排版页座标. 应用匈牙利命名法用TypeFromType取代传统的 TypeToType, 这样每个函数名就会以传回的型别开头, 这正与我稍早在范例中把Encode改名为SFromUs的作法相同. 事实上在正规的应用 匈牙利命名法中Encode函数一定要改名为SFromUs. 应用匈牙利命名法在该函数命名上并没有提供其他选择. 这其实是件好事, 因为你少一件事要背, 另外也不必担心Encode究竟是用什么型别. 程式也变得精确多了. 应用匈牙利命名法非常有用, 特别是当初C语言盛行, 而编译器尚未提供很有用的型别系统时. 不过接下来却出了一些问题. 黑暗世界占用了匈牙利命名法. 似乎没有人知道为什么或是如何发生的, 不过似乎是视窗团队中写文件的人不小心创造出后来名为系统匈牙利命名法的东西. 某处有人读了Simonyi的文章看到里面用了"型别"这个字眼, 因此认为作者指的就是型别, 意思就像是类别或是型别系统中, 或是编译器所做的型别检查. 其实不然. 作者很小心并精确的解释他用"型别"这个字的意义, 不过没有用. 伤害已经造成了. 应用匈牙利命名法的字首很有用而且有意义, "ix"表示阵列索引, "c"表示个数, "d"表示两个数字间的差(比如"dx"表示"宽度"), 如此类推. 系统匈牙利命名法的字首作用就差多了, "l"表示长整数, "ul"表示正长整数而"dw"代表双字组(呃, 事实上就是正长整数). 在系统匈牙利命名法中, 字首只能告诉你变数真正的资料型别. 这误解了Simonyi的意图和实作, 差异虽细微实质上却是完全不同. 这件事唯一的教训是让你知道, 如果你写出些没人能懂的艰深难解学术文章, 你的想法可能会一再被误解, 结果变得非常荒谬, 完全违背你的原意. 所以在系统匈牙利命名法中会出现大 量的dwFoo表示"双字组的某某", 可恶的是某个变数是双字组这件事对你几乎是完全没用的. 难怪大家都很讨厌系统匈牙利命名法. | |
|
| hua@vgh:charm-1.6.0$ cat ~/bin/abs-slot-qt-ui.sh #!/bin/sh # 提取 .ui 里的 slot 函数 # 二 1月 17 18:00:22 CST 2006 # 需要 xml2 工具
E="/UI/slots/slot="
if [ "$1" = '' ] ;then xml2 | grep $E | cut -d'=' -f2 exit 0 elif [ -f "$1" ] ;then xml2 < $1 | grep $E | cut -d'=' -f2 exit 0 else echo usage: abs-slot-qt-ui.sh [.ui FILE] exit 0 fi
hua@vgh:kid2$ abs-slot-qt-ui.sh form1.ui fileNew() fileLoad() fileDumpHtml() fileOpen() fileSave() fileSaveAs() filePrint() fileExit() editUndo() editRedo() editCut() editCopy() editPaste() editFind() helpIndex() helpContents() helpAbout() helpaboutQt()
| |
|
| 我喜欢用 glade-2 来设计 Gtk 程序界面 但是要记住 glade 里都用了哪些 handler 比较麻烦 干脆用个 shell script 来完成 hua@vgh:glade$ cat ~/bin/abs-handler-glade.sh #!/bin/sh
# 提取 .glade 里的 handler 列表
# Huang Jiahua <jhuangjiahua@gmail.com>
# 二 1月 17 18:00:22 CST 2006
# 需要 xml2 工具
if [ "$1" = '' ] ;then
xml2 | grep handler= | cut -d'=' -f2
exit 0
elif [ -f "$1" ] ;then
xml2 < $1 | grep handler= | cut -d'=' -f2
exit 0
else
echo usage: abs-handler-glade.sh [.glade FILE]
exit 0
fi
用到了 xml2 这个 xml/html 分析工具, xml2 真的很好用
xml - Convert between XML, HTML, CSV and a line-oriented format xml2 tools are used to convert XML, HTML and CSV to and from a line-oriented format more amenable to processing by classic Unix pipeline processing tools, like grep, sed, awk, cut, shell scripts, and so forth. | |
|
| 我在 google 新闻组也问了会 http://groups.google.com/group/python-cn/browse_thread/thread/a1e7f7a3e275854d/d82b51f9ec505034 但是我不想用跟标准 reStructuredText 太不兼容的扩展 现在考虑的是 把 LaTex 编译为图片来显示
- 在 gif/png 图片文件的 meta 里记录 LaTex 代码
让 restword 读取图片的meta 信息 好处:- 不用修改标准的 reStructuredText
- 图片跟 LaTex 标记绑定,不会弄混图片
坏处:- rst 里不带 LaTex 信息,不能用文本工具修改,只能在 restword 里编辑 LaTex
- 由于 LaTex 都在图片里, rst 文件必须跟 图片 一块放置
- 在 image 标记里用 alt="latex:LaTex 标记" 来记录 LaTex
好处:- 公式、分子式的 LaTex 标记都在 rst 里, 可以用其它文本编辑器直接编辑
- 可以不用附带图片
坏处:- LaTex 标记跟图片可能不一致
附图: 编辑 LaTex 和图片 ( 请用 Firefox 浏览): ![]() | |
|
| 在考虑我的编辑器的文件格式用 reStructuredText ( rst , 新结构化文档 ) 还是 docbook 最重要的都是跟 plainHtml 的转换 docbook 的章节可以换成 Html 的一个块,用嵌套的快来表示章节层次 而 rst 的章节标记可以用 HTML 的 <h1> <h2> - <h9> 来标记
看看哪种更舒服吧
另外要考虑插入图片的 src 的路径如何安排,标准的 docbook 和 reStructuredText 都不能像 html 那样嵌入 base64 的 date , 插入的图片必须用路径表示。 对于在硬盘上的文件, 可以直接用相对路径 。 但是刚新建,没有保存的文档里插入的图片如何呢?如果直接用绝对路径 (如 file://home/hua/pic/logo1.png ), 那么发布后就会有麻烦。
刚才看了看 NVU 里的处理 , NVU 在新建的未保存文件里用绝对路径 , 保存后, 可以在图片属性里改为相对路径 。 用 NVU 的办法并不太合适。
最简单的应该是强制插入图片的时候要求用户先保存文件,然后就用相对路径 。但是这肯定不被用户接受的。
待会再看看 lyx 里如何……
lyx 里更加简单,对未保存的文件,当作是 lyx 的工作目录下的 如果图片目录当前目录下,就使用当前的相对路径;如果不在当前目录下, 就使用绝对路径。
我在 ~/ 即 /home/hua 下启动 lyx , 先插入图片 home/hua/scrothot/2005-05-19-170126_1024x768_scrot.png.jpg lyx 是把路径记录为scrothot/2005-05-19-170126_1024x768_scrot.png.jpg
再点新建文件 , 插入 图片 /data/date/goodies/friend/PiPi/IMG_0795.jpg lyx 把路径记录为 /data/date/goodies/friend/PiPi/IMG_0795.jpg | |
|
|