Debian GNU/Linux スレッド Ver.93

WindowsUpdate

何度も書くけどお前プログラミングしたことないだろ

プログラム関係の技術用語それっぽく並べても現実と対応しないから全く意味不明なの

waylandの色々な情報おつかれさま

「使う様にできる上にそうなってる」のと「使う様にできるけどそうなってない」のは全然違うぞ

内容は何となくしか分からないけど、２人の主張するテーマとここまで熱くなった理由だけはよく分かった
簡単にスレチとは言い切れないし激論も止む無し

全部Cでやるってんなら「基本クラス」を「機能の派生元のコントロール」に置き換えろ

ところで機能の派生元のハンドラを無理やり実行させない方法は今思いついた様な気がする
が、元のコードが終了時に多重開放とかしそうで上手く動くかどうかはわからん

先ずは機能の派生元のコントロールが保持している子コントロールのハンドラと、
機能の派生の為のコードが後から追加したハンドラの処理順序をはっきりさせろ

てかなんでX（Wayland）の上にコモンコントロールの類が無くて
ツールキットの類がそれぞれ自前で実装してるかってったら
WindowsやMacみたいなメッセージキューの類がないからコンポーネント化しづらくって
誰もやりたがらないんじゃねーの？としか思えん
仮にできるにしてもとんでもなく工数が掛かるとかじゃ現実的じゃない

レポジトリつかってればfix受けられるが、自分で入れたらどうなる？

それファイルダイアログみたいな原始的な奴だけだろ

Xのコアの話ってググって出てくるのか？

キューを持ってるのはXのクライアントじゃなくってXサーバだって事位わかってるぞ
だからXの場合はネットワーク越しに飛んできたイベント以上の事を知る事はできない

CSpinButtonCtrlに貼り付けられてるエディットコントロール（こいつはCSpinButtonCtrlが内部で生成してる）が
フォーカス受け取った時とかにCSpinButtonCtrlからの派生だけでエディットコントロールへの
イベントを処理した上で、更にその派生クラスがWM_SETFOCUSを処理できるようになる

レベルが低くて失笑ものなのは承知での質問何だけど、それが出来ると何か便利になるの？
実用的な例を上げてくれるととても嬉しい
(お陰でWindowsの○○では●●と言う操作が出来て大変有用だが、
Linuxの同類アプリ■■では残念ながらそれが出来なくて非常に不便だ。
みたいなかみ砕いた話もしてくれると実に面白いと思う)

> WaylandのAPIはWindows上だと非公開APIであるDWM.exeへのAPIに対応するもの
> DWM.exeがwestonやmutter等のWayland Compositorに対応する

ツールキット類を実装する人はそれを直接叩けって？
んなわきゃねえ
更に付け加えると事実上xlibがuser32.dllみたいなもんだろ

おまえら仕事できてもともだちできないやつらだろ

相手してくれてありがとう
KDE好きだけど、しばらくGNOME on Waylandで過ごすわ

あ
すまん

的外れなことを言ってるバカが、実際にはVBか何かのポトペタコピペしかできない無能なんだろうなあと
Xlib で書けるだけでもエライこっちゃ。。。

10.2 ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

waylandなんて使い物にならないから使わないだけ
まだ少しはましになっただけだろ

片方は脱線しつつも有り難い最前線のDebian情報提供してくれたけど、もう片方はもう全然このスレに関係ないよね
せめてWindowsでは○○が出来るけどDebianでは●●が出来ないから▲▲すればどうだと言う書き方にすればいいのに

それは与えるものがある奴が言うことだ
お前がUbuntu使ってろやｗ

大体NGにはしたけど
nvidiaがガン無視してる内はWaylandとかどうでもいい

俺は現場のSEじゃないから野蛮で低レベルな切り口でしか話が出来ないけど、Xはまだまだ使われるもののもう過去の遺産の為の維持営業になって、余計な拡張を削ぎ落としたWaylandにリソースが注がれる世の流れなんじゃないの？
で、貴方の言いたい事は俺みたいなシロートでも分かるように言い換えるならば、「ライブラリの類がLinuxはWindowsに比べて汎用的な実装が遅れてるから良いところは取り入れた方がいい」と言う意味で解釈した。
現場の人間ならではの熱い議論と提案、実は興味深かった。今日の激論、掘り下げるとすごい勉強になりそう。
ありがとう。激論は自治警察に睨まれない程度にね。

> まーwaylandはまだあちこち問題があるみたいだし、何よりネットワーク透過の為の部分を削って
10年以上前からLinuxのXクライアントはMIT-SHM拡張を前提とする実装になっているから
事実上ネットワーク透過でなくなっている

今のLinuxはXサーバとXクライアントをリモート用のBSD socketではなくローカル用の
Unix domain socketでつなぎ、MIT-SHM拡張による共有メモリを使ってXImageやPixmap等
イメージをやり取りしている
ttps://www.x.org/releases/X11R7.7/doc/xextproto/shm.html

ちゃんと実装されていればローカルでもリモートでも動作するが、リモートだと動作が大幅に
遅くなるし、リモートだと動作しないXクライアントも多い

10年以上前の時点でXクライアントなのにXRender等拡張プロトコルで実装され、Xのコア
プロトコルはほとんど使っていない状態になっていたから、拡張プロトコルをベースに作り
直したグラフィックシステムがWayland

> もうxlibとかとの互換とか捨ててWinMac辺りのウィンドウシステムのAPIやハンドラへの仲介の機構とか見習うべき
Waylandのプロセス間通信はasynchronousだからWindows Vista以降と同じ
というかWaylandとWindowsのDWM(いわゆるAero)はほとんど同じ構造

まあWaylandはXWaylandでXクライアントも普通の性能で動作するが、DWMはGDIの実装が
いまいちなんだけどな

ttps://pc.watch.impress.co.jp/docs/2008/1126/hot582.htm
ttps://jehupc.exblog.jp/11464034/

NG便利

なら知ったかこいてねえで黙ってろ

今北産業

そういえばWindows 10では従来のデスクトップアプリとモダンアプリとでときどき違和感が
あるけど、gtk+アプリとQtアプリでこんな違い感じたことないぞ

https://wayland.freedesktop.org/docs/html/
waylandでのxlibに相当するものがこれだろ？
で、CSpinButtonCtrlの中のCEditに飛ぶメッセージを親が処理する、みたいな事が
Windowsで言うとこの非公開APIでできるとか言いたい訳か？
それはどのソースだ？

>> WaylandのAPIはWindows上だと非公開APIであるDWM.exeへのAPIに対応するもの
>> DWM.exeがwestonやmutter等のWayland Compositorに対応する

「waylandのAPI」と「waylandでのWindowsで言うとこの非公開API」はどれだ？

俺もそんなにきちんと勉強してるわけじゃないけど、あなたの言おうとしていることはわかるよ

だから関係ないものを出して何がいいたいの?

お前プログラミングしたことないだろ

いいってことよ
Debianがデフォルトにするだけあって、基本全然安定してるぜ

処理しないイベントだけ処理できたって意味ねえ
CSpinButtonCtrlから派生したクラスが文字列を全て選択できる様にした上で、
更に基本クラスがフォーカスされた時のイベントを処理、
CSpinButtonCtrlを使うアプリも更にOnSetFocusを処理できなきゃ
恥ずかしくってカスタムコントロールなんて言えないぞ

は出来る子

ここの板のスレに自治する人達（いわゆるスレチやめろと苦情を言う人達）がよく湧く理由がお分かり頂けただろうか。こうなるのです。
これを放っておくとこのスレだけでなく板全体が崩壊し人がまったく寄り付かなくなります。必要な情報を探す（共有する）のが非常に困難になるからです。

シェルスクリプトベースのinitでも近代化（並列起動とか）
できるんだけどね。割と簡単に

waylandに入れ替えてみた→わからない→xorgに戻る

これが正しい流れ
シツモニするな恥ずかしい

で、DebianのWaylandは使った上でどんな不満があるの？
内部のミクロな話じゃなくて

https://docs.microsoft.com/ja-jp/cpp/mfc/receiving-notification-from-common-controls?view=vs-2019
デタラメならMSはなんでこんな事してる？
CSpinButtonCtrlで話せばよかったのか？どっちも変わらんわ
こいつはコンテナみたいなコントロールにエディットコントロールとアップダウンコントロールを
名指しで生成してるから生成するエディットコントロールの挙動だけを変更する、みたいな事はできない
何故ならMFCで例えればCSpinButtonCtrlの元になってるコントロールがMFCで言うとこの
CEditを直接newしちまってる様なもんだからCEditの派生クラスをnewさせるなんて事は当然できない

ただしCSpinButtonCtrlの下のエディットコントロールのWndProc()を挿げ替える事はできるし
下に行くウィンドウメッセージをCSpinButtonCtrlが処理する事もできる

お詳しいんですね。
よかったらWaylandとX11の起動シーケンスについてご教授して頂けませんか？
WaylandはXサーバーを使わないのでstartxしても意味が無いから同じスクリプトじゃ動かない事くらいなら把握してるんですけど。

てかハンドラの追加はできても基本クラスのハンドラを呼ばない様にして全部自前で処理とかできねえよな

追い出し発言しか能のない自治厨はすっこんでろ

たしかに使ったことはないけれども gnome で選んだテーマ機構は
qt / kde アプリに自動的に適用されて同じ見た目と操作感で動くの？？

まじ？
じゃー入れ替えるしかないな
（謝罪なし）

それは誰にとって使いやすいLinuxであって欲しい？
PCマニア？Linuxマニア？素人を含めた一般人？

お堅いDebianの最新stableがデフォルトDEに採用したのがWaylandだろ？

DM→各DEごとの短い起動スクリプトを呼ぶ

この流れはどのディストリでも同じなので
どれが向いてるも無い
同じくスクリプト書いてXなりWaylandが起動するのは当たり前

今の時代Xプロトコルを透過にするより、
画像の差分を送ったほうがいいだろ？

Wayland
https://mevius.5ch.net/test/read.cgi/unix/1323873988/

Wayland の話題ならココ
DE の話を wayland のスレでやるなよ？

互換レイヤーで動くので俺環では実用上困った事は無い。
今のところwineとVNC以外は。

> GIMPのドロップダウンとか色選択のダイアログ（Winの場合は汎用ダイアログがあるんだが）の操作感は？
ダイアログもクロスプラットホームのツールキットは色々配慮するようになっているよ
自前のものが標準のはずでOSに合わせたテーマで動くようになっている

Windowsのgtk+だと知らないけどLinuxではgtk+がKDEのダイアログを使うようにもできる

ttps://wiki.archlinux.jp/index.php/Qt_%E3%81%A8_GTK_%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E5%A4%96%E8%A6%B3%E3%81%AE%E7%B5%B1%E5%90%88