ToDo:
tfgeoによるpos/gammab/geo配列の構成は、tfgeo1による計算直後は、物理並びであるが、tfgeoがMARKer要素に関しては、OFFSET参照先の値を計算してpos/geoを更新しているが、gammabは明示的に更新していないので、tfgeoの設計意図的にはgammab配列上のMARKer要素の値は一つ前の物理element出口の値を保持している状態を意図しているものと思われる
しかし、fractionalなgeometryを計算するtfgeo1の読み出しで、再計算の対象となったelement出口側のgammabは作業領域として使われたあと復元されていない また、MARKerからのoffset計算に置いて、再帰的なMARKer列が考慮されていない (qcell1やtturneでは、tffselmoffsetによる再帰検索が行われている)
また、*frac関数系の動作としては、有限のfracional lengthかつqfraccompが偽(長さの更新が光学系を変更しない)場合、次の要素の値を返している
従って、MARKer要素の有限fractinal positionは、次のelementを指すことになる
他のTypeはすべて偽となる
例えば、
本質的に局所的に不連続な写像を含むSOL, COORD, APERTに関しては厚みが無いものとして扱うほかないと思われる
BEAMBEAMに対しては意味づけの議論が必要
MAPに関しては、非物理的な任意写像を含むので、一般に分割を定義するのは困難と思われる
一方、進行方向に広がった磁場分布をモデル化するUND, WIG, INS, PROTには中点を意味づけ可能
例えば、PROTは、逆写像が存在すればMatrixLog/Expベースで定義可能と思われる
scim + ja-scim-anthyで使っているが、最近の13-stableとportsのアップデート後あたりからscim-panel-gtkが固まるようになった模様 更新かけてない環境で動くのもいるので、何か退行したっぽぃ
ザクッとしらべた範囲では、scimとXIM関連で最近変更されてるportsだと、libX11/glib/gtk2まわりのうち、XIM絡みで前科があるlibX11を巻き戻しても治らないので、それ以外の模様
あと、13-STABLE側だと、kern.osreldateが変更されるmake worldを跨いでいる
日常的に困るのでscimからibusに切り替えてみたが、プロパティーパネルを常時表示で固定する運用だと、起動時の初期位置が画面右上で固定で使いにくい(dconfのschemaにはカスタマイズ向けの座標変数らしきものが用意されているが、ibus-ui-gtk3自身には初期位置がハードコードされている罠)
一応、マウスでドラッグすると動かせるのだが、自分の環境だと初期起動時に常にemacsの裏側になるので面倒この上ないので、パッチしてみた
作例は、基準位置を主画面右下から少し左側(fvwmのパネル分)にシフトしてみた場合
ホントは、gsettingsあたりで見れる org.freedesktop.ibus.panel内のxとかy属性を使うのが正しい気がするが、xsessionがほぼ決め打ちなのでそこまで作り込むのは面倒
--- ui/gtk3/propertypanel.vala.orig 2021-02-21 23:58:38.000000000 +0900 +++ ui/gtk3/propertypanel.vala 2021-06-08 00:57:21.726898000 +0900 @@ -374,8 +374,8 @@ } } else { if (_("default:LTR") != "default:RTL") { - x = monitor_right - allocation.width; - y = monitor_area.y; + x = monitor_right - allocation.width - 262; + y = monitor_bottom - allocation.height - 2; } else { x = monitor_area.x; y = monitor_area.y;
カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記