mcpField
S
ShareX Architecture and Porting

ShareX Architecture and Porting

github.com/sharex開発34258 回インストール今日更新
リポジトリ

ShareX Architecture and Porting について

XerahS のアーキテクチャと移植ルールを記した開発スキルです。プラットフォーム抽象化の境界と Avalonia の構成案を示し、共有レイヤーに Windows 固有依存を持ち込まず ShareX のバックエンドを移植する際に役立ちます。

主な機能

  1. 01プラットフォーム抽象化の要件
  2. 02ShareX コードの移植ルール
  3. 03Avalonia のプロジェクト構成案
  4. 04過去の状態との比較手順

活用シーン

  1. 01ネイティブコードと共有ロジックの分離
  2. 02UI 作業前のバックエンド構成計画
  3. 03実装と指定コミットの比較

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/sharex/xerahs --skill sharex-architecture-and-porting

インストール後、Claude Code で/sharex-architecture-and-portingを入力して読み込まれたか確認します。

詳細

プラットフォーム抽象化とネイティブコードのルール

プラットフォーム固有の機能はすべて、プラットフォーム抽象化インターフェイスの背後に分離する必要があります。

XerahS.Platform.* プロジェクト以外のコードから、以下を参照することは禁止されています。

  • NativeMethods
  • NativeConstants、NativeEnums、NativeStructs
  • Win32 の P/Invoke
  • System.Windows.Forms
  • Windows 固有のハンドルやメッセージ

Common、Core、Uploaders、Media、その他のバックエンドプロジェクトで Windows API を直接呼び出すことは禁止されています。

必須アーキテクチャ

XerahS.Platform.Abstractions でプラットフォームに依存しないインターフェイスを定義します。

XerahS.Platform.Windows で Windows の機能を実装します。

将来のプラットフォーム向けに、スタブ実装を作成します。

  • XerahS.Platform.Linux
  • XerahS.Platform.MacOS
Windows 専用機能

機能が Windows 専用の場合：

  • 抽象化インターフェイスを介して定義する必要があります。
  • Windows では具体的な実装を提供します。
  • その他のプラットフォームでは、次のいずれかを行うスタブ実装を提供します。
    • PlatformNotSupportedException をスローする。
    • または、警告をログに記録したうえで安全な no-op を返す。

UI とワークフローでは、機能が利用可能かどうかを検出し、サポートされていない機能を無効化するか、非表示にする必要があります。

既存の ShareX コードを移植する際のルール

次の参照が一切含まれていない場合に限り、ファイルをそのまま移植できます。

  • NativeMethods または関連するネイティブヘルパー
  • WinForms の型
  • Windows 固有の相互運用機能

ファイルにロジックとネイティブ呼び出しが混在している場合：

  • 純粋なロジックを Common または Core に抽出します。
  • ネイティブコードを XerahS.Platform.Windows に移動します。
  • 呼び出し箇所をインターフェイス呼び出しに置き換えます。

ネイティブメソッド名とシグネチャは Windows 固有のままにし、共有レイヤーに漏れないようにする必要があります。

適用

ShareX.HelpersLib を移植する際、次を参照するファイルは：

  • NativeMethods.cs
  • NativeMethods_Helpers.cs
  • NativeMessagingHost.cs
  • DWM、フック、クリップボード、または入力 API

プラットフォームコードとして扱い、ファイル全体をそのままコピーすることはできません。

主な目標と移植ルール

  • 主な目標：まず ShareX のバックエンドを移植して XerahS を構築し、その後 Avalonia の UI を設計します。
  • C:\Users\liveu\source\repos\ShareX Team\ShareX を調査して既存の非 UI ロジックを理解し、Avalonia のソリューションとプロジェクトの下書きができた後、このリポジトリにコピーして再利用します。
  • WinForms や WinForms の UI コードは再利用しないでください。非 UI のメソッドとデータモデルのみコピーします。
  • UI 設計フェーズが明示的に開始されるまで、バックエンドの移植を優先します。

Avalonia ソリューションの提案（ShareX の分析に基づく）

  • 最もシンプルなバックエンドライブラリから始め、次に複雑なモジュールへ進みます。
  • 推奨される構成：
    • XerahS.Common：共有ヘルパー、シリアル化、ユーティリティ。
    • XerahS.Core：タスク設定、ワークフロー、アプリケーションレベルのサービス。
    • XerahS.Uploaders：アップローダー、設定、OAuth、HTTP ヘルパー。
    • XerahS.History：履歴モデルと永続化。
    • XerahS.Indexer：ファイルのインデックス作成と検索。
    • XerahS.ImageEffects：フィルター／エフェクトのパイプライン。
    • XerahS.Media：エンコード、サムネイル、FFmpeg との統合。
    • XerahS.ScreenCapture：キャプチャエンジンとプラットフォーム抽象化。
    • XerahS.Platform.*：OS 固有の実装（まず Windows、その他は後から）。
    • XerahS.App と XerahS.UI：Avalonia UI とビューモデル（バックエンドの準備ができるまで保留）。

履歴比較と同等性

特定の過去のコミットとの機能の同等性を確保するよう求められた場合や、「コミット X と同一にする」よう求められた場合は、次の手順に従ってください。

  1. git コマンドを繰り返し実行しない：セッション中に、ファイルの内容を確認するために git の履歴を繰り返し照会するのは避けてください。
  2. ref ディレクトリを作成する：一時フォルダー（例：src/XerahS/ref）を作成します。
  3. 参照ファイルをダウンロードする：git show <commit_hash>:<file_path> > src/XerahS/ref/<commit_short>_<filename> を使い、そのコミット時点の関連ファイルの状態を確認します。
  4. ローカルで比較する：現在のローカルファイルとダウンロードした参照ファイルの差分を取り、分析します。
  5. クリーンアップする：特に指示がない限り、タスクが完了し、検証できたら ref ディレクトリを削除します。

これにより、git コマンドの実行回数を抑え、同等性を確認するための安定した参照点を確保できます。

コメント

Markdown 対応