高見知英の技術ログ

技術関係のログをQiitaから移行してきました。プログラミングのほか、使っているアプリの細かい仕様についてなど書いていきます。

tkinterで表示するダイアログをマウスカーソル位置に表示する

Pythonで簡単なGUIを表示する場合、標準モジュールで何も追加しなくても使えるtkinterが便利です。

tkinterには、tkinter.simpledialog.Dialogというダイアログを表示するためのひな形クラスが存在するので、それを使用すると割と簡単にダイアログを作ることが可能です。

# 初期案
import tkinter.simpledialog

class ChooseDialog(tkinter.simpledialog.Dialog):

  def body(self, master) -> None:
    # 入力部分に表示するコントロールを作成する
    return super().body(master)

  def ok(self, event=None):  super().ok(event); self.result = True
  def cancel(self, event=None): super().cancel(event); self.result = False

owner = tkinter.Tk()
owner.withdraw()
dlg = ChooseDialog(owner, 'Choose Link Style')

ダイアログをマウスポインタの位置に表示したい

さて、このダイアログ、初期の設定だとウィンドウの中央に画面が表示されるようになっています*1

ただ、個人的にはちょっとしたダイアログなのでマウスカーソルの位置に表示させて、すぐに操作できるようにしたい。マウスポインタの位置を取得すればできるはずですので、やってみましょう。

# 動かないバージョン
import tkinter.simpledialog, ctypes, ctypes.wintypes

class ChooseDialog(tkinter.simpledialog.Dialog):

  def body(self, master) -> None:
    p = ctypes.wintypes.POINT()
    ctypes.windll.user32.GetCursorPos(ctypes.byref(p))
    
    self.geometry(f"+{p.x - self.winfo_width() // 2}+{p.y - self.winfo_height() // 2}")
    # 入力部分に表示するコントロールを作成する

    return super().body(master)

  def ok(self, event=None):  super().ok(event); self.result = True
  def cancel(self, event=None): super().cancel(event); self.result = False

Pythonからマウスカーソルを取得する方法については、ググってみても大抵「PyAutoGUI.positionを使え」と書いてあるのですが、マウスポインタをとるためだけにPyAutoGUIをインポートするのはちょっと・・・ と思い、PyAutoGUIのソースを参照してみたところ、ふつうにWindows APIGetCursorPosを呼んでるだけだったので、こちらを使いました。

さて、そんな感じでマウスカーソルの周囲にウィンドウを表示するよう、ウィンドウのジオメトリを設定するのですが、なぜか動きません。なぜか。

調べてみると、tkinter.simpledialog.Dialogはコンストラクタで_place_windowというプライベート関数を呼んでいるようで、このメソッドがダイアログの位置を設定しているようです。

それでも強引にウィンドウの位置を設定する

それでも自分でダイアログの表示位置を設定したい場合は、_place_window()関数の呼び出しよりあとにウィンドウの位置を矯正する必要がある。

と、いうことで、引数がなく副作用も最小限で済みそうな、grab_set()メソッドをオーバーライドして、処理を付け足します。

# 動くバージョン
import tkinter.simpledialog, ctypes, ctypes.wintypes

class ChooseDialog(tkinter.simpledialog.Dialog):

  def body(self, master) -> None:
    # 入力部分に表示するコントロールを作成する
    return super().body(master)

  def grab_set(self) -> None:
    p = ctypes.wintypes.POINT()
    ctypes.windll.user32.GetCursorPos(ctypes.byref(p))
    self.geometry(f"+{p.x - self.winfo_width() // 2}+{p.y - self.winfo_height() // 2}")
    return super().grab_set()

  def ok(self, event=None):  super().ok(event); self.result = True
  def cancel(self, event=None): super().cancel(event); self.result = False

こうすると、マウスカーソルの位置にウィンドウを表示させることができます。

わかったこと

  • tkinter.simpledialog.Dialogはちょっとしたダイアログを表示させたいときに結構便利
  • 挙動が分からないことがあったらソースコードを読もう(Visual Studio Codeからであれば、Ctrlキーを押しながらキーワードをクリックでもソースが表示できる)
  • Pythonの標準モジュールのソースはGithubでも公開されているのでそちらも確認を
  • なんだかんだ他人のソースコードを読みたいときに読めるようにしておくトレーニングは重要

参考文献

*1:の、はずなんですが、なぜか自分の環境では1モニタ目の画面左上に表示されます…。マルチスクリーンに対応していないのか・・・?

Lazarus体験記

Lazarusという開発環境をご存知でしょうか。

Delphiのベースになった言語、Object Pascalの開発環境で、オープンソースで開発が進められています。

www.lazarus-ide.org

今回デスクトップで比較的高速に起動するアプリケーションを作る必要があり、とりあえず手近にあるもの・・・ ということで、今回こちらを使うことにしました。

昔のDelphiそっくり!

とりあえずLazarus、Delphi 6あたりの時代のDelphiにそっくりです。

f:id:TakamiChie:20211031164918p:plain
Lazarusの開発環境

構文も他の言語と違ってそれほど昔から変わってないので、まさに昔ながらのDelphi という感じ。思わず「懐かしい!」と感じていました。

Lazarusの雑感

とりあえずLazarusをしばらく使ってみた感じですが。

  • 定義と実装部分が分かれている、昔ながらのObject Pascal
  • 未だにガベージコレクションがない
  • 画面レイアウトは最近の開発環境と違い、オブジェクトインスペクタやプロジェクトインスペクタ、ソースエディタなどのウィンドウがバラバラになっている状態*1
  • Delphiに比較的近いため、Embarcaderoの公開しているDelphi言語リファレンスがある程度使える(使えない部分もある)
  • Git連携などは存在しない。外部ツールを起動することはできるので、そこでGithub Desktopなどを起動できるようにすればまあ代用可能
  • ソースコード上の何行目を今選択しているか 等の情報をすべてプロジェクトファイルに保存してしまうため、地味にGitなどと相性が悪い?
  • Lazarusの機能差分やモジュール差分はLazarusのWikiにまとまっている
  • 開発環境自体のデータサイズが結構軽い(とくにVisual StudioやEmbarcaderoのDelphiに比べると)
  • Chocolateyでインストールできる

という感じ。

Visual StudioやEmbarcaderoのDelphiだとインストールもそこそこ重いし、PC再セットアップの時など、なんだかんだいっておっくうになりそうという理由で今回はこれを選択しました。

情報検索

とりあえず極端にやりづらいです。

この辺はDelphi自体が他の言語に比べればマイナーなのでしょうがないところはありますが、活用事例がとにかく少ない。

他の言語みたいにプログラミング系のブログが引っかかることはほとんどない(引っかかっても2006年くらいの古い記事)。英語文献を探しても結構少ない感じで。

まあ、スタックオーバーフローの機械翻訳記事や、プログラミングスクールなどのいかがでしたか記事が引っかからない分気が楽と言えば気が楽かもしれない。

LCLは、なかなか良い

ただ、DelphiVCL互換コンポーネントとして作られているLCL(Lazarus Component Library)は結構DelphiVCLとかなり近い実装となっている。

そして、VCL自体の評判がよかったとおり、LCLも結構いい感じ。まだまだそんなには使っていませんが、ここは結構使いやすいです。

ガベージコレクション

上に書いたとおりですが、Object Pascalには今の時代になってガベージコレクションというものがありません。

StringやIntegerなどのプリミティブな型はとくに解放の必要がありませんが、オブジェクトはすべて必ずFree()メソッドを呼んで解放する必要があります。

ただ、ガベージコレクションのある言語だと、解放されるだろうと思っていた変数がしれっと解放されずに残ってしまうことが時々あったり、ガベージコレクションまかせでバンバンメモリリークする第三者モジュールなどもあったりして、特に長時間動くアプリを作るならいっそないほうがいいのかもな・・・ と思いました。

まあありかなという感じ。でも大規模プロダクトには向いてなさそう

今時にしてはちょっと古くさい感じがあるものの、使ってみて悪くはないかな という印象でした。

ただ、プロジェクトインスペクタがフォルダ分けをサポートしていない、Delphi関係以外のファイルをリストしづらいなど、Windows標準のエクスプローラーやVisual Studio Codeと併用した方が楽 というシーンもあり、ある程度以上規模が大きいプロダクトを作成するのには向いていないように思えました。

まあこの辺は今だと比較対象がVisual Studioくらいになってしまってやや分が悪いか・・・?

言語自体はマイナーですが、クラス定義部とそれ以外、メソッドの宣言部と実行部が完全に分かれているという状況は見やすくもあり、悪くはないな と感じました。

もうちょっと使いやすいモジュールがあるといいんだけどな・・・。

作ったもの

とりあえず今回は常駐型のプログラムを作りました。ソースコードはこちら。

github.com

0000Studio

また今回はLazarus自体や自分自身、まちづくりエージェント SIDE BEACH CITY.などの知名度向上に向けた試みということで、0000Studioというサービスで作業内容を配信してみました。

0000.studio

stand.fmの収録などもこちらで配信してるので混ざっていますがまあ、参考になればと。

*1:でもAlt+Tabのタスク切り替えでは一つだけ。どうなってるんだろう

Let's EncryptのルートCA期限切れに対応する

昨日から、Pythonで作ったプログラムのurllib.request.urlopenがなにやら以下のエラーで失敗するようになっていました。

<urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired (_ssl.c:1129)>

なんでだろう と考えていて思い立って気付いた結果が、Let's EncryptのルートCA期限切れ。

jp.techcrunch.com

最近のブラウザなどは大抵問題ないようになっていますが、urllibモジュールは普通に影響を受けたようです。

(暫定的な?)解決策

とりあえず暫定的な対策としては、SSL証明書の有効期限切れを無視するようにすること。

import ssl

ssl._create_default_https_context = ssl._create_unverified_context

・・・

urlopenメソッドの前に、上記のコードを呼んでおけば問題ないです((引用先のコードを見ると一見urllib.requestimport前に呼び出す必要がありそうですが、そういうわけではないみたい))。

end0tknr.hateblo.jp

最終的にはたぶんモジュールの方で対策されたりするんじゃないかなあ と思いますが、それまではこれで。

既存WebアプリにServiceWorkerを追加してPWAっぽくする(たぶん続く)

とりあえず途中まで進んだので記録。

表題の通り既存のWebアプリにServiceWorkerを追加して、PWAっぽく使えるようにします。操作対象は最近いろいろいじっている、CastBackgroundです。今回はキャッシュ処理とmanifest.jsonの設定だけします。

github.com

実際どうやってるのかを見たい場合は、上記ソースコードを直接確認してください。manifest.jsonsw.jsを見れば大抵わかると思います*1

実際の手順

既存サイトにServiceWorkerを追加する場合、やるべきことは以下の通り

  1. (manifest.jsonを追加する)
  2. ServiceWorker用のJavaScriptファイルを「ルートフォルダに」作成する
  3. キャッシュ対象となるファイルのリストを作成する
  4. ServiceWorkerのライフサイクルに対応するイベントハンドラを記述する(最低限必要なのは、install, fetch。たぶんactivate)

とりあえず順を追って確認

(manifest.jsonを追加する)

ServiceWorkerとは直接関係ないですが、まずはmanifest.jsonをつくっておくと、アプリがPWAとして認識されるようになるので、作っておくと便利です。

この辺は参考文献のMDNを参考に。とりあえず記述の通りの内容を書いておけば問題はなさそうです。Edgeで開くと「Web app manifest should have the filename extension 'webmanifest'.」と言われていますがその辺はよくわからないのでとりあえずスキップ

アイコンファイルなどは事前に作成しておくと良いでしょう。

ServiceWorker用のJavaScriptファイルを「ルートフォルダに」作成する

まずは、ServiceWorkerを作成します。インストール処理については大まかにいろんなサイトに書いてある限りで問題なし。

  <script type="module">
    if ('serviceWorker' in navigator) {
      navigator.serviceWorker.register('/sw.js', {scope: "/"})
        .then((reg) => {
          console.log('Service worker registered.', reg);
        });
    }
  </script>

type="module"はとりあえず流れで書いてしまっていますが要らないかも(外したときの挙動を確認していないので記載しています)。

第一引数にはServiceWorkerとして動作するためのJavaScriptファイルを指定します。

ServiceWorkerは、サイトの状態などを確認するためにブラウザにインストールされるUIを持たないJavaScriptファイルです。このファイルでオフライン時のキャッシュの制御などの操作を行います。

第二引数のscopeについては、第一引数のJavaScript配下のディレクトリパスを指定します。未指定時はJavaScriptファイルのあるディレクトとなります。

インストールが完了すると、以降scope配下のファイルリクエストがあったときに、このスクリプトが呼び出されるようになります。このため、よほどのことがなければアプリケーションのルートディレクトリ、すなわち/を指定することになります。

なお、ここでsw.jsがあるディレクトリより上位のディレクトリを指定すると例外が発生します*2

これは「Service Worker、はじめの一歩 | 第1回 Service Workerとは | CodeGrid」によると、「Service-Worker-Allowedヘッダ」というヘッダがないと変更できない動作のため、sw.jsは素直にルートディレクトリに置くのが無難です。

キャッシュ対象となるファイルのリストを作成する

次に、キャッシュしたいファイルの一覧を作成します。キャッシュ対象は自分の作成したファイルだけでなく、CDNなどを参照しているJQueryやBootstrapなどのファイルも対象です。

この辺については面倒なので、わたしは次のようなファイルを列挙してJavaScriptファイルを生成するPythonスクリプトを書きました。ファイルの変更があったときはこれを使用する ということで。

from pathlib import Path
import json

def files(rootdir: Path, path: Path) -> list[str]:
  l = []
  for f in path.glob("*"):
    if str(f.name).startswith("."): continue
    if f.is_file() and f.suffix == "": continue
    if f.is_file() and f.suffix in [".pptx", ".py", ".json", ".md"]: continue
    if f.is_dir() and f.name in ["tools"]: continue
    if f.is_file() or not f.name in ["res", "src"]:
      fs = "/{}{}".format(str(f.relative_to(rootdir)).replace('\\', '/'), '/' if f.is_dir() else '')
      print(fs)
      l.append(fs)
    if f.is_dir():
      l.extend(files(rootdir, f))
  return l

root = Path(__file__).parent.parent
data = json.dumps(files(root, root), indent=2)

with (root / "src" / "files.js").open("w") as f:
  f.write(f"""
const CB_ALL_FILES = {data}
""")

print("Done.")

そして、sw.jsの冒頭に以下のように書きます。

importScripts("./src/files.js")
const CB_ALL_FILES_URLS = CB_ALL_FILES.concat(
  "https://cdn.honokak.osaka/honoka/4.3.1/css/bootstrap.min.css",
  "https://code.jquery.com/jquery-3.5.1.slim.min.js",
  "https://cdn.honokak.osaka/honoka/4.3.1/js/bootstrap.bundle.min.js"
);

これでファイルリストの作成は完了です。*3

なお、詳細は不明ですが、このような記述と、JavaScript読み込み時のintegritycrossoriginの指定は競合を起こす場合があります*4

ServiceWorkerのライフサイクルに対応するイベントハンドラを記述する

sw.jsに各種イベントハンドラを書いていきます。ServiceWorkerのライフサイクルはGoogleの記事などを見ればおおよそわかります

とりあえず最低限キャッシュを動作させるには、installfetchだけ書けば良いっぽい(ただ適宜キャッシュを捨てるなどの処理におそらくactivateも必要)。

キャッシュが必要なファイルの一覧作成

installでキャッシュ必要なURLのリスト(https://からはじまるアドレスかサーバルートからの絶対パス)を指定します。

self.addEventListener('fetch', (event) => {
  console.log('service worker fetch ... ' + event.request);
  event.respondWith(
    caches.match(event.request).then((cacheResponse) => {
      return cacheResponse || fetch(event.request).then((response) => {
        return caches.open('v1').then((cache) => {
          cache.put(event.request, response.clone());
          return response;
        });
      });
    })
  );
});

上記のopen()メソッドの引数に使っている「v1」はキャッシュの呼称なので、本来であれば定数として持っておいた方が良さそうです。定数が変わればキャッシュを参照しなくなります。

ただしこの時点ではキャッシュが必要なURLのリストは指定できてもキャッシュは行なわれていない状態です。実際のキャッシュはfetchで行ないます。

fetchする

次に実際にファイルをダウンロードし、必要ならキャッシュに追加します。

self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open('v1').then((cache) => {
      return cache.addAll(
        CB_ALL_FILES
      );
    })
  );
});

これでキャッシュは完了です。

動作確認する

動作確認には、Edgeの開発者モードがとても便利です。Applicationタブでほとんどの情報を参照することができます。

f:id:TakamiChie:20210922174914p:plain
開発者モード

ただしくServiceWorkerがインストールされていれば、「ServiceWorkers」項目にsw.jsの名前が、「キャッシュストレージ」の項目にキャッシュされているファイルの一覧が表示されています(キャッシュストレージの項目に入っているはずのファイルがなかった場合は、files.jsの中身を確認します)。

オフライン時の挙動を確認する

オフライン時の挙動を確認するときは、画面上部のオフラインチェックボックスをチェックします。するとその間はインターネットに接続していない扱いになります。

f:id:TakamiChie:20210922175623p:plain
オフライン チェックボックス

ServiceWorkerを削除してやりなおす

キャッシュが古くて更新したいときなど、ServiceWorkerを削除するときは、「登録解除」ラベルをクリックします(実運用の時は、ちゃんとアンインストール処理を設けましょう)。

f:id:TakamiChie:20210922180020p:plain
登録解除ラベル

ただしそのまま再読込するとページがうまく読めないときがあるので、一度ブラウザタブを閉じてから開き直すと良いです。

(この時点での)まとめ

とりあえず落とし穴がところどころにあるのが注意が必要ですが、PWAのキャッシュストレージ機能を実装しました。実際使うにはキャッシュを適宜更新したり、期限切れキャッシュを削除したりする必要がありますが、ひとまず一つ目の峠は越えたようです。

参考文献

*1:執筆時点ではfeature-pwa_support_n32というブランチで作業中です

*2:Failed to register a ServiceWorker for scope ('指定しようとしたURL') with script ('sw.jsのファイルURL'): The path of the provided scope ('指定したディレクトリ') is not under the max scope allowed ('sw.jsのあるディレクトリ'). Adjust the scope, move the Service Worker script, or use the Service-Worker-Allowed HTTP header to allow the scope.

*3:なお、ディレクトリも必要であれば指定が必要です。たとえば多くのサーバーでは「/src/」がリクエストされた場合「/src/index.html」が返されますが、ServiceWorker側では相手のサーバが挙動をするサーバかどうかが判断できないからです。なお、今回は「/src/」に直接アクセスする可能性がないので記述していません

*4:実際に指定したファイルを読み込もうとすると「The FetchEvent for "https://code.jquery.com/jquery-3.5.1.slim.min.js" resulted in a network error response: an "opaque" response was used for a request whose type is not no-cors」というエラーが出ました。Githubで検索をしてみるとそれでも読めているソースコードが散見されるのでなにか手順が抜けている気もします

Bootstrapを呼び出すとき、bootstrap.bundle.min.jsを呼び出したらbootstrap.min.jsは不要

ずっとhonokak使ってたのでハマった。だってコード例ないんですもの。

表題の通りですが、bootstrap.bundle(.min).jsは、bootstrap(.min).jsを内包しているようです。そのため、bootstrap.bundle(.min).jsを読み込んだらbootstrap(.min).jsの読み込み処理は不要です。

なので以下のような書き方が正しい。

<html lang="ja">
<head>
  <!-- 中略 -->
  <link rel="stylesheet" href="https://cdn.honokak.osaka/honoka/4.3.1/css/bootstrap.min.css">
</head>
<body>

  <!-- 中略 -->
  <script src="https://code.jquery.com/jquery-3.5.1.slim.min.js"></script>
  <script src="https://cdn.honokak.osaka/honoka/4.3.1/js/bootstrap.bundle.min.js"></script>
</body>
</html>

なお、Bootstrap公式サイトに書かれているとおり、bootstrap.bundle(.min).jsはpopper.jsを内包してはいますが、jqueryは内包していません。jqueryは別途読み込みましょう。

参考資料

pipenv installでエラーが出たら再起動を検討しよう

だいぶハマった。

久しぶりに触るプログラムでpipenv installpipenv updateをすると、次のようなエラーメッセージが出てくるときがあります。

ValueError: invalid literal for int() with base 10: ...

一番最後に出てくるエラーはUnicodeDecodeErrorだったりといろいろなプログラムエラーが出てくるんですが、コンソールを手繰ってみると上記のようなエラーメッセージが出てくる。

スタックトレースを見てみると自分が作ったソースコードに関するエラーが一切出ておらずどうしたものかと思っていたのですが、こういうときは大抵バックグラウンドで起動しているなんらかのプログラム名をpipenvが読み込んでしまっているために起こる問題っぽい。

タスクマネージャを開いて日本語名のプログラムが出ていたらそれを終了させる というのも一つの手なのですが、日本語名のプログラムが見当たらない場合はPCを再起動(多分一度サインアウトしてサインインし直すでも可)してしまうのも手。

また、同じようなエラーは拡張子.pyにPython以外の実行ファイルが関連付けられているときにも起こることがあるので、とりあえず以下の点を確認すると良いです。

  • 拡張子pyはちゃんとPythonに関連付けられているか?(うちの場合いつの間にかVisual Studio Codeに関連付いてた)
  • タスクマネージャの詳細タブで、日本語名のプログラムは起動していないか?
  • それでもダメならPCを再起動 またはサインアウト→サインイン

ああもうほんと疲れた。

参考資料

プルリクエストがマージされた話し

さてなんとなく他の方の記事を読んで「そういえば書いてないな」と思ったので。

neko314.hatenablog.com

元記事ほど大きなプロダクトではないですが、こちらでもPyPDF3に行なったプルリクエストがマージされました。

github.com

問題概要

内容は「PyPDF3*1で古いPDFを読むと、書き込み時に埋め込みフォントの情報が壊れる」というものです。

Shift-JISでフォント名が埋め込まれている非常に古いPDFを読み込んだときのみ発生する問題 ということで非常にレアなものですが、仕事で非常に古いPDFを読まなければいけなくなってしまい、やむなく・・・。

そもそもPDFにShift-JISでフォント名を埋め込む と言うこと自体が最近のPDFではあり得ない挙動のため、PdfFileReaderのコンストラクタ引数strictFalseを指定したときのみ、今回の動作を行なうようにしました。

まあ、結果こういう体験ができたわけで、古いPDFの存在にも多少は感謝しなければいけないのかもしれません。多少は。

テストも書いた

ちょうど良く現象を再現できるテストコードが作れたので、テストコードも書きました。

サンプルファイルは今からPDFを作るとどうやっても事象を再現できないため(Shift-JISでフォント名を書き込む ということができないため)、昔々開催していたスマートフォン懇親会の式次第チェックリストを使っています。

github.com

というかtempfileなんていうモジュールあったんですね。

一次出力ファイルの中身を確認することが困難になるため試行錯誤の多いテストケースではあまり使えませんが、まあ今回はそれほど試行錯誤するわけじゃないのでいいかなあ と。

英語を書いた

そして英語圏のプロダクトなので、もちろんプルリクエストも英語です。最近英語圏の企業さんやフォーラムに向けた英文を書く機会が増えてきました。

このあたりは表のブログにも書きましたが、慣れればわりと気軽に英文は送れます。多少面倒くさいですが、送れるには送れる。

blog.onpu-tamago.net

とくにShift-JISに起因する今回のような問題は海外の環境では再現しない(というか、そんなコンテンツがない)問題なので、どんどん問題挙げていくと自分のためにもちょうど良いかもよ と思った次第。

*1:2も4も5も同じ症状が出るのですが、いちおう今のところ一番活発そうなブランチが3だったので…