8月底到9月初的aKademy 2005 , KDE 碰头会，总得有个什么总结吧－－尽管3.5都还没出来，4.0的规划已经在进行中了－－KDE 4又会是一次根本的改变－－不论外观还是功能。

        目前不少进行中的工作涉及把已有代码移植到QT 4。同时，开发者将利用版本4引入和试验一些新概念，新应用－－就像 3 曾经扮演过的类似角色。KDE 团队希望版本 4 能再次提高桌面使用体验，激发起新一轮的第三方应用开发热潮。
       
        Appeal ，KDE对新方法和新概念的实践（用IE浏览有问题可以换用Firefox）。包括项目有Tenor，集成进桌面的关联搜索框架；Oxygen，下一代KDE图标主题；Plasma，KDE 4的桌面shell；Coolness ，充分压榨你的显卡－－反正你不压榨，Vista也会压榨，何苦让他们专美于前。
        Appeal的试验和探索性质十分明显－－目标也够雄伟。通过把艺术家，可用性专家，程序员和狂热的爱好者在软件开发初期就集合起来，他们希望能取得某种新的突破－－至少让Open Source不只是少数人的游戏，看看我们也能严肃地作出严肃的产品。
       
        Tenor，可以把Tenor看作GNOME 环境中的 Beagle  的表兄，不过他们的实现方法极有可能完全不同（目前看来，应该是的），定位也很 很大不同，Beagle和无数的Windows上桌面搜索产品没有本质差别，Tenor 的雄心则不比《华尔街》里的那个毛小子低。除了让用户更简单快捷地搜索文档之外，Tenor还有望成为开发者的助手，比如在程序之间通过Tenor传递数据。不过考虑到Appeal的特质和Tenor目前的开发方式嘛，很难预测到 KDE 4 发布的时候，我们会得到一个强力丑陋的弗兰肯斯坦还是美艳无边的克丽奥佩拉。
       
        与Tenor不一定“视觉可见”的成果比，Plasma 要受欢迎的多，即便不太了解技术的最终用户也会跟Plasma 打交道，能感受和评价它。整个桌面环境，从桌面，墙纸，图标，面板，小程序，都会随着Plasma 重新整合。即便将来 4 的桌面看上去和 3 会有相似指出，但是他们的功能，视觉效果会完全不同。像SuperKaramba 和 KHotNewStuff 这样的新技术的引用会带入点新鲜感觉。
       
        除了讨好一般用户外，开发者也是大头。KDE-Apps.org 上已经有很多应用了，不过来自独立软件供应商ISV的东西还是很少。要提高ISV对KDE的兴趣，措施之一是提供培训，比如10月份在 San Diego 召开的Open Source Development Workshops 就会向开发者提供KDE开发平台方面的培训。当然这并不是一把解决问题的方法－－很多公司即便采用QT，也会只编写纯QT程序，而不去/不会/不愿利用KDE已有的强大框架（不过这个从BUSINESS的角度倒也可以理解）。
        有老兄Martin Konold，他的主义是提供一个QT和KDE之间的兼容层，RuDI 。这样开发者便携的纯QT程序仍然可以利用KDE的一些强大功能。如果用户在KDE中运行该程序，那么由RuDI保证应用能利用KDE的特性，比如Tenor，以及网络透明的文件对话框。如果引用在没有KDE的环境下运行，那RuDI保证程序能无缝地回到纯QT的世界，只使用QT的功能。
        扩展一步，RuDI在Gtk，GNOME圈里也能派上用场，可以解决GNOME程序在KDE下外观都变成怪胎的问题，反之亦然，KDE程序也可以在GNOME里容颜不老－－我总能保证你继承所在的桌面环境的行为，不论你用什么语言编写。这样，RuDI就可能可以解决ISV关于平台依赖问题的担忧。

        来自KDE－－其实不光KDE，应该是大量的OpenSource社区－－的新想法总是激动人心，他们真的有不少好主意。
        版本4的任务仍然艰巨，Tenor 还是个表达模糊的概念，Plasma还在不断的讨论中，Coolness甚至还在摸索自己的远景目标，不过，大家注意到没有，他们在面对未来时的态度很有意思－－与其在预测中消耗，不如在渐进中创造。

        Via NewsForge

        
        大家都忙着搞什么 MacOS for X86 了，啧，啧，没啥意思，Jobs 搞定了Barrett和Otellini那一半儿，Apple的员工们搞定中间，编译器搞定剩下的，本质上所有工作在Apple那帮家伙那儿都包办得差不多了，咱再怎么折腾充其量也就是一爱好者－－无他，搞搞窍门或破解耳。
        反过来，在现有系统上做点出人意料的事情似乎更好玩，比如澳大利亚Mac社群网站AppleTalk上这篇Setting Up And Running Kde And Xfree86 With Fink  －－ 在Mac上运行KDE，对系统有深入了解和敢想能做的人才能发掘这样有意思的东西，这些家伙正好做到了Apple的广告所说的: Think Different。

        KDE和XFree86就不说了，Fink 是SourceForge上的项目，旨在把*nix上的OpenSource软件带入Mac的世界。这个包管理软件能为Mac用户下载并安装OpenSource软件。

        要在Mac上跑KDE，需要几样东西：
        一是能运行至少OSX 10.3的Mac（这不是废话嘛。。。），会使用终端，有最新的Apple Developer Tools，还有，不怕改机，有足够的时间和...咖啡。

        我没苹果机器，不能亲自验证尝试，就搬搬简要步骤好了：
        1。安装Fink－－好像是废话，这活儿Mac用户比我们在行。
        2。配置Fink。
           主要是设置Fink使用最新版本，不过也可能是unstable版本的软件，比如用KDE 3.4而不是3.3。
           需要在命令行工作，这个...似乎对哪些我们通常以为的的Mac用户群有点困难。
        3。删除原本的X11，用XFree86代替。
           转为基于BSD的MacOS自然带着自己的X，可是干吗要干掉Apple本来的X11？－－因为这个X不能很好地支持KDE－－除非做些很麻烦的设置改动。
           这一步需要把/usr/X11R6删除－－或者你备个份改名；同样/etc/X11和Mac Application文件夹下的X11应用也要删除。
        4。安装XFree86。
           旧的已去，装新的。
           还是在命令行工作，输入fink install xfree86－－然后就可以去睡个觉或者出去溜一圈了。
        5。安装KDE。
           类似地，输入fink install kdebase3－－估计你上一个觉已经睡够了，得想点别的做做，比如读读我的blog，看看有没有类似在Linux上 native 运行 OSX Aqua的文章......
        6。设置XFree86。
           好歹要告诉它用哪个Window Manager吧。修改/usr/X11R6/etc/xinit/xinitrc。
           到这一步其实就差不多了，在xinitrc里写上启动kwin，xterm，blah blah随你便了，现在就尝试用startkde手工启动你心爱的小甜心儿也完全可以了－－因为KDE已经安装完毕了。
           如果想多了解一下系统机制和tweak方法，继续。
        7。启动时进入KDE
           不好意思，一点都不神秘，和前一步一样，在xinitrc里写上startkde。
        8。与OSX窗口里运行KDE
           这招比较有颠覆性，虽然几乎没有实用价值，不过，好玩。
           第一，创建一个要被xinitrc引用的脚本，这个脚本执行Kwin，并在一个窗口内执行startkde。
           第二，上xnest（装RedHat系的发行版时，你也能看到这个xnest的安装选项在X那一类里，不过通常都是未选状态的:-P －－至少在我装的 Fedore Core 所有系列中 ），用一句够恶心的xinit ~/.xinitrc.kde -- /usr/X11R6/bin/Xnest :3 -geometry 1024x768 填充xinitrc －－ 当然1024x768那个分辨率可以随便改。
           此等妙技虽不够安天下的效果，至少没赔夫人也不折兵，你可以继续使用喜欢的Mac，同时还有KDE可供选择。
           如果你有双显示器，那效果就呆了......

        
        效果大图 
        
        考虑到编译KDE和X的时间，机器越新越快当然越好－－在作者的双 1.25 G4上，这话儿花了8个小时。
        这文章很有帮助，俺也了解了不少X的东西。

        估计最麻烦的在命令行，其实这个step by step的文章里用的pico已经是非常容易的文本编辑器了，只是人们恐怕会有心里障碍而已。
        Fine，我们的世界。

        
        近点儿，再近点儿，The People Behind KDE 。
        看看他们是什么样的神仙儿。

        kde.news 23号的消息，Wikimedia Foundation主席，Jimmy Wales当天宣布，他们将和KDE项目展开合作。怎么个合作法嘛......作为开端，KDE的媒体播放器 amaroK 将开始集成Wikipedia的内容。在可预见的将来，其他应用开发者也能使用同样的webservice API来访问Wikipedia和Wiktionary，提供KDE API也有可能。
        如果成真的话，KDE程序可以非常方便地嵌入Wikipedia内容，当然，可以根据在线或离线状态决定是否访问本地数据库。现在已经有个示范/试探性质的QT程序 Knowledge，一个Wikipedia的离线阅读器。
       

        amaroK 一直很有创意，在集成web内容方面做得不错，比如现在的1.2版本就支持Audioscrobbler ，一个音乐欣赏习惯网站；还可以自动搜索下载歌词。
        以前我觉得能从CDDB里面取CD专辑，单曲信息已经很酷了，现在能从网上获得的信息则多多了，互联网时代经常这么考验我们的想象力，你还没回过神儿来，就发现眼前多了这么多好用，还很好玩的东西。

        那么...KDE和Wikimedia合作这样的动作，有什么意义呢？
        Wikimedia 在起步时和现在（当然也包括将来），最大的主旨是把尽可能多人的智慧集合到一块，先填满一个pool，构造一个非阳春白雪的知识库，这是第一步或者说第一层次，这时候重点是积累。有了积累人们才有基础可以突破传统方法去获取和共享知识，意义已经不薄。
        现在迈出的第二步，则再把Wikimedia打散，让它不再只是集合或者容器。第二层次的核心，是Wikimedia开始有计划地输出，回馈，开始融入到能利用它的地方。amaroK这样的程序就像对Wikimedia的二次包装，能自动发掘Wikimedia里相关的内容，展现Wikimedia里相关的内容。在将来的amaroK里，人们对Wikimedia的使用可能是不自觉的，透明的，用户看到的不是先从浏览器访问Wikimedia网站，然后按条目浏览或者手工搜索，而是集成在amaroK里，经过整理的，有机一体的完整篇章。人们查阅词典，书籍和Wikimedia可能是有问而来，目的明确，当然也可以是闲逛。如果正着查John Lennon，当然很简单，但是让amarok自动fetch这个内容就舒服多了，再者，从一首单曲反查洋子呢？这种活儿可不适合人类手工完成，那些错综复杂联系着音乐，谋杀，人物，甚至日本这样的信息片断，通过适当定义的web service，让amaroK代劳，呈现形式会“优美”得多。
        另外，前端程序对Wikimedia信息的利用一定是100%目的明确，需求彰显的，网站在提供service的同时，也就开始了对用户，对内容的圈子划分（或者说群体划分－－如果你觉得这个词挺起来更酷的话）。苦于分析用户习惯，期望抓住刁钻的用户口味的商家们一定会喜欢这个局面－－或许这意味着不坏的商业前景 ;-P
        相当多的事实验证的一点结论是，把内容推到用户的桌面上才是最保险最有效的方法，离用户最近的永远是桌面，用户觉得访问最方便的地方也永远是桌面，别看用户和网站间似乎只有一个浏览器的距离，这个隔阂其实不小（可能因为这个google才会有deskbar，并在以后的GDS里也不忘集成web搜索）。amaroK 集成 Wikimedia内容和昨天写的Konfabulator的Widget把网站内容“拉到”桌面一样，这才是让用户用着最舒服的方式，也最能培养他们的“懒惰”和“依赖”，把他们彻底地lock in ;-)

        目前其他可能集成Wikipedia的KDE程序还有
        天象仪软件KStars；世界地图Globepedia；化学元素（及其背后的故事 ;-P ）Kalzium；还有诸如This day in history这样的东西。

        有时候你会有这种感觉，这世上会写软件的人太多了，缺的是另外两种人。一种是有创意的，他能想到无数的点子，规划让软件去做什么，等他想完要搞这么个软件后，很多人也回过味来，说，这种软件我也会写－－是的，你也会，但是你就是想不到要去写。Wikimedia 绝对不会在中国诞生，没办法，在despotism环境下长大的人，还有环伺饥饿的生存现实，让人很难迸发好点子或者有心无力。