Foxit Readerは比較的軽量なPDFリーダー。Adobe Readerの代わりに使える。
アプリケーションからPDFをFoxit Readerを開くと以下のような警告が出る。
これは署名されていないアプリケーションから起動するとこれが出るようだ。チェックボックスをチェックしても消えない。
これを消すにはファイル ⇒ Preferencesからダイアログを開いて以下の場所でアプリケーションの実行ファイルと登録する。(日本語版ではTrust Managerは「信頼マネージャ」)
ヘッダファイルをダブルクリックしてリソースエディタで開こうとするとエラーになる。
これはヘッダーファイルの最初のクラスが当該フォームでないため。以下のソースのように前方参照(ref class)を使っていてもうまく動かない。
1 2 3 4 5 6 7 8 9 10 11 |
namespace Ambiesoft { using namespace System; ref class EncComboItem; ref class CSearchURL; ref class AddHttpDicDialog : public System::Windows::Forms::Form { ... } } |
これを回避するには前方参照の部分だけのヘッダーをつくり、それをインクルードすればよい。
前方参照だけのヘッダーheaderref.h
1 2 3 4 5 6 |
#pragma once namespace Ambiesoft { ref class EncComboItem; ref class CSearchURL; } |
もとのヘッダー
1 2 3 4 5 6 7 8 9 10 |
#include "headerref.h" namespace Ambiesoft { using namespace System; ref class AddHttpDicDialog : public System::Windows::Forms::Form { ... } } |
適当に書くので参考までに。
アプリのビルドの際にいろいろなターゲットを指定できる能力のこと。ターゲットには以下の内容が含まれる
ターゲットとコンパイラを合わせてToolsetと言う。ToolsVersionと同じ。
ツールセットで指定される。C:\Program Files\Reference Assemblies\Microsoft\Frameworkにあるアセンブリを参照する。ここにあるアセンブリは実装を持たず機能があるかだけを表す。
VSのプロジェクトファイルには以下の内容が含まれる。
1 |
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> |
15.0は使うMSBuildのバージョンだがVS2013以降はこの値は使われず、VSのバージョンに合ったバージョンが使われる。MSBuildは互換性が高いのでこの値は対して意味がない。
VSのバージョンとToolsVersionの対応は以下
14.0以前はレジストリにある以下のキーを参照する
1 |
HKLM\Software\Microsoft\MSBuild\ToolsVersions\14.0 |
15.0以降はレジストリは見ないで、以下のものを使う
C:\Program Files\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin
1 2 |
protected: virtual void WndProc(Message% m) override = Control::WndProc; |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
void Form1::WndProc(Message% m) { switch (m.Msg) { case WM_CLIPBOARDUPDATE: { if (Clipboard::ContainsText()) { try { String^ text = Clipboard::GetText(); txtLog->AppendText("\n"); txtLog->AppendText(text); } catch (Exception^ ex) { MessageBox::Show(ex->Message); } } m.Result = (IntPtr)0; return; } } Form::WndProc(m); } |
Windowsで実験。python3.5でやった。
1 |
>set PATH=C:\path\ffmpeg\bin;%PATH% |
pythonのpipでffmpeg-normalizeをインストールする
1 |
>pip install ffmpeg-normalize |
ffprobeでaudioコーデックを見つける。
1 |
>ffprobe file.webm |
出力のストリームからaudioコーデックを見つける。aacやvorbisなどがある。
1 |
>ffmpeg-normalize a.webm -o o.webm -c:a libvorbis |
ffmpeg-normalizeが見つからない場合は、pythonフォルダのScriptsにパスを張る。
1 |
>ffmpeg -nostdin -y -i a.webm -filter_complex [0:1]loudnorm=lra=7.0:offset=0.0:i=-23.0:tp=-2.0:print_format=json -vn -sn -f null NUL |
メニューから[Visual Studio 2017]→[Developer Command Prompt for VS 2017]を開き、VS2017の環境でコマンドプロンプトを開きます。(日本語版の場合名前が日本語になっていると思うので読み替えてください。)
開いたらQtプロジェクトのあるフォルダへ移動します。
1 |
>set PATH=Y:\G\Qt\5.10.0\msvc2017_64\bin;%PATH% |
上記のqmake.exeへのパスは自分の環境に合わせます。
1 |
>qmake.exe -tp vc qdtc.pro |
成功するとvcxprojが作られます。
1 |
>"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\devenv.exe" qdtc.vcxproj |
vcxprojを開くためには毎回qmakeへのパスを通す必要があるので、出来上がったvcxprojをエクスプローラなどから起動してもうまくビルドできません。
新しくなったfirefoxのQuantum、早くなってマルチプロセスになって使い心地はよくなったが過去のアドオンが使えなくなってしまった。アドオンのできることに大きな制限が加えられたため、機能自体が不可能になったものも多いはず。これらのレガシーアドオンを使うためには古いバージョンのfirefoxであるESRバージョンを使うしかない。しかし一般的にはESRとQuantumの共存は考えれていなくてどちらか一方をインストールするように設計されている。そこでここではそれらの共存を目指す。
以下の2つ(ESRとQuantum)をダウンロードする。(win32のja(日本語)直リン)
https://ftp.mozilla.org/pub/firefox/releases/52.6.0esr/win32/ja/Firefox%20Setup%2052.6.0esr.exe
https://ftp.mozilla.org/pub/firefox/releases/58.0/win32/ja/Firefox%20Setup%2058.0.exe
これらは7zなどで解凍できるので解凍する。中にcoreというフォルダがあるのでそれぞれ”Mozilla Firefox ESR“と”Mozilla Firefox Quantum“と変えて、インストールしたいフォルダに移動させる。
“Mozilla Firefox ESR\firefox.exe”を起動して閉じる。この操作でデフォルトのプロファイルが生成される。プロファイルは共存させることができないので、ESRとQuantumで別々につくる予定だが、とりあえずデフォルトのものをつくっておく。
WIN+Rで「ファイル名を指定して実行」を表示し、%APPDATA%\Mozilla\Firefoxと入力する。この中にあるprofiles.iniを編集して以下のようにする。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
[General] StartWithLastProfile=1 [Profile0] Name=default IsRelative=1 Path=Profiles/b9lnre2b.default Default=1 [Profile1] Name=ESR IsRelative=1 Path=Profiles/ESR Default=0 [Profile2] Name=Quantum IsRelative=1 Path=Profiles/Quantum Default=0 |
ここではProfile1とProfile2を追加した例。NameとPathを変えて、Defaultを0に設定している。すでにプロファイルが存在していた場合には番号を変えて対応する。
次に指定したPathに対応するするフォルダを作成する。すでにあるフォルダをコピーしてもいい。
次にこれらのプロファイルを利用するショートカットを作成する。Mozilla Firefox Quantum\firefox.exeとMozilla Firefox ESR\firefox.exeのショートカットファイルをつくり、プロパティを編集してリンク先に以下の値を追加する。
ESR
1 |
--no-remote -P ESR |
Quantum
1 |
--no-remote -P Quantum |
これでそれぞれのショートカットからESRとQuantumを起動でき、同時に起動することもできる。このショートカットキーから起動しなかったときは、デフォルトのプロファイルが使用される。
オープンソースのライセンスはなかなかわかりづらいし解説も難しいものが多いのでここでは簡単に(そしていい加減に)記述したい。
基本的な用語の整理。
自分が作った創作物には著作権があり、著作権者は著作物の独占的権利をもつ。他人が勝手に他人の著作物を複製して公開したりしてはいけない。フリーソフトウェアの推進者はソースコードを自由に利用できる世界をつくるために自分のソフトウェアにライセンスを設定し他人に自分の著作権の権利の一部を許可する。
ライセンスを受け入れた人(ライセンシー)は自由にソースコードを利用し改変する自由を得るが、自由を得るだけではなく幾つかの義務も課せされる。義務を課さないと利用されるだけになりフリーソフトウェアの理念を拡大できないからである。
ライセンスには幾つもの種類がありGPLがもっとも自由なライセンスと謳われている。それを自由と感じない人もいるかもしれないがソフトウェアの世界で自由といえばGPL系と思われていてそれ自体に対しては意義は唱えれていないと思われる。
それに対してもっと義務の薄いライセンスもある。これらはloose(緩い)ライセンスと言われる。一般に元のソースコードに改変を加えて公開してもソースコードの公開は要求されず元のライセンスの表示や元の著作者の表示をすることだけが義務となる。
ライセンスとはあくまで著作権法の範囲の話なのでそもそも著作権法と関係ない行為にはライセンスは関係ない。
フリーソフトウェアを理念に基づいて考えるとその自由を侵害しないように注意すれば大体のとこは許される。プログラマーの多くは元のライブラリなどを改変しないでそのまま利用し自分のアプリにリンクすることが多いだろう。問題なのは、このとき自分のソースコードを公開する義務があるのかということになる。自分の考えではもっとも「自由」なGPLでもその必要はないと思われる。課される義務は元のライブラリのソースコードを公開することで自分のアプリのソースコードを公開することではない。ここで難しいのがリンクの法的扱いで、それは改変と何が違うのかということだ。これに対して技術的に回答しても技術的に対応されるだけなので法的に考えないとならない。著作権で守られるのは創作物でありそれは著作者の意図を体系として表したものであるから改変とはこの意図にたいしてライセンシーの意図を組み入れて元の意図を展開あるいは破壊したものと考えればいいと思う。
この問題も難しい問題である。社会は経済で回っており人間はカネを稼がないと生きられない。すべてがフリーソフトウェアになってしまえばプログラマーは食っていけない。それを推進する人たちは保守をすればいいとか言っているが、プログラマーが食えないことに代わりはない。とは言え市場経済がソフトウェアの発展にとってもっとも適切だという保証もないしフリーソフトウェアが人々に貢献してきたのは事実だし今も貢献し続けている。マイクロソフトなどもオープンソースへ大きく舵を切った。
日本のソフトウェア業界は遅れていると思う。世界の大手ソフトウェア業界はオープンソースへ向かっている。日本にもそれを普及しようという動きはあるが弱い。このことが将来のソフトウェア産業において日本の地位をさらに貶める危惧がある。これは政治問題でもある。