TaggyTODO：工作模型（三） 任务分类

标题更新：Gotask正式更名为TaggyTODO。


我对任务分类的考虑相当简单，就一条：tag。每一个TaggyTODO中的任务都可以被打上一个或多个标记，比如“家庭事务”，“工作”，“重要”，“可以忽略”。每当定义一个新的任务时，用户可以选择打上对应的标记。在后来查询的时候我们就可以利用这些标记过滤出我们要的任务，比如“所有可以忽略的工作事务”，或“重要的家庭事务”。我知道很多管理程序都喜欢在tag之外再实现一个能包含层级关系的category概念用于分类，但我不打算这么干，因为我认为tag本身已经足够用于表示分类，至于层级关系，我认为可以用tag组合代替，不需要多此一举。

必须强调的是，我希望tag是必须先定义后使用的。这一点和通常意义上的tag不同。如今我见过的很多用tag这个概念的软件一般都是允许用户随意增减tag的，比如Blogger，每一篇文章都能随便加个标记，Blogger会记录所有用到过的标记，并只显示目前仍在被使用的。但是我认为随意定义tag的做法不适合管理任务，因为用户可能会定义一堆实际意义相同而叫法不同的标记，然后在最后定义query的时候发现自己顾此失彼，总是漏掉一两个任务。

我更期望一个tag应该是一个有限的集合。用户用之前就定义好，需要的时候从列表中选择。这样用户能更仔细地定义所有的tag，因此任务的标记信息可以更规范。除此之外，预先定义还有一个额外的好处：当用户发现某个tag名字不合理时不用一个个任务修正，只需要修改那个tag定义本身就可以了。——别忘了TaggyTODO的目标是用来管理大数量的长期任务，要求用户一个个修改任务可不是什么聪明主意。

最后，我不打算提供任务名称中关键字搜索的功能，也就是说，查询任务时tag是除时间之外唯一的搜索条件。我知道也许有人会认为这种做法太死板，特别是Outlook的用户，他们往往更习惯于在search框里输入标题中的关键字来查找。但我认为我的考虑更适合TaggyTODO，理由有两个：

• 概念单一不会使用户养成不同的使用习惯。假定我同时提供标题字符串搜索和tag，就可能出现两个用户一个习惯用tag而另一个习惯搜索标题的情况。如果他们两人共享任务列表，则合并后的task就无法满足任何一个人的需要。
• 基于tag查找的方法进行优化的方法简单。单纯字符串搜索就可能得动用索引结构之类的大家伙了。相比之下，我更希望我的软件能尽量小一点。

当然，TaggyTODO相对于邮件程序而言更容易实现分类规范化。因为所有的任务定义都是从用户这边来的。邮件程序必须使用字符串搜索的理由是用户收到的邮件来自四面八方，我们不可能要求所有联系人都用一样的规范写信。相比之下，都是自己定义的任务就不会有这个问题。

First Release: GoTask is renamed as TaggyTODO!

OK. So I finally pushed the first bunch of code for GoTask to Google Code. It's still incomplete, which can only run some basic unit tests, but I'll update in the new year. -- New year, new start, right? :)

Also, I finally found a name for the project: TaggyTODO. I have to change the name because I found the name GoTask has been used in another project, a library for Game development. Hope the name is not used again.

If you are interested in it, check it out from http://code.google.com/p/taggytodo.

ConsoleKit, access denied and a see-it-once bug

    I just noticed an interesting bug when I upgraded my ArchLinux last Sunday.  Every time when I log on my Openbox desktop, I found my NetworkManager applet icon cannot be shown on the system tray. When I invoke nm-applet from comman line, I got an error like below:

** (nm-applet:14122): WARNING **:   applet_dbus_manager_start_service(): 
Could not acquire the NetworkManagerUserSettings service.
  Message: 'Connection ":1.21" is not allowed to own the service 
"org.freedesktop.NetworkManagerUserSettings" due to security policies in the 
configuration file'

The most interesting thing is: the issue only happens *once*. When I log out and log in again, everything looks fine.

Obviously it's not a hardware issue. Since it only happens after upgrading, I decided to have a check on udev configuration files and finally got something new:

<policy at_console="true">
   <allow own="org.freedesktop.NetworkManagerUserSettings"/>
   <allow send_destination="org.freedesktop.NetworkManagerUserSettings"
     send_interface="org.freedesktop.NetworkManagerSettings"/>
   <allow send_destination="org.freedesktop.NetworkManagerUserSettings" send_interface="org.freedesktop.NetworkManagerSettings.Connection"/>
</policy>

This is new to me. I know that the traditional way is to use network group to define who can access network configuration. I also got some suggestions from *here* that I should add to make it back to old behavior.


But wait -- is it really the root cause? If that is the case, why it works when I log on twice?

After some studies I noticed that the settings above are used by ConsoleKit. Meanwhile, I also found that there should be a daemon, /usr/sbin/console-kit-daemon, which will assign an XDG_SESSION_COOKIE environment variable to every active logon session so it can determine who is using the current console. This is important for nm-applet to determine who should be assigned the access to read network settings.

Look -- the key is here. I didn't see XDG_SESSION_COOKIE environment variable when I log on system for the first time! However, I'm able to see the setting from the second logon. It seems the server was not there but was then invoked after first session, but NO DOCUMENT says that console-kit-daemon can be automatically started!

So the final fix is rather simple: I opened my /etc/rc.local file and added two lines:

#!/bin/bash
/usr/sbin/console-kit-daemon

That will force starting a console-kit-daemon service when system starts up. I rebooted the machine and everything works then.

Also, it just solve another see-it-once issue: my PCManFM file manager always give me an error when I'm trying to mount any USB flash disk, with a message like "send message rejected". This is also a see-it-once issue on my first logon session. After applying the fix (or workaround? Who knows) above, it also disappeared.

So my friend, if you are also experiencing the same issue, try that. Good luck.