Linux

Boot-repairでgrubを修復

メモメモ。

余ってたSSDにLinuxMintを入れて非常時に起動できるようにしようと思ったら、grubの見先が変わってしまった。

configファイルとかで手動修正も可能みたいだけど、検索してたら、Boot-repairなるツールがあることが解った。

ここを参照

一応書いておくと以下の手順でアプリ追加

$ sudo add-apt-repository ppa:yannubuntu/boot-repair
$ sudo apt update
$ sudo apt install -y boot-repair

あとはboot-repairを起動して、おまかせで修復。

昔はこんな作業も難しかったもんだけど、ずいぶん便利になったねぇ。

| | コメント (0)

メインマシンのSSD交換

メインマシンのLinux用のSSDを交換しました。

#交換つーか、追加なんだけど。

購入したのはこれとこれ。

SSDの方はNTT-Xストアで購入。

#買った時より500円値下がりしてて、ちょっとショック。

拡張カードの方は、マザーボードのM.2スロットを使ってしまうとSATAポートと排他のため、既存ドライブが使えなくなること、M.2スロットにアクセスするには、いろいろ外さないとならないこと、が理由となり、PCIeスロットに装着するために購入しました。

#起動ドライブにできるかどうか、不安があったのですが、そこはさすがASRock、ふつーに対応してました。ちなみにASRock Z270 Extream4。

購入したSSDはM.2形状のNVMe形式のもので、従来のSATAのものより高速というのが売りです。

SATA3も十分高速ではあるのですが、SSDになると、バススピードのせいで、転送速度が頭打ちになっていました。

そこでNVMe規格が出てきた、という経緯があるようです。

この辺、あまり気にしてなかったので、そういうものがあることを知りませんでした。

Windows用のSSDはSATA3のものですが、まあ、十分に高速だったので、それでいいかな、と思ってたんですが、より高速なストレージがあるなら、試してみたくなるのが人情でしょう。

#廃人だけか。

購入したのは、型式についているLiteからも明らかな通り、エントリーモデルで、性能を追求したものではありません。

それでも、SATA3の3倍の転送レートをマークするというのですから、ここは期待でしょう。

中身の移行は、DISKから、イメージの作成/リストアで新SSDにイメージ転送してから、gpartedでパーティションを拡張しました。

容量も512GBありますので、Linux用途としては巨大すぎるため、/homeも同一ドライブに移行しています。

この時、DropboxとVirtualBoxの仮想PC、toolなど容量の大きいものは、HDDに残したままとし、SSDに作成したhomの下にマウントしています。

結論からいえば。

ベンチマークは3倍。読み書きとも高速になっています。

エントリーモデルでもリード1.5GB/sって。ハイエンドだと、PCIe3.0x4の帯域食いつぶすほどの性能らしいので、動画編集なんかやってるひとには、ハイエンドのNVMe大容量SSDは必須になるんでしょうね。

ワタクシの用途としては、エントリーモデルで十分です。

GIMPが一瞬で起動して笑えます。

他にもVSCodeなんかもめっさ軽く起動しますし。

同容量だと、割高なNVMe SSDですが、性能考えると安く思えてしまいますね。

まあ、今回は、たまたまNTT-Xストアで安売りしているのを見かけたので購入に踏み切ったわけですが。

Amazonから比較して半額になってましたからね。

Amazonでの値段だったら買わなかったと思います。苦笑

加えていえば、Linuxに使っていたSSDは、128GBのもので、まだメディアとしての信頼性が高くなかった頃のものであり、書き込み回数の制限も比較的厳し目の時代のものでした。

なので、そろそろ交換時期ではあったわけです。

#勢いで購入したのを正当化。

ま、/homeの方は、これから巨大データを扱うことはありませんし、そういうデータはHDDの方に逃してしまうので、今後しばらく容量的な問題で困ることはないと思いますね。

しかし、ここまで性能が出るとなると、Windows用に1TBのものが欲しくなってくる…

まあ、バスが空いてないので無理なんですがー。

次にPC組む時は、Widnows用のSSDも検討することにしましょうかね。

| | コメント (0)

透過するカレンダー(完結?)

苦心惨憺。

透過するカレンダーが、どうにか形になりました。

これまで透過していたメインウィンドウが、どんな設定をしても透過しなくなってしまったのが苦労の原因です。

どうやら、Gtk.Builderで作成したトップレベルウィンドウには透過設定(CSS含む)が適用されないようで、Gtk.Windowを自前で作成し、そこにGladeで作成したカレンダーの中身をaddすることで、期待通りの動作になりました。

 

このへん、特にドキュメントが見当たらなかったので、バグの可能性もありますが、まあ、それはどうでもいいことで。

結果がすべてですから。

_20191008_210019

これが無事に透過したカレンダーのスナップです。

以前とそんなに変わりないですね?

この状態を取り戻すために苦労していたのです。

なお、Gladeでトップレベルウィンドウを作成してもCairoリージョンによるウィンドウマスクは問題なく動作します。

CSSも「透過以外は」正常に適用されていました。

ワタクシが実現したい「透過」だけがNGだったのです。

もはや誰かの陰謀を疑うようなピンポイントの責めでした。

問題解決のいとぐちとしては、「シンプルな透過ウィンドウのサンプル」を発見したことにあります。

これです。

このページの下の方にあるPythonサンプルを実行して、ウィンドウが透過するかどうかを確認したのです。

そうしたら、なんということでしょう!

普通にウィンドウが透過するではありませんか!!

なので、ここから推測して、違いはなにか、ということを追求していきました。

まあ、結果はGladeを使ってるかどうか、なわけですが。

なので、Gtk.Builder内部でなんらかの処理が行われて、Gladeでトップレベル指定されているウィンドウが透過しないようになっているとしか思えません。

#ワタクシは英語力が貧困なので、英語のドキュメントを漁っても「トップレベルウィンドウは自分で破棄してね♡」という記述しか見つけられませんでした。

 

とはいえ、GUI構築のためにGladeを使わない選択肢はありえません。

#まあ、いまXamarinやってるから、案外Gladeなしでも行けるかも知れん、とも思いますけれども。

そこで考えついたのが、前述の「トップレベルウィンドウは自前で用意。そこにGladeで構築したコンテナをぶちこむ」だったわけです。

うまく行った時には小躍りしそうになりました。

#踊ってませんよ?

まあ、需要があるかどうかは知りませんし、今後もメンテしていくかどうかは解りませんが、いちおうGithubに公開しておきます。

https://github.com/kaorin/gcalcal

んでもまあ、これもdeb作らないと、設定とかめんどうなんだろうなぁ。

依存関係にgcalcliが入ってくるし、そっちの設定はそれなりに手がかかるので、ワタクシは知らん、と放置したいところではあります。

では今夜はこのへんで。

| | コメント (0)

萌え時計(吹き出しデータ更新)

枠線を自前描画して、細くすると吹き出しに設定されている外枠が表示されてしまう場合がある、ということでTOYさんが吹き出しデータを更新してくれました。

そのデータを含んで、debファイルを作成しています。

これでだいたいやるだけやったかな。

みくんちゅ♪の吹き出しデータは…

位置変更すると確かに微妙すぎる。苦笑

みくんちゅ♪枠を使用する場合は運用で右下固定で御願いします。

https://github.com/kaorin/moeclock/releases

| | コメント (13)

透過するカレンダー(引き続き)

結局、アリモノのコントロールでは満足出来なかったので、Gladeで画面を作成。

予定日のマークや、休日の色変え、土曜日の色設定などなど。

CSSで定義出来る部分を増やして、イベントのある日にはツールチップも表示可能。

_20190917_223247

添付のCSSで色とかイベントの背景色とかは設定可能です。

肝心のgcalcliとの連携部分が、まだソースコード埋め込みになっているので、この辺をダイアログで設定可能にすれば、汎用性は一気に上がると思われるけれども、個人使用では、この程度で十分満足出来る感じ。

これ以上は、この画面から予定の登録とかその辺の機能追加になるかなぁ。

やれないことはないけど、カレンダーから予定入力は、運用の面であまり用途がない。

iPhoneで予定登録してPC画面で忘れないように表示しときましょうか、ってのがこのアプリの目的なので、ここから予定入力となると、ちょっと機能過剰。

まあ、そういう運用をしたくなったら機能追加かな。

アプリ名も適当だしdebも作ってないし。

あくまで個人用な感じ。

要望があって、自分でも使う機能なら追加するかも。

ひとまずGithubに登録。

https://github.com/kaorin/gcalcal

やはり休日と土曜日、祝日の色を変えるのは必須と思った。

あとイベント日の背景色も変えるのも重要。

カラーはCSSで設定可能なので、弄るひとはご自由に。

| | コメント (0)

透過するカレンダー(とりあえずここまで)

CSSとかで頑張らないとダメなんだけど、そのCSSの情報があまりない。

GTK+ Inspecterなんてのも使ってみたけど、そこまで詳細な情報は取得出来なかった。

GTKのバージョン依存?

イベントを設定した日(Marked)と週末/休日の色を変えたい。

_20190915_195930

曜日を表示しているCSSはなんとかわかったんだけども。

ん〜難しい。

ソース保存の意味も含めてGithubに登録。

/kaorin/gcalcal

Readme、まだなんにも書いてねぇ。

ウィンドウデコレーションのON/OFFと透過率を指定可能。

背景に指定画像を表示とかも不可能ではないけど、あんまり意味がないように思われる。

#昔、もえせっとあっぷでやったような…

 

| | コメント (0)

萌え時計完成。

ようやく終わった感。

今回の対応で、GTKとCairoの使い分けも出来るようになったので、学習効果はあったかな。

本家で紹介されてます。>今回の対応

| | コメント (0)

萌え時計の吹き出しサイズ調整機能で吹き出しデータをSVGに変更

TOYさんから要望が上がっていたので、SVGでデータを作成していただき対応しました。

当初、けっこうな手間になるな、と思ったのですが、Cairoの機能をちゃんと調べてみれば、案外たいしたことのない手間で実装可能だったので、変更に踏み切ったものです。

ついでに、GTKの機能とCairoの機能を混同していて、うまく実装できていなかった部分も修正しています。

テンポラリファイルを使用していましたが、オンメモリで処理するように変更しました。

ぶっちゃけ自己満足以外のなにものでもないのですが、この辺の処理の見直しにより、コードの見通しがよくなったと思います。

けっこうやっつけ感が強かったからなぁ。

というわけで修正したものをリリースに入れてあります。

/moeclock/releases

| | コメント (11)

萌え時計-吹き出しサイズ変更機能追加

追加で要望が上がっていましたので。

昨悗は眠くて対応できなかったため、早起きして対応してました。

さて、ちゃんと動くのか?

ビットマップを拡大しているので、150%くらいに拡大すると、ちょっとボケた感じなるのですが〜

SVG+フォントサイズ調整となると面倒すぎる。苦笑

/moeclock/releases

続きを読む "萌え時計-吹き出しサイズ変更機能追加"

| | コメント (9)

萌え時計の吹き出し位置変更機能追加(画像追随)その2

吹き出し表示位置変更ですが、画像ファイル名のプレフィックス追加とデフォルト位置設定が紛らわしいのでダイアログを表示するようにしました。

 吹き出し位置を選択すると、以下の動作を行うダイアログが表示されます。
 ・画像に吹き出し位置を保存
 ・デフォルトの吹き出し位置を変更
 デフォルトではチェックされていますが、チェックを外すと、指定動作は実行されません。

仕様としては暫定的なものですが、「やっぱりこの画像の場合は、吹き出しはこっちがいいや」ってなった時に画面から行える手段があった方がいいかな、と。

最終的にはTOYさんと相談になりますけれども。

 

/moeclock/releases

| | コメント (0)