さっきソフトウェア関係の会社からメールが来たが

詳細は何も書いてない。
ソフトウェア関係の会社から協業したいとメールが来た。
開発依頼か?と思って返信したら、すぐ返事が来た。
スパムだったようだ。
ソウトウェア販売の営業を代行する会社だった。
私がその会社に金を払って私のソフトウェア販売の営業の代行をしてもらうという話なんだろう。
協業じゃなくて、「仕事ください。」の間違いだろうに。
騙すようなメール送って来ないで欲しい。

確かに私はソフトウェアの開発及び公開はしているんですが、
フリーソフトであって、販売してないんですよ。
金払えっていうメールは要らないなあ。
金くれる話はないかなあ。

Qtについて

Qtは良いものなんですが、プロ向きみたいな感じがあります。
とっかかりにくいというか、最初に越えなければならない壁があると思います。
クロスプラットフォームという大きな利点の代償として、OS固有の機能を使うことがOS純正の開発環境と比べて難しいという欠点があります。
例えば、Windowsのメッセージという機能は使えないんじゃないでしょうか。
IEコントロールを直接使うこともできないと思います。
しかしOS固有の機能を使うとクロスプラットフォームではなくなってしまいますし、
Qtは高機能で多機能でOS固有の機能を直接使いたいと思うことはほとんどないので、あまり問題にはならないとは思います。
QtCreatorの存在がQtを難しく見せているような気がします。
C++ Builderは最初からGUI環境でプログラムを作るようになっていましたが、
Qtは元々コマンドラインでやるもので今でも基本はそうです。
後発としてQtCreatorが出ましたが直感的に使えるようになっていないし環境が整っていません。
サンプルプログラムはなぜかQtCretorを使わないものばかりというか、QtCreatorを使うサンプルプログラムってないような気がする。
Qtが用意しているサンプル、デモのプログラムのソースコード、及び検索してでてくるソースコードがQtCreatorを使わないものばかりだと、サンプルのソースコードを見てもQtCreatorでどうやって作っていいか分からないわけです。
それらのソースコードを入手すれば、QtCreator使わずにコマンドラインでやろうかとなってしまう。
ここがまず大きな壁。
逆にC++ BuilderはRADを使うサンプルばかりです。
QtCreatorの設計画面でコンポーネントを貼り付けてそのコンポーネントをダブルクリックしても、そのコンポーネントのイベントのソース部分にはジャンプしません。
これもとっかかりとしては大きな壁。
C++ BuilderやVisual Studioのように、タプルクリックでなんらかのイベントのソースコード部分にジャンプしてくれればQtCreator使ってみようなという気持ちになれるかも知れないが、どうしたらいいんだよ!って思わせてしまうこの仕様でQtをやめた人は多いと思う。
これからこの先ずっとこんな感じで直感的に使えないんだなというイメージがここで定着してしまってQtCreatorを使うことに大きな不安ができてしまう。
設計画面のコンポーネントを右クリックしてメニューから「Go to slot…」を選んでその中からイベントを選ぶというQtを知らない人にとっては直感的でない方法を見つけたとしても、
その選択肢はヘルプに連動していないみたいでまたひとつの壁。(しているのかも知れないが少なくとも直感的にそれを知る方法はない。)
気を取り直して、イベント先で他のコンポーネントを操作する記述を書いてもスコープ内にコンポーネントのメソッドが見つからないとエラー。
おかしいなと思ってmainwindow.hを見ても、貼り付けたコンポーネントのメソッドの記述は一切書いてない。
答えは「ui->label->setText(“押されました。”);」のようにのように、ui-> を付ければいいのだが それを直感的もしくは、C++の知識で知る方法はない。
C++では宣言はヘッダファイルに書くもので、C++ BuilderのRADでは、普通のC++の文法でヘッダファイルに宣言を自動的に書く。
C++ Builderは、C++の知識を使って宣言を知ることができて固有の予備知識は必要ない。
QtCreatorは、拡張子がuiのXMLファイルにコンポーネント関係の記述があるが、構文はC++ではなくXMLだ。
そして、そのXMLファイルを見てもC++でどのように宣言されているものなのかは分からない。
C++ Builderと違ってQtCreatorでは宣言すら見せてもらえないのだから純粋なC++ではプログラムを作れないことになる。
コマンドラインでやったほうが分かりやすいとか楽では思えるひとつの要因になる。
QtCreatorを使うと一度決心したとしても検索して出て来る使い方の例がQtCreatorを使わない場合の例が多すぎて少しずつQtCreatorやめたほうが楽なのではという気持ちが強くなっていく。
後は言語の壁がある。
C++ Builderは初期から日本語版があり、今でも日本語版がある。
C++ Builderは公式のドキュメントも日本語で揃っている。
Qtは今の今まで一度も日本語版が出たことがなく、英語嫌いの人にはとっつきにくいと思う。
今まで日本語でやってきた人間には新たな試練かも知れない。
Qtは日本語で情報を検索した時に、情報量が少ないせいか質の悪い情報が上位に出て来ることが多かった。
現在のQt(Ver 5.x)とは書き方が違うVer 3.xとかVer 4.xの情報が多かった。
それでもQtのバージョンを示す記述が書いてあればいいが、全く書いてないいい加減なサイトが多く騙されてしまう。
Hellow World程度のサンプルのソースコードすら動かせなくて、長時間はまった挙句、後でQt 3.xの情報だったと分かったりした。
Qt入門者にとってこのような質の悪い情報が上位にはびこっている状況は、せっかく一度Qtに興味を持っても、興味をそいでしまうきっかけになる。
頼むから、古い情報は消すか、バージョン書いて新しいQtでは動かないなどの記述を追加するかして欲しい。
古いQtサイトを書いたままで放置している本人はもうQt使ってないんだろうな。
新しいQtの情報を書いたサイトも増えて来ないので、未だに検索され続けて検索上位に君臨している。
Qtは、こういう状況なんで壁を乗り越えられる人でないと何も分からないままてやめていく人が多いのではないかと思う。
Qtに挫折した人にはC++ Builderをすすめます。
今試しにQtCreator起動して見たんですがフォーム(QMainWindow)を右クリックしてGo to slot…でイベントの一覧出しても、ほとんど出て来ず、必要なものは出て来なくてリサイズのイベントも出て来ない。
QtCreatorを使わない方法では検索コピペでリサイズイベント処理は実現できているんですがQtCreatorでは真面目にどうしたらいいか分からない。
あくまでC++ Builderとの比較ですけど、QtCreatorはRADでイベント処理するつもりがないような気がします。
QtベースのCLXというGUIライブラリを使ったC++ Builder6 はC++ Builder用の通常のGUIライブラリのVCLと同等にイベントを含めたRAD操作ができました。
だから、Qtが悪いというより、QtCreatorの実装が悪いんじゃないかと思います。
もし、これらのイベント処理をGUI操作で自動もしくは半自動でするのではなくて自分でソースコードをいちから書けということなら、はっきり言ってQtCreator使わないでテキストエディタでソース書いて作ったほうが効率いいです。

C#について

天下のマイクロソフトがやっている言語ですから、欠点があっても大きな利点もありますし悪くないと思います。
個人的は使う気しないというか使う利点を見出せませんが。
C++ Builderがありますしね。
C#よりJavaのほうがまだ好きです。
Javaもほとんど使ってないですが。
C#が選ばれる理由は複数あると思いますが、
一番大きな理由はGUIで画面設計ができるRADがあるからではないでしょうか。
Visual StudioではC++ではRADを利用できません。
好んでC#を使っている人もいると思いますが、Visual StudioのC++にRADがないために嫌々仕方なくC#を使っている人もいると思います。
C++でRADを使いたい人にはC++ Builderがあります。

新しいプログラミング言語は使うべきではないと思う

過去の資産を捨て去ることのデメリットは計り知れない。
既存の言語とは別に存在しなければならない理由もないような気がする。
新しくても今現在環境が充実していて未来もあるならいいですけどね。
後は、簡単を謳うプログラミング言語やめておいたほうがいいと思う。
簡単と自称しているのもので開発するのは実は一番難しい。
次から次へといろんな言語がでますよね。
D言語、GO言語、Swift、Hack、Rust、Dart、Scratchとか。
どんなものかはよく分からないです。
JavaやC#もそんなに古いほうじゃないですね。
あまり新しくないという古いかも知れないけどPerl、Python、Rubyはやめといたほうがいいと思います。

昔はLinuxをメインに使っていました。

昔はLinuxをメインに使っていました。
はじめて使ったLinuxは1995年ごろのSlackwareだったかな。
カモノハシの絵のディストリです。
Linuxといえばペンギンと思っている人が多いと思うかも知れませんが、私の世代で言うとLinuxといえばカモノハシかも知れない。
JEという日本語化するパッケージを入れて使っていました。
それでもあんまり日本語化されてませんでしたけどね。
メインに使っていたころはTurbolinuxというディストリを使っていました。
当時はあんまり日本語対応できてなくてあちこちで文字化けするのにそれでも無理して使ってました。
Linuxでも動作するWebブログラムに興味持っていたんですけど、
なんかひょんなことから鍋田辞書を作ることになって、そこからWindowsメインというか、ほぼWindowsだけを使うようになりました。
今ではLinuxは仮想環境(VirtualBoxとVMWare)に入れていてたまに使う程度です。
PHPで鍋田辞書Pを作ってようやく元々やろうとしていたWebプログラムに戻ったような感じです。
(PHP版は2012年かな?Perl版は2010年)
Linuxのネイティブソフトにももちろん興味を持っていました。
鍋田辞書のわりと初期の時代はWindows版の他にLinux版も公開していました。
2006年からLinux版を公開していました。
ですが、開発海峡であるKylix3(C++使用)が開発中止されたのにLinuxが大変化していって、ついていけなくなりました。
フォントの処理の方法が変わりましたし、クリップボードの方式も変わりました。
別のOSのように大変化しました。
昔のクリップボードは三つボタンマウスの真ん中ボタンで貼り付けていたんです。
C++ BuilderとKylixでWindowsとLinuxのクロスプラットフォーム開発ができるはずだったのに、夢、幻となってしまいました。
ながらくLinuxから遠ざかっていましたけど、
またいつかLinuxに戻りますよ。

なぜ今までQtを使わなかったか

Qtを今まで使わなかった理由は、
・C++ Builderのような質のよいRADがない。
・GPL/LGPLライセンスが気にいらない。
・商用ライセンスは高い。
・難しい。
・GTK+に負けて衰退するんじゃないだろうかという懸念があった。
・Windows固有の機能を利用する場合は制限がある。
・開発環境をダウンロードするのが難しかった。(エラー中断ばかり)
・なるべくC++ Builderでやりたかった。
などです。
個人的にはQtはいいものだと昔から思っていたんですが、
Qtは長らく前からGTK+と対立していて、GTK+にシェア争いで負けて衰退すると見られていた。
今現在、Qtは健在で人気がありこれからも無くなるとは思われてはいないが、KDEは人気ないしGTK+アプリは多いしLinuxディストリではGTK+のほうが重要視されているようには見える。
Qtは昔はTrolltechという会社が開発していてオープンソースの未来をこの会社一社に左右されることを懸念してQtは使うべきではないという意見があった。
オープンソースとして使う場合のQtのライセンスに対しての問題も指摘された。
こういう意見があることでQtへの興味はそがれた。
衰退するかも知れない状況のQtとオープンソース界で支持が強まっているGTK+のどちらのほうがいいのかというのは永遠?のテーマのような感じだった。
昔GTK+を試したことありますがQtと比べると機能不足で鍋田辞書をGTK+に移植はできないという結論に達してあまり興味がなかった。
Qtの機能が十分なのは知っていたけど商用ライセンスが超高額で手が出せず、フリーのライセンスだと(昔は)GPLで、GPLというライセンスにはものすごく抵抗があった。
ソースを公開したくないから。
ソースを公開するということは、せったく作ったソフトを開発の苦労をしていない他人に乗っとられて功績を全て持って行かれるということに多分なる。
C++ Builderではそんなライセンス制限ないし。
今は、Qtのオープンソース版はLGPLになって昔よりは制限が少なくなった。
LGPLではソースを公開しないですむ方法もある。
2011年にDelphi/C++ Builderの新しいGUIフレームワークのFireMonkeyが登場しQtへの興味をさらにそぐことになった。
FireMonkeyはクロスプラットフォームで今ではWindows、Mac OS、iOS、Androidに対応している。
Mac OS Xに対応しているなんてすごいと思った。
できればC++ Builderで開発したかったのでFireMonkeyにはものすごく期待した。
FireMonkeyに期待している内はQtは眼中になかった。
しかしFireMonkeyは低機能だったしVCLやCLXととの互換性が少なく不満は多かった。
2002年に出たC++ Builder6のCLXのほうが今のFireMonkeyよりずっと高機能だ。
それでもバージョンアップでFireMonkeyが進化することを期待した。
2015年のXE8からTWebBrowserが追加されるなど改善があったが機能的にあまり役に立たないものだった。
2016年8月にC++ Builder 10.1 Berlinを試してみて非常にがっかりすることになった。
TStringGridのイベントの一部をオブジェクトインスペクタで見えないように隠して、既存のプロジェクトの読み込みでTStringGridのOnClickやOnKeyDownがエラーになった。
それを解決してもコンパイル時にCellControlByRowがないとエラー、そしてTTextCellがないとかエラーが出てソース互換がなくなった。
見えるイベントを減らしたことは大きな退化。
FireMonkeyはもうだめだ。期待できないと思うようになった。
それでもTStringGridとTWebBrowserを使わない開発ではFireMonkeyも大きなメリットがあると思う。
ただ、鍋田辞書の移植にはこの二つのコンポーネントがものすごく重要だった。
FireMonkeyの期待が薄れて少しずつQtに目が行くようになった。
とは言ってもQtは前試したときにちんぷんかんぷんだったし、QtCreatorがC++ Builderと比べるとできが悪すぎて直感的に何もできないと感じた。
これは勘違いとか使い方をよく知らないだけかも知れないが、Visual StudioのC#の画面設計は特に調べなくても直感的に使えたし、調べても思うように使えなかったQtCreatorに少しは問題があるとは思う。
10月6日に暇だったのかなぜかふと思い立ちQtをやってみようと思った。
開発環境だけは大部前からインストールしてあった。
QtCreatorは使わないほうがいいのではと前にやった時に思った。
使い方を調べてもQtCreatorを使わない方法で説明されていたらどうしていいか分からないという不利な点があった。
コマンドラインでコンパイルする方法を知らなかったのでまずそこからだった。
全然分からないところからはじめたので、どうせ物にならずすぐやめてしまうだろうと思っていたが、
分からん分からんと悩みながらも根気よく数日続けると使えるようになった。
C++ BuilderのようにRADで画面設計を高速にできないが時間かければできるようになった。
(QtCreatorは使っていない)
今はQtすごくいいんじゃないかと思っている。
問題はLGPL対策というか、LGPLを受け入れる必要がある。
Qtの商用ライセンスを買えない以上はC++ Builderで作ったように気楽に作ったソフトを公開するわけにはいかない。
ソースを隠す方法を考えるのも面倒くさいし、GPLで公開したほうがいいかも知れない。
LGPLを使用していると、ライセンスを順守した上でソースを隠していても、ライセンスを理解していない人にライセンス違反とか言われるリスクがある。

Qtで開発はじめました。

QtCreatorを使わないという手段を選んで、make(nmake)でコンパイルできるようにして、勉強して作り方は分かったつもりです。
もうお勉強というよりは開発をはじめています。
C++はできるし、C++ BuilderのCLXで間接的にQtを長年使っているのでここからは速いです。
開発しているものというのは Qt版の鍋田辞書です。

Qtは入門の域を脱した。

Qtのお勉強の再開四日目。
Qtでプログラムを作れるようになったと思う。
開発を停止しているFireMonkey版の鍋田辞書の開発は非常に残念だが中止になると思う。
FireMonkyの機能不足は鍋田辞書を作るには致命的だ。
CLXで作った既存の鍋田辞書Windows版はTStringGridとTTextBrowserを使用しているが、
FireMonkeyのTStringGridはVCL、CLXとは仕様が違い過ぎる上に低機能。
そして、FireMonkeyにはTTextBrowserがない。
CLXのTTextBrowserの代替になりそうなFireMonkeyのTWebBrowserも低機能すぎて使えない。
QtかJavaなら機能面では問題ないと思う。
現行の鍋田辞書Windows版で使っているGUIフレームワークのCLXは下層でQtを使っているからQtはいろいろと都合がいい。
鍋田辞書はQtに移植できると思う。
全ての機能は移植する気はないけど部分だけでも十分価値があるかと。
そしてQtに移植するということは同時にMac OS XやLinuxにも移植できるということだ。