GUIフレームワーク-スレッドごと

ご挨拶、同僚！



数か月前、デスクトップアプリケーションにGolangを使用することを目標にGolangを検討し始めました。 言語、ボリューム、およびそのために書かれたパッケージの主題が印象的でしたが、GUIの状況はそれほどバラ色ではありません。 詳細については詳しく説明しませんが、いくつかのレビューと既存のGUIパッケージの概要を読んだ後、特にこの経験があるので、自分で作成することにしました。



私の最初の考えは、すでに打たれた道に沿って行くことでした：対応する一連の関数をCで書くか、すでに用意されているものを適応させます-かつてハーバーとC ++用に書いたものをcgo（C API for Golang）を使用してバインドし、フレンドリーなラッパー。 私もこれを始めて最初のウィンドウを手に入れましたが、Windows、Linux、純粋に技術的な作業を別々に行っていたので、すでに進んでいたので、私の熱意はやや冷めていました。



そして、別のアイデアが生まれました。



結局のところ、ハーバー用のGUIライブラリであるHwGUIが既にあります。これは、非常に機能的で、クロスプラットフォームであり、アプリケーションで定期的に使用しています。 必要なものはすべて既に実装されています。 ある種のGUIサーバーとして機能するプログラムをその基礎の上に書いてはどうでしょうか。 起動後、このサーバーは特定のポートを静かにリッスンし、Golangプログラムから接続を受信した後、ウィンドウ、ウィジェットを作成し、それらを操作し、ウィジェットからのイベントが表示されたときにフィードバックを提供しますGUIを実装します。 GUI実装の低レベルの詳細はすべて、Windowsの場合、WinAPIへの直接呼び出し、Linux / Unixの場合、おそらくmacOsの場合-GTKを介して、すでにライブラリにあります。 さらに、私は言葉の意味でサーバーを作成するつもりはありません。異なるプログラムからの接続を受け入れません-これは追加の不必要な困難をもたらします。 Golangプログラムの各インスタンスに対して、GUIサーバーの個別のインスタンスが起動され、タスクがさらに簡素化されます。 したがって、一般に、プログラムは2つのプロセスで構成され、一方はメインタスクを実行し、もう一方はインターフェイスを担当します。



Goの対応するパッケージには、GUIサーバーを起動して結合するInitプロシージャ、およびウィンドウとウィジェットを作成して操作するための一連の構造、メソッド、関数を含める必要があります。 これらすべての機能の主な内容は、特定の形式（JSONに基づく）のメッセージをサーバーに送信し、サーバーからメッセージを受信することです。 通信は2つのtcp / ipポートを使用してサポートされます。1つはサーバーへのリクエストの送信を担当し、もう1つはイベント処理（ボタンのクリック、ウィンドウのクローズなど）のためのサーバーからのシグナルの受信を担当します。 タスクは比較的単純で、パッケージ自体は小さいです。 cgoを使用する必要も、サードパーティライブラリへのバインドも、すべてGoのコードも必要ありません。 プログラム自体の実行可能ファイルとGUIサーバーの実行可能ファイルはすべてです。



GUIサーバーの実装にHarbor + HwGUIを選択したのは、まず、これらが最も単純で最速のソリューションである「ネイティブ」ツールであるためです。 しかし、これは他の観点からは良い選択です。 ここで、私の意見では、主な利点：

• 「ボックス内」のクロスプラットフォーム。
• ネイティブルックアンドフィールと呼ばれるもの。Windowsではこれらは排他的にWinAPI呼び出しであるため、Linux / UnixではGTK。 ただし、macOsのGTKが「ネイティブ」であるかどうかはあまりわかりません。
• Harborを組み込みのスクリプト言語として使用する機能により、コードフラグメントをサーバーに実行するために転送できます。たとえば、イベントハンドラーは、実装の詳細からメインプログラムをオフロードできます。 さらに、Harborは、dbfや一部のデータベースの操作など、多くの点で優れています。
• 印刷の実装;
• Designer（HwGUIユーティリティ）によって作成された画面フォームを使用する機能。 これらのフォームはXML形式で保存され、サーバーが実行されているOSを変更することなく使用できます。
• 同じDesignerで作成されたレポートフォームを（XMLでも）印刷に使用する機能。

要するに、私はこれを始め、作業の大部分はすでに完了しています。 GuiServerとGolang External GUIフレームワークの両方のプロジェクトはGithub上にあり、すべてのリンクは記事の最後にあります。 以下にスクリーンショットをいくつか示します。 特別なことはありません。テストするだけです。



これは簡単なダイアログボックスです。









これは、Kernigan and Donovanの本の例に基づいて行われます。









現在、プロジェクトの主な目標は、この甘いカップル、ExternalとGuiServerがHwGUIでできることをすべて実行できるようにすることです。 さて、Externalを使用して実際のアプリケーションを作成するプロセスでは、さらに必要なものが明確になります。



これで終わりになる可能性があるので、Golangパッケージの説明を延期しました。 しかし、この記事の主なことはまだ始まったばかりです。 結局のところ、同じGUIサーバーでGUIフレームワークを実装するために説明した方法は、他の言語にも使用できます。 C、Python、Java、...、さらにはPerlやPHP（そしてなぜそうではないのか）-記事のタイトルを参照してください。 最小コスト-かなり機能的なGUIソリューションが用意されています。 特定の各言語にとって最も難しいことは、サーバーとの交換の実装ではありませんが、このソリューションはそのパラダイム、内部ロジックに有機的に適合します。 誰かがそのような言語用にこのようなフレームワークを作成したい場合、必要な情報を取得するため、また場合によってはGUIサーバーにいくつかの機能を追加するために、可能な限りの支援を提供します。



Golangパッケージと並行して、主に検証/デバッグの目的で、Harborのアナログを作成しました。 Perlのフレームワークは実行されそうにありませんが、CまたはC ++の場合は非常に可能性が高いです。 理由は次のとおりです。結局のところ、GUIサーバーの使用に関連する別の興味深い機能があり、別のコンピューターで実行できます。 メインプログラムは1台のコンピューターで実行され、そのインターフェイスは別のコンピューターで実行されます。 このケースを使用するためのオプションはすぐにここに見られます：

• メインプログラムは、グラフィカルシェルがまったくインストールされていないLinux / Unixサーバーで実行されます。
• メインプログラムは（会社の条件付き会計士がいる）外国のコンピューターで実行され、ユーザーはそれを妨げずに自分で管理します。
• メインプログラムはスマートフォンで実行され、通常のコンピューターからその内部を掘り下げます。
• メインプログラムは、通常のモニターが存在しない可能性のある一部のArduino、Raspberry、またはそれらのカウンターパートのコントローラーで実行されます。 あなたのラップトップと接続してください。

さて、この最後のオプションでは、GUIサーバーのCフレームワークがおそらく役立つでしょう。この可能性は非常に有望だと思います。



そして最後に、リンク：



github.com/alkresin/guiserver-GithubのGuiServer

github.com/alkresin/external-Githubの外部（Goパッケージ）

www.kresin.ru/guisrv.html-私のサイトのGuiServerページ、ここで既製のバイナリをダウンロードできます

habr.com/post/198618-ハーバーに関する私の記事はHabréにあります

en.wikipedia.org/wiki/Harbor-ウィキペディアの港

www.kresin.ru/harbour.html-私のウェブサイトのハーバーページ

www.kresin.ru/hwgui.html-私のウェブサイトのHwGUIページ



PS：ソースからGuiServerを構築するためにHarbourとHwGUIをインストールする人はほとんどいないので、収集したバイナリを定期的にサイトのGuiServerページに投稿します-Windows、Debian 8 32ビット、Ubuntu 18.04 64ビット Fedora用に組み立てることはできますが、macOsでは、残念ながら、徒歩圏内にはありません。