mikutter

HierarchyChildは、必ずHierarchyChildParentのあとにincludeしなければなりません。理由は、最初に指摘してもらったとおりの現象が発生するからです。
確かにこういう制約は良くないと考えてます。
このプラグイン内に完結しているので目を瞑っているのが現状ですが、やろうと思えば別のプラグインでウィジェットを定義することもできるので、それをやろうとしてハマったということなら考えないといけないと思います。

今回はどういう状況でこの問題に直面しましたか？

見解有り難うございます。

きっかけは「タブにフォーカス」の類似品で、「タブにフォーカスした時にTLのカーソルを見える位置に移動する」コマンドを作ろうとして、Pane::active_class_ofを叩いた時に気づきました。

処理としては、Plugin[:command]::focus_move_to_latest_widget()をベースにして、paneをactive!した後に、pane.active_class_ofで GUI:Timeline を取得して、TLのカーソル位置を取得しようとしました。

しかしながら、実際にはpane.active_class_ofではHierarchyChild版が呼ばれたため、Timelineが見つけられずnilとなりました。

＞HierarchyChildは、必ずHierarchyChildParentのあとにincludeしなければなりません。

色々やってみましたが、同名メソッドを持つmoduleをincludeした場合、後勝ちになる様です。
PaneはHierarchyParentー＞HierarchyChildの順でincludeしているので、HierarchyChild版が顔を出している様です。

＞このプラグイン内に完結しているので目を瞑っている

設計的にこの動作を許容していると言う事ですね。了解です。
意図しない状況ならば危ないなぁと思ってたので懸念氷解しました。

以上を鑑みると、僕が言いたかったのはGUI::Pane限定でHierarchy*のinclude順が逆じゃない？と言うことみたいです。

（なお、プラグインは自前で同等の処理を実装して無事完成しました。）

3.0で修正します。
Paneと、Profileでも同様の問題を見つけたので順序を修正したことと、間違った順番でincludeした時に例外を発生するようにしてみました。その自前の実装ではなく、guiプラグイン側を呼んでどうなるか試してみてもらえますか。

無事、純正APIで動作する様になりました。
有り難うございました！