記事"グラフィカルインタフェースVI：スライダーとデュアルスライダーコントロール(チャプター 2)"についてのディスカッション
皆さんのコメントや提案に興味があります。
私は明確化が必要です。
- メイン・ウィンドウとセッティング・ウィンドウのコンセプトをどのように分けていますか？
- 現在のウィンドウの実装にどのような機能を追加すれば、"メイン "と呼べるようになりますか？
...
メイン・アプリケーション・ウィンドウをコンポジットにすれば、すべての開発者に「メイン」コンテンツを選択する機会を与えることができます。私見ですが、「コンポーザビリティ」こそが「メイン」アプリケーション・ウィンドウの特徴だと思います。
いずれにせよ、ウィンドウの機能を開発することに目を向けるべきだと思います。
そう思います。現在のライブラリ構造では、そのような機能を実装することができる。しかし、それを実装し始める前に、かなり美しくするために他の多くの問題を解決する必要がある。いくつかの選択肢が見える。どれを使うかはまだわからない。最もリソースを消費しないものを選ぶには、いくつもの実験とテストを行う必要があるからだ。
現在の連載の予定記事が掲載された後にするつもりだ。開発コントロールの観点から最も複雑で興味深いものが残されている。
というのも、現在のバージョンでコードを最適化 し、いくつかの追加や修正を行う予定なので、リソースの消費は大幅に減るはずだからだ。また、最適化とリソース消費削減の試みについて語るとき、最終的に何か利益を得られるかどうかはまだ未知数だという点もある。多くの時間を費やしても、ゴールにたどり着いたときにはまったく意味がなかったということもある。でも、それは怖くない。やってみなければわからない。;)
しかし、非常に興味深い質問の仕方だ...。個人的には、資源消費の最適化と削減が不必要であり、有害でさえあり、"ゴールライン "では役に立たないということは、私には思いもつかなかった。困ったなあ......。このトピックについて議論や論争ができるのは確かだが、私はこの側面からこの問題を見たことがないので、十分な議論を見つけられそうにない。
...
資源消費の最適化と削減は不必要であり、有害でさえある」というのは私の言葉ではない。私の場合、最適化は行わなければならないし、間違いなく利益がある。私はそれを実行し、結果が出れば記事にするつもりだ。今はまだ、それについて詳しく説明する十分な時間がない。
例えば、グローバルレベルで変数を見えるようにできるのに、なぜ関数に変数を渡すのか？関数ファイルを接続できるのに、なぜクラスを接続するのか？関数の相互接続や、 関数や変数にアクセスするためのクラス・オブジェクトの作成といった複雑なシステムは、ファイルには必要ない 。なぜ、ルールやさまざまな構文がごちゃごちゃと出てくるのか。それは、解決しようとする問題の本質から目をそらし、混乱させるからだ。
同じことを、OOPなしでやってみよう。すべてがこの通りに動くように。私はまずそれを試してみて、OOPなしでこのようなプロジェクトを行うのは、たとえ自分のためだけに行うとしても非常に難しいという結論に達した。今はこの構造でとても簡単にナビゲートできる。すべてが整理され、その場所にある。ライブラリーのすべてのオブジェクトと要素にアクセスできる。それらは互いに重なり合うことなく、アクセス可能な場所にのみアクセスされ、それぞれが独自の型と名前を持っている。どこをリファクタリングし、コードや一部のアルゴリズムを最適化し、リソースの消費を抑えられるかがわかる。
誰もが、提案だけでなく、いくつかの問題を解決する方法についても貢献することができる。私はすでに、さまざまなユーザーから、何をどこを修正すべきかについて、プライベートで多くの提案を受けている。英語のフォーラムでも、このライブラリに関するいくつかの設計ミスが指摘されている。私はすでに、リソース消費を増加させる少なくとも4つの要因を知っている。いくつかは明らかに不必要に消費しており、それらを排除することで結果が得られる可能性が高い。しかし、これらはすべて今のところ理論上の話でしかない。いずれにせよ、私たちはテストを行い、それを行って初めて、何らかの利益があるかどうかを言うことができる。
いずれにせよ、私はどのプログラミング方法が優れていて、どの方法が劣っているかという議論は無意味だと考えている。あなたの経験はあることを教えてくれるかもしれないし、他の人はまったく反対のことを言うかもしれない。人生は無限に多様である。;)
しかし、そのような順序は、その実装の特定の方法に縛られるものではない。機能性をクラスで分割することでプログラムの秩序を作るなら、機能性をファイルで分割することで同じ秩序を繰り返すことができる ことを知っておくべきだ。
順序はそうだが、異なるタイプの多くのオブジェクトへのアクセスや操作はそうではない。私見では、OOPの方がはるかに簡単だ。
列挙型や構造体をAS THESEとして作成すれば、それらはOOPのルールやOOPの構文に従う必要はない。その行をコメントアウトして「構造体A、要素のリスト：」と書けば、変数へのアクセスは単純化される。OOPは何かを順序付ける助けにはならないが、既製の順序付けスキームを書くための統一規格を 提供するだけだ。
なぜか？なぜなら、本格的な構造体を一度に作成し、そのインスタンスや配列、さらにはインスタンスの配列の配列を宣言することで、これらすべてを扱うことができるからだ。OOPでなくてもできるが、私の考えではOOPの方が便利だ。
また、変数が 構造体やクラスの外部にある場合、変数へのアクセスは どのように簡略化されるのだろうか？それどころか、OOPの考え抜かれた順序のスキームこそが、すべてを整理し、アクセス可能な変数とアクセス不可能な変数へのアクセスを簡素化するのに役立つのだ。
ここでは反論できない。OOPは一般的に受け入れられているので、あなたのライブラリーの開発は他のプログラマーに簡単に取り上げられるでしょう。そうなることを祈っています。:)
そのためにこのプロジェクトは始まったんだ。頭は1つで十分だ。;)
それが秘密でないなら、それはあなたにとって何なのか？
宇宙に尋ねなさい。私たちはその手の中の道具に過ぎないのだから。;)
虚栄心？
いや、満足だ。でも虚栄心ではない。理由はわからない。おそらく、私の頭の中にある未実現のアイデアやタスクの大群を部分的に間引くためだろう。また、記事を書くことで責任が重くなり、自分を律している。もともと自分のために書いたこのライブラリのコードを大幅に改良した。そして、これは限界には程遠い。
また、記事に対する報酬は、少なくとも費やした時間に対するささやかな報酬です。
頭は大多数が怠け者で、製品を作るための説明書や建材が入ったツールキットよりも、完成品の方がはるかに価値がある。 強制されることで、彼らはあなたのライブラリを使うだろうが、労力を減らし、コードを書かずにインターフェイスを作る機会を与えられたら、残念ながら、彼らはあなたの美しいライブラリをすぐに忘れてしまうだろう。これは、無私の努力と魂を捧げている誠実で高潔な人々に対して、社会が常に課している裏切り行為そのものになるだろう。
ほとんどの人はそうかもしれないが、すべてではない。私は彼らと分かち合っている。彼らが他の人々と分かち合うように。
ところで、私もグラフィカル・インターフェースを作る ためのビジュアル・スタジオを作ろうと思っている。このライブラリーの助けを借りて作る予定だ。マイクロソフトのビジュアル・スタジオで 行われているようなことをやりたいんだ。そして、もしかしたらもっと良くなるかもしれない。時間が解決してくれるだろう。いつものように、すべては小さな実験から始まる。最終的に何ができるかは自分でもわからない。)
私には、コミュニティが取引プログラム作成の実践において革命を起こす機が熟しているのに、あなたはまた新たな「アップグレード」を提供しようとしているように思えます。 しかし、私はあなたの幸運を祈っています。:)
もちろんそうです！だからこそ、私はこのすべてを公表することにしたのです。この方向性を修正し、さらに前進させるために。;)
なんという野心と楽観主義！！！私と同じだ...)))))
私だけにですか、それともアナトリーと私の両方にですか？
もし私になら、私は最近、ウィンドウ、スクロールバー、テーブル、特殊効果の基本的な機能を示した。
もちろん、あなたにも。アナトリーのよくコメントされているソースと、あなたのビデオで競争したいのですか？どんなカテゴリーで？)
プログラムを評価するには、少なくともデモ版が必要です。インターフェイスだから、それを感じる必要がある。
だから、"怖い競争相手 "について話すのをやめて、デモに移ることを強く勧める ;)
ちょっとした競争を期待していたんだ！:)残念だ。まあね。このコミュニティは競争心が弱い。マーケットでの競争について尋ねると「ない」と言うし、他の人のイニシアチブを応援して選手権を開催しようとすると「参加者がほとんどいない」と言うし......。つまらない話だ。
今後の記事も必ず見ます。頑張ってください。:)
品質と機能性を競いましょう。
それに、私はすでに18の 記事を発表している。18 手だ。いや、あなたが決めた18 ゴールだ。そして、あなたはまだ1つも決めていない。少なくともあと7つは 約束する。1点差のゲームだとあまり面白くない。;)
- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索
新しい記事 グラフィカルインタフェースVI：スライダーとデュアルスライダーコントロール(チャプター 2) はパブリッシュされました:
作者: Anatoli Kazharski