Tatsu still writes something... Fourth season

これからも私はなにかをしてなにかを書く

10年のコールドスリープから起こす(Local INdex maker "LIN" & "LIN-Win" Version 2.0.0)

ソフトウェア プログラミング 自作ソフト Webページ

退屈をぶっ飛ばせ

このGW、天気は悪くないものの強風で鉄道はグダグダなので近場のお出かけはままならず、個人的事情で遠くへの旅行はちょっとという感じだったのでせっかくの8連休だったのだが、特にすることがない。

そこで前から気になったウェブページを保存したときに気にしていたのだが取り掛かれなかったLocal INdex maker "LIN" & "LIN-Win"のUnicode対応を行うことにした。

それにしても、6日を費やすとは思っても見なかった。

コア部分

まずはコア部分であるが、地味に時間がかかった。

Windowsとのインタフェース部をUnicode化してあとは気になるところを潰してと思っていたがそんなこんなで3日はかかった。

主な修正点は以下である。

  • サロゲートペアの処理
  • JIS X 0213の認識(するだけ)
  • WindowsのUnicode API対応
  • ほかミスの修正

ミスの修正についてはよく動いていたなというレベルだった。

今回はせっかくAIが使えるのでAIにレビューをさせてみた。今の仕事先ではできないので今風である。

std::stringviewやstd::shared_ptrも提案されたが、時間がないのでバグ取りだけとなった。これはそのうち。

GUI

GUIの部分は以下のことを行った。

  • Unicode化
  • OSによってフォントを変えること
  • 高DPIで破綻しないようにすること

OSによってフォントを変えるのは日本のソフトがいつまで経ってもMSゴシック・MS UI ゴシックを使っていてだからダサいということへの反抗なのだが、Windows 8.1の游ゴシックが見つからず苦労する。で、答えを見つけたのは13年前に書いたMeiryo UIも大っきらい!!の一節。13年前の自分に負けたようで不覚である。

高DPI対応はやはり苦労するところで画面をまたぐときのDPI変更メッセージがなんであんなに飛んでくるんだかというのと、未だにデバイスコンテキストの正しい使い方を知らずフォントのサイズをちゃんと履かれていなかったことが原因だった。案外ツール類で使うことってないんだなと思わされる。

フレームがなくなった!!

で、リリースとなるのだが今まではHTMLのフレームを使ってHTMLヘルプ代わりにしていたが、現代のHTMLだとAI曰くナビゲーションなどが破綻するので廃止されたとのことで仕方なくHTMLヘルプにする。

それにしてもオフラインヘルプにnode.js持ってきてツールを動かすだとか果てはElectronで作るとかどれだけオフラインのヘルプを放置してたんだというものである。

ソフトが生成するフレーム形式の表示はHTML 4.01のものを使っているが、出力形式を考えさせられるというものである。

フレーム形式での目次と選択したファイルの同時表示をどうするかとか考えさせられる終わりとなった。

OSSにしたのなら

せっかくOSSにしたのでタグをちゃんとつければリリースが楽なGitHubにソースを出すようにした。git-svnの分はうまく転送できなかったが古すぎるので良いかなと。

また、掲示板を作るのを凍結したのでディスカッションのカテゴリを日本語にするということをやったのでこっちの方を日本人のみなさんも使ってほしいところである。

Meiryo UIも大っきらい!!ではGitHubに書いてくる日本人いないし。

ということで10年ぶりのリリースで今までエラーになっていたUnicodeファイル名のファイルも整理できてバッチリである。

MulSync Version 2.1.8

自作ソフト C# .NET プログラミング ソフトウェア

今度こそ同期対象ファイルチェックにけりをつけるぞ

ということで何度もやらかしている同期対象ファイルチェックの不具合修正をした。

今回は、NTFS/SMBとFAT/ExFAT間での比較が破綻していたという致命的な物だった。

というわけで最近はPC高いから古いの使い潰そうと考えていたが慌てて本業追えて帰った後自作機で直した次第である。

郷に入りては郷に従え

原因はファイルの時間比較はちゃんとWindows APIでやるようにと書いてあったのだが、自前計算していたのでUTCのNTFS/SMBとローカルタイムのFAT/ExFAT間でずれていたという時刻比較ベースの設計ミスである。

MulSyncはC#で作成しているが、.NET Frameworkのファイル列挙が遅かったのでこの部分をWin32 APIを呼び出して行っていたのだが、その際の時刻比較ルールを見落とした時点でアウトであった。

また、MulSyncは2011制作開始なのだが、この頃から目に見える形でAPI説明の機械翻訳が増えた上に質がひどく(いまもひどいけどってかAIはそこにはつかっとるんか？)見るのに萎えて前後比較はWin32 API使えというのを見落としてたのかもしれない。

あとは、.NETに持っていってTimeSpanを使ってFAT対策の2秒以下無視も書き変えることになったのだが、Ticsの概念に慣れずに苦戦したりといったところでこれでもかと確認はしているがなんか不安ではある。

Java 7までの日付・時刻周りはイケてなかったけど.NET Frameworkの時刻周りも案外微妙かもと思った次第である。

結論

始め良けりゃなんとやらの反対である。

MulSync Version 2.1.7

.NET C# ソフトウェア プログラミング 自作ソフト

相変わらず俺バカだなぁ

前回のバージョンでぼちぼち開発環境のこともあるので.NET Framework 4.0(仮想環境のWindows XPまではターゲットなので)に移行かな等と言っていたら不具合報告が来たので、慌てて直した次第。

内容としてはウインドウの最小化とウインドウのサイズ調整がぶつかってUIパーツのサイズ指定がおかしくなったことで起きた物だが、自分の作ったソフトにウインドウサイズ可変の物が少ないので視野が狭くなっていたということも多分にありそうである。

こういうしょぼいバグが何年も出ないあたり、ほんといつまで経っても弱小フリーソフト作者だなと思った次第である。メジャー級だとユーザーが多いので誰かが見つけてくださる可能性も多いのでしょうが、まあこんなもんかと。

LibreOfficeで人に渡せるファイルに挑戦する

ソフトウェア PC Windows

町内会用の表を書くことになった

2026年度は家が町内会の班長ということで回覧板のリストを急遽書くことになった。

手元にあるOfficeは以下の4つ。

  • LibreOffice 26.2
  • OnlyOffice
  • WPS Office 2
  • 仮想マシン上のMicrosoft Office 2007

もし再来年度の人がOffice使える環境でファイルを渡せるのであればファイルを渡す事を考えていたので、どれが交換性に向いているかChatGPTに伺いを立ててみたらLibreOfficeが一番の有力候補として出た。

LibreOfficeはヘッダやフッタの高さ計算がMicrosoft Officeと違うので大丈夫なのかなと思いながらChatGPTのアドバイスでヘッダ・フッタは使わないことにして表を書いてみることにした。

レイアウト周り何気に楽だった

で、前の班長さんが使っていたフォーマットを元に各欄のサイズを測って、LibreOfficeで書いてみたが、LibreOfficeは行・列幅をセンチメートルで書くので測った物をそのまま入力できるというところが強かった。なので、表自体は楽に完成した。

OnlyOfficeのポイント(換算が必要)やExcelの文字(どうやって計算するんだ？)等とは比較にならない楽さだった。

人に渡せるか

人に渡せるかどうかを検証するため、仮想マシン上のMicrosoft Office 2007とLibreOfficeでそれぞれPDF印刷して合わせてみたが、ずれは目視ではないレベルだった。これなら1年後人に渡せると言えるだろう。

ヘッダ・フッタを除けばLibreOfficeのレイアウトやいろんな所への適用性は高いと言えることがよくわかった一日である。

焼け石に水(MulSync Version 2.1.6)

C# ソフトウェア 自作ソフト .NET

メイン画面ソース長っ

MulSync作り出したのが2011年3月6日、気がつくとこのソフトも15年延々と続けていることになる。子供だったら中学3年である。

そんなソフトなので、色々と追加などをしていった結果今回のバージョンのメイン画面のソースを今眺めてみたらこれだけで5418行いっていた。

ステップ数となるとまた違ってくるのだが個人的に因縁の5,000である。実際には一部のルーチンをサービスクラスに切り出しているのでもっと長いのではあるのだが。

この切り出しは中途半端で止まっている.NET(not Framework)でWPFを使ってクソダサフォント完全おさらば版を作ろうとしたときのMVVMから来ているのではあるが、いざ切り出してみると時間の経過などから切り出し方が違ったりしてなんともといったところである。

切り出し方の違いはあれど、これでも十二分に長く、ソース追うのが厄介なことこの上ないと来たものである。

さてWindows 7時代.NET Framework 3.5が標準で入っていた頃に作られて15歳のこのプログラムであるが、仮想マシンなども考慮するのと開発・動作両方の関係でよほど酷いバグがなければWindows XPをデッドラインとして.NET Framework 4.0をベースにする(今までは.NET Framework 3.5をベースとしてexe.configファイルで.NET Framework 4.0以降があればそちらを優先していた)ことを考えている。

自分でもまだまだ必要になることから、最新のVisual Studioへの開発体制の対応面や.NET Framework 4.8はまだWindows 7以降用としてサポートされるのでこのあたりがバランスの取りどころかと思う。

というわけで、酷いバグがないようであれば次は.NET Framework 4.0以降と動作環境が変わるので、Version 3.0.0として開発のためだけに.NET Framework 3.5が不要な状況を作ることを考えています。

Oppo Pad AirのSDカードを見失う問題が今更解決できた？...やっぱりダメでした。

タブレット Android

Oppo Pad AirのSDカードに悩まされる

買って1年になるOppo Pad Air。10.3インチの割には細身でダイソーで売っている小型タブレットポーチに入ったり、盾持ちだと文字入力時に両手持ちでキーボードっぽく打てたり、音も悪くなく取り回しは良いのだが最大の弱点があった。

SDカードが数日くらいのしばらくすると認識されなくなるというものである。

電子書籍系はSDカードに入れて、アプリやその他データは本体という使い方をしようと思っていたのだが、これでは一番の目的である電子書籍が見られないので本体にとりあえず電子書籍とバスの時刻表だけ常設して、後は必要なときに格納して使わなくなったら削除という運用を強いられていた。

解法(のねた)は突然に

この状態で一年半ちょい経った最近、スマホやタブレットのおまけのアンチウイルスってどうよ？という疑問から設定をいじったら認識されなくなることがなくなった。

やったことは次。

  • タブレットマネージャーの設定のセルフチェックを「オフ」にする
  • タブレットマネージャーの設定のストレージの自動クリーンアップを「適用しない」にする

というそれとなくシステムよりな設定の変更である。

これでしばらくするとSDカードを認識しなくなることがなくなったようなので現在経過観察中。

とはいえ、あと半年もするとOSバージョンやや勤務表書き用のMicrosoft 365のサポートの絡みで運用や処遇を検討する時期に入るのだが、ここで解法が見つかったのかなと思うとなんとも言えない感じである。

と思ったら1週間でまた認識がおかしくなった。ダメだこりゃ。

ミツミ製メンブレンキーボードの清掃から見る今のDELL付属キーボードのちょっと良い所

PC ハードウェア

ついでにもう一台やってみた

Realforce 106の掃除ついでにもう1枚掃除できそうなキーボードがあったので、こちらもキートップを外して掃除してみた。

1997年に初めてPCを購入したとき付属してきたミツミ製のメンブレンキーボードである。

こちらはRealforce 106を購入してからほとんど使っていなかったのでホコリの侵入はなかったが年数が年数だけにかなりの黄ばみ具合である。そして、キータッチも鈍くなっていた。

そこで、こちらはキーの底のほこり取りよりは清掃を重視してみた。

中性洗剤(洋服用)で洗った後、洋服用の漂白剤に一晩つけてみたがさすがにその程度では手に負えなかったのでやはりビンテージな黄色のままである。

キーの見た目とストロークについてふと考える

ついでにメンブレンキーボードのキーを支えるカップを取ったのでスプレーグリスを何度かに分けてかけてキーを押したときの滑りが良くなって少しはキータッチが良くならないか試してみた。

キーと押下を検知する所までのバーが数ミリとキーの見た目より全然浅いので何度かけてもちゃんとバーの動きがなめらかになるか不安だったが、心なしキーがスムーズになったくらいではあった。プラシーボ効果くらいか。

こうやって見ると今のDELLデスクトップPC付属の薄くてキーが浅いキーボードがほこりの清掃効率や見た目とストロークが合うことで自分がかつてNECのキーボードでかかった力を入れた押しすぎによる腱鞘炎を防ぐと共にキーが柔らかいので音も静かという合理的な物だということを体感した次第である。下手なエレコムのどこか設計がずれているキーボード買うより(水抜き穴の出っ張りの上にキーが合ってキータッチがおかしいキーボードを静音を人質に買わされた)有線であるということを除くと使えるのではないかとさえ思えてしまう。

残業続きで疲れていたので細かいことをやってみたが興味深い体験であった。

Firefoxの新しいプロファイル機能なにあれ？

Firefox ソフトウェア

Firefoxの新しいプロファイル機能への移行方法がお粗末な事ありゃしない

自分の環境では昨日

forest.watch.impress.co.jp

等で出た新しいFirefoxのプロファイル機能が有効になったのだが、いろいろな所でお粗末な事ありゃしない。

いつもの設定されたブラウザはどこ行った？

はじめ、いつものようにFirefoxを起動すると新しいプロファイル機能のプロファイル選択画面が出てきた。

今までのプロファイルの選択と新しいプロファイル作成を選べて、今までのプロファイルと新しいプロファイルの作成が選択できるようだが、今までのプロファイルの選択を押しても何もできない。

仕方がないので新しいプロファイルをとりあえず作って起動し、一旦終了して今までのプロファイルを選択しようとしたがなぜか選択できない。

これで、事実上のデータロストである。あまり詳しくない人はここで詰まるというだろう。

「ヘルプ」 - 「他のトラブルシューティング情報」で表示できる新しく作ったプロファイルに今までのプロファイルフォルダのファイルを上書き保存することでデータ移行自体はできるのだが、コマンドラインから新しいプロファイル機能のプロファイルを選択することはできない。古いプロファイル機能のプロファイルが選択されるだけである。

今までのブックマークを蓄積してきたスタンドアローンの旧来プロファイルとAndroidやLinuxのFirefoxと同期するための旧来プロファイルを使い分けてきた自分にとってはランチャーのボタン登録でのプロファイル選択ができないので新しいプロファイルを能動的に使うにはプロファイル選択画面を一度経る必要があるという一手間がかかるので非効率的なことこの上ない。

ChromeなどBlinkベースのブラウザでは金太郎飴のように同じコマンドラインでプロファイルをコマンドラインから使い分けてランチャーなどで使い分けられることを考えるとこの実装はお粗末である。

更に、今までの実行ファイルfirefox.exeを-profilemanagerオプション付きで起動してプロファイルを作り、ランチャーなどで起動する際は-P プロファイル名でプロファイルを切り替えることができていた上、新しいプロファイル機能でできることは今までのプロファイル機能と変わらないときた物である。

これなら、従来のプロファイルマネージャー機能のGUIを現代風に変更して普段から呼び出せるようにするだけで良かったんじゃね？

強硬手段

いつもの設定のFirefoxが使えないと困るので強硬手段を執ることにした。

過去の都合でプロファイルを通常とは別の所に作っていたので、

C:\Users(ユーザー名)\Appdata\Roaming\Mozilla\Firefox 配下の

  • Profiles フォルダ
  • profiles.ini

を消してプロファイルのないインストール直後の状態を作り、一旦初期プロファイルを作った後今まで使っていたプロファイルの情報を亡き者としてFirefoxを起動し、終了した後今まで使っていたプロファイルの情報を書き写すということでとりあえず使えるようになった。

この後、段階的ロールアウトでプロファイルメニューが出てきたが、新規プロファイル作成を押しても何も起きないという状態。

実害はないが、なにそれ？状態である。この後の仕組みの解析結果の構想を見るに、どうにも作り込みが甘い状態で出した感がありありである。

画像のダウンロードなどもできる強力なページ情報機能、カジュアルに大量のブックマークをため込めるブックマークメニュー、ブックマークツールバー、その他のブックマーク、モバイルのブックマークと一時的に専門ページをブックマークするのにも使えてブックマークマネージャーもなれべ替えなど強力なブックマーク機能、サイトが用意している場合用意したスタイルシートを選択できるテーマ機能のようなalternative style sheetの選択機能といった情報を読むための機能があるので情報を読むためのブラウザとして優れている上に危険性のあるWeb標準に提案された機能を実装しないでWebの安全を陰で支えるといった安全性とプライバシーに配慮した設計方針は他にはないので、頑張って欲しかったという所である。

続きを読む

MulSync Version 2.1.4

自作ソフト プログラミング ソフトウェア C#

事件は夜起こった

1時間残業して家に帰り、ふとLinuxマシンとのデータのやりとり補助に使っているHDDをMulSyncで同期しようとHDDの側から起動してチェックをしてみた。

「あれ？なんか変だ」

悪魔は細部に宿る

出てきた不具合はポータブルモードで起動したときの動的に決まる(外付け)起動ドライブのファイルチェックの誤りだった。

悪魔は細部に宿るとばかりに不具合は利用頻度の低いところに潜む格好である。

今まで気づかなかったのは、普段の起動よりポータブルモードでの起動が少なかったのとファイルを外付けドライブに送ることが大半で外付けドライブからファイルをコピーするシチュエーションに出会わなかったため、今回同期したマシンのフォルダ構成を大幅に変えたことでバグが顕在化したという物である。

Version 2.1.2でファイル名のチェック処理に大幅に手を加えた際に2.1.3に続いてここも漏れた格好である。チェック項目増やさないと。