どこかに行ってしまったウィンドウを戻す

マルチディスプレイのサブディスプレイでつかっていたとあるソフトを、シングルディスプレイで使おうと起動してみたところ、どうやらまだサブディスプレイがあるものと勘違いしているらしく、画面外から帰ってこない。以前にも同様な症状になったことがあるが、いつのまにか問題が解消されていた。

今回またおこったのだけど、どうしようかとGoogle先生にお伺いを立てたところ、

www.atmarkit.co.jp

という情報を教えて貰えた。無事回復。

LibreOfficeのメニューが表示されないぞ!

X270で快適生活なんだけど、気づいたらカメラもX30だった。なんだかXシリーズつかっているのね、他にもあるかな?

さて、X270をメイン機にするということで、必要なソフトは一通りインストール完了。マウス共有は、実は双方向でセットアップされている事に気づき、今はX270側のマウス&キーボードをデスクトップの操作につかっている。

さて、つぎはプレゼン等にも必要なLibreOfficeMS Officeを使えばいいのだけど、慣れというか過去の資産というか、いまだにLibreOfficeメイン。さてさて最新版と5.4.3をインストールしてみると・・・・・

メニューが表示されない!どうも表示されていないだけで、そこにはメニューがあるらしい。アイコンがずれて表示されているので、仕事にならん。なんとか見えないメニューでオプションを開き、きっとOpenGLだとあたりをつけて解除してみるが・・・・変化なし?アンインストール&インストールでもだめなので、やっぱりグーグル先生と検索してみると

www.niteco.co.jp

あるじゃん。で、解決方法一緒じゃん。もう一度やってみたら無事にメニューが表示されました。

しかし「すべてのレンダリングOpenGLを使用する」を外すと、一部のレンダリングには使われている事になるのだろうか?メニュー等にはいらないのだと思うけど、ドキュメントの中身で必要な場合もあるのでは?

TeXstudioを使ってみる

今までは、TeXは一括インストール。エディタは emacs (gnupackかNTemacs)、TeX GUITeX Shell 2 でやってきた。ただ、TeX Shell2の場合、PDFまで作ろうとすると、ファイル更新に対応できるビュワーがないと少々面倒。AcrobatでPDFを見ていると、dvipdfmx で変換できない。統合環境は、エディタでいつも毛嫌いしていたのだけど、今回試しに TeXstudio を使ってみる事に。

今のところ、それほど問題ない。

TeX for Win

Windows向けのTeXは一括インストーラーにセットアップをおまかせしている。X270にインストールしてみて、一つだけ躓いたのでメモ。

ghostscript等のリストに64bit versionがあるので、そちらを選択。タイプセットは問題ないのだけど、dvipdfmxでdvi→PDFを試みるがエラー。エラーはepsファイルが見つからないとの事。

結局、64ビット版*しか*インストールしなかったら、PATHが通っていなくて、gs を見つけられないというオチ。PATHの設定をいじるのではなく、今回は32ビット版をインストールして問題解消。

まとめて64ビット版にしてしまうような設定があるといいなぁとおもったり。

久しぶりにThinkPadにしてみた

いい加減J10の動作ももっさりしてきたので、ノートパソコンを新調。最近は出張もそれほどないし、タブレットで事足りるときはタブレットで十分。ということで、あまり小ささにはこだわらない方向で検討。

とはいえど14インチは大きいので12インチ、その他もろもろの事情で久しぶりにThinkPad Xシリーズに。X270米沢モデル。なんの因果がこの地にながれてきたこともあり、米沢モデルいいよね、って感じ。

その昔PowerBook 2400cを使いながら、IBM京都工場がうんたらかんたらといっていたようないっていないような記憶にひたりながら、X270を使う。今つかっているデスクトップよりも性能は良いので、いっそのことメイン機にする事に。何年も前X2?をメインで使っていたときのように、と思うのだけど。。。。

デスクトップの方はHDD容量が魅力。X270も奮発してSSD512をつんだけど、HDDにはかなわない。Google Drive等のクラウド経由でファイルを管理するので気を抜いているとデスクトップの方でどかどかと使うとX270側でも容量が減っていく。

しばらくはX270をメインとするけど、デスクトップも使う必要もあるわけで、机の上がごちゃごちゃする可能性が大きい。それなら、キーボード共有か?とおもうのだけど、USB切り替え等を使うよりもきっと今はいろいろ便利なものがあるだろう。

そういえば以前Synergyを使っていたけど、正直MacLinuxWindowsでの共有+日本語キーボードで少々面倒だった記憶がある。それでもものは試しと、ホームページを覗いてみると・・・・有償ソフトになっているねぇ。さて・・・・

と、他の可能性を探ってみたところ、

Microsoft Garage Mouse without Borders

なるものがある。Widows限定だけど今の環境であればまったく問題なし。早速試してみました。

環境としては

・ デスクトップPC側に最初にインストール: デスクトップPCのマウス等を共有

・ ノートパソコン側にインストール: デスクトップ側のキーを入力

・ どちらも同じLAN内に。(今はノートは無線、デスクトップは優先。)

・ どちらも日本語環境。キーボードはHHK Pro J。マウスはLogicool M705。

です。使ってみて

  1. キーボード: 入力遅延はほとんどなし。キー配列も問題なし。
  2. マウス: デスクトップ側でSet Pointで速度・加速度設定をしているが、ノート側には反映されていない?若干反応が悪い気がする。作図作業だときになるような気が。

若干マウスの挙動に気になるところがありますが、キーボードの方はリモートである事がほとんど気にならないレベル。素晴らしいですね。もうしばらくつかってみましょう。

 

※ 追記

電源設定でカバーを閉じても何もしないようにしてみた。Let's Note J10は電源ボタンが側面にあるので、カバーを閉じていても電源を入れる事ができる。X270は蓋をあけないと電源スイッチに手がとどかない。どうしても電源いれてから蓋を閉じないといけないわけだが、ドックを使うと解決できるだろうか。

同時期に別件で入手したTシリーズは、なぜか設定してもカバーを閉じると休止してしまう。なぜだろう。

マウス共有はスリープ解除後も自動的に復帰。再起動後でもOK。タスクに常駐してくれるのが良いですね。

一度、共有が切れてしまったときがあった。サーバー側のプログラムがハングしてしまったのだが、いまいち理由がわからない。

マウスがまともに動かない

Windows 機でマウスがまともに動かない日がつづいていた。問題のない時もあるのだが、急に反応が悪くなり秒単位で止まる。

  • 充電?: SetPointで見る限りOK
  • マウスパッドの摩耗?: 新品にしても同じ
  • メモリ?: 再起動しても駄目
  • Windows Update?: Fall Creator Updateを入れても駄目

と、なにをやっても改善しない。ハードウェアのトラブル?と疑いはじめていたのだが、PC本体に挿していたレシーバーを手元のUSBハブに挿してみたら問題が解決した様子。今の所極めて快調。

結果オーライなわけなのだが、この症状は最近とみにひどくなっていたこと、特にその間にUSB機器の追加などもしておらず、まったく意味不明。マウスとの通信の劣化なんだとは思うのだが。

ちょっと作文をしないといけないのだけど、フォントの体裁整えたり、コピペ、図の移動などでストレスマッハだった所が解消されて、まったくヤレヤレだぜ。

愚痴ついでに。作文作業だけじゃなくって、ファイルを移動しようとドラッグしていても、移動の途中で通信が途切れるのか、マウスが止まるだけじゃなくてファイルをドロップしてくれる。Acrobatで領域選択で図のコピペをしたいのに、選択途中でかってに選択終了になる。もうほんとうに作業がまったく進まない。進まないならまだしも、むしろ後退。

昔は良い印象をもっていなかったけど、Bluetoothでつなぐ方がもしかしたら安定しているのかも?と思ってみたり。

ただ、レシーバー間距離を縮めてみたら、ほんとうに改善というより問題解消なので、もうこれでいいや。

ROOTでバグ?

ROOTをつかっていろいろやっているのだけれど、よくわからない現象がおきたのでメモ。

最近になってc++11や14に少しづつ馴染んできている。他人が残していったコードを整理しながらすすめているとこれまで知らなかった利点なども見えてくるわけで、自分なりに工夫しながらつかってみようかしら、と試してきた。

今回の問題は std::shared_ptr 。shared pointer 自体に問題があるわけでもなく、適当なメソッドで std::shared_ptr< TGraph > オブジェクトを返すようにしておいて処理をすすめておけば、delete の問題を自然に回避できて良いですね、ということで使う訳。

今回のケースは、返り値として得たstd::shared_ptr<TGraph>をつかって作図したいという話。作図するのだけど、ROOTの良いところというか面倒な所は、作図はCanvas上のイメージを更新するだけではないというところ。Canvas 上には作図対象のオブジェクトが連結されていて、そのオブジェクトに変更が加えられると自動的に図も更新される。あるデーターを持つグラフオブジェクトがあって、その内容をキャンバス上にグラフ化しましょう、と例えば TGraph::Draw() メソッドを呼ぶ場合、内部的にはTGraphオブジェクトを連結、そのオブジェクトを利用して更新がおこなわれる。オブジェクトに変更を加えると、Canvasに再描写命令を与えなくても勝手に図は更新。

便利なんだけど、寿命をもつオブジェクトを作図するといろいろ問題が。ヒープ領域に new で確保するのじゃなくて、適当なスコープ内でオブジェクトを普通に生成しDrawしても、スコープ終了とともに作図結果もろとも消滅。Canvasは白紙に!回避する手段は、

  • 永続的なオブジェクトとして new する
  • TObject::DrawClone() メソッドを利用して、自身のクローンをCanvasに与えてしまう

後の方法は 元々のオブジェクトに変更を加えてもCanvas内容は更新されなくなり、ROOTのメリットを捨てているようにも感じられます。

さて、今回は std::shared_ptr 。使われなくなると自動的に delete されるもの。TCanvas の方ではそれが shared_ptr なのか知らないわけで、単にDrawをしてもその結果はオブジェクトの寿命とともに海の藻屑と。じゃあ DrawClone でよいかしら、というわけなんだけど・・・・・

普通はこれで上手く行くのだけど、今回はなんだかおかしなことに。Canvasを分割して、複数のプロットを並べて描写していました。分割した領域をPad と呼ぶのですが、PadにはIDがあるので、順に一つづつすすめながら、別の std::shared_ptr< TGraph > をつかって DrawClone。

ところが、結果を見てみると2番目以降のPadでおこなったDrawClone処理は、該当Padに描写するのではなくて、なぜか一つまえのPadに結果を描写しているではないですか。????

なんとなく、DrawCloneした時に、一個前のPadに紐付けされていたObjectと入れ替わってしまう様子。なんじゃこりゃ?ROOTにはクローンを作る TObject::Clone というメソッドがあるので、自分でクローンをつくっておいて、それからDrawしてみるとこれはOK。

TObject::DrawClone のリファレンスマニュアル  ROOT: core/base/src/TObject.cxx Source File を見てみても、結局やっているのは Cloneしてから Draw なわけで、うーんなんだかほんとうによくわからない。

std::shared_ptr< TGraph > をつくっているのは std::make_shared< TGraph > を活用しているので、なにか関係するかもとぐぐってみると

cflat-inc.hatenablog.com

なんていうものもあったり。独自の new、 delete が無視されるというのはもしかしたら問題かしら?なんか昔その関係でいろいろ困った事があったような・・・と思い、 make_shared なしで試してみても問題は解消されない。きっと、 TCanvas 側の方の理由だろうなぁと思うのと、なんとなくいやなんだけど解決策が見つかったのでこれはこれで良しとする。