2019/11/11(月) [n年前の日記]
#3 [prog] GUIレイアウトのMarkdown的フォーマットはないのだろうか
GUIアプリのレイアウトにおける、Markdown的なフォーマットって無いのかなと、なんとなく思ったり。
分かる人なら、これで話は終わりというか。
分かる人なら、これで話は終わりというか。
◎ GUIレイアウト指定のトレンド。 :
一応、簡単に説明。
GUIアプリを作る際は、「ウインドウ内の、このへんに、このWidget(GUI部品)が配置されて、そのWidgetはこんなプロパティを持ってるよ」といった指定を ―― レイアウト情報を記述していく必要があって。
それらレイアウト情報は、プログラムのソース内に、プログラマーが手打ちで記述していくことも、一応はできるのだけど。
しかし、一般的には、レイアウト情報だけをまとめた別ファイルを書いて、プログラム側はソレを読み込んでレイアウトをする事例が多いわけで。それがトレンドというか、随分前から当たり前になってるようで。
そりゃまあ、そうなるよなと。だって、Widgetの位置やサイズを変更するたびに、UIのデザイナーさんがプログラマーにお願いして、プログラムソースを弄ってもらうとか、そんなの面倒臭いし…。間違って、計算その他の処理部分を弄ってしまってエンバグしたらヤバいし…。見た目とロジックは分離しておいたほうがいいわけで。
もしかすると、Webページが、ページ内容を記述する HTML と、ページの見た目についての指定を記述する CSS に分かれている、てなノリに近いのかもしれない。見た目に関する情報だけをまとめて別ファイルで管理しようぜ、そのほうがイケてるぜ、みたいな。
それらレイアウトを指定するファイルのフォーマットは、GUIライブラリ毎に違っていて。
他にも色々あるだろうけど、つまりは各ライブラリが自身にとって都合のいいように、フォーマットを勝手気ままに決めている状態というか。
GUIアプリを作る際は、「ウインドウ内の、このへんに、このWidget(GUI部品)が配置されて、そのWidgetはこんなプロパティを持ってるよ」といった指定を ―― レイアウト情報を記述していく必要があって。
それらレイアウト情報は、プログラムのソース内に、プログラマーが手打ちで記述していくことも、一応はできるのだけど。
しかし、一般的には、レイアウト情報だけをまとめた別ファイルを書いて、プログラム側はソレを読み込んでレイアウトをする事例が多いわけで。それがトレンドというか、随分前から当たり前になってるようで。
そりゃまあ、そうなるよなと。だって、Widgetの位置やサイズを変更するたびに、UIのデザイナーさんがプログラマーにお願いして、プログラムソースを弄ってもらうとか、そんなの面倒臭いし…。間違って、計算その他の処理部分を弄ってしまってエンバグしたらヤバいし…。見た目とロジックは分離しておいたほうがいいわけで。
もしかすると、Webページが、ページ内容を記述する HTML と、ページの見た目についての指定を記述する CSS に分かれている、てなノリに近いのかもしれない。見た目に関する情報だけをまとめて別ファイルで管理しようぜ、そのほうがイケてるぜ、みたいな。
それらレイアウトを指定するファイルのフォーマットは、GUIライブラリ毎に違っていて。
- wxWidgets (wxPython) : XRC
- Kivy : .kv
- Microsoft : XAML?
- Qt : QML?
他にも色々あるだろうけど、つまりは各ライブラリが自身にとって都合のいいように、フォーマットを勝手気ままに決めている状態というか。
◎ 統一できないのかな。 :
GUIレイアウト情報を記述するフォーマットは、GUIライブラリ毎に違っているので、たくさん種類があるというか、乱立しちゃってるわけだけど。
なんだかこのへん、wiki記法とか、はてな記法とか、HNS(hnf) とか、reStructuredText とか、Markdown とか、その手の軽量マークアップ言語を連想するなと。
少し説明しておくと…。HTML だの PDF だの、そのあたりのソースは、コンピュータが読み書きして処理がしやすくなることを前提にしたフォーマットなので、そんなものを人間が直接手打ちで書いていくなんて馬鹿馬鹿しいよなと。まだ人間でも分かり易くて、比較的よく使う機能だけをまとめた簡単なルールで、一旦、元になる文書を書いて、それを HTML や PDF に変換すればええやん ―― という発想で、wiki記法だの、Markdownだの、色々な軽量マークアップ言語が次々に発明されてきたわけで。その中でも、テキスト形式の状態で何が書いてあるかが「見た目」「パッと見」で分かり易い Markdown が、徐々に人気を得て席巻してきた、という状況があって。
そのあたりを考えると、GUIレイアウトについても、とりあえずコレで書いとけば他のGUIライブラリでも流用できる、人間が直接手打ちすることも不可能ではない程度には分かり易いし、みたいなフォーマットがあったりはしないのかなあ、と。
もっとも、そういった分野のデファクトスタンダードを狙って、各社・各組織・各ライブラリが、その手のフォーマットを提示してきたから、こうして乱立してるのだろうけど…。
ライブラリ毎に持ってる機能が違うので、共通化できない面もあるのだろうな。時々、「Markdown は機能が少な過ぎる」と文句が出たりもするけれど、「分かり易くすると、できることも少なくなる」というか…。何でもそうだけど、結局はトレードオフ、なのかも。
なんだかこのへん、wiki記法とか、はてな記法とか、HNS(hnf) とか、reStructuredText とか、Markdown とか、その手の軽量マークアップ言語を連想するなと。
少し説明しておくと…。HTML だの PDF だの、そのあたりのソースは、コンピュータが読み書きして処理がしやすくなることを前提にしたフォーマットなので、そんなものを人間が直接手打ちで書いていくなんて馬鹿馬鹿しいよなと。まだ人間でも分かり易くて、比較的よく使う機能だけをまとめた簡単なルールで、一旦、元になる文書を書いて、それを HTML や PDF に変換すればええやん ―― という発想で、wiki記法だの、Markdownだの、色々な軽量マークアップ言語が次々に発明されてきたわけで。その中でも、テキスト形式の状態で何が書いてあるかが「見た目」「パッと見」で分かり易い Markdown が、徐々に人気を得て席巻してきた、という状況があって。
そのあたりを考えると、GUIレイアウトについても、とりあえずコレで書いとけば他のGUIライブラリでも流用できる、人間が直接手打ちすることも不可能ではない程度には分かり易いし、みたいなフォーマットがあったりはしないのかなあ、と。
もっとも、そういった分野のデファクトスタンダードを狙って、各社・各組織・各ライブラリが、その手のフォーマットを提示してきたから、こうして乱立してるのだろうけど…。
ライブラリ毎に持ってる機能が違うので、共通化できない面もあるのだろうな。時々、「Markdown は機能が少な過ぎる」と文句が出たりもするけれど、「分かり易くすると、できることも少なくなる」というか…。何でもそうだけど、結局はトレードオフ、なのかも。
[ ツッコむ ]
以上です。