Debian GNU/Linux スレッド Ver.93

extend:checked:vvvvv:1000:512
extend:checked:vvvvv:1000:512
次スレを立てる方は↑を二行重ねて書いてください

公式
https://www.debian.org/index.ja.html

過去ログは各自検索して見つけること
大体参考にならないので過度な期待は禁物

前スレ
Debian GNU/Linux スレッド Ver.92
https://mao.5ch.net/test/read.cgi/linux/1565609547/

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

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

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

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

>>52
waylandの機構じゃコントロールの機能をsoに過不足なく詰め込んでコモンコントロールにして、
更にそのsoの”ソースも抜きに”機能を派生させたsoを作って、
その派生させたsoを言語問わずに再利用とかできないか、できるにしてもWindowsみたいな
メッセージキューみたいなのをウィンドウシステムとツールキットの間に挟まなきゃなんないだろ

ソースがありゃいじり放題だけど、多分世の多くのコーダーはそんな事は求めてない
機能が分離されてて親ウィンドウのクラスのソースにあっさりハンドラを記述したり
カスタムコントロールにするまでもないようなのはウィンドウのWndProc()で
WM_NOTIFYの時にイベントを横取りして工数を削減したいだろう

>>54
もう一度言うよ

お前プログラミングしたことないだろ
デタラメ書くのやめて

>>55
https://docs.microsoft.com/ja-jp/cpp/mfc/receiving-notification-from-common-controls?view=vs-2019

おまえ、なんでMSがこんな事してるか未だに理解してないんだろ？

上下ボタン付きの数値限定のエディットコントロールでタブが移った時に全選択させる、
みたいなありふれた実装でもお世話になる筈なんだがな・・・

あれ、内部だとコントロール本体は殆ど空のウィンドウ（コントロール）だから、
コントロール自体はエディットコントロールでもアップダウンコントロールでもないから
そのつもりでコントロールを派生して云々しようとしても上手くいかない
上下ボタン付きのコントロールが保持してる子コントロールのウィンドウクラスを識別した上で
その子コントロールに対して直接干渉しないと思った通りの動作はさせられない

その子コントロール（しかもDLLでしかないただのコモンコントロール）を２つ積んだコントロールの機能を
たった１つのDLLに詰め込んで、派生してる訳でもないのに更に言語を問わず再利用できるってのも
Windowsの強みの１つだろ

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

>>56-57
> たった１つのDLLに詰め込んで、派生してる訳でもないのに更に言語を問わず再利用できるってのも
> Windowsの強みの１つだろ
XやWayland上のQtやgtk+でコントロールの制御ができないわけないだろう

プログラミングしたことない人間が想像でデタラメ書くのやめて

>>58
KDEに関して完全にWaylandにできるのはDebianに限らずもう少しかかる

ttps://community.kde.org/Plasma/Wayland_Showstoppers

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

>>59
ただの制御の話なんてしてない

例えば上下ボタン付きエディットコントロールで例えれば、コントロールがフォーカスを受け取った時に
全選択するハンドラをコンストラクタで設定してやれば目的は達成できる
ただしそのクラスを再利用する側はフォーカスを受け取った時のハンドラを設定してはならない、
若しくはsoの類にひとまとめにするとすれば、ハンドラを設定したらsoでexportされてるそのハンドラの関数を
名指しで呼び出さなければならない

んな事意識しなきゃ再利用できないとか時代遅れと言わざるを得ない

>>59
補足

技術的にKDEというかWayland全体で時間がかかりそうなのは
> Plasma Native Wayland windows are not restored
>
> Session restoring does not include Wayland native windows.

Debian busterで確認済みだから実際にKDEで試してもらえばわかるけど、例えば
Konsoleとか電卓とか適当なページを開いたFirefoxとかを起動したままログアウトして、
もう一度ログインするとウィンドウの場所や開いているページやタブ等を含めて復元される

20年以上前からデスクトップセッション管理機能としてX Window Systemにこういう機能が
存在しているんだけど、おそらくWaylandを設計した段階で見落とされたらしい

DBusベースでなんとかしようみたいなリンクが貼ってあるけど
ttps://wiki.gnome.org/Projects/SessionManagement/GnomeSession
Wayland下で使えるようになるまでしばらく時間がかかるんじゃないかな

>>53
スレちがいになっているのはわかるんだけど

>>61
技術的にデタラメな話をするのやめて
デマが広まると迷惑なの

>>62
何がデタラメ？
waylandなら後からハンドラを上書きされても元のハンドラを自動的に呼び出してもらえたりすんのか？
しかも.NETでいうとこのNumericUpDownコントロールみたいに、DLLの中でウィンドウクラス決め打ちで
newされた様なエディットコントロールでも、waylandならインスタンスの元になったクラスの動作そのものを
改変できたりするのか？

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

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

>>64
何がデタラメなのか欠片も言わねえのな

numericupdown フォーカス 選択 とかでｇｇると、構造を理解してない人の
「フォーカスを受け取った時に〜どうすればいいですか？」みたいな質問がいっぱい引っ掛かる
じゃあタブキーでのフォーカス移動で自動的に全選択してくれる様な、世のアプリは一つ一つに
ハンドラ設定して全選択してるか、カスタムコントロールがフォーカス移動のハンドラを隠蔽してるのか？
んなわきゃねえ

Windowsなら２つの子コントロールを保持してるクラスでWM_NOTIFYを処理すればトリッキーな事をせずに済むし、
それに頼らなくてもサブクラス化みたいな手法もあるし、WndProc()のオーバーライドって手もある
（.NETの類でWndProc()貪るのもどうかと思うが）

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

>>62
バトルしながら貴重な情報も提供してくれてありがとう。
晩メシ食ってたんだけど気になって気になってｗ
今日は書いてくれた情報と貼ってくれたURLを読みながら過ごし、明日KDE環境を作って検証してみるよ。

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

Linuxってより現状のXだと操作感がWinMacAndroid程統一されてない
その要因がコモンコントロールとソースの無いコントロール（DLL）からの更に派生したコントロールの再利用みたいな
仕組みの提供が無い事じゃないかって言ってる

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

>>70
悪いけど何の役にも立たない

>>65
> 何がデタラメなのか欠片も言わねえのな
>>63
> waylandならインスタンスの元になったクラスの動作そのものを
WaylandはCのライブラリでC++ではないんだけどインスタンスとかクラスって何?

そもそもレイヤーが全然違うものを比べているのよ

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

WindowsではDWM.exeのAPIとDirectXやGDIのAPI等を組み合わせてWinFXやMFCの
ようなライブラリが作られている

Linuxも同様にXlibやWayland、OpenGL等のAPIを使ってQtやgtk+が作られている

だからMFCとQtやgtk+を比較するならわかるけどMFCとWaylandを比較されても
全くとんちんかんなのよ

>>65
お前、Windowsでの.Netの話しかしてないじゃん
Windowsのウィンドウシステムやイベントハンドラの話してないだろ

それがデタラメなんじゃねーの？
お前、.NETでVBあたりでポトベタしてるだけで、OSの内部構造とかきちんと把握してないんじゃねいのか？

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

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

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

>>72
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が処理する事もできる

寝る前に証明の方法書いとく
CEditとCSpinButtonCtrlにEnumChildProc()掛けてみろ
CEditは自身のコントロール（ウィンドウ）で全ての機能を実現してるから子ウィンドウは原則出現する事はない
（そのコントロールから何かポップアップする様な実装をしてCEditのインスタンスが子ウィンドウを作ったりしたら話は別だが）
CSpinButtonCtrlの場合は必ず２つ以上の子ウィンドウが列挙される
コントロールが必ず１個のウィンドウだけでできてると思うなよ？

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

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

>>77
涙拭けよ知ったか野郎

>>78
dselect でパッケージ入れようとしたら、同時に沢山インストールしようとするので、apt で入れたいものだけインストールしたけど、それが原因か。

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

>>28
さすがにそれはオーバーキルだし、そもそもOSやカーネルが違うシステムでの互換性を保証出来なくなるからやるべきではないと思うよ(´･ω･`)

(=ﾟωﾟ)ﾉ おはよー (なんとなくなつかしいAAをつかってみたり)

>>74
>> WaylandのAPIはWindows上だと非公開APIであるDWM.exeへのAPIに対応するもの
>> DWM.exeがwestonやmutter等のWayland Compositorに対応する
> ツールキット類を実装する人はそれを直接叩けって？
> んなわきゃねえ
いいえ

例えば、VulkanとかDirectX12等の最新の薄いプリミティブな最小限な層になっていて、
上位のUnityやUnreal Engineの方で通常使う機能を実装している
直接一般のプログラマがVulkan等を使うようには設計されていない(別に使っても
いいけど大変なだけで意味がない)

Waylandも同じ発想で一般のプログラマが直接WaylandのAPIを使うんじゃなくて、Qtや
gtk+等の上位のライブラリを一般のプログラマが使う形式

UnityやQt等ツールキットやフレームワークの開発者だけが頑張ればいいようにしている
からプリミティブな機能しかVulkanやWaylandは実装していない

プログラミングしたことあるならどのAPIがどういう目的で誰を対象としているかわかるはず
なんだけど

> 更に付け加えると事実上xlibがuser32.dllみたいなもんだろ
いいえ、xlibはuser32.dllとgdi32.dllの両方

やっぱりWindowsのことすら全くわかっていないのね

>>75-76
何度も言うけど何でWaylandと関係ないこと書いているの?

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

83さんは一見ものすごいスレチの様に見えますが、今後のDebianのデフォルトDEに関するとても有用な情報を提供して下さってます

でももう腹いっぱい　そろそろ止めようね

Debian10 で Gnome もしくは KDE 使う時に、日本語かな漢字変換(Mozc or Anthy) のサジェストを止めたいのですが、設定はどこにあるのでしょうか？

>>83
https://wayland.freedesktop.org/docs/html/
つまりこれがuser32.dllとgdi32.dllの両方って事か？
これでCSpinButtonCtrlに貼り付けられた上に外に出てこないCEditの動作をどうやって変えられる？
世の上下ボタン付きエディットコントロールがフォーカスを受け取った時に〜できません〜なんてのは
CSpinButtonCtrlをエディットコントロールから派生したクラスだと思って、上っ面のコントロールの
イベントに処理を書いたり、ただの上っ面にCEditの操作をしにいくから上手くいかねえんだよ
それでもやってる奴がいるのはWM_SETFOCUSじゃなくってWM_NOTIFYで処理してっからだ

> WaylandのAPIはWindows上だと非公開APIであるDWM.exeへのAPIに対応するもの
その非公開API使えばWindowsと同じことができるって言いたかったのか？
それを使ってるツールキット類があるんならリポジトリ名書いてみ

>>83
Xlibがuser32.dllとgdi32.dll相当であってWaylandではないぞ

Waylandが何なのか全然わかってないようなので、ツールキットやWin32、Xlibでの
簡単なプログラムとWaylandの簡単なプログラムへのリンクを張るよ

gtk+
ttp://lmj.nagaokaut.ac.jp/~lu/programming/gtk_tut_ja/gtk_tut_ja-2.html
十数行

Qt
ttps://wiki.qt.io/Qt_for_Beginners#Our_first_window
の下の方のPushbuttonの十数行

Win32API
ttp://www.kumei.ne.jp/c_lang/sdk/sdk_00.htm
50〜60行ぐらい

Xlib
ttps://ja.wikipedia.org/wiki/Xlib
50行

Wayland
ttps://jan.newmarch.name/Wayland/WhenCanIDraw/
ttps://jan.newmarch.name/Wayland/EGL/
300行越え
ttps://devm33.hatenadiary.org/entry/20140422/1398182440
だいぶ頑張っている人のコードで130行
ttps://eng-info-office.com/ww-simpleegl/
一番シンプルかつ基本的な構成とか呼ばれているものが800行越え

Waylandが全然違う次元の存在なのわかった?

>>89
>>83じゃなくて>>88へね

>>88
> それを使ってるツールキット類があるんならリポジトリ名書いてみ
DWM.exeへのAPIを使っているのはWPFとかDirect2DとかWindowの現行の
システムそのものだよ

どういう仕組みでWindows Vista以降のグラフィックシステムが動いていると
思っているの?

>>89
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」はどれだ？

実際にやってんのはガチのポトペタとコピペだけだったりしてな
こういう奴がバグの数を増やすんだ

複数のコントロールをウィンドウに貼り付けたコントロールを再利用する側が
外から内側のコントロールの動作に介入できる機構かどうかと
作り手がバグを作り込むかどうかは別問題

NG便利

あ
すまん

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

いくら人格攻撃をしたとこでXやwaylandの機能は増えない

Windowsに出来てLinuxに出来ないGUIの機能って何なんだろう
Windowsアプリはwineで大体動くし
プリンタドライバがショボくてふち無し印刷が出来ないくらいしか思いつかん
‥それもGUIとは関係ないかｗ

親ウィンドウによる子コントロールのイベントの先取りとか

>>97
WindowsUpdate

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

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

CSpinButtonCtrlだけじゃなくってカレンダーコントロールみたいなのもそうだろ
あれはウィンドウ１つでできてるコントロールじゃない

>>101
ほほぉ
で、それが可能になる事により、プログラミング？何それ美味しいの？みたいな大多数のWindowsユーザーはどんな恩恵を受けてるの？

>>102
カレンダーね
Windowsのカレンダーに出来てLinuxのカレンダーに出来ない事って？

再利用の話をしていたのであって作り手が好き好きにブランチして
”全く別のコントロールのクラスにすれば”LinuxでもWindowsに似せた事はできるだろう
ただしそれらの使い勝手はてんでバラバラだろうけどな

なるほど
素人ながらに効率やら統一性の話をしてた事は語彙的には伝わってた
では貴方の言う使い勝手の統一性の無さが引き起こす問題とは具体的にはどういう事だろうか
とても興味があるので是非聞きたい
Debianは使いやすいLinuxであって欲しいので

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

>>107
もちろんまずは自分自身。でなければここに来ることは無い。

Linuxマニアのカテゴリになると多種多様過ぎてとても俺のような小物に偉そうに語れるものではない事くらいは認識してるつもり。

一般のLinuxを触った事も無いような人はにとっては使いやすいかどうか以前の話になってしまうのではないだろうか。PCのデスクトップ用途と言う意味では。
無論理解してくれる方が増えれば自分としても嬉しいけど、どんなに開発側の方々が頑張って素晴らしい実装をしてくれたって、世の流れや評価がWindowsやMacOSからLinuxにならない限りは残念な単語しか浮かんでこない。
「Windowsと違うから使いづらい」「Macみたいにお洒落じゃない」「何それ知らない」みたいな感想が多数派でしょう。

個人の主観などとても無力。でも俺は不便を感じないし使い道に合ってるから使う。
眠くなってきたのもあって俺に書ける事はこの程度の事ですな

素直に動いてくれればなんでもいいです

https://www.debian.org/vote/2019/vote_002

> General Resolution: Init Systems and systemd

そろそろsystemd以外のinit入れるかどうかのGeneral Resolution始まりそう
もうChoice 3でええやん……

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

というか既にsysvinitも並列化されてるでしょ
それよりsystemdがLinux以外に対応してないのが問題
kFreeBSD向けのpatchを送ったら「そんなtoy OSはしらん」とrejectされたらしいし

>>98
> 親ウィンドウによる子コントロールのイベントの先取りとか
X Window Systemでもできるよ

根本的な部分から説明するね

Windowsはローカルで動かすためのウィンドウシステムとして作られたので、マウスを動かしたりクリック
したりすると対応するメッセージが対応するウィンドウに常に送られる

だから子ウィンドウに対するメッセージを親ウィンドウで処理したい場合は子ウィンドウがメッセージを
一旦受け取った上で親ウィンドウにさらにSendMesseageで送らなくてはいけない

これに対してX Window Systemはネットワーク上で動かすことを前提にしているため、例えばボタン
ウィジット(ウィンドウ)ならマウスの移動を扱うとその分余計なリソースが消費されてしまうから、
マウスの移動は無視してマウスクリックとリリースに対応するイベントのみ受けとりたいので、
受け付けるイベントと最初から処理しないイベントを設定できるEventMaskというのがあり
処理しないイベントは親ウィンドウやその上位へ自動的に送られる仕組みになっている

ttp://csweb.cs.wfu.edu/~torgerse/Kokua/Irix_6.5.21_doc_cd/usr/share/Insight/library/SGI_bookshelves/SGI_Developer/books/XLib_PG/sgi_html/ch08.html
ttp://csweb.cs.wfu.edu/~torgerse/Kokua/Irix_6.5.21_doc_cd/usr/share/Insight/library/SGI_bookshelves/SGI_Developer/books/XLib_PG/sgi_html/figures/fig.8.02a.gif

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

>>113
つづき

当然子ウィンドウが受け取った上で親ウィンドウにXSentEvent等で送ることもできる
ttps://xjman.dsl.gr.jp/X11R6/X11/CH11.html

基本的に設計当時のPCとUnixワークステーションの性能に大きな差があった関係で、
WindowsよりX Window Systemの方が柔軟な設計になっているから、Windowsでできて
X Window Systemでできないことはないよ

ちなみにWaylandはマウスとキーボード3セットで3人同時に動かすmultiseat機能等
もっと複雑なことができる

>>115
具体的なページを貼りたいのにNGワードに引っかかる

例えば
emboss.ブログ28.エフシー２.コム/ブログ-エントリ-115.html
にあるような処理はWindowsだと子ウィンドウでのメッセージ処理コードが必要だけど
X Window Systemでは、同様に処理してもいいが、子ウィンドウがマウスクリック
イベントを受け取らないようにするだけで実装できるなど

ちなみに実際にXlibで相互にイベントをやり取りする場合はXSentEventより
XTEST ExtensionIの方がもっと柔軟なやりとりができるようになっている
ttps://www.x.org/releases/X11R7.7/doc/xextproto/xtest.html

>>115
その処理順序は？

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

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

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

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


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

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

>>121
> 全部Cでやるってんなら「基本クラス」を「機能の派生元のコントロール」に置き換えろ
そもそも対応するものではありません

それと
> 先ずは機能の派生元のコントロールが保持している子コントロールのハンドラと、
そもそもハンドラとは?

ウィンドウハンドラというものはあるが、Win32のメッセージループもXlibのイベントループも
caseで場合分けとして実装するものであって、それをクラスライブラリで抽象化したものが
イベントハンドラだから、Win32 APIやXlibレベルではコントロールが保持するハンドラなんて
存在しないのだが

> てかなんでX（Wayland）の上にコモンコントロールの類が無くて
> ツールキットの類がそれぞれ自前で実装してるかってったら
> WindowsやMacみたいなメッセージキューの類がないからコンポーネント化しづらくって
いいえ

歴史的な経緯でX Toolkit Intrinsicsというツールキットの基盤となるものがあってXawや
Motifなどで使われていたんだけど、gtk+やQtが使っていないだけ

>>122
揚げ足取りより先に機能を派生する側が後から追加したハンドラが必ず真っ先に呼び出してもらえるのかどうか
それをはっきりさせようぜ

じゃなきゃイベントの先取りも何もあったもんじゃない

>>123
揚げ足取り以前に根本的に用語が正しくないの
何度も言うけどプログラミングしたことあるの?

例えばWin32のメッセージループの最小限のコードの例として
（またうまく貼れない)
ttp://wisdom.サクラ.えぬいー.じぇいぴー
/system/winapi/win32/win9.html
だと
ボタンが押された処理はメッセージループの本体の
if (msg.message == WM_LBUTTONUP) break;
であってボタンハンドラなんて存在しないから

>>124
根本のWndProc()がそうなってるだけでMFCもVCLも.NETも実際にはメッセージ毎に分離してんだろ

それより先に機能を派生する側が後から追加したハンドラが必ず真っ先に呼び出してもらえるのかどうか
それをはっきりさせようぜ

>>125
だからメッセージやイベント構造が同等かLinuxの方が上なら
WindowsでできることはLinuxでもできるでしょ

上位のMFCやQtでどう扱えるかはそれぞれのツールキットの実装の
違いであって、WindowsとX Window Systemの違いではない

お前が最初に話したのはWindowsのメッセージの仕組みがLinuxの
方にないということだったのに何でメッセージやイベント処理の根本的な
部分の話をごまかそうとするんだよ

ハンドラとかslotとか呼び方違うけど順番なんてツールキットの実装次第

>>126
それは単独のウィンドウでできたコントロールでしか通用しない話
コントロールが更に子コントロールを作ってる様な高機能なコントロールの話をしてる

先に機能を派生する側が後から追加したハンドラが必ず真っ先に呼び出してもらえるのかどうか
それをはっきりさせようぜ

>>127
要するにWindowsやLinuxのウィンドウシステムの基礎であるWin32のメッセージ
ループもX Window Systemのイベントループも何も知らないのね

何にも知らないのにLinuxにいちゃもんつけただけ

やっぱり>>71で言ったように何も役立たない会話でした

親ウィンドウによるイベントの先取りの話に対して
> 当然子ウィンドウが受け取った上で親ウィンドウにXSentEvent等で送ることもできる
（先取りとは言っていない）

これを必死に流そうとしてるだけだろ

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

面白いからもっとやってくれ

片方がWindowsのMS謹製ツールしか知らないのは良くわかるぞ

読みたくない人は専ブラの機能でミュート出来るしね
俺はめっちゃ読みたい

この話がわかる用の知識が付く本を教えてくらはい。
Linux 用が無ければ Windows 用でもいいです。
（てか、本って一時期より少なくなったね）

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

今北産業

お互いが相手がどの部分を勘違いしてるのか分かってなくて、
永遠に交わることないパターンでしょ。

web系プログラマの俺も来ましたよ

組み込みの私もやってきましたよっと…

>>110
選択肢のどれがなんだって？
initはよう

あの人やっぱり賢いな
プログラミングとは別の意味でも

2人揃って必死にググってると思うとほんわかするわ

なんて微笑ましい光景

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

180個もうｐグレードがキタから何かと思えば
バージョンが10.1→10.2になるんだって

https://www.debian.org/News/2019/20191116
結構security fixがある

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

「自分で入れたら」とは？

apt コマンドを使わないで野良ビルドとか /usr/local とか？？

dpkg -i *.debしたやつでそ

単にDebianどころかLinuxディストリもよく知らない人では

知らずに二回インストしたら「手動でインストされたことにします」と
メッセージ出るけどなんか意味あんの?