Linuxは、開発環境が40年前と同レベル
HTMLのなんとかというタグはこう使うなんてのは 別でそういうお約束を与えてるだけなのに自然に決まるみたいな発想はどこから湧いてくるんだろう この下らないスレのやり取りでも新しい発見があった それは既存のテキスト形式の独自形式の設定ファイル それは、テキストエディタが設定ツールで 設定ファイル自体はUIとみなせるということ 設定ファイルには設置値だけではなく、コメントという形で どういう項目であるかが書かれていて、ユーザーは その説明を見て設定を変更する 新しいもなにも*nixは昔からコンソールでテキストコンフィグをいじるんだろ。 だからなにも知らないって言われるんじゃねーかwww >>207 やっぱり理解してないw 上の方で馬鹿がいっていただろ? 設定ファイルは単に値さえ入っていればいいって。 現実として設定ファイルに人間が読むための文章が 入っていることの意味を理解してない 設定ファイルは単なる設定値があるだけのものではなくて インターフェースになってるって話をしてる そしてそのインターフェースを強化するための XML設定ファイルの話をしてる >>205 自然に決まらないならoptionがどういうUIを持つか実装依存で何の意味があるのやら 何の意味があるのやらと言われても、ブラウザがそうじゃん iPhoneの<select> & <option> 見たことある? PC版とぜんぜん違うよ。ドラムロールと呼ばれるUIになってる 見た目は違う(実装依存)だが機能は同じ 物事を抽象化して考えられないのかな? >>213 selectが選択肢から選ぶというのはどこから湧いてくるわけ? >>214 質問の意図がさっぱりわからない 話の流れとしては、設定ファイルがXMLのものはたいてい XMLを間違った方向に使ってしまってメリットが失われている これが話の発端 間違っているというのならどういう使い方が正しいのか? と聞かれたのでHTML(のフォーム)を参考にすれば良いと言った そのHTMLのselectがどういうものかはw3cとかが決めてるだろ もちろん参考でしかないのでXML設定ファイルを同じように する必要はないが、他のXMLベースのフォーマットと同じように 誰かが決めるだけの話しだろ それで、その質問は何が言いたいのだ? 俺はXMLベースの正しい使い方はどういったものであるべきかを説明しているだけなんだが? selectの細かい仕様とか誰が決めるのかとかどうでもいいよ。 そこはXML設定ファイルがどうあるべきかの話にとって本質的な部分ではない 要するに誰かがオレオレ仕様決めるだけか 何の意味があるのやら 要するに マークアップ良いじゃん。使いたい。メタデータあるし。 マークアップを解釈できるソフトで設定ファイルを管理しよう。 これを標準化しよう。ってことだろ。 こんなゆるい、どこまでも意味ない標準もないし、マークアップ縛りってだけの意味のない制限。 理解してほしい文章書くなら後出しジャンケンやめて、標準化したい仕様を書かないとなんにも伝わらん。 実装出すと、仕様出す、コンセプト出すが酔い順番で コンセプトが誰にも理解してもらえない時点でどうでもいい話だな >>216 何の意味って、最初に言ったとおり、 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>217 標準化しようじゃなくて 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>218 仕様を書く必要はないよ 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>219 世の中はXMLの使い方を間違ったよなーって話をしてるだけ お前が間違ってると主張する意味がわからんし オレオレ正しい正しい使い方もわからん >>221 テキストエディタでXMLの設定ファイルを編集しても面倒なだけだから かといってXMLの設定ファイルを持ってるアプリが設定ツールが あるかといえば無いだろう?設定ツールも作るのは大変だからね キーとバリューの使い方を間違えたんだよ。 たいていXML設定ファイルはこんな感じになってる https://help.adobe.com/ja_JP/air/build/WSEC63CD64-C52C-41ef-82FD-94E6B540A5FA.html <configuration xmlns="http://ns.adobe.com/air/framework/update/configuration/1.0" ;> <url>http://example.com/updates/update.xml< ;/url> <delay>1</delay> <defaultUI> <dialog name="checkForUpdate" visible="false" /> <dialog name="downloadUpdate" visible="false" /> <dialog name="downloadProgress" visible="false" /> </defaultUI> </configuration> こんなの独自のタグばっかりあるんじゃ汎用のツールで扱えるわけがない まあガリレオ並みの人物なら死後にでもやっぱり世間が間違ってた、あいつは凄い!ってなるやろハナホジー 今までと同じようにHTMLのタグを拝借して こういうふうに書くと汎用のツールで対応できる(実際ブラウザが出来てるわけだし) <form> <input type="text" name="url" value="http://example.com/updates/update.xml" ;> <input type="number" name="delay" value="1"> <fieldset name="defaultUI"> <input type="checkbox" name="checkForUpdate"> <input type="checkbox" name="downloadUpdate"> <input type="checkbox" name="downloadProgress"> </fieldset> </form> そして開発の初期段階は最初は簡単なフォームでいいし、 のちのち見栄えを整えたくなったらCSSなどを使えばいい。 だから最初からそう言ってる。 XML設定ファイルは、アプリが個々に要素を定義するんじゃなくて 共通の仕様を作るべきだったと そうすれば設定ツールは汎用のものを別に開発できて、 全てのXML設定ファイルをそのツールで設定でき 開発者も独自の設定ツールを作ることがなくて楽になってたんだよ。 GUI大嫌いって開発者でも、XML設定ファイルにするだけで テキストエディタでも設定できるし、設定ツールでも設定できるようになってた さらに作り込めば使いやすいUIを作れるし、多言語化もできてた だから間違った方向に進んだよなーって思ってるわけだよ。 特定目的設定XMLで表現できない項目が出てきたらどうすんだ >>227 > 特定目的設定XMLで表現できない項目が出てきたらどうすんだ 結論を先にいうとそういうのはないと思ってる 設定のしやすさは別として(後述するがこれは解決できる問題) どんな設定であっても、キーとバリューのリストで設定できる 例えば、Firefoxのabout:config の例 設定名: devtools.performance.timeline.hidden-markers 型: 文字列 値: ["Composite","CompositeForwardTransaction"] (JSON文字列かな?) このような単純なキーとバリューのリストで保存されている。 これを見る限り、型としては最低限、文字列、整数値、真偽値 があれば必要十分なのだろう まあJSON文字列とか卑怯な物使ってるからねw もう少し便利にするならば、レジストリを参考して「複数行文字列」「変数展開が可能な文字列」や キーバリューのリスト型みたいなものがあるといいだろう で、開発の初期段階であれば、どんなに複雑な項目であっても 最悪JSON形式の文字列でテキストエディタで保存すればOKということ。 JSON設定ファイルなんてものがあるんだから、それぐらい苦じゃないだろう?w でも、設定のしやすさの問題が残っている。エンドユーザーにとってはJSON文字列で設定するのは大変。 そこで出てくるのが・・・というかもったいぶって言うほどのことではなくウェブが すでにその問題を解決してる。CSSとJavaScriptでインターフェースを作ればいい。 そしてその値をフォームにマッピングする(例えばJSON形式で保存) 当然外部CSSとJavaScriptを使うため、設定ファイル自体はシンプルな状態を保つことができるし、 テキストエディタで編集したい人はそのまま編集できる。 それでいて設定ファイルをシームレスにユーザーインターフェースへとつなげることができる。 ウェブ技術の応用だからUIを作れる人は多いだろうし、なによりUIの作り込みは後からやれるから開発者の負担も減る 何でも設定できる汎用フォーマットに何でも設定できる汎用GUIという ありとあらゆる機能を詰め込んだ膨大な仕様、実装を要求してることに気が付かないのか >>229 ぜんぜん? だって>>224 を見てよ。 タグは使い方を変えただけ。本質的には今の使い方と変わらない 今までと同じようにテストエディタで編集できる それに加えて汎用の設定ツールの開発が可能になる。 設定ツールの仕様がブラウザ並みに大変になる思うかもしれないが、 CSSやJavaScriptはオプショナルに過ぎない。搭載は必須ではない。 ネスケ4とかガラケーやテキストブラウザレベルのものがあれば 設定ツールとして機能する。膨大でもなんでもない。 どうせ今だって複雑な項目をテキストエディタで編集してるんだろ? ならそこだけ諦めて <textarea>で編集すればいいだけだよ。 そして将来高機能な設定ツールが登場すれば、CSSとJavaScriptで リッチなUIが使えるようになるし、それがでるまでは テキストエディタやテキストブラウザ等で設定できる そして設定ツールは汎用なので独立して開発できる。 なにかアプリを作ったときエンドユーザーが簡単に使えるようにと アプリ開発者がオリジナルの設定ツールを作る必要はないわけだ。 重要なのは、テキストエディタで編集するのなら、 今のXML設定ファイルとほぼ同じ使い勝手でありながら、 将来的に拡張していけるということ、 今よりも悪くなっているところがなにもない 相当頭悪そうでまともにプログラム書いたこと無さそうなのがわかるので なんか実装見せてくれたら誰か相手してくれると思うよ 一言悪口を言わないと気がすまないようだなw 何かわからなかったら言えば説明するし、 わかったなら、そのことについてコメントしろよ。 なんで書いてあることをいつも見なかったことにして悪口だけ言うんだ? お前の言うことには中身がない。 頭悪そうに見えるのはお前の方だよ あなた人の指摘が理解できないでトンチンカンな持論くりかえすだけだからね だからこれ以上なにか言いたきゃ実装出せば 一連のXML、HTML君の言い分をまとめれば矛盾だらけだけど、矛盾を指摘するのがだるいから意味のあることだけまとめるね。 ・マークアップ言語を使って設定アプリを作れる。xmlは間違った進化してるけど、それはxmlの仕様を変えれば問題ない。 ってことだ。マークアップも一応プログラミング言語だからPC上でできることは何でもできる。っていうだけのことでしょ。 つまりおまえの言ってる標準は言語を使えばアプリを作れるってPCの誰でも知ってる標準にXMLと設定アプリを加えただけなんだが、 それ以上になにかあるのか?っていうこと。 >>123 から始まってるxml君の言いたいことはよくわからんが、 メタ情報の標準化はxmlに限らずオントロジーの作法を知らないからxmlの仕様がーとなるんだろ。 メタ情報を標準化しなくてもオントロジーを定義してrdfの仕様に沿えばメタ情報の解釈はできるんだけど知ってるのかな。 膨大なアプリじゃないと言い切るならどんなブラウザでもそのくらいはできるし大丈夫だよね。 >>236 お前がわかってないじゃんw XMLは何の略か知ってる? eXtensible Markup Languag 日本語にすると「拡張可能なマークアップ言語」 「拡張されたマークアップ言語」ではないんだよ。 拡張可能が意味する所は、拡張して使いましょうってこと。 XMLの仕様を変える?XMLの仕様のどこが問題なんだ? ODFなど様々なXMLベースの仕様が作れるほど拡張可能な素晴らしいマークアップ言語だろ ただ世の中XMLを間違った拡張をした独自の設定ファイル形式が多いってだけ それはXMLの仕様や進化とは関係ない。そもそもXMLの仕様はシンプルではずっと前から 安定していて、仕様を変える必要性もないほど柔軟で拡張可能に作られている 俺はXMLの仕様自体には文句をつけていない。アプリ独自の拡張方法に文句をつけてる 俺が言ってる意味ちゃんと理解できてる?XMLがどういうものかもわかってないでしょ? 君どうも知識が浅いよ。具体的じゃなくてどうとでも取れるようなことしか言ってない。 > マークアップも一応プログラミング言語だから ぜんぜん違う。チューリング完全であることはプログラミング言語に要求されることの一つだが、 マークアップ言語はチューリング完全ではない そういうポロッと素人レベルのことを漏らすから、知識浅いとわかる > PC上でできることは何でもできる。っていうだけのことでしょ。 そんな意味のないことは一言も言ってない。お前が理解してない証拠。 (俺が言ってることを理解出来ないが)きっと誰でもわかるようなことを言ってる違いないと お前が思って、誰でもわかるようなことを言ってる例として出しただけでしょ? >>237 何が言いたいの? 俺はXMLベースの設定ファイルの多くが間違った拡張をしてると言ってるだけ? で、お前は?オントロジー? XMLベースじゃなくても、頑張ればなんでもできるって 一般的な話をしてるだけ? 俺はそんな話はしてないよね。 変な所にはてながついちゃったw 俺はXMLベースの設定ファイルの多くが間違った拡張をしてると言ってるだけ 俺は今の現実を批判してるのであって、 お前みたいに存在しないものを作るなんて話はしてない 架空の世界の話はしてないんだよ > 膨大なアプリじゃないと言い切るならどんなブラウザでもそのくらいはできるし大丈夫だよね。 XMLベースならテキストエディタで変更できるんでー 大丈夫ですよーw 現実にはお前の理想とする設定ツール実装は存在しないんだろ? それは架空の話と言うんだよ だからテキストエディタで設定できるって(笑) 何度も言わせんなや ぼくのかんがえたさいきょうの設定はテキストエディタで何でも設定できるんだー!って何が凄い発想なのか >>240 >俺はXMLベースの設定ファイルの多くが間違った拡張をしてると言ってるだけ ここにみんなが突っ込んでるんじゃなくて(間違った拡張も主観的な主張だけど。)、 >XML設定ファイルは、アプリが個々に要素を定義するんじゃなくて >共通の仕様を作るべきだったと それは作りたい人が作ればよろしい。みんな使わないと思うが。 自由に拡張できるといい、他人の拡張を間違っているといい、しまいには共通の仕様を作れと言う。 文脈に矛盾が生じてるのに気がついていない。 ぼくのかんがえたさいきょうの汎用設定用XMLスキーマを策定すれば素晴らしい未来が訪れる、 ということらしいがスキーマの汎用性を高めれば仕様も実装も爆発し 制限すれば不便になりさいきょうでは無くなりそうだ。 ぼくちんの妄想の中ではいい感じに出来上がってるらしいのでサンプル実装はよ >>246 それの何処が矛盾してるんだ? ・XMLは拡張可能なマークアップ言語 ・いろんな人が拡張してるが、アプリ独自の設定ファイルは 間違った拡張をされている ・設定ファイル用のXML拡張の仕様を作れ やっぱり何も間違ってないな。 お前がXMLを理解してないから、矛盾に見えるんだろう? >>248 アプリ独自の設定ファイルがxmlで独自拡張が間違っている例を上げてください。 そしてそれがどのように間違っているかを示してください。 もしかしてスキーマを作ることを「XMLの拡張」なのかね >>252 それがわかるならオントロジーもrdfも理解しても良さそうなんだが。 >>250 XMLの拡張の意味も知らないで突っかかってきてるのかよw XMLの言葉の意味の通り 「eXtensible Markup Language」 「拡張可能なマークアップ言語」 XMLの拡張とは何を意味しているかは、 XMLの意味を調べればわかる(すでにこのスレに書いた) 俺が書いたことが信用出来ないならググれ、と言おうと思ったが、 仮にググったら、良い説明があったので以下を読め http://www.atmarkit.co.jp/aig/01xml/xml.html ↑にはどういう勘違いがあるかも書いてあるから、 XMLが本当はどういうものかがわかるぞw >>254 具体的に拡張するとは何を定義するか説明できるの? >>257 それ俺が質問してるんだわ XMLは何の略か知ってる? eXtensible Markup Languag 日本語にすると「拡張可能なマークアップ言語」 「拡張されたマークアップ言語」ではないんだよ。 おれがXMLとはなにか知ってる?と聞いてるのに 聞き返してるのは知らないってことなんかね? いつものことだがこういう輩は自分で説明すると (どこがも言わずに)それは違う。やっぱりわかってないって いうだけで逃げるので、ソースを出すことにしてる https://support.office.com/ja-jp/article/%E5%88%9D%E3%82%81%E3%81%A6%E3%81%AE-xml-a87d234d-4c2e-4409-9cbc-45e4eb857d44 XML タグを利用することで、自分が見ているデータの種類がはっきりわかります。 たとえば、それが猫に関するデータであることがわかります。猫の名前や年齢などを簡単に見つけられます。 ほとんどすべてのデータ構造を定義するタグを作成できることから、XML は "extensible (拡張可能)" と呼ばれています。 というか、調べればわかることをわざわざ書かせるのは 揚げ足取り目的だってわかってるからさぁ http://park18.wakwak.com/ ~little-box/xml_basic/1-002.htm >>238 なんかを見るとODFが「XMLの拡張」の例だとおもいこんでるようだけどあってるのかな? ODFを展開して出てくるXMLそれぞれが XMLを拡張(独自タグを定義したもの)になってる で、揚げ足取りは?w >>253 メタフォーマットであるXMLのフォーマットを決める、スキーマを定義する、ことにすぎないことを XMLの拡張なるものと思い込んでいて ぼくのかんがえたさいきょうの設定ファイルに適したオレオレスキーマを定義することを設定向けXML拡張と呼んでるらしい。 スキーマを定めることでフォーマットが固定されるのに 「拡張」という言葉を使うことでなんでも自在な機能が持てると 妄想も拡張しているようだ。 ? メタフォーマットであるXMLのフォーマットを決める、スキーマを定義する、ことにすぎないことを XMLの拡張というんですよ? なんだろう?最もすごいものじゃないと拡張と言っちゃいけないとでも思ってたの? へんだなぁ。俺じゃなくて XML(eXtensible Markup Language)という名前をつけた人に 言うべきことでしょう? XMLは拡張可能なマークアップ言語ですよ? なんでも自在な機能がもてるとか誰が言ったんですかねぇ。 俺「XMLとは拡張可能なマークアップ言語です」 馬鹿「拡張といったな?」 俺「言ったけど?」 馬鹿「ぼくのかんがえたさいきょうの設定ファイルってことだな?」 俺「(そんなことなにもいってないけど?)」 馬鹿「スキーマを定義することにすぎないことをXMLの拡張なるものと思い込んでるな?」 俺「(そのとおりだろ?) 馬鹿「XMLの拡張というものは・・・・そのとおりだ」 俺「(思い込んみは間違いだ!って言うんじゃないのかよ?)」 馬鹿「拡張という言葉を使うと自在な機能を持ってると思ってるな?」 俺「(何言い出してるんだろうこいつ?)」 馬鹿「妄想も拡張しているようだ。」 俺「(それ言い出したの全部お前じゃん) あー、>>267 が言いたいことがわかったわw XMLを拡張して作るXMLベースの設定ファイルのスキーマ 今のアプリの設定ファイルが間違ってると言ったろ? >>267 はその間違ったXMLベースの設定ファイルに 基づいて発言してる。 つまり>>267 は、アプリケーション固有のスキーマを作る話をしてるから スキーマを定義すると、アプリケーションを機能追加(拡張?)できなくなると言ってる。 あほやな。いや、大部分のXMLベースの設定ファイルは アプリケーション固有のスキーマを作ってるから、 >>267 も含めてみんな間違ってるなーっていうことか 汎用のXML設定ファイルっていうのは(どういうものかは上に書いたので探せ) アプリケーション固有ではなく、スキーマを定めたところで、 アプリケーションの機能追加を妨げるものじゃない 固定するのは設定ファイルのスキーマだけ そのスキーマにはアプリケーション固有のスキーマ定義はないから アプリケーションは自由に「拡張」できる。 だいたいHTMLを参考にしてる点で気づかんかな? HTMLなんかスキーマが定められてフォーマットが固定されてるのに いろんなサイトやウェブサービスが作れるだろと 自在な機能を持つ能力は無いが任意のアプリ固有の機能追加できる アプリ固有のスキーマは無いので好き勝手定義できるけど汎用の設定ツールを作成して設定できる この短い中でこんな滅茶苦茶なこと言う奴も珍しいなあ >>273 えとさぁ、お前、設定ファイルの話とアプリの機能をごっちゃにするの止めたら? 馬鹿らしい。 設定ファイルの形式なんて、レジストリとか見れば、固定でいいってわかるだろ。 固定っていうのは(最低限)キーとバリューの組み合わせが保存できればいいってこと どうせお前は馬鹿だから、キーの名前を固定にするのと ごっちゃにしてるんだろうけどなw ともかく、HTMLのフォームが、inputとselectとtextareaとグループ分け程度の 少ないスキーマ定義で、実際にいろんなウェブサービスに 対応できてるんだから、現実を受け入れようね? どうも齟齬があるなあと思ったら「設定を記録するのに必要なスキーマの」機能の話を アプリの機能と勝手に思い込んでるわけね オレオレさいきょうキーバリューだかなんだかしらないXMLを作成したいって話か?そんな低レベルの話? オレオレ設定XMLじゃ困る人は切り捨てりゃいいなら楽だよなあ キーバリューの話しかできないならなんでこいつはXMLにこだわってるのか謎 また>>220 をコピペすればいい? >>216 何の意味って、最初に言ったとおり、 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>217 標準化しようじゃなくて 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>218 仕様を書く必要はないよ 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>219 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>275 俺は最初から、設定を記録するのに必要なスキーマの話しかしてない 世の中のアプリは、アプリ固有のオレオレスキーマを作成して 単に編集しにくいだけで、XMLを使用する意味をなくしてしまってる。 世の中はXMLの使い方を間違ったよなーって話をしてるだけ キーバリューならCSVで十分だ運動すれば? あと多彩なWebサービスの話はinputとかフォームに関係ない部分だから わかってないことは使わない方がいいぞ(あとHTMLはXMLじゃないのはいいのだろうか) そして馬鹿は極端だから、 「固定っていうのは(最低限)キーとバリューの組み合わせが保存できればいいってこと」 と書いていても、(最低限)の部分を もうすっかり忘れているwww >>279 設定を記録するXMLと他のデータを記録するXMLを混合できるXMLなんて誰も話してないと思うがね ところで設定ファイルの設計ミスした具体的アプリ名とかないの? >>280 CSVだったら入力インターフェースが作れない 設定の値しか書いてないから、設定が取りうる値などがわからない 例えば、sambaのmap to guestという項目は「Never」「Bad User」「Bad Password」の いずれかの値を入れることができるが、そのことが設定ファイルには書かれていない (コメントとして書かれている場合があるかもしれないぐらい) 設定ファイルでありながらHTMLのフォームと同じような スキーマを採用することで、設定ツールを作ることが可能になる あー、何度言えば良いんだろうw スキーマにはアプリ固有のものは含まれないから、 HTMLが、まさにHTMLがそうしているように、 汎用の設定ツールで設定が可能になる。 アプリ開発者は単に設定ファイルにHTMLフォームライクな XMLを拡張して作った汎用のXML設定ファイルを採用するだけ アプリ開発者は設定ツールを作ること無く、 初心者は汎用の設定ツールを使って設定できるようになる。 何度言えば理解しますかね? >>283 >>216 何の意味って、最初に言ったとおり、 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>217 標準化しようじゃなくて 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>218 仕様を書く必要はないよ 世の中はXMLの使い方を間違ったよなーって話をしてるだけ 今の設定ファイルはコメントで、設定方法が書かれているが、 まあこれがまさにテキストエディタ用のインターフェースなわけだが 設定値のみ書かれていればいいならコメントは要らない コメントはまさにテキストエディタで編集する人が 読むためのもの でも設定ファイルのコメントは英語でしか書かれていない。翻訳の仕組みがないからだ。 あるとすれば設定ファイルにずらーっと何カ国後もコメント書くぐらいだなw こういう問題も、まともなXML設定ファイルを作れば多言語対応も可能になるだろう HTMLがブラウザが設定入力インターフェイスだというなら ExcelはCSVの入力インターフェイスだと主張できるなあ しかもHTMLは選択肢がつくれる HTMLがブラウザが設定入力インターフェイスだというなら ExcelはCSVの入力インターフェイスだと主張できるなあ しかもHTMLは選択肢がつくれると言ってんのはデータはどこに入れるの? そしてお前のさいき HTMLがブラウザが設定入力インターフェイスだというなら ExcelはCSVの入力インターフェイスだと主張できるなあ しかもHTMLは選択肢がつくれると言ってんのはデータはどこに入れるの? そしてお前のさいきょうXMLで表現できない設定記述機能要望(アプリの機能じゃねえぞ)はどうするの? 例えば、sambaのmap to guestという項目は「Never」「Bad User」「Bad Password」の いずれかの値を入れることができるが、そのことが設定ファイルには書かれていない いやコメントでこう書かれているかもしれない # ○○をするための項目です(という英語) # 「Never」「Bad User」「Bad Password」のいずれかの値を入れられます。 # デフォルトは「Never」です。 map to guest=Never というものが書いてあってもここから設定ツールは作れない CSV形式でも設定ツールは作れない。 HTMLのフォームライクなXML設定ファイルにすれば設定ツールを作れる <label for="map-to-guest" >"○○をするための項目です(という英語)</label> <select id="map-to-guest" name="map to guest"> <option selected default>Never</option> <option>Bad User</option> <option>Bad Password</option> </select> この中には設定値、設定の候補、デフォルト値が含まれている。 今までどおりテキストエディタで編集もできる > そしてお前のさいきょうXMLで表現できない設定記述機能要望(アプリの機能じゃねえぞ)はどうするの? ない >>289 CSVだったら入力インターフェイスが作れないという文章どこに行った >>294 あ、その事(笑) ExcelでCSV編集しても、値しか入れられないだろ。 取りうる値なんかわからない >>293 えっ?世の中数百万以上のアプリがあってこれからも生み出されるのになんで無いって言えるの? >>296 アプリの機能じゃねえぞ どんなアプリが増えようが、設定はすべて キーとバリューだけで表現できる (便利だと思うならその他の形式をいくつか増やしてもいいが) ほんとなぁ、設定の値の話をしてるのに 結局、ID:3OE6BV46 自身が、アプリの種類が増えたらどうするの? なんて言ってるんだもんなぁw アプリの機能を気にしてるのはお前じゃん >>292 それどこかのアホが <option selected default>ほげ</option> とか書くのどーやって防ぐの? >>297 アプリが未来永劫設定項目の記録表現としてさいきょうの設定XMLでは 不十分だと言うとこは無いとどうやって証明したのですか? >>299 え?テキストエディタを使った場合の話? アプリ独自にテキスト形式で、map to guestをmap to guestoooooと書くのを防ぐ方法あるんですか? CSV形式で、以下同文 テキストエディタを使っている以上不可能でしょw そんなの当たり前。 だから設定ツールが重要になるわけですが? でもアプリ独自のテキスト形式やcsv形式だと、その設定ツールを アプリごとに作らなければいけない あぁ、無駄無駄。時間の無駄 HTMLのフォームライクなXML設定ファイルなら、 その設定ツールで間違った値を設定することはありませんね。 そして汎用で使えるから、アプリ開発者の負担が減りますね。 今のXMLはアプリ固有のスキーマになって、汎用の設定ツールなんか 作れないから、世の中はXMLの使い方を間違ったよなーって話をしてるだけ 設定記述機能の話しかしてねえのに アプリ本体機能と勘違いしてる馬鹿がいるんだと 必死で藁人形打つのやめろよなあ >>300 バイナリデータを含む全てのデータは、 エンコードすることで、テキスト文字列で表現可能だから (必ずしもそうしろと言ってるわけじゃない) >>302 それお前なw アプリがどんな機能を持ってようが 設定は(最低限)キーとバリューの組み合わせが保存できれば十分 >>304 証明どころか実装がある。 Base64はどんなバイナリデータであっても テキスト文字列に変換できる >>305 設定表現にはキーバリューで必要十分なのか他に表現が必要なのか 他に必要なら必要十分な範囲は決められるのか 決められないのか適当に逃げ回るなよ >>307 頭が悪いなw バイナリデータをテキスト文字列に変換できるのなら、 お前が不安に思ってる、どんな表現であっても 単一のテキスト文字列に変換できるってことだよ >>306 お前のさいきょう設定XMLで全てのアプリの設定記述要望を満たす 証明はあるのかと聞いたんだよ 誰かがバイナリのアスキー表現の話してるんだよ。答えられないのわかるけどさ。 JSONなんか、文字列、数値、真偽値、配列、連想配列 たったこれだけのもので、どんな複雑なものでも表現できるからな。 一体何が表現不可能だと思ってるのか わけがわからない >>309 やっぱりさ、お前 まーた、アプリ固有のスキーマの話してるだろw アプリ固有のものなんて無いんだから、 どんなアプリのものだって対応可能 いい加減アプリの機能と設定をごっちゃにするの止めたら? >>310 質問はお前のさいきょう設定XMLで全てのアプリの 設定記述機能を満たす証明はあるのか?です 関係ない話に逃げるのはやめましょう >>311 そういう勘違いしてる人に仕立て上げたい気持ちはわかる(笑) >>312 なんで実装があるのに証明にこだわってるの? Base64でエンコードすれば、どんな設定だって 文字列で保存できるじゃん >>314 テキストファイルとテキストエディタがあればどんな設定でも記述できるという主張かね? 元の証明はできないということだね。理解できてなさそだけど。 >>313 だって>>312 でまた「全ての」アプリの設定記述を満たすものがあるのかとか言ってるじゃん つまり「一部の」アプリ設定記述を満たすものはあるって 納得してるんでしょ? そして「一部」に含まれない、もっと別の高度なアプリの機能の 設定記述を満たすものはあるのかー!!!って アプリの機能を気にしてるじゃんw >>315 > テキストファイルとテキストエディタがあればどんな設定でも記述できるという主張かね? そりゃそうだろうね 使いやすいかどうかは別として 最初からそう言ってるんだが。 どんな設定だろうが、テキストに変換できる以上 テキストエディタで編集は可能。 ただし便利なインターフェースを作るためには 設定値だけでは無理。 メタ情報が必要。XML設定ファイルであれば そういうメタ情報を入れることはたやすいが、 世の中間違って使い方をして、独自のXML設定ファイルばっかり作るから 汎用の設定ツールを作ることができない 今日はあと一時間切ったぞ。 100レスまであと45もあるじゃないか >>228 ですでに書いたこと(わざとなのか知らんが、すでに答えたことを繰り返されるのは面倒だ) > 特定目的設定XMLで表現できない項目が出てきたらどうすんだ 結論を先にいうとそういうのはないと思ってる 設定のしやすさは別として(後述するがこれは解決できる問題) どんな設定であっても、キーとバリューのリストで設定できる 例えば、Firefoxのabout:config の例 設定名: devtools.performance.timeline.hidden-markers 型: 文字列 値: ["Composite","CompositeForwardTransaction"] (JSON文字列かな?) このような単純なキーとバリューのリストで保存されている。 これを見る限り、型としては最低限、文字列、整数値、真偽値 があれば必要十分なのだろう まあJSON文字列とか卑怯な物使ってるからねw もう少し便利にするならば、レジストリを参考して「複数行文字列」「変数展開が可能な文字列」や キーバリューのリスト型みたいなものがあるといいだろう で、開発の初期段階であれば、どんなに複雑な項目であっても 最悪JSON形式の文字列でテキストエディタで保存すればOKということ。 JSON設定ファイルなんてものがあるんだから、それぐらい苦じゃないだろう?w でも、設定のしやすさの問題が残っている。エンドユーザーにとってはJSON文字列で設定するのは大変。 そこで出てくるのが・・・というかもったいぶって言うほどのことではなくウェブが すでにその問題を解決してる。CSSとJavaScriptでインターフェースを作ればいい。 そしてその値をフォームにマッピングする(例えばJSON形式で保存) 当然外部CSSとJavaScriptを使うため、設定ファイル自体はシンプルな状態を保つことができるし、 テキストエディタで編集したい人はそのまま編集できる。 それでいて設定ファイルをシームレスにユーザーインターフェースへとつなげることができる。 ウェブ技術の応用だからUIを作れる人は多いだろうし、なによりUIの作り込みは後からやれるから開発者の負担も減る 俺は面倒だから、基本的にIDを見てないんだが、 みてみたら同じやつじゃんw なんで繰り返しおんなじ質問するのかね? 言い方を変えてもいいな どんな荒唐無稽な設定データを想像してるのか知らんが、 テキスト形式の設定ファイルでは設定できないデータが あるというのなら諦めればいいだけだろう。 バイナリデータでさえBase64で保存できるというのに それがどんなものが設定ファイルに書けないのか、 俺にはわからんが、それは諦めるという方向でいい。 で、諦めなければならないもの例をあげてくれ。 俺には全く思いつかない。まあ無いんだろう。 そういや今はCSSファイル(当然テキスト形式)に 画像データをBase64エンコードして入れられることを思い出した。 おとなしくなったようなので、続き(?)を 汎用のXML設定ファイル形式(おれのかんがえたさいきょうってやつw)は、 HTMLのフォームを参考にすれば良いと言ったが、欠点もある そこはHTMLフォームを厳守しろっとは言ってないので変えればいいだけだが、 リストやハッシュデータの扱いが難しい。もちろんできないわけじゃない。 PHPやRubyはフォームの名前を工夫することでリストやハッシュを表現している 例えばこんな感じだ <form> 名前:<input type="text" name="personal[name]"> 住所:<input type="text" name="personal[address]"> 電話:<input type="text" name="personal[telephone]"> </form> これで少なくともJSONなみの表現力は得られるわけだがやっぱりダサいと思う <form> <fieldset name="personal"> 名前:<input type="text" name="name"> 住所:<input type="text" name="address"> 電話:<input type="text" name="telephone"> </fieldset> </form> こんな感じで直感的な仕様にしたほうが良いだろうな >>267 こんなひどいストローマン久しぶりに見たわwww 「xmlの拡張」の文節はどうとでも解釈できるのに最終的にスキーマを新しく作るってことを「xmlの拡張」と呼ぶらしいぞwwww 普通、「xml(の言語仕様)の拡張」と受け取るよな。 で、間違ったxml使ったアプリの例はいつ出してくれんだろう。 具体的なアプリ名はスレのどこにもなさそうだけど。 ていうか、文章能力なさすぎだろ、間違ったxmlって同じ属性が2つ書かれてるとかぐらいしか思いつかないけど、なにを指してるんだろ。 あとjsonの例は、xmlが文章以外にもデータ記述子として使われることもあるので、設定ファイルに置いてjsonと比較されるのはなんの不思議でもない。 設定ファイルに直接コメント書きたいらしいが、ドキュメント書いてくれればなんの問題もない。 一つのファイルに書くことがそんなに重要ならテキストファイルの中にjson書いて、jsonだけ受け取れば十分だろ。 >>323 まあ全体的に ID:3OE6BV46 は何を言ってるのかよくわからんよ。 わかってないからいろいろごっちゃにして勘違いしてるんだろうさ。 XMLの拡張、なにがいいたかったんだろうね 俺は、XMLは eXtensible Markup Language(拡張可能なマークアップ言語)の 略だと言っただけなんだよね。だからこの文脈では名前に入ってる「拡張可能」の 意味で解釈してもらわないと XMLを拡張してXML 2.0を作るとか言う話じゃなくて そもそもがXMLは拡張可能なマークアップ言語として作られたものなんだよって 話をしてるだけなんだが、基本がわかってないからいつもずれてしまって話が通じない。 XMLは言語を記述するための言語とも言われてるね ってかお前か、いつものキチガイw まーた、わざとらしい間違いしてくるし、 俺が、XMLの間違った使い方といったら、 お前は、XMLの文法ミスのことなんだって まーた間違えるし、本当に話が通じない 説明済みのことを何度も聞いてくる > で、間違ったxml使ったアプリの例はいつ出してくれんだろう。 間違ってないXMLベースの設定ファイルを使ってるアプリなんて存在しないよ。 > 設定ファイルに直接コメント書きたいらしいが、 はい、また。そんなこと言ってない。 > ドキュメント書いてくれればなんの問題もない。 ドキュメントは設定ツールとして生かせない > 一つのファイルに書くことがそんなに重要なら はい、また、そんな事も言ってない > テキストファイルの中にjson書いて、jsonだけ受け取れば十分だろ。 jsonでは機能不足だってすでに説明済み ほんとなーずーっとXMLベースの汎用的なXMLスキーマを作って、 設定ツールで設定するという話をしてるだろうに一体いつになったら 嘘吐くのやめてくれるんだろう? 俺が言ったことにして、話を混乱させてる こいつの設定XMLでできないことは無いと断言しながら できないことがあったら諦めろとかどんな神経したら書けるんだろうな バイナリバイナリってバリューの話だけでデータ構造の話は出てこないのか(笑) >>327 敵味方の二元論しか受け取れないのやばいけど、レスの内容が理解できてないから勘違いするんだ。 ちゃんと読めよ。 >>330 > こいつの設定XMLでできないことは無いと断言しながら > できないことがあったら諦めろとかどんな神経したら書けるんだろうな また、嘘書いてる。 そんなことは一言も言ってません。 もし本当にできないことがあるというのなら諦めるよ? だからできないことがあるというのなら、言ってみろ まああるわけないけどね、って書いてるんだ。 >>328 >XMLの間違った使い方 >>248 >アプリ独自の設定ファイルは間違った拡張をされている 表記ゆれが紛らわしいんだが、これらは同じ意味か?文法ミス以外で言語で間違うってなに? それは主観的な間違いなんじゃないの?間違いと感じただけ? >>331 > バイナリバイナリってバリューの話だけでデータ構造の話は出てこないのか(笑) それも>>322 で書いた。 いくら俺がいないすきを狙って、嘘をついても、 こうやってばれるんだからいみないよ? >>334 ほんとお前に日本語の読解力がないのなw 道具の間違った使い方だっていってんだろう 設定ファイルをXMLにする意味がないから、間違った使い方 >>336 「XMLの間違った使い方」って書いてたのを「道具の間違った使い方」って書いてたことにするのか? XMLは物理的な道具じゃないからXMLをなにかの道具に例えたんだな。さあ、教えてくれ、XMLはなんの道具なんだい? ちなみに「道具の間違った使い方」の文節は初めて出てきたよ。びっくりだよ。 >>337 このレスは君のレスかい? >>919 >HTML風XMLの設定ファイルは開発者が作成するもの 君はXMLを設定ファイルにするのは諦めたってことかい? アプリの設定ファイルをXMLにされるのはおかしいと思ってたから伝わっているならそれが何よりだよ。 お前らが熱い討論してる間、俺は洪水の電柱が危険だということを知ったから、お前らにも教えといてやるよ https://gfycat.com/gifs/detail/unacceptableangryfossa お前らも有事には気をつけろよ >>338 道具と言われて、物理的なもの限定って思うのか・・・ Officeソフトは道具じゃないんですねーw ほんと日本語のレベルであやしいや >>339 > >HTML風XMLの設定ファイルは開発者が作成するもの > 君はXMLを設定ファイルにするのは諦めたってことかい? HTML風XMLは、XMLだろ・・・ 和風ハンバーグはハンバーグじゃないっていう理論か? 日本語のレベルで(ry あれでもおかしいぞ〜。 >設定ファイルをXMLにする意味がないから、間違った使い方 って意味なら >間違った拡張 の拡張の意味が浮いちゃうな〜。拡張はxmlの<拡張可能な>から取ってきたんじゃなかったんだっけ? 表記ゆれが激しくて、それぞれが突っ込まれると微妙に違うことを言ってるから矛盾してきちゃったな〜。 単純に >アプリ独自の設定ファイルは間違った拡張をされている >設定ファイルをXMLにする意味がないから、間違った使い方 が同じ意味だと思っているなら文章能力も読解力もないって言われて当然。 普通になにを言ってるかなぞ。せめて訂正とかしてほしい。 >>340 > アプリの設定ファイルをXMLにされるのはおかしいと思ってたから伝わっているならそれが何よりだよ。 別にアプリの設定ファイルがXMLでも問題ない。 ただXMLにするメリットがない使い方ばっかりされてる 他の形式に比べて冗長なのは言うまでもなくわかってること その冗長さを上回るメリットを見つけていない 汎用的なXML設定ファイルのスキーマ (HTML風のXML、どういうものかは上の方に具体的に何回も書いた) を作れば、XML設定ファイルは大きなメリットを得られる 具体的には、汎用の設定ツールで設定可能になる。 アプリ開発者がわざわざ手間ひまかけて設定ツールを作る必要がなくなる。 アプリ開発者はXML設定ファイルを選ぶだけで恩恵が得られる ユーザーも難解な設定ファイルをテキストエディタで間違えないように 修正する必要がなくなる。GUIから簡単に設定できるようになる 作り込めば、より便利なインターフェースを作ることもできる それでいながら、初期段階はテキストエディタで簡単に修正することもできる もう何度同じことを言っただろうか? xmlくんはなにが言いたいのやらさっぱりわからん。 >>343 officeは文章作成のための道具だろ? xmlはなんの道具だよ? >>344 だから「拡張可能」の拡張だって何度も言ってるだろ そして、お前は自分でXMLをベースとして新しいタグを作ることが 拡張だって理解したはずだよな? > ODFなど様々なXMLベースの仕様が作れるほど拡張可能な素晴らしいマークアップ言語だろ > ただ世の中XMLを間違った拡張をした独自の設定ファイル形式が多いってだけ ↑ 世の中のアプリは独自でタグを作りまくってるから、それが間違った拡張だと 最初からずーっと書いてある。 >>346 > xmlはなんの道具だよ? マークアップ言語を作るための道具 拡張可能という意味を持つXMLが可能な 拡張を行って独自のタグ(スキーマ)を作るための道具 いいか!みんな!!xmlくんは「間違い」ってことを >別にアプリの設定ファイルがXMLでも問題ない。ただXMLにするメリットがない使い方ばっかりされてる と表現し直した! >設定ファイルをXMLにする意味がないから、間違った使い方 >アプリ独自の設定ファイルは間違った拡張をされている >設定ファイルをXMLにする意味がないから、間違った使い方 と散々意味不明な言い分で「間違った」と言っておきながら「メリットがない」と変更した。 これが典型的なストローマン論法だ。「間違った」と「メリットがない」が内を平気で混同する主観的な主張を繰り返してるだけだ。 これ以上価値のないレスをするな。 こいつはXMLはタグでデータ構造を作るってだけで、 タグの種類は定義されてないってことも知らないんじゃないだろうか? みんなXMLを使ってなにかのデータ構造を作るときは XMLを拡張して使ってるんですよ? >>350 ん? 確かにより適切な意味に変更したが? 違う意味に変更したわけじゃないから問題ないだろ なに重箱の隅ばかりついてるんだよw その行為に意味はないぞ。 > と散々意味不明な言い分で「間違った」と言っておきながら「メリットがない」と変更した。 メリットが無いから間違った使い方だって書いたろ? やっぱり日本語の時点でおかしいんだよな。 権力のある人が他人の作ったアプリの構造の「メリットがない」と「間違った」を言い間違えたら訴訟レベルだな。 >>352 >>353 その理論は流石にゴリ押しできないぞ。素直に訂正といえばいいのにw >>348 さっぱりわかんないぞ。officeはアプリでツールで道具だけど、XMLは言語だろ。XMLはXMLのための道具なのか? なんで「メリットがない」と「間違った使い方」をごっちゃにしてるんだろう? 根拠と結論の関係なんだが? まあここでネタバレすると ID:rkXy/Ofn がやってるのは議論じゃない 俺への攻撃だ。 この指摘だけでも、読む価値がないとわかるだろう? XMLが文章のための道具とかXMLがデータ交換のための道具とかXMLがフィードのための道具って言うならわかるけど、 XMLはマークアップ言語のための道具ですか、理解に苦しむわ。 >>355 > XMLはXMLのための道具なのか? はい、もう10回目ぐらいかな? そんな事は言っていない XMLは言語を作るための言語 http://www.atmarkit.co.jp/ait/articles/0012/23/news002.html > XMLを用いて新しい言語を作る場合 http://www.atmarkit.co.jp/ait/articles/0005/22/news009.html > XMLはメタ言語である。メタ言語とは、言語を記述するための言語という意味である。 http://park18.wakwak.com/ ~little-box/xml_basic/1-002.htm > XMLは、"何をどう表現するか自由に定義できることから、"住所録用のXML"、"Webページ用のXML"、 > "論文用のXML"といったように、新しい言語を作ることができます。 https://www.milk-island.net/document/xml/kihon/b1/ > XMLとは言語を作るための言語。 >>357 お前が理解できてないだけだよw >>358 を読んで反省したら? >>356 攻撃じゃない。アホだからからかってやろうとも思ってるけど、 さんざん「間違い」って言ってきたやり取りを、いきなり「メリットがない」に変えたら、今までのやり取りの意味がなくなる。 もっと言えば、「メリットがない」ってことを「間違い」って書いてたらそりゃ意味が通じるわけがないでしょってこと。受けての問題じゃない、発信側の問題。 https://www.ibm.com/support/knowledgecenter/ja/ssw_i5_54/rzakl/rzaklintro.htm > XML を使えば、名前、肩書き、住所、郵便番号などのように特定の必要に応じた方法で > 情報を記述する一連の規則やタグを含む独自のマークアップ言語を作ることができます。 http://www.techscore.com/tech/XML/Basic/Basic1/1_1.html/ > ひとつめの特徴は、SGMLが「言語を作る言語」、メタ言語と呼ばれるものであることです。 > SGMLそのものは、言語ではありません。SGMLにより、ユーザの環境に合わせた”フォーマット”を > 作成することができます。 > HTMLはSGMLにより作成された、代表的な言語です。 http://www.techscore.com/tech/XML/Basic/Basic1/1_1-2.html/ > XMLはインターネットの標準としてW3C(*1)より勧告されたメタ言語です。SGMLをよりシンプルに、 > 利用しやすく発展させたものが、XMLです。XMLは、SGMLの2つの特徴 (「メタ言語、マークアップ言語)で > あることを受け継いたため、インターネット上でのデータ交換に非常に適した技術であるといわれています。 >>360 > さんざん「間違い」って言ってきたやり取りを、いきなり「メリットがない」に変えたら、今までのやり取りの意味がなくなる。 だから、メリットが無いから間違いだって言ってる。 間違いを撤回などしてない 正しくは「XMLにするメリットが無い」から「XMLの間違った使い方」 だと言ってる。 こいつは中途半端に文章をぶった切って 違う意味にしようとするからな。用心のため 「メリットが無いから間違い」この命題は間違ってるだろ。論理性のかけらもないだろ? クソめんどくさい。 もう寝るからxmlについて重大な誤解をしてるxmlくんに忠告だけど、 xmlスキーマは名前空間を定義しないとタグが重複するから定義するだけで、重複がない独自タグをアプリ内で使うのは自由。 独自タグを使っただけで間違いとは言えない。独自タグを使うメリットはアプリ独自の解釈ができるからでこれも間違い。 主張は間違ってる。 ちなみに名前空間の設定だけでは他のアプリが解釈できるわけじゃないから、スキーマに加えてオントロジーを定義する。 これでやっと独自タグが他のアプリからも読める。(アプリがオントロジーとスキーマを参照して機能を割り当てることによって。) でも設定ファイルは特定のアプリから読むだけだから不要。 話の発端の設定ファイルを編集する汎用ソフトはめんどくさいし不要。 誰一人、設定ファイルのためだけにxmlスキーマもオントロジーの定義もしない。そのほうが面倒くさいからだ。 >>365 > 独自タグを使っただけで間違いとは言えない XMLの文法的に正しいか間違っているかの話なんかしてない 設定ファイルにアプリ独自のタグを量産するのは XMLの間違った「使い方」だって言ってるの 使い方の話 やっぱりまた日本が通じない >>365-366 は意味不明なことを言ってるから誰も理解できないと思う だから代わりに俺が言ってることをまとめよう。 今のアプリでよく行われてるようにXMLを独自で拡張して オレオレタグを作るというやり方は間違ったXMLの使い方 なぜならそんなことをしてもメリットがなにもないからだ。 XMLを拡張して汎用的な新しい言語を作れば、 汎用の(例えばGUIの)設定ツールを作ることができる そうすれば、ユーザーは設定が簡単になるし、アプリ開発者はいちいち自分のアプリのために 設定ツールを作らなくてすむし、それでいて今までどおりテキストエディタで編集も可能 >>222 と >>224 に、今の間違った使い方と、あるべき使い方の例を書いておいた >>292 にも別のパターンを書いた。 >>228 ではどんなデータでもこれで扱えるという話、そしてUIの作り方を書いた。 >>322 ではリスト構造、ハッシュ構造を作る方法を書いた 222の間違った使い方では、アプリごとに独自のタグを作るから、どうしても汎用の設定ツールが作れない せいぜいXMLエディタというXMLの形で編集するツールが作れるぐらいだ。それは何も使いやすくない 224の例からは、アプリごとの独自のタグはない事、独自のタグの名前がname属性になっていることが読み取れるだろう 292の例では何が選択可能で、今どんな値が設定されていて、デフォルトの値が何かが 設置ファイルにかかれており、それを汎用の設定ツールから読み取ることができる 独自のタグを作っていたらこんな事はできない。 なにか意見を言うのなら、ここまで具体的に書いてほしいものだ とりあえず掲示板の使い方間違えるのやめてほしいな。 >>369 良い皮肉だ。 やつなら、掲示板に文法ミスでもあるんですかーとかいいそうw 書き込めるならどんな使い方でも、正しい使い方ですってな。 xmlくんは自分への皮肉を他人への皮肉だと受け取った模様。 まあXMLくんは抽象論ばかりじゃ嫌になるだろうから具体論として とりあえずsmb.conf、DNSゾーンファイル 、cron、bashrcぐらいを さいきょうの設定XMLで書き直してどれぐらい便利かアピールしてくれよ 他にもミスしやすいシリアル値を自動入力できるようになる cronだと日本人には分かりづらい日時の並び順を 分かりやすくすることができる barshrcは設定ファイルでなくスクリプト。引っ掛けかな?w まあスクリプトでもtextariaを使うことはできるし シンタックスハイライトぐらいやれるだろう XMLを見せて欲しいと書いたんですよ? UIじゃない。 smbも一項目じゃなくてそれなりに動きそうなもの示してくださいよ。 >>378 引っ掛け問題のつもりはないですがどんなソフトの設定ファイルてもかけると豪語してるのだから bashrcが書けないとは思えないので設定XMLのサンプルよろしく。 >>381 <textarea> ここに好きなbashrcのコードを書け </textarea> >>377 であればこんな感じかな <table> <tr><th>ホスト名</th><th>タイプ</th>・・・</tr> <tr> <td><input type="input" name="hostname1"></td> <td><select name="type1"><option>A</option><option>MX</option></td> ・・・ </tr> <tr> <td><input type="input" name="hostname2"></td> <td><select name="type2"><option>A</option><option>MX</option></td> ・・・ </tr> </table> ただこれには問題がある。それは<option>の部分が重複しているということ これはHTML5のdatalistを参考にしてselectで使用すれば一応解決できる <datalist id="types"> <option>A</option> <option>MX</option> </datalist> <table> <tr><th>ホスト名</th><th>タイプ</th>・・・</tr> <tr> <td><input type="input" name="hostname1" /></td> <td><select name="type1" list="types" /></td> ・・・ </tr> <tr> <td><input type="input" name="hostname2" /></td> <td><select name="type2" list="types" /></td> ・・・ </tr> </table> ただまだ冗長さは感じる。やはり配列型が必要だろうか inputのtype、いっその事タグにしたほうが良いかもしれない HTML5でも大して数があるわけじゃないし というか間違ってたなw type="input" じゃなくて type="text" だ ついでに値も入れてみる。ここもHTMLとは違う方法にする <datalist id="types"> <option>A</option> <option>MX</option> </datalist> <table> <tr><th>ホスト名</th><th>タイプ</th>・・・</tr> <tr> <td><text name="hostname1">www.example.com</text></td> <td><select name="type1" list="types">A</select></td> ・・・ </tr> <tr> <td><text name="hostname2">mx.example.com</text></td> <td><select name="type2" list="types">MX</select></td> ・・・ </tr> </table> >>382 久しぶりにこんなひどいウンコードみたwwwww <datalist id="types"> <option>A</option> <option>MX</option> </datalist> <table name="records"> <thead><tr><th>ホスト名</th><th>タイプ</th>・・・</tr></thead> <tr> <td><text name="hostname">www.example.com</text></td> <td><select name="type" list="types">A</select></td> ・・・ </tr> <tr> <td><text name="hostname">mx.example.com</text></td> <td><select name="type" list="types">MX</select></td> ・・・ </tr> </table> 配列型を考えてみた、table要素だとtbody(省略可能)以下のtrが自動的に配列となる) データとして取り出すと、以下のように見える records:[ { hostname: 'www.example.com', type: 'A' }, { hostname: 'mx.example.com', type: 'MX' }, ] >>386 bashrcの中身見たことある? こんなコードだよ。設定じゃない。 そんなこともわからないレベルなんだろうなーとしか思わんさw # System-wide .bashrc file for interactive bash(1) shells. if [ ! -e "$HOME/.sudo_as_admin_successful" ] && [ ! -e "$HOME/.hushlogin" ] ; then case " $(groups) " in *\ admin\ *|*\ sudo\ *) if [ -x /usr/bin/sudo ]; then cat <<-EOF To run a command as administrator (user "root"), use "sudo <command>". See "man sudo_root" for details. EOF fi esac fi >>388 textareaの中にbashのコードがあるとどうやったら解釈できるの? UIとして考えると、レコードの追加、削除も必要になる。 それは属性として書けばいいだろう。 削除は単に属性つければ削除ボタン追加できるが 追加の場合は、どんな内容を追加するのかを書かないといけない コレはHTMLのtemplateを参考にするとしよう <datalist id="types"> <option>A</option> <option>MX</option> </datalist> <table name="records" deletable="true" appendable="record"> <thead><tr><th>ホスト名</th><th>タイプ</th>・・・</tr></thead> <tr> <td><text name="hostname">www.example.com</text></td> <td><select name="type" list="types">A</select></td> ・・・ </tr> <tr> <td><text name="hostname">mx.example.com</text></td> <td><select name="type" list="types">MX</select></td> ・・・ </tr> </table> <template id="record"> <td><text name="hostname"></text></td> <td><select name="type" list="types"></select></td> ・・・ </template> >>389 質問の意味がよくわからんがシンタックスハイライトの話かな? <textarea lang="bash"> bashのコード </textarea> とすればいいだろう。 もちろんこれは設定ファイルであって、bashrcとして実行可能にするには 設定からコードを生成しなくてはいけない。 でもそれは別のツールの話 一応>>390 でXMLとしてはDNSのレコードを編集することは可能になるが ちょっと冗長だから、テーブルの項目名が同じ場合専用の簡易版を作っても良いかもしれない 追加する場合のテンプレートはデフォルト空でよければ不要 <datalist id="types"> <option>A</option> <option>MX</option> </datalist> <tablelist name="records" deletable="true" appendable="true"> <thead> <tr> <th type="text" name="hostname">ホスト名</th> <th type="select" name="type" list="types">タイプ</th> ・・・ </tr> </thead> <tr> <td>www.example.com</td> <td>A</td> ・・・ </tr> <tr> <td>mx.example.com</td> <td>MX</td> ・・・ </tr> </tablelist> まあいまざっくりと考えながら書いてるんで 穴とかあると思うけど結構面白いな。 XML設定ファイルでありながら、汎用の設定ツールの たたき台のたたき台ぐらいにはなりそうw 今ひらめいたけど、>>392 のレコードを追加可能にする仕様 テーブルの最後に追加するか、途中に追加できるのか?は 設定ファイルに書く必要はない それは設定ツールの実装に任せればよい。 間に追加してもいいし、最初や最後にしか追加できなくても良い ツールによっては、レコードを絞り込むフィルタ機能や並び替え機能も つけてもいいだろう。 所詮、テキストである設定ファイルの項目を 増減したり並び替えたりするだけだから問題は起きないだろうし。 本質的には設定ツールはテキストファイルの内容を (使いやすく)書き換えるだけに過ぎないしね >>391 UIの話してんの?htmlでホームページ作れるよってこと? >>395 設定ファイルの話。 設定ファイルをXML形式にする・・・というのは それなりに行われているが、単に冗長になっただけで テキストエディタで編集しづらく、大したメリットがない。 だけどそれはXMLの使い方を間違えているからの話。 (他の形式に比べて)冗長なのはXMLである以上どうしようもないが、 メリットを出すことはできる。 それが汎用のXML設定ファイル形式(XMLを拡張してスキーマを定義する) HTMLを参考にしてXML設定ファイルはタグが定義されているため 汎用の設定ツールを作ることが可能になる。 アプリの作者は単にその汎用のXML設定ファイル形式を採用するだけで 設定ツールの作成は他に任せることができる。 汎用の設定ツールはユーザーフレンドリーなツールで 例えば選択項目であれば選択候補を表示したり、 もちろん実装次第だが、ウェブサイトで見たことがあるような設定画面を 設定ファイルから作り出すことができる。多言語対応なども可能 ブラウザで表示したHTMLファイルのフォームの値を変更して、 そのまま元のHTMLに保存できるような感じ そのような高度な設定ツールを使うことが可能な、 汎用のXML設定ファイル形式を作る・・・というふうに 世の中がなっていたら良かったのにという話 つまり、世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>396 単にホームページを作ってカスタムしたい設定ファイルをDLできるようにすれば良いんじゃね? なんでも表現できる君なんだから 欲しいと思う人は各々スキーマなりスクリプトなり勝手にこしらえればいいんじゃね って事じゃないかな もう <textarea> ここに〇〇の設定ファイルを書け </textarea> でいいんじゃね? スーパーGUI設定ツールにハイライトや補完他色々して貰えばOK >>400 必死にならなくていいよw お前のアイデアはクソ 汎用XML設定ファイルの足元も及ばない 汎用設定XMLを使って専用GUIも使うと言ってるのに何が不満なんだろ そりゃGUIからの設定がしづらいからだろ? HTMLのフォームに似た要素ががある汎用XML設定ファイルなら 設定しやすいGUIが作れる。 GUIだったらどんなものでも満足するんだろ? みたいな考え方じゃないんだよ 汎用XML設定ファイル専用GUIをもっと高機能にすれば解決ですね! 開発頑張ってください! いや全然よくわかんないんだけど、 >ブラウザで表示したHTMLファイルのフォームの値を変更して、 >そのまま元のHTMLに保存できるような感じ これはjavascriptでhtml生成して保存とかでいいんじゃ。。<textarea>で何でもかけるとか言い出したらもうタグの意味さえないけど。 >>405 > これはjavascriptでhtml生成して保存とかでいいんじゃ。。 変更したいのはフォームの値だけなのに、面倒くさいだけじゃん > <textarea>で何でもかけるとか言い出したらもうタグの意味さえないけど。 それは設定ファイルの話をしてるのに、 実行可能コードをどうやって設定ファイルに含めるのか?とか 言い出したやつへの皮肉だな >>404 GUI(設定ツール)の開発とXMLスキーマの定義は別々に考えよう >>406 えwxml君の言うとおり、フォームの値を入れるだけだろもちろん。 ブラウザにそんな機能ないからjavascriptで足してやればいいじゃん。それともブラウザを一から開発するのか? >>408 開発する必要があるのは設定ツールだよ ブラウザ技術を応用する。さすがにブラウザそのものは機能が多すぎる そしてその設定ツールを作る前段階のXMLの使い方の話をしている。 汎用のXML設定ファイル(XMLをベースに拡張して独自のタグを定義したもの)は 設定ツールがなくてもテキストエディタで修正できる。だから設定ツールの存在は必須ではない 設定ツールの存在は必須ではないが、XMLをテキストエディタで修正するのは面倒 設定ツールがあれば設定は楽になるが、今のいろんなアプリの設定ファイル(XMLを使ったもの)は 独自のタグを定義しているため、アプリ専用の設定ツールを作る必要がある。つまり開発コストが高い だから設定ツールはなくXMLファイルをテキストエディタで修正するにとどまっている もし汎用のXML設定ファイル(XMLをベースに拡張して独自のタグを定義したもの)があれば そんな状況は変わっていただろう。今頃はどんなアプリでも同じ設定ツールを使って 初心者でも簡単に設定できていた つまり、世の中はXMLの使い方を間違ったよなーって話をしてるだけ さて、無理やり軌道変更しようとしていたようだが、 世の中はXMLの使い方を間違ったよなーって話に 軌道修正できましたかね?w 突っ込まれるとややこしくなりそうな問題から逃げ回るのを軌道修正というのか ん? >>220 のときから書いてあるように 「世の中はXMLの使い方を間違ったよなーって話をしてるだけ」に 戻しただけですが? 何度言っても理解しないで、 俺にツール作れとか言い出すからね ちゃんと言っておかないと 単純な話なんだけど、世界中で使われてるxmlの応用例を間違ってると言って自分が考える正しい使い方を披露しても、スタンダードの方が効率的で合理的だと思われるのは自然。 設定ツール無しでこんな複雑なXMLを手で編集しろと言われても メリット無いだろ 設定ツールが無いとまともに扱えないようなXMLをテキストエディタでも大丈夫と 設定ツールの話を避けられても ODFはLibraOffice使わずともviで書けますと言うようなもんだ >>414 思うとかじゃなくて、ちゃんと理由をいいなよw それじゃ素人の意見じゃん >>415 > 設定ツール無しでこんな複雑なXMLを手で編集しろと言われても > メリット無いだろ だって手で(テキストエディタ)で修正するのは、開発者や技術者のために そういうことも可能ってだけだから。普段は設定ツールで設定すれば良いんだよ 開発が進んで育てれば、設定ツール用のUIが追加されていくが、開発の初期段階とか 設定ツールのことは考えないって決めれば、設定項目を羅列するだけでも良い 例えば上の方で「設定ツールでユーザーが候補から選べるように<select>を使用する」と言って 以下のようなタグを書いたが、 <select name="item" value="a"> <option>a</option> <option>b</option> </select> 開発の初期段階とか設定ツールのことは考えないのであれば、以下のように書いてもいいわけだ <input name="item" value="a"> どちらも設定内容としては同じ。これは複雑なXMLではない。 複雑なXMLになるのは設定ツールのためにそうするのであって、 それなら設定ツールでやれるようになるわけだよ >>416 あまりにもクソコード過ぎて素人でも説得力ないってわかるって言いたいだけだよ。 selectにしろ、inputにしろ、それがどの設定における値なのかわからないってことぐらいわかるだろ。 開発者でもツールが無けりゃこんなもの扱う気なくすわ まあだからxmlは今人気がないわけで。 xmlはあくまで文章なんで、officeに使われてるのもそれが理由だろ。昔はバイナリだったが。 こんなXMLはひどいと言われたらツールの支援があると逃げ ツールの話になるとXMLの使い方の話だと逃げ 立場を変えるなあと思ったら ついにはXMLの悪口言い出したか >>418 > selectにしろ、inputにしろ、それがどの設定における値なのかわからないってことぐらいわかるだろ。 いや、名前で見分けろよw <select name="url"> とかでわかるだろw >>421 同じことを繰り返すな >>396 ですでにまとめてる 設定ファイルの話。 設定ファイルをXML形式にする・・・というのは それなりに行われているが、単に冗長になっただけで テキストエディタで編集しづらく、大したメリットがない。 だけどそれはXMLの使い方を間違えているからの話。 (他の形式に比べて)冗長なのはXMLである以上どうしようもないが、 メリットを出すことはできる。 それが汎用のXML設定ファイル形式(XMLを拡張してスキーマを定義する) HTMLを参考にしてXML設定ファイルはタグが定義されているため 汎用の設定ツールを作ることが可能になる。 アプリの作者は単にその汎用のXML設定ファイル形式を採用するだけで 設定ツールの作成は他に任せることができる。 汎用の設定ツールはユーザーフレンドリーなツールで 例えば選択項目であれば選択候補を表示したり、 もちろん実装次第だが、ウェブサイトで見たことがあるような設定画面を 設定ファイルから作り出すことができる。多言語対応なども可能 ブラウザで表示したHTMLファイルのフォームの値を変更して、 そのまま元のHTMLに保存できるような感じ そのような高度な設定ツールを使うことが可能な、 汎用のXML設定ファイル形式を作る・・・というふうに 世の中がなっていたら良かったのにという話 つまり、世の中はXMLの使い方を間違ったよなーって話をしてるだけ 本人は何も考えてないだろうけど この設定記述XMLには 設定値の保存のみではなく、 構造の定義やスキーマ他メタ情報、 データ型、バリデーションの記述、 UIやフォームのインターフェイス作成、 オブジェクトマッピングの定義など(まだまだあるかも)の機能や規格が必要で 規格書が電話帳のようになり実装可能だとしてもフットプリントは巨大になるのは間違い無いな そりゃ規格なんだからある程度の量にはなるが、 基本はXMLなのでXMLとしての仕様は不要 タグ一覧があれば十分だろ 少なくともHTMLの仕様よりは大きくならない > 設定ファイルをXML形式にする・・・というのは > --- (中略) --- > 汎用の設定ツールを作ることが可能になる。 ここまでは、まあ分かるが > アプリの作者は単にその汎用のXML設定ファイル形式を採用するだけで > 設定ツールの作成は他に任せることができる。 これが分からん。 現状のwel-formedなだけのXMLでも可能でしょ? 設定ツールやスキーマなど必要なものの作成は他に任せりゃいいだけで アプリの作者は今のまま何の負担もない。 なぜ作者にとって本来不要な手間のかかる俺ルールを押し付けるのか意味が分からない。 一ユーザーの立場からするとそんなつまらんものに時間を割くぐらいなら 他の事をやるなり体を休めてくれとか思うな >>426 > 現状のwel-formedなだけのXMLでも可能でしょ? > 設定ツールやスキーマなど必要なものの作成は他に任せりゃいいだけで > アプリの作者は今のまま何の負担もない。 それだとアプリごとに設定ツールを開発しなければいけなくなる。 今度は設定ツールを開発する側の負担が大きい(だから設定ツールは作られない) > なぜ作者にとって本来不要な手間のかかる俺ルールを押し付けるのか意味が分からない。 必要最低限の使い方でいいなら使用するタグは<input>タグだけで成り立つよ <input>タグのname属性が設定項目名になる。 今はほとんどが設定項目の名前をタグにしてるが、 それをname属性に変えるだけなんだよ。 アプリ作者の手間にはならない。 そしてHTMLライクなXML設定ファイルだから、プログラマじゃない人でも手伝える。 アプリ開発者がアプリ本体を開発間に、他の人が使いやすい設定ファイルを 作ってくれることも期待できる。 > それだとアプリごとに設定ツールを開発しなければいけなくなる。 そうならないような設定ツールを作るなり スキーマなりスクリプトなどで扱える形なり 工夫すればいいだけじゃないの > 今度は設定ツールを開発する側の負担が大きい(だから設定ツールは作られない) ようするに設定ツールの作者個人のスキルが足りなかったり手間を掛けたくないから 全てのアプリ作者に無駄な作業を強いるって事ね > 今はほとんどが設定項目の名前をタグにしてるが、 > それをname属性に変えるだけなんだよ。 そんな程度なら相互の変換スクリプトでも噛ませばいいだけの話 > アプリ作者の手間にはならない。 ゼロじゃなければ意味ないよ > そしてHTMLライクなXML設定ファイルだから、プログラマじゃない人でも手伝える。 プログラム側でやってる全てのチェックをスキーマなりに落とし込む作業だからコードが読めないと無理では > そうならないような設定ツールを作るなり だからツールを作れるようにするために、汎用のXML設定ファイル というのを作るべきだってって言ってるんだが? 現状、どんなアプリの設定ファイルも設定できるツールないでしょ 現実に不可能だったという実例があるのに、そうならないように〜とか言っても意味ない > 全てのアプリ作者に無駄な作業を強いるって事ね 無駄じゃない。アプリの作者は自分でXMLの設定ファイルを考える必要がない 設定ツールを作る必要がない。というメリットが有る。 > ゼロじゃなければ意味ないよ 言葉遊びかな?ゼロじゃなければ意味がないというなら、 自分で独自形式を考えるのも時間がかかるからゼロじゃないってことになるね。 最初から汎用のXML設定ファイルを使うなら、 そこから別に物に変える必要がないのでゼロとも言えるw > プログラム側でやってる全てのチェックをスキーマなりに落とし込む作業だからコードが読めないと無理では プログラム側でやってるというなら、それに任せればいいだけだろ。 だからこの処理に相当するものはスキーマ(タグの定義)に入れる必要はない。 設定側でチェックをする必要はない。っていうかスキーマで設定値までチェックするとか勘違いしてるな?w スキーマにそんなものを入れるなんて言ってない。せいぜいどんなタグがあるかとその親子関係ぐらいだ スキーマで設定値のチェックまでやっていたら、設定ファイルごとにいろいろ作らなきゃいけなくなるだろ(頭が硬いぞw) HTMLの<input>タグの値だってスキーマで値のチェックまでやってないだろ。 まあこれは具体例を言わないと理解できないだろうから説明すると ある設定項目は、A、CNAME、AAAA、MX、という文字列のいずれかの値を設定できますってことなら そのチェックをプログラム側でやってるはずなので、設定ファイルにそんなものは不要。 設定ファイルの内容はこれ。現在設定されている値はAで、A、CNAME、AAAA、MXのいずれかを選択できる事がわかる <select name="type" value="A"> <option>A</option><option>CNAME</option><option>AAAA</option><option>MX</option> </select> 繰り返すが「いずれかを選択できる事がわかる」と言ったんだ。この値以外を設定したときのチェックまでするとは言っていない。 だってそうだろう?テキストエディタで変更すればなんでも設定できるんだから、 そんなものを設定ファイルに入れることなんてできやしない。 これは、コメントを発展させたものと考えれば良いんだよ # type: Select one of A, CNAME, AAAA, MX type=A ほら、typeにはBでもCでも好きなものを入れられてしまう。だから値のチェックはプログラム側でやることだしやってるはずだ。 そして英語がわかればどんな内容を設定できるかはわかるが、コメントから設定ツールのインターフェースは作れない しかし設定ファイル自体がXMLであれば、それを読み取って設定ツールのインターフェースとすることができる。 汎用のXML設定ファイルというのは、テキストエディタで変更可能という特徴も残しながら、 ユーザーに設定しやすいインターフェースを提供する設定ツールを作れるようにするのが目的 XML文化の汚点の一つだよな。 なんでもXMLでやろうとしてしまったことだな。 XMLはデータだけを扱っていればいいのに そのデータが正しいかどうかの検証もXMLでやりましょうとか XMLはデータだけを扱っていればいいのに、 別の形式にデータを変換する処理もXMLでやりましょう(XSLTのこと)とか 俺はXMLSchemaやそれ相当のものを使うとは一言も言ってないよ。 面倒だから使わないと言い切ってもいいやw 現状使わないでやってきてるんだから。 >>425 タグ一覧だけ作って…って馬鹿だろ 何指摘されているのか意味わかってないんだろ? 口だけの無能と言うのがますますバレますなあ あるアプリケーションの特有値は出来ないだろ。 例えばゲーム中に登場するキャラクターの変数とかどうすんだ? 全部nameにつめこむのか?もはやそれは独自タグと変わんないぞ。 nameの名前空間にカカロットとかベジータまで定義すんのかw >>429 > だからツールを作れるようにするために、汎用のXML設定ファイル > というのを作るべきだってって言ってるんだが? 繰り返しになるけど ようするに設定ツールの作者個人のスキルが足りなかったり手間を掛けたくないから 全てのアプリ作者に無駄な作業を強いるって事ね > 現状、どんなアプリの設定ファイルも設定できるツールないでしょ > 現実に不可能だったという実例があるのに、そうならないように〜とか言っても意味ない 存在しないから不可能だと決めつけるのは短絡的だよ、需要がないからだとか面倒だからとか他にも理由は考えられる > > 全てのアプリ作者に無駄な作業を強いるって事ね > 無駄じゃない。アプリの作者は自分でXMLの設定ファイルを考える必要がない 多くのアプリの作者は手近なシリアライザの書き出しがXMLというだけで気にしちゃいないと思うぞ > 設定ツールを作る必要がない。というメリットが有る。 元々設定ツールは必須じゃないし 設定弄るのなんてほとんど最初だけだから テキストエディタでの編集しやすさってのはさほど重要じゃない > 言葉遊びかな?ゼロじゃなければ意味がないというなら、> 自分で独自形式を考えるのも時間がかかるからゼロじゃないってことになるね。 XMLの使い方を間違った世の中を正す よりは XMLの使い方を間違った世の中に対応する ほうがよほどマシ と言えば分かるかな どんなに素晴らしいものであろうが、使い方を間違っていると因縁つけ続けようが 他人は思い通りに動いてくれないからね > プログラム側でやってるというなら、それに任せればいいだけだろ。 > 設定側でチェックをする必要はない。っていうかスキーマで設定値までチェックするとか勘違いしてるな?w 静的チェック可能ならメリットあるかと思って賛同したけど 素通りとなるとenumなどの設定が安全簡単になりますよってなぐらいで魅力は薄れるね >>430 > そして英語がわかればどんな内容を設定できるかはわかるが、コメントから設定ツールのインターフェースは作れない # type: Select one of A, CNAME, AAAA, MX type=A を <select name="type" value="A"> <option>A</option><option>CNAME</option><option>AAAA</option><option>MX</option> </select> と解釈すればいいだけの話だと思うけど >>431 > 俺はXMLSchemaやそれ相当のものを使うとは一言も言ってないよ。 >>426 は >>423 (ID:29LJB/lv) に向けた書き込みで > 423 名前:login:Penguin [sage]: 2018/09/16(日) 17:54:48.62 ID:29LJB/lv (5) > 設定ファイルをXML形式にする・・・というのは > それなりに行われているが、単に冗長になっただけで > テキストエディタで編集しづらく、大したメリットがない。 > だけどそれはXMLの使い方を間違えているからの話。 > (他の形式に比べて)冗長なのはXMLである以上どうしようもないが、 > メリットを出すことはできる。 > それが汎用のXML設定ファイル形式(XMLを拡張してスキーマを定義する) > HTMLを参考にしてXML設定ファイルはタグが定義されているため > 汎用の設定ツールを作ることが可能になる。 つまり 設定ファイルをXML形式にする・・・というのは 大したメリットがない。 メリットを出すことは スキーマを定義する とはっきり書いてあるぞ。 もし 427(ID:4205k3sJ) ≠ 423(ID:29LJB/lv) だとするなら なぜアナタが回答してきたのか疑問 >>432 なにか言い返せってw ほんと何も言えないくせにとりあえずなにか言い返そうとするよな >>434 > ようするに設定ツールの作者個人のスキルが足りなかったり手間を掛けたくないから > 全てのアプリ作者に無駄な作業を強いるって事ね 意味がわからん。その理屈で言えば、素人はプログラミングできないから プログラミングを勉強するのは、無駄な作業であるということになるぞ? プログラミングできるなら、そのスキルは当然ありますよね? > 存在しないから不可能だと決めつけるのは短絡的だよ、需要がないからだとか面倒だからとか他にも理由は考えられる だから「面倒」ってことだよ。ずーっといってるじゃん。 アプリごとに設定ツールを作るのは面倒。だから作られないと。 でも汎用のXML設定ファイルというのがあれば、アプリごとに設定ツールを作らなくてよくなる > 多くのアプリの作者は手近なシリアライザの書き出しがXMLというだけで気にしちゃいないと思うぞ はい、だからそれも同じで、単なるXMLのシリアライザではなく、 汎用のXML設定ファイル用のシリアライザを使えば気にしなくて良くなりますよね? アプリ作者の手間なんて殆どないよ。最低限<input>を覚えるだけですむ。(普通はそれ以上のことを知ってる) > 静的チェック可能ならメリットあるかと思って賛同したけど > 素通りとなるとenumなどの設定が安全簡単になりますよってなぐらいで魅力は薄れるね えとさぁ、もう少し柔軟な思考持ったほうが良いよw 「設定側でチェックをする必要はない」と言ったんだよ? プログラム側で今チェックしてるでしょ?愚直に値の範囲チェックとかしてさ それをプログラミングしてる側がXMLSchemaを使ってやるのは構わないよ 必要がないと言っただけで、やってはダメなんて言ってない。 理解すべきことは、設定ファイルを書く側は、チェック内容まで書く必要はないってこと 役目をしっかり分けて考えよう。 ・汎用のXML設定ファイル・・・アプリの設定値は仕様に含めない(含められない)。ただしタグの種類や親子関係は仕様として定義する ・設定ツール・・・汎用のXML設定ファイルを元に設定変更のユーザーインターフェースを提供する ・アプリ作者・・・読み書きは専用のシリアライザを使うだけ。読み取った設定値のチェック(やり方は自由)を行う。 >>436 XMLSchemaってなにか知ってる? 仕様として考えたスキーマを XMLで記述するための言語の名前がXMLSchema https://ja.wikipedia.org/wiki/XML_Schema > XML Schema(XMLスキーマ)は、XML文書の論理的構造を定義する為に > 開発されたスキーマ言語の一つ。現在、W3Cが開発・標準化にあたっている スキーマ = スキーマ(笑) スキーマ言語 = スキーマを記述する言語 この2つをごっちゃにしてはダメ 同wikipedia > しかし、複数の業界有力企業が仕様の策定に参加して、各社の思惑が絡み合い、 > あまりに多くの機能を取り込んだ為に、標準化は難航し、複雑な仕様となってしまっている。 複雑な仕様のものを使う必要はない 汎用のXML設定ファイルのスキーマは必要 汎用のXML設定ファイルにアプリ固有の情報(設定値の範囲などの)は 含まれない(というか汎用なんだから含められない) だけど それを利用したアプリ固有のXML設定ファイルのスキーマは必要ない アプリごとにスキーマの定義はしなくて良いんだよ そんな無駄で面倒な作業、誰がやるんだw (必要ないと言っただけで、やったらダメとは言ってない) 理想的な世の中 アプリ作者「設定ファイルの形式どうしよう? ini?JSON?YAML?XML?アプリ独自形式?」 アプリ作者「汎用のXML設定ファイル形式というのがあるのか? よし使って設定ファイルを書き出してみよう」 <?xml version="1.0" encoding="UTF-8" ?> <configurations> <input name="foo" value="1"> <input name="bar" value="item1"> <input name="baz" value="true"> </configurations> アプリ作者「ほうほう。これが汎用のXML設定ファイル形式というやつか シンプルで使い方も簡単だが、なにが便利なのかな?」 設定ツール作者「我々が開発した設定ツールでGUIで設定できますぜ」 アプリ作者「単にインプットボックスで変更できるだけではないのかな?」 設定ファイル利用者「設定ファイル改良してみました。使いやすいインターフェースになります!」 <?xml version="1.0" encoding="UTF-8" ?> <configurations> <input name="foo" type="number" min="0" max="100" value="1"> <select name="bar" value="item1><option>item1</option><option>item2<option></select> <input name="baz" type="checkbox" checked="true"> </configurations> アプリ作者「いいね!」 お前さんこんなギャグセンスがあるとは思わなかったぞ 目指せIT系漫談家 425 login:Penguin sage 2018/09/16(日) 20:03:57.41 ID:29LJB/lv そりゃ規格なんだからある程度の量にはなるが、 基本はXMLなのでXMLとしての仕様は不要 タグ一覧があれば十分だろ 少なくともHTMLの仕様よりは大きくならない いやいや、xmlの仕様は不要で、htmlの仕様よりは大きくならないタグ一覧 が理解できる人がいたら教えてくれ。本人以外でな。俺は意味がわからん。 >>433 は見逃してたわw 433が何を言ってるのかよくわからない アプリの設定と(セーブ?)データをごっちゃにしてるようにしか見えないな。 ゲームは特殊で基本的に、アプリ(つまりゲームない)で設定変更するものだから 例えに使うと分かりづらくなるからやめたほうが良い そうだな。ユーザーがアプリの動きを変更させるためのもので、 ユーザが作成したいデータではないものってことでいいかな? >>444 > いやいや、xmlの仕様は不要で、htmlの仕様よりは大きくならないタグ一覧 > が理解できる人がいたら教えてくれ。本人以外でな。俺は意味がわからん。 XMLの仕様はW3Cが作ってるんだから、わざわざ作る必要はない。 作る必要があるのは、汎用のXML設定ファイルの仕様 https://ja.wikipedia.org/wiki/Extensible_Markup_Language > XML の仕様は、World Wide Web Consortium (W3C) により策定・勧告されている。 必死に設定XMLの機能、使いやすさ、展望を語るたびに >>425 が光り輝くのであった そもそも、xmlは独自タグ多くて、読みにくいし書きにくいからめんどくさいわ。 っていう共通認識から始まってるのに、xmlの運用を変えれば便利になるよっていう意味わかんない蛇足をつけるからややこしくなるんだ。 >htmlの仕様よりは大きくならないタグ一覧 ってなんだよwブラウザよりは小さいアプリで足りるってことかよw 世界中でまともに使えるhtmlエンジンは2~3ぐらいしかないんだぞ。 ほんといい加減にしてくれ、知識をつけてから話に参加してくれ > そもそも、xmlは独自タグ多くて、 XMLにタグは定義されてない。一つもない。タグが定義されてるのは XMLを拡張して作ったXMLベースの言語でタグが多いかどうかは、その言語によるだろ これぐらいの知識もない状態でからんでくるから、わざわざ説明しなきゃいかん > >htmlの仕様よりは大きくならないタグ一覧 > ってなんだよwブラウザよりは小さいアプリで足りるってことかよw > 世界中でまともに使えるhtmlエンジンは2~3ぐらいしかないんだぞ。 まずな。引用してる部分がおかしいから。 「htmlの仕様よりは大きくならないタグ一覧」は俺が言った言葉じゃない 俺が言ったのは>>425 だ > そりゃ規格なんだからある程度の量にはなるが、 > 基本はXMLなのでXMLとしての仕様は不要 > タグ一覧があれば十分だろ > 少なくともHTMLの仕様よりは大きくならない >>424 が不要なものまでごてごてに付け加えて、あーたいへんだーって言ってるから 「汎用のXML設定ファイル」の仕様はタグ一覧程度で十分だって言ってんだよ UIとかフォームのインターフェースとか仕様に要らねぇよ。 汎用のXML設定ファイルの仕様なんだから。 設定ツールをどう実装するかは、設定ツールに任せればいいこと んで、なんだ?汎用のXML設定ファイルの話をしてるのに、 お前は、それに対応した設定ツール(HTMLエンジン)の話してんのか 話にならない。設定ツールの実装をどうしろとか何も言ってねぇから 小さなツールも大きなツールも、大きさは設定ツール次第だろ lynxやw3mといった小さなブラウザだってあるし、そもそもHTMLエンジンである必要もない 425 login:Penguin sage 2018/09/16(日) 20:03:57.41 ID:29LJB/lv そりゃ規格なんだからある程度の量にはなるが、 基本はXMLなのでXMLとしての仕様は不要 タグ一覧があれば十分だろ 少なくともHTMLの仕様よりは大きくならない 大きさと行数はイコールというわけじゃないが大体の目安にはなるな https://www.openhub.net/p/chrome 23,701,168 lines of code https://www.openhub.net/p/firefox 36,890,150 lines of code https://www.openhub.net/p/w3m 172,152 lines of code https://www.openhub.net/p/lynx 209,536 lines of code >>451 設定ツールでどんな機能・利便性・使い勝手が実現できるかが肝心なとこじゃねえの? そこ実装依存とか逃げまわる所じゃないだろ(笑) htmlエンジン使わないならタグのGUIにおける解釈はどうすんの?設定ツール作る人に投げるの? はい、案の定、俺の意見を曲解されたので>>220 をコピペしておきますね。 >>216 何の意味って、最初に言ったとおり、 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>217 標準化しようじゃなくて 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>218 仕様を書く必要はないよ 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>219 世の中はXMLの使い方を間違ったよなーって話をしてるだけ だからxmlで設定書くのはやめて他のツール使えって話で終わりだと思うんだけど。 >>458 はい、案の定XMLの正しい(爆)の使い方の話に切り替えましたねー。 では設定ツールという概念はNGワードにしましょう。 ただのテキストエディタしか使わない状況で 設定XMLのメリットを解説してくれませんかね。 ていうか、ずっとリブレオフィスの例とか引っ張り出してきてて文章としてのxmlと設定ファイルのxmlをごっちゃにされも困るんだけど。 普通にアプリケーションの設計を考えた時に、guiのアプリで、設定ツールだけ別の汎用ツール使ってくださいってことでしょ。 使う側も開発する側もめんどくさいよ。どうせアプリのGUIを作るんだから、ついでに作ったほうが楽だよ。 ユーザーフレンドリーでもないし。 >>459 世の中のアプリで汎用の設定ツールで設定できるものありますか? 汎用の設定ツール = テキストエディタとか言わんでしょうね?w 設定ファイルに書いてあるコメント(英語)を読んで長ったらしくて見づらい 設定ファイルをテキストエディタで編集するのは初心者には大変なんですよ。 GUIの設定ツールが必要です。そのGUI設定ツールを アプリ開発者が作る手間を省く方法がありますか? 面倒だから、GUIの設定ツールはなかなか作られないそれが現実ですよ。 汎用のXML設定ファイルという形式が作られれば、その問題が解決するわけです。 アプリごとに異なる形式の設定ファイルでは不可能ですからね >>460 > はい、案の定XMLの正しい(爆)の使い方の話に切り替えましたねー。 いや、お前がすり替えていたんだろ? > では設定ツールという概念はNGワードにしましょう。 ははw 言われて困る言葉は封殺しようということですかw 何度でも言いますよwww > ただのテキストエディタしか使わない状況で > 設定XMLのメリットを解説してくれませんかね。 汎用の設定ツールで設定できるようにするために、汎用のXML設定ファイルが必要なのです。 ただのテキストエディタしか使わない状況なんてありません。そんなのお前の中の世界の話でしかありません 汎用のXML設定ファイルのメリットは、汎用の設定ツールを作ることが可能になり、そのツールを使えるので アプリ作者は何も作らなくても設定がGUIで可能になることです。そうなると開発者とユーザーの両方にメリットがあります。 正しくXMLを使えていたら、今頃はそうなっていたのに、 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>462 > どうせアプリのGUIを作るんだから、ついでに作ったほうが楽だよ。 開発者には設定ツールの開発ではなく もっと本質的な機能の開発をしてもらうか、 休ませてあげましょう。 それともあんたが作るの?w ユーザー「設定ツールはアプリ開発者が作れよ。どうせGUI版も作るんだろ?その方が開発者も楽だろ?」 開発者「うるせーぞクソユーザー。GUI版なんていらねー、楽だと思うならお前が作れや」 お前さあ 「設定ツールがどういう実装になるか知ったことじゃない 実装どころかどんな機能になるのか機能が実現できるかオレに聞くな 正しい設定XMLの使い方を教えてやる」 という態度取っておいて 「設定ツールが設定XMLがあるから素晴らしいのだ」 って面白い奴だな。 > 「設定ツールが設定XMLがあるから素晴らしいのだ」 違う。 汎用の設定ツールを作れるようになるから 汎用のXML設定ファイルは素晴らしいのだ と言ってる お前さぁ、どうも自分の思い込みで勝手に俺の像を作って そいつを叩いてるだけだよな? >>464 俺は作る側の人間だから自分のアプリではつくる。 設定ツールってよくわからんが、設定するための画面はアプリのメニューに合ったほうが良いじゃん。 > 設定するための画面はアプリのメニューに合ったほうが良いじゃん。 良いと思いますよ? 汎用の設定ツールがあれば、アプリのメニューから それを呼び出すだけいいですね。 簡単です。 >>469 読解力ゼロか。設定ツールなるものと設定するための画面と言葉を変えてるだろ、同一のものを指してるんじゃないんだよ。 >>470 はぁ? アプリ埋込み型の設定ツール(ライブラリ)を使えばいいでしょう? 今の時代、スマホのゲームの画面からお知らせを開いたら アプリ埋め込みのwebkitライブラリからHTMLを表示している なんて普通に行われてるんですが >>471 スマホアプリの話ししてるならスレチもいいとこだから帰れ。 後出しジャンケンすんな。ただのストローマンかよ。 >>472 お前本当に頭が固すぎるな スマホアプリは例であって、どんなアプリでも応用できる話だろ 汎用のXML設定ファイルというものが作るというふうに世の中が進んでいたら、 今頃はライブラリとして、汎用のXML設定ファイルを設定できる ダイアログを表示する機能も実現できていただろうなって話だ。 アプリ開発者はAPI一つ呼ぶだけで、設定画面が完成してしまう。 もちろん開発初期は、<input>並べただけだからろくな見た目ではないが それでも使える。後々作り込めばいいし、プログラマじゃない人でも手伝うことができる。 それこそデザイナーに頼んでかっこよくて使いやすい設定画面を作ってもらえばいいし その間にアプリの開発者は本質的な機能の実装に取り掛かれる >>473 そうか、つまりwebkitライブラリ的なライブラリが設定ツールに必要でそれがほとんど、htmlエンジンだって気がついてくれたかな? ていうか、webkitライブラリの中身はHTMLエンジンなんだけど。 だいたいなー 「画面はアプリのメニューに合ったほうが」っていうのが GUIアプリのことしか考えられてない点で視野が狭いんだよな。 CLIコマンドやサーバーアプリの設定とかもあんだろと >>474 > htmlエンジンだって気がついてくれたかな? HTMLじゃないので、 「汎用のXML設定ファイル」エンジンなw ほんとなんでこういう基本的な 理解がないんだろう。 見た目似てれば全部同じものなんですかー?w あー、くっそ頭悪いわこいつ。相手する必要さえないわ。 日本語うまく書けないし、たとえ話を事実のように書くし、誰も理解できんだろ。 相手にしてくせに(笑) 相手にしてるくせに、相手する必要ないってわざわざ言うのは、 相手する必要があるのに、相手を言い負かせられない言い訳だろw 有言実行、相手する必要ないと言ったならこれから先レスをするな そうすりゃお前は自分の言葉を曲げず、俺も逃げたと皆に思われるから満足だ。 お前はレスするな。それが俺の命令。俺の命令にお前は従うしかないのだ >>396 でまとめたことの再掲 設定ファイルの話。 設定ファイルをXML形式にする・・・というのは それなりに行われているが、単に冗長になっただけで テキストエディタで編集しづらく、大したメリットがない。 だけどそれはXMLの使い方を間違えているからの話。 (他の形式に比べて)冗長なのはXMLである以上どうしようもないが、 メリットを出すことはできる。 それが汎用のXML設定ファイル形式(XMLを拡張してスキーマを定義する) HTMLを参考にしてXML設定ファイルはタグが定義されているため 汎用の設定ツールを作ることが可能になる。 アプリの作者は単にその汎用のXML設定ファイル形式を採用するだけで 設定ツールの作成は他に任せることができる。 汎用の設定ツールはユーザーフレンドリーなツールで 例えば選択項目であれば選択候補を表示したり、 もちろん実装次第だが、ウェブサイトで見たことがあるような設定画面を 設定ファイルから作り出すことができる。多言語対応なども可能 ブラウザで表示したHTMLファイルのフォームの値を変更して、 そのまま元のHTMLに保存できるような感じ そのような高度な設定ツールを使うことが可能な、 汎用のXML設定ファイル形式を作る・・・というふうに 世の中がなっていたら良かったのにという話 つまり、世の中はXMLの使い方を間違ったよなーって話をしてるだけ 最初の書き込み(>>123 ) 我ながら言ってることが一貫してるわw 設定ファイルのXML方式はやり方を間違えたからな。 そもそもXMLというだけではタグの種類は定義されておらず タグと属性を使ってデータを表現しますっていう縛りにすぎない。 例えばOpenOfficeとかはXMLをベースにした ODFというフォーマットを採用している。 このフォーマットに相当するものが設定ファイルになかった 標準化せずに各アプリがそれぞれ独自のフォーマットを作成してしまった。 そのせいでXMLを使いながらも、汎用の設定変更アプリが出現することはなかった >>467 汎用設定ツールとやらをどうやって作るとか 何を実装すべきかとかどういう動作をすべきかは知ったことではないんだよな(笑) 結局これでは設定ツールがどんな代物になるのかわかる人いないだろ(笑) 425 login:Penguin sage 2018/09/16(日) 20:03:57.41 ID:29LJB/lv そりゃ規格なんだからある程度の量にはなるが、 基本はXMLなのでXMLとしての仕様は不要 タグ一覧があれば十分だろ 少なくともHTMLの仕様よりは大きくならない このように汎用のXML設定ファイルの話をしているのに 何が何でも設定ツールの話にすり替えようとしている人に 騙されないようにしましょう。 注意喚起でした。 「汎用の設定ツールを作れるようになるから 汎用のXML設定ファイルは素晴らしいのだ」 でも設定ツールの具体的な話はお断りです。 設定ツールが設定ファイルをどう扱うかうか怪しいのに アプリが設定ファイル読み込んでちゃんと設定値の利用できるんだろうか > もちろん開発初期は、<input>並べただけだからろくな見た目ではないが > それでも使える。後々作り込めばいいし、プログラマじゃない人でも手伝うことができる。 enum Items {item1,item2,item3}; class Configurations { int foo; Items bar; bool baz; } Configurations configurations; なら <configurations type="Configurations"> <foo type="int">1</foo> <bar type="Items">item1</bar> <baz type="bool">true</baz> </configurations> なら助かるけど <configurations> <foo>1</foo> <bar>item1</bar> <baz>true</baz> </configurations> でもまったく問題ないな もちろん初期は、全てtype="string"として扱うだけだが それでも使える。後々type="bool"なりtype="Items"なりスキーマなどで定義すりゃいいし、プログラマじゃない人でも手伝うことができる アプリ作者は何もしなくていい 設定ツールの作者にとっても bool,int,Itemsなどをどう扱うかは設定ツールの作者が好きにしたらいい もちろん開発初期は、すべて<input>並べただけだからろくな見た目ではないが それでも使える。後々Itemsをセレクトボックスで選べるようにしたりboolをcheckboxなり好き勝手に作り込めばいい >>486 > 設定ツールが設定ファイルをどう扱うかうか怪しいのに > アプリが設定ファイル読み込んでちゃんと設定値の利用できるんだろうか まさかと思うけど、設定ツールで設定したら、設定ファイルが 壊れちゃったとかそういう事考えてる? それってテキストエディタで 編集したらファイルが壊れたみたいなことと同じこと言ってるよ 設定ツールは何もデータを変更せずに保存すれば設定ファイルは何も変更しない 設定ツールが変更できるのは<input>とか<select>とか設定値として使用する要素だけ さすがにこれぐらいは決めるよ。決めるっていうかガイドラインだね。 アプリが設定値として利用するのは<input>とか<select>とか設定値として使用する要素だけ これらの要素の名前を値を利用する。DOMの構造は設定値としては不要な情報なので無視する。 だから構造をガラッとかえても、名前と値が同じならアプリからは同じ設定に見える >>487 「なら助かるけど」も「でも全く問題ない」も両方とも問題がある。 設定の名前(つまりfoo, bar, baz)をタグにするから 汎用の設定ツールで扱うことができないんだよ だって、<foo>、<bar>、<baz>をどういうタイプとして扱うかなんてわからないでしょ その使い方が間違ってると言ってるわけ。 でもやっぱりそういう使い方をするもんだって思い込んじゃってるんだよね・・・ 発想が凝り固まってるのはどうしようもないんかねw じゃあどうすんの?って話なんだろうけど、すでに上の方でも書いてるけどこんな感じね <configurations type="Configurations"> <label>foo: <input name="foo" type="int" value="1" /></label> <label>Items: <input name="bar" type="Items" value="item1" /></label> <label>baz: <input name="baz" type="bool" value="true" /></label> </configurations> そうすりゃ設定ツールは、fooという未知のタグをどう表示すりゃいいんだ?なんて悩むことはなく あ、はいはい、inputタグね。これはユーザーの入力項目ですね。intですね。なら数値フィールドですね。 数値以外は入れられないようにしますよ。なんなら上下ボタンで値の増減もしますよ。 みたいに理解できる。 ちなみに上の例にはわざと<label>を追加してる。なぜかというと設定ファイルにあるタグはすべてが 入力項目とは限らないからだ。既存の設定ファイルでもコメントでどんな値を入力すればいいかなどの説明が書いてあるだろ? すべてのタグを入力項目として扱えない。どうせそのことが抜け落ちてるんだろうからさ >>489 >>490 色々できることが増えてきたけど 何ができるとか何をして良いとか何をしてはいけないとか どうやって決めるんだろう 425 login:Penguin sage 2018/09/16(日) 20:03:57.41 ID:29LJB/lv そりゃ規格なんだからある程度の量にはなるが、 基本はXMLなのでXMLとしての仕様は不要 タグ一覧があれば十分だろ 少なくともHTMLの仕様よりは大きくならない >>491 > 色々できることが増えてきたけど > 何ができるとか何をして良いとか何をしてはいけないとか > どうやって決めるんだろう 誰かが決めれば? 俺は、世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>220 より >>216 何の意味って、最初に言ったとおり、 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>217 標準化しようじゃなくて 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>218 仕様を書く必要はないよ 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>219 世の中はXMLの使い方を間違ったよなーって話をしてるだけ あと、何度もコピペしてるけど そりゃ規格なんだからある程度の量にはなるが、 基本はXMLなのでXMLとしての仕様は不要 タグ一覧があれば十分だろ 少なくともHTMLの仕様よりは大きくならない HTMLの仕様は巨大で複雑。タグが省略できるなど XMLに反してるのでそこまで決めなければならなかったし HTML5では間違ったHTMLであってもすべてのブラウザで 同じように表示できるように不正なHTMLの解釈の方法まで定義された 汎用の設定ツールはXMLベースなので、そんなことは不要 XMLをベースにしてますの一言で、拡張部分(つまりタグ一覧)さえ決めれば良くなる >>492 誰かが決めればってそれは規格を作成して決めなきゃいけない問題であるとの認識なのか 丸投げ逃亡宣言かどっち? >>494 お前が技術的なメリットデメリットの話から、実現が大変かどうかの話に すり替えようとしてるのには気づいているからさw 俺からすりゃ、大変だから何? 大変というのは俺が言ってる 世の中はXMLの使い方を間違ったなーという話への反論には なってないでしょの一言で終わりだから 丸投げ逃亡宣言(笑)とか、結局技術的な話をしたいんじゃなくて 俺を論破(笑)したいだけなのモロバレだし だから技術的な話から揚げ足取りできる方向にすり替えたいんだろうな 規格の制定が必要だと認識してるのかどうか答えられないの? 独自タグに溢れてるから間違いって主張は間違ってるじゃん 何度でも聞くけど >>492 誰かが決めればってのは ・設定ツール作成や利用アプリの為に規格作成が必要 ・規格なんか決めなくて実装者が好き勝手決めて思う通りやれば良い ・自分でも 何言ってるのか意味が 何度でも聞くけど >>492 誰かが決めればってのは ・設定ツール作成や利用アプリの為に規格作成が必要 ・規格なんか決めなくて実装者が好き勝手決めれば良い ・自分でも何言ってるのか意味がわからない どれ? だから決めるべきことがあれば、誰かが決めろって 俺は最初からずーっと 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>493 XHTMLは「XMLを拡張して」作ったけどタグ一覧で済んでたかな ひょっとして >>123 から始まってたのか? 今気付いた。 さすがにちょっと可哀想になってきたよ。 近くに君と会話できる人はいないのかい? >>501 誰が何を決める想定なんだよ 決めるべき所は決めるじゃトートロジーだろ >>502 > XHTMLは「XMLを拡張して」作ったけどタグ一覧で済んでたかな XHTMLの話はしてない >>503 数ヶ月あけてレス (>>177 ) が来たからね。 話を再開しただけ > 近くに君と会話できる人はいないのかい? それが技術的な話と何か関係ある? もっというと、それは反論ではないよ。 >>504 > 誰が何を決める想定なんだよ だからそんなの想定する必要がないってw 俺は最初からずーっと 世の中はXMLの使い方を間違ったよなーって話をしてるだけ ほんとなぁ「XMLの使い方を間違った」という意見に対しての 技術的な反論してくれればいいのに、大変だろう?とか誰がやるんだよ?とか 無関係な話にすり替えて揚げ足撮ろうとしてるのミエミエだからw 仕事でも「解決すべき問題の認識」と「どうやって解決すべきか」は 分けて考えないといけない。 でないと、以下のようなシナリオが起きる 上司「なにか問題はありますか?」 部下「○○という問題があります?」 上司「誰が問題点を解決するんだ?そのコストがいくらかかる思ってるんだ? お前責任取れるのか?その答えがでてないなら議題に上げるな」 こうやって問題があるのになかったことにされる。 優秀だが嫌味な部下「まず問題があるか無いかを決定する話をしましょう。 問題があることに異論はないわけですよね。では問題があるということは決定します。 そして、あなたは問題があると認識した上で誰が解決するのかとコストが不明という別の理由で 問題がなかったことにするのですか?おかしいですね。問題があることは決定したはずです。」 ミスったw 上司「なにか問題はありますか?」 部下「○○という問題があります」 部下が、聞いてどうするんだってなw 仕様をどう決めて何を実装すべきか言えないのに 今のソフトは間違ってる(笑) >>505 XHTMLはタグ一覧ではすまなかったのかな? 設定XMLはタグ一覧で済む理由あるのかなあ(爆) 世間のXMLの使い方は間違ってて設定XMLの先生が間違ってない理由は何さ(大爆笑) >>509 根本的なところがずれてない? http://jtdan.com/spec/ の中から XHTML 1.0 拡張可能ハイパーテキスト・マークアップ言語 (第二版) http://msugai.fc2web.com/web/W3C/xhtml1SE/Cover.html XHTMLの仕様書ってこんだけだよ? 意外と少ないでしょ。 誰かが電話帳ぐらいになるはずだとか言ってたけど。そんな量はない。 見ての通りHTMLとの互換性の話が含まれるから、XHTMLは量が多めだけど、 それでもこの程度、XML設定ファイルはこれよりも少ないってのは明らかだろうね もしかしてA4用紙で3枚を超えたら多いとか思ってない? >>510 > 世間のXMLの使い方は間違ってて設定XMLの先生が間違ってない理由は何さ(大爆笑) 間違ってるという(俺の)意見がある その俺の意見に対して間違っているという意見がない >>512 いや色々突っ込まれてることにお前が認識してないだけだろ >>511 https://www.w3.org/TR/2002/REC-xhtml1-20020801/ 原典だせないの? これはタグの一覧に見えるのか? お前のリファレンスのHTML4の差分という文章は? >>512 お前の設定XML(笑)に賛同してくれる物好きいないから却下でいいんじゃないの(笑) 都合の悪い質問は無視して難癖できるとこだけ明後日の妄想続ける(爆) >>505 間違ってるなら正しい使い方示せばいいのに 誰かが決めるべき所は決める(笑) >>505 今のXMLが間違ってる以外の ぼくのかんがえたさいきょうの設定XMLだの 設定ツールが作れるだのは思えの意見じゃ無いの? 何度も言ってるけど、xmlは異なるアプリ間やxmlを共有(feed利用)しない限り、 名前空間を定義(スキーマ)せずに使っても間違いとは言えない。 文法の誤りとかじゃなくて、設定ファイルなんかの特定のアプリ内で使うようなxmlに独自タグが入っててもいいだろ。 そもそも設定ファイルにxml使ってるようなアプリはエディタで編集されるのを想定してないからxml使ってるようなもん。 普通に使ってたら設定ファイルすらみない。 linux使っててbash書いたり、yml編集したり、config.jsonをエディタで編集してもxmlはguiで編集するのが多かった。 独自タグがあってもうまく隠されてて不都合が起きることはまずない。 だからxml君の主張は的外れだな。世間のxmlの使い方は間違ってない。 だいたい世間が使うときはFeedぐらいだしな。 お前らのXMLの使い方は間違ってる! 正しい使いかはこれだ(ボコボコに叩かれる) いやーオレのXMLの使い方は間違ってるに誰も反論してないこれはオレの大勝利 こういうことですかね fooの型ってなんだよ ← 分かる boolだよ boolって言ってもいろいろあるだろ ← 分かる true/falseの大文字小文字区別なし、[Tr][Rr][Uu][Ee]だね radioboxか?checkboxか?selectboxか?何で扱えばいいんだ? ← 分からない 好きにしろよ… 間違ってる使い方(>>487 )と正しい使い方の例 >>487 「なら助かるけど」も「でも全く問題ない」も両方とも問題がある。 設定の名前(つまりfoo, bar, baz)をタグにするから 汎用の設定ツールで扱うことができないんだよ だって、<foo>、<bar>、<baz>をどういうタイプとして扱うかなんてわからないでしょ その使い方が間違ってると言ってるわけ。 でもやっぱりそういう使い方をするもんだって思い込んじゃってるんだよね・・・ 発想が凝り固まってるのはどうしようもないんかねw じゃあどうすんの?って話なんだろうけど、すでに上の方でも書いてるけどこんな感じね <configurations type="Configurations"> <label>foo: <input name="foo" type="int" value="1" /></label> <label>Items: <input name="bar" type="Items" value="item1" /></label> <label>baz: <input name="baz" type="bool" value="true" /></label> </configurations> そうすりゃ設定ツールは、fooという未知のタグをどう表示すりゃいいんだ?なんて悩むことはなく あ、はいはい、inputタグね。これはユーザーの入力項目ですね。intですね。なら数値フィールドですね。 数値以外は入れられないようにしますよ。なんなら上下ボタンで値の増減もしますよ。 みたいに理解できる。 ちなみに上の例にはわざと<label>を追加してる。なぜかというと設定ファイルにあるタグはすべてが 入力項目とは限らないからだ。既存の設定ファイルでもコメントでどんな値を入力すればいいかなどの説明が書いてあるだろ? すべてのタグを入力項目として扱えない。どうせそのことが抜け落ちてるんだろうからさ >>521 > fooの型ってなんだよ ← 分かる > boolだよ > boolって言ってもいろいろあるだろ ← 分かる > true/falseの大文字小文字区別なし、[Tr][Rr][Uu][Ee]だね > radioboxか?checkboxか?selectboxか?何で扱えばいいんだ? ← 分からない > 好きにしろよ… それなw 型だけじゃどう表示すればいい変わらないよね ということで>>522 は間違っていたので訂正 Itemsはなんのアイテムかわからないので文字列の配列としてる <configurations type="Configurations"> <label>foo: <input name="foo" type="number" value="1" /></label> <label>Items: <select name="bar" type="Items" multiple="true" value="item1,item2" /> <option>item1</option> <option>item2</option> <option>item3</option> <option>item4</option> </select> </label> <label>baz: <input name="baz" type="checkbox" value="true" /></label> </configurations> 全然話違うけど設定ファイルをスクリプトにするのってどう思う? メリットもあればデメリットもある。いちいち騒ぐほどのことじゃない。 >>524 ドキュメントついててわかりやすかったらなんでも良いと思うよ。 >>527 誰に感化されているのか、本人なのか知らないが、 ドキュメントはあくまでドキュメント。インストール方法からアプリについて必要なことを書くべき。設定ファイルを含む。設定ファイルに書いてあるコメントだけで設定しようと言うやつはものぐさなだけ。 そもそも設定が必要なアプリもインストールと対して変わらないが。 >>528 そもそも設定ファイルにコメントっているの? >>531 「開発者が」か やっぱりそこに開発者とユーザーの温度差を感じるんだよな ドキュメントは読まなくても使えるようにするのが良いソフトなわけで ドキュメントとついてるからOKだろって発想が このスレに合わせて言うのなら思考回路が40年前と同じレベルw 設定はデフォルトで不満だったり、変更する必要がある時に変更するので、設定ファイルを編集する時点でドキュメントを読む必要がある。 これを読んだことがなく設定を変更するにはブログや本等の二次情報に頼るか、GUIの機能を使う。 設定ファイルのコメントが読まれる状況は本人か、ハードユーザーになるのでそれ向け。 一般に普及してるのはWindowsなのでドキュメント文化が根付いていないのは仕方ないと思うが、Linuxを使うのであれば、一次情報のドキュメントを読むべき。 Windowsはドキュメントが不十分すぎてoffice使うのも教室通ったり、本屋で本買ったりするだろ。 ドキュメントがるソフトであれば、それが不要になるてこと。それがオープンソース。 これは最大の強みだから昔と同じでいい。 Windowsだからドキュメント文化がないんじゃなくて 家電でもスマホでもゲームでも自動車でも同じでしょ? ドキュメント読まないと使えないから仕方なくドキュメント読むんやで >>535 お前がドキュメント読まないで使ってるソフト ブラウザとか5ちゃんねるブラウザとか ほとんどのスマホアプリとか >>534 マジレスするとWindowsの方がドキュメントは充実してる >>537 ブラウザもスマホアプリも専ブラも始めに使い方を調べるだろ、もしくは小学校で学ぶ。パソコンが普及したときはクリックってなに?から始まったんだぞ。 直感的に使えるということであれば、他のアプリを真似て作ってるだけ。 家電の話でも使ったことないやつは洗濯もできないやついるだろ。ママに教わらないとできない。 ママが近くにいないときは取説を読め。 >>539 でもドキュメント読んだことないでしょ? 教室通ったり、本屋で本買ったりして使えるようになるんだから >>540 全部のドキュメントを読むということはない。設定ファイルをいじるようなときにだけドキュメントを読むって話。拡大解釈してないか? >>541 その読むべき項目が、設定ファイルの設定項目の上に 書いてあれば、便利じゃないですか? 俺が >ドキュメントついててわかりやすかったらなんでも良いと思うよ。 って書いたのは、コメントでもなんでも文章で説明されてればってことなんで、単語に引っ張られてミスリードしないでくれ。 設定ファイルからコメントが取り除かれてる場合はハードユーザー以外はいじらないでくれって暗に示してる時もあるから絶対コメントがあったほうが良いって話じゃない。 開発環境が云々ってスレでドキュメントがあるアプリが良いって意見はそんなに不自然ではないと思うがな。 自分がしたい話題にのみ焦点を当てて他人のレスを曲解するのは良くないぞ。 設定する項目の上に、説明が書いていれば便利だけど 英語だったら便利さ半減なんだよな。読めない人が大半だし。 だからLinuxではみんな技術書を買って使い方を勉強するんだろう LinuxはMacやWindowsと違って対象ユーザーが一般向けじゃないからな。 一般も別に使ってもいいけど、いじりたければ自己責任の世界だから。 ubuntuなんかは企業が入って開発者とユーザーの間に入っていろいろやってくれてるけど、無料じゃ限界があるだろ。 >>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属性は入力する値の種類を意味します。 設置ツールは適切なインターフェースを使用してください 終わり。たったこれだけw >>567 値の種類とは?何種類あるの?勝手に増やしていいの? 適切なとは?何が適切でないとどうやって判断するの? 疑問一杯で仕様書とか読んだことも無さそうにしか見えないけど? >>567 このレベルが仕様だと思ってるようでは話が通じないわけだ >>556 お前は何が言いたいんだ? HTMLはXMLベースではないのだから「XMLの仕様に準拠します」と書くことができない。 だからXML相当の仕様に加え、XMLには不要なHTML独自の仕様がたくさん含まれてる 例えばタグを省略したときのルールや、不正なタグ場合の解釈の仕方などだ 汎用のXML設定ファイルには、XMLの仕様を含める必要がない ただ一言「XMLの仕様に準拠しますと」書けばいい 汎用のXML設定ファイルの仕様だけあればいい だからどう考えても、 HTMLの仕様の量 > 汎用のXML設定ファイルの仕様の量(XMLの仕様は含まない) になるのは明白なんだが >>568 だから、仕様を作るだけですよね? >>569 何が足りないのか、言ってみたら? その量がHTMLの仕様の量を超えるまで待ってるよw >>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 また何の根拠もなくブラウザより大きくなる(笑)か 何が大きくなるのー?w ブラウザがどれだけ大きいかしらないのー?w >>598 HTML5で素数だけ入力可とかできるの? お前は設定ファイルで素数だけ設定したことあるのか? そんなマイナーケースまで対応しようとか考えるから 仕様がぶくぶく太っていくんだぞw 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は設定できる値のリストとか正しくない値を設定しようとするとエラー返すとか普通に出来てるんだよなぁ 画像見せて ぱっと検索した限りでは、単なる名前と値の羅列しかないですね。 これみてエンドユーザーに設定させろと? 無理でしょ。各アプリが丁寧に作った設定画面と どれだけ差があると思ってるのさw >>613 何度も言わないと本当に理解できんのなw 大前提としてアプリケーション側でチェックしてあるんだから、 設定を読み込ませれば、エラー出るっていってんの >>612 前提としてツールの実装によっては 滅茶苦茶な値を設定してもスルーされるという話を無視するなよ 簡単に編集出来ても滅茶苦茶な値で喜ぶユーザーいるのか? >>609 > この設定XMLとツールで汎用とはどういう話? 汎用のXML設定ファイルの、汎用とは別のアプリでも同じXMLスキーマを利用できること (いっとくが利用できるのはスキーマだけだぞw) >>615 アプリで読み込ませるまで滅茶苦茶な値入れても気づかない ツールが何が嬉しいの? >>616 > 前提としてツールの実装によっては > 滅茶苦茶な値を設定してもスルーされるという話を無視するなよ 現状だって、テキストエディタで編集したら メチャクチャな値を設定してもスルーして保存できるじゃん。 アプリケーションに読み込ませたらエラー出るっていってんの >>619 設定ツール使っても何も便利にも改善もされてないけど何か意味あるの? >>618 > アプリで読み込ませるまで滅茶苦茶な値入れても気づかない > ツールが何が嬉しいの? ユーザーが簡単に設定変更ができること メチャクチャな値を入れたらアプリでエラーが出る メチャクチャな値を入れられない所はエラーが出ない >>620 > 設定ツール使っても何も便利にも改善もされてないけど何か意味あるの? ユーザーが簡単に設定できるようになるので意味がある。 君の話だと設定項目のウィジェットかどう実装されるかは決まってない バリデーションもやらなくてもいいしエラーが出るかもわからない。 えーとテキストエディタに比べて嬉しさどこにあるの? >>621 滅茶苦茶な値を入れるのを防ぐ保証ないのに 滅茶苦茶な値を入れるのどうやって防ぐの? >>623 汎用のXML設定ファイルとして仕様が共通化されてるので 設定ツールを含めさまざまなツールやライブラリを作って 共通で利用することができること またそれらのツールやライブラリを使ってユーザーも開発者も 便利で楽ができること >>624 テキストエディタで設定ファイルを編集することを考えればわかる。 設定ファイルの編集は可能だが、アプリケーションでチェックが行われる >>625 ツール作ってもツールが何できるかわからないし 期待していたことが期待外れも余裕であるんだろ? 役立たずのツールが作れて何かメリットだって? >>625 いよいよ壊れたレコードのように同じことを繰り返すしか能が無くなってきたな 40年経ってもwindowsレジストリの素晴らしさが理解できないのか。 >>624 結局作る側はユーザーが手で弄ったりする事も考慮して自分でも値のバリデーションをしないといけないもんな なんつーか本当にものを知らないガキの妄想だよな 汎用ツールの特徴は ・開発者が楽できる(汎用ツールの仕様に合わせて開発すべき) ・ユーザーフレンドリー(直感的?アプリの仕様に関係なく設定はブラウザに似たインターフェース) ・設定ファイルがguiコーディングも兼ねる。(設定ファイルでインターフェースを描画し、値を変更したものを保存する) これだけでもクソ仕様だとわかる。 >>630 これずっと思ってたわ この人設定と設定の設定の区別がついてないような感じよね 引用忘れた > ・設定ファイルがguiコーディングも兼ねる。(設定ファイルでインターフェースを描画し、値を変更したものを保存する) テキストファイル書いて設定させるなんて昭和末期か平成初期には通用したけど、いまじゃデメリット多くて古くさいってバレバレの手法だよねw >>634 設定が多段のツリー構造になったことで柔軟に構成できる(限度はあるけどフラットなテキストファイルより使い勝手は良い) パス、キーが判ってれば値の取得と更新はOSにリクエストするだけで済む。 独自ライブラリでR/Wしなくて良いしOSのバージョンが変わってもアプリには影響ない(APIが互換性保つかぎりはw デメリットとしては「設定を保存するエリアにコメントを書けない」ってのがあるね。 レジストリがテキストより編集しやすいかは習熟度によると思うぞ。慣れたらテキストのほうが見通しが良いし、わかりやすい。 レジストリとかgconfとかって機能してない項目が大量にあるのはなんでなん? >>631 > この人設定と設定の設定の区別がついてないような感じよね わかった上であえてそうしてるんやで。 なぜなら、設定ファイルをテキストエディタで 修正したいという層が一定数いるから テキストエディタで修正しないんだったら 設定ファイルにコメント機能なんていらん。 コメントはまさに、設定ファイルにUIが含まれてるってことなんだよ それみてどんな値を入れるか判断しているわけだから 設定値と設定UIを作り出すタグを分離すれば、 今度はテキストエディタで修正したい人が使いづらくなる UIがどう表示されるか規定されないし 個々のフォームがどういう挙動するかも不明で 使いやすいのかというか実用になるかもわからんけどな > UIがどう表示されるか規定されないし HTMLだってそうだよ。 そもそもどう表示されるかはデバイスによって異なる PCで使いやすいUIがスマホでも使いやすいわけじゃない なんでこうすでに通り過ぎた歴史の話ばかりするだろうか? 現実を否定しているところから始まってる妄想だから現実離れしてて現実的じゃないのは当然やろうな。 こうだったら良かったのにというボヤキなんだろうが、ボヤキにしても無知を晒してるだけだからな。 アイデアとしてはわかるんだよね。 東芝が昔実験的に作ってた。 XMLスタイルシート的なアイデアは大昔から存在するんだが、実用的なものを構築するのはなかなか難しいと思う。 HTMLが規定されてない、という部分を都合よく拡大解釈するし 不味いところは逃げ回るし >>642 なんで現実にある問題点と解決策を言ったら、現実離れになるの? その理屈だと、効率が悪いと指摘するだけで 効率が悪いのが現実なんだ。現実離れしたことをいうな!ってことになるけど? >>644 拡大解釈だろうがそうでなかろうが、 どちらにしろその解釈に反論できないんでしょ? 少なくともUIの意味論的な話で共通理解が無いと実際に実装は無理。 その規約決定を放棄してお前の頭の中でだけそんなのわかるだろでは話にならない >>648 > 少なくともUIの意味論的な話で共通理解が無いと実際に実装は無理。 何が言いたいんだかさっぱりわからん。 HTMLの仕様とか見たこと無いのかな? UIをどうしろとか書いてないよ W3Cは戦場なので、力あるものが勝つし、勝ったものが正しいとは限らない。 裁判と同じだよ。 エンジニアなのに教祖への愛がすべてなのが、ウェブの未熟さを表してるんだよ。 >>645 現実にある問題点はconfig.xmlに独自タグが多いってだけのこと?他にある? ウェブ業界には勉強会と称して毎週ミサがあるだろ。 お互いに啓蒙しあい信仰心を深める。 最後にみんなで歌を歌って解散。 まさにイカ臭い新興宗教じゃないか。 二言目にはHTMLガーであるがこいつが想像してることは JavaScript・CSS・サーバサイドその他HTTP技術が関わっていのに XMLの話だけで設定ツールへのその部分の押し込み方が全く不明 >>650 >>648 の言いたいことがわからないのは読解能力がないから。お前の妄想をなんとか理解しようとしてるみんなは表現力が乏しい文章に根気よく付き合ってるから。 実際それっぽいのはweb技術に寄生したらelectronですぐ作れるけど、今度はアプリケーション側がhtmlスクレイピング並みに頑張らねばならなくなる。どこに得があるんだって話だよ。 そしてすぐ作れるものを誰も作ってないってことは、もう言わなくてもわかるだろ。 本当に役に立つならすぐ作っちゃえよ。それで飯くっていけるぞ。 Windows 使ってないからレジストリについてググってみた。 Windows を使わない理由が増えた。いや、今更だが…… アホやろ 移植性が段違いじゃんか それに世界中に使ってる人がいるってことも 無視しとるやんけ、自分が無能なだけや 正直、C89以前のCなんか読めたものじゃないし、 かといってC++11以降の機能使いまくったソースも読めたものじゃない。 >>637 嘘だよ。初心者に優しいのは、テキスト編集だよ。 英語が苦手なだけでしょ。 マウントなんて、大分前からクリックするだけやんけ それよりディスクの故障チェックもできないとか、そっちのほうが怖いよ >>633 へー、今はむしろナウいんだけどな 取っとけるし 見通しがよいかどうかはシステムのサイズによる。複雑になれば階層構造のレジストリのほうがいいに決まってる。 基本的な型は用意されてるし、細かくセキュリティも設定できるし、読み書き用のAPIも用意されてる。 OS起動時に必ずバックアップを取ってから起動してくれるのもメリット。 なんでもviで作業したいというのが諸悪の根源。開発環境が50年前とい言われても仕方がない。 >>665 英語苦手じゃないけど、ちょっと言ってる意味がわからん。とりあえず、レジストリはめんどくさいぞ。 レジストリより環境変数のほうが使いやすいよな!!! って人は少ないだろう。 みかんとしいたけだったらみかんのほうが美味しいよな 何も足す必要がないということは究極を極めているということであろうか。 xmlの優位性はテキストだということだけれども、実際テキストエディタでxmlを閲覧すると醜悪そのものだよね。 >>4 Windowsのビルドって、どれぐらいかかるか知ってる? >>669 そういう意味なんだけどね テキスト編集の方が楽だけど、設定ファイルの雛型に 書いてある説明が英語なのは、日本人にとって辛いかなと 慣れればなんてことないけど。 ちなみに勘違いしてるみたいだけど autotools 作ったのはGnuではないよ。 自動的にMakefile作るシェルスクリプトが回覧されていく うちに、みんなで改良加えて、なんとなく出来上がったのを Gnuが採用しただけだよ。移植性を重視してたからね。 別に好きな奴使えばいいんだよ。気に入るのが無ければ 自分で作ればいい。それが自由であることの尊さなんだから。 autotools使うのは、それだけ多くのライブラリに依存 しているからで、その分のコードを書く手間を 省けるのだから、大したことでは無いね。移植性も 高まるし。でも、それが必要ないなら、別にMakefile添付でも 全然問題ないし、そういうプロジェクトも少なくない。 他のビルドツール利用でも良いし。なんか 勘違いしてない?これらはあらかじめ与えられてるん じゃなくて、享受するものだよ。嫌なら自分でやるんだ。 近所の落ち葉をかたずけるのと同じさ。君のために 誰かのためにやるんだよ。そう思うなら、自分で どうにかするんだよ。 良いこと言うね、全くそのとおりだわ 読んでねーけど INIのように書式とデータ構造とAPIが共通化されてるテキストベースの多層構造の設定を保持するメカニズムがあればよいんだよ、Linuxに。 ハイ論破厨ってたまに5chで見るけどいつも論破できてないよな。同一人物? 「ハイ論破」はダサいという風潮はとうにご存知だが必要不可欠な機能 C/C++やPerlのセミコロンみたいなもの 私たち日本人の、日本国憲法を改正しましょう。 『憲法改正國民投票法』、でググってみてください。 平 和は、勝ち取るものです。拡散も含め、お願い致します。 >>684 あなたは、日本人じゃない気がする。 日本人なら絶対しない「ご存知」「機能」の使い方してるから。 へー、LinuxにはJSON読み書きする「共通化されたAPI」ってあるのかぁ。 知らなかったな。 Cで使おうと持ったらインクルードファイルは何をしてして、どんな関数呼べばいいんだろう? 定番のunistd.hかな? JSONってそんないいもんじゃないよね、コメント書けないのは致命的 jsonが爆発的に普及したきっかけはバイナリ保存はしたくないけど、オブジェクトをそのまま保存したいって需要だから 設定に使うとしても開発者よりなんだよな。linuxは開発者フレンドリーだから開発者マインド無いときついってのは理解できるけども。 階層が深くないならiniが見やすくていい 階層が深いならyamlだし、記述性ならxmlだし、どれも一長一短あるけど、テキストエディタで開く設定ファイルならiniは使いやすい 複数行コメントを書けて、日本語も問題ない、Ruby が良い =begin 複数行 コメント =end Windows界はいろんな産業ロボットを使ってモノを生産しているのに Linux界はいまだに手作りでモノを生産しているようなもんだからね。 >>1 Unix は世界最古のOSらしいので、最初は良かれと思って決めたものが、 使ってみると使いにくかった、ということはあるかもしれない。 一例として、 $ コマンド名 パラメータ >a などとして、リダイレクトするとき、stdout と stderr が分かれている のも、現実的には不便。 $ . スクリプト名 と先頭にピリオドをつけないと環境変数がスクリプトによって設定できない のも不便。 どちらも、DOS では修正されていた。DOS の方が後発だから。 資本制企業はいかに人件費を削って量産するかを常に考えている。 少ないプログラマでより多くをと。 ところがオープンソースの世界はコーディングすること自体が楽しい って人々の集いだからな。効率化へのインセンティブが小さい。 >>697 別の環境変数で処理したいなら別の端末を開けば良いわけだから、 スクリプト内での設定を反映しないという仕様は、今となっては アリガタ迷惑だと思う。 ただ、行儀の悪いわけの分からんスパゲッティーで解読するのも 時間の無駄なスクリプトも多いが。 >>697 stdout と stderr と時系列的に合わせて出力しないと、解読しにくい 場合があるので、結局、2つの出力を合成したいことが多く、 1&>2 a だったか、覚えていられないような変な記号を書かなくてはならない。 あと、tee コマンドも覚えにくい。 というか何もかも覚えられない 脳が退化しているのか? &> a と、 1>&2 a の両方の書き方があったり、export が必要あったり無かったり、 そんなアホみたいなものは、むしろ高級な脳であるほど覚えられない。 高級な脳は、共通原理や一般法則だけを覚えようとし、単純で無意味な情報は 削除される傾向があるから。 >>1 なんという愚かなOSなんだろう。 DOSと同じことがこんなに長くなる : [DOS] $ コマンド名 >a [Linux] $ コマンド名 1>a 2>&1 >>703 > [DOS] > $ コマンド名 >a ↑間違い > [Linux] > $ コマンド名 1>a 2>&1 ↑1は不要 正しくはこうだよ [DOS] $ コマンド名 >a 2>&1 [Linux] $ コマンド名 >a 2>&1 参考 http://tooljp.com/windows/doc/stdout-stderr/stdout-stderr.html > (4)標準出力と標準エラー出力を同じファイルにリダイレクト > mycmd.exe > stdout-stderr.txt 2>&1 >>705 DOS に関しては、そもそも原則として多くのツールが、stderr を使わない流儀 だったので、stdout だけをリダイレクトすれば十分だったんだ。 だから、その意味で、 [DOS] $ コマンド名 >a は間違ってない。 要は、トータルの使い勝手で考えた場合だから。 ほらほら、間違いを指摘されて、 焦ってきてるぜwww つまり、DOSコマンドは設計に沿わないアプリが多かったということかな? >>709 いや違う。 最初からそれを前提にしていたので間違ってない。 あなたは、DOSの事知らないからそんなこと言ってるのでは。 >>710 いや、むしろ、stderr を滅多に使わないのがDOSの流儀だった。 少なくとも、コンパイラのエラー表示は100%、stdout に出ていたし、 その他のフリーソフトなんかの表示もほぼ、そうだった。 使いにくくなるだけなのに、stderr を使っているソフトが多いのは、Unix系の プログラマには、実は真の意味では頭の悪いのがいっぱい混じっているから ではないか。 明言していない前提 他社を憶測で知らないもの扱い ごく主観的な流儀 主観的な使いにくさでOSの草分け的な開発者を無能扱い これだけでまともに取り合う気がなくなる。 元々、stdoutとstderrが分れているのには理由がある。 理由もなしに分けたりしないという想像力があれば憶測でモノを言うと恥ずかしいことぐらいわかりそうなもんだが。 標準出力がUIを兼ねていたのでユーザーへのメッセージがerrで塗りつぶされるのが良くないし、 出力結果を次のコマンドに渡すときなどにerrメッセージが混ざると困るし、 コマンドが入力待ちの状態の時、errなんか出たらなにで止まってるのかわからないからな。 当時は無視するしか無いerrもあって切り分けるしかなかった。 例えば標準出力をファイルを書き込んでる最中にエラーを出力するにはstderrに出すべきだろ。 それを使いにくくなるとは。。。 >>715 コンパイラの出力をパイプで渡していくのは時代遅れだと思う。 今は、ファイルに書いて渡せば良い。 >>714 古い時代とはまた違った、今の時代に合った CUI の流儀がある。 Unix好きの人には、古いものを維持し続けようとする人が多すぎるのか、 または、古いソースを使いまわし続けすぎているためか、古い流儀のまま になっているために効率が下がっている。 >>716 ファイルに書いて渡すと遅くなる ディスクが遅いとかいう話じゃなくて 並列処理ができなくなるという話 >>719 実際のコンパイルは、a1.c, a2.c, a3.c, ・・・ などを別のCPUコアに渡して、 マルチコアでコンパイルするので、既にCPUコアが完全に使用しきられている。 なので、それ以上、コアに空きが無いので、パイプを使っても並列度が 上がることはほぼ無い。 一方、いったんファイルに書いてもファイル・バッファにキャッシュされ、 実際のディスクへの書き込みは、全く行われないか、または、ずっと後 になってから行われ、コンパイル作業中にはRAM上でデータの受け渡し が行われるためディスクの遅さは全く関係しないと言っても過言ではない。 >>720 パイプを使っている今はね。 ファイルを作ると遅くなるって言ってるの 今のやり方が最適なの。だからCPUコアを使い切れている >>721 パイプを使っても、0.000001% 位しか速度差が出ないのに、 gccなどのコマンドラインはめちゃくちゃ使いにくくなる。 コンパイラのエラーメッセージは標準出力に出て問題ないだろ。*nix系でも出るぞ。何いってんだこいつ。 パイプを使わないと動画をリアルタイムにエンコード出来ない >>725 別にパイプを使うなとは言ってない。 そういうケースでは使っていい。 どうやら時代遅れなのはお前の頭だと気づいたようだなw 違うな。 古いものと新しいものを逆さに捕らえる人がいて困る。 そもそもstderrの使い方知らなかっただけじゃないの? >>729 そんなことない。 stderr が有っても敢えて使っていなかった DOS の選択は賢いと思ってる。 >>1 gcc や clang も、include path の設定が無視されることがある。 複雑に複数の言語処理系がインストールされている場合に、 include path が勝手に「コマンドPATHから推定して」 決められて しまい、それを修正したいために、環境変数などを設定しても 優先順位がおかしくて、なかなか修正されないことがある。 しかも、その状況を確認するには、-v オプションを付けて 出てくる長いメッセージを解読しなくてはならない。 また実は、バイナリになってしまってからは修正すること が難しいパス設定が存在することもある。 その場合は、ソースから make する際に、./configure のパラメータで決められてしまっている。 つまり、バイナリレベルでは、動作が変えられるように 出来ていない欠陥品が多い。 $ prog1 | prog2 | prog3 > job1.out $ # で済むところを $ prog1 > tmp1 $ prog2 < tmp1 > tmp2 $ prog3 < tmp2 > job1.out $ rm tmp1 tmp2 $ # ってやるのか? >>732 最初のようなパイプでつなぐような表記を、コマンドラインから打つこと自体、問題なんだよ。 むしろ、ファイル名を指定して、少しずつ進んでいくほうが賢い。コマンドラインからだと。 型のあるプログラムだとコンパイラがエラーを出してくれる確率も高いが、 コマンドラインからだと、わずかな間違いが重大な問題に発展しやすい。 それに、どうせ、打ち間違える確率が高いので、何度も試すことになり、最初から 実行し直しになることが多い。 $apt-cyg show | grep -i nantoka や $コマンド名 | less みたいなことやら無くちゃならない頻度が高すぎ。長すぎて馬鹿だ。 こんな設計思想、ダメだ。 正直期待してなかったけど、初めてまともな返答をしてくれたね。 君は自分が世界の中心ではないということを理解すべきだ。 君のために存在するものなど何もない。 それでも適切な方法で助けを求めることはできるはずだ。 〇〇をうまく使えないという理由で〇〇の作者の頭が悪いなどというなら 誰も助けてくれないし君にとって良いことなど何も起こらない。 まあ、それはそれとして、シェルのヒストリ機能や行編集機能は使ってる? ターミナルエミュレータの copy&paste は? これらを使ってもまだ大変だと感じるなら Emacs なんかが助けになるかもしれない。 You! Visual Studio codeをinstallしチャイナyo! #ifdef なんかも設定に応じて認識して、ちゃんとコードの色に反映してくれるからねえ。 バランスが取れておらず、かつ、統一感もない。 それが Linux。 また、安さ以外に売りが無いのに最新のハードと最高の通信環境を要求する。 最新のハードを要求する前に、最新のハードのドライバを用意したまえ。 WINE もバイナリは新しい Linuxを要求するのに、Emulator としては、 64BIT Windows はサポートしていなかったりする。 つまり、新しいハードでしか動かないのに、古いOSしかエミュレートできない。 訳分からん。 あたらしいプログラムはPowerShelも対応するようにして 徐々に移行していったらええのに 貼れと言われた気がした 【田】Windows10のダメな点 ・個人情報を勝手にネットに垂れ流す ・診断データと使用状況データをMicrosoftに送信する機能をレジストリでオフにしてもなお8時間で4000回、93つの異なるIPのMicrosoftサーバへデータが送信されている ・エロファイルを持っている場合はそれも全て晒される ・間違ってロリファイルを持っていた場合はネットに繋いでいるだけで警察が来る ・死ぬほどUIがダサく異様に使いづらい ・ダサい上に抑揚のないフラットデザインのため、どのウィンドゥが手前で奥なのかわからない ・かつてあった多くの機能の半分以上をカットし、使わない機能をてんこ盛りにしたデブOS ・起動が超遅い。見かけ上早く起動したように見えるだけでほとんどのソフトを読み込んでいない ・スリープ復帰速度はほとんど変わらず ・ファイル圧縮・解凍速度も遅いまま。フリーウェアの圧縮・解凍ツール使ったほうが200%以上高速化する ・ファイルコピー速度が壊滅的に遅い。フリーウェアの高速コピーツール使ったほうが400%は速い ・メモリ使用量が馬鹿みたいに多い。初期は少なく見えるが使えば使うほど多くなる ・タブレットでも動くように設計されているが、利便性もデザインもiPadの足元にも及ばないゴミ ・標準ブラウザにEdgeとかいうゴミを採用。機能が少なすぎる上におそろしく遅くて使い物にならない ・無料のセキュリティソフトと称する重いウィルスソフトが多数憑依している ・仮想デスクトップと称するゴミを搭載。フリーウェアの仮想デスクトップソフトの半分の利便性もない。 ・Win8で削除したスタートボタンを恥を忍んで復活させた ・しかしスタートメニューにまつたくいらんメトロや宣伝がゴチャゴチャついて無駄に肥大化、邪魔。機能性がない ・非アクティブウィンドウもスクロール可とかいう、昔からできるような機能を大げさに宣伝 ・タッチパネルとして使いやすいUIとして喧伝しているが、デスクトップPCで画面の汚れるタッチ操作を行うのはよほどの馬鹿だけ ・ダサくて見づらいゴミフォント「游書体」がデフォルト設定 ・ほとんど反応しないゴミ丸出しの音声認識アシスタントCortana搭載。画面に向かって話しかけているぼっち野郎の姿はバカそのものw リダイレクトやら、 パスに文句言ってる人がいるが、 OS の問題じゃなくてシェルの仕様の話だろ シェルを変えればいいだけ パスの書式だけならそれで何とかなるけど、構造だけはどうにもならない事がある \\PC名\共有名\〜 みたいな表記はCreateFileとかに直接投げてそのまんま動く位、 ファイルシステムの構造とそれを実現する為の実装に密接してっかんな VSCodeが出たから、 「やっと、やっと、まともなIDEがLinuxでも使えるようになった! MSがやってくれた! ありがとうMS!」 ってことなんだろうね。 IDEを使ってるのではなく使われてるレベルなんだろーな 別に自分の好きなようにやりゃいいだけだろ Linuxの開発環境はVSCodeが出る前は vi使え! とか大声でいうやつがマジで居たぐらいに貧弱だったな。 環境改善に尽力してるMicrosoft様々だわ。 >>749 Kateでイイじゃん VSCodeだと、テレメとってくるから VSCodium入れてっけど Kateばっか使ってる >>751 VSCodiumの作者が、そう言ってて わざわざ毒なしのVSCode提供してくれてるから フィードバック提供しないって 設定すればイイだけなのかもしれんけど デフォルトでOnになってるし Officeもそうだけど、そういのばっかり 熱心にやってきて なにシレット仕込まれるか分かんないから VSCodium入れてる >>752 マジか。 MSは中国並みに情報収集熱心だな。 中国は国策でやってるわけだが、アメリカもなんぞ法律でもあって情報集めろってやってんのか? >>753 なんなんだろうね ほんと ヨーロッパだと、そいうのわりと敏感で 問題になってるみたいだけど 開発環境云々もUbuntu Japanese Teamによる志賀慶一氏のライセンス違反認定が取り消されないのも、 全部無能な鍋田コピペのせい。 鍋田コピペが悪い。 >>754 ね 国によってフィードバックのデフォルトに変化があったりするのかね GCC使ってる時点で性能をスポイルしてるからね。 40年前と同じで問題ないのさw VSCの中の人じゃないが、テレメがあるとしても基本的にはどの機能がどれだけ使われてる とか、デバッグ情報とかそんなんじゃないかな。"ユーザーエクスペリエンスの向上"のため。 そういうのも集められるのはイヤ、と言われるとアレだけど。 たまにハックしたバージョン入れててそれがクラッシュして、そういうユーザーに限って SNS等にキレた書き込みをしたりw そういうのもクラッシュトレースを見れれば安心w 今時のOSって、いろんなことを登録するじゃん。あれとかね... ま、あからさまに個人情報を集めたりしてそれがバレると今時大変なことになるからなあ。 cmakeとか、masonとかninjaとか良く分からん >>751 VCですらMSアカウント必須になって久しいのにテレメトリ無いとは思えんな コマンドラインのコンパイラさえMSアカウント無いと使えないよ read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる