• <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>

            MUILIB

            讓UI設計師的思想自由飛翔

               :: 首頁 :: 新隨筆 ::  :: 聚合  :: 管理 ::
              33 隨筆 :: 0 文章 :: 39 評論 :: 0 Trackbacks
            re: 各類AR互動系統創意及原理 bukebushuo 2018-09-15 09:36
            所有演示的鏈接都是訪問受限
            這種程度只能說是一個技術驗證庫,離真正實用還早
            @溪流
            微軟講求的全平臺用戶體驗統一性,如果加上開關,也會引起更多的用戶疑惑,產生更多的問題,中國用戶倒是習慣了,有問題也不會去問客服,但是國外的就不一樣,不是有個經典的電源插頭沒插都打電話到微軟去問的段子嗎?
            讀屏那個應該不太可能了,dui本身就是一個無句柄方式的界面,與原先的訪問機制完全不一樣了(主要是獲取控件指針的方式,原先按點坐標可以獲取控件窗口句柄,現在不行了),給控件加上你說的那個機制也達不到目的,除非是針對dui的界面寫專門的訪問接口,但是那樣的話,就不算通用方法了吧?
            控件加鍵盤支持應該是最簡單的,只要響應下鍵盤消息就可以了,沒啥麻煩的,幾行代碼的事
            設置0xFF那一步沒必要
            NativeApp可以以WebAPP為起點然后增加各種WebApp沒有的功能
            但凡成功的App或者說有足夠用戶的App從來沒有因為跨平臺成為發展障礙
            除了網頁,App還沒見過有可以跨平臺的
            創業真的很難,不是做技術!
            又是一個NX的項目,干這種事,沒有充足的資金,基本就是半途而廢吧?
            關注中...
            高手啊,學習了
            re: XP之后Windows的一些變化 bukebushuo 2013-07-20 09:53
            以前,是因為大部分都是Windows,沒別的選擇,只能用Windows,最多,就是用跨平臺的技術,比如Java,把服務端搞到Linux上,那時,微軟想怎么干就怎么干,后面你只能跟著跑。
            現在,前端有了多種選擇,已經不是微軟想怎么樣就怎么樣了,不考慮用戶的需求,只能吃老本了。
            re: 理解WinRT[未登錄] bukebushuo 2013-01-19 10:11
            @megax
            要說低功耗,還得WIN32啊,不過歷史的潮流總是在向前發展,嗯,是不是升級成WIN64更好點?哈哈!
            re: 理解WinRT bukebushuo 2013-01-13 17:33
            感覺博主把概念弄混了,上面講的貌似就是Windows8的架構
            RT,實際就是Arm版的Windows8
            CUDA的最大缺點是需要特定硬件
            1.適用面窄,通常用于局域網中。
            這個應該是陳年舊歷了吧?
            re: 關于warning C4819 bukebushuo 2012-11-12 10:10
            我也經常碰到這種無法Debug的情況,至于是不是這個警告還真沒注意到,下次遇到了研究下!
            能截層窗口嗎?
            re: Window8的壟斷以及LINUX的現狀 bukebushuo 2012-08-17 23:31
            LINUX不是不能做到Windows那樣,而是不能做到Windows那樣,
            Ubuntu算是Linux的極致了,不能在向Windows靠攏了,為什么?
            因為Windows的界面元素好多好多都是申請了專利的,看看安卓的專利官司就知道了,所以Linux是心有余而力不足。
            順便說一句,國內的Linux就可以非常非常的相似于Windows,為什么?
            因為天朝的特殊情況決定的!
            一般來說,只要不是無休止的繪制,中間只要有考慮中斷,CPU就會很低!
            RichEdit很強大,但是缺點也很明顯,必須要在Windows上有那個lib
            @Richard Wei
            是的,如果僅僅停留在GDI這個基礎上肯定是不行的!
            呵呵,有時候你看到的并不代表就是事情的全部!
            你的共享的代碼我看了,有好多的地方值得我去借鑒和學習!
            果然三人行必有我師,謝謝!
            re: 開源一套DirectUI界面庫 bukebushuo 2012-07-04 15:41
            源碼我看了,很不錯的東西,有很多值得學習的地方
            3KS
            @Richard Wei
            什么是傳統的GDI,接口形式而已,后面的這些系統的API底層也是支持硬件加速的!只是沒有DX和GL全面
            話說回來了,一個應用程序一定要加速嗎?不需要加速的占大多數吧!
            @ggt87125@163.com
            快了,那個編輯器已經到收尾階段了
            @alp
            QT基本上已經等同于Java了
            @roger814
            至少在最近幾年內,硬件的能耗將是嚴重制約Android的發展的瓶頸!
            看看PC平臺吧,在PC上Java都不是主流桌面應用開發工具何況移動平臺?
            re: MUILIB-特性展示圖(典型) bukebushuo 2011-10-25 12:44
            @jemmyLiu
            這個庫是純C++和GDI技術編寫,沒用MFC,所以對Dialog的封裝繼承沒怎么研究
            re: MUILIB—UI開發庫的簡歷 bukebushuo 2011-10-24 12:20
            MUILIB界面開發庫目前尚未開源,非商業應用免費!
            感覺大家對屏幕截圖進入了一個誤區,
            真正的思路應該是創建一個屏幕大小的層窗口,設置一個適當的Alpha使得能
            半透明的看到屏幕上的內容,然后繪制那個選區框,進行調整,點擊確定的時候才真正的截取屏幕上的內容。
            国产亚洲精久久久久久无码AV| 99久久精品免费看国产一区二区三区| 伊人久久大香线蕉AV色婷婷色| 精品国产日韩久久亚洲| 久久精品中文字幕大胸| 狼狼综合久久久久综合网| 久久综合综合久久97色| 久久亚洲欧洲国产综合| 欧美牲交A欧牲交aⅴ久久| 伊人久久免费视频| 久久精品国产清自在天天线 | 久久人人超碰精品CAOPOREN| 久久久久久久女国产乱让韩| 久久久久久国产精品免费无码| 久久天天日天天操综合伊人av| 日韩精品无码久久久久久| 久久婷婷五月综合97色直播| 国产亚洲精久久久久久无码| 婷婷久久综合| 久久99精品九九九久久婷婷| 日产精品久久久久久久性色| 久久久久这里只有精品| 四虎国产精品免费久久5151| 一本色综合网久久| 久久久久99精品成人片| 久久99国产精品99久久| 亚洲人成伊人成综合网久久久| 久久久久久久综合综合狠狠| 国产午夜精品理论片久久影视| 伊人久久综合成人网| 久久只有这里有精品4| 精品久久久久中文字幕一区| 99久久久精品免费观看国产| 亚洲综合伊人久久大杳蕉| 久久一区二区三区免费| 精品多毛少妇人妻AV免费久久| 久久婷婷国产麻豆91天堂| 2021久久国自产拍精品| 嫩草影院久久国产精品| 国产精品久久久久无码av| 国产精品久久久久久久久鸭|