Blue Blazer

Achieve perfection by constant effort and creative will.
Code every day, no matter what...

One man fight

从www.reddit.com转载而来:) 受到了鼓舞

There are many successful one man software projects. I can think of many - you don't have to look very far. For example, Resourcer was made by one guy: Doug McKenna. I believe the game Glider Pro was written by one guy. Woz wrote the BASIC interpreter for the Apple I. I've done one person projects myself to deliver application software before many times.

My advice is that you don't just demand more people. Get their requirements and make a realistic plan of how you can complete the project by yourself. By "get their requirements" you need to have a good understanding of not only what the software needs to do, but what an acceptable solution might look like. Is it OK to use open source third party libraries in your solution? Whether they will allow this will make a big difference in how long it will take.

Come up with at least a high level design for the software/system. Decompose it into parts. Identify those parts that you know how to write and those where you are going to have to gain additional expertise. Make an estimate as to how long it will take to make each part. At this stage, your estimate should consist of two numbers. The earliest you think it could be finished if everything goes right and the latest it could be finished in the 90% worst case scenario. For parts of the project you know well, your estimates will be a little tighter. For parts of the project that you don't know well, your estimates will have to be looser. Budget time to get up to speed with any technology you don't know. Be a little generous with yourself here. If you do the project by yourself, it is actually a blessing because you will gain new skills by working in areas outside your normal expertise.

Make a list of any things you might need to buy in order to do the project. This could be computers, other equipment, software libraries, tools, etc. You might want to shop around for third party libraries to solve some of your problems. For example, let's say you decided to use XML in your project, you might need to shop around for an XML parser. Make sure it meets your technical AND business requirements. For example, can you use LGPL stuff in your project? How about GPL? If you go commercial - do you have the budget? Does the vendor require a royalty? These are just some of the questions.

Next, plan a proposed team that could complete the project. Your company might prefer to use contractors for this if they do not want the burden of additional full time employees. You probably will need at least one test engineer. This person could be a contractor. Speaking of quality, you need to understand their quality requirements. This will probably be driven by who the customer is and how critical the system is. If your bosses are non-technical, be prepared to answer why betty the office manager can't do your testing or why the users can't just test the system when it is deployed. Explain that while both of these things might have some value, those ideas basically mean that you are testing the software yourself which has risks because programmers tend to get myopic and have a difficult time testing their own code.

You need to have a plan for deploying the solution. If it replaces an existing solution, then the deployment plan will be more complex.

Then when you propose it to your bosses, lay out the various scenarios. One where you do everything yourself, then another where maybe it is just you and a test engineer, and then maybe a third solution where you bring in some additional developer(s) who have specific skillsets that complement yours. Explain to them that the benefit of this third solution is that they don't have to pay you to learn technology X where X is important for a specific reason and you don't know X already. If you want to do a great job, you could estimate the costs of each of these solutions for them.

Also, keep your team as small as possible. If you are hiring developers, make sure they pass a code test. An easy way to do this is to setup a clean machine with just the development environment, pick a topic like Poker and give your candidate a printout of the rules, and ask him to write a program to sort poker hands. It doesn't have to be poker - it could be anything like that. This is the simplest way I know not to hire a complete bozo. Be aware that you might have to interview ten people to find one that is not a bozo. Having a degree - even a PhD - or having worked for a big name company does not mean they know how to program.


庆祝中期考试结束,今天给Ark加入了lzma支持 :)


kdelibs (KXzFilter), kdebase, ark...

.xz, .lzma, .tar.lzma

tar cfa aabb.tar.lzma abcde/

测试了一下,压缩时间、解压时间、压缩率都优于gz、bzip2,缺点是内存占用很吓人,大一点的文件一般都占用几百MB内存,我压kernel src时候居然要占用650多MB,看了一下代码发现他的最大内存占用阀值=所有内存/3

Ribbon UI , Korat UI

Hello, i've hesitated to put this blog post on KDE, afraid being told this is a crazy idea.Finally i'm open for challenges, at least this post shows an idea.

Plasma is maturing, more widgets have been added. As a result it enables some other possiblites.

Recently i've seen the beauty of Ribbon UI in Office 14 and Windows 7.
And googling the Ribbon UI on Linux, found two implementations:
GTK# version in Mono:

It seems to be (maybe intended to be) 1-1 copy of M$'s Ribbon UI, where's their creativities?

Vtk designer's menustrip:

Looks OK ,and that's all. It's just bigger icons on a bar.....

Not satisfied with the above two, i'm writing my own:

My Korat::MenuBar's Features:

  • Adaptive layout according to width (use own greedy relaxing algorithm), similar to M$'s Ribbon UI.
  • Users are very easy to wrap their graphics widgets to be adaptive layoutable. You just need to provide only three other functions (typedef QList WeightList;):
    • QList availableWidths();
    • qreal getWidth(const WeightList &);
    • void adjustWidth(const WeightList &);
  • Use plasma extensively: theme, palette, Plasma::IconWidget, Plasma::LineEdit etc....,
Pics comming....



Too narrow, scroll button appears:

Also i'm thinking of bringing more powers and beauties of plasma and graphics model/view to normal widget based application, so i start a Korat UI project(plan):

Its goal is to provide a normal QWidget - Korat::MainWindow,
which correctly provide a view on a QGraphicsWidget - Korat::MainWindowGraphics

Feature plan of Korat::MainWindow:
  1. Fully QGraphicsWidget based, goes deeper on the way that Plasma::Dialog do, correctly manage the layout for you (handle spacing, margins, theme change etc...), It's auto themed according to your plasma theme, provide animated layout(Kinetic ?), and other animation effects.
  2. Integrate KRunner into the main window. Application and its plugins can provide its own krunner plugin, the main window manage/merge them, To quickly search this application's actions, help info, quickly tag the document etc... anything that krunner can do. (You can see from my above pics, there's a filter button and a lineedit besides the tabbar, that's it).
  3. Ribbon like menubar as i mentioned above, but merge the application and its plugins' sub actions( maybe need to extend kde's xml gui somehow )
  4. Provide optional Drawers on four corners of central graphics widget, optional Docks on four edges of central graphics widget. Manage their position,size,layout to ease your programming .
  5. A statusbar(notification area) on bottom.

The Korat::MainWindow's base architecture is done and the Ribbon like Menubar is nearly finished (some scrolling bugs not fixed yet).

Future plan:
  1. brainstorm and implement the Drawer, Dock, StatusBar.
  2. Port(hack) my own version of KJots to use this UI, since it's one of my favourite KDE application, so it deserves to have a beautiful and easy to use GUI.
  3. Experiment XML Gui support.
Source code under trunk/playground/base/plasma/widgets/koratbar

Thanks for reading, finally a pic for "korat“ , kudos for plasma developers.

Portable Meta-Information again...

Sth. about Portable Meta-Information storage with File Forks/Resource Forks.

Portable meta-information has been discussed twice recently on planetkde:

Portable meta information can be thought as File's meta information is not stored centrally (they may still be indexed in a central database to optimize query).

It introduces some benefits:

1. You can transfer the files around without loose the meta informations, I only concern move files locally now.

2. When you re-install your system or your central database broken, as long as your files are still there, their meta information aren't lost.

3. Everything is file, as long as we standardlize the file format, apps/libraries needn't to learn nepomuk query, manipulate database to perform basic meta info operation (like backup, remove etc....)

My thought is realistic:
1. Will nepomuk really be more usable with portable/distributed stored meta information ?
I don't know much of nepomuk's server implementations, afaik it seems use a central database to index/store these information, so I've a question to ask : when user move his file to another local folder, will the file's meta information get lost , updated later(next time to index) or updated instantly (use inotify )? The first result(lost) is totally un acceptable, the second is OK, but nepomuk's value/power will be limited, the third is good, just stick to central storage.

2. How to implement it ?
someone has suggested to use side-car file, other suggested xattr.
There is a seems better way to implement it : file forks/resource forks (not process fork),
It's invented by Apple , store text file's encoding, applications' icon ...

Apple's HFS, and the original Apple Macintosh file system MFS, were designed to allow a file to have a resource fork to store metadata that would be used by the system's graphical user interface (GUI), such as a file's icon to be used by the Finder or the menus and dialog boxes associated with an application.

It tightly bonded/embed to a file unlike side-car file, but also bypass the size limit of xattrs(Extended File Attributes), the size limit is the largest file you can create, and you can also assign serveral meta info file to one file.
This is a practise proof method,but only modern filesystem support it:
Only Apple's HFS, Microsoft's NTFS, Solaris's ZFS has full support.

And extensively used by Apple(store all sorts of metadata) and Microsoft(store its system backup related infomation, security control info).

Something need to mention, that Mac OS X's unix command line utilities (cp, mv, ....) can handle file with resource/file forks correctly. And Microsoft name it alternate data stream (ADS).

You can refer their dev docs to see how they design the api.

Oops the main linux file system, ext2/3/4, XFS, JFS... doesn't support it well.

3. Is it possible/hard to implement it under linux ? (you can skip the following paragraphs if you're not interested in implementing such things in kernel)

In my personal opinion, not hard indeed, i want :) and asume it to be implemented in VFS level (so all sorts of filesystem beneath this level gain support).
The simplest way is to add a "dentry" to each "general inode", that from the filesystem's view(not user visible), a regular file can be associated with a "directory" too, all metadata files resides under that "directory".
like this:
/home/xx/xxx/a.jpeg ----> nepomuk.xml



And make getfattr/setfattr related system call to lookup that dentry too, this method also remains backward compatible with xattrs (Extended file attributes), but remove the size limit put on them.

Or we can add new system call like getfmeta/setfmeta ....

Of course, we need more analysis/profiling to say sth. on the memory/time performance.
:) Just make a predication, the extra memory requirement it introduces(an extra "dentry" pointer) is affordable, and there's no/very subtle extra time needed by open/write ..regular system call, and it will be fast than create side-car files, since we needn't to create/open the side-car files from user space and pollute a directory with side-car file per data file, kernel handles it ..

Also need some security concerns.

Anyway, to implement portable meta information, i think we need support from underline library/filesystem/architecture.

4. This method's disadvantages:

a.We have no POSIX standard to define the API, and Apple's HFS, Microsoft's NTFS and Solaris's ZFS use different api for similar functionalities. We may need to abstract the api to make KDE cross platform.

b.No major filesystems under linux provide file forks / resources forks support now. Need to implement it or make feature requirement.

c.We can't directly associate a xml as a file's meta info, since xml is not an appendable format, data corruption may happens when we update this file's meta info while user eject the source disk, suddenly power goes off ,etc.......... These problems need to be solved if we want to support portable/distributed meta information.


Thanks for reading..


Amarok2 + XEmbed

感谢Sanfanling的IrcShow-X,So cool
把IrcShow-X通过XEmbed集成进了amarok2的Context View,
理论上可以将符合XEmbed规范的任意窗口(甚至Firefox, Openoffice)嵌入到Amarok2中去 :)

Amarok2中的Dolphin文件浏览器 :)


Gnome global menu in KDE4

Hello, i've implement gnome's global menu in Bespin's XBar.
Now xbar users can get global menu both for GTK and Qt4 applications.
Pics comming....
Gnome's Epiphany web browser:

KOffice2's Krita application:

kimpane applet, ask for review

I just dumplicate the mail and add some more pics :)
Moved to kdereview/plasma/applets/

It's mainly an applet for input methods, so that persons use difference input methods can share the same user interface and the unified systemsettings input method configure integration.
And also include a standalone application and a control module for systemsettings now.

Its main features:

  • Multiple backend support, currently support SCIM and IBus(1.1.0+ version)
  • Able to float out and embbed into panel dynamically, The floating statusbar(a qwidget) is just a view on the same qgraphicswidget.
  • Skin support:
    1. You can choose the skin to follow current plasma theme, then it will auto switch skin when user change plasma theme.
    2. Use custom theme, support install theme from Get Hot New Stuff
    3. Internally use javascript to layout svg, enable the abilities to do adaptive svg layout and "theme" the layout.
  • KCModule based configure, config pages for ui, backends are combined to one dialog.
  • Provide a standalone version with floating statusbar only if you don't want to add the applet to panel.

Its design is simple, just provide a dbus service for input methods
Backends(SCIM,IBus, fcitx ...) <-------->dbus<---------->kimpanel (org.kde.impanel)
communicate by signals only.

Currently the above features are finished, Except:
  • Only one kcmodule for ui now, haven't provide kcmodule for backend,
  • The kcmodule is working, but lack help text, theme auto preview , other eyecandies........
  • The extra two themes are only make for horizontal statusbar and horizontal candidate window layout only, but default theme fully working.
And it's also stable now, no crashes in my everyday use.

The backend need to be configured before test this applet, see backend/scim/README and backend/ibus/README
You can even mix use SCIM and IBus for different types of programs(eg. scim for qt, IBus for xim and gtk), but you still have the same user interface
and can't tell the difference without looking at their logo icon.

I'd like to include it in KDE 4.3 but it will be soft freeze is in early April,
So i think i have to ask for review now.

Pics comming

As my first post, first say hello to everyone :)

Want a fancy input method user interface?
Want to put it inside your panel ?

I'm currently writing a plasma applet for input method, which enables different input methods (scim etc..) to share same unified user interface under KDE.
Its main features are there and with a fully working scim backend.
Have a look at some pics:

  • Not a new input method, user interface only.
  • DBus-based, signal only backend<->user interface communicate
  • Svg themed, currently theme according to your plasma theme.
  • Layout to try to make the icon as large as possible under certain size.
  • Can expand/collapse from an applet to widget.
Its user interface is modern and highly integrated to KDE, which give you better user experience when typing text.
And it also break the situation which we only have gtk based input method now whose user interface is designed without concern KIG, KDE integration ...

The source code is under playground/base/plasma/applets/kimpanel
If you're a CJK person whom use input method a lot, have a try !


不少程序为了追求漂亮的外观都会实现它,如windows media player等软件。






int main(int argc, char *argv[]) {
bool argbVisual=false;
Display *dpy = XOpenDisplay(0); // 打开显示接口
if (!dpy) {
qWarning("Cannot connect to the X server");

int screen = DefaultScreen(dpy);
Colormap colormap = 0;
Visual *visual = 0;
int eventBase, errorBase;

if (XRenderQueryExtension(dpy, &eventBase, &errorBase)) {
int nvi;
XVisualInfo templ;
templ.screen = screen;
templ.depth = 32;
templ.c_class = TrueColor;
XVisualInfo *xvi = XGetVisualInfo(dpy, VisualScreenMask
VisualClassMask, &templ, &nvi);

for (int i = 0; i < style="color: rgb(255, 0, 0);"> XRenderPictFormat *format = XRenderFindVisualFormat(dpy,
if (format->type == PictTypeDirect && format->direct.alphaMask) {
visual = xvi[i].visual;
colormap = XCreateColormap(dpy, RootWindow(dpy, screen),
visual, AllocNone);
if (argbVisual == true) {
qWarning("Found ARGB visual. Starting app...");
else {
qWarning("Couldn't find ARGB visual... Exiting.");

QApplication app(dpy, argc, argv,
Qt::HANDLE(visual), Qt::HANDLE(colormap)); // 最关键的一行
return app.exec();


// 也可以用png,这里用的是svg格式背景
QSvgRender *render = new QSvgRenderer(QLatin1String("my_background.svg"));

void Widget::paintEvent(QPaintEvent *e)
QPainter p(this);
// QPainter使用混合扩展模式中的源覆盖模式,很重要!不然会得到白色背景
// 使用“透明”颜色来填充背景
p.fillRect(rect(), Qt::transparent);

//也可以不用一个QPixmap cache,直接在Widget上画,Qt有Backing store(类似于double buffer)来避免闪烁,使用cache好处是只需要在resizeEvent()那里更新cache就好了。
QPainter p(&cache);


p.drawPixmap(0, 0, cache);
if (iconShown) {
p.drawPixmap(20, 20, icon);







  • 支持透明,支持采用Svg来作皮肤。KDE4 下面根据当前桌面(Plasma)主题自动换皮肤、和文字配色方案。还能根据你是否启用桌面效果调整外观。
  • 图形界面和后端是分开的,将来支持ibus也是可以做到的。
  • 简洁小巧,图形界面程序只有68k大,scim后端支持程序只有176k大小。


Clean Blend主题下效果


emacs采用的是间隙缓冲区(Gap buffer),如: abcdI____efg I是光标,这样在光标处插入删除就变得很快速,缺点是当光标移动距离过大时需要移动大量数据。

Data Structures for Text Sequences
介绍了Piece Table方法,就是使用两个缓冲区,一个只读,一个只能做尾部附加操作。
不妨设编辑次数为 m , 文本长度为 n,插入操作的长度为p,来分析复杂度,容易得:
时间复杂度:从上次临近位置插入 O(1),随机位置插入O(m),删除时间复杂度同插入。获得某个位置字符O(m),获得长度为l的字符串O(m+l),遍历所有字符O(n)。

如果采用平衡树而不是链表来表示节点的话,固定位置,随机位置插入/删除时间复杂度变为O(log m),
获得某个位置字符O(log m),获得长度为l的字符串O(log (m) +l),遍历所有字符O(n),但是这样实现(撤销/重做等操作)耗费更多内存,实现起来麻烦,并且一般需要用户交互的文档编辑软件的编辑次数不会太多(用户经常就会存盘,也不可能连续几小时编辑)。





  • Qt/KDE 应用开发相关
  • Linux 应用相关
  • 最新最酷的东东的转载/翻译/评论
  • 政治,广告