【Win/Mac/Linux/Android/iOS】 Qt 総合スレ 19

**デフォルトの名無しさん** · 2019/10/24(木) 13:32:07.93

Qt（キュート）は C++ ベースのフレームワーク＆RAD開発環境です。

ライブラリの機能は、フォーム、ボタンなどの各種ウィジェットからネットワーク、マルチスレッド、
グラフィックス(OpenGL)や各種コンテナ、XMLパーサー、組み込み JavaScript など、非常に多岐に渡ります。
公式の統合開発環境「Qt Creator IDE」を使えば、クロスプラットフォーム対応のRAD開発が可能です。
また、EclipseやVisual Studio上で開発したい人のためのアドインも用意されています。

■主な対応プラットフォーム（デスクトップ用途の場合）

Windows XP, Vista, 7
Mac OS X 10.4, 10.5, 10.6
Linux

■ライセンス

・オープンソース版（Open-source version）
　LGPL 2.1 または GPL 3.0 のうちどちらかを利用者が選べます。
　LGPL を選んだ場合はソースコード非公開のままでの商用利用が可能です（いくつか制限あり）。
　※正確には通常「LGPL＋商用利用向きの例外条項」を選ぶことにな７ります（Qtインストール先の「LGPL_EXCEPTION.txt」を参照）。
　　ちなみにGPLでも商用利用が不可能というわけではありません、念のため。
・商用版（Commercial version）
　こっちはDigia社か日本の代理店（SRA社）とライセンス契約（年間30万くらい？）を結んで使います

■Qt を使って作られたソフト例

KDE、Maya、Adobe Photoshop Elements、Google Earth、Skype、DAZ Studio
MotionBuilder、RealFlow、Nuke、LuxRender、Mathematica、Kindle、VirtualBox、
RuviEdit、さくさくエディタなど

■前スレ
【Win/Mac/Linux/Android/iOS】 Qt 総合スレ 18
http://mevius.5ch.net/test/read.cgi/tech/1488948543/

**デフォルトの名無しさん** · 2019/10/24(木) 13:33:58.74

■リンク

・Qt Project
　http://qt-project.org/

・Qtユーザー会
　http://planet.qt-users.jp/
・Qt Users Forum Japan
　http://qtusersforum.s2.zmx.jp/forum/index.php
・Qt Creator を日本語化するプロジェクト(非公式)
　http://qt-creator-jp.sourceforge.jp/

・PyQt4（GPL。定番）
　http://www.riverbankcomputing.co.uk/software/pyqt/intro
・PySide（LGPL。）
　http://www.pyside.org/downloads/

■ライセンス関連まとめ

各ライセンスでの自作アプリのソース公開/頒布

Qtのライセンス　　　アプリのライセンス　　　　　Qtの頒布/(変更部分のソース公開)
GPL 　　　　　　　　　GPL(ソース公開必須)　　　　　　必須
LGPL　　　　　　　　　任意(ソース公開不要)　　　　　　必須
商用　　　　　　　　　任意(ソース公開不要)　　　　　　不要

*: LGPLは動的リンク時

実際には他にも条件(リバースエンジニアリング関係とか)あるので、
きちんとライセンスの条文を読むこと。

**デフォルトの名無しさん** · 2019/10/26(土) 00:08:17.81

>>1-2がいくつかリンク切れしてるね
次スレがいつになるかわからんけど、次は更新した方がよさそう

**デフォルトの名無しさん** · 2019/11/06(水) 03:33:30.11

Qt6のQMLがC++主体になる方針に期待
しかし従来のコードと互換性がなくなることに涙ちょちょぎれる

**デフォルトの名無しさん** · 2019/11/06(水) 11:20:00.91

潮時

**デフォルトの名無しさん** · 2019/11/06(水) 14:47:06.97

旧来のQWidgetベースの画面デザインがカスタマイズ性が弱すぎるので
QMLベースに書き直していこうと思ってるんだけど、
ライセンス買ってネイティブコンパイラを使わないとやっぱり重いかな？
重くはしたくないんだよな。

**デフォルトの名無しさん** · 2019/11/27(水) 17:47:54.26

というか今更javascriptもどきなんてめんどい

**デフォルトの名無しさん** · 2019/11/27(水) 18:21:02.29

UI作りたいのに何でわざわざオレオレ言語学ばないかんねんってのは思うわね
しかもそれQt6でまた結構大きく変わるらしいし(´・ω・`)

**デフォルトの名無しさん** · 2019/11/27(水) 20:22:52.11

めちゃめちゃわかる
Qtに限らず何にせよオレオレ言語はとにかくやめてほしい

**デフォルトの名無しさん** · 2019/11/27(水) 20:25:49.95

どの言語も最初はオレオレよ

**デフォルトの名無しさん** · 2019/11/27(水) 21:26:14.20

宣言と処理を楽に書ける都合の良い言語ってあるか？

**デフォルトの名無しさん** · 2019/11/28(木) 01:26:38.70

QMLとC++の仕様の制約が掴み合いの喧嘩してるなと、バインディングしてるときに思った

**デフォルトの名無しさん** · 2019/11/28(木) 09:20:10.60

そりゃ従来の言語がGUIを構築するのに向いてないからだろ。
簡単な話じゃないか。
手続き型言語より宣言型言語のほうが適性がある

**デフォルトの名無しさん** · 2019/11/28(木) 16:29:23.57

widgetアプリもwebGLバックエンド使えるようになったら便利なんだけどなあ

**デフォルトの名無しさん** · 2019/11/28(木) 16:59:28.09

でもちょこっと処理を書きたいときにいちいちバックエンドの言語に渡すのもめんどくさいやん？
せや宣言的な言語の中に処理も書けるようにしたらええやんついでにJSとある程度互換性を持たせられたら今後流行るWebViewアプリで便利やろなあ→QML
一応QMLである理由はあるんだよなあ
完成度が低かっただけで

**デフォルトの名無しさん** · 2019/11/28(木) 17:14:48.39

昔はUIのデザインとロジックを分離しろって言ってたじゃん(´；ω；｀)

**デフォルトの名無しさん** · 2019/11/29(金) 11:10:18.94

93年か94年頃からずっと退化し続けてるな

**デフォルトの名無しさん** · 2019/11/29(金) 14:06:13.25

https://telektlist.com/app-store-sales/
↑
よく言われることとして、世界全体のスマフォOSシャアでは、
Androidが7割、iOSが3割程度なのに、ソフトの売り上げは、後者の方が
多いのがある。ところが、それは、上位100位くらいまでのアプリの話で、
それ以下のアプリでは、Androidの方の売り上げが多いらしい。
だから、大部分のソフト開発者にとっては、Androidの方がよく売れる
のではなかろうか。

**デフォルトの名無しさん** · 2019/11/29(金) 15:12:23.30

>>15
webviewアプリがもっと流行ればよかったんだな。
android/iOS 両対応のネイティブアプリ作れるフレームワークが流行っちゃったからなあ。
unityみたいなc#ではなくc++でそういうのできるオープンソースのフレームワークがあったらなあ（棒

**デフォルトの名無しさん** · 2019/11/29(金) 15:43:08.22

>>19
Unreal Engine と cocos2d-x は、C++ の1つのソースで Android/iOS の
アプリが作れる。ただし、基本的に Mac 実機と xcode が必要。

**デフォルトの名無しさん** · 2019/11/29(金) 15:45:40.23

あるやん

**デフォルトの名無しさん** · 2019/11/29(金) 15:49:39.19

iOS用のアプリ開発は、XamrineやUnity、Unreal Engineなど
を使っても、結局は、最新に近いMac実機とiOSマシンが必要となり
（中古Macを買っても難しいらしい。）、それにプラスしてAppStoreの
年間登録料が必要となる。シェアウェア作家レベルではそれらのコストを
回収するのは不可能なことが多いはず。ちゃんと作ったゲームは売れるが、
インディーズゲームで一回もダウンロードされないものも珍しく無いらしい。
個人的に派、Androidに限定して出すか、PWA+WASMの組み合わせで出すかなど
が個人開発者には良い選択肢になるのではないかと思う。

**デフォルトの名無しさん** · 2019/11/29(金) 15:57:53.00

WASM?
iOSはOSレベルでJITコンパイルが無効になっているのに何の意味があるのか。

**デフォルトの名無しさん** · 2019/11/29(金) 16:04:12.39

無効って何の話だ？

**デフォルトの名無しさん** · 2019/11/29(金) 16:29:55.67

>>23
WASMでゲーム開発するのは現状難しいと思うが。

**デフォルトの名無しさん** · 2019/11/29(金) 16:38:46.88

https://www.itmedia.co.jp/news/articles/1804/05/news095.html

2018/04/05
App Storeアプリの減少は、Appleが量よりも品質を優先した結果によるもので
意欲的だとしながらも、iOSアプリからAndroidアプリへの移植が多かったのに
対して、その逆は半分にも満たないと分析している。

現在のApp Storeのアプリ数は約160万、Androidアプリ数は約320万で
クロスプラットフォーム化されているアプリ数は約45万程度に留まっているそうだ。

**デフォルトの名無しさん** · 2019/11/29(金) 16:59:15.19

>>23
PWA+WASM+WebGLの例：
https://yutakaaoki.github.io/demo_Mountain/index.html
https://yutakaaoki.github.io/demo_land_Polygon/index.html
https://yutakaaoki.github.io/demo2/index.html

インディーズゲームでは、この位の3Dを使ったゲームが、
WindowsマシンだけでWindows/Mac/Linux/iOS/Androidの全てに
無料で作れる事は大きい。

最近では、MSのMailソフトのOutlookがPWA化されたらしい。
上記のサイトでは分かりにくいが、WASMの入力に対するレスポンス速度
はGoogle EarthのWASM版で十分速いことが分かった。

**デフォルトの名無しさん** · 2019/11/29(金) 17:34:10.31

>>24
iOSはアップル以外のメーカーのアプリはヒープメモリに実行権限をつけられない。
つまりJITコンパイルが動かない。
WASMは基本、JITコンパイルが前提の技術。

**デフォルトの名無しさん** · 2019/11/29(金) 21:06:44.06

>>28
だとすれば、iOSでは ChromeもJavaScriptもnative 的なJITは無効
ということになります。Safariは分かりませんが。
そういえば、聞いた話だと、iOSでPWAをサポートしているのはSafariだけで、
PWA提唱者のGoogleが作ったところのChromeはサポートできていないそうです。

**デフォルトの名無しさん** · 2019/11/29(金) 21:10:26.55

>>28
さっき、Swiftが出したLLVMコードを見ていて気づいたのですが、
実は、Swiftの最終出力はnativeコードであると言っても、実は、
さまざまなチェック・コードを混ぜて生成しているようです。
例えば掛け算するだけでオーバーフローチェックをしています。
普通のC/C++では、そのようなコードを生成しないものなのです。

**デフォルトの名無しさん** · 2019/11/29(金) 21:27:41.76

>>28
iOSでは、Safari 以外のブラウザも、Safariと同様に UIWebView か
WKWebView のどちらかを使うことが強制されているそうで、
WKWebViewの方は、JIT コンパイラが使える、と書いてあります。
詳しくは分かりません。

**デフォルトの名無しさん** · 2019/11/29(金) 21:38:15.30

https://stackoverflow.com/questions/11259152/chrome-ios-is-it-just-a-uiwebview

As of version 48, Chrome for iOS uses WKWebView, which is the same view used in Safari.

**デフォルトの名無しさん** · 2019/11/29(金) 21:46:21.51

結論を書いておきます。
・iOSでは、Apple以外のベンダーは、ヒープメモリに実行権限を付けられない。
・Apple純正であるところの WKWebViewはアプリとは別プロセスで実行され、
　（メモリに実行権限を付けることができるので）、JITコンパイル機能も持っている。
・iOSでは、Apple以外のベンダーのWebブラウザも、Appleと同じ描画エンジン
　を使わなければならないことになっており、独自エンジンは使用禁止。
・実際、iOS 上の Ver 48 以後の Chrome は、Safari と同じApple 製 WKWebView を
　使用している。
・ということは、iOS 上の Chrome は、ちゃんと JavaScript や WASM でも、
　JIT コンパイル機能によって高速に描画できていると考えられる。

**デフォルトの名無しさん** · 2019/11/29(金) 22:44:37.93

>>30
>例えば掛け算するだけでオーバーフローチェックをしています。
>普通のC/C++では、そのようなコードを生成しないものなのです

16 * 16 ビットは、絶対に、32ビットに納まる！
32 * 32 ビットは、絶対に、64ビットに納まる！

例えば、10進数で考えても、
2 * 2桁は、絶対に、4桁に納まるだろ。
99 * 99 = 9,801

絶対に、掛け算のオーバーフローは起きない！

**デフォルトの名無しさん** · 2019/11/29(金) 23:03:53.77

64 * 64 ビットは