チェックボックスをなくすのではなく、親のチェックボックスを付けるとすべての子チェックボックスが付くようにするのはどうでしょう
これについてはどういった経緯で今の実装になっているかを説明した資料がなかったため、今憶えている範囲で書いておきます。現在の実装には様々なメリットがあり、そのメリットを失うことは原則許容できません。一方で今の実装に問題がないと考えているわけではありません。以下のことを踏まえた上で、問題が解決できたら、と思っています。
これは実装当初考えていて、以下の二つの問題から、実現が難しいため実装を見送りました。
子となるデータソースが増えた時に、それを選択したことにできない¶
例えばTwitterのリストに対するデータソースのように、あとから増える可能性のあるデータソースでこの問題は起こります。
データソースに階層構造は無い¶
そもそも、データソースにおける階層構造というものは本来存在せず、データソースの表示名を配列で渡された時に、他のデータソースと各インデックスの文字列が一致するものを階層表示しているだけです。
表示だけとはいえ階層構造があるのだから、表示名から階層構造を取得して実装すれば良いかというとそうもいきません。データソースは見かけの階層構造をあとから変更してしまっても、識別名（データソーススラッグ）を変更しなければユーザの選択が保持されます。
階層構造を持たないメリット¶
本題となっている問題を解決するには、現在の実装のメリットを理解した上で、この実装のメリットを潰さないように改善策を検討する必要があります。
例えば今提供されているデータソースだと「@toshi_a＞ホームタイムライン」のように、ユーザの中にいくつかデータソースがありますが、「ホームタイムライン＞@toshi_a」のように階層構造を変えてしまっても、過去のバージョンでユーザがした選択は保持されるということです。
データソースを提供するプラグイン開発者は、名前にはこの程度の意味しか無く、あとから階層構造の変更や、スペルミスの修正をしても良いのです。
その時表示されているものを基準にすると長期的に混乱を招く¶
とはいえ、表示されている段階では階層構造が存在しているため、その時表示されている子全てをチェックする」ような機能は作ることができます。
これをしていない理由は、 階層構造を持たないメリット にあるように、あとから子が増えることにあります。ユーザからしてみれば、全てのリストをチェックしたはずなのに、数ヶ月とか数年後に見直したら、実はそれ以降に作成したリストにはチェックマークが入っていなかった、ということが起こりえます。
これを直感的にUI上で説明するのは困難です。
グループには識別名がないため、記録できない¶
extractプラグインが、利用しているデータソースをどうやって保存しているかという話ですが、これは識別名の配列として保持しているだけです。
全てのデータソースには識別名がありますが、各グループは データソースに階層構造は無い で述べたとおり、データソースではないため識別名が存在しません。
そのため、これを選択されたという情報は保持することができません。
現在運用されている解決策¶
チェックボックスを無効化する¶
上で述べたような理由で意味のないチェックボックスにはチェックマークを入れられないようにしています。
ただし、部分的に無効にする方法が分かっていないので、チェックできるような見た目なのにチェックできないという状態になってしまっているのは、 #736-1 で述べているとおりです。
「○○（全てのアカウント）」というデータソース¶
では現在のmikutterでは特定のカテゴリに分類されるようなデータソースを全て選択するようなことはできないのかというと、決してそんなことはありません。
「ホームタイムライン（全てのアカウント）」といったデータソースがそれで、実装としてはプラグインが全アカウントぶんのホームタイムラインを結合したようなデータソースを提供しているだけで、先に述べたような表示上の階層構造の影響を受けません。
一見、全ユーザのホームタイムラインを選択するのと同じに見えますが、上記のデータソースはアカウントが増えた時にはそれも対象となります。
更にこういったデータソースは、別々の親に属している同じようなカテゴリーのデータソースを一括選択できるとい点で、子要素を全選択するモデルよりも秀でている点もあります。
そもそも親子関係で分類するというのは、探す上では便利なことが多いのですが分類は難しいです。例えば画像をフォルダに分類する場合など、一つの画像が「黒髪」「貧乳」「美少女」いずれの特徴も有していて、入れるべきなフォルダが一意に定まらない場合があります。
「○○（全てのアカウント）」系のデータソースは「ある親の子要素全て」ではなく「あるカテゴリーに分類されうる全て」を選択できるので、抽出タブでユーザが本来やりたいことにより近くなる可能性が高いと思っています。すなわち「○○（全てのアカウント）」系のデータソースは、子要素全選択が実装されたとしても必要となるものなのです。
