解决opera的字体问题

deafwolf — Mon, 29 Oct 2007 11:00:00 +0800

作者: deafwolf 链接：http://deafwolf.javaeye.com/blog/136260 发表时间: 2007年10月29日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

opera是我最喜欢的浏览器，没有之一。小巧，快速，还集成了邮件客户端和rss阅读器，甚至IRC客户端也现成。但是opera在linux下的字体表现是非常奇怪的，也许今天配好了，明天就出了问题，所以写点东西留个记录。

1. 首先配置X的字体
2. 调整Tools->Preferences->Advanced->Fonts的字体
这两步是最基本的，如果解决了，那么运气算是非常好

3.
nano ~/.opera/styles/user/user.css
html,body,*{
font-family:"STHeiti"!important;}
这个是设置用户自己的css，有可能改变页面上的字体，但是对工具栏不起作用

4. 据说可以通过改变字体名来解决，这个我没试过，也不建议用

5. 删除不使用的字体，这个是我用的方法，因为前面的都不起作用

我用的是gentoo，本来opera在前两步已经配好了，但是一次重启后，页面和工具栏又全乱了
第3步不起作用，因为我用的STHeiti在opera中压根就不加载
根据google的结果，有可能是因为emerge xdm导致的，于是把/usr/share/fonts/corefonts挪到别的地方，果然恢复了
使用gentoo经常需要emerge，很可能增加新字体导致opera字体错误，所以，清理corefonts可能需要经常进行

opera的字体选择机制非常奇怪，相当混乱，所以第5步是迫不得已的做法，也许会导致某些问题，但是目前还没发现

以上做法适用于opera9.24

已有 0 人发表留言，猛击->>这里<<-参与讨论

JavaEye推荐

业务逻辑能否不依赖于持久层？

deafwolf — Mon, 14 May 2007 18:45:28 +0800

作者: deafwolf 链接：http://deafwolf.javaeye.com/blog/79882 发表时间: 2007年05月14日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

我现在的架构是po->manager->service->action
其中manager实现业务逻辑，提供事务，action调用service
service中仅获取session，控制事务，load对象，然后调用manager，所以我可以单独的测试业务而不依赖于持久层

目前有这么个场景：一张地图，分成小块。给我一个坐标和半径，然后判断这个范围内是否有水。
因为地图是上下相通，左右相通，所以我要算出这个范围内所有地块的id，然后load出来，再逐格判断
于是代码就得类似这样：
List idList=manager.computeIdList(int x,int y);
Query query = session.createQuery("from Field where id in (:list)");
query.setParameterList("list", idList);
boolean hasWater=manager.fieldHasWater(query.list());

我想把这些东西都封到manage里，于是我定义了一个MyMap，与地块是一对多，内部用map，key为地块的id
这时会多个MyMap表，里面只有一行数据，地块表会多一列，以对应MyMap
于是manager就能写成：
boolean hasWater(int x,int y,MyMap map);
然后在内部用may.getField(int id)来得到地块
地块的数量有几十万，所以我用了lazy="extra"。

这种设计是否合理，是否会产生某些问题？

PS：，这种情况下不能用extra，hibernate生成的查询条件会出现null
再PS：以前看过一篇文章，select * from table where id in(1,2)的性能不如select * from table where id=1 union select * from table where id=2
因为in查询不能很好的利用索引，所以我觉得hibernate在缓存命中高的情况下，用循环load对象比用in查询要好一点，这个没测试过，高手有经验请说说

已有 2 人发表留言，猛击->>这里<<-参与讨论

JavaEye推荐

[旧文]TRPG地图编辑器0.4版新鲜出炉

deafwolf — Fri, 02 Feb 2007 17:47:54 +0800

作者: deafwolf 链接：http://deafwolf.javaeye.com/blog/51884 发表时间: 2007年02月02日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

　　经过三个礼拜的不懈努力（刨去有几天跑团，有几天出去，大概两个礼拜），终于把地图编辑器0.4版做出来了。上次做0.3版时还是二月份的事，那时候我也就刚学MFC。这次也一样，我一边学一边做，总算是完成了。

　　在Matrix申请的blog也没怎么用过，这次就作为个人原创的第一篇blog吧，也是对自己制作的过程做个记录。

设计：

地图编辑器概述

　　做这东西的起因，是因为跑团的时候发现法术范围不容易表示，经过简单测试，IRC的脚本可以实现这一点，碰巧那时候在学MFC，就做了一个0.2版的（0.1版的更烂，只给DINO一个人看过），经熊猫，TAGE，ANDOR各位老爷的指点，以及诸位DM的建议，改成现在的0.3版。

　　其实0.3版也很烂，不过能凑合用而已，一开始的设想是背景色用于法术范围，现在发现，用背景色画地形的DM貌似很多，所以，功能上的定义有一些变化（详情见下）。而且，由于本人初学MFC，经验很少，所以有一些细节没有充实，属于历史遗留问题，这些都会在0.4版中改进。

地图编辑器功能概述

1.地图编辑器是以IRC为基础的，没有IRC以及脚本，便无意义

2.表示地图时，可以利用以下资源：字符（以全角为主）以及颜色，背景色。由于IRC的颜色只有16种，尽管可以自己定制，但是传送的是颜色的控制符，如果其他人使用不同的调色板，看到的显示就不一样，所以一般以默认颜色为主。

3.由于控制符的加入，需要传输的内容比以前大，所以速度会慢一点，这个是没办法的事。如果有人发现生成的脚本有冗余的地方，请指出，我会尽可能的简化。

新版编辑器的功能

　　由于各位DM在背景色的使用上超出了我的预计，所以我无法设定比较合理的操作流程。所以希望大家能够说出自己的想法，你觉得该怎么操作比较好，尽管提出来，由大家讨论，尽量详细一些，千万不要简单化（我不太善于处理抽象的事物）。而且要在功能多样和操作的简便上有一个折中。初步设想基础：地形可以用前景+背景表示，生物可以用前景表示，法术范围可以用背景表示（讨论1）。我觉得分开地形、生物、法术，会容易控制一些。界面相关的元素：一个地图的画布（请不要被这个词迷惑，就是那个跟表格一样的东西），一个用于显示图例的列表框（类似于IRC的右边栏，只能单选），一组添加/删除/修改的按钮，一组上移/下移按钮。

操作流程：

a.添加图例的过程都一样，点选添加，出现一个输入框，选择添加地形/生物/法术，输入相关的信息，确定。

b.在地图上画的过程，略有不同，先在列表框选一个图例，如果是地形，那么可以画在任何地方，数量没有限制，可以是分开的；如果是生物，那么只能画一个格或者矩形区域，如果以前已经用这个图例画过了，新画的会删除以前画的（讨论2）；如果是法术范围，与地形相同。

c.删除操作相同，删除一个图例会导致地图上相同图例全部消失。

d.一个图例在列表框里的位置，决定了显示的优先权（讨论3），比如地图上有一块石头，一个人站在石头上，如果列表框中人在石头之上，那么人显示，石头只显示背景（如果有的话），如果人在石头下，那么人不显示。

相关讨论

1.也许可以分得更细，也许仍然使用0.3版的设定，总之，操作方便跟功能多样的折中

2.这样就省掉了移动等操作，但是如果有多个地精，就需要定义多个图例，也有不方便的地方。

3.这个还有值得商榷的地方，主要就是俯视一片场地一样，有层次的问题。法术通常为背景，生物总在法术之上，如果有人使用了Obscuring Mist，那么法术该在人之上，我还没想清楚，所以看大家的意见。

考虑过的功能

1.把生物弄成棋子：这个确实考虑过，不过柿子姐姐认为体型变动的情况不少，总改来改去的麻烦，这个需要大家讨论。

2.自动画法术：确定法术范围很容易，PHB上就五种，但是碰到墙等障碍需要附加的处理，这样就需要对地形做更多的规定，从而导致操作复杂度大大增加，所以此特性以放弃为主。

3.隐藏某些图例：陷阱可以提前画，然后设置隐藏，用的时候再改成显示，有人用了隐形术时，也可以这么处理。

4.图例的输出：这样就不会有人问，那个符号什么意思之类的。

历史遗留问题的处理

1.地图尺寸：肯定会扩大，然则这东西占内存，所以在测试后给一个比较合理的大小，初步定为128X128

2.编辑器最大化：这个是我FC，下次一定会做到

3.改用java编写：我放弃了MFC，这东西真不好用，还是java合我的性子，代价就是，大家需要安装JRE5.0，一个15M的东西。

4.存储：因为地图扩大了，而且功能跟以前不一样，所以存储方式要换一个，跟以前的地图不兼容（这个应该没什么问题吧）

制作：

SWT我是初学，对能做到什么不能做到什么也不是很清楚，于是决定边做边改。

SWT里的表格只能按行处理，不能达到我的要求。所以我去sourceforge找了一下，发现swt+table关键字只能找到一个叫ktable的项目，于是check out，看了一下example和代码，发现这个控件功能很强大，而且用途多样，代码也比较复杂，不过设计上很巧妙。但是有一个在我看来致命的缺点，就是速度慢，在演示程序里，一个10*6（显示出来的）的texttable，重画时能明显的看出来（我是CIII800, TNT2, 256SDR），对于地图那样一屏内有几百个格的情况来说，太慢了。所以我决定自己写。在动手之前，我找了一下SWT的优点，发现SWT用的是原生码，我希望能够直接使用原生码编写，这样效率高，于是我看了三天SWT的源码，了解了一下OS包，结果发现一点富余的都没有，于是作罢。然后在eclipse的网站找到一篇文章《Creating Your Own Widgets using SWT》，并且看到一篇有补充性质的文章《开发Eclipse自定义控件》，这两篇文章帮了我非常大的忙。

下面说说遇到的问题。

1.最小化后，再显示出来，速度很快，比ktable快不少，但是使用滚动条时，屏幕闪得厉害，后来尝试用了scroll方法，发现就不那么闪了。

2.滚动条向下向右滚动很正常，向上向左就不对，会多画一行/列表头，只好每次多重画那行/列的单元格

3.与ktable比较时发现，ktable增大size时，只重化新显示出来的那部分，尝试实现未果。用gridlayout+label写了一个，能做到这个效果，但是暴慢，于是放弃，不考虑此问题，毕竟更改size的情况很少。

4.实现了绘制和滚动后，开始做界面，发现gridlayout制作流布局的效果最好，折腾一天终于解决了界面布局。

5.在主界面的main中为DTable增加鼠标事件，发现十分混乱，权衡之后决定重新设计。经历了三四次折腾，成为现在的结构。

6.表格的select，背景用深蓝，前景用白色，那么按下鼠标后移动该如何实现？一开始时用的是一个Rectangle，利用两次重绘，先取消原来的，再画上新的，效果不好，特别晃眼。最后使用两个set，一个是pointToDraw，一个是pointToCancel，先把最新的rect里的点存到pointToDraw，然后用一个临时的set存储Cancel和Draw的交集，然后用这两个removeAll这个临时set，再取消Cancel，画Draw，再把Draw和临时set的并集赋给Cancel。处理速度不错，没有延时的问题。

7.画法术范围，一开始drawFocus时画在紧贴表格线的地方，后来发现画两次focus可以互相抵消，于是就直接画在表格线上，因为表格线太深看不出来，就调浅了。

8.显示地图的时候发现，用半角的字母或者智能ABC里那些●■之类的速度很快，如果换成汉字或者全角的字母，就慢很多，全屏幕的话，时间上要差五倍以上。试着给gc设置一下字体（宋体），就正常了。我担心有些系统没有宋体，就把字体名改成asdf，发现没报异常，速度也正常，十分奇怪，然则跟目标没太大的关系，不管了。

9.画法术范围时，改代码的过程中出现过的现象：先向下后向上滚动，新画出来的法术没有下面那条边；然后是滚动效果完全不对，有时候地图动了，法术没动。最后发现问题的关键，画地图（包括法术范围）时，用的gc是event的，而按下按钮时，画法术范围用的是自己创建的gc，因为按钮事件不提供gc，而且画地图是DTable的事，不能让主界面介入，于是把全部的gc都改成自己建立的，不使用event的，这样就正常了。

10.本来写好了输入框，使用也正常，忽然发现一按esc，输入框跟直接点了确定一样，可是这时候确定按钮明明是灰的，只好改了。

11.添加快捷键，找了差不多两个小时，居然没有实现swt快捷键的，本来菜单能实现快捷键，但是菜单项不能隐藏，于是作罢。对shell加一个KeyAdapter，结果shell不能获得焦点。最后实现一个KeyAdapter，让所有能获得焦点的控件都加上这个，这办法真笨。

12.因为在退出前要提醒是否保存，所以对shell加了个disposeListener，结果无法防止退出，而且也无法禁止那个关闭按钮。用google搜索，总算找到个方法，加一个ShellAdapter，把event的doit给否了就行。

13.打包之后，发现按钮上的图片读不了了，找了两个小时（关键字有问题，而且相关信息确实不多），可以用class.getResourceAsStream读图片，而swt的Image可以直接根据InputStream生成图片，于是就能用了。

14.有一位台湾朋友希望能有繁体的版本，正好java也支持国际化，所以一开始做的时候就那么准备了，只不过繁体字实在不好输入，而且同一个简体字可能对应好几个繁体字，最后找到个窍门，用word转，快捷方便。

15.后来又发现存好的地图读不出来，不对啊，我用的是序列化，怎么可能读不出来？后来发现是eclipse给加的那个什么号惹的祸，把需要序列化的类里面的那个号都清掉，再改动类也没关系了。

总结：

这些都是碰到的比较难缠的问题，更多的细小问题数不胜数，而且我是纯手工编码，除了重构可以自动，代码输入有提示，完全没有其他方便可言。经过这回，我对SWT有了不错的了解，算不上精通，可是再做东西，也难不住我了。这次也暴露出一些问题，我在设计上还缺乏锻炼，控件前后重写了好几遍，浪费了不少时间。代码还不够优秀，可以修改的地方不少，这个也跟设计能力有关，以后有时间要好好改改代码。

下载：请在下载后把扩展名改为rar http://blog.matrix.org.cn/resources/deafwolf/MapEditor.jpg
苹果园的下载http://www.ellesime.net/bbs/index.php?showtopic=5701

05年12月8日首发matrix，07年2月2日转javaeye

已有 0 人发表留言，猛击->>这里<<-参与讨论

JavaEye推荐