]]>
Nokia today announced that its Qt cross-platform user interface (UI) and application framework for desktop and embedded platforms will be available under the open source LGPL version 2.1 license from the release of Qt 4.5, scheduled for March 2009. In addition:
- Qt source code repositories will be made publicly available and will encourage contributions from desktop and embedded developer communities.
- Service offerings for Qt will be expanded to ensure that all Qt development projects can have access to the same levels of support, independent of the selected license.
We have some exciting news we’d like to share with the free software community: Qt will be licensed under the terms of the LGPL version 2.1 with the upcoming Qt 4.5 release, in addition to our standard GPL and commercial licenses. We are also pleased to announce that we are going to open up the Qt source code repository and also make it easier for the community to contribute to Qt.
Adding LGPL version 2.1 will greatly increase adoption of Qt across Windows, Linux, embedded Linux, Mac, S60, Windows CE, maemo, and Ovi web services. Having a larger number of users, including Nokia developers, providing feedback and contributions will help Qt remain a cutting edge, robust UI and application framework.
Going forward we will speed up the development of Qt using additional resources and work in even closer cooperation with the free software community. We will do this in a number of ways, including:
- Employing more Qt developers
- Opening our source code repository
- Reducing the overhead needed to make a submission, including no longer requiring copyright assignments.
- Launching a new web infrastructure to support contributions later this year.
As we know that license versions are important for many in the free software community, we wanted to also take the opportunity to provide some highlights of our upcoming changes:
- Versions of Qt prior to 4.5 are not impacted by this announcement
- We will continue to support the GPL version 2 through the newly added LGPL version 2.1 license, as it allows for the automatic conversion to the GPL.
- We will continue to release Qt under GPL 3
As a first step we have selected LGPL version 2.1 as this is the version of the LGPL that best fits our purposes and we are most comfortable with at this point in time. We will continue to evaluate the adoption, use and legal interpretation of LGPL version 3 by the community and may use this version of the LGPL for future releases.
Finally, we will open the Qt repositories and provide more information regarding how interested parties can contribute to Qt with the release of Qt 4.5, which is scheduled for March. Until then, if you have any questions, please feel free to post your questions below.
Sincerely,
Sebastian Nyström
Vice President, Qt Software
]]>
]]>
作者Matthias EttrichQ译者Googol LeeQ原文地址?a >q里?
在奇（TrolltechQ，Z改进Qt的开发体验，我们做了大量的研I。这文章里Q我打算分n一些我们的发现Q以及一些我们在设计Qt4时用到的原则Qƈ且展C如何把q些原则应用C的代码里?
设计应用E序接口QAPIQ是很难的。这是一门和设计语言同样隄艺术。这里可以选择太多的原则，甚至有很多原则和其他原则有矛盾?
现在Q计机U学教育把很大的力气攑֜法和数据结构上Q而很关注设计语a和框架背后的原则。这让应用程序员完全没有准备去面对越来越重要的Q务：创造可重用的组件?
在面向对象语a普及之前Q可重用的通用代码大部分是由库提供者写的，而不是应用程序员。在Qt的世界里Q这U状冉|了明昄改善。在M时候，用Qt~程是写新的组件。一个典型的Qt应用E序臛_都会有几个在E序中反复用的自定义组件。一般来_同样的组件会成ؓ其他应用E序的一部分。KDEQK桌面环境Q走得更q，用许多追加的库来扩展QtQ实C数百个附加类。（一般来_一个类是一个可重用lgQ原文这里没有写清楚。）
但是Q一个好的，高效的C++ API是由什么组成的呢？是好q是坏，取决于很多因素——比如，手头的工作和特定的目标群体。好的API有很多特性，一些特性是大家都想要的Q而另一些则是针对特定问题域的?
好的API的六个特?/h2>
API是面向程序员的，用来描述提供l最l用LGUI是什么样子。API中的P带表E序员（ProgrammerQ，而不是程序（ProgramQ，用来API是给E序员用的，lhcȝE序员用的?
我们坚信API应该是最化且完整的Q拥有清C单的语义Q直觉化Q容易记忆，q且引导人写出易ȝ代码?
- 最化Q?/strong>最化的API是指一个类可能只拥有最的公开成员且尽可能只拥有最的cR这个原则可以让API更简单易懂，更好讎ͼ更容易除错，且更Ҏ改变?
- 完整的：完整的API是指要提供所有期望的功能。这个可能与最化原则相冲H。另外，如果一个成员函数属于一个不应该属于的类Q很多潜在的使用者都会找不到q个函数?
- 拥有清晰且简单的语义Q?/strong>像其他设计工作一P你必遵守最惊奇原则（the principle of least surpriseQ。让常见的Q务简单易行。不常见的工作可行，但不会让用户q分x。解决特D问题时Q不要让解决Ҏ没有必要的过度通用。（比如QQt3中的QMimeSourceFactory可以通过调用QImageLoader来实C同的API。）
- 直觉化：像电脑上的其他东西一PAPI必须是直觉化的。不同的l验和背景会D在判断什么是直觉而什么不是时不同的感觉。如果一个中U用户不L就可以使用Qa semi-experienced user gets away without reading the documentationQ没懂这里的get away该怎么译Q，q且一个程序员不懂API可以理解羃写的代码Q这UAPI是直觉化的?
- 易于记忆Q?/strong>让API易于记忆Q用统一且精的命名Ҏ。用可识别的模式和概念Qƈ且避免羃写?
- 引导易读的代码（Lead to readable codeQ：代码一l写，会读Qƈ且除错和修改Q多ơ。易ȝ代码可能会花Ҏ间来写，但是可以节省产品周期中的其他旉?
最后，CQ不同类型的用户会用到API的不同部分。虽然简单的实例化一个QtcL非常直觉化的Q让资深专家在试囑֭cd之前M遍文，是很合理的?
便利陷阱
q是个常见的误解Q更好的APIQ用更少的代码完成一件事。永q记住代码一ơ写，之后需要不断的阅读q理解。比如：
QSlider *slider = new QSlider(12, 18, 3, 13, Qt::Vertical, 0, "volume");
q比下面那样难读Q甚至难写）Q?
QSlider *slider = new QSlider(Qt::Vertical); slider->setRange(12, 18); slider->setPageStep(3); slider->setValue(13); slider->setObjectName("volume");
布尔参数陷阱
布尔参数通常会导致不易读的代码。更q一步，l一个已l存在的函数加入一个布参敎ͼq常常是个错误。在Qt里，一个传l的例子是repaint()Q这个函数带有一个布参敎ͼ来标识是否擦除背景（默认擦除Q。这让代码通常写成Q?
widget->repaint(false);
初学者很Ҏ把这句话理解?#8220;别重?#8221;Q?
q样做是考虑到布参数可以减一个函敎ͼ避免代码膨胀。事实上Q这反而增加了代码量。有多少Qt用户真的C了下面三行程序都是做什么的Q?
widget->repaint(); widget->repaint(true); widget->repaint(false);
一个好一些的API可能看v来是q样Q?
widget->repaint(); widget->repaintWithoutErasing();
在Qt4里，我们重新设计了widgetQ得用户不再需要不重画背景的重画widgetQ来解决q个问题。Qt4原生支持双缓存，废掉了这个特性?
q里q有一些例子：
widget->setSizePolicy(QSizePolicy::Fixed, QSizePolicy::Expanding, true); textEdit->insert("Where's Waldo?", true, true, false); QRegExp rx("moc_*.c??", false, true);
一个显而易见的解决Ҏ是，使用枚Dcd代替布尔参数。这正是我们在Qt4?a >QString大小写敏感时的处理方法。比较：
str.replace("%USER%", user, false); // Qt 3
str.replace("%USER%", user, Qt::CaseInsensitive); // Qt 4
静态多?/h2>
怼的类应该含有怼的API。在必要的时候——就是说Q需要用运行时多态的时候——这可以通过l承实现。但是多态依旧会发生在设计时期。比如，如果你用QListBox代替QComboBoxQ或者用QSlider代替QSpinBoxQ你会发现相似的API使这U替换非常容易。这是我们所说的“静态多?#8221;?
静态多态也使API和程序模式更Ҏ记忆。作为结论，一l相关类使用怼的APIQ有时要比给每个cL供完的单独APIQ要好?
Q译注：C++ 0x要引入的conceptQ就是静态多态的语法层实现。这个要比单独的函数名相似更强大且易用。）
命名的艺?/h2>
命名Q大概是设计API时唯一最重要的问题了。该怎么U呼q个c？成员函数该叫什么？
通用的命名规?/h3>
一些规则通常Ҏ有名字都是有用的。首先，像我之前提到的Q别用羃写。甚臛_明显的羃写，比如“prev”表示“previous”从长q看也是不划的Q因为用户必记住哪些词是羃写?
如果API本n不一_事情自然会变得很p糕Q比如， Qt3有activatePreviousWindow()和fetchPrev()。坚?#8220;没有~写”的规则更Ҏ创徏一致的API?
另一个重要但更加微妙的规则是Q在设计cȝ时候，必须力保证子类命名I间的干净。在Qt3里，没有很好的遵守这个规则。比如，?a >QToolButton来D例。如果你在Qt3里，对一?a >QToolButton调用name()、caption()、text()或者textLabel()Q你希望做什么呢Q你可以在Qt Designer里拿QToolButton试试Q?
- name属性承自QObjectQ表CZ个对象用于除错和试的内部名字?
- caption属性承自QWidgetQ表C窗口的标题Q这个标题在视觉上对QToolButton没有M意义Q因Z们L跟随父窗口而创建?
- text属性承自QButtonQ一般情况下是按钮上现实的文字，除非useTextLabel为真?
- textLabel?a >QToolButton里声明，q且在useTextLabel为真时显C在按钮上?
׃对可L的xQname在Qt4里被UCobjectNameQcaption变成了windowsTitleQ而在QToolButton里不再有单独的textLabel属性?
l类命名
标识一l类而不是单独给每个cL个恰当的名字。比如，Qt4里所有模式感知项目的视图c（model-aware item view classesQ都拥有-View的后~Q?a >QListView?a >QTableView?a >QTreeViewQ，q且对应Z目的类都用后缀-Widget代替Q?a >QListWidget?a >QTableWidget?a >QTreeWidgetQ?
l枚丄型及其值命?/h3>
当声明枚举时Q时刻记住，在C++Q不像Java和C#Q中Q用枚丑րg需要类型信息。下面的例子演示了给枚DDv个太q常用的名字所引v的危宻I
namespace Qt
{
enum Corner { TopLeft, BottomRight, ... };
enum CaseSensitivity { Insensitive, Sensitive };
...
};
tabWidget->setCornerWidget(widget, Qt::TopLeft);
str.indexOf("$(QTDIR)", Qt::Insensitive);
在最后一行，Insensitive是什么意思？一个用于命名枚丑ր的指导思想是，在每个枚丑ր里Q至重复一个枚丄型名中的元素Q?
namespace Qt
{
enum Corner { TopLeftCorner, BottomRightCorner, ... };
enum CaseSensitivity { CaseInsensitive,
CaseSensitive };
...
};
tabWidget->setCornerWidget(widget, Qt::TopLeftCorner);
str.indexOf("$(QTDIR)", Qt::CaseInsensitive);
当枚丑ր可以用“?#8221;q接h当作一个标志时Q传l的做法是将“?#8221;的结果作Z个int保存Q这不是cd安全的。Qt4提供了一个模板类 QFlags<T>来实现类型安全，其中T是个枚Dcd。ؓ了方便用，Qt为很多标志类名提供了typedefQ所以你可以使用cd Qt::Alignment代替QFlags<Qt::AlignmentFlag>?
Z方便Q我们给枚Dcd单数的名字（q样表示枚Dgơ只能有一个标志）Q?#8220;标志”则用复数名字。比如：
enum RectangleEdge { LeftEdge, RightEdge, ... };
typedef QFlags<RectangleEdge> RectangleEdges;
有些情况下，“标志“cM用了单数的名字。这Ӟ枚DcM?Flag做后~Q?
enum AlignmentFlag { AlignLeft, AlignTop, ... };
typedef QFlags<AlignmentFlag> Alignment;
Q这里ؓ啥不是把”标志“cȝ-Flag做后~Q而是把枚丑ր做后缀呢？感觉有点h……Q?
l函数和参数命名
l函数命名的一个规则是Q名字要明确体现个函数是否有副作用。在Qt3Q常数函?a >QString::simplifyWhiteSpace()q反了这个原则，因ؓ它返回类一?a >QString实例Q而不是像名字所提示的那P更改了调用这个函数的实例本n。在Qt4Q这个函数被重命名ؓQString::simplified()?
参数名是E序员的重要信息来源Q虽然在使用APIӞq不直接展示在代码里。由于现代IDE在程序员写代码时可以自动昄参数名（是自动感知或者自动补全之cȝ功能Q，值得花时间给头文仉声明的参C个合适的名字Qƈ且在文档中也使用相同的名字?
l布D|函敎ͼSetterQ、提取函敎ͼGetterQ和属性命?/h3>
l布属性的讄函数和提取函C个合适的名字QL非常痛苦的。提取函数应该叫做checked()q是isChecked()QscrollBarsEnabled()q是areScrollBarEnabled()?
在Qt4里，我们使用下列规则命名提取函数Q?
- 形容cȝ属性用is-前缀。比如：
- isChecked()
- isDown()
- isEmpty()
- isMovingEnable()
- scrollBarsEnabled()Q而不?tt>areScrollBarsEnabled()
- 动词cȝ属性不使用前缀Q且不用第三hUͼ-sQ：
- acceptDrops()Q而不?tt>acceptsDrops()
- allColumnsShowFocus()
- 名词cȝ属性，通常没有前缀Q?
- autoCompletion()Q而不?tt>isAutoCompletion()
- boundaryChecking()
- isOpenGLAvailable()Q而不?tt>openGL()
- isDialog()Q而不?tt>dialog()
讄函数名字l承自提取函数名Q只是移掉了所有前~Qƈ使用set-做前~Q比如：setDown()q有setScrollBarsEnabled()。属性的名字与提取函数相同，只是L了前~?
指针q是引用Q?/h2>
传出参数的最佳选择是什么，指针q是引用Q?
void getHsv(int *h, int *s, int *v) const void getHsv(int &h, int &s, int &v) const
大部分C++书推荐在能用引用的地方就用引用，q是因ؓ一般认为引用比指针?#8220;安全且好?#8221;。然而，在奇（TrolltechQ，我们們使用指针Q因让代码更易读。比较：
color.getHsv(&h, &s, &v); color.getHsv(h, s, v);
只有W一行能清楚的说明，在函数调用后Qh、s和v有很大几率被改动?
例子QQProgressBar
Z展示如何实际应用q些概念Q我们将学习Qt3中的API QProgressBarq和Qt4里相通的API做比较。在Qt3里：
class QProgressBar : public QWidget { ... public: int totalSteps() const; int progress() const; const QString &progressString() const; bool percentageVisible() const; void setPercentageVisible(bool); void setCenterIndicator(bool on); bool centerIndicator() const; void setIndicatorFollowsStyle(bool); bool indicatorFollowsStyle() const; public slots: void reset(); virtual void setTotalSteps(int totalSteps); virtual void setProgress(int progress); void setProgress(int progress, int totalSteps); protected: virtual bool setIndicator(QString &progressStr, int progress, int totalSteps); ... };
API相当复杂Q且不统一。比如，仅从名字reset()q不能理解其作用QsetTotalSteps()和setProgress()是紧耦合的?
改进API的关键，是注意到QProgressBar和Qt4?a >QAbstractSpinBoxcd其子c?a >QSpinBoxQ?a >QSlider?a >QDial很相伹{解x法？用minimum、maximum和value代替progress和totalSteps。加入alueChanged()信号。加入setRange()函数?
之后观察progressString、percentage和indicator实际都指一个东西：在进度条上显C的文字。一般来说文字是癑ֈ比信息，但是也可以用setIndicator()设ؓL字符。下面是新的APIQ?
virtual QString text() const; void setTextVisible(bool visible); bool isTextVisible() const;
默认的文字信息是癑ֈ比信息。文字信息可以藉由重新实现text()而改变?
在Qt3 API中，setCenterIndicator()和setIndicatorFollowStyle()是两个媄响对齐的函数。他们可以方便的׃个函数实玎ͼsetAlignment()Q?
void setAlignment(Qt::Alignment alignment);
如果E序员不调用setAlignment()Q对齐方式基于当前的风格。对于基于Motif的风|文字居中显C；对其他风|文字靠在右辏V?
q是改进后的QProgressBar APIQ?
class QProgressBar : public QWidget { ... public: void setMinimum(int minimum); int minimum() const; void setMaximum(int maximum); int maximum() const; void setRange(int minimum, int maximum); int value() const; virtual QString text() const; void setTextVisible(bool visible); bool isTextVisible() const; Qt::Alignment alignment() const; void setAlignment(Qt::Alignment alignment); public slots: void reset(); void setValue(int value); signals: void valueChanged(int value); ... };
如何把API设计好（原文是How to Get APIs RightQ我L成We do APIs right……Q?/h2>
API需要质量保证。第一个修订版不可能是正确的；你必d试。写些用例：看看那些使用了这些API的代码，q证代码是否易诅R?
其他的技巧包括让别的人分别在有文和没有文的情况下Q用这些APIQ或者ؓAPIcd文档Q包括类的概q和独立的函敎ͼ?
当你卡住Ӟ写文也是一U获得好名字的方法：仅仅是尝试把条目Q类Q函敎ͼ枚D|{等呢个Q写下来q且使用你写的第一句话作ؓ灉|。如果你不能扑ֈ一个精的名字Q这常常说明q个条目不应该存在。如果所有前面的事情都失败了q且你确认这个概늚存在Q发明一个新名字。毕竟，“widget”?“event”?#8220;focus”?#8220;buddy”q些名字是q么来的?
]]>
下面l出了示例代码：
bool MyDialog::winEvent(MSG* msg, long* result){ const int captionHeight = 25; const int frameWidth = 6; if (msg->message != WM_NCHITTEST) return false; QPoint pos = mapFromGlobal(QCursor::pos()); int w = width(); int h = height(); if (QRect(frameWidth, captionHeight, w-frameWidth-frameWidth, h-captionHeight-frameWidth).contains(pos)) { *result = HTCLIENT; } else if (QRect(0, 0, w, captionHeight).contains(pos)) { *result = HTCAPTION; } else if (QRect(0, captionHeight, frameWidth, h-captionHeight-frameWidth).contains(pos)) { *result = HTLEFT; } else if (QRect(w-frameWidth, captionHeight, frameWidth, h-captionHeight-frameWidth).contains(pos)) { *result = HTRIGHT; } else if (QRect(frameWidth, h-frameWidth, w-frameWidth-frameWidth, frameWidth).contains(pos))
{
*result = HTBOTTOM;
}
else if (QRect(0, h-frameWidth, frameWidth, frameWidth).contains(pos)) { *result = HTBOTTOMLEFT; } else if (QRect(w-frameWidth, h-frameWidth, frameWidth, frameWidth).contains(pos)) { *result = HTBOTTOMRIGHT; } return true;}]]>