为了随时更新到 Chromium 的最新 nightly build,又不想每次去 Chromium 的网站下,还有解压,移动,麻烦……为了省事,直接用 REALbasic 写了一个 Chromium Updater,专门用来更新 Chromium。目前只支持 Mac :)
下载(使用右键下载):ChromiumUpdater (3.5M)
为了随时更新到 Chromium 的最新 nightly build,又不想每次去 Chromium 的网站下,还有解压,移动,麻烦……为了省事,直接用 REALbasic 写了一个 Chromium Updater,专门用来更新 Chromium。目前只支持 Mac :)
下载(使用右键下载):ChromiumUpdater (3.5M)
今天在使用 AutoDiscovery 发送数据时,发生了错误码为 40 的错误,直接在 UDPSocket 的属性列表里找了一下,没有找到对应的错误码。
在网上搜了一下,找到这篇帖子,里面提到在发送大量数据时,UDPSocket 就会报错误,并且这个错误没有在文档中提到,因此这应该是一个系统级别的错误。
MonkeybreadSoftware 提到了 unix 的错误码定义:
#define EMSGSIZE 40 /* Message too long */
联想到在程序中是在今天开始有问题的,而且今天添加了一大堆数据,看来的确是同于 UDP 消息过大造成的错误 40。
在网上找了找,使用 UDP 发送消息时,报文的大小最好不要超过 MTU,否则会就容易丢包。我在测试时是使用的 127.0.0.1,包大小为 12.5K,照理说应该是直接走 loopback 而不需要走路由的,就算超过 MTU 也应该能发送,不清楚是不是因为 OS 内部实现机制的问题。
为了彻底解决这个问题,最后还是采用了 TCP 来传递大量数据,只使用 UDP 来传递一些控制信息。
本篇所讲关于 AIR 的内容是基本 HTML+JS,而不是 Flex 或其他。
在 AIR 中,如果当前页面有一个 iframe,并且我们需要获取这个 iframe 的内容,但是如果 iframe 里包含的是远程页面,在默认情况下,浏览器策略并不允许这种情况,这就是同源策略的限制。
在 Titanium 这个类似于 AIR 的平台中,默认情况下是可以直接从应用的页面中去读取 iframe 中的内容而没有任何限制,但是在 AIR 中不可以。在网上搜索了一番,再看了好几遍 AIR 的文档之后,终于找到解决问题的方法了。
在 AIR 中,iframe 标签拥有额外的几个属性:sandboxRoot、documentRoot、allowCrossDomainXHR 及 ondominitialize。这里为了解决读取 iframe 内容所用到的属性就是 sandboxRoot 及 documentRoot。
通过 sandboxRoot 及 documentRoot,可以将本地的页面映射为远程页面,并在沙盒中运行,另外,在沙盒中运行的页面就会拥有映射域名的域。例如,我们可以将本地的 proxy.html 映射为 http://example.com/local/proxy.html,这样,在实际运行时,proxy.html 中如果用 document.domain 获取页面所在的域,就会得到 example.com,这个时候如果在 proxy.html
这是一篇介绍类似于 js hack 的文章,只是说明了一种可行的途径,并且可能会增加代码复杂程度,具体项目中是否可以使用还请自辨:)
在前端开发过程中,有许多业务流程可能是需要用户进行登录的,并且登录过程是放在弹出层中,这样就可以不用刷新页面,增强用户体验。在登录时,用户的操作就会被打断,为了进一步增强用户体验,我们可能需要在登录完成后自动继续进行用户在登录前想进行的操作。
假设有这样一个场景,用户需要发表一个留言,但是发表留言是需要登录的,而发表留言的输入框是一直显示的,这也就要求在用户点击了发表按钮时对用户登录状态进行验证,传统的做法是将在用户登录状态检查封装在一个函数之中,这个函数接收一个回调参数,如果登录验证通过,则执行回调函数。这样的逻辑可以用以下代码表示:
function doAction() {
checkLogin(function() {
// 处理业务逻辑
});
}
function checkLogin(callback) {
if (isLogin) {
callback();
} else {
showLogin(callback);
}
}
function showLogin(callback) {
document.getElementById("login-btn").onclick = function() {
isLogin = true;
callback();
};
}
总觉得这样的方式会将业务逻辑放到一个匿名函数中,而不是放在了按钮的事件响应函数中,感觉上不是那么好。这对整个事件响应函数的改动比较大,主要的业务逻辑都放在了登录验证函数的回调中。而希望可以是下面这样:
在 REALbasic 中,如果需要执行 cmd 命令,可以直接使用 Shell 类,但是这样的话,编译成 Windows 程序时会额外需要一个 Shell.dll 的动态链接库,这对于我这样的 1exe 爱好者是不能忍受的。但是对于 Mac OS X 和 Linux 的生成目标来说,是不存在这个问题的,因为 Mac OS X 的应用程序本身就是一个文件夹,而 Linux 的目标不会生成额外的链接库。因此,需要针对 Windows 进行特殊处理。于是在网上搜索解决方案,找到了 VB 中执行程序的几种方法:
1. 使用 CreateProcess
通过 CreateProcess 以及使用管道,可以执行外部程序并获取输出,但是这个方法过于烦琐,并且我也不需要外部进程执行完毕后的输出结果,因此不采用。
2. 使用 Shell 方法
VB 里有一个 Shell 方法,但是在 RB 中并没有,所以此路不通。
3. 使用 ShellExecute
这个方法同样是一个系统 API,可以直接通过 …
阅读全文 »
在公司里为了让笔记本和台式机共享文档,决定用内部的 Samba 做中转,但是在 Finder 中直接使用“连接到服务器”时,会出现“输入的文本似乎不是可识别的 URL 格式”错误,但是我输入的地址明明是 smb:// 开头的。
用这个错误信息在网上找了找,没有找到任何解决文案,遂放弃。
今天决定再尝试一下,换了个关键字,直接用“iDeneb samba”作为关键字来搜索,慢慢发掘之后还真找到了有用的信息:http://www.hackint0sh.org/f179/81233.htm
按照文中说明,到 /System/Library/Filesystems 目录下,把 afpfs.fs 删除,并重新创建到 /System/Library/Filesystems/AppleShare/afpfs.kext 的软链接,但是操作完之后还是会提示“输入的文本似乎不是可识别的 URL 格式”。
再找了找,找到了这篇:http://www.insanelymac.com/forum/i ... opic=92989&st=580,似乎说是系统安装完成时 afpfs.fs 到 /System/Library/Filesystems/AppleShare/afpfs.kext 的软链接少了开头的斜杠,也就是说它的软链接地址是 System/Library/Filesystems/AppleShare/afpfs.kext。
好吧,我在之前操作的时候为了省事,直接进入 Filesystems 目录用相对路径来创建软链接的,看了文章之后,老老实实的用全路径再次创建软链接,Command+K,双击,成功连上 Samba 服务器:)
完整的操作步骤也只有两步:
sudo rm /System/Library/Filesystems/afpfs.fs
sudo ln -s /System/Library/Filesystems/AppleShare/afpfs.kext /System/Library/Filesystems/afpfs.fs
注意:一定不能省略了路径最开始的斜杠(/)或者使用相对路径。
所以,如果你也是用黑苹果的,也碰到了这个问题,不妨试试这个解决方法吧。
上周去把 EPC 的内存升级到了 2G,直接发现开机进不了 OSX 了。
在两天没有电脑用之后,下定决心重装系统。重装之后,能进系统,但是重新启动之后键盘和触摸板就不能用了,电池状态指示挂了,郁闷。
在网上找了找,发现可能是 dsdt 的问题。由于内存大小变了,dsdt 中的信息不正确,继而导致 ACPI 失效,然后就整个玩完了。
一个老外找到了解决方法,通过修改 dsdt.aml 文件中的内存大小信息,就可以正确进入系统了。直接下载他提供的压缩包中的 dsdt.aml,开机直接四国了……
好吧,这个老外蛮厚道的,给出了手动处理的方法:
…For the 1GB:
…
Name (SMBS, 0×0400)
OperationRegion (BIOS, SystemMemory, 0x3F7AE064, 0xFF)
Field (BIOS, ByteAcc, NoLock, Preserve)
{
…
For the 2GB:
…
Name (SMBS, 0×0400)
OperationRegion (BIOS, SystemMemory, 0x7F7AE064,
在 EeePC 上装了个 Mac OS X,相应的开发工具也选择了 Coda。在 Windows 下,EditPlus 可以通过添加自定义 工具的方式来给 EditPlus 的添加前端工具,但是在 Coda 上,就没有这么方便的自定义方式了。之前师兄清羽用 Python 实现 了 Coda 的 YUI Compressor 和 JS Lint 两个插件,后来在群里讨论要不要把 JS Beautify 也集成。
想 法有了,上周末回家就开写,Coda 的插件有两种形式的,一种是用脚本来写,另外一种是用 Cocoa 来写。使用脚本很简单,Python、 Ruby 等等都可以,只要系统上有解释器。相对而言还是 Python 熟一点,就选用 Python 来编写这几个插件了。
下载:
http://dl.getdropbox.com/u/1451589/Blog/CodaF2ETools.zip
for Coda 2:
F2E Tools for Code …
阅读全文 »
上一篇介绍了 HTML5 中 Canvas 的路径,这篇将要介绍一下 Canvas 中的颜色及渐变。
Canvas 中的基本颜色系统
在 Canvas 中,颜色主要用途就是在绘制路径时,用来指定填充颜色和边框颜色。
Canvas 中的颜色参数值有两种格式:
1. 如果透明度为 1.0,也就是不透明,颜色值的格式就与一般使用一样,为:#AABBCC,其中 AA、BB、CC 分别为 Red、Green、Blue 分量。
2. 如果透明度不为 1.0,也就是带透明,颜色值格式可以使用 rgba(r, g, b, a),其中 r、g、b、a 分别为 Red、Green、Blue 分量和透明度。透明度的值为 0 至 1.0 之间的一个数值。
3. 颜色值还可以为已知的颜色名称,例如 red、blue、green 等。
总的说来,Canvas 中颜色值的格式与 CSS 中一致,因此颜色值没有特别需要注意的地方。
<canvas id="canvas" width="600" height="500"></canvas>
<script
…上一篇介绍了 HTML5 中 Canvas 的基本概念,这篇将要介绍一下 Canvas 中的基本图形。
图形的基础 - 路径
在 Canvas 中,所有基本图形都是以路径为基础的,也就是说,我们在调用 2dContext 的 lineTo、rect 等方法时,其实就是往已经的 context 路径集合中再添加一些路径点,在最后使用 fill 或 stroke 方法进行绘制时,都是依据这些路径点来进行填充或画线。
在每次开始绘制路径前,都应该使用 context.beginPath() 方法来告诉 Context 对象开始绘制一个新的路径,否则接下来绘制的路径会与之前绘制的路径叠加,在填充或画边框时就会出现问题。在绘制完成路径后,可以直接使用 context.closePath() 方法来关闭路径,或者手动关闭路径。另外,如果在填充时路径没有关闭,那么 Context 会自动调用 closePath 方法将路径关闭。
基本路径方法
1. beginPath, closePath
这两个方法在前面已经介绍过,分别用来通知 Context 开始一个新的路径和关闭当前的路径。
在 Canvas 中使用路径时,应该要保持一个良好的习惯,每次开始绘制路径前都要调用一次 beginPath 方法,否则画出来的效果难看不说,还会严重影响性能。
在下面这张图中,左边的图形在每次绘制矩形前都调用了一次 beginPath 来清除之前的路径并重新开始绘制新的路径,而后面的图形则就只在绘制所有图形前调用了一次 …
阅读全文 »
近期评论