Linuxは、開発環境が40年前と同レベル
間違ってもらっては困るのは、それはコマンドライン・メインなのが主因ではないということ。
本当の一因は、本来手書きでも簡単な Makefile の作成をわざわざ難しくしてしま
う autotools を権威に流されたのか多くのプロジェクトが使ってしまっている事にある。
高々 Makefile 1つ作るためにも以下のような工程を踏まなければならない。
本来、典型的には、ソースファイルである *.c, *.cxx, *.cpp を指定するだけ
でも自動生成する事が出来るはずなのに、ツール類が馬鹿だからそうなってない。
なのに、「Linuxはプログラマーには便利」などと嘘情報が流れるから、普及しない。
しかも、カレントディレクトリのスクリプトの実行に「./configure」などと「./」
の指定が必要なのも馬鹿丸出し。ファイル名に大文字小文字の区別がされているのも馬鹿。
ファイルのコピーもdosなら、「copy *.c /xxx/aaa 」で済むことが
$ find . -name '*.c' | xargs -n 1 -i cp -p {} /xxx/aaa
などとしなくてはならず長すぎ、馬鹿ですか？ しかも、'*.c'の部分が、*.c と書かれている
説明が溢れているがそれだとbashが展開してしまうのでたまたま上手く行く事はあっても、
実際には正しくない。また、mountしないとディスクが認識出来ないのも初代PC-8001の
レベル。PC-8801で自動マウントできるようになったのに（いつの時代（苦笑））。まずは、
不便さを認めるなければ、改善すらままならないのにそれすら全否定。正直に便利と思って
るなら井の中の蛙で馬鹿で無知なだけだ。そして、僅か１点でも間違いがあれば全てが間違って
いるように全否定してしまうLinux信奉者の愚かさもアホとしか言いようがない。 >>522
>>523
あるタグならこう動作するこの属性はこう取り扱うなど記述してるけど
その取り決めは誰がするの？ 例えばにはtype=intとあったときにintというのは整数型で実装すると判断する根拠はどこにあるのかな？ >>551
取り決めを誰がするのかどうかの話は
技術的な話と何の関係があるの？
例えばJavaScriptのブラウザの新しいAPIの仕様の話をしているときに
取り決めは誰がするの？と言い出すことに何の意味があるの？ >>552
> 例えばにはtype=intとあったときにintというのは整数型で実装すると判断する根拠はどこにあるのかな？
あ、それは間違いでしたって>>523で訂正したよ。
type=intはデータ型に過ぎなくて、データ型の情報では
どういうインターフェースで入力するかは決定できない。
古き良き、テキストボックスで入力するかもしれないし
HTML5の数値専用のテキストボックス（数値増減の▲▼つき）かもしれないし
スライダーを使うかもしれない。なので汎用のXML設定ファイルには
データ型を記述することはない。
要するに「整数型で実装するという判断はすべきでない」が正解なんだわ
なぜならそもそも不要だからね。XMLでない設定ファイルだって、
log_level=[ここ] が整数型で実装するか文字型なのかって判断は必要ないでしょ？
今やってないのに、汎用のXML設定ファイルにした途端、必要になるなんておかしい。 >>554
では質問を変えて。
実装者が実装する参考資料として事前に取り決めつまり仕様書は必要なの？ >>555
それだとintとかいてあったらカレンダーが表示される
実装するのは禁止されてないと読めるけど？ >>557
だからintなんて書かないって言っただろ
お前が訂正するまで話は進めない >>558
type=numberならOKなのか？ >>559
numberは変数の型じゃないからな
inputタグ（テキストボックス）を使いnumber（数値）を扱うための
インターフェースを使用しろって明示してあるんだから
カレンダーを使うやつなんていないだろう
>>556はこの話題の対象外です。 まあもちろん腐った実装がカレンダーを表示した所で
おかしな設定をしてしまうってだけ
汎用のXML設定ファイルじゃない場合を想像してみりゃわかる
log_level="2018-09-27"
こう書いてしまっただけのこと
あとはプログラム側で今までどおりエラーがでるだろう いや関係あるだろ。
何の前提知識もない実装者が
これを見て
<label>foo: <input name="foo" type="number" value="1" />
numberが数値を意味するとか
テキストボックスでもよいスライダーでもよい
カレンダーはだめだという判断を下せる根拠はどこからくるの？ >>562
腐った実装という言葉を使うけど客観的に腐ってるか正しいか
どうやって判断するの？ >>563
え？なに？仕様書を作る必要があるって話をしてるの？
作ればいいだけじゃん。 >>565
それはずっと言ってるHTMLより小さいと想定する仕様書に全部含まれると考えている？ <input name="foo" type="number" value="1" />
inputはユーザーが入力する項目を示します。
type属性は入力する値の種類を意味します。
設置ツールは適切なインターフェースを使用してください
終わり。たったこれだけｗ >>567
値の種類とは？何種類あるの？勝手に増やしていいの？
適切なとは？何が適切でないとどうやって判断するの？
疑問一杯で仕様書とか読んだことも無さそうにしか見えないけど？ >>567
このレベルが仕様だと思ってるようでは話が通じないわけだ >>556
お前は何が言いたいんだ？
HTMLはXMLベースではないのだから「XMLの仕様に準拠します」と書くことができない。
だからXML相当の仕様に加え、XMLには不要なHTML独自の仕様がたくさん含まれてる
例えばタグを省略したときのルールや、不正なタグ場合の解釈の仕方などだ
汎用のXML設定ファイルには、XMLの仕様を含める必要がない
ただ一言「XMLの仕様に準拠しますと」書けばいい
汎用のXML設定ファイルの仕様だけあればいい
だからどう考えても、
HTMLの仕様の量 > 汎用のXML設定ファイルの仕様の量（XMLの仕様は含まない）
になるのは明白なんだが >>568
だから、仕様を作るだけですよね？
>>569
何が足りないのか、言ってみたら？
その量がHTMLの仕様の量を超えるまで待ってるよｗ >>567
アプリの作者からすると<foo>1</foo>で事足りる
設定ツールの作者からしても
input + number という無駄情報より
type="int" という型情報
のほうが正確というかそのものなのでありがたいな >>572
そういうこというと汎用設定ツールが作れないだのXMLの使い方が間違ってるだの馬鹿にされて
破綻してる設定XML構想聞かされるぞ つか未だにgconfだのdconfだのが一度も出てこないことに驚き >>574
それはずっと思ってた。
XMLおじさんによる比較とかダメ出しとかねーのか？ >>572
> 設定ツールの作者からしても
> input + number という無駄情報より
> type="int" という型情報
> のほうが正確というかそのものなのでありがたいな
type=intとあったときにintというのはスライダーで実装すると判断する根拠はどこにあるのかな？ >>574
gconfやdconfは値を編集することはできるが、
どういった値（型ではないぞ。値の範囲や文字列の候補だ）が設定可能か？の情報や
どういうインターフェースで設定するのか？という情報が抜けてるので、
使いやすいツールにはできない >>576
numberと書けばスライダーが出てくる理由がわからん numberと書けばスライダーが出てくるなんて言ってないぞ？
話を整理しようか？
1. type="int" という型情報じゃスライダーと数値用テキストボックスの
どちらを出せばいいかわからない
このことから型情報ではダメであると理解できたはずだ。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
で、numberと書けばスライダーが出てくるかどうかだったな
HTMLを参考にしてると言っただろう？
http://www.htmq.com/html5/input.shtml
2. type="number" だと数値用のテキストボックス（相当のもの）
type="range" だとスライダー（相当のもの）が表示される
typeに書いているのは変数の型ではないことが理解できたかな？ >>579
例えばnumberで出てくる数値入力ボックスは
要求が整数か浮動小数点か区別できるの？ >>580
まずさ、君が理解しないといけないことは
XMLではない設定ファイルにデータの型情報を
書いてるものなんか無いって事実だよ。
そう。いらない。整数化浮動小数点数か区別する必要がない。
inifileに
[VM]
MemoryGB=1
とかあった時、MemoryGBが整数か浮動小数点数か区別できるの？
区別できないし区別する必要がないよね。
数値どころか文字だって書くことができる >>581
テキストボックスがぼーんとあって何を入れるかわからないのに何が便利なの？ 彼の目的は >>220 に書かれている。すべて、そのための妄想だ。
妄想だということを本人も >>180 で認めている。
まあ、それが彼のやりたいことだというなら仕方ないじゃないか。 >>582
> テキストボックスがぼーんとあって何を入れるかわからないのに何が便利なの？
はい。情報が型しかないとそうなりますよね。
だから型の情報はいらなくて、
「何を入れるか分かる情報」が必要なんですよ >>576
アプリの作者からしたら
スライダーだろうがテキストエディタだろうが関係ないんだから関与する必要がない
ツール作者やその利用者が好きにしたらいいだけ
>inputはユーザーが入力する項目を示します。
>type属性は入力する値の種類を意味します。
>設置ツールは適切なインターフェースを使用してください
という軟着陸なアイデアは無意味なので無視するとして
アプリ作者の独断で
エディット、スピン、スライダー、ダイヤル…
数有るコントロールの種別の中から一つを決めたとしても
そのチョイスを万人が受け入れるはずがないし
そのチョイス自体負担だし選び直しでリビルドとかやってられない
それなら
int型です、UIはご自由に
と投げたほうがいい
そもそも
int型です
という情報すらも必要ない
それが必要だという人が勝手に調べりゃいいだけ >>585
型情報とは違う「何を入れるかわかる情報」の具体例は何？ >>587
> アプリの作者からしたら
> スライダーだろうがテキストエディタだろうが関係ないんだから関与する必要がない
> ツール作者やその利用者が好きにしたらいいだけ
そう。だから利用者が好きにできるように
汎用のXML設定ファイルがある。
設定ファイルの情報をもとに設定画面を組み立てるから、
設定ファイルを書き換えて使いやすい設定画面を作ることができる
まさに、ツール作者やその利用者が好きにできるということを実現している
アプリの作者からしたら、どのインターフェースでも設定された値を取得できる。
ツール作者やその利用者が好きに使いやすいインターフェースを作ることができる >>588
数値だったら、その範囲等。0〜100とか
文字列だったら、その文字列長さや、正規表現パターンなど
選択項目だったら、設定可能な値、例えばredやblueといった色の名前など ある設定項目αについ設定ツールAが1から100のスライダーで表示したとき
設定ツールBでも同様に1から100のスライダーが出てくると
ユーザは期待して良いのか（y/n）？ >>591
NO。ただしどのツールでも設定できる
[VM]
MemoryGB=1
結局の所↑の1の部分を入力するだけだから
スライダーが出てこないでテキストボックスがでてきても
なんてことはない。普通に入力して設定できる。 では設定項目αは整数値で1-100と設定した場合
設定ツールから1000と入力しようとしたら何らかのエラーが
ユーザに通知されるものと期待して良い（yn） >>593
聞いてばかりいないで、少しは自分で考えてみたら？
まずXMLではないよくあるテキストファイルの
設定ファイルのことを考えてみようか？
不正な値も含めどんな値でも書くことができる
その不正な値が書かれた設定ファイルをアプリケーションが
読み込めば普通はエラーを出すだろう。
いいか、汎用のXML設定ファイルの話はまだしてないぞ。
信頼できるチェックはアプリケーション側で行われているこれは大前提である
で、ここからが汎用のXML設定ファイルの話
設定ファイルに書かれた範囲などは、使いやすくするためのガイドに過ぎない
どうせXMLファイルをテキストエディタで開いて書き換えれば好きな値にできる。
不正に値にされた所で、大前提である信頼できるチェックはアプリケーション側で行われてるから問題ない
で、何らかのエラーが出るかって？ 設定ツールの実装次第
まあ普通はエラーを通知するようにするだろうね
実際HTML5もそうなってる。対応してるブラウザであればエラーを通知するが
対応してないブラウザではエラーを通知しないし、スライダーの指定をしても
対応してなくてテキストボックスが表示される。でも信頼できるチェックは
サーバー側で行われてるから問題ない
もうね。ここらへんHTMLの世界ですでに通った道なの。
一旦HTML5を勉強したほうが良いよ？
基本的な質問をしてるってことがわかってない。 要するに設定項目の値の範囲の制限などを指定したとしても
設定ツールによる入力の挙動は実装依存だと。
さて「何を入れるかわかる情報」とし0〜100の数値を挙げているが
このようなものはどれだけ記述できるのか？
事前に何があると知らない限り設定XML記述者も設定ツール作成者も困るだろう。
・0から100の整数
・0から1の浮動小数点（閉区間もあれば半開区間もある）
・32ビット長ただし16進記法
・任意長整数
・素数
・42の倍数のみ
等々数値だけでもいくらでもやりたいことは考えられるがこれらは
何でも記述できるのか
数種だけ用意されててあとはあきらめろということなのか？ >>594
HTMLのフォームの値チェックはサーバサイドがJavaScriptの話に
なってHTMLやXMLの範疇を超えてるがどういう話になるんだこれ もはや、汎用設定ツールでも何でも無くて、
汎用GUI作成ツールになりつつあるな。ブラウザより大きくなる。 >>595
だからHTML5を勉強しろって
>>596
フォームの値チェックなんか、
フォームコントロールの属性でできるだろ
HTML5の勉強しろって >>597
また何の根拠もなくブラウザより大きくなる（笑）か
何が大きくなるのー？ｗ
ブラウザがどれだけ大きいかしらないのー？ｗ >>598
HTML5で素数だけ入力可とかできるの？ お前は設定ファイルで素数だけ設定したことあるのか？
そんなマイナーケースまで対応しようとか考えるから
仕様がぶくぶく太っていくんだぞｗ xmlはhtmlじゃないと言ったり、htmlを参考にしたり、なにがなんやら。
xmlのタグをguiのパーツに対応させるコーディングだけでも大変なのになんかのツールキットでも使うつもりなのか 設定ツールのvalidationが実装依存は相当まずくね？
ツールで値を入力したときエラーがでなくても
値が妥当なのかエラー処理が手抜きなのかユーザーにはわからない
ことになるけどそれ何もチェックしないより悪いな 不正な値を設定したらアプリがエラーを出す、確かに正しいが
そんなぶっちゃけやるならリッチなUIとかもういらないだろ dconfは設定できる値のリストとか正しくない値を設定しようとするとエラー返すとか普通に出来てるんだよなぁ
しかもなぜxmlじゃなくて独自のバイナリフォーマットなのかってのも、DEの起動時みたいに一遍に色んなアプリケーション起動して大量の設定をロードしてってなるとxmlのgconfだとパフォーマンス的に良くないってんでそうなってるわけだが
そういう現実的な部分をすっ飛ばして実際に作ってすらねぇ妄想でドヤってちゃ話になんねぇわ >>601
素数を設定するなんてかなりマイナーな話だと思うけど
マイナーだからと逃げたら汎用性の謳い文句がすたるぞ >>608
この設定XMLとツールで汎用とはどういう話？ >>602
> xmlはhtmlじゃないと言ったり、
XMLはHTMLじゃない。当たり前
> htmlを参考にしたり、なにがなんやら。
著名な論文を参考にして、書いた自分のレポートは
著名な論文になるとでも思ってるのか？
> xmlのタグをguiのパーツに対応させるコーディングだけでも大変なのになんかのツールキットでも使うつもりなのか
汎用のXML設定ファイルの話とは関係ない話ですね。 >>603
> 設定ツールのvalidationが実装依存は相当まずくね？
全然まずくない。何度も大前提と書いた
アプリケーション側のチェックは行われてる。
何度も大前提と言わないと理解できないのか？ >>604
> 不正な値を設定したらアプリがエラーを出す、確かに正しいが
> そんなぶっちゃけやるならリッチなUIとかもういらないだろ
アプリがエラーを出すことと、
設定ファイルを簡単に編集できることに何の関係が？ >>605
> dconfは設定できる値のリストとか正しくない値を設定しようとするとエラー返すとか普通に出来てるんだよなぁ
画像見せて
ぱっと検索した限りでは、単なる名前と値の羅列しかないですね。
これみてエンドユーザーに設定させろと？
無理でしょ。各アプリが丁寧に作った設定画面と
どれだけ差があると思ってるのさｗ >>613
何度も言わないと本当に理解できんのなｗ
大前提としてアプリケーション側でチェックしてあるんだから、
設定を読み込ませれば、エラー出るっていってんの >>612
前提としてツールの実装によっては
滅茶苦茶な値を設定してもスルーされるという話を無視するなよ
簡単に編集出来ても滅茶苦茶な値で喜ぶユーザーいるのか？ >>609
> この設定XMLとツールで汎用とはどういう話？
汎用のXML設定ファイルの、汎用とは別のアプリでも同じXMLスキーマを利用できること
（いっとくが利用できるのはスキーマだけだぞｗ） >>615
アプリで読み込ませるまで滅茶苦茶な値入れても気づかない
ツールが何が嬉しいの？ >>616
> 前提としてツールの実装によっては
> 滅茶苦茶な値を設定してもスルーされるという話を無視するなよ
現状だって、テキストエディタで編集したら
メチャクチャな値を設定してもスルーして保存できるじゃん。
アプリケーションに読み込ませたらエラー出るっていってんの >>619
設定ツール使っても何も便利にも改善もされてないけど何か意味あるの？ >>618
> アプリで読み込ませるまで滅茶苦茶な値入れても気づかない
> ツールが何が嬉しいの？
ユーザーが簡単に設定変更ができること
メチャクチャな値を入れたらアプリでエラーが出る
メチャクチャな値を入れられない所はエラーが出ない >>620
> 設定ツール使っても何も便利にも改善もされてないけど何か意味あるの？
ユーザーが簡単に設定できるようになるので意味がある。 君の話だと設定項目のウィジェットかどう実装されるかは決まってない
バリデーションもやらなくてもいいしエラーが出るかもわからない。
えーとテキストエディタに比べて嬉しさどこにあるの？ >>621
滅茶苦茶な値を入れるのを防ぐ保証ないのに
滅茶苦茶な値を入れるのどうやって防ぐの？ >>623
汎用のXML設定ファイルとして仕様が共通化されてるので
設定ツールを含めさまざまなツールやライブラリを作って
共通で利用することができること
またそれらのツールやライブラリを使ってユーザーも開発者も
便利で楽ができること
>>624
テキストエディタで設定ファイルを編集することを考えればわかる。
設定ファイルの編集は可能だが、アプリケーションでチェックが行われる >>625
ツール作ってもツールが何できるかわからないし
期待していたことが期待外れも余裕であるんだろ？
役立たずのツールが作れて何かメリットだって？ >>625
いよいよ壊れたレコードのように同じことを繰り返すしか能が無くなってきたな 40年経ってもwindowsレジストリの素晴らしさが理解できないのか。 >>624
結局作る側はユーザーが手で弄ったりする事も考慮して自分でも値のバリデーションをしないといけないもんな
なんつーか本当にものを知らないガキの妄想だよな 汎用ツールの特徴は
・開発者が楽できる（汎用ツールの仕様に合わせて開発すべき）
・ユーザーフレンドリー（直感的？アプリの仕様に関係なく設定はブラウザに似たインターフェース）
・設定ファイルがguiコーディングも兼ねる。（設定ファイルでインターフェースを描画し、値を変更したものを保存する）
これだけでもクソ仕様だとわかる。 >>630
これずっと思ってたわ
この人設定と設定の設定の区別がついてないような感じよね 引用忘れた
> ・設定ファイルがguiコーディングも兼ねる。（設定ファイルでインターフェースを描画し、値を変更したものを保存する） テキストファイル書いて設定させるなんて昭和末期か平成初期には通用したけど、いまじゃデメリット多くて古くさいってバレバレの手法だよねｗ >>634
設定が多段のツリー構造になったことで柔軟に構成できる（限度はあるけどフラットなテキストファイルより使い勝手は良い）
パス、キーが判ってれば値の取得と更新はOSにリクエストするだけで済む。
独自ライブラリでR/Wしなくて良いしOSのバージョンが変わってもアプリには影響ない（APIが互換性保つかぎりはｗ
デメリットとしては「設定を保存するエリアにコメントを書けない」ってのがあるね。 レジストリがテキストより編集しやすいかは習熟度によると思うぞ。慣れたらテキストのほうが見通しが良いし、わかりやすい。 レジストリとかgconfとかって機能してない項目が大量にあるのはなんでなん？ >>631
> この人設定と設定の設定の区別がついてないような感じよね
わかった上であえてそうしてるんやで。
なぜなら、設定ファイルをテキストエディタで
修正したいという層が一定数いるから
テキストエディタで修正しないんだったら
設定ファイルにコメント機能なんていらん。
コメントはまさに、設定ファイルにUIが含まれてるってことなんだよ
それみてどんな値を入れるか判断しているわけだから
設定値と設定UIを作り出すタグを分離すれば、
今度はテキストエディタで修正したい人が使いづらくなる UIがどう表示されるか規定されないし
個々のフォームがどういう挙動するかも不明で
使いやすいのかというか実用になるかもわからんけどな > UIがどう表示されるか規定されないし
HTMLだってそうだよ。
そもそもどう表示されるかはデバイスによって異なる
PCで使いやすいUIがスマホでも使いやすいわけじゃない
なんでこうすでに通り過ぎた歴史の話ばかりするだろうか？ 現実を否定しているところから始まってる妄想だから現実離れしてて現実的じゃないのは当然やろうな。
こうだったら良かったのにというボヤキなんだろうが、ボヤキにしても無知を晒してるだけだからな。 アイデアとしてはわかるんだよね。
東芝が昔実験的に作ってた。
XMLスタイルシート的なアイデアは大昔から存在するんだが、実用的なものを構築するのはなかなか難しいと思う。 HTMLが規定されてない、という部分を都合よく拡大解釈するし
不味いところは逃げ回るし >>642
なんで現実にある問題点と解決策を言ったら、現実離れになるの？
その理屈だと、効率が悪いと指摘するだけで
効率が悪いのが現実なんだ。現実離れしたことをいうな！ってことになるけど？ >>644
拡大解釈だろうがそうでなかろうが、
どちらにしろその解釈に反論できないんでしょ？ 少なくともUIの意味論的な話で共通理解が無いと実際に実装は無理。
その規約決定を放棄してお前の頭の中でだけそんなのわかるだろでは話にならない >>648
> 少なくともUIの意味論的な話で共通理解が無いと実際に実装は無理。
何が言いたいんだかさっぱりわからん。
HTMLの仕様とか見たこと無いのかな？
UIをどうしろとか書いてないよ 
