Fluxboxウィンドウマネージャーのウィンドウ配置戦略をエミュレートする必要があります。
大まかなガイドとして、ランダムなサイズのウィンドウが一度に1つずつ画面に表示されることを視覚化します。各ウィンドウの大まかなサイズでは、ウィンドウが互いに重なることなく、画面上に平均80個のウィンドウが表示されます。
システムにFluxboxとXtermがインストールされている場合は、xwinmidiarptoy BASHスクリプトを試して、私が何をしたいかの大まかなプロトタイプを確認できます。それが何をするのか、そしてそれがどのように使われるべきかを説明する私がそれについて書いたxwinmidiarptoy.txtノートを見てください。
ウィンドウが閉じ、以前に閉じていたウィンドウが占めていたスペースが、新しいウィンドウの配置に再び使用できるようになることに注意することが重要です。
アルゴリズムは、「最初から入力全体を利用できるようにすることなく、入力がアルゴリズムに供給される順序で、シリアルに1つずつ」データを処理するオンラインアルゴリズムである必要があります。
Fluxboxウィンドウ配置戦略には、エミュレートしたい3つのバイナリオプションがあります。
Windowsは水平行または垂直列を作成します(潜在的に)
ウィンドウは左から右または右から左に配置されます
ウィンドウは上から下または下から上に配置されます
ターゲットアルゴリズムとウィンドウ配置アルゴリズムの違い
座標単位はピクセルではありません。ブロックが配置されるグリッドは128x128ユニットになります。さらに、配置領域は、グリッド内に配置された境界領域によってさらに縮小される場合があります。
なぜアルゴリズムが問題なのですか?
オーディオアプリケーションのリアルタイムスレッドの期限まで動作する必要があります。
現時点では、高速アルゴリズムの取得のみに関心があります。リアルタイムスレッドの影響と、それがもたらすプログラミングのすべてのハードルについては気にしないでください。
また、アルゴリズムが別のウィンドウと重なるウィンドウを配置することはありませんが、ユーザーは特定のタイプのブロックを配置および移動でき、重なるウィンドウが存在します。ウィンドウや空き領域を格納するために使用されるデータ構造は、この重複を処理できる必要があります。
これまでのところ、ルーズなプロトタイプを作成した2つの選択肢があります。
1)Fluxbox配置アルゴリズムのコードへの移植。
これに伴う問題は、アルゴリズムを使用して256ブロックの最悪のシナリオを配置しようとすると、クライアント(私のプログラム)がオーディオサーバー( JACK )から追い出されることです。このアルゴリズムは、256番目のウィンドウを配置するときにすでに配置されているブロックのリストの14000を超える完全な(線形)スキャンを実行します。
これをデモンストレーションするために、text_boxer-0.0.2.tar.bz2というプログラムを作成しました。このプログラムは、入力としてテキストファイルを受け取り、ASCIIボックス内に配置します。make
それを構築するために発行します。コマンドラインオプションのリストには、少し不親切です--help
(またはその他の無効なオプション)を使用してください。オプションを使用してテキストファイルを指定する必要があります。
2)私の代替アプローチ。
部分的にのみ実装されているこのアプローチでは、長方形の空き未使用スペースの各領域のデータ構造を使用します(ウィンドウのリストは完全に分離でき、このアルゴリズムのテストには必要ありません)。データ構造は、二重にリンクされたリスト(ソートされた挿入を含む)のノードとして機能し、左上隅の座標、および幅と高さを含みます。
さらに、各ブロックデータ構造には、4つの側面のそれぞれですぐ隣接する(接触する)各ブロックに接続する4つのリンクも含まれています。
重要なルール:各ブロックは、片側に1つのブロックのみと接触できます。これは、未使用の空きスペースを保存するアルゴリズムの方法に固有のルールであり、実際のウィンドウが互いに接触する可能性がある数には影響しません。
このアプローチの問題は、非常に複雑であるということです。1)ブロックの1つのコーナーからスペースを削除し、2)隣接するブロックを分割して、重要なルールを順守するという単純なケースを実装しました。
削除するスペースがボックスの列または行内でのみ検出される、それほど単純ではないケースは、部分的にしか実装されていません-削除するブロックの1つが幅(つまり列)または高さ(つまり行)その後、問題が発生します。また、これは幅1ボックスの列と、高さ1ボックスの行のみをチェックするという事実についても言及しないでください。
私はこのアルゴリズムをCで実装しました-このプロジェクトで使用している言語です(私は数年間C ++を使用しておらず、C開発にすべての注意を向けた後、それを使用するのは不快です、それは趣味です)。実装は700行以上のコードです(多くの空白行、中括弧行、コメントなどを含みます)。実装は、水平行+左右+上下配置戦略でのみ機能します。
したがって、この+700行のコードを他の7つの配置戦略オプションで機能させる方法を追加するか、これらの+700行のコードを他の7つのオプションで複製する必要があります。これらはどちらも魅力的ではありません。1つ目は既存のコードが十分に複雑であるため、2つ目は肥大化のためです。
機能が不足しているため、アルゴリズムはリアルタイムの最悪のシナリオで使用できる段階にさえありません。そのため、最初のアプローチよりも実際にパフォーマンスが良いか悪いかはわかりません。
このアルゴリズムのC実装の現在の状態はfreespace.cです。私はこれgcc -O0 -ggdb freespace.c
をビルドして、少なくとも124x60文字のxtermサイズで実行するために使用します。
他には何があるの?
私はざっと目を通し、割引しました:
ビンパッキングアルゴリズム:最適な適合に重点を置いているため、このアルゴリズムの要件と一致しません。
再帰的二分配置アルゴリズム:有望に聞こえますが、これらは回路設計用です。それらの重点は、最適なワイヤ長です。
これらの両方、特に後者では、アルゴリズムが開始する前に、配置/パックされるすべての要素がわかっています。
これについてどう思いますか?どのようにアプローチしますか?他にどのようなアルゴリズムを検討する必要がありますか?または、コンピュータサイエンス/ソフトウェアエンジニアリングを勉強したことがないので、どのような概念を調べればよいでしょうか。
さらに情報が必要な場合は、コメントで質問してください。
この質問をして以来、さらなるアイデアが生まれました
- 私の「代替アルゴリズム」と、配置する大きなウィンドウが空きスペースのいくつかのブロックをカバーするかどうかを識別するための空間ハッシュマップのいくつかの組み合わせ。