PVS-Studioインターフェースの更新中に発生した問題

最近リリースされたPVS-Studio 6.10の新しいバージョンでは、Visual Studioプラグインのグラフィカルユーザーインターフェイスとスタンドアロンバージョンが大幅に更新されました。 インターフェースの以前のバージョンは、絶え間ない進化（新しいボタンとメニュー項目が追加および非表示）にもかかわらず、大幅な変更なしでほぼ​​6年間続き、2010年にPVS-Studioバージョン4.0で初めて登場しました。



この記事では、インターフェイスを変更する必要性について考えさせられた理由と、その作業の過程で発生した問題について説明します。

古いPVS-Studioインターフェースの問題と、それを変更することにした理由

まず、少し歴史。 Visual Studioプラグインには、アナライザーの4番目のバージョンから別のPVS-Studioウィンドウが表示されました。 以前のバージョンでは、標準のエラーリストウィンドウを使用して診断メッセージを表示していましたが、このウィンドウの機能はすぐに要件を超えました。 独自のフィルター、コンテキストメニュー、ボタンなどを追加できないことに加えて、PVS-Studioメッセージ用に独自のウィンドウを実装するように促した主な理由は、エラーリストのパフォーマンスでした。 その中に少なくとも数千のメッセージを記録すると、それを扱うことが不可能になりました-スクロールしようとしてもスタジオがフリーズしました。



もちろん、何千ものメッセージを生成するアナライザーは悪いアナライザーです。 ただし、最初の診断はC ++プログラムを64ビットプラットフォームに移植する際のエラーであり、その性質上、特に実際の大規模プロジェクトではこのようなエラーが非常に多くなる可能性があることに留意してください。 ひそかに、私たちの「アンチレコード」は〜250,000メッセージのレポートだったと言えます！ ユーザーをすぐに安心させたい-PVS-Studioの最新バージョンは通常これを許可しません。特に現在、エラーの「重要度レベル」や失敗した操作（方法論の枠組み内で不可避的に発生する）を簡単に抑制または無効にするさまざまな方法などの概念があります静的解析）。 ただし、2010年には、これらすべてがまだ存在していなかったため、インターフェイスの「ブレーキ」はこれまで以上に関連性がありました。



別のウィンドウを備えたプラグインの最初のバージョンは、Visual Studioバージョン2005および2008をサポートしていました。最新のVisual Studioも停止せず、標準のエラーリストに多数のメッセージを表示する問題はすでに起こり、あまり関連していません。しかし、別の「出力ウィンドウ」の利点は依然として明らかです。 ここでは、組み込みのVisual Studio C ++アナライザーとの類似点を描くのは面白いです-一定の期間（バージョン2010-2012のようですが、間違っている可能性があります）、このアナライザーは独自の個別の出力ウィンドウを使用して作業結果を表示しました。 ただし、最近のバージョンでは、Visual Studioは標準のエラーリストウィンドウに結果を表示するようになりました。 私たちの意見では、Visual Studioの開発者がこれを行った理由については、新しいウィンドウについて説明する時期をお知らせします。



前述したように、PVS-Studioウィンドウの最初のバージョンは、Visual Studioの2005および2008バージョン用に作成されました。 したがって、ウィンドウの初期設計を開発するときは、これらのバージョンのIDEからの標準エラーリストの設計に焦点を当てました。 これは、基本的に当時採用したアイコンのスタイルを説明しています。 Visual Studioの最新バージョンでは、ウィンドウがすべての新しいカラーテーマをサポートしていましたが、その中のアイコンは当時のままでした。 これは、「再スタイル」する前のインターフェイスの主要コンポーネントの外観です。

図1-Visual Studio 2015の古いPVS-Studioインターフェイス（出力ウィンドウとメインメニュー）



純粋に「審美的な」ことに加えて、私たちのインターフェースの問題は何ですか？ おそらく私たちの主な問題、またはむしろ、ユーザーに不便をもたらす問題は、インターフェースの直観性です。 コンテキストメニューで誤検知をマークしたり、メッセージをその重要度に応じて区別したりするような一見基本的な機能でさえ、多くの場合、ユーザーには明らかではなく、質問が寄せられました。 ユーザーがレベル3のメッセージを最も「危険」であると考えることは珍しくありません。 もう1つの問題は、一般的な「かさ高さ」です。ラベルが多すぎる、省略形やボタンがわかりにくい、何かを見つけるのが困難です。



新しいインターフェースでは、これらの問題を解決しようとしましたが、どれだけのことを行ったのかをさらに調べることができます。

新しいメインウィンドウのデザイン

コードを書き始める前に、新しいインターフェイスのコンセプトを作成するタスクを持つプロのデザイナーに頼りました。 前述したように、ウィンドウには標準のエラーリストの概念が繰り返されていたため、その中心部分は古典的なグリッド、つまり列と行のあるテーブルでした。 私たちは、「古典的な」公式を実験し、放棄しようとしたので、さらにミニマリズムが流行しているため、Visual Studio自体はインターフェイスのこれらの傾向に左右されます。 新しい「インスピレーション」として、組み込みのC ++アナライザーの結果の通知ウィンドウと出力ウィンドウであるVisual Studioの要素を使用して再試行することにしました。

図2-組み込みの静的分析ウィンドウ（Visual Studio 2012）および通知ウィンドウ（Visual Studio 2013）



写真からわかるように、両方のウィンドウは可能な限り最小限に抑えられています。メッセージテキストと識別子（コードまたはカラーマーカー）のみが含まれています。 左側のウィンドウには、検索/フィルタリング用のフィールドもあります。 また、エラーリストとは異なり、両方のウィンドウは水平方向ではなく垂直方向に配置されています。



そして、ここで私はすでに上で述べたものに戻りたいと思います-2015年のスタジオで、Microsoft開発者は何らかの理由で静的解析のための「ファッショナブルな」新しい垂直ウィンドウを放棄し（左の写真）、「古き良き」エラーリストを支持しました。 なぜそうしたのですか？ 私の意見では、この新しいウィンドウを独自に使用した経験から-このウィンドウは使用するのが不便だったからです。 垂直の表では、画面に表示されるメッセージはほとんどなく、基準（たとえば、コードまたはファイル）で並べ替えることはできませんでした。メッセージのあるカードが「開かれた」場合、画面全体を占有することがありました。



さまざまな設計オプションで「遊び」ましたが、ようやく同じ結論に達しました-アナライザーメッセージ（たとえば、コンパイラーの警告など）は、古典的な水平の「グリッド」で表示および分析する方が便利です。 はい、通知インターフェース（図の右側）は、注意が必要な2つまたは3つのメッセージを表示する必要がある場合に便利ですが、ユーザーが数十（場合によっては数百または数千）のメッセージを処理する必要がある場合は、表の利点が明らかになります。 もちろん、初期設定の後、開発者は通常、新しいコードでいくつかのメッセージを同時に処理する必要があります。もちろん、静的アナライザーが正しく使用されている場合、つまり 定期的に。 ただし、初期セットアップ段階も同様に重要であり、多くの場合、アナライザのさらなる使用の成功は、その実装の正確さに依存します。 それでも、通知ウィンドウでは、メッセージの「重要性」を視覚的に区別するという興味深いアイデアが得られました-カラーバーの助けを借りて。



一般的な方向性を決定した後、インターフェイスの技術的基盤を選択する必要がありました。 以前のバージョンのインターフェイスでは、「古き良き」Windowsフォームを使用していました。これは、Visual Studio 2005および2008をサポートする必要があるためです。VisualStudioプラグインはC＃で開発されていることを考えると、Visual Studioはクロスプラットフォームではなく、おそらくそれ自体が主な理由ですVisual StudioはWPFテクノロジを使用しています。更新されたインターフェイスに同じWPFを使用するのが最も理にかなっているようです。 それにもかかわらず、プラグインの内部ロジック全体とそれによって使用されるデータ構造がインターフェースに直接「結び付け」られていない場合でも、現在のバージョンでは「化粧品の修復」を最初に実行することを決定しました。 更新されたデザインに従って現在のインターフェイスを単に「再描画」し、基礎となるすべてのコンポーネントを変更せずに残します。 残念ながら、現実の世界はその条件を決定し、時にはあなたがしたいこととあなたがする必要があることを優先しなければなりません。 さらに、このような化粧品の修理は、非常に少ない労力で短時間で行うことができます。



WinFormsの基本機能がすでに見逃され始めていることを認めなければなりません-そのような一見小さな「化粧品」の修正でさえ、コードにいくつかの「クランチ」の実装が必要でした-ユーザーには目立たないが、インターフェースのさらなるサポートと開発をすでに複雑にします。 たとえば、ツールストリップパネルに表示されるときに、新しいレベルボタン（カラーバー）を「いじる」必要がありました。 WinForms自体の標準ツールストリップは、その要素のレンダリングを担当しますが、ユーザーコントロールをホストする場合、このコントロールのレンダリングをその上にシフトする必要があります（これは、カラースキームをサポートする上で特に重要でした）。 また、WinFormsを使用すると、かなり古風なVS SDK GetVSSysColorExインターフェイスを使用してカラースキームをサポートし、コンポーネントを個別に「色付け」し、カラーテーマを切り替える瞬間をキャッチする必要があります。 WPFコンポーネントの場合、Visual Studioは、XAMLマークアップで直接、動的リソースを通じて色を選択するためのより便利なメカニズムを提供します。



その結果、PVS-Studioインターフェイスの次の（現在の更新後の）バージョンは完全にWPFに基づいていると自信を持って言えます。 さて、私たちの目標は、以前のインターフェイスのイテレーションと同様に、標準のVisual Studioウィンドウとの関連で「信頼性」を維持することでした。 結果は次のとおりです。

図3-更新されたPVS-Studioインターフェイス（出力ウィンドウとメインメニュー）

メニュー項目、アイコン、熊手

古いPVS-Studioプラグインアイコンは、理想とはほど遠い、またはVisual Studioの標準の「テーマ」とはほど遠いため、それらを置き換えることが決定されました。 新しいアイコンの主な要件は、単一のスタイルへの適合性とすべてのVisual Studioカラースキームに対する優れたコントラストでした。



一連のアイコンを決定し、開発を開始しました。 最初に遭遇した問題は、奇妙なことに、Visual Studioのメインメニューにアイコンを直接表示することでした。 「待って、PVS-Studioの最初のバージョンから始めて、このメニューにすでにアイコンを表示しています！」と言います。 実際、これはそうですが、以前に使用した方法は私たちの目的には適していませんでした。 アイコンを設定するために、単一のVisual Studio拡張メカニズムを使用してメニュー項目（vsctファイル）を作成したことを明確にします（詳細については、 こちらをご覧ください ）。 このオプションで私たちに合わなかったのは何ですか？ まず第一に、アイコンは一度だけ設定できます-プラグインがスタジオによってロードされたとき。 標準のスタジオアイコンの動作をシミュレートしたかったのです。 選択したカラースキームに応じてそれらを再描画します（後で判明したように、この要件は冗長でした-スタジオはそれ自体を行う方法を知っています）。 第二に、vsctファイルは、どのようにアイコンの画像でアルファチャネルを使用するかを知らないため、見た目が非常に悪くなります。



質問が発生しました：メニュー項目アイコンの画像をプログラムで設定するにはどうすればよいですか？これを行うことも可能ですか？ 長い検索の後、私はこれをうまく行うことができるサードパーティのVisual Studio拡張機能を見つけることができました。 そのソースコードの調査により、上記の質問に対する答えを見つけることができました。 すべてが非常にシンプルであることが判明しました。

var commandBars = (CommandBars)DTE.CommandBars; var menuBar = commandBars[menuBarKey]; var pvsBar = menuBar.Controls["PVS-Studio"] as CommandBarPopup; ... cmdBtnControl.Picture = ImageHelper.BitmapToStdPicture(bmp);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、ユーザーが必要な場合（およびその理由は？）、PVS-Studioのメニュー項目の名前を変更したい場合、そのような方法は「壊れる」という懸念がありました。 しかし、これらの恐怖は無駄でした-commandBarオブジェクトの内部名は変わりません。



アイコンの動的表示の問題を解決した後、アクティブなVisual Studioテーマから選択された色でモノクロアイコンを塗りつぶすアルゴリズムを実装しました。 プラグインリソースのすべてのアイコンを白に反転し、画像の各ピクセルの色に必要な色を掛ける簡単な変換アルゴリズムを作成しました。

 public static void Colorize(ref Bitmap img, Color color) { for (int x = 0; x < img.Width; x++) { for (int y = 0; y < img.Height; y++) { //       //            var pixel = img.GetPixel(x, y); var r = (byte)(((float)pixel.R) * ((float)color.R / 255f)); var g = (byte)(((float)pixel.G) * ((float)color.G / 255f)); var b = (byte)(((float)pixel.B) * ((float)color.B / 255f)); img.SetPixel(x, y, Color.FromArgb(pixel.A, r, g, b)); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

出力では、次の結果が得られました。

図4-アイコンの色付けアルゴリズムの操作の例。



しかし、予期しない動作が見つかりました-たとえば、Visual Studioデザインの「赤」テーマが選択された場合、アイコンは正しく表示されました。 正しく、「ライト」スキームで表示されていました。 「暗い」スキームでは、アイコンは黒のままで、予想どおり白になりませんでした。 スタジオ自体が、選択された配色の背景の「明るさ」に応じて画像の特定の色を反転できることが判明しました-アイコンの色付けの以前の実験は無駄であることが判明しました。 スタジオはすべてを行ってくれました。 それにもかかわらず、アルファチャネルの問題のため、上記のアイコンをプログラムで設定する方法を残すことにしました。



同様に、PVS-Studioのメッセージ出力ウィンドウで、すべてのアイコンとアイコンを同じセットから適切なものに変更しました。 ただし、Visual Studioの配色に応じてメニューのアイコンの色が自動的に変更された場合、プラグインウィンドウのアイコンはすべての配色に対して元の形式のままになります。

図5-Visual Studioの暗い配色でアイコンを表示する際の問題。



Visual Studio SDKを使用して、アイコンにスタジオカラー化アルゴリズムを適用できるかどうか疑問に思いました。 結果は私たちを長く待たせませんでした。 数分検索した後、 Microsoft.VisualStudio.PlatformUI名前空間のImageThemingUtilitiesクラスのGetThemedBitmapメソッドに出会いました。 彼は私たちが必要なことを正確にやった！

図6-暗いVisual Studioテーマのウィンドウでのアイコンの正しい表示。



アイコンを変更するときに発生した別の問題は、100％以外のDPIでのぼかしでした。 これは、すべてのアイコンのサイズが16x16ピクセルだったために発生しました。 最初は64x64アイコンを使用して、この問題を部分的に無効にしました。 この場合、VisualStudioはそれらを自動的に目的のサイズに圧縮しました。 しかし、この実施形態では、すべてが非常に滑らかではないことが判明した。 現在、DPIが100％の場合、わずかにぼやけています。 その結果、100％以外のDPIでは最も許容できる結果が得られ、100％DPIではぼかしが実質的に目立たなかったため、正確に64x64の画像を使用することが決定されました。



また、DPIが115％の場合、アイコンの右端が数ピクセル分切れていることがわかりました。 プログラムで数ピクセルを右に追加しようとした（画像のサイズが64x68になるように）試みも失敗しました。 Visual Studioのアイコンは圧縮されて正方形のアスペクト比に戻され、トリミングは勝ちましたが、ブラーは時々増加しました。 最終的に、各アイコンにいくつかの空白ピクセルを追加し、サイズを64x64のままにしました。 このソリューションは、最小限のぼかし（ほとんど目に見えない）を提供し、アイコンの右側の割礼を除外しました。

おわりに

一見重要な外部の変更にもかかわらず、PVS-Studioの「内部」インターフェースは実際には同じままでした。 古いユーザーにとっては新しいインターフェイスが「なじみやすい」ままであり、新しいユーザーにとってはより直感的で楽しいものになることを願っています。 そしてもちろん、それはすべてのユーザーの目には「きれい」になります。 私たちが何とかしたかどうかはあなたの判断次第です。





この記事を英語圏の聴衆と共有したい場合は、翻訳へのリンクを使用してください：Ivan Kishchenko、Paul Eremeev。 PVS-Studioユーザーインターフェイスを更新するときに直面した問題 。