2006世界杯16强对阵图

nokia手机指令秘籍

A 一般指令

1 输入*#06#：显示IMEI码

2 输入*#0000#：显示软件版本

　　 (部分型号如果不起作用，可按*#型号代码#，如*#6110#)
　　
第一行--软件版本；

第二行--软件发布日期；

第三行--手机型号

3 输入*#92702689#查询更多的手机信息。有五个选项（可用上下方向键选择）：

　　①Serial No.：手机的IMEI码。

　　②Made：手机的制造日期.

　　③Purchasing Date：购买日期，此日期一经设定不可更改，新机子应该是mmyyyy

　　④Repaired：维修次数的记录。新机子应该是mmyyyy

　　⑥Life timer：新机子是6553501。

B 高级指令 （专门为各位大侠准备的, ^_^ 建议一般初学者不要随便输入，以免输入错误导致手机无法复原！）

　　1 速率编码

　　*3370#或*efr#：开启(EFR)全速率编码
　　
#3370#或#efr#：关闭全速率编码

　　（开启全速增强型编码模式，可改善话音质量但会耗电）

　　*4720#或*hra0#：开启(HR)半速率编码

　　#4720#或#hra0#：关闭半速率编码

　 （话音质量降低，但可延长电池大概30%左右使用时间，需网络支持）

　　键入这些代码后，会关机重开，然后才能生效。

　　2 SIM卡锁信息

　　*#746025625# (= *#sim0clock#)：如果SIM卡能被锁，进行检测时键入该指令后，手机显示"SIM CLOCK STOP ALLOWED" or "SIM CLOCK STOP NOT ALLOWED"，这取决于你的SIM卡。

　　SIM卡锁信息：包括四种不同的锁

　　1).国家锁--锁指定的国家

　　2).网络锁--锁指定的网络

　　3).供应商锁--锁服务提供商

　　4).SIM卡锁--锁指定的SIM卡

3 查询手机是否锁频

　　首先必须找出设定手机时必须使用的几个键。其中，连续按*键二次即出现"+"；连续按*键三次即出现"p"；连续按*键四次即出现"w"。然后，你就可以依次顺序输入相应组合键。

　　#pw+1234567890+1#：查询是否锁国家码

　　#pw+1234567890+2#：查询是否锁网络码

　　#pw+1234567890+3#：查询是否锁网络提供者锁定的码

　　#pw+1234567890+4#：查询是否锁SIM卡

　　4 电源按键

　　轻触电源键，屏幕将显示情景模式的选单，你可以通过上下键快速地在各个模式中切换。在键盘锁模式下打开屏幕灯，你曾感受过在夜晚摸黑想打开手机的键盘锁的烦恼吗？其实你可以轻触电源键，这时屏幕和键盘的夜灯将会打开，这样你就可以从容地分辨按键打开键盘锁了。

　　
　　5 查看手机状态

　　操作指令：#pw+(mastercode)+X#

　　(mastercode)是一10位数(没有括号) X是一个1到4的数, 它显示以上的锁，还不确定何数对应何锁。

　　SIM卡不限制信息，意味着你的电话还没锁。

　　1).VIN CHARGER INPUT VOLTAGE 8.4V 0.8A

　　2).CHRG CTRL CHARGER CONTROL PWM 32Khz

　　3).XMIC MIC INPUT 60mV - 1V

　　4).SGND SIGNAL GROUND

　　5).XEAR EAR OUTPUT 80mV - 1V

　　6).MBUS 9600 B/S

　　7).FBUS_RX 9.6 - 230.4 KB/S

　　8).FBUS_TX 9.6 - 230.4 KB/S

　　9).L_GND CHARGER / LOGIC GND

C 诺基亚其他手机指令内容　

　　1 NOKIA 9000/9000i

　　1).显示IMEI号：*#06#

　　2).显示软件版本号：*#682371158412125# 最新版本在电话信息下面

　　3).显示制造星期和年： *#3283#

　　4).电话类型： GE8

　　2 5110锁码机解码

　　操作步骤：按C,按下 -> 按C不放 -> 按*不放 ->按*不放 ->

　　键入04*PIN*PIN*PIN#，就完成了。

　　3 更换当前号码

按住#键不放约一秒钟，屏幕会出现“交换号码？” ，按确认后屏幕上方会出现一个2字，这时手机不能拨出但能接听来电。取消重操作一次，利用它可达到锁机的效果。在非来电时进入来电菜单，持续按住功能键两秒，将进入来电菜单，而这个菜单平时只是会在有电话打入时才会出现的。

　　4 6110在待机画面显示名字

　　选择一个最不常使用的操作模式，通常是寻呼机 Menu3-5，将个人化选择Menu3-5-2设定完后，重新命名Menu3-5-3为自己的名字，启动后即可。备注：若要恢复为寻呼机，重新命名Menu3-5-3为空白即可。

D 查验“手机串号”：www.chinamobile.gov.cn；

　　辨别“进网许可证”真伪：www.tenaa.com.cn！

　　如果买的是原装水货，一般来说质量还是行的；如果是改版就难说了，不法商家私自将英文机改装成中文机，将英文机软件置换，使之可以输入中文。此种手机在使用中可能会出现字符乱码、死机等现象。

E　还有一个鲜为人知的：

　　恢复GMS蜂窝网运营商的工程代码：*#67705646#如果是“全球通”或“神州行”的SIM卡就将待机画面恢复为“中国电信”或“中国移动”；如果是中国联通用户，就显示为“中国联通”！

关于Portal

这里所说的Portal是指JCP-JSR168规范所描述的：Portal是一个基于Web的应用，通常它提供个性化、单点登录、内容集成和显示等功能。Portal技术包括三个方面：

1） Portal服务器(Portal Server)；

2） Portlet容器；(Portlet Container)

3） Portlet。

1) Portal Server 的定义是

一个 Portal（门户网站）就是指一个 Web-based 的系统，通常都会提供个人化设置、单一登陆、以及由各种不同来源或不同网站取得各式各样的信息，并且将这些信息放在网页之中组合而成的呈现平台，门户网站会有精巧的个人化设置去提供定制的网页，当不同等级的使用者来浏览该页面将获得不同的信息内容。

负责接收HTTP请求，调用portlet，并将portlet产生的内容聚集到portal page返回给客户。

2) Portlet Container 的定义是

portlet container 是提供 portlets 执行的环境，包含了许多 portlets 并且管理他们的生命周期，他也会永远保存着 portlets 的喜好设置，一个 portlet container 接收到来自 portal 的请求后，接着将这个请求传递给存在 container 的 portlet 执行。portlet container 没有义务去组合 portlets 产生的信息內容，这个工作必须由 portal 来处理。portal 和 portlet container 可以放在一起视为同一个系统的组件，或者分开成为两个独立的组件。

负责提供portlet的运行时环境，管理portlet的生命周期，还负责提供portlet持久化能力。

3) Portlet 的定义是

一个 Portlet 是以 Java 技术为技术的 Web 组件，由 Portlet Container 所管理，专门处理客户的 request 以及产生各种动态的信息内容。Portlets 为可插式 ( pluggable ) 的客户界面组件，提供呈现层成为一个信息系统。这些由 portlet 产生的内容也被称为片段 (fragment)，而片段是具有一些规则的Markup( HTML、XHTML、WML )，而且可以和其他的片段组合而成一个复杂的文件。而 Portlet 中的内容正常来说是与其他 Portlet 的内容聚合而成为一个 Portal 网页。而 Portlet 的生命周期是被 Portlet Container 所管理控制的。客户端和 portlets 的互动是由 portal 通过典型的 request/response 方式实现，正常来说，客户会和 portlets 所产生的内容互动，举例来说，根据下一步的连接或者是确认送出的表单，结果 portal 将会接收到 portlet 的动作，将这个处理状况转向到目标 portlet。这些 portlet 内容的产生可能会因为不同的使用者而有不同的变化，完全是根据客户对于这个 portlet 的设置。

Portal主要是解决企业信息和应用的前端集成问题，它负责连结企业后台EAI，集成企业的结构和非结构化信息，并提供统一的访问企业信息和应用的入口。

(摘自JSR168规范文档)

portlet 与 servlet 的关系
Portlet 和 Servlet 算是兄弟有那么一点点相似却又有那么一点点不同，因为 Servlet 和 Portlet 不尽然相同，所以研究小組決定将 portlets 定义成为一个新的组件，因此定义了 portlets 一个新的并且明确的界面与行为。为了尽可能与现有的 servlet 结合达到重复使用的目的，portlet 的规范利用了 servlet 的规范，许多观念都很相似的，结合 portlets、servlets 及 jsp 在同一个网站系统中，我们称为 portlet application 。在同一个 portlet application 中，他们将分享同一个 classloader，context 及 session。

1) Portlet 和 Servlet 的相似之处

@ portlets 也是 Java 技术的 web 组件
@ portlets 也是有特定的 container 在管理
@ portlets 可以动态产生各种内容
@ portlets 的生命周期由 container 所管理
@ portlets 和客户端的互动是通过 request/response 的机制

2) Portlet 和 Servlet 也有一些不同

@ portlets 只产生 markup 信息片段，不是完整的网页文件。而 Portal 会将所有的 Portlet markup 信息片 段放到一个完整的 Portal 网页。
@ portlets 不会和 URL 有直接的关系
@ 客户端必须通过 portal 系统才能和 portlets 互动
@ portlets 有一些定义好的 request 处理，action request 以及 render request。
@ portlets 默认定义 portlet modes 及窗口状态可以指出在网页中该 portlet 的哪个功能正在执行及现在的 状态。
@ portlets 可以在同一个 portal 网页之中存在多个。

3) Portlet 有一些附加的功能是 Servlet 所没有的

@ Portlets 能够存取及储存永久配置文件及定制资料。
@ portlets 可以存取使用者数据
@ portlets 具有 URL 的重写功能在文件中去动态建立连结，允许 portal server 不用去知道如何在网页的片 段之中建立连结及动作。
@ portlets 可以储存临时性的数据在 portlet session 之中，拥有两个不同的范围：
application-wide scope 及 portlet private scope 。

4) Portlet 不具有一些功能， 但是 Servlet 却有提供

@ servlet 具有设置輸出的文字编码( character set encoding)方式
@ servlet 可以设置 HTTP 输出的 header
@ servlet 才能夠接收客户对于 portal 发出的 URL 请求

基于Portal开发项目的优势
1、可以与以后新开发的或已集成到Portal中的企业应用实现无缝集成。

2、可以分享Portal服务器和Portlet容器提供的种种功能。这要视Portal服务器提供商而定。

3、由于Portlet已规范化（JSR168），所以应用中开发的Portlet可以部署在不同的Portal服务器上。

Lost全图

这几天好累

在北京机场待了三天，接了很多牛人来参加应用数学国际会议。这个会议可以说和我有关，也可以说和我无关。

大部分外国学者还是很nice的，除了极个别人。最有印象的还是Rudy，看样子很乐观，也很有趣。MIT的 Gareth H. McKinley 竟然夸我，"Your English is very excellent. Have you been to America?" 呵呵，搞得我真是不好意思。在我看来，训练英语还真不如到机场大厅找外国人聊天，应该会进步神速。

国内的航班还是有些问题，有的航班甚至会晚点好几个小时，我问的时候竟然告诉我是正点起飞。

最主要还是困啊，白天接人，晚上看球，在机场都可以睡着，搞得我现在腿都疼得不行。

纸张尺寸

http://publish.it168.com/cword/2672.shtml

纸张的的大小和形状是由长、宽尺寸决定的。其长、宽尺寸是依据印刷品的开法（最常用的为几何级数开切为32开）和印版的要求由国家主管部门规定的。国际标准尺寸是根据DLN476（德国工业标准）由ISO国际标准化组织推荐使用的。这个标准尺寸是根据奥斯特瓦尔教授的标准尺寸制定的。纸张长边和短边的比例是：1：2或1：1.414。这种尺寸无论是对开、四开或八开，其长边与短边的比例始终保持一样。国外不少国家都采用这个长宽比，我国也是这样，因此目前我们使用的打印、复印纸长边和短边的比例都是1：1.414。下边列出了常见纸张大小的尺寸：

研究图论的一个辅助工具

http://www.mi.sanu.ac.yu/newgraph/index.html

newGRAPH is a fully integrated environment used for improving a research
process in graph theory. Its purpose is:

• help a researcher pose, verify or disprove a conjecture
• experiment with graphs
• educative application

It is a new version of GRAPH, written by Dragoš Cvetković
and his collaborators. It is currently being developed by Dragan Stevanović
and Vladimir Brankov, with Dragoš Cvetković and Slobodan Simić
serving as consultants.

How to write a Makefile

How to write a Makefile

Introduction

Make is one of the original Unix tools for Software Engineering. By
S.I. Feldman of AT&T Bell Labs circa 1975. But there are public
domain versions (eg. GNU) and versions for other systems
(eg. Vax/VMS).

Related tools are the language compilers (cc, f77, lex, yacc, etc.)
and shell programming tools (eg. awk, sed, cp, rm, etc.). You need to
know how to use these.

Important adjuncts are lint (source code checking for obvious errors)
ctags (locate functions, etc. in source code) and mkdepend. These are
nice, and good programmers use them.

Important, and related tools, are the software revision systems SCCS (Source Code Control System) and RCS (Revision Control System -- the recommended choice)

The idea is to automate and optimize the construction of
programs/files -- ie. to leave enough foot prints so that others can
follow.

Makefile Naming

make is going to look for a file called Makefile, if not found then a
file called makefile. Use the first (so the name stands out in
listings).

You can get away without any Makefile (but shouldn't)! Make has
default rules it knows about.

Makefile Components

• Comments

  Comments are any text beginning with the pound (#) sign. A
  comment can start anywhere on a line and continue until the end of the
  line. For example:
  

  
  
  # $Id: slides,v 1.2 1992/02/14 21:00:58 reggers Exp $
  
  

• Macros

  Make has a simple macro definition and substitution mechanism. Macros are defined in a Makefile as = pairs. For example:
  

  
  
  MACROS=  -me
  
  PSROFF=  groff -Tps
  
  DITROFF= groff -Tdvi
  
  CFLAGS= -O -systype bsd43
  
  

  
  There are lots of default macros -- you should honor the existing naming conventions. To find out what rules/macros make is using type:
  

  
  
  % make -p
  
  
  

  
  NOTE: That your environment variables are exported into the make as macros. They will override the defaults.
  

  
  You can set macros on the make command line:
  

  
  
  % make "CFLAGS= -O" "LDFLAGS=-s" printenv
  
     cc -O printenv.c -s -o printenv
  
  

• Targets

  You make a particular target (eg. make all), in none specified then the first target found:
  

  
  
  paper.dvi: $(SRCS)
  
         $(DITROFF) $(MACROS) $(SRCS) >paper.dvi
  
  

  NOTE: The the line beginning with $(DITROFF) begins with TAB not spaces.
  
  The target is made if any of the dependent files have changed. The dependent files in this case are represented by the $(SRCS) statement.

• Continuation of Lines

  Use a back slash (\). This is important for long macros and/or rules.
  

  
  

• Conventional Macros

  There are lots of default macros (type "make -p" to print out the defaults). Most are pretty obvious from the rules in which they are used:
  

  
  
  AR = ar
  
  GFLAGS =
  
  GET = get
  
  ASFLAGS =
  
  MAS = mas
  
  AS = as
  
  FC = f77
  
  CFLAGS =
  
  CC = cc
  
  LDFLAGS =
  
  LD = ld
  
  LFLAGS =
  
  LEX = lex
  
  YFLAGS =
  
  YACC = yacc
  
  LOADLIBS =
  
  MAKE = make
  
  MAKEARGS = 'SHELL=/bin/sh'
  
  SHELL = /bin/sh
  
  MAKEFLAGS = b
  
  

• Special Macros

  
  Before issuing any command in a target rule set there are certain special macros predefined.

  
  

  
  
  1. $@ is the name of the file to be made.
     
  2. $? is the names of the changed dependents.
     

  
  So, for example, we could use a rule
  

  
  
  printenv: printenv.c
  
          $(CC) $(CFLAGS) $? $(LDFLAGS) -o $@
  
  

  
  alternatively:
  

  
  
  printenv: printenv.c
  
          $(CC) $(CFLAGS) $@.c $(LDFLAGS) -o $@
  
  

  
  There are two more special macros used in implicit rules. They are:
  
  
  
  1. $< the name of the related file that caused the action.
     
  2. $* the prefix shared by target and dependent files.
     

• Makefile Target Rules

  The general syntax of a Makefile Target Rule is
  

  
  
      target [target...] : [dependent ....]
  
      [ command ...]
  
  

  
  Items in brackets are optional, ellipsis means one or more.
  Note the tab to preface each command is required.
  

  
  The semantics is pretty simple. When you say "make target"
  make finds the target rule that applies and, if any of the
  dependents are newer than the target, make executes the com-
  mands one at a time (after macro substitution). If any
  dependents have to be made, that happens first (so you have
  a recursion).
  

  
  A make will terminate if any command returns a failure sta-
  tus. That's why you see rules like:
  

  
  
  clean:
  
          -rm *.o *~ core paper
  
  

  
  Make ignores the returned status on command lines that begin
  with a dash. eg. who cares if there is no core file?
  

  Make will echo the commands, after macro substition to show
  you what's happening as it happens. Sometimes you might want
  to turn that off. For example:
  

  
  
  install:
  
          @echo You must be root to install
  
  

  
  

• Example Target Rules

  
  For example, to manage sources stored within RCS (sometimes
  you'll need to "check out" a source file):
  

  
  
  SRCS=x.c y.c z.c
  
  
  $(SRCS):
  
          co $@
  
  

  
  To manage sources stored within SCCS (sometimes you'll need
  to "get" a source file):
  

  
  
  $(SRCS):
  
          sccs get $@
  
  

  
  Alternativley, to manage sources stored within SCCS or RCS
  let's generalize with a macro that we can set as required.

  
  
  SRCS=x.c y.c z.c
  
  # GET= sccs get
  
  GET= co
  
  
  $(SRCS):
  
          $(GET) $@
  
  

  
  For example, to construct a library of object files
  

  
  
  lib.a: x.o y.o z.o
  
          ar rvu lib.a x.o y.o z.o
  
          ranlib lib.a
  
  

  
  Alternatively, to be a bit more fancy you could use:
  

  
  
  OBJ=x.o y.o z.o
  
  AR=ar
  
  
  lib.a: $(OBJ)
  
          $(AR) rvu $@ $(OBJ)
  
          ranlib $@
  
  

  
  Since AR is a default macro already assigned to "ar" you can
  get away without defining it (but shouldn't).
  

  
  If you get used to using macros you'll be able to make a few
  rules that you can use over and over again.
  
  For example, to construct a library in some other directory
  

  
  
  INC=../misc
  
  OTHERS=../misc/lib.a
  
  $(OTHERS):
  
          cd $(INC); make lib.a
  
  

  
  Beware:, the following will not work (but you'd think it
  should)
  

  
  
  INC=../misc
  
  OTHERS=../misc/lib.a
  
  
  $(OTHERS):
  
          cd $(INC)
  
          make lib.a
  
  

  
  Each command in the target rule is executed in a separate
  shell. This makes for some interesting constructs and long
  continuation lines.
  

  
  To generate a tags file
  

  
  
  SRCS=x.c y.c z.c
  
  CTAGS=ctags -x >tags
  
  
  tags:   $(SRCS)
  
          ${CTAGS} $(SRCS)
  
  

  
  On large projects a tags file, that lists all functions and
  their invocations is a handy tool.
  
  
  To generate a listing of likely bugs in your problems
  

  
  
  lint:
  
          lint $(CFLAGS) $(SRCS)
  
  
  

  
  Lint is a really good tool for finding those obvious
  bugs that slip into programs -- eg. type classes, bad argu-
  ment list, etc.
  

  
  

• Some Basic Make Rule
  

  
  People have come to expect certain targets in Makefiles. You
  should always browse first, but it's reasonable to expect
  that the targets all (or just make), install, and clean will
  be found.
  

  
  

  
  
  1. make all -- should compile everything so that you can do local testing before installing things.
     
  2. make install -- should install things in the right places. But watch out that things are installed in the right place for your system.
     
  3. make clean -- should clean things up. Get rid of the executables, any temporary files, object files, etc.

  
  

  
  You may encounter other common targets, some have been
  already mentioned (tags and lint).
  

• An Example Makefile for printenv

  
  

  
  
  # make the printenv command
  
  #
  
  OWNER=bin
  
  GROUP=bin
  
  CTAGS= ctags -x >tags
  
  CFLAGS= -O
  
  LDFLAGS= -s
  
  CC=cc
  
  GET=co
  
  SRCS=printenv.c
  
  OBJS=printenv.o
  
  SHAR=shar
  
  MANDIR=/usr/man/manl/printenv.l
  
  BINDIR=/usr/local/bin
  
  DEPEND= makedepend $(CFLAGS)
  
  all:    printenv
  
  
  # To get things out of the revision control system
  
  $(SRCS):
  
          $(GET) $@
  
  # To make an object from source
  
         $(CC) $(CFLAGS) -c $*.c
  
  # To make an executable
  
  printenv: $(OBJS)
  
          $(CC) $(LDFLAGS) -o $@ $(OBJS)
  
  # To install things in the right place
  
  install: printenv printenv.man
  
          $(INSTALL) -c -o $(OWNER) -g $(GROUP) -m 755 printenv $(BINDIR)
  
          $(INSTALL) -c -o $(OWNER) -g $(GROUP) -m 644 printenv.man $(MANDIR)
  
  # where are functions/procedures?
  
  tags: $(SRCS)
  
          $(CTAGS) $(SRCS)
  
  # what have I done wrong?
  
  lint: $(SRCS)
  
          lint $(CFLAGS) $(SRCS)
  
  # what are the source dependencies
  
  depend: $(SRCS)
  
          $(DEPEND) $(SRCS)
  
  # to make a shar distribution
  
  shar:   clean
  
          $(SHAR) README Makefile printenv.man $(SRCS) >shar
  
  # clean out the dross
  
  clean:
  
          -rm printenv *~ *.o *.bak core tags shar
  
  # DO NOT DELETE THIS LINE -- make depend depends on it.
  
  printenv.o: /usr/include/stdio.h
  
  

• Makefile Implicit Rules

  
  Consider the rule we used for printenv
  

  
  
  printenv: printenv.c
  
          $(CC) $(CFLAGS) printenv.c $(LDFLAGS) -o printenv
  
  

  
  We generalized a bit to get
  

  
  
  printenv: printenv.c
  
          $(CC) $(CFLAGS) $@.c $(LDFLAGS) -o $@
  
  

  
  The command is one that ought to work in all cases where we
  build an executable x out of the source code x.c This can be
  stated as an implicit rule:
  

  
  
  .c:
  
          $(CC) $(CFLAGS) $@.c $(LDFLAGS) -o $@
  
  

  
  This Implicit rule says how to make x out of x.c -- run cc
  on x.c and call the output x. The rule is implicit because
  no particular target is mentioned. It can be used in all
  cases.
  

  
  Another common implicit rule is for the construction of .o
  (object) files out of .c (source files).
  

  
  
  .o.c:
  
          $(CC) $(CFLAGS) -c $<
  
  

  alternatively
  

  
  
  .o.c:
  
          $(CC) $(CFLAGS) -c $*.c
  
  

• Make Dependencies

  
  It's pretty common to have source code that uses include
  files. For example:
  

  
  
  % cat program.c
  
  
  #include        
  
  #include        "defs.h"
  
  #include        "glob.h"
  
          etc....
  
  main(argc,argv)
  
          etc...
  
  

  The implicit rule only covers part of the source code depen-
  dency (it only knows that program.o depends on program.c).
  The usual method for handling this is to list the dependen-
  cies separately;
  

  
  
          etc...
  
          $(CC) $(CFLAGS) -c $*.c
  
          etc...
  
  program.o: program.c defs.h glob.h
  
  

  
  Usually an implicit rule and a separate list of dependencies
  is all you need. And it ought to be easy enough to figure
  out what the dependencies are.
  

  
  However, there are a number of nice tools around that will
  automatically generate dependency lists for you. For example
  (trivial):
  

  
  
  DEPEND= makedepend $(CFLAGS)
  
          etc...
  
  # what are the source dependencies
  
  
  depend: $(SRCS)
  
          $(DEPEND) $(SRCS)
  
          etc....
  
  # DO NOT DELETE THIS LINE -- ....
  
  printenv.o: /usr/include/stdio.h
  
  

  
  These tools (mkdepend, mkmkf, etc.) are very common these
  days and aren't too difficult to use or understand. They're
  just shell scripts that run cpp (or cc -M, or etc.) to find
  out what all the include dependencies are. They then just
  tack the dependency list onto the end of the Makefile.
  

  
  

SuSE10.1的Xgl

按照http://www.novell.com/coolsolutions/feature/17174.html
的说明直接可以安装成功。

只是在安装完Xgl和compiz，并且做完设置以后还需要重启gnome才能打开gnome-session-properties继续进行设置。
最后的效果截图：