4 ポイント 投稿者 GN⁺ 2024-05-26 | 1件のコメント | WhatsAppで共有
  • シンプルなクロスプラットフォームのReactive GUIツールキット
  • シンプルさ: プロジェクトに簡単に追加して、すぐにUIを構築できる。追加のツールやコード生成ステップは不要。Goコードを書けば、自己完結型バイナリとしてネイティブGUIアプリケーションを生成できる
  • クロスプラットフォーム: 可能な場合はネイティブウィジェットを使用し、コンパイル時に実行中のプラットフォームに最適なバックエンドを自動的に選択する。現在はFLTKベースとCocoaベースの2種類のバックエンド実装が提供されている
  • リアクティブ: アプリケーションの状態が変更されるとUIを自動的に更新する。副作用のないレンダリング関数を提供し、UseStateフックを使ってアプリケーション状態を管理する
  • 幅広いウィジェット対応: Spotはボタン、ラベル、テキスト入力、スライダー、ドロップダウンなど、さまざまなUIコントロールを標準で提供する

よくある質問(FAQs)

「リアクティブ」とは何を意味するのか?

  • Spotにおける_リアクティブ_とは、アプリケーションの状態が変更されたときにUIが自動的に更新されることを意味する。これは、状態変更時に不変のコンポーネントツリーを再構築し、以前の状態と比較してどのUIコントロールを更新すべきかを判断することで実現される。

Spotが使用する「ネイティブウィジェット」とは何か?

  • 現在Spotは、macOSではCocoaバックエンドを使用し、それ以外のすべてのプラットフォームではFLTKベースのバックエンドを使用する。オプションでMacでもFLTKを使用できる。今後はWindows向けのより良いサポートが計画されている。

独自のフックを実装できるか?

  • はい、Reactと同様に独自のフックを実装できる。*spot.RenderContextを最初の引数に受け取る関数を作成し、それを通じてSpotのライフサイクルに「フック」できる。

カスタムコンポーネントを作成する方法は?

  • SpotではUIをコンポーネントに分割する方法がいくつかある。主な方法は、spot.Componentインターフェースを実装する構造体を作ること。このインターフェースは、Render(ctx *spot.RenderContext) spot.Componentという単一のメソッドを持つ。

提供されているものとは別のウィジェットライブラリを使えるか?

  • はい、可能。spot.Componentインターフェースを実装し、ネイティブウィジェットを管理する構造体を作ればよい。

CocoaまたはFLTK以外のバックエンドを使えるか?

  • 現時点ではこの2つのバックエンドのみがサポートされている。ほかのバックエンドを追加したい場合は、PRを提出できる。

spot/uispotの違いは?

  • spotは、リアクティブモデルとレンダリング機能を提供する中核パッケージ。バックエンドに依存せず、spot.Controlインターフェースを実装する任意のコントロールセットと組み合わせて使用できる。
  • spot/uiは、spotと併用できる事前構築済みのクロスプラットフォームGUIコントロールセットを提供する。

「コンポーネント」と「コントロール」の違いは?

  • Spotにおいて_コンポーネント_は、ビジネスロジックと状態を含むアプリケーションの論理的単位である。すべてのコンポーネントは他のコンポーネントで構成され、最終的には1つ以上の「コントロール」としてレンダリングされる。
  • _コントロール_は、UIツリーにマウントされ、画面上の視覚要素を表す特殊な種類のコンポーネントである。

Spotにおける「make」「render」「build」「mount」「update」という用語の意味は?

  • Make: 新しいコンポーネントインスタンスを生成するプロセス。spot.Componentインターフェースを実装する構造体のインスタンスを参照するか、レンダリング関数としてspot.Makeを呼び出すことで行う。
  • Render: コンポーネントの状態をビルディングブロックに適用し、別のコンポーネントインスタンスを返すプロセス。コンポーネントインスタンスでRenderメソッドを呼び出すことで行う。
  • Build: コンポーネントインスタンスから新しいUIツリーを生成するプロセス。コンポーネントを再帰的にレンダリングしてコントロールツリーを生成する。
  • Mount: (仮想)コントロールツリーから実際のUIコントロールを生成するプロセス。ツリーノードでMountを呼び出すか、コンポーネントインスタンスまたはレンダリング関数としてspot.Mountを呼び出すことで行う。
  • Update: (マウント済みの)コントロールツリーを更新するプロセス。ツリーノードでUpdateを呼び出すことで行う。

現在Spotがサポートしていない機能

  • 自動レイアウト
  • マルチウィンドウ
  • モーダルダイアログ
  • サイズ変更可能なウィンドウ
  • メニューバー
  • カスタムウィジェット
  • ネイティブウィジェットへのアクセス
  • ドラッグ&ドロップ
  • 国際化

サポートされるUIコントロール一覧

  • Button: アクションを開始するシンプルなボタン (Fl_Button, NSButton)
  • Checkbox: 相互排他的な2つのオプションのうち1つを選択するコントロール (Fl_Check_Button, NSButton (NSButtonTypeSwitch))
  • ComboBox: テキスト入力が可能なドロップダウンメニュー (ComboBox, NSComboBox)
  • Dial: 円形の状態コントロール (Fl_Dial, NSProgressIndicator (with NSCircular style))
  • Dropdown: 複数の選択肢から1つを選ぶドロップダウンメニュー (Fl_Choice, NSComboBox)
  • Image: 画像コントロール (Image, NSImageView)
  • Label: シンプルで編集不可のテキストラベル (Fl_Box, NSTextField)
  • ListBox: スクロール可能なコントロールで、指定されたリストから1つまたは複数の項目を選択できる (Fl_Select_Browser/Fl_Multi_Browser, NSTableView)
  • ProgressBar: 長時間実行タスクの進行状況を可視化するプログレスバーコントロール (Fl_Progress, NSProgressIndicator)
  • Slider: 水平スライダー入力コントロール (Fl_Slider, NSSlider)
  • Spinner: 上下ボタン付きの数値入力コントロール (Fl_Spinner, NSTextField+NSStepper)
  • TextField: 単一行テキスト入力コントロール (Fl_Input, NSTextField)
  • TextView/TextEditor: 複数行のテキスト内容を表示・編集できる汎用テキストボックス (Text, NSTextView)
  • Window: 画面上の(最上位)ウィンドウを表すコントロール (Fl_Window, NSWindow)

GN⁺の見解

  • SpotはGo言語でクロスプラットフォームGUIアプリケーションを容易に開発できるようにする。特にリアクティブモデルを導入することで、開発者がUI更新を気にせずアプリケーションロジックに集中できるようにしている。
  • 現時点では未対応の機能が多く、複雑なアプリケーションを開発する際には制約がある可能性がある。特に自動レイアウトやマルチウィンドウのような機能が必要なら、別のツールキットを検討すべきだ。
  • Spotのシンプルさとクロスプラットフォーム対応は、小規模プロジェクトやプロトタイプ開発に非常に有用だろう。ただし大規模アプリケーションでは機能面の限界があるかもしれない。
  • Spotのコミュニティとドキュメントがさらに発展すれば、より多くの開発者が容易に利用できるようになるだろう。特にカスタムフックやコンポーネントの作成方法に関する例がさらに増えるとよい。
  • Spotのバックエンド拡張性は興味深い。特にWindows向けのより良いサポートが追加されれば、さらに多くの開発者が利用できるようになるだろう。

1件のコメント

 
GN⁺ 2024-05-26

Hacker Newsの意見

Hacker Newsコメントまとめ

  • 対応プラットフォームをREADMEに明記するとよさそう。Flutterのドキュメントのような書き方を提案したい。
  • Goを使って社内開発ツールを作りたいと考えていて、現在はWailsを使っており満足している。このプロジェクトも興味深く、一度見てみる価値がありそう。
  • GoはクロスプラットフォームUI開発で良い体験を提供できると思う。
    • ビルドの複雑さを管理することがクロスプラットフォーム開発の大きな難しさだが、Goはそれをほぼ取り除いてくれる。
    • ネイティブコントロールのサイズがプラットフォームごとに異なる場合、クロスプラットフォームのレイアウトをどう解決するのか気になる。
  • 仮想コントロールツリー方式の利点が何なのか気になる。
    • ユーザーに表示されるコントロールを直接更新するのと比べて、どんな利点があるのか知りたい。
  • 何年も前からこういうものを探していた。
    • Windows対応が必要だったのでC++に切り替え、wxWidgetsを使っている。
  • 努力は称賛したいが、Windows対応のないクロスプラットフォームは惜しい。
  • 3週間前にこのプロジェクトを知っていたらよかったのに。
    • Goに移植されたReactやReactライクなフレームワークは、すばらしい開発体験を提供すると思う。
  • FltkはWindowsをサポートしている。
    • 別のソリューションを使っているため、まだWindowsをサポートしていないのか気になる。
  • このコードはGOMAXPROCSを最低2に設定する必要があることを意味するのか気になる。
  • クロスプラットフォームビルドがどう実現されるのか気になる。
    • プラットフォームごとのパッケージ管理、コンテナ、署名の問題を解決しなくても、MacOSの.appやWindowsのexeを生成するコマンドがあるとうれしい。