Blue Blazer

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

Portable meta-information has been discussed twice recently on planetkde:
http://www.kdedevelopers.org/node/3923
http://zwabel.wordpress.com/2009/03/29/portable-meta-information/

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),
http://en.wikipedia.org/wiki/Fork_(filesystem)
http://en.wikipedia.org/wiki/Resource_fork
It's invented by Apple , store text file's encoding, applications' icon ...

Quote:
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

user.encoding

user.img.source.url

....
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..

Regards,

修补了Amarok2编码检测的bug.........
Amarok2可以像千千静听那样显示歌词了，
感谢Sanfanling的IrcShow-X，So cool
把IrcShow-X通过XEmbed集成进了amarok2的Context View,
理论上可以将符合XEmbed规范的任意窗口(甚至Firefox, Openoffice)嵌入到Amarok2中去 ：）



Amarok2中的Dolphin文件浏览器 ：）


Google在Chrome里声称的“安全”的沙盒技术也是基于这个原理，
每个Tab是单独的进程，浏览器进程也是独立出来的，
Linux下的实现每个Tab通过XEmbed或其他组件技术？嵌入到浏览器中，
而浏览器通过Socket或dbus等IPC手段控制Tab,
这样任何个Tab挂掉或被恶意脚本“攻陷”都理论上不会挂掉/影响浏览器进程，
而浏览器进程挂掉的话，各个Tab就自动变成单个单个的窗口：）

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:

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等软件。
而图像的Alpha值是和透明度相关的，采用部分半透明的背景能够能加提升视觉效果。

在Qt中实现异形窗体一般采用setMask()，
实现透明也有setWindowOpacity()，
但这并不是最高效的方式。

而直接使用窗口管理器的接口来设置背景透明度却不能得到一个各部分透明度不同的控件（窗口）背景。

直接与Xlib打交道是一种解决方法。

其实Qt提供了一个简便的方法来供您使用，
如果你有支持复合(Composite)的窗口管理器，如(compiz或者kwin)，
就可以去除不必要的控件闪烁，并获得显著的性能提升。

首先要这样初始化你的程序。

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

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
VisualDepthMask
VisualClassMask, &templ, &nvi);

for (int i = 0; i < style="color: rgb(255, 0, 0);"> XRenderPictFormat *format = XRenderFindVisualFormat(dpy,
xvi[i].visual);
if (format->type == PictTypeDirect && format->direct.alphaMask) {
visual = xvi[i].visual;
colormap = XCreateColormap(dpy, RootWindow(dpy, screen),
visual, AllocNone);
argbVisual=true;
break;
}
}
}
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();
}

然后在你要渲染的Widget的paintEvent里面这样做：

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

void Widget::paintEvent(QPaintEvent *e)
{
QPainter p(this);
p.setRenderHint(QPainter::Antialiasing);
p.setClipRect(e->rect());

p.save();
// QPainter使用混合扩展模式中的源覆盖模式，很重要！不然会得到白色背景
p.setCompositionMode(QPainter::CompositionMode_Source);
// 使用“透明”颜色来填充背景
p.fillRect(rect(), Qt::transparent);
p.restore();

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

p.end();

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

}

现在的Widget就是一个以my_background.svg为背景，各个部分有不同透明度的控件了，
并且渲染得到了显卡的加速:)

需要更详细完善的例子，可以参考KRunner的源代码:
http://websvn.kde.org/trunk/KDE/kdebase/workspace/krunner/krunnerapp.cpp?view=markup
http://websvn.kde.org/trunk/KDE/kdebase/workspace/krunner/krunnerdialog.cpp?view=markup