投稿者: freemikan

大変だった。ダラダラとやっていたのもあるけど丸1日かかった。操作の説明が難しい。スクリーンショットを交えながら、これをクリックするとか、メニューからこれ選択するとか、そういうのがやりづらい。だんだん長くなってくると、途中から苦痛にさえなってきた。

そもそも、Lazarusに興味を持つような人にこんな初歩的なGUI操作の説明は必要ない可能性が高い。一体誰に向けて書いているのか自分でもよくわからない。単にWikiのコンテンツを充実させたいだけなのかもしれない。何にせよ続きを書きたいという気持ちは今のところない。

U++のインストールは通常ソースからビルドする。その筋通りにFedora 42でビルドした。TheIDEを起動して、何らかのプロジェクトを開くとクラッシュする。どうやらlibclangの互換性に問題があるらしい。そういうメッセージが表示される。

もともとU++は独自のコード補完の機能を搭載していたが、それも今の時代にそぐわないためだろうか、2022年頃からlibclangを使用するように置き換えられた。そのlibclangが原因でクラッシュする。Fedora 42ではパッケージマネージャーでclang-libsというパッケージをインスールすることでlibclangが使える。そのバージョンは20になっている。それより前のバージョンはclang19-libsのような名前のパッケージになっている。

TheIDEで使用するlibclangのバイナリのパスを手動で設定する方法がないようだ。システムの方でデフォルトのclangのバージョンを変更してしまうのも良い考えだとは思えない。コード補完の機能を完全にオフにしてしまえばクラッシュはしないと思われるが、それでは不便すぎる。

もしかしたら見落としているだけの可能性もある。

FlatpakにTheIDEが存在しているのを見つけたのでそちらも試してみた。クラッシュはしない。しかし、やはりコード補完がおかしい。具体的には、次のようコードをエラーとする。

void foo(char const *s) {}

void ExpectNoError()
{
    Upp::String x = "Hello, U++!";
    foo(x);
}

これはエラーであるべきではないし、実際にコンパイルはパスする。しかし、AssistのコードチェックではStringからconst char *への変換はできないとエラーを報告する。

奇妙なことに、Assistの設定でC++標準をデフォルトのC++17からC++23にするとすべてがうまく行く。だからといってそのまま使い続けるのは気持ちが悪いので全くハッピーになれない。残念な気持ちのほうが強い。

Fedora 42は新しすぎるので仕方のないことだ。別の環境では特に問題に遭遇していない。そんなに落ち込む必要はない。

おそらく先日USBキャプチャカードを接続したときに誤ったGPUドライバがインストールされたタイミングだと思うけど、使用しているFedora 42のシステムでGNOMEにログインできなくなった。Waylandだけで、Xの方はログインできた。ログを漁って原因を特定しようと時間を費やした。一つわかったのは、Waylandが問題ではなく、GNOMEの方に何かしら問題があったということだけだった。XのGNOMEがログインできるからWaylandが怪しいと思っていたところを逆手に取られた。Waylandのウィンドウマネージャーであるlabwc（これはラズパイOSのデフォルトのウィンドウマネージャーでもある）を試したところ、問題なかったのでGNOMEに何かあると疑いを強めた。また、別ユーザーならWayland+GNOMEの環境にログインできるので、このユーザーの設定か何かに問題があることは確定した。

はっきりした原因はどうしてもわからないので、ユーザーのGNOMEの環境をリセットする方法を調べた。ひどく単純で、ホームディレクトリにある「.cache」、.「.local」、「.config」の3つのディレクトリを削除するというものだった。流石にそれはやりすぎだろうということで、もうちょっと絞り込んでいったら、ディレクトリ「$HOME/.config/dconf」を削除することでログインできるようになるところまでいった。さらなる調査も面白そうだが、すでに時間をかけすぎていたのでやめておいた。

先日Amazonで2000円に満たない額でUSB接続のビデオキャプチャカード購入した。まだ活用はしていないけどPCに繋ぎっぱなしにしてあった。そうしたことが原因でちょっとした問題が発生した。PCを起動するときにUEFIのブート(POST)に異様に時間がかかる。Linuxシステムの起動に異常に時間がかる。また、LinuxシステムのアップデートでNVIDIAやAMDのGPUドライバが勝手にインストールされ、おかしなことになる。

今になってみればそのUSBキャプチャカードを抜けば解決するだけの簡単な問題だと思える。しかし、それに気づけずに、またディスクに異常が発生したのかもしれないなどと色々疑ってかなり時間を費やした。

また、GPUドライバが勝手にインストールされてしまう問題は実際に使うときになったらまた対策を考えよう。

やや苦戦したがLinuxでもちゃんと使えそうだ。OBSやffplayできれいに表示される。ただ、その画面を見ながら操作できるほどにレスポンスは良くない。かなりの遅延が発生するので、マウス操作はままならない。なんとかなるものかどうかを調査するのにだいぶ時間をかけた。結果、無理だと判断した。

ライズパイ4と5はHDMI出力が2ポートあるのが幸いした。1つはPCモニタへの出力で、もう一つは同じ画面をキャプチャカードへ出力する。OBSでは入力の解像度が定番の1920×1080などに制限される。場所を取らないために小さいPCモニタを使いたかったのだけど、そのモニタの解像度が定番のものではないので使いづらい。しかたなく、27インチのフルHDのモニタをつなぐことにした。

そうすると、置く場所と作業場所を確保するためにテーブルをなんとかしないといけなくて、部屋の家具配置を大変更しないといけなくなった。面倒な作業だったけど、最後にはなかなか良い感じに落ち着いた。ちょうど良い機会だったと考えられなくもない。

6月18日にAmazonでUSB接続のビデオキャプチャカードを買った。高価なものなのかと思っていたら、2000円にも満たない額で買えて満足している。

唐突にこんなものが欲しくなったら理由は、ReactOSを触っていている最中にその画面のYouTubeで配信できたら面白いかもと思ったからだった。そうすると、ReactOSを動かしているPCの映像出力をそのまま受信する装置が必要になる。PCモニタの代わりにビデオ出力端子とつなぐものが必要になる。多分そういうのはあるだろうとは思っていたところ、実際にあった。あとは、受信側で入力をデスクトップに表示できるようにするアプリケーションがあれば良い。できれば、その画面を見ながら操作できるくらいに実物のPCモニタの代わりになれれば完璧だが、そんなことできるのだろうか。

それ以前に、ReactOSはまだビデオカードのドライバの問題が解決していないので配信するのは難しいだろう。

それよりは、なんだかラズパイの画面を配信したい気持ちが湧いてきた。プログラミングの動画をやっていたとき、Linuxだとあまり見てもらえないかと思って、VirtualBoxでWindows Vistaを使うという奇妙なことをやっていた。もうそんなことはちっともやりたくない。ラズパイならLinuxでも大丈夫ではないかという気がしている。

YouTubeの再開のことは後で考えるとして、届くのが楽しみだ。

半年ほど前に試したときと状況は変わっていない。

$ sudo dnf install gambas3
$ sudo dnf install gambas3-gb-hash
$ sudo dnf install 'gambas3-*'

これだけやってもだめだった。なんとかかんとのエラーメッセージがポップアップで表示されるのみで起動しない。

ソースからビルドすれば正常に動作する。これも以前試したときと変わっていない。ソースからビルドするにはそこそこの時間がかかるしディスクスペースも1GB以上必要になるので、あまり嬉しくない。

いつになったら修復されるのだろう。

IDEを終了したときや、ビルドしたプログラムを実行して終了したときに、エラーメッセージが出力される。プログラムの動作には影響は見られないが、かなり鬱陶しい。

X Error of failed request: BadAccess (attempt to access private resource denied)
Major opcode of failed request: 152 (GLX)
Minor opcode of failed request: 26 (X_GLXMakeContextCurrent)
Serial number of failed request: 176
Current serial number in output stream: 176

rootで実行すると表示されない。

使用されているfreeglutのバージョンが2.8.0と古いことに原因があるのではないかと疑った。freeglut単体のソースをダウンロードしてできる限り最小のサンプルプログラムを書いて動かしてみることにした。2.8.0はビルドできなかったので、2.8.1で試してみた。結果、問題なかった。

このまま使い続ける気にはなれないので、残念だけど使用を諦めることにした。

Lazarusのスクリーンショットの関係で、ReactOSを試してみたくなった。存在は前から知っていたけど、実際に試すのは初めて。まずはQEMU/KVMの仮想環境で試した。しばらくいじくってみて、なかなか良い感触が得られたので、2010年くらいの古いPCにインストールしてみることにした。

残念ながら、良い結果が得られなかった。まず、インストーラーが起動しないという問題で時間を取られた。USBスティックメモリにインストーラーを書き込んで試したところ、途中で真っ黒な画面で止まってしまう。どうやらCDでないとだめらしい（これに気づくだけで結構時間を食った）。空のCD-RがなかったのでDVD-Rに焼いてやってみた。2台のうち1台は先に進むことができて、最後まで到達できた。起動してみると、異常にマウスやキーボードに対する反応が悪い。ウィンドウの更新がラグすぎる。間違いなくビデオドライバが問題なのだろう。NVIDIAのGeFroce 9600 GTが装着されているので、ドライバを入手してインストールしてみた。インストーラーが動作すること事態が驚きだ。インストールは完了してマウスとキーボードの反応は良くなり、ウィンドウの更新の反応も良くなった。しかし、画面の解像度が800×600しか選べない。というところでやめておいた。

QEMU/KVMの仮想環境だとビデオカードの問題はないが、厄介なのがホストとファイルをやり取りする方法だ。virt-managerにあるファイル共有の機能は使えない。USBデバイスのリダイレクトも使えない。そうするとFTP経由で渡すのが良さそうだが、今回はこの辺りでやめておいた。

サブPCのSSDの1つに不良セクタがあり、修復できない事態になった。まだ動作に悪影響は見られていないが、これ以上使い続けるのは良くないと思い取り外すことにした。

取り外してPCの電源を入れてみると、F11でブートデバイスを選択するメニューがおかしい。フリーズする。また、UEFIメニューに入ると、取り外したはずのOSがリストにあらわれている。

新たに知ったことなのだが、UEFIではブートの仕組みが古いBIOSのものと大きく異なっているようだ。どうも、ここに存在しないブートデバイスの情報が残っていることがF11のブートメニューに悪影響を与えているのではないかと疑って、削除する方法を模索していた。

思ったより難航した。UEFIメニューにはそれらを管理するような機能がない。

Linuxならばefibootmgrというツールで管理できるということを知った。PCに装着されているSSDのOSを起動してそれを試みるが EFI variables are not supported on this system. というメッセージが出力されるだけでうまくいかない。

どうやら、CMSをオフにする必要があるようだ。しかし、CMSをオフにすると、その他のSSDがブートデバイスとして認識されなくなりOSが起動できない。なので、CMSをオフにしたうえで、USBのLinuxライブ環境を起動してそこで試すことにした。efibootmgrで存在しないブートデバイスの項目を削除してから、再起動して再度UEFIメニューからCMSをオンにしてやる。結果、それでうまくいった。F11のブートデバイス選択メニューが使えるようになった。

最近のRaspberry Pi OSのデフォルトデスクトップはバックでンドがWaylandになっている。そのため、CtrlとCapsLockを入れ替える定番の方法が使えなくなっている。

• /etc/default/keyboard のXKBOPTIONSに書く方法
• setxkbmap を使った方法
• xmodmap を使った方法

これらはいずれも使えないようだ。

試してうまく行った新しい方法は $HOME/.config/labwc/environment に設定を書く方法だった。内容は次のようになっている。

XKB_DEFAULT_MODEL=pc105
XKB_DEFAULT_LAYOUT=jp
XKB_DEFAULT_VARIANT=
XKB_DEFAULT_OPTIONS=ctrl:nocaps

XKB_DEFAULT_OPTIONS=ctrl:nocaps が変更した箇所だ。デフォルトでは空になっているので、そこに ctrl:nocaps を追加してやった。非常に紛らわしいことに、ダブルクオートで囲んではいけない。それだと機能しない。

ともかく、現時点ではこれでうまくいく。

3日ほど使ってみた。結果、使うのをやめることにした。ほんのちょっとだけLinuxディストリビューションを試してみる程度ならありかもしれないけど、それ以上は求めないほうが良い。UIや設定項目が無駄にシンプル過ぎて使いづらい。結局virt-managerの助けを借りないといけない。それなら最初からvirt-managerだけを使えば良い。そういうことで、もういじくり回すのはやめた。

Ubuntuではgnustep-develというGNUstepの開発環境をまとめてインストールしてくれるパッケージが存在している。チュートリアルにこのパッケージではclangをコンパイラに使用できないと書いた。改めて見ると本当にそうなのか自信がなくなったので確認しておいた。結果、確かに使えないことがわかった。Foundation.hを利用する単純なHelloWorldプログラムでobjc.hが見つからないというエラーになってコンパイルが通らないことがわかった。

まだ疑念が完全に消えたわけではないけど、なんだかんだ良い本だと思う。流し読みだったので、ほとんど吸収できていないだろう。そのときが来たらじっくり読むことにする。GUIアプリケーション開発のベストプラクティス集として引き出しに入れておく。

MVCとリアクティブプログラミング。ためになる。しかし流し読み。一回このペースで最後まで目を通してしまうことにした。

ここは全部FLTKについて書かれていて安心した。信頼しても良い本であることに確信を得た。

ついにPythonのコードまで登場した。GUIプログラミング一般についてだけ述べられていてFLTKに触れていないセクションは別の本の使い回しではないかと疑念が強まった。それらの部分の内容は決して悪くない。ただFLTKとリンクしていないので空虚になってしまうのが問題だ。

これは受け入れないといけないことなのかもしれない。マニュアルを見れば分かるようなことを本にしても仕方がない。この章のように高いレベルを切り口に語らないといけない。そうすると、どうしても一般論になりがちで、それはどのGUIライブラリの解説であっても同じ内容になってしまう。

少なくとも生成AIで作られた文章ではない。使ったことないからわからないけど、このクオリティの文章を生成するのは難しいのではないかと思う。