1 ポイント 投稿者 GN⁺ 2025-03-17 | 1件のコメント | WhatsAppで共有
  • 2006年夏、個人用マンガリーダー Fiew を作った経験が出発点となり、C++とWindows APIでPhotoshopに似た画像エディター Fedit を卒業論文プロジェクトとして実装した
  • Feditはインストーラー、圧縮ファイル、レジストリキー、追加ランタイムなしで 単一の実行ファイル として動作し、権限が制限されたPCやUSBドライブ上でもすぐに実行できた
  • インターフェースは クラシックPhotoshop のワークフローに似せて設計され、フローティングツールウィンドウ、カラーピッカー、レイヤー管理、取り消し履歴、画像フィルター、ユーザー定義のピクセル移動フィルターを備えていた
  • 最大の難関は ユーザーインターフェースの再現 で、ツール設定パネルのスナップ/アンスナップ動作や、色・ツール選択機能の実装に多くの時間を費やした
  • プロジェクトは論文の成功と工学学士号の取得につながり、その後GoldenLineのCTOに印象を残して、大量画像アップロード用WinAPIアプリを作る C++の仕事 につながった

マンガリーダーFiewから画像エディターFeditへ

  • 2006年初夏、既存の画像リーダーアプリに満足できなかったことが出発点だった
    • 特に、マウスだけで読書操作を制御できず、キーボードに何度も手を伸ばさなければならない点が邪魔だった
  • 大学で C++/Windows API のコースを終えた直後で、夏休みの間に個人的に理想のマンガリーダーを開発した
  • このマンガリーダーは Fiew という名前だった
  • 2006年初秋に卒業論文のテーマを決める必要があり、画像ビューアー開発が順調だった経験から、画像エディターも作れると判断した
  • 当時Adobe Photoshopをよく使っていたため、目標はPhotoshopに似たエディターになった

Feditの実装方法と配布上の制約

  • FeditはC++で書かれた Advanced Image Editor で、Windows APIとGDI+グラフィックライブラリを使用した
  • ユーザーにとって有利な配布形態にするため、5つのルールに従った
    • インストーラーなし
    • 圧縮ファイルなし
    • レジストリキーなし
    • 追加ランタイムなし
    • 単一の実行ファイル
  • その結果、インストール不要ですぐに動作し、権限が制限されたシステムやUSBドライブ上でも実行でき、リソース消費の少ないプログラムになった

Photoshopに近いインターフェースと機能

  • インターフェースは クラシックPhotoshop のように見えるよう慎重に作り、よく使っていた機能を含めた
  • 主な機能は次のとおり
    • 自由に浮かせられるツールウィンドウ
    • カラーピッカー
    • 簡単なレイヤー管理
    • 段階的に取り消せる履歴
    • 複数の画像フィルター
    • ピクセル移動フィルターを直接エンコードできる 行列インターフェース
  • 以前のプロジェクトFiewから取り込んだ大規模画像ライブラリビューアーも含まれていた
    • 大量の写真をすばやく簡単にスクロールできた

自力でデバッグする必要があった開発過程

  • MSDNとExperts Exchangeを多く参考にしたが、問題があまりに具体的だったため、ほとんどは自分で分析してデバッグする必要があった
  • 学士論文の締め切りに間に合わせるため、最後の2か月は1日 14時間 ずつ作業した
  • 最も厄介だった領域はユーザーインターフェースだった
    • Photoshopにできるだけ近いワークフローを望んでいた
    • ツール設定パネルを自由にスナップ/アンスナップする動作が特に難しかった
    • カラーピッカーとツール選択機能を再現する作業も簡単ではなかった
  • プロジェクトを終える頃にはかなり疲弊し、WinAPIへの苦手意識も生まれた

論文後の結果と公開資料

  • 論文は成功し、Warsaw University of Technologyで Bachelor of Science in Engineering の学位を取得した
  • Feditはオンラインでいくつか好意的なレビューを受けたが、積極的に宣伝はしなかった
  • その後、FiewとFeditがGoldenLineのCTOに印象を与え、Flickrクローン向けに大量画像アップロード用の高効率WinAPIアプリを作るC++業務につながった
  • 公開資料

1件のコメント

 
GN⁺ 2025-03-17
Hacker Newsのコメント
  • 「ユーザーの利益になる5つのルール:インストーラーなし、圧縮ファイルなし、レジストリキーなし、追加ランタイムなし、単一の実行ファイル」という一文を読んで、温かく幸せな気持ちになった。
    レジストリがなぜ存在するのか、現在のWindowsソフトウェア・エコシステムがなぜこのように回っているのかは理解しているが、昔のように大半のデスクトップソフトウェアが単純だった時代が本当に懐かしい。
    最近は可能ならポータブル版を使っているし、こういう方式がもっと一般的になってほしい。設定を完全に復元できるか分からない時間・手間・不確実性のせいで、Windowsの再インストールを積極的に避けるようになる。

    • インストーラーにも有用なことは多く、エンドユーザーのかなりの割合は実際にそれを望んでいる。たとえば、スタートメニューにショートカットを追加して見つけたり検索したりできるようにする、ファイル形式を関連付ける、Windowsのプログラム一覧に登録する、といったことだ。
      以前はポータブルソフトウェアが大好きだったが、最近は両方提供されているなら、むしろインストーラーのほうを好む。そうでないと、検索できるようにするために自分でスタートメニューへ追加しなければならないからだ。
      ただしレジストリキーは嫌いだ。OSを再インストールすると、よく消えてしまうからだ。設定は単に**%appdata%** に保存してほしい。
    • だからGoが好きだ。単一の実行ファイルなので、他の人がツールを使いやすくなる。
      代替案として、NSISで単一の実行ファイルにパッケージ化し、実行前に一時ディレクトリへすべて展開する方式も使っている。
      Windowsレジストリは一貫性がなく、設計の悪い寄せ集めに近いと思う。比較すると、Gnomeのレジストリはよく設計されている。キーの説明、制限付きの値の選択肢、デフォルト値の表示といったものは、優れたユーザーインターフェース設計だ。
      Windowsのグループポリシーとレジストリのマッピングを見るだけでも、同じ論理構造がバラバラで、キーに二重否定まで混ざっている。
    • レジストリの本来の目的は、COMがGUIDを見てDLLファイルの場所を見つけられるようにすることだった。そうすればCOMがオブジェクトインスタンスを作成できた。
      今でもHKEY_CLASSES_ROOTにその痕跡を見ることができる。
      技術的には、レジストリなしでもオブジェクトは作れる。DLLをロードしたあと、エクスポートされた関数を呼び出してFactoryオブジェクトを作り、そのFactoryオブジェクトでインスタンスを作ればよい。COM自体がやっているのもその方式だ。
    • そういうシンプルで軽量な設計は、私にも響いた。
      記事も本当に素晴らしい回想だった。ただ、序盤で筆者が少し示唆していた苦労について、もっと深く扱っていればよかったと思う。とはいえ些細なあら探しにすぎず、記事はとてもよく、実際かなり印象的な取り組みに見える。
    • ライブラリを静的コンパイルで含めずに単一バイナリアプリを作る最善の道が何なのかはよく分からない。ライセンスのせいで、たいていは対応が難しくなる。
  • Photoshopには本当に多くの機能があるので、画像フィルターをいくつか作っただけでは再現とは言いにくい。

    • しかしユーザーインターフェースをきちんと合わせるのは非常に難しく、非常に重要だ。
      2006年のGIMPも機能はものすごく多かったが、Photoshopのインターフェースと比べると本当にひどかった。
    • それでも学部の制作物としては、とても、とても印象的だ。
    • ここでの「再現」を文字通りに受け取れという意味ではないと思う。
    • その通り。Photopeaが最も近いクローンの試みだと思うが、それでも多くの機能が欠けている。
    • 「基本的な画像エディターを作った」と言えば、当然それほど印象的には聞こえない。記事がこう始まっているのを見ると、驚きでもない。

      As I’m getting older I look back on all the things I’ve done as a creative developer, and I see so many cool projects!
      なんとも謙虚だね…

  • この素晴らしいプロジェクトへの直接リンクもあるべきだ。
    https://github.com/f055/fedit-image-editor

  • 「宣伝はしなかった。数カ月後にC++の仕事を得た。結局、そのすべての努力は報われたわけだ」という箇所が興味深い。
    私たちは本能的に、苦労してやった仕事は報われるべきだと分かっているが、オープンソース開発者が、特に本番環境で広く使われるコードに多大な労力を注いでも、実際の報酬をほとんど得られないことがあまりにも多いのは残念だ。
    だから評判という報酬を求めたり、NPMが「このライブラリの作者に寄付してみませんか」のような機能を入れたり、GitHubがPatreon連携を作ったりしたのだと思う。
    純粋だが誠実な若いクリエイターを利用しない、今より良いモデルが必要だ。

  • 2000年代初めにpixel32、後にはPixel Studio Proというプロジェクトがあった。本当に良さそうに見え、アーリーアクセスとして販売されていた。
    しかし結局ベイパーウェアになり、お金を払った人たちはひどく怒り、作った人はあっという間に英雄から悪役へと変わった。
    https://discuss.haiku-os.org/t/pixel-studio-pro-in-past-call...

  • 筆者はWarsaw University of Technologyを卒業したと言っていたが、ここではいつもかなり良い大学の一つと見なされていた。
    それとは別に、当時の学位論文が今とどれほど違っていたかも目につく。最近、別の大都市の工科大学で論文を書いたが、私たちの工学士論文の90%はかなり低水準で、自分のものも含まれている。

    • 今でも大きく違うのだろうか、と思う。私の知る限り、目的は分野を発展させることではなく、学士号や修士号を授与する側に対して、論文形式の成果物を作れることを証明する点にある。
      目立つ論文もあるだろうが、大半はおそらくかなり退屈なものだろう。
  • だからWindowsが好きだ。特定のニッチをうまく満たす、小さく公開ソースのソフトウェアがものすごく多い
    昔はsourceforge.netやfreshmeat、たしかそんな名前だったと思うが、そういう場所を見て回って探していた。

  • Phonegapで働いていた友人が、10年ほど前にAdobeに買収されたあと、遊びでさっそくPhotoshopをJavaScriptに移植した。

    • 反対票に文句を言うつもりではないが、Hacker Newsが嫌いそうな話に見えるのはかなり不思議だ。
      ソフトウェアエンジニアの社内ハックプロジェクトの話は面白いだろうと思ったのだが、まあ仕方ない。
  • 人々が作っておきながら、世の中に知らせないものがある。GitHubに上がっていてよかったし、本当に印象的だ。