私は XMLテキストエディター を記述しました。これは、同じXMLテキストに対して2つの表示オプションを提供し、1つは(実質的に)インデントされ、もう1つは左揃えされます。左揃えビューの動機は、XMLコンテキストの自動化された副作用であるインデントによる干渉なしに、ユーザーがプレーンテキストまたはXPathコードのインデントに使用している空白文字を「見える」ようにすることです。
ユーザーを支援する左詰めモードの視覚的な手掛かりを(エディターの編集不可能な部分に)提供したいが、あまり複雑にならない。
接続線だけを使ってみましたが、忙しすぎたようです。これまでに思いついた最高のものが下のエディターのモックアップされたスクリーンショットに表示されていますが、より優れた/より簡単な代替策(コードを多く必要としない)を探しています。
[編集]
ヒートマップのアイデアを採用(から:@jimp)私はこれと3つの選択肢-a、b、cとラベル付けされています:
インデントを使用せずにネストされたコードの可読性を向上させる視覚的な方法を提供するこのアイデアの名前。
NestView内の異なる陰影付きの線の名前
上の画像は、XMLスニペットの視覚化に役立つNestViewを示しています。この図ではXMLが使用されていますが、この図では、ネストを使用する他のコード構文を使用することもできます。
ネストレベルを伝えるために、等高線は(ヒートマップのように)シェーディングされます
等高線は、入れ子レベルが開いているか閉じているかを示すために角度が付けられています。
等高線は、ネストレベルの開始点を対応する終了点にリンクします。
等高線の幅を組み合わせることで、ヒートマップに加えて、入れ子レベルの視覚的な印象を与えます。
NestViewの幅は手動でサイズ変更できますが、コードが変更されても変更しないでください。これを維持するために、等高線を圧縮または切り詰めることができます。
空白行は、テキストをより消化しやすいチャンクに分割するために使用されるコードです。このような行は、NestViewで特別な動作を引き起こす可能性があります。たとえば、ヒートマップをリセットするか、背景色の等高線を使用するか、またはその両方を行うことができます。
現在選択されているコードに関連付けられている1つ以上の等高線を強調表示できます。選択したコードレベルに関連付けられた等高線が最も強調されますが、含まれているネストされたグループを強調表示するのに役立つ他の等高線も「ライトアップ」できます
異なる動作(コードの折りたたみやコードの選択など)は、等高線のクリック/ダブルクリックに関連付けることができます。
輪郭線の異なる部分(リーディング、ミドル、トレーリングエッジ)には、異なる動的動作が関連付けられている場合があります。
ツールチップは、等高線上のマウスホバーイベントで表示できます。
コードが編集されると、NestViewは継続的に更新されます。入れ子がバランスが取れていない場合、入れ子レベルを終了する必要があるという想定を行うことができますが、関連する一時的な等高線を警告として何らかの方法で強調表示する必要があります。
等高線のドラッグアンドドロップ動作をサポートできます。ドラッグされる等高線の部分によって動作が異なる場合があります。
エラーの行番号付けや色の強調表示、状態の変更など、左マージンによく見られる機能がNestViewをオーバーレイする可能性があります。
この提案はさまざまな追加の問題に対処します-多くは元の質問の範囲外ですが、有用な副作用があります。
等高線は、ネストされた各レベルの開始と終了を接続します
コードを選択すると、NestViewの関連するネストレベルを強調表示できます
XMLの場合、異なる名前空間に異なる色相を使用できます。プログラミング言語(c#など)は、同様の方法で使用できる名前付き領域をサポートしています。
読みやすくするために、コードに余分な行が挿入されることがよくあります。このような空の線は、NestViewの等高線の飽和レベルをリセットするために使用できます。
インデントなしのコードでは、ワードラップや水平スクロールが必要になる可能性が低いため、複数列ビューをより効果的に使用できます。このビューでは、コードが1つの列の下部に到達すると、次の列に流れ込みます。
概要で提案されているように、NestView couldは、TreeViewコントロールから期待されるものとおおむね一致する幅広い編集および選択機能を提供します。主な違いは、一般的なTreeViewノードには、エキスパンダーとノードアイコンの2つの部分があることです。 NestViewの等高線は3つの部分(opener(傾斜)、connector(垂直)、およびclose(傾斜))を持つことができます。 。
インデントされていないコードと共に表示されるNestViewは、従来のインデントされたコードビューを補完しますが、置き換えることはできません。
NestViewを採用しているソリューションは、空白文字を含むコードテキスト自体に影響を与えることなく、インデントされたコードビューとインデントされていないコードビューをシームレスに切り替える方法を提供する可能性があります。インデントされたビューの1つの手法は、「仮想フォーマット」です。動的な左マージンは、タブまたはスペース文字の代わりに使用されます。 NestViewを動的にレンダリングするために使用されるのと同じ入れ子レベルのデータは、より一般的な外観のインデントされたビューにも使用できます。
印刷
インデントは、印刷されたコードを読みやすくするために重要です。ここで、タブ/スペース文字と動的な左マージンがないことは、テキストが右マージンで折り返されてもインデントされたビューの整合性を維持できることを意味します。行番号は、コードがワードラップされている場所とインデントの正確な位置を示す視覚マーカーとして使用できます。
NestViewが貴重な画面の不動産を使い果たすかどうかの問題に対処します。
等高線は、コードエディタの文字幅と同じ幅でうまく機能します。したがって、12文字幅のNestView幅は、等高線が切り捨てられる/圧縮される前に12レベルのネストに対応できます。
インデントされたビューが各入れ子レベルに対して3文字幅を使用する場合、入れ子が4レベルの入れ子に達するまでスペースが節約されます。この入れ子レベルの後、フラットビューには、各入れ子レベルとともに増加するスペース節約の利点があります。
注:コードには4文字幅の最小インデントがしばしば推奨されますが、XMLは多くの場合それ以下で管理します。また、仮想フォーマットでは、配置の問題のリスクがないため、使用するインデントを減らすことができます
2つのビューの比較を以下に示します。
上記に基づいて、ビュースタイルの選択は画面の不動産以外の要因に基づくと結論付けるのはおそらく公正です。 1つの例外は、スクリーンスペースが貴重な場合です。たとえば、ネットブック/タブレットや複数のコードウィンドウが開いている場合などです。これらの場合、サイズ変更可能なNestViewが勝者のようです。
NestViewが有用なオプションとなる可能性のある実際の例:
画面の不動産が貴重な場合
a。タブレット、メモ帳、スマートフォンなどのデバイス
b。ウェブサイトにコードを表示するとき
c。複数のコードウィンドウをデスクトップに同時に表示する必要がある場合
コード内のテキストの一貫した空白のインデントが優先される場合
深くネストされたコードを確認するため。たとえば、サブ言語(C#のLinqまたはXSLTのXPathなど)により、高レベルの入れ子が発生する可能性がある場合などです。
視覚障害のある人を支援し、環境条件や個人の好みに合わせるために、サイズ変更と色のオプションを提供する必要があります。
NestViewオプションを組み込んだソリューションは、インポートされたコードから先頭のタブ文字とスペース文字(フォーマットの役割のみを持つものとして識別される)を取り除くことができるのが理想的です。次に、コードが取り除かれると、コードは変更されずに、左揃えビューとインデントビューの両方で適切にレンダリングされます。空白を認識しないマージツールや差分ツールなどのシステムに依存している多くのユーザーにとって、これは大きな問題になります(完全な表示ストッパーではないにしても)。
2004年から発行された Wendell Piez による公開された研究は、重複するマークアップの視覚化の問題、具体的には [〜#〜] lmnl [〜#〜] に対処しています。これには、NestViewの提案とかなり類似しているSVGグラフィックが含まれるため、ここで認められています。
Wendell Piezのグラフィックスはネストされたネストを表すように設計されているのに対し、NestViewはネストされたXMLまたはコードのみを対象としているのに対し、視覚的な違いは画像(下)で明確です。
上記のグラフィックは複製されました-親切な許可を得て-からhttp://www.piez.org
出典:
ここで自分の質問に答えようとしましたが、これには@jimpのヒートマップのアイデアと、@ Andreaの「XMLっぽくする」というアイデアが組み込まれています。
うまくいけば、angularラインとともにヒートマップの色が開始タグと終了タグの間に目を引くのに役立ちます。水平線の区切りを削除すると、開始から終了までの「フロー」が改善されます。ユーザーは、要素を使用して、ヒートマップの一致する部分を何らかの方法で強調表示できます。
編集これを使用することを決定しました。おそらく、色のユーザーオプションが必要になります。 「生産準備完了」のスクリーンショット:
そして比較のために...別のインデントされたビュー:
編集さて、より入れ子になった場合-描画スキルをテストしています...
1つのアイデアは、テキストに3Dを追加してみることです。フォントレベルのレベルに基づいて、フォントサイズを増減します。
たとえば、次のコード:
このようになります:
さまざまなレベルで固定されたテキストサイズの配置が失われるため、作業が面倒な場合があります。別のアイデア;各レベルの彩度を変更します。
それは本当に深いものにどれだけ耐えますか?わからない...
私は実際にあなたのガター視覚化のアイデアがとても好きです。簡単にグループ化できます。これらのアイデアのいずれかと組み合わせると、さらに見栄えがよくなるか、はるかに質素になります。 ;)
少し前に、Cでスコープを示すヒートマップを作成しました。ブレーンストーミングを見るのは楽しいかもしれません。
左揃え:
元のアイデアを調整して、正方形からカプセルに切り替えるだけです。これらのバージョン(元のバージョンを含む)は、表示要素をネストすることでネストを示すバージョンよりも複雑さが少ないため、読みやすいと思います。ツリーの要素は、よりシンプルで直感的な方法で情報を伝達すると思います。
左はインデントを直接表示するのに最適ですが、右は入れ子の関係を伝えるのに適しています。
私の考え:
ネストはネストのように見えます。各レイヤーの横幅はそれほど広い必要はありません。
アイデアが大好きです。 「ビジー」を抑えるための私の提案は、正方形の代わりにグラデーションを使用することです。それは行を削減します。多分極端なインデントのために異なる色。
あなたが持っているものはすべて素晴らしいと思いますが、私の好みでは少しブロック状です。
私のコメント:Visual Studio IDEがインデントを行う方法に常に苦労しています。このようなものやバリエーションを使用したいと思います。
そのため、リンクなしで、現在のxml /コードでインライン化されているリンクを想像してください。
ビジュアライゼーションは編集できない(左?)マージンに存在する必要があるとおっしゃっていたので、ビジュアライゼーションが混在したり、コードの背後にあることはできないと考えています。
おそらく左側の列のヒートマップで、明るい色はより深いインデントを示していますか?マージンを固定サイズにし、DOMの深さによって決定される最大インデントに従って指定されたすべてのスペースを動的に使用する(インデントと同じように左から右に移動することを期待する)視覚化を使用します。
あなたがエディター領域に進んで進んで進んでいくのであれば、私は非常によく似たものを提案しますが、それは文書の背景としてです。影付きの領域は、インデントが有効になっている場合、空白あるはずの場所になります。この場合、テキストの強調表示と対照的な、単色の明るい色を使用します。
悪い考えではありませんが、私のブロックを明確に表示するために左マージンを参照する必要があると、少し迷惑になるかもしれません。それは、画面の不動産や、構造が非常に深くなるとどのように見えるようになるかについてさえ考えていません。
動機は、ユーザーがインデントに使用している空白文字を「表示」するのを助けることなので、空白文字を表示するだけで済みます。
私は段落マーカーのような特別な視覚的文字ではなく、ハイライトだけを話している。スペースは黄色、タブは緑(またはその他)
マージン/入れ子の問題については、各ブロックのマージンを移動するだけです。マージンが直線である必要はありません。
これは新しい考えではないと思います。
このようなもの:
jGRASPは、マージンに視覚マーカーを使用してこれを行います。
ループを使用していることも認識し、その内側のループを表すために別のタイプの線を使用します。
既存の編集者がそれをどのように行うかを指摘したいと思いました。
Vimは、かなりよくはありませんが、すでに同じようなことを行うことができます。
Vimで「コードの折りたたみ」を行う方法はさまざまです。それらの1つは、構文の折りたたみルールに基づいています。これが完了すると、ネストされたアウトライン構造を使用してコードを折りたたむことができ、「FoldColumn」を使用して、「foldlevel」のグラフィカルな(実際には「|」と「-」文字を含む「文字ベース」)表現を提供できます。 。
Foldcolumnは、foldmethodに関係なくネスト表現を提供できますが、構文ベースの方法は、おそらく目的に適した方法です。どこかでxmlの構文ベースの折りたたみルールが事前に作成されているかどうかはわかりませんが、あると思います。
括弧を開いて閉じないのはなぜですか?
私が言及していないことの1つは、落ち着いたと思われる彩度効果に加えて、色相で何ができるかです。私の提案は、ポインタが置かれている巣の色を変更することです。これにより、ユーザーは、途中の兄弟と比較して、どの行がネストの一部であるかを簡単に識別できるようになります。
色相ベースのものを実装するときは、色覚異常を意識し、普遍的に区別できる色を選択するか、人々が選択できるいくつかのオプションを提供してください。
オプションBとCで正しい方向に進んでいると思います。幅とヒートマップのカラーリングの両方を含めます。邪魔にならないので、現時点ではオプションBがCよりも好きです(Cの真ん中の非常に重いブロックではなく、幅が広く希釈されているか、狭くて強烈です)。1つの欠点は、そのオプションではレベルをどこかに挿入した場合は、グラフ全体を再構築します。私はあなたがブロックをはるかに小さくすることができると思います、1または2 pxはおそらく十分でしょう。それは多くである必要はありません、それは区別可能である必要があるだけです。特に人々がエディタを何度も使用することが予想される場合、邪魔にならないため、邪魔にならない、より微妙な効果は扱いやすくなります。
ある種のエディターを使用する際に重要なことの1つは、現在のスコープを強調表示することです。エディターで行を選択するときは、そこに含まれる要素と、停止する場所を正確に確認する必要があります。ツリーを上に強調表示することもできます(どの要素がその子であるか)。これは別の問題であり、対処して考える必要があり、ユーザーがエディターでの経験をどのように評価するかにより影響を与えると思います。
おそらく、(元の投稿からの)ヒートマップの折りたたまれたビューに、1列の色と深さの数値しか含まれていない可能性があります。これにより、彼らは自分たちがどれだけ深いかを知ることができ、xmlのためのより多くの画面領域を彼らに与えます。私にとっては勝利のようです。
色の違いが深く入れ子になるのに十分なのか心配です。
これまでの他の提案と組み合わせて使用できる1つのオプションは、XPath表記を使用してラインへのパスを示す左マージンのツールチップを使用することです。ブラウザの「要素検査」ツール(Firebug、Chromeに組み込まれているツールなど)は、ステータスバーで同様のことをすることがよくあります。