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信奉者の愚かさもアホとしか言いようがない。

>>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 で認めている。
まあ、それが彼のやりたいことだというなら仕方ないじゃないか。

afinity modeを実装すれば解決する。

>>582
> テキストボックスがぼーんとあって何を入れるかわからないのに何が便利なの？

はい。情報が型しかないとそうなりますよね。
だから型の情報はいらなくて、
「何を入れるか分かる情報」が必要なんですよ

すげー40年前と同じ話題してる。

>>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
素数を設定するなんてかなりマイナーな話だと思うけど
マイナーだからと逃げたら汎用性の謳い文句がすたるぞ

>>601
そこでActiveXですよ。

>>606
汎用と万能は違いますからねｗ

>>608
この設定XMLとツールで汎用とはどういう話？

>>602
> xmlはhtmlじゃないと言ったり、
XMLはHTMLじゃない。当たり前

> htmlを参考にしたり、なにがなんやら。
著名な論文を参考にして、書いた自分のレポートは
著名な論文になるとでも思ってるのか？

> xmlのタグをguiのパーツに対応させるコーディングだけでも大変なのになんかのツールキットでも使うつもりなのか
汎用のXML設定ファイルの話とは関係ない話ですね。

>>603
> 設定ツールのvalidationが実装依存は相当まずくね？

全然まずくない。何度も大前提と書いた
アプリケーション側のチェックは行われてる。

何度も大前提と言わないと理解できないのか？

>>604
> 不正な値を設定したらアプリがエラーを出す、確かに正しいが
> そんなぶっちゃけやるならリッチなUIとかもういらないだろ

アプリがエラーを出すことと、
設定ファイルを簡単に編集できることに何の関係が？

>>611
お前は一行目しか読めないのか

>>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コーディングも兼ねる。（設定ファイルでインターフェースを描画し、値を変更したものを保存する）

テキストファイル書いて設定させるなんて昭和末期か平成初期には通用したけど、いまじゃデメリット多くて古くさいってバレバレの手法だよねｗ

windowsレジストリの利点って？

>>634
設定が多段のツリー構造になったことで柔軟に構成できる（限度はあるけどフラットなテキストファイルより使い勝手は良い）

パス、キーが判ってれば値の取得と更新はOSにリクエストするだけで済む。
独自ライブラリでR/Wしなくて良いしOSのバージョンが変わってもアプリには影響ない（APIが互換性保つかぎりはｗ


デメリットとしては「設定を保存するエリアにコメントを書けない」ってのがあるね。

全て共倒れの危険性もね

レジストリがテキストより編集しやすいかは習熟度によると思うぞ。慣れたらテキストのほうが見通しが良いし、わかりやすい。

レジストリとかgconfとかって機能してない項目が大量にあるのはなんでなん？

>>631
> この人設定と設定の設定の区別がついてないような感じよね

わかった上であえてそうしてるんやで。
なぜなら、設定ファイルをテキストエディタで
修正したいという層が一定数いるから

テキストエディタで修正しないんだったら
設定ファイルにコメント機能なんていらん。

コメントはまさに、設定ファイルにUIが含まれてるってことなんだよ
それみてどんな値を入れるか判断しているわけだから

設定値と設定UIを作り出すタグを分離すれば、
今度はテキストエディタで修正したい人が使いづらくなる

UIがどう表示されるか規定されないし
個々のフォームがどういう挙動するかも不明で
使いやすいのかというか実用になるかもわからんけどな

> UIがどう表示されるか規定されないし
HTMLだってそうだよ。

そもそもどう表示されるかはデバイスによって異なる
PCで使いやすいUIがスマホでも使いやすいわけじゃない

なんでこうすでに通り過ぎた歴史の話ばかりするだろうか？

現実を否定しているところから始まってる妄想だから現実離れしてて現実的じゃないのは当然やろうな。
こうだったら良かったのにというボヤキなんだろうが、ボヤキにしても無知を晒してるだけだからな。

アイデアとしてはわかるんだよね。
東芝が昔実験的に作ってた。
XMLスタイルシート的なアイデアは大昔から存在するんだが、実用的なものを構築するのはなかなか難しいと思う。

HTMLが規定されてない、という部分を都合よく拡大解釈するし
不味いところは逃げ回るし

>>642
なんで現実にある問題点と解決策を言ったら、現実離れになるの？
その理屈だと、効率が悪いと指摘するだけで
効率が悪いのが現実なんだ。現実離れしたことをいうな！ってことになるけど？

>>644
拡大解釈だろうがそうでなかろうが、
どちらにしろその解釈に反論できないんでしょ？

>>646
答えられないところから逃げ回るなって

少なくともUIの意味論的な話で共通理解が無いと実際に実装は無理。
その規約決定を放棄してお前の頭の中でだけそんなのわかるだろでは話にならない

>>647
全部答えてるけど？

>>648
> 少なくともUIの意味論的な話で共通理解が無いと実際に実装は無理。
何が言いたいんだかさっぱりわからん。

HTMLの仕様とか見たこと無いのかな？
UIをどうしろとか書いてないよ

W3Cは戦場なので、力あるものが勝つし、勝ったものが正しいとは限らない。
裁判と同じだよ。

>>649
フォームの挙動は規定するの？

エンジニアなのに教祖への愛がすべてなのが、ウェブの未熟さを表してるんだよ。

>>645
現実にある問題点はconfig.xmlに独自タグが多いってだけのこと？他にある？

ウェブ業界には勉強会と称して毎週ミサがあるだろ。
お互いに啓蒙しあい信仰心を深める。
最後にみんなで歌を歌って解散。
まさにイカ臭い新興宗教じゃないか。

二言目にはHTMLガーであるがこいつが想像してることは
JavaScript・CSS・サーバサイドその他HTTP技術が関わっていのに
XMLの話だけで設定ツールへのその部分の押し込み方が全く不明

>>650
>>648の言いたいことがわからないのは読解能力がないから。お前の妄想をなんとか理解しようとしてるみんなは表現力が乏しい文章に根気よく付き合ってるから。

実際それっぽいのはweb技術に寄生したらelectronですぐ作れるけど、今度はアプリケーション側がhtmlスクレイピング並みに頑張らねばならなくなる。どこに得があるんだって話だよ。

そしてすぐ作れるものを誰も作ってないってことは、もう言わなくてもわかるだろ。
本当に役に立つならすぐ作っちゃえよ。それで飯くっていけるぞ。

Windows 使ってないからレジストリについてググってみた。
Windows を使わない理由が増えた。いや、今更だが……

>>53
これやね

アホやろ
移植性が段違いじゃんか
それに世界中に使ってる人がいるってことも
無視しとるやんけ、自分が無能なだけや

>>628
嫌みだなあ

正直、C89以前のCなんか読めたものじゃないし、
かといってC++11以降の機能使いまくったソースも読めたものじゃない。

>>637
嘘だよ。初心者に優しいのは、テキスト編集だよ。
英語が苦手なだけでしょ。

マウントなんて、大分前からクリックするだけやんけ
それよりディスクの故障チェックもできないとか、そっちのほうが怖いよ

>>633
へー、今はむしろナウいんだけどな
取っとけるし

見通しがよいかどうかはシステムのサイズによる。複雑になれば階層構造のレジストリのほうがいいに決まってる。
基本的な型は用意されてるし、細かくセキュリティも設定できるし、読み書き用のAPIも用意されてる。
OS起動時に必ずバックアップを取ってから起動してくれるのもメリット。

なんでもviで作業したいというのが諸悪の根源。開発環境が50年前とい言われても仕方がない。

>>665
英語苦手じゃないけど、ちょっと言ってる意味がわからん。とりあえず、レジストリはめんどくさいぞ。

レジストリより環境変数のほうが使いやすいよな！！！
って人は少ないだろう。

みかんとしいたけだったらみかんのほうが美味しいよな

何も足す必要がないということは究極を極めているということであろうか。

しいたけの方が好きだな。

xmlの優位性はテキストだということだけれども、実際テキストエディタでxmlを閲覧すると醜悪そのものだよね。

>>4
Windowsのビルドって、どれぐらいかかるか知ってる？

>>669
そういう意味なんだけどね
テキスト編集の方が楽だけど、設定ファイルの雛型に
書いてある説明が英語なのは、日本人にとって辛いかなと
慣れればなんてことないけど。