FreeOZ论坛

标题: 向苹果学系统设计的理念 [打印本页]

作者: key 时间: 21-8-2010 00:27
标题: 向苹果学系统设计的理念
今天开始试用mac，传说中的mac一如我所预料，见面不如闻名。举个我觉得很搞笑的东西吧。
我想设计环境变量，google了一轮后发现可以通过设置一个叫做$HOME/.MacOSX/environment.plist
的xml文件来实现，于是我就照做了。搞好后，netbeans出错，说$JAVA_HOME指向的路径有错。
我打开xml文件一看，原来通过界面设定的JAVA_HOME在xml文件中被写成：
<key>JAVA_HOME</key>
<string>/System/.....
</string>

问题在哪里？多了一个回车。我们一般会拿到输入字符串后做trim处理，但苹果同学不做这事，
因为这是它的定义，你要字符串，我就完整地提供给你。好，这个我认了。

后来我要安装一个小Perian的quicktime插件，死活都装不上去。查看system.log，看到的是
一个非常神奇的错误：找不到mkdir。明显不可能的事，但发生了。

一个半小时之后，我终于猜到有可能是路径错了。因为我的路径设置是这样的：
<key>ANT_HOME</key>
<string>$HOME/dist/ant</string>
<key>

ATH</key>
<string>$ANT_HOME/bin

PATH</string>
其结果就是，苹果同学根本不做变量解释，直接就原字样照搬。

是的，这样非常不友好。但我一点也没办法埋怨它，因为它照着定义，没有任何歧义地执行
程序。我能怨什么呢？

这就是苹果，走的正好和win相反的路线：以最没有歧义的方式来实现程序。
这样的坏处是明显的：用户会觉得不方便，尤其是习惯了各种“方便”法门之后。
但好处更明显：
1. 定义清晰，解释清楚
2. 容易实现
3. 不需要因为扩展了定义而为扩展定义进一步扩展

这两天在公司讨论配置系统的改进。手下的兄弟希望引入一个灵活，扩展性良好的系统。
这些想法我都明白，但我一再强调，简单，简化，无歧义。他不明白这样做的重要性。
我们是非常小的开发团队，人少，开发周期短，经验也不足，没有足够的测试用户群，
所以我们必须想尽所有办法来简化开发，以最直接和可行的方法开发一个简单，实用的
系统。我很清楚灵活和扩展性的好处，我更明白带来多变的表达方式能讨好用户，
这些我都明白，但我必须数着手指过日子，以小时来算开发时间。开发是一个多阶段
的工作，不是说你想到一个主意，写出一段程序就完了的事。如果你的定义过于复杂，
引入过多的解释分支，基本上就和自己过不去。首先你不能在足够短的时候内定义出一个
完善的定义集，其次你不能收集到足够多的用户反馈，以证明你的定义能为大众所接受，
第三就是当时发现某些定义不合理，会误导用户或使系统晦nei不清再改回来就头痛了，
第四，维护一个过于灵活的系统会比一个直接简单的系统多出一两个数量级的时间。
这些问题，都是一个小的开发团队不能接受的事。为什么不去接受一个直接，简单，
清晰定义的系统呢？

我手上还有大量的工作要这个团队齐心合力去跟进，纠缠在一个小得不能更小的功能上，
有何意义？与其花时间去考虑在一个不起眼的地方改进这些，扩展那里，还不如切切
实实地做一些大的，急需的功能。缺少经验的人往往只看到某种方案有好处，却不知道
这种方案坏处比好处多很多。

设计系统，不能单单考虑功能的强弱。在开发人力相对较少的情况下，把精力集中在必须
解决的大问题上才是王道。

[ 本帖最后由 key 于 21-8-2010 00:30 编辑 ]

作者: coredump 时间: 21-8-2010 12:51
你真能发散思维

作者: woodheadz 时间: 21-8-2010 13:05
没觉得苹果这个做法有什么好处

所谓的逻辑清晰因该是针对人而言，而不是针对计算机系统而言的。
类似不允许多一个小回车符这样的和人的自然思维相背离的逻辑，明显就是苹果的设计人员偷懒。
针对系统的简化有句名言：“尽量简单，但不是太简单”。苹果的做法我觉得明显就是“太简单”了

当然如果回车符在这个配置文件中也有意义，那么苹果的做法也算合理。

[ 本帖最后由 woodheadz 于 21-8-2010 13:12 编辑 ]

作者: key 时间: 21-8-2010 14:22
不错，如果单单是讨论“功能”之类的问题，这样做的确没有什么好处。
但如果综合功能，性能，开发难度，维护难度，文档难度等于系列东西之后，你就能看到好处了。

01年我设计的第一套系统最后几乎谈不上成功，多年后一直在思考失败的原因。其中最大的一个原因，
应该是因为我们没有直接拒绝当时公司领导的提议：我们要实现一个无限灵活，可以支持任何可能的政策系统。
新手总是会说，这样的想法能实现，为什么不做；那样的做法是客户想要的，我们应该考虑这个需求。
这些想法都没有错，但一定要和代价放在一起考虑；而且不是独立地考虑代价。

你的想法没有错，苹果的软件最多只能是二三流的水平，他们这样做当然不会有什么太大好处。
如果他们够牛x，Snow Leopard就不会是69刀，而是690刀了。但作为一个世界一等一的公司，
这种软件理念是值得学习的。这不是一个偶然的实现，你看看整套苹果的操作系统产品，都是以
简单、简洁、无歧义为理念的。

我再举个例子吧。窗口的缩放只有一个地方能控制，就是右下角的缩放控制点，这个控制点在很多时候
都让你觉得不方便，尤其是习惯了win的四个控制边和四个控制角的操作之后。但有没有想过，这样一个简化
能让开发人员和后期维护节约多少时间？让文档减少多少篇幅？也让用户减少多少学习时间？
你不能简单地说，一个控制点比四边四角控制做得好，那是笑话中的笑话，但从一个开发公司的角度来看方案，
这个方案更适合象苹果这种二三流的软件公司。而作为一个第十九流的软件公司，我觉得我的开发团队应该
跟苹果来学习，而不是跟老大微软来学习。

原帖由 woodheadz 于 21-8-2010 13:05 发表

 登录/注册后可看大图

没觉得苹果这个做法有什么好处
所谓的逻辑清晰因该是针对人而言，而不是针对计算机系统而言的。
类似不允许多一个小回车符这样的和人的自然思维相背离的逻辑，明显就是苹果的设计人员偷懒。
针对系统的简化有 ...

作者: kaile 时间: 21-8-2010 16:09
发人深省的观点

作者: coredump 时间: 21-8-2010 16:14
简单、简洁、无歧义是好理念，例子不是好例子

作者: yuba 时间: 21-8-2010 16:55

原帖由 key 于 21-8-2010 00:27 发表

 登录/注册后可看大图

手下的兄弟希望引入一个灵活，扩展性良好的系统。
这些想法我都明白，但我一再强调，简单，简化，无歧义。他不明白这样做的重要性。

原帖由 key 于 3-8-2010 16:58 发表

 登录/注册后可看大图

public static final int DEFAULT_PORT = XXXX;
与
public static final int PORT = XXXX;
是有很本质的区别的。事实上我做的事比这个还多一步。当然，吹毛求庇的事就不说了。

很难说“DEFAULT_PORT和PORT有本质区别”这件事儿，是为了打造：
“一个灵活，扩展性良好的系统”，还是
一个“简单，简化，无歧义”的系统

在我看来“老大期望在一台服务器上有且只有一个系统在跑，我坚持在同一个系统上，必须能理论上跑无限个系统。“更容易被理解为你想做“一个灵活，扩展性良好的系统”

看来你那个兄弟是东施效颦了

作者: woodheadz 时间: 21-8-2010 17:16
老丐说得好。
LZ你的大观点我是同意的，但你举的例子我实在是很不以为然

设计要力求简洁，但不是简陋。那个XML的例子说明的是苹果的简陋，而不是简洁。
而类似MAC OS这类的通用软件，以牺牲软件的可用性作为代价的“简洁”，就更是不值得赞赏啦。
我想你应该也做过GUI的编程，一个角落的Resizer和四个角落的Resizer基本上工作量是差不多的。苹果之所以只提供了一个角落的Resizer，只是出于他一贯的傲慢和自负。苹果有这个资格去傲慢，但去把他的傲慢当成优点去学习，我看还是算了吧

作者: key 时间: 21-8-2010 17:48

原帖由 yuba 于 21-8-2010 16:55 发表

 登录/注册后可看大图

很难说“DEFAULT_PORT和PORT有本质区别”这件事儿，是为了打造：
“一个灵活，扩展性良好的系统”，还是
一个“简单，简化，无歧义”的系统

在我看来“老大期望在一台服务器上有且只有一个系统在跑，我 ...

情况的确是这样。我关注系统的伸缩性，而关注伸缩性的方法是通过简化系统设计。
不过情况不同的是，我关注的是实现的完整性与正确性。作为一个专业的开发人员，
通过认真思考，并不难在逻辑上论证完整性与正确性的，如果你的系统相对简单的话；
但复杂了，连自己也搞不清的时候就很危险了。

说具体点，我们的配置里需要一种变量的赋值系统。这有点象spring的reflocal，
或者ant中的pathid。在此之前，我已经做了一套基于字符串的变量换名系统，
大致上就是解决类似：
JAVA_HOME=$HOME/java
PATH=$JAVA_HOME/bin

HOME/bin
之类的变量换名问题。而这位兄弟想扩展这个概念，把object引入再进行扩展，
比如有一个object是File，另一个object是String
NEW_FILE=$OLD_FILE/$NEW_FILENAME
做成一个文件定义。这个想法他觉得很灵活，很有用。但事实上这是行不通的，
因为你没有办法完整地定义这个替换系统，所有的实现只是个人的想当然。
这就是我坚决不能接受的地方。这个新的变化替换系统最终就会变成一个EL语言，
或者是一个错漏百出的配置系统。你永远不知道你的用户会在什么时候引入一个
你想象不出来的对象，然后试着把他换过来。如果换不过来，错就是你，因为
你连自己都搞不清你要做什么，你又怎样期望用户搞清他们在做什么呢？

把一个配置做得错漏百出，这当然没有必要。
那把一个配置文件变化一个EL又有必要吗？

作者: key 时间: 21-8-2010 18:01

原帖由 woodheadz 于 21-8-2010 17:16 发表

 登录/注册后可看大图

老丐说得好。
LZ你的大观点我是同意的，但你举的例子我实在是很不以为然
设计要力求简洁，但不是简陋。那个XML的例子说明的是苹果的简陋，而不是简洁。
而类似MAC OS这类的通用软件，以牺牲软件的可 ...

你能从例子中看到“不以为然”，看到“简陋”而不是“简洁”，那就证明我的例子没有举错。
我就是在举出一个简陋的例子。一个世界一等一的IT公司的“简陋”实现，如果被简单地理解成傲慢，
我觉得就有点轻率了。我不是一个果粉，我比很多人都b4苹果，我把它列入二三流的开发公司，
因为我和你一样，看到这种简陋。但我和你不一样，我看到这种简陋背后的意义。

你真的觉得一个resizer和四个操控边加四个操控角是一样的工作量？鼠标hover在各种不同的角、边上的
大量转换是一样的工作量？每个边角操作的文档说明是一个工作量？多个窗口重叠或位置接近时，边角沿线定义
和鼠标感应操作定义和实现是一个工作量？这个玩笑有点开大了。

苹果在很多人眼中是傲慢和自负的，这是苹果要建立的一种所谓对外“气质”。但对内，背后一大堆stakeholders能灭掉
这种无意义的风格。一个东西，在引入苹果系统里，并不可能象我们想象那样steve jobs一拍脑袋就进去的。
小得象我们这样的破公司都要经过几层管理层讨论才能定下来的事，苹果市值过千亿，就一拍脑袋能出系统，
那玩笑也开得有点大了。

作者: aroma 时间: 21-8-2010 18:23

作者: woodheadz 时间: 21-8-2010 18:27
其它就不说啦。。
关于Resizer，你自己再好好想想吧，一个角落和四个角落的工作量真的是差不多的

苹果财大气粗，你不会认为他们为了节省成本而不加这个功能吧？

作者: yuba 时间: 21-8-2010 18:34

原帖由 key 于 21-8-2010 17:48 发表

 登录/注册后可看大图

把一个配置文件变化一个EL又有必要吗？

一般的逻辑应该是问一件可能做到的事情的必要性，一件事儿不可能做到，管它必要不必要呢。你上面说的都是不可能（不可能满足需求，且不可能做到），如果不可能，就不用谈必要性了，对吧

我再说说可能性，他认为不可能的，你未必不能做到，反之亦然。你坚决不能接受的是你搞不清楚的东西，这个没有问题。但是同时，要接受别人能搞清楚的东西，或者说如何证明你不能接受的事情也是别人不能搞清楚的东西。

你和老大吵架也无非是让他知道“一些他认为不可能的东西，因为有你的经验，变得可能了”，“一些他认为不必要的东西，因为有你的预见，变得必要了”，对吧

那个哥们你认识我们不认识，如果他没有“多年的产品经验和运维经验”，不会预见一些你能预见的东西，不能做出那些你能够做出的东西。那么问题就简单了，没经验的shut up，对吧

作者: key 时间: 21-8-2010 18:42

原帖由 woodheadz 于 21-8-2010 18:27 发表

 登录/注册后可看大图

其它就不说啦。。
关于Resizer，你自己再好好想想吧，一个角落和四个角落的工作量真的是差不多的
苹果财大气粗，你不会认为他们为了节省成本而不加这个功能吧？

不会吧。我就算不计算任何模糊定义，单单 1 : 8 的工作量就已经摆在面前，你还觉得工作量差不多？
估计你说的是在有明确定义之后实现起来工作量差不多吧？这就好象有人说，这首歌有个3，那首歌是个4，唱起来工作量
都是一样。但我是立足于系统的设计者（不是graphic design）的角度来看这个问题，很明显，你考虑四边四角，至少
要将脑袋换 8 个位置想一下你的鼠标应该怎样变化吧？

苹果财大气粗，但在软件领域他算老几？所谓扬长避短，Snow Leopard才能弄个69元吐血跳楼价。
去看看win7旗烂版多少钱一套？

作者: key 时间: 21-8-2010 18:54

原帖由 yuba 于 21-8-2010 18:34 发表

 登录/注册后可看大图

我再说说可能性，他认为不可能的，你未必不能做到，反之亦然。你坚决不能接受的是你搞不清楚的东西，这个没有问题。但是同时，要接受别人能搞清楚的东西，或者说如何证明你不能接受的事情也是别人不能搞清楚的东西。

是的，如果他能搞清楚，而我不能搞清楚，我会接受他的方案，因为这是我能力以外的东西。
但如果他觉得自己搞清楚了，我听了半天，还是觉得他没搞清楚，你觉得他自己搞清楚的可能性有多少？
再者，你觉得用户有多大可能性接受你解释说，${object}有可能被当成一个完整的对象，但如果你设置为${object}/something，
马上变成一个字符串，而变成字符串的算法，是依据这个object所属于的class的toString()方法，具体能变成什么，
就看你的toString()里写了什么了。那你作为team leader，是接受这样的方案，还是不接受？
再接着，我们还有关于list, map的定义。下面是list:
1, ${object}, 2, ${obj2}
而map则是：
key1 : ${obj1}, key : ${obj2}
你又如何解释到底这里变成字符串还是变成对象？

那么问题就简单了，没经验的shut up，对吧

你觉得这样说，你还有多少机会从你的下属哪里听到有益的建议？

作者: woodheadz 时间: 21-8-2010 19:06

原帖由 key 于 21-8-2010 18:42 发表

 登录/注册后可看大图

不会吧。我就算不计算任何模糊定义，单单 1 : 8 的工作量就已经摆在面前，你还觉得工作量差不多？
估计你说的是在有明确定义之后实现起来工作量差不多吧？这就好象有人说，这首歌有个3，那首歌是个4，唱起来工作 ...

key同学，我觉得1个角对4个角1：4的工作量估计已经让我不可思议了，你现在还弄出1：8来了？

在你手下做小弟一定很巴适

如果这个工作是我安排的，我最多最多能接受的就是1：2。
苹果是不单纯靠存软件吃饭的，但不论苹果的软件研发力量再怎么臭（事实上我觉得苹果软件也很牛），说他连一个简单的Resizer都需要到考虑成本来决策是否采用，打死我都不信

作者: yuba 时间: 21-8-2010 19:16

原帖由 key 于 21-8-2010 18:54 发表

 登录/注册后可看大图

你觉得这样说，你还有多少机会从你的下属哪里听到有益的建议？

看到“那么”了，往前看，能找到“如果”吗？

我从你几次描述你的下属的情形，看到了他们应该“那么”做

作者: yuba 时间: 21-8-2010 19:18

原帖由 woodheadz 于 21-8-2010 19:06 发表

 登录/注册后可看大图

说他连一个简单的Resizer都需要到考虑成本来决策是否采用，打死我都不信

我也不信

作者: yuba 时间: 21-8-2010 19:26
仁者见之谓之仁，淫者见之谓之淫。每个人用苹果悟出的不是道，而是投射后的自己的想法。

否则，让你的老大和兄弟们都用苹果吧，不久你们就可以一切尽在不言中了。即使对开发方向产生了暂时的异议，当各自的心中浮现出苹果以后，problem 自然 solved。

作者: key 时间: 21-8-2010 19:32

原帖由 woodheadz 于 21-8-2010 19:06 发表

 登录/注册后可看大图

key同学，我觉得1个角对4个角1：4的工作量估计已经让我不可思议了，你现在还弄出1：8来了？
在你手下做小弟一定很巴适
如果这个工作是我安排的，我最多最多能接受的就是1：2。
苹果是不单纯靠存软 ...

我来数1 ：8看看吧，我不一定对，尽力而为了。
首先是resizer的定义，其实质是一个button，鼠标点击后进行拖动的定义是随着鼠标的位置做位置取值，然后用同样的值来输入窗口的长宽。
现在来定义边角控制。相应地进行client区内容的变化。
首先是上边，因为它是标题栏，标题栏的有重要的移动功能，现在考虑在y坐标在标题栏上下hover时的变化，由上至下移入，则变化成
双箭，继续移动，由双箭变成单箭，用来准备标题烂的移动功能。
然后是状态栏，箭头移入时有可能直接跨入client区，箭头因client区的要求变化。如果有状态栏区，则依照状态栏的箭头要求变化。
你再注意看，由内到外的移动，箭头在标题栏向上走的时候，会在离边沿比较远的地方变进行转换，转换后箭头的上沿正好点和窗体对齐，
但往下走的时候，鼠标要在一个很短的短离里跨过client区和下边沿。要知道下边沿不是一个象素的点，同时也没有鼠标箭头长，所以就
涉及到何时变化的问题。如果你注意的话，这个变化的位置和往上变化的位置是不同的。
再看角的变化，你拖动鼠标，在右上角进行沿角进行变动时，鼠标的变化与你在左下角沿角进行变动时是不同的。
上面的定义已经足够复杂了吧？

你觉得绝对没有 1 : 8 ，是因为别人已经做出来给你用，你觉得就是边角的问题，但作为一个设计者，必须把每个角和每条边都详细考虑
一次，还要针对不同的环境元素进行考虑。所以我说你不是从一个原始设计者的角度来看问题，而是站在一个应用系统的角度来看问题。

苹果再烂也不至于连个resizer做成边角控制的能力都没有。这个观点我非常同意。但苹果采用这种理念来控制了他的很多（如果不是全部的话）
的实现，就不是一个resizer的事了。

作者: key 时间: 21-8-2010 19:37

原帖由 yuba 于 21-8-2010 19:16 发表

 登录/注册后可看大图

看到“那么”了，往前看，能找到“如果”吗？

我从你几次描述你的下属的情形，看到了他们应该“那么”做

不明白你的意思。能不能说清楚一点？

作者: coredump 时间: 21-8-2010 19:39
我只说说你举的这个例子本身，为什么我说它不是个好例子。
在Mac下，有以下几种设置程序启动信息的方式(有好几个是我Google来的，从来没用过，不像Linux，想都不想都能罗列出10来个放配置文件的地方, Mac就是直接拿来用就好，不需要折腾玩):
1.
~/.profile
~/.cshrc
~/.tcshrc
2.
/etc/paths
3.
/etc/launchd.conf

4
~/.MacOSX/environment.plist

5.
Information Property List Key

以上几种环境变量的配置方式，会有互相覆盖的现象，比如.profile/.cshrc之类的会覆盖4的配置(如果你从shell启动UI的话), 其它几种配置的优先级不太清楚。总之，从这些方面来开，远谈不上简洁和高效，无歧义就更不是了[size=13.8889px]

[size=13.8889px]此外，这个是编辑[size=13.8889px]~/.MacOSX/environment.plist的专用[size=13.8889px]工具，比较会少犯错：
[size=13.8889px][size=13.8889px]Property List Editor application (located in <Xcode>/Applications/Utilities, where <Xcode> is your Xcode installation directory).

[size=13.8889px]Apple的一贯哲学是对用户极其关照，当傻子一样关照，对开发者极其恶劣(最近好转趋势明显). 简洁高效无歧义是对用户说的，简陋，苛刻和原始是对开发者来说的，虽然最近对开发者的照顾也提升了许多，不多，Apple一直都不是个对开发者友好的公司。

作者: yuba 时间: 21-8-2010 19:41
按住shift点击最小化按钮，我从这里悟出了你们应该推出带EL的配置文件

作者: yuba 时间: 21-8-2010 19:42

原帖由 key 于 21-8-2010 19:37 发表

 登录/注册后可看大图

不明白你的意思。能不能说清楚一点？

“那个哥们你认识我们不认识，如果他没有“多年的产品经验和运维经验”，不会预见一些你能预见的东西，不能做出那些你能够做出的东西。那么问题就简单了，没经验的shut up，对吧”

作者: key 时间: 21-8-2010 19:48

原帖由 yuba 于 21-8-2010 19:42 发表

 登录/注册后可看大图

“那个哥们你认识我们不认识，如果他没有“多年的产品经验和运维经验”，不会预见一些你能预见的东西，不能做出那些你能够做出的东西。那么问题就简单了，没经验的shut up，对吧”

原来是这样。这位同事经验少了些，满足你建议的shut up要求。
但我不能这样做，因为我还需要从他们那里听到更有益的建议。

作者: key 时间: 21-8-2010 19:50

原帖由 coredump 于 21-8-2010 19:39 发表

 登录/注册后可看大图

此外，这个是编辑~/.MacOSX/environment.plist的专用工具，比较会少犯错：
Property List Editor application (located in <Xcode>/Applications/Utilities, where <Xcode> is your Xcode installation directory).

如果我说我用的就是这东西来编辑的呢？

作者: yuba 时间: 21-8-2010 19:51

原帖由 key 于 21-8-2010 14:22 发表

 登录/注册后可看大图

01年我设计的第一套系统最后几乎谈不上成功，多年后一直在思考失败的原因。其中最大的一个原因，
应该是因为我们没有直接拒绝当时公司领导的提议：我们要实现一个无限灵活，可以支持任何可能的政策系统。

你们当时的公司领导从这件事悟出的是：这帮xx，四化蓝图都给你们画好了，还给我做出这么个破东西

作者: key 时间: 21-8-2010 19:57

原帖由 coredump 于 21-8-2010 19:39 发表

 登录/注册后可看大图

Apple的一贯哲学是对用户极其关照，当傻子一样关照，对开发者极其恶劣(最近好转趋势明显). 简洁高效无歧义是对用户说的，简陋，苛刻和原始是对开发者来说的，虽然最近对开发者的照顾也提升了许多，不多，Apple一直都不是个对开发者友好的公司。

其实你所说的东西和我所说的东西没有本质的冲突。
win把用户当傻子，是关照着这个傻子，让他能方便点。
苹果把用户当傻子，是让他不需要思考，拿起来就用。
你前面所说的shell变量设置在图形界面下不起作用，
或者我连苹果所定义的傻子都还不如，没有让他们用起来。

你说的苹果对开发者不友好，是指对采用苹果的api的开发者不友好吧？

作者: key 时间: 21-8-2010 20:01

原帖由 yuba 于 21-8-2010 19:51 发表

 登录/注册后可看大图

你们当时的公司领导从这件事悟出的是：这帮xx，四化蓝图都给你们画好了，还给我做出这么个破东西

哈哈哈，这个是有可能的。你想想一群没有开发背景的博士会想出什么东西来？
我当时让一个数学专业的人想了一个真的能最后解决他们想到的所有政策的政策系统，
从那以后，我就明白到，多难的点子，总有实现的方法，只在乎代价。

作者: key 时间: 21-8-2010 20:11

原帖由 yuba 于 21-8-2010 19:41 发表

 登录/注册后可看大图

按住shift点击最小化按钮，我从这里悟出了你们应该推出带EL的配置文件

关于键盘控制结合鼠标进行操作的问题我也有一些想法，
说出来让你批评一下。

我觉得因为键盘布局明确，容易说明，虽然必须两手操作。苹果的一键鼠标结合键盘，形成了
它自己的独特的风格。如果说这东西很牛x，那就有点吹了，但这东西定义的确比较明确，清晰。

现在苹果推荐的多点触控则正好相反，是否象wood同学说的钱多了，什么事都干得出来，我就不知道了。

作者: coredump 时间: 21-8-2010 20:16

原帖由 key 于 21-8-2010 19:50 发表

 登录/注册后可看大图

如果我说我用的就是这东西来编辑的呢？

那就更不属于无歧义了，典型的BUG

作者: key 时间: 21-8-2010 20:21

原帖由 coredump 于 21-8-2010 20:16 发表

 登录/注册后可看大图

那就更不属于无歧义了，典型的BUG

我copy & paste过去的，copy的时候带了回车，结果paste进去也回车了。你说bug，估计苹果是打死也不认的。
再说了，那个${ANT_HOME}/bin

PATH你也不能轻易说是bug嘛。
我后来发现这个问题，是因为我用env | grep 看到了最原始的定义。
不过，我觉得在shell执行的时候，bash应该是做过转换的。这是在shell一层做，
在苹果那里却没有做。

作者: woodheadz 时间: 21-8-2010 20:42

原帖由 key 于 21-8-2010 19:32 发表

 登录/注册后可看大图

我来数1 ：8看看吧，我不一定对，尽力而为了。
首先是resizer的定义，其实质是一个button，鼠标点击后进行拖动的定义是随着鼠标的位置做位置取值，然后用同样的值来输入窗口的长宽。
现在来定义边角控制。相应 ...

你其实给我分析了半天，还是只在分析一个resizer是怎么弄的，而没有说一个resizer和4个resizer工作量上有什么区别。

你这个“原始设计者”的视角，呵呵, 真够原始的...
不才刚好对UI编程方面略有心得，觉得你做这个Resizer有点要命，UI的编程哪有像你这样的思路:
首先不管是什么OS上做Resizer，肯定不会以Button为基础构建Resizer。第二，窗口的边框和窗口的内容一般是由不同的Handle来处理的消息，标题栏和状态栏也肯定是另一个独立的消息handle，所以你想象的要控制鼠标在各个区域不同的指针其实是很简单很自然的事，有什么困难的。
在边界的指针选择，无非就是判断下是左上-右下还是左下右上，真是再简单没有了。拖动调整窗口的逻辑，看起来像是“八个方向”，算法上要处理的其实只有横向和纵向的区别，只需几行简单的程序，四个Resizer全部搞定。

作者: woodheadz 时间: 21-8-2010 20:52

原帖由 key 于 21-8-2010 19:32 发表

 登录/注册后可看大图

但作为一个设计者，必须把每个角和每条边都详细考虑一次，还要针对不同的环境元素进行考虑

“设计者”的思路不是针对每条边+不同的环境元素进行考虑，而是对边角进行定性分析和归纳抽象，再研究这些抽象和系统内其它抽象元素间的关系。
一个系统里那么多东西，如果都像你这么死板板的思路，“设计者”非累死不可。即便累不死，用这种思路写的代码啊

我祈祷不要让我碰上了

作者: yuba 时间: 21-8-2010 21:21

原帖由 key 于 21-8-2010 19:48 发表

 登录/注册后可看大图

这位同事经验少了些，满足你建议的shut up要求。
但我不能这样做，因为我还需要从他们那里听到更有益的建议。

但愿他们愿意陪你玩儿

作者: key 时间: 21-8-2010 21:42

原帖由 woodheadz 于 21-8-2010 20:52 发表

 登录/注册后可看大图

“设计者”的思路不是针对每条边+不同的环境元素进行考虑，而是对边角进行定性分析和归纳抽象，再研究这些抽象和系统内其它抽象元素间的关系。
一个系统里那么多东西，如果都像你这么死板板的思路，“设计者”非 ...

相信你也从DOS时代走过来，如果你是win 1.0的设计者，你会怎样
设计你的系统？几行代码？

既然你在UI编程有心得，相信你也知道WinMain吧？WinMain里的事件响应模型
是怎样实现的？你再想想最早期的Win系统应该是如何定义这一系列东西？
每一个动作，都是有血有肉几百行上千行的代码。更不用说每个鼠标图标都需要
精心定义和设计了。

我很相信你理解我的意思。只是你站的角度和我的角度完全不同而已。

作者: key 时间: 21-8-2010 22:03

原帖由 woodheadz 于 21-8-2010 20:42 发表

 登录/注册后可看大图

你其实给我分析了半天，还是只在分析一个resizer是怎么弄的，而没有说一个resizer和4个resizer工作量上有什么区别。

你这个“原始设计者”的视角，呵呵, 真够原始的...
不才刚好对UI编程方面略有心 ...

我想到一个很有趣的证明，不知道你有没有兴趣。用你最熟悉的编程语言，不允许使用任何窗口创建和移动API，
直接用绘图方法来由头构建一个简单的可控大小的窗口系统，来响应鼠标事件，你试试看需要做什么？
如果再要求你必须不同于当于Windows系统的模式，另外建立一套界面，但需要实现四边四角的操控，
先不用考虑实现，你看看设计说明书应该怎样写？

你试试从这两个问题出发，考虑一下。我看过你之前的讨论，知道你是一个不错的程序员。如果我们能调整一下
视角，或者你有不同的看法。

当然，没兴趣就当我上面都是废话好了。

作者: woodheadz 时间: 21-8-2010 22:06

原帖由 key 于 21-8-2010 21:42 发表

 登录/注册后可看大图

相信你也从DOS时代走过来，如果你是win 1.0的设计者，你会怎样
设计你的系统？几行代码？

既然你在UI编程有心得，相信你也知道WinMain吧？WinMain里的事件响应模型
是怎样实现的？你再想想最早期的Win系统应 ...

唉，不幸我自己写过winmain,更不幸的是我甚至自己曾经用C从HitTest、消息分发开始写过UI系统...

我们之前说的是在一个已经成熟的平台（MacOS）上写Resizer，根本就用不到这些东西。我现在退一步，即便我们是凭空从消息循环开始写UI，我们是需要处理消息分发，重绘和失效之类的一大堆复杂问题，但这些问题我们只需要处理一次。
我们讨论的是Resizer，也就是窗口已经在那里了，我们只需要为他加上拖动改变大小的控制而已。我需要做的就是在非客户区对鼠标消息做点处理，修改下窗口大小，改改指针之类的，真是再简单不过了。
至于绘制Resizer，修改鼠标指针，这些工作肯定不用重头写一次吧？不管你是个窗口，还是个按钮或者是Resizer，都是用同样的方式，调用同样的代码。如果你非要说不是，那么只能说明UI系统的“设计者”过分脑残，也说明你说的UI系统非MacOS

[ 本帖最后由 woodheadz 于 21-8-2010 22:08 编辑 ]

作者: woodheadz 时间: 21-8-2010 22:22

原帖由 key 于 21-8-2010 22:03 发表

 登录/注册后可看大图

我想到一个很有趣的证明，不知道你有没有兴趣。用你最熟悉的编程语言，不允许使用任何窗口创建和移动API，
直接用绘图方法来由头构建一个简单的可控大小的窗口系统，来响应鼠标事件，你试试看需要做什么？
如果 ...

为了向你证明在Mac OS上可以很容易弄个Resizer出来，我得从窗口的绘制和移动开始？

那么我也给你出个题目吧，为了证明“不hard code PORT定义是个很简单的事”，你从编译器开始入手，来试试看需要做什么？不要把代码编辑器忘了哦，不然你连coding都做不了，更不要说不“hard coding”了。

不是想和你抬杠，只是想说你顶楼举的例子实在是不怎么地而已。
你把我们拉倒巨人Apple前面，我们可以和你一起仰视他，但仰视他不能说明他脚板边上那块发臭了死皮我们也一样需要仰视。也许我们是没资格去说他的脚臭，但捂鼻子权利还是要保留的

作者: woodheadz 时间: 21-8-2010 22:26

原帖由 花蕾般的钟声 于 21-8-2010 22:14 发表

 登录/注册后可看大图

再打你的屁屁！

回打屁屁100下

作者: coredump 时间: 21-8-2010 22:42
听到花蕾般的打屁声

作者: key 时间: 21-8-2010 22:43
我明白你的观点，其实你的观点就是，这些东西都有现成的支撑，
一句话就写完的东西，多想也是多余。

我也明白到通过软件分层，界面组件化之设计之后，这些东西即使重头开始做，
也不是一条边一个框地考虑。

我明白你这些观点。然后如果你喜欢觉得我脑残，我也没有办法。
不过你可能不明白，我和你一样b4这些臭脚皮，我只是思考一个市值两千亿（我没记错吧）的公司
的一块臭脚皮是怎样做出来的。如果一定要说，这是高傲的某人拍脑袋弄出来，我觉得可信度不高。

原帖由 woodheadz 于 21-8-2010 22:06 发表

 登录/注册后可看大图

唉，不幸我自己写过winmain,更不幸的是我甚至自己曾经用C从HitTest、消息分发开始写过UI系统...
我们之前说的是在一个已经成熟的平台（MacOS）上写Resizer，根本就用不到这些东西。我现在退一步，即便我们是 ...

作者: woodheadz 时间: 21-8-2010 22:48

原帖由 key 于 21-8-2010 22:43 发表

 登录/注册后可看大图

我明白你的观点，其实你的观点就是，这些东西都有现成的支撑，
一句话就写完的东西，多想也是多余。

我也明白到通过软件分层，界面组件化之设计之后，这些东西即使重头开始做，
也不是一条边一个框地考虑。

...

呵呵，求同存异，继续灌水

对了，还要去打那个花蕾般的屁屁

欢迎光临 FreeOZ论坛 (https://www.freeoz.org/ibbs/)