@akkiesoft 酒飲んだらできた

This account is not set to public on notestock.

マジ？言ったな

gtk3ブランチはどの辺のファイルに手を入れているのかという確認用のテキスト
https://gist.github.com/shibafu528/904b822bdc42fd303996490f138e6938
#mikuttergtk3

おきた

あたまいてー

This account is not set to public on notestock.

お

ふとツイみたら、昔使ってたソフトに異様な機能が追加されててビビった
https://twitter.com/m_matsubara/status/1429313569166749697

飯どうしようになっているよくわかんねえ

やっぱりmikutter.gitが一番push速い

#mikuttergtk3 gtk3 gemの参照を上流のmasterにある今一番新しいコミットに変えた。不都合ありそうならRevertします。

temporary mogunoをさっさと消したかっただけ

set_shape_rendererでセグることがあって、根拠はないけどこれこうなんじゃないかと思って書き換えてみているが、そもそもセグりの再現性がない
https://gist.github.com/shibafu528/d4a5db1ae3ed50d96d0cf3a1aed3d56a
#mikuttergtk3

GTKに渡しているブロックの中でブロック貫通した大域脱出したら死にそうみたいなそういう直感

直感commit

めしくお

あとどれくらいgtk障壁があるのか、まずはmikutter側を洗わないとだが

どうやっていこうかなあになってる

状況が変わってしまったので、本当なら美しさよりも最小手でのマイグレーションを実施してからGTK3らしくしたいところだが……

diffを改めてる
gtk_dark_matter_prification.rbがロードされてるの、これはいいのか？w なんかミスっぽい気がする #mikuttergtk3

関係なさそうだなーしぬわ

GRClosure invoking callback: already destroyed: GtkMenu::deactivate
は、Gtk::Menuをその辺の適当なインスタンス変数に突っ込んだら出てこなくなったんだけど、Gtk::MenuItemのほうはwarning出ない上にProcも特に呼ばれないのでむしろ謎になった
#mikuttergtk3

ハッシュタグ付け直しまくってるが自分用

gtk3ブランチ、特殊環境では起動不能になった
- ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [arm64-darwin20]

safaty_signal_connect内でprintデバッグしてるが、どうもGtk::MenuItem.activateにconnectしたやつまったく呼ばれてないぞ？

GRClosureのGC Protect漏れwarnですらないのでマジでどこいったんだよ

これにはshibafu528もニッコリ

Gtk::MenuItemがクリックされた時のsignalってactivateで本当にあってるんですか？？？？？？？？？？？？

ふーん…

@toshi_a しますね

ruby-gnome/ruby-gnomeの最新コミットが俺のPRマージされたやつなので、一瞬自分のforkかと間違えそうになるから早く他のコミットが打たれてほしい

def toshia.say
"#{yome}ちゃんのおっぱいちゅうちゅうする〜"
end

あっおれもうGTKなにもできないかもしれん

実際Qtのほうがわかる

Qt自身をビルドしたらそりゃ長いですよ

@toshi_a 根本から間違えているのかもしれん

mikutterにQt5フロントエンドを後付けする実験はもう過去にやった

バインディングが信頼できなくなったら直接APIコールできる言語で検証する、はい

検証した結果このザマか

@toshi_a
GtkMenu.deactivateをgtk_widget_destroyにconnectしてるとあかんな
これを外した状態でメニュークリックまでのsignal眺めてたら
GtkMenuItem.select
GtkMenuItem.deselect
GtkMenuItem.activate
GtkMenuShell.selection-done
の順で発火された。

@toshi_a no, destroyは購読してない

@toshi_a
menu.ssc(:deactivate) { menu.destroy }

言われてあれっ？となったんですが、gtk_widget_destroyしたらそりゃ何もできずに死ぬ気がするな。
これは単にmikutter/gtk3の実装バグかもしれん。

@toshi_a これの場合はactivateのハンドラーに到達しないね。deactivateが先に実行されて終了。

@toshi_a ちなみにsignal_connectのブロック戻り値ってどういう意味になってる？
Valadocでいうout引数がある場合に対応してる程度に思ってるんだけど、ruby-gnomeにおいては何か意味付けされてる？

@toshi_a そうだね、一旦それで進めたほうが動かせる範囲が広がるので前進できそう。

@toshi_a なるほど理解

destroyしちゃったからGRClosureも解放されちゃったんですかね？と思ったらそこは関係なかった

なんか騒ぎすぎて疲れたな

次はmastodon_account_viewerがマージミスか何かで確定クラッシュするの直すわ…

This account is not set to public on notestock.

犯罪だね

どうせ全部GIを通るんやと思ったら、これはむしろGTK2の時よりやりやすいかもしれない。
Valadocにあるメソッドシグネチャを機械的にRuby訳すればほぼ通るので

Vala書かないけどValadocはGObjectを使うのに便利

昔もそうしてれば案外通ったのかもしれないけど

Valadocのメソッドとかのアイコン、Visual Studioに引っぱられてる感じあるなと思った
https://valadoc.org/gtk+-3.0/Gtk.Widget.html

Pixel3修理に出してた時にメディア音量がMAXにされてたようで耳破壊された

うわーなんだこの例外読みづれー

@ahiru じゃあそろそろ晩飯届くので上げます

GIやっぱわかんねーおしりになった

GIで例外出ると割と読めねえよ馬鹿になる

あれ……これ似たようなこと6年くらい前に言いまくってた気がするぞ……

6年どころではない

それは本当にヨシなのか股間に手を当ててよく考えて

荒巻システム

/home/shibafu/git/mikutter-gtk3/vendor/bundle/ruby/3.0.0/gems/pluggaloid-1.7.0/lib/pluggaloid/listener.rb:25: [BUG] object allocation during garbage collection phase
ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux]

ｷﾞｬｱｱｱｱｱ

GCクラッシュするやつgtk3ブランチに上げたから

みんなも [BUG] を見て嫌な気持ちになろうぜ、俺もやったんだからさ

GC死はマジで分からんから一旦シャワーでも浴びよう

どう立ち回ったものか

あまりに変な落ち方をされるとC拡張を書いたほうが落ちないんじゃないかみたいな根拠のない妄想に取り憑かれてしまうのでやばい

正解はもっと落ちる

ちょっとgtk疲れたからほかのことしようか

mikutter-qt5はさわらんで

いやちょっとおもちゃをみつけたので普通のmikutterで動かす

まずそのために10GBのパッケージダウンロードを要求されていて心が死にかけているが…

ダウンロードじゃねえこれ展開サイズか!!

Qt6なあ、手元のQt5のやつ移行したほうがいいんだろうけどKDE統合が無いから萎える

テーマ的な面もそうだし、ファイルダイアログとかそういう面の統合もそうだし

インストールおわったな、SSDの空きが10GB切った。

インストールするパッケージ間違えてたぜ

数GBダウンロードしなおし

あーこれはArchじゃだめなやつかなあ

今俺はmakepkgを叩いています

SSD埋まりそうなんだけど

土奴の長編だ!

人生相談。 - ニコニコ動画
https://www.nicovideo.jp/watch/sm39319666

SSD足りるかな〜df -h

→ / 200MB

あっだめだ

.cache/yay がいつもデカいことを思い出せたので6GB空けた

ENOSPCで止まる前に空けられたのでセーフ

@toshi_a ありがとうその手をいつも忘れる

@toshi_a 2GBしか空かんかったわ

@toshi_a さ、さいきんLinux機使ってなかったし…