inputwindow 怎么是那个样的啊？ 是不是你也修改过了 :)
鄙视cjacker这么久了还不放出！
每次看到他的桌面抓图都是一次精神上的严重打击………
:-(
inputwindow 怎么是那个样的啊？ 是不是你也修改过了 :)
个人喜好，我觉得flat plain是我个人想要的风格，呵呵。
Patch还没有，随手改的，等成熟一点再放。
关于skin，KDE是没有解决方案的。
你只能采用读配置文件的方式，
比如，定义一个/usr/share/apps/skim/SKIN/
里面有一个个的目录，放着图片和配置文件。
不过，这样一来，你的skim的很多控件都要重写了，至少需要点重构工作。
弄不好，utils和plugins目录里有大量代码要改。
其实，我也想搞两件事情：
1，skinnable skim
2，dockable skim mainwindow.
支持skin还容易，支持dock, undock，就不太方便了。
如果给kicker来个补丁没准好一点。
比如：要dock，其实就是这个hide，然后通知kicker show一个出来。
如果不dock，就销毁kicker上的这个，然后让主窗口show出来。
如果要写成一个，那就只有做成applets，用applet_proxy？我觉得不太好。
鄙视cjacker这么久了还不放出！
每次看到他的桌面抓图都是一次精神上的严重打击………
:-(
要体谅我，哈哈，你以为这些代码我留着能生金子啊:-D
鄙视cjacker这么久了还不放出！
每次看到他的桌面抓图都是一次精神上的严重打击………
:-(
要体谅我，哈哈，你以为这些代码我留着能生金子啊:-D
:lol: ，同鄙同鄙，cjacker，老实交待，生了多少金子啦？:mrgreen:
haha
什么时候能放出啊，如果这个放出来，我的LP就可以不用Windows了.......
关于skin，KDE是没有解决方案的。
你只能采用读配置文件的方式，
比如，定义一个/usr/share/apps/skim/SKIN/
里面有一个个的目录，放着图片和配置文件。
不过，这样一来，你的skim的很多控件都要重写了，至少需要点重构工作。
弄不好，utils和plugins目录里有大量代码要改。
你现在做的这个难道不是一个 KDE style plugin 吗？我看到你的 kicker 是使用的XP 的 style，但是 skim 依旧是 plastik 的。不会你也修改了 kicker 吧？ 我看你的意思，好像是说，为了使用你实现的 skin 支持，必须修改现有KDE程序的代码，或者我理解错了？
我现在还没有想出来一个 decent 的方案来实现 skim 的 skin 的支持，很高兴听大家的建议
其实，我也想搞两件事情：
1，skinnable skim
2，dockable skim mainwindow.
2 已经在 skim CVS HEAD 中实现了 :) 如果感兴趣，可以看看CVS。 这个功能将会包含在 skim 1.3.0 版本中
如果给kicker来个补丁没准好一点。
比如：要dock，其实就是这个hide，然后通知kicker show一个出来。
如果不dock，就销毁kicker上的这个，然后让主窗口show出来。
呵呵，你可以修改 rf 中的 KDE 的 kicker 的代码，没什么问题，但是我是不指望这些修改会被其他 distro使用的，因此我没有考虑过任何需要修改 KDE 的方案 （修改 bug 除外）
如果要写成一个，那就只有做成applets，用applet_proxy？我觉得不太好。
我选择了这种方案，但是，不用 applet_proxy（不直接调用），而是使用 xebmed
现在基本上可以使用了，但是还有些比较麻烦的问题，主要是涉及进程间通讯的问题： 现在用dcop 的，我觉得可能应该用一个更加低层的协议。。。 不过，dcop是我想到的可行的唯一方案了，而且，总的来说，至少在我的机器上现在工作的很不错，当然了，还没有经过大家广泛的测试...
欢迎大家试用 CVS :)
liuspider也是比较勤奋的啊，cjacker还是不要吊大家的胃口了，当心吃了你！
:);)
支持 alpher 继续将游戏完成，尽管 cjacker 已写出同样的游戏。
写出来了吗？
我怎么不知道，到什么地方去下？
关于skin，KDE是没有解决方案的。
你只能采用读配置文件的方式，
比如，定义一个/usr/share/apps/skim/SKIN/
里面有一个个的目录，放着图片和配置文件。
不过，这样一来，你的skim的很多控件都要重写了，至少需要点重构工作。
弄不好，utils和plugins目录里有大量代码要改。
你现在做的这个难道不是一个 KDE style plugin 吗？我看到你的 kicker 是使用的XP 的 style，但是 skim 依旧是 plastik 的。不会你也修改了 kicker 吧？ 我看你的意思，好像是说，为了使用你实现的 skin 支持，必须修改现有KDE程序的代码，或者我理解错了？
我现在还没有想出来一个 decent 的方案来实现 skim 的 skin 的支持，很高兴听大家的建议
其实，我也想搞两件事情：
1，skinnable skim
2，dockable skim mainwindow.
2 已经在 skim CVS HEAD 中实现了 :) 如果感兴趣，可以看看CVS。 这个功能将会包含在 skim 1.3.0 版本中
如果给kicker来个补丁没准好一点。
比如：要dock，其实就是这个hide，然后通知kicker show一个出来。
如果不dock，就销毁kicker上的这个，然后让主窗口show出来。
呵呵，你可以修改 rf 中的 KDE 的 kicker 的代码，没什么问题，但是我是不指望这些修改会被其他 distro使用的，因此我没有考虑过任何需要修改 KDE 的方案 （修改 bug 除外）
如果要写成一个，那就只有做成applets，用applet_proxy？我觉得不太好。
我选择了这种方案，但是，不用 applet_proxy（不直接调用），而是使用 xebmed
现在基本上可以使用了，但是还有些比较麻烦的问题，主要是涉及进程间通讯的问题： 现在用dcop 的，我觉得可能应该用一个更加低层的协议。。。 不过，dcop是我想到的可行的唯一方案了，而且，总的来说，至少在我的机器上现在工作的很不错，当然了，还没有经过大家广泛的测试...
欢迎大家试用 CVS :)
支持skin就没有别的办法了。
我作的确实是修改了kicker, kdm和退出对话框也就是ksmserver的大量代码。
实现了一个skin的loader，然后，可以让这些东西来表现出skin的样子。
仅靠写style，不能实现。
所以，最可行的办法也只能是一个plugin了，呵呵，我也不知道还有什么好办法了。
dcop还是可以用的，理由如下：
１，skim肯定是要用在KDE主环境的。
２，即使有了dbus，dcop最大的修改是对dbus作封装，而不会完全抛弃，所以api兼容性不会有问题。
dockable问题，我倒是愿意作一个tester，呵呵。
支持skin就没有别的办法了。
我作的确实是修改了kicker, kdm和退出对话框也就是ksmserver的大量代码。
实现了一个skin的loader，然后，可以让这些东西来表现出skin的样子。
仅靠写style，不能实现。
所以，最可行的办法也只能是一个plugin了，呵呵，我也不知道还有什么好办法了。
如果仅仅是为了实现 XP 风格的 style 的话，我记得有一个 windows XP KDE theme。那不个符合你们的要求吗？ 为什么要实现有一需要修改KDE代码的方案呢？ 而且，最重要的是，这种修改是永远不可能进人KDE的。难道rf 每次都想重新修改 KDE？不解...
我记得还有一个 icewm KDE theme (或者类似的，名字记不清了），可以使用自定义的pixmap 来render的，用那个不好吗？
dcop还是可以用的，理由如下：
１，skim肯定是要用在KDE主环境的。
２，即使有了dbus，dcop最大的修改是对dbus作封装，而不会完全抛弃，所以api兼容性不会有问题。
你说的很对，但是我总觉得 dcop 不是特别可靠的样子。希望仅仅是“感觉”...
dockable问题，我倒是愿意作一个tester，呵呵。
不知道在你那么“严重”修改后的 kicker 中是否能使用。
为了实现这个 embed mainwindow，我迫不得已使用了一些比较 ugly 的 hacks，实在是没有办法的办法：没有什么 KDE app 会有像 skim 这样特殊的需要的。事实上，skim 的这个 dock 功能严重依赖于 kicker 的具体实现：为了支持 KDE 3.3.x 和 KDE 3.4.0 的 kicker，skim 根据 KDE version 来选择使用的 hack 策略
你要是改的太大的话，你可能还要给 skim 打 patch :)
支持skin就没有别的办法了。
我作的确实是修改了kicker, kdm和退出对话框也就是ksmserver的大量代码。
实现了一个skin的loader，然后，可以让这些东西来表现出skin的样子。
仅靠写style，不能实现。
所以，最可行的办法也只能是一个plugin了，呵呵，我也不知道还有什么好办法了。
如果仅仅是为了实现 XP 风格的 style 的话，我记得有一个 windows XP KDE theme。那不个符合你们的要求吗？ 为什么要实现有一需要修改KDE代码的方案呢？ 而且，最重要的是，这种修改是永远不可能进人KDE的。难道rf 每次都想重新修改 KDE？不解...
我记得还有一个 icewm KDE theme (或者类似的，名字记不清了），可以使用自定义的pixmap 来render的，用那个不好吗？
dcop还是可以用的，理由如下：
１，skim肯定是要用在KDE主环境的。
２，即使有了dbus，dcop最大的修改是对dbus作封装，而不会完全抛弃，所以api兼容性不会有问题。
你说的很对，但是我总觉得 dcop 不是特别可靠的样子。希望仅仅是“感觉”...
dockable问题，我倒是愿意作一个tester，呵呵。
不知道在你那么“严重”修改后的 kicker 中是否能使用。
为了实现这个 embed mainwindow，我迫不得已使用了一些比较 ugly 的 hacks，实在是没有办法的办法：没有什么 KDE app 会有像 skim 这样特殊的需要的。事实上，skim 的这个 dock 功能严重依赖于 kicker 的具体实现：为了支持 KDE 3.3.x 和 KDE 3.4.0 的 kicker，skim 根据 KDE version 来选择使用的 hack 策略
你要是改的太大的话，你可能还要给 skim 打 patch :)
不是为了要一个Windows XP 的风格，而是要一个skinnable的kicker和ksmserver以及kdm。
kdm的theme支持KDE刚刚做了，我用的是kde-3.2，所以自己修改的这些还不能丢。
至于支持皮肤的kicker和退出对话框，还是有意义的。
Style在kde中只能起到一个控件渲染的作用，满足不了我的需求，比如：我要一个不规则的按钮，等等(其实我也没有这个需求，只不过个别人有，哈哈)。
红旗确实有维护麻烦这个问题，也正在想办法，比如，项目尽量不修改KDE，或者尽量剥离项目等等。
另，很不幸的告诉你:-D
它work了，我是从cvs backport了一部分代码在skim-1.2.2上，虽然我大规模修改kicker，但是协议和基本实现的东西还是不敢动的，呵呵
当然，dockable window不能支持我的skin，这是很正常的事情。
这个事，其实也没什么紧要的。
kicker提供了几个属性，可以支持kicker的背景设置，我想这个dock应该支持这几个背景设置才好，至少要配合好，不知道你考虑过这个问题了没有？
另，如何常驻面板？
至于我的skin实现，我也提供了几个特殊的标签，到时候需要自己修改一下skim支持我的标签就可以了。
哈，没想到你还在使用 这么老的 KDE 啊？ 我以为 rf 会一直用最新的呢
看来，skim 1.3.0 还可以支持 KDE >= 3.2.0 了，我本来想放弃 ＜ 3.3.0 的支持的
Style在kde中只能起到一个控件渲染的作用，满足不了我的需求，比如：我要一个不规则的按钮，等等(其实我也没有这个需求，只不过个别人有，哈哈)。
但时，据我看 style 的实现代码，你完全可以控制一个按钮的边框是什么样的，你都可以不画边框出来
kicker提供了几个属性，可以支持kicker的背景设置，我想这个dock应该支持这几个背景设置才好，至少要配合好，不知道你考虑过这个问题了没有？
这个我注意到了。现在 skim 在 dock 的时候，我希望使用 kicker 的背景设置，但是，呵呵，因为是两个进程，不能互相调用 qwidget，因此比较难办。但是因为我使用的两个style 都是标准的 KDE theme，这个问题在我这里没那么明显。所以我没怎么上心去解决它
另，如何常驻面板？
？？看来你没有 backport 全：CVS 中的 skim 是会自动记住上次的状态的