友愛その７。

まだ続き。



数値パラメータでスライダを出さない方法やります。


var oProp = XSIFactory.CreateObject ( "CustomProperty" );
oProp.name = "hoge";

oProp.AddParameter2 ( "HageHage",  siInt4,  5 );
oProp.AddParameter2 ( "HegeHege",  siDouble,  4);

var oLayout, oItem;
oLayout = oProp.PPGLayout;

oItem = oLayout.AddItem ( "HageHage", "はげはげ" );
oItem.SetAttribute ( siUINoSlider, true );
oItem = oLayout.AddItem ( "HegeHege", "へげへげ" );

InspectObj ( oProp );



HageHage パラメータを AddItem の呪文で UI に登録する時に一度 oItem に代入しておき、その oItem に対して SetAttribute の呪文で、siUINoSlider は true だぜ、と指定しています。　これはその名の通り、 ノースライダ つまりスライダ無しにするかどうかのフラグを true にしているつまりオンにしています。

結果、スライダは消えます。


こうして　はげはげ　は手打ちフィールドのみの UI になりました。パッと見は文字列パラメータと見分けがつきませんが、AddParameter2 の呪文のところでこの　はげはげ　は siInt4（整数）だと宣言しているので、整数以外は入力できません。　文字列を打ってもはじかれます。

狭いエリアに AddRow を使ってパラメータをいっぱい詰め込んで場所の余裕がなくなると、どのみち XSI は勝手にスライダを消してしまいます。 また、スライダを消すか消さないかくらいの瀬戸際の時は、スライダは表示されていますが肝心のスライダ部分の面積は狭く、スライダの左側に必ず付く手打ちフィールドの方が大きくなってしまい、スライダとしての使い勝手は非常に悪くなってしまいます。　このようにどのみちスライダが意味をなさず、結局はスライダに付属する手打ちフィールドしか使わないのであれば、いっそのこと最初からスライダを無しにして手打ちのみにしてしまった方がスッキリした UI になることが多いと思います。　なのでこの siUINoSlider はよく使います。


ちなみにこの siUINoSlider ですが、もとからスライダを持ちようがないパラメータには効きません。例えば siString （文字列）のパラメータはスライダを付けようがないので、siUINoSlider が意味を成しません。ただ、意味を成さない場合でも、実行したときにエラーは出ないと思います。








ついでに UI 面積の節約をもうひとつやります。


var oProp = XSIFactory.CreateObject ( "CustomProperty" );
oProp.name = "hoge";

oProp.AddParameter2 ( "Ho",  siInt4,  1280 );
oProp.AddParameter2 ( "Ha",  siInt4,  720);
oProp.AddParameter2 ( "Fu",  siDouble,  1.7778);

var oLayout, oItem;
oLayout = oProp.PPGLayout;

oLayout.AddGroup( "" );
    oLayout.AddRow( );

        oItem = oLayout.AddItem ( "Ho", "ほ～" );
        oItem.SetAttribute ( siUINoSlider, true );

        oItem = oLayout.AddItem ( "Ha", "は～" );
        oItem.SetAttribute ( siUINoSlider, true );

        oItem = oLayout.AddItem ( "Fu", "ふ～" );
        oItem.SetAttribute ( siUINoSlider, true );

    oLayout.EndRow( );
oLayout.EndGroup( );


これを実行すると、

こうなります。　数値入力フィールドがでかいために、パラメータ名の後で改行されちゃって、２行になってしまっています。　これ、１行でおさめたいじゃないですか。

なので、単純に考えると、入力フィールドの大きさを小さくすればいいわけですね。
なので前にも出てきた siUICX を指定してやればいいわけです。

以下のように赤字の部分を追加します。

oLayout.AddGroup( "" );
    oLayout.AddRow( );   

        oItem = oLayout.AddItem ( "Ho", "ほ～" );
        oItem.SetAttribute ( siUINoSlider, true );
       oItem.SetAttribute ( siUICX, 40 );

        oItem = oLayout.AddItem ( "Ha", "は～" );
        oItem.SetAttribute ( siUINoSlider, true );
       oItem.SetAttribute ( siUICX, 40 );

        oItem = oLayout.AddItem ( "Fu", "ふ～" );
        oItem.SetAttribute ( siUINoSlider, true );
        oItem.SetAttribute ( siUICX, 40 );

    oLayout.EndRow( );
oLayout.EndGroup( );


すると結果は、

こうなります。　

１行におさめることができました。でも、この赤線のスペースが無駄ですよね。　パラメータ名の後に続く破線を少なくして、その分数値入力フィールドを広げてあげたいわけです。特にパラメータ値のケタ数が大きくて入力フィールドにおさまらない時は、すぐに値を読み取れなくて不便ですからね。だからもうちょっと入力フィールドを広くしましょう。

単純に考えると、現在 siUICX = 40 としているので、この数値を少し大きくしてやればいいと思うじゃないですか。やってみましょう。


oLayout.AddGroup( "" );
    oLayout.AddRow( );   
   
        oItem = oLayout.AddItem ( "Ho", "ほ～" );
        oItem.SetAttribute ( siUINoSlider, true );
       oItem.SetAttribute ( siUICX, 50 );
   
        oItem = oLayout.AddItem ( "Ha", "は～" );
        oItem.SetAttribute ( siUINoSlider, true );
       oItem.SetAttribute ( siUICX, 50 );
   
        oItem = oLayout.AddItem ( "Fu", "ふ～" );
        oItem.SetAttribute ( siUINoSlider, true );
        oItem.SetAttribute ( siUICX, 50 );
   
    oLayout.EndRow( );
oLayout.EndGroup( );


すると、

こうなりますた。

だーかーらー　破線を少なくすればいいだけじゃんかよ　まだスペース十分あるだろが　なんで改行しちまうんだよｺﾞﾙｧ　　モニタを破壊します。


XSI 様にとってはラベル（＝パラメータの表示上の名前。この場合 「ほ～」 とか） を表示するための面積もある程度必要みたいです。　siUICX = 50 とした場合、この 50 という値は数値入力フィールド（スライダがある場合はスライダも含む）の大きさであり、ラベルは含みません。　50 という指定によって、ラベルの表示で消費されるべきスペースに入力フィールドが侵食を始めているようで、そうなると勝手に改行されてしまうように見えます。


こういう場合は、LabelMinPixels を試してみるとよいです。
以下のように、赤字の部分を追加します。


oLayout.AddGroup( "" );
    oLayout.AddRow( );   

        oItem = oLayout.AddItem ( "Ho", "ほ～" );
        oItem.SetAttribute ( siUINoSlider, true );
        oItem.SetAttribute ( siUICX, 50 );
       oItem.SetAttribute( siUILabelMinPixels, 10 );

        oItem = oLayout.AddItem ( "Ha", "は～" );
        oItem.SetAttribute ( siUINoSlider, true );
        oItem.SetAttribute ( siUICX, 50 );
       oItem.SetAttribute( siUILabelMinPixels, 10 );

        oItem = oLayout.AddItem ( "Fu", "ふ～" );
        oItem.SetAttribute ( siUINoSlider, true );
        oItem.SetAttribute ( siUICX, 50 );
        oItem.SetAttribute( siUILabelMinPixels, 10 );

    oLayout.EndRow( );
oLayout.EndGroup( );


すると、

ようやく、siUICX = 50 を満たしつつ１行におさめることができますた。

siLabelMinPixels は、ラベルの表示に使うピクセル数の最小値を決めていることになると思います。　この場合 10 ピクセルと指定しているので、10 ピクセルはラベル用に確保し、その 10 ピクセルに侵食が始まったら改行されるがそれ以下なら改行されない、という状態を作り出したのだと解釈しています。合っているかな。どうかな。


ちなみにですね、マニュアルを見ると、siUILabelMinPixels を使うときは siUILabelPercentage とセットで使うべきだ、と書いてあるんですね。これの意味がよくわかりません。　siUILabelPercentage は、「そのパラメータのコントロール全体のうち、ラベル部分が何％占めるか」　を規定しているように読めます。つまりスライダや入力フィールドやラベルまで全て含めて、その１つのパラメータが占める UI 上の面積のうち、ラベル部分は何％食っているのか、という意味だと思うんですが、セットにしなければいけない理由がわかりません。現に、上の例ではセットにせず、siUILabelMinPixels 単体で使っていますが、目的は達成できています。　マニュアルに従い siUILabelPercentage まで書くとなると、

oLayout.AddGroup( "" );
    oLayout.AddRow( );   
   
        oItem = oLayout.AddItem ( "Ho", "ほ～" );
        oItem.SetAttribute ( siUINoSlider, true );
        oItem.SetAttribute ( siUICX, 50 );
       oItem.SetAttribute( siUILabelMinPixels, 10 );
       oItem.SetAttribute( siUILabelPercentage, 5 );
   
        oItem = oLayout.AddItem ( "Ha", "は～" );
        oItem.SetAttribute ( siUINoSlider, true );
        oItem.SetAttribute ( siUICX, 50 );
       oItem.SetAttribute( siUILabelMinPixels, 10 );
        oItem.SetAttribute( siUILabelPercentage, 5 );
   
        oItem = oLayout.AddItem ( "Fu", "ふ～" );
        oItem.SetAttribute ( siUINoSlider, true );
        oItem.SetAttribute ( siUICX, 50 );
        oItem.SetAttribute( siUILabelMinPixels, 10 );
        oItem.SetAttribute( siUILabelPercentage, 5 );
   
    oLayout.EndRow( );
oLayout.EndGroup( );


こんな風に更に青字の部分が追加になってしまいます。そして、実行した結果は、siUILabelPercentage を記述していない場合と全く変わらないように見えます。　おそらく特定の条件下で意味が出てくるんだと思いますが、俺の経験ではまだ出くわしてない・・・・かな？　どうかな、忘れた。





うーむ、めんどくせえ。　UI のチューニングはめんどくさいですね。

このように、そのパラメータが UI 上にどのように描画されるのかチューニングすればするほど書かなければいけないコードが増えて、開発に時間がかかり、ソースは読みにくくなり、後で見た目を変えたくなった時に書き直す箇所が劇的に増加し、ストレスは溜まり、納期はせまり、雨はやまず、洗濯物は乾かず、クラッチプレートは焼け、車検に金がかかり、破壊されるモニタの数が増えます。　でも見た目が気に入った UI じゃないと使う気になれないので、ここはスクリプト書きの頑張りどころです。　そのスクリプトが実用上便利かどうかなんてもはや二の次ですし、ましてやそのスクリプトを利用しながら作ったＣＧ映像のデキが良いかどうかなんて全くどうでもいいです。　大事なのは UI なんです。そうなんです。





ごきげんよう。




.