• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            posts - 319, comments - 22, trackbacks - 0, articles - 11
              C++博客 :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

            為什么我要把公司做成扁平型

            本文是從 Why I Run a Flat Company 這篇文章翻譯而來。 
            譯者提示:本文中所提到的37signals是一家在西方很有知名度的公司,它是Ruby On Rails這個框架發祥地。

            我一直在保持公司組織結構上層級體系的最小化。當有一個員工說出“晉升我吧”,我不得不重新評估公司的組織結構。

            爬樓梯

            幾個月前,公司里發生了一些奇怪的事情:我們放棄了一個員工。這種事情在我創辦的37signals這家芝加哥軟件公司里并不常見。在過去的11年里,我們僅損失了5個人——其中還有個人在離開了7年后又回來了。

            但這里真正奇怪的事情是這位員工和我一起決定在此時辭去的原因。問題出自志向抱負上——不是缺乏,而是過剩,我們無法接受。

            她在我們的客戶服務部已經做了差不多3年,工作一直很優秀。她聰明,主動積極,工作有效率,從未出過問題?,F在,她希望獲得管理職務、一個新的頭銜,作為她這種表現的獎賞。這不是薪水待遇方面的問題。

            你可能感到奇怪,這種事情怎么會成為了一個問題。畢竟,哪一個公司老板不想讓自己的公司里多些希望能多承擔更多工作的有積極性的員工呢?事實上,很多公司都經常的想辦法多發明一些職位、職責、工作頭銜,來留住他們的最有抱負的員工。

            然而,在 37signals,我們對志向抱負有不同的立場。我們對那種、我認為是“垂直型”發展的志向報復并不多感興趣—— 那是我們最常見的職業發展軌跡——一個員工從入職開始向上爬梯子,在多年的工作中從新員工爬上經理職務,爬到副總裁。相反,我們推崇“水平型”的志向發展方向——在這種情況下,當員工喜歡他們所做的工作時,我們會鼓勵他深入研究,擴展他的知識面,讓他在這方面越來越強。我們一直在努力招到一些渴望成為技術高手的人,也就是那些希望成為大師級設計師的設計人員,想精通編程技術而不是管理工作的開發人員。

            相對于給予更高的管理職位作為獎賞——這樣通常會把這些人從他們實際擅長的工作崗位上移走——我們獎賞跟他們的工作相關的東西。我們同時會提供高于市場水平的薪水和豐富的福利,包括夏天每周4天工作日,假期想休多少天都可以(當然,要有理由),在他們正在做的項目上給予他們充分的自主決策權。

            這種策略我們使用了多年,效果很好。但最近,因為我們招入了更多的人,這種模式開始顯現不適應的跡象。我們現在是26個人。就像很多企業家都知道的,一旦你的公司達到一定規模,以前你不會太注意的事情現在就變得不可忽視了。在我們公司現在這種情況里,諸如”部門”,“經理”,“頭銜”的人力資源術語開始平凡的出現了。

            除了要保持小規模,37signals一直在保持一個扁平型的組織結構。事實上,扁平化是我們的一個核心理念。我們有8個開發人員,但我們沒有首席技術師。我們有5個設計人員,但我們沒有創意總監。我們的客戶支持團隊里有5個人,但沒有客戶支持經理。而且因為我們沒有市場部,我們沒有首席營銷主管。

            即使我們規模擴大了,我們仍然維持著一個干癟的組織結構。我們沒有任何空間留給沒有實際工作的人。在37signal的每個人幾乎都跟我們產品的某些東西有直接的關系。從編寫員編寫和更新支持文檔,到設計人員設計用戶界面,到程序員給使用用戶開發代碼,他們都在盡自己的職責,我們沒有一個拿著薪水只是去告訴別人去做什么的議院議員。

            我們曾做過實驗,把一部分人提升到管理層。在某些方面,這樣做有好處;但另外一些方面,這樣有問題。其中我們發現的一個問題就是,讓團隊自己管理自己通常比讓團隊受另外一個人管理要好。所以,當組織需要建設的時候,我們通常讓他們自己去處理。

            例如,當我們還是只有3個人在客戶服務處的時候,我們招募了一個人去管理這個團隊。這個人的職責是審查每個人的工作表現,注意他們的語氣,確保我們的客戶能得到迅速和正確的回復,并和我們的開發人員交流,讓他們知道客戶的需求,評估我們整個支持的執行效果。他也許可以投入到客服工作中,解決一些客戶問題。但他的主要職責是退出前線、改進整個部門的工作。

            效果不好。這并不是對某個經理的問責(他是個很棒的家伙,知道如何去管理一個部門,我們希望他能找到其它合適的工作)。關鍵問題不是誰在這個角色職位上;這個角色職位本身是沒必要的。因為我們希望這個部門能夠成長,所以我們就以為適當的調整現有組織機構是個好主意。畢竟,誰都知道,當你增加人手時,你就擴大了組織。

            我們從這件事情中學的的教訓是,增加一個專職經理、創造出上下級關系并不是建設你的組織的唯一途徑。相反,我們決定讓這個團隊完全的自主管理自己。仍然會有一個團隊領導,但這個角色是在整個團隊人員中每周輪流輪換的。每周,新團隊領導會勾勒出這周的議事日程,把問題和完成的任務寫成報告,進入第一線來解決跟客戶交流中遇到的各種問題。

            我喜歡這種安排的一個原因是,它解決了常見的非常有害的管理者和勞動者之間的沖突,在這樣的安排中,兩種角色的人都能體驗到對方角色的狀況。你會發現公司中的很多沖突都是因為對相互的職務不了解產生的。因為這種每周的輪流管理,每個人都更能體諒其他人的處境。當你知道你很快就會被管理時,你就會更注意你的管理工作了。這讓我想起一句最喜歡的名言、哲學家John Rawls說的:“最公平的規則是讓那些不知道自己該有多大權利的人都同意的規則。(The fairest rules are those to which everyone would agree if they did not know how much power they would have.)”我們的客戶支持工作上了一個新臺階,我們的客戶比以前更滿意了。我們對比了以前和現在的不同,我們知道現在是對的。

            對客服服務團隊的工作表現的觀察,使我想到了橫向激勵而不是豎向激勵會使每個人都受益。把有志向的人往上層推實際上是阻擋了團隊里其他有能力的人。當有三、四個人都有管理能力(按傳統的說法),如果只晉升其中的一位,團隊氣氛就會陷入困境。我們更喜歡一個所有人都能融洽相處的環境,讓每個人都能有機會在橫向上自豪的完全的發展。

            最后我要說的是,當一個員工離開時大家都很不高興。但作為一個公司老板,我必須去考慮公司的長遠發展。只是因為他或她具有超出了現有的職位的能力就讓其升上管理職位,這理由還不夠充分。增設管理職位對于一個扁平型的公司來說實際是宣判了公司文化向等級制度的妥協。目前我們絕對沒有這樣的想法。我希望永遠都不會有。

            跟很多故事一樣,我們的故事也有了一個完美的結局。我們的這位走掉的員工沒有找到合適的工作——她創辦了自己的公司。她管理整個公司,忙得不亦樂乎。我們還給她提了建議、幫助宣傳她的新業務。對任何人來說這都是一個絕對正確的發展方向。

            Jason-Fried
            本文作者Jason Fried是37signals這個芝加哥軟件公司的創始人之一,他也是《Rework》(中文版《重來》)這本書的合著者。

            posted @ 2011-05-04 07:17 RTY 閱讀(167) | 評論 (0)編輯 收藏

            六種最具視覺效果的Android(安卓)手機瀏覽器

            Android手機上有很多各種各樣的應用軟件,但想找到免費且好用的可不容易。這就是為什么今天我要向大家分享這六款最具視覺效果的android手機瀏覽器的原因。讀一下每個瀏覽器的特點,看哪款最適合你。

            Dolphin(海豚)瀏覽器HD版

            Dolphin(海豚) HD瀏覽器是Android市場上最受歡迎和最強大的瀏覽器,它支持Android 2.0以上版本。除了一些諸如手勢命令、多觸點縮放、書簽(同步谷歌書簽)等基本功能外,Dolphin HD瀏覽器還支持很多像插件、HTML5、書簽自定義排序、新穎的界面效果、更改下載目錄等高級功能。

            Opera移動瀏覽器

            這是一個很快、很流暢的瀏覽器,能讓你在移動設備上的上網沖浪具有前所未有的樂趣和效率。重新設計過的用戶界面在手機中看起來更漂亮,使你的手機具有一個時髦的、很現代的顯示外觀。捏擠縮放和平滑的場景切換效果給你的互聯網沖浪一個自然的、直觀的感受。你還可以使用它把網頁內容分享到其它的社交網站和網絡上。Opera移動瀏覽器是連接WiFi網絡和無線寬帶的最佳瀏覽器。

            Miren 瀏覽器

            Miren瀏覽器通過對標簽頁瀏覽+智能全屏模式、頂部網站導航、智能提示等功能的支持,使你具有最直觀的沖浪體驗。這是一個支持Flash、多觸點捏擠縮放功能的瀏覽器。它采用很方便的文件夾形式書簽管理方式,讓你更好的管理書簽、通過SD導出、導入書簽。

            Skyfire瀏覽器

            Skyfire瀏覽器能讓你具有更豐富、更智能、更有趣的移動web沖浪體驗。它還能讓你的瀏覽活動更具社交化。你可以輕易的通過它來訪問Facebook和Twitter上的新聞訂閱,個人簡介,朋友情況,收件箱,事件提醒和地點位置情況。它能通過你正在訪問的網址來幫你發現朋友共享出來的流行網頁內容,發現相關的信息。它能在你的視頻和社交搜索結果是提供你更多的信息。

            Opera Mini 瀏覽器

            通過使用Opera服務器對網頁進行壓縮,Opera Mini瀏覽器不僅在加載網頁速度上更快,而且能比普通瀏覽器節省九成的數據量。Opera Mini瀏覽器是在慢速的或按流量計費的網絡上的最優選擇。

            Boat瀏覽器

            Boat瀏覽器是一個快速的、簡潔易用的Android瀏覽器。非常簡潔和漂亮,能給你在Android上的web沖浪帶來最優的用戶體驗。

            posted @ 2011-05-04 07:14 RTY 閱讀(324) | 評論 (0)編輯 收藏

            你真正需要的代碼測試覆蓋率是多少?

            本文是從 How much code coverage do you really need? 這篇文章翻譯而來。

            我寫這篇文章的起因是由于看了@unclebobmartin在微博上的一些看起來言之鑿鑿的話語。給那些不認識Uncle Bob的人介紹一下——他是我們軟件產業里最著名的一個專家,是《 Clean Code(代碼整潔之道)》這本著作的作者,是敏捷宣言(Agile Manifesto)的簽署人之一。在上世紀九十年代,他對文獻最佳面向對象實踐方法貢獻了很大的力量。所以,當他說話時,我們一定要關注一下。

            他給我們日常的TDD和單元測試制訂了一個最高綱領。我們可以從他的微博里清楚的看到這點:

            “兩件事。可重復性和成本。跟自動化測試比起來,手工測試的成本高的可怕。”

            “手工測試不是測試;那是在做實驗。只要有人的因素牽涉其中,那結果就必然可疑。”

            “你們告訴我的實際意思就是讓我大開方便之門、不去測試某些程序。哼 …”

            “代碼覆蓋率100%并不是成績,那是最低要求。即使只寫了一行代碼,你也要測試它。”

            他接著把軟件測試跟在其它領域里常見的但被認為很關鍵的活動進行了比較:

            “戰地外科醫生也許沒有最夠的時間做嚴格的消毒,但這帶來的風險可能是死亡或高昂的治療代價。”

            “會計難道只會把80%的數據表做雙份備份嗎?”

            “有多少回你們都看到了那些嚴重的宕機事故都是因為一些愚蠢的程序員以為那些愚蠢的代碼不需要經過測試而導致的?“

            他的所有這些觀點都很有價值,但他只向我們展示了問題的一面?,F實中并不是所有的應用都需要如此謹小慎微的測試。并不是所有的應用都跟戰地手術或巨額資金核算那么重要。(更不要說在很多情況下的為”合理避稅“而做的帳務:))。

            一個更重要的原因是,100%的測試覆蓋率并不能保證bug的不出現。就連Uncle Bob自己也承認:

            ”測試并不能杜絕bug。但測試能保證程序的行為是符合預期的。“

            這很顯然指的是:同一個程序員在程序里埋下的概念性或邏輯性錯誤,由他自己測是絕對測不出來的。

            最終,所有的問題歸結于ROI(投資收回率)和實用主義。有些應用比其它應用需要更多的測試。有些bug需要比其它bug投入更多的精力去修復。 究竟是否需要在自動化測試是投入更多的時間和財力,或多少覆蓋率是合適的還是過分了,這都需要人的主觀判斷。

            posted @ 2011-05-04 07:11 RTY 閱讀(245) | 評論 (0)編輯 收藏

            你去創業太老了

            本文是從 But You're to Old to do a Startup 這篇文章翻譯而來。

            這么說,當你過了30歲,再來經營或創辦一個企業就顯的有點老了嗎?超過30就意味著你不再有激情、驅動力和決心了嗎?

            papa-smurf

            怎么算我也不老,我才34歲,但對于創業世界里的人來說,我似乎是就應該坐在某個企業的辦公室里同跟我相仿年紀的人上班。年輕就容易創業嗎?的確,當你年輕時,跌倒了更容易爬起來,失敗了更容易重新再來。但不管怎么說,這也不能表明只有在年輕時才可以創業。

            如今的年代是一個前所未有的創業好時機。你無需一個辦公室,互聯網可以讓你和全世界所有的自由職業者聯系起來,開源軟件提供了你高質量的微軟產品的替代物,大量的便宜的主機提供商提供你選擇。有不計其數的閱讀材料能教你如何起步入手;你甚至能在線填報申請來聯合組成公司。

            通過學習各種創業知識技巧,你可以最小化發展客戶過程中的各種風險、以最小的成本生產出滿意的產品。

            但是,如果你也像我一樣,有兩個孩子,一筆抵押貸款,養一輛車,一筆助學貸款,各種日常消費,等等…!!我可不敢把話說死!但你要知道,這只是你前進道路上的障礙,你要解決它們,風險肯定會有。

            最近我和Noah Kagan有一次談話,關于我的家里個人勸我向另外一個方向發展。一個新成立的公司愿意提供我一個職位,做他們IT部門的負責人,薪水很高,公司運營的也不錯。家里人說我應該有個穩定的收入,給家人留下更多一起相處的時間,我欠家人很多。但Noah給了我一些很好的思考,例如,兩個方向,哪一個是我更喜歡的?如果選了一種不喜歡的工作會怎樣?每天早上,當睜開眼后,我想做什么?想干什么?

            做事必然會有風險。我可以接受這份工作,把無數的時間花在別人的產品上。或者我做我自己的公司,那是我的激情所在,是我每天醒來后就能享受的事情。沒有完美的事情,在公司你可能被解雇、被炒,創業有可能會失敗或成功。

            熱情和決心沒有年齡的限制!

            在創業公司使用Lean或敏捷開發方法,你可以快速的獲得經驗,快速的調整,降低風險。你的選擇是什么?我是一個真正的信仰者,相信無論你想做什么,或正在做什么,你必須努力做到最好。不要讓投資者們、其他企業家或任何其他人對你說你不行或你太老了。你的成功你自己決定。

            posted @ 2011-05-04 07:09 RTY 閱讀(176) | 評論 (0)編輯 收藏

                 摘要: IonMonkey是Mozilla的新JavaScript JIT編譯器,旨在為SpiderMonkey JavaScript引擎引入新的優化手段。 InfoQ 采訪了IonMonkey首席開發者David Anderson,討論了其進展,及它為使用SpiderMonkey引擎的產品如Firefox、Thunderbird、Adobe Acrobat和MongoDB所帶來的性能進步。 ...  閱讀全文

            posted @ 2011-05-04 07:05 RTY 閱讀(411) | 評論 (0)編輯 收藏

            本文是從 S.O.L.I.D. Class Design Principles 這篇文章翻譯而來。


            本文是由敏捷宣言簽署人之一、《 Clean Code(代碼整潔之道)》一書的作者Robert C. Martin為他的《Applying Principles and Patterns》這本書搜集整理而來。

            單一責任原則(SRP)

            只有一個理由去修改一個類。例如,如果一個業務規則的改變會導致這個類的修改,那么,數據庫、界面、報表格式或系統任何其它的部分的改變都不該迫使這個類做修改。

            開發/關閉原則(OCP)

            軟件構成(類,模塊,方法等)向擴展行為開放,向修改行為關閉。

            Liskov替換原則(LSP)

            子類必須能夠用來當作基類使用。如果類A繼承類B,任何能使用A的地方,B也同樣可以使用。例如,是否還記得,正方形可以看作是矩形!當進行擴展 時:前提條件不許繞過,后置條件不能放寬限制,可見常量不能被修改(?)。常量:在擴展之前或之后,用戶都需要依靠這個常量來傳遞信息。正確的使用set 形式的繼承關系。不遵守set語義是非常危險的。歸納:使用超類的引用的任何上下文中也可以使用其子類的引用替代。這個原則極大的限制了在純擴展(繼承) 機制里可以做的事情。不遵守會帶來風險。

            接口分離原則(ISP)

            一個類對另一個類的依賴應該限制在最小化的接口上。

            反向依賴原則(DIP)

            依賴抽象層(接口),而不是具體類。

            其它重要原則

            Demeter定律

            也被稱做封鎖信息原則:只跟朋友交流

            一個對象O的任何一個方法M只能調用下列類型的對象的方法:

            • 它自己
            • 它的參量
            • 它創建/實例化的對象
            • 它的直接組件對象

            參考

            好萊塢原則

            不要調用我,我會調用你的。

            不要自我重復(DRY)

            去掉重復代碼。

            對接口編程,而不是對實現

            反向依賴的另外一種說法。

            你不需要它(YAGNI)

            不要添加你“認為以后可能有用”的代碼。只在“事到臨頭”時才添加代碼。

            簡單化,傻瓜化(KISS)

            讓它能工作的最簡單的方法是什么?

            posted @ 2011-05-04 06:58 RTY 閱讀(190) | 評論 (0)編輯 收藏

            版權聲明:http://www.ruanyifeng.com/blog/2011/05/how_to_choose_free_software_licenses.html

            如何為代碼選擇開源許可證,這是一個問題。

            世界上的開源許可證,大概有上百種。很少有人搞得清楚它們的區別。即使在最流行的六種----GPL、BSDMIT、Mozilla、ApacheLGPL----之中做選擇,也很復雜。

            烏克蘭程序員Paul Bagwell,畫了一張分析圖,說明應該怎么選擇。這是我見過的最簡單的講解,只用兩分鐘,你就能搞清楚這六種許可證之間的最大區別。

            下面是我制作的中文版,請點擊看大圖。

            (完)

            posted @ 2011-05-02 21:59 RTY 閱讀(204) | 評論 (0)編輯 收藏

            1、示例代碼

            1        QtCore.QTimer.singleShot(self.delaySpinBox.value() * 1000,
            2                self.shootScreen)

            2、關于QTimer.singleShot 的用法

            void QTimer::singleShot ( int msec, QObject * receiver, const char * member ) [static]

            This static function calls a slot after a given time interval.

            It is very convenient to use this function because you do not need to bother with a timerEvent or create a local QTimer object.

            Example:

             #include <QApplication>
            #include <QTimer>
            int main(int argc, char *argv[])
            {
            QApplication app(argc, argv);
            QTimer::singleShot(600000, &app, SLOT(quit()));
            ...
            return app.exec();
            }

            This sample program automatically terminates after 10 minutes (600,000 milliseconds).

            The receiver is the receiving object and the member is the slot. The time interval is msec milliseconds.

            Note: This function is reentrant.

            See also setSingleShot() and start().

            posted @ 2011-05-01 13:21 RTY 閱讀(2297) | 評論 (0)編輯 收藏

            本文由程序猿What is the single most influential book every programmer should read?翻譯而來。

            國外知名網站stackoverflow上有一個問題調查: 哪本書是對程序員最有 影響、每個程序員都該閱讀的書?

            這個調查已歷時兩年,目前為止吸引 了153,432人訪問,讀者共推薦出了478本書(還在增加),其中最火的一本 書《Code Complete》被頂了1306次。

            如果你是個程序猿,你一定有興 趣看看這些書里你都看過幾本,如果你一本沒看過的話,我也不好說什么 ,也許你是個天才,但我相信大多數人都知道,你在學校里根本學不到什 么真正的工作中需要的知識,我們畢業后能幫助我們在公司中勝任工作的 老師就是這些優秀的書籍,一本好書可以改變一個人的一生。

            下面是這個調查中排名靠前的書的一個簡單的清單:

            第一名:1306票《Code Complete (2nd Ed) by Steve McConnell》,中文版《代碼大全(第二版)》,兩屆Software Jolt Award震撼大獎得主!

            程序猿,程序員都該閱讀的書

            第二名:1161票 《The Pragmatic Programmer》,中文版《程序員修煉之道》

            程序猿,程序員都該閱讀的書

            第三名:689票 《Structure and Interpretation of Computer Programs》,中文版《計算機程序的構造和解釋》

            程序猿,程序員都該閱讀的書

            第四名:557票 《The C Programming Language》,中文版《C程序設計語言》

            程序猿,程序員都該閱讀的書

            第五名:472票 《Refactoring: Improving the Design of Existing Code》,中文版《重構:改善既有代碼的設計》

            程序猿,程序員都該閱讀的書

            第六名:472票 《Introduction to algorithms》,中文版《算法導論》

            程序猿,程序員都該閱讀的書

            第七名:430票 《The Mythical Man-Month》,中文版《人月神話》

            程序猿,程序員都該閱讀的書

            第八名:426票 《Design Patterns》,中文版《設計模式》

            程序猿,程序員都該閱讀的書

            第九名:386票 《The Art of Computer Programming(First Volume Hardcover)》,中文版《計算機程序設計藝術第 (第一卷)》

            程序猿,程序員都該閱讀的書

            第10名:353票 《Compilers: Principles, Techniques, and Tools 》,中文版《編譯原理》

            程序猿,程序員都該閱讀的書

            第11名:329票 《Head-First Design Patterns》,中文版《Head First 設計模式》

            程序猿,程序員都該閱讀的書

            也許,這里的排名并不具有什么權威性,但絕對可以說都是好書!

            這11本外還有很多書雖然票數不是那么多,但大家估計都耳熟能詳,比如《Effective C++》(中文版《Effective C++:改善程序與設計的55個具體做法》),《Clean Code》(中文版《代碼整潔之道》),《Effective Java》(中文版《Effective Java中文版(第2版)》等 。

            記得有位先哲曾說過:

            一種編程語言的重要性并不在于語言本身,而是在于這種語言來體現出來的編程思維模式。所以說,并不是你用到的書才去讀,讀書是一種習慣。

            posted @ 2011-05-01 10:38 RTY 閱讀(258) | 評論 (0)編輯 收藏

            1. 示例代碼

            1        self.screenshotLabel.setPixmap(self.originalPixmap.scaled(
            2                self.screenshotLabel.size(), QtCore.Qt.KeepAspectRatio,
            3                QtCore.Qt.SmoothTransformation))

            2. Label 的 setPixmap函數說明

            pixmap : QPixmap

            This property holds the label's pixmap.

            If no pixmap has been set this will return 0.

            Setting the pixmap clears any previous content. The buddy shortcut, if any, is disabled.

            Access functions:

            const QPixmap * pixmap () const
            void setPixmap ( const QPixmap & )

            3. 對QPixmap的scaled函數的解析

            QPixmap QPixmap::scaled ( const QSize & size, Qt::AspectRatioMode aspectRatioMode = Qt::IgnoreAspectRatio, Qt::TransformationModetransformMode = Qt::FastTransformation ) const

            Scales the pixmap to the given size, using the aspect ratio and transformation modes specified by aspectRatioMode and transformMode.

            • If aspectRatioMode is Qt::IgnoreAspectRatio, the pixmap is scaled to size.
            • If aspectRatioMode is Qt::KeepAspectRatio, the pixmap is scaled to a rectangle as large as possible inside size, preserving the aspect ratio.
            • If aspectRatioMode is Qt::KeepAspectRatioByExpanding, the pixmap is scaled to a rectangle as small as possible outside size, preserving the aspect ratio.

            If the given size is empty, this function returns a null pixmap.

            In some cases it can be more beneficial to draw the pixmap to a painter with a scale set rather than scaling the pixmap. This is the case when the painter is for instance based on OpenGL or when the scale factor changes rapidly.

            See also isNull() and Pixmap Transformations.

            QPixmap QPixmap::scaled ( int width, int height, Qt::AspectRatioMode aspectRatioMode = Qt::IgnoreAspectRatio, Qt::TransformationModetransformMode = Qt::FastTransformation ) const

            This is an overloaded function.

            Returns a copy of the pixmap scaled to a rectangle with the given width and height according to the given aspectRatioMode and transformMode.

            If either the width or the height is zero or negative, this function returns a null pixmap.

            posted @ 2011-04-29 23:02 RTY 閱讀(734) | 評論 (0)編輯 收藏

            僅列出標題
            共31頁: First 23 24 25 26 27 28 29 30 31 
            久久久久国产日韩精品网站| 日产久久强奸免费的看| 久久天天躁夜夜躁狠狠| 色欲久久久天天天综合网| 国内精品伊人久久久久AV影院| 免费观看成人久久网免费观看| 久久精品亚洲欧美日韩久久| 久久久久亚洲AV无码观看| 国产精品久久久久影院嫩草| 久久九九久精品国产免费直播| 伊人久久大香线蕉亚洲五月天 | 精品无码久久久久久久动漫| 国产巨作麻豆欧美亚洲综合久久 | 久久久久久精品免费免费自慰| 欧美噜噜久久久XXX| 合区精品久久久中文字幕一区| 色欲综合久久中文字幕网| 四虎国产精品免费久久| 精品一区二区久久| 亚洲国产一成人久久精品| 久久久精品波多野结衣| 国产精品一区二区久久| 午夜天堂av天堂久久久| 麻豆久久久9性大片| 秋霞久久国产精品电影院| 久久精品国产亚洲av麻豆色欲| 亚洲综合久久夜AV | 久久国产成人亚洲精品影院| 久久成人精品视频| 99国产欧美精品久久久蜜芽 | 亚洲日韩中文无码久久| 香蕉久久夜色精品国产尤物| 久久国产成人精品国产成人亚洲| 久久免费高清视频| 99久久婷婷免费国产综合精品| 性做久久久久久久| 欧美精品久久久久久久自慰| 色8久久人人97超碰香蕉987| 久久国产精品一国产精品金尊| 色综合久久无码中文字幕| 久久婷婷激情综合色综合俺也去|