Debian GNU/Linux スレッド Ver.93
extend:checked:vvvvv:1000:512
次スレを立てる方は↑を二行重ねて書いてください
公式
https://www.debian.org/index.ja.html
過去ログは各自検索して見つけること
大体参考にならないので過度な期待は禁物
前スレ
Debian GNU/Linux スレッド Ver.92
https://mao.2ch.sc/test/read.cgi/linux/1565609547/
ありがと
やってみる
…そういうプリミティブなの試すなら gentoo とか arch とかの方が向いてるかも知れんけど…
https://mao.2ch.sc/test/read.cgi/linux/1565609547/999n
もし俺がわかんない事があったら優しく教えてね。
では失礼
この流れはどのディストリでも同じなので
どれが向いてるも無い
同じくスクリプト書いてXなりWaylandが起動するのは当たり前
DMだった
キモイと云われてもしようが無いわ
6年もDebian入れっぱだと、全てを忘れるな
しかし6年前に入れたのに、最新だなんて最高だな！と誤魔化しておく（笑）
お詳しいんですね。
よかったらWaylandとX11の起動シーケンスについてご教授して頂けませんか？
WaylandはXサーバーを使わないのでstartxしても意味が無いから同じスクリプトじゃ動かない事くらいなら把握してるんですけど。
そいついつも後付けで威張るだけでろくな回答出さねえんだぜ
Waylandについてなんて絶対わかってねえよ
まだ少しはましになっただけだろ
Ubuntuでも使ってろ
なら知ったかこいてねえで黙ってろ
それは与えるものがある奴が言うことだ
お前がUbuntu使ってろやｗ
ローカルでのウィンドウシステムとしての動作でオーバーヘッドを減らしつつ
GUI部品に相当する部品の単位について単純にコールバックを提供できる様にした程度
もうxlibとかとの互換とか捨ててWinMac辺りのウィンドウシステムのAPIやハンドラへの仲介の機構とか見習うべき
これが正しい流れ
シツモニするな恥ずかしい
じゃー入れ替えるしかないな
（謝罪なし）
Debianがデフォルトにするだけあって、基本全然安定してるぜ
互換レイヤーで動くので俺環では実用上困った事は無い。
今のところwineとVNC以外は。
> まー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/
画像の差分を送ったほうがいいだろ？
windowsからリモートデスクトップするなら、waylandかXがどちらがいいですか？
>>24
> ちゃんと実装されていればローカルでもリモートでも動作するが、リモートだと動作が大幅に
> 遅くなるし、リモートだと動作しないXクライアントも多い
コレ読んで wayland でリモートデスクトップする気は起らんなあ、私なら
そういう機構じゃなくって、
ウィンドウシステム全体をカーネルのモジュールか何かにしてメッセージキューを提供するとか
GUI部品（コントロールの類）が受け取ったイベントをその持ち主のウィンドウに先にルーティングする仕組みとか
それらを組み合わせての言語を問わないGUI部品の抽象化と派生による再利用の促進とか標準化みたいな
内側の構造じゃなくって外側からのAPIの呼び出し方と
イベント時に処理を実行する機会の提供の仕方とかによるツールキット類の作り易さの向上、
強いてはツールキット類の仕様（開発時）や操作感（使用時）の統一、使いやすさの向上を促さないと
> 内側の構造じゃなくって外側からのAPIの呼び出し方
API共通なら何の問題もない
> イベント時に処理を実行する機会の提供の仕方とかによるツールキット類の作り易さの向上
これはツールキット類のコードを書く人の問題だけど
具体的にどういう悩みがあって「こんなクソコード書かせんな」と思ったのか分からん
> ツールキット類の仕様（開発時）や操作感（使用時）の統一、使いやすさの向上
これだけじゃ具体的にどういう問題点があるのか分からん上に wayland 全く関係ない
Debian GNU/Linux スレッド Ver.92
https://mao.2ch.sc/test/read.cgi/linux/1565609547/18
18 名前：login:Penguin[] 投稿日：2019/08/14(水) 18:42:01.79 ID:XlTWnfY2
netinst使えばいいのに
Debian -- 最小の CD を使って、ネットワークインストールする
https://www.debian.org/CD/netinst/
non-free firmware付きのはこちらで
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/10.0.0+nonfree/amd64/iso-cd/firmware-10.0.0-amd64-netinst.iso
Debian GNU/Linux スレッド Ver.92
https://mao.2ch.sc/test/read.cgi/linux/1565609547/502
502 名前：login:Penguin[sage] 投稿日：2019/09/24(火) 19:45:28.49 ID:t8p2w6v2
https://cdimage.debian.org/images/unofficial/non-free/cd-including-firmware/10.1.0+nonfree/amd64/iso-cd/
https://cdimage.debian.org/images/unofficial/non-free/cd-including-firmware/10.1.0+nonfree/i386/iso-cd/
リンク先が切れてたっぽい
今のXのAPI（システムが提供してる訳じゃないから別プロセスへのインターフェースだけど）の形式で
どうやってウィンドウが保持してるGUI部品へのイベントを先取りできると？
>> ツールキット類の仕様（開発時）や操作感（使用時）の統一、使いやすさの向上
> これだけじゃ具体的にどういう問題点があるのか分からん上に wayland 全く関係ない
たぶんは>>28は実際にGnomeやKDEを使ったことなくて想像で言っているだけだとおもうよ
実際に使えばテーマ機構によりgtk+アプリもQtアプリも全く同じ見た目と操作感で動くから
しらんけど
xlib ができないんだったら x では出来ないし
互換レイヤーを作ってあるだけなら x で出来ないことを実装する必要はない
xlib ができないんだったら x で出来るし
互換レイヤーを作るなら x で出来ることを実装する必要がある
たしかに使ったことはないけれども gnome で選んだテーマ機構は
qt / kde アプリに自動的に適用されて同じ見た目と操作感で動くの？？
操作感が統一されてないなんてGNOMEKDE両方試せばすぐ違和感に気付くだろ
開発時の話は今時のフレームワーク類だとハンドラをウィンドウのクラスに記述するって時点で、
既にWinMacの類だとシステムがウィンドウに対してイベントをルーティングしれる事から考えると
単純なコールバックしか提供しないwaylandですら遅れてると言わざるを得ない
例えばVLCとかPhotoshop ElementとかKindleとかWindowsで動かしてみて違和感感じた?
これらはQtを使っているんだけど、Qtのような現代のクロスプラットホームのツールキットは
ネイティブなWin32のツールキットを使わず自前で描画していて、Windows上では標準で
Win風テーマエンジンでWindowsそっくりのルックアンドフィールを実現している
Linuxではどのディストリも何もいじならなければ同じテーマエンジンを使うようになっている
からQtとgtk+で違和感を感じることはない
本当は使ったことないでしょ?
それと
> 既にWinMacの類だとシステムがウィンドウに対してイベントをルーティングしれる事から考えると
> 単純なコールバックしか提供しないwaylandですら遅れてると言わざるを得ない
そんな仕組みになっていない
どっからそんなおかしな発想が出てくるの?
あるけど、gtk+アプリとQtアプリでこんな違い感じたことないぞ
それQt限定だし、同じプラットホームでもQtとQtでしか比較しないつもりか？
GIMPのドロップダウンとか色選択のダイアログ（Winの場合は汎用ダイアログがあるんだが）の操作感は？
waylandのコールバックルーチンの設定のAPI見てこい
ウィンドウじゃなくってコントロールにはハンドラは設定できるが、
Winで例えればWM_NOTIFY〜の類はない、ウィンドウが子のコントロールのイベントを処理するっつー話だぞ？
コントロールに設定されたコールバックルーチンをコントロール（一種のウィンドウ）が処理するっつー話じゃないぞ？
> waylandのコールバックルーチンの設定のAPI見てこい
見ましたが
> ウィンドウじゃなくってコントロールにはハンドラは設定できるが、
> Winで例えればWM_NOTIFY〜の類はない、ウィンドウが子のコントロールのイベントを処理するっつー話だぞ？
> コントロールに設定されたコールバックルーチンをコントロール（一種のウィンドウ）が処理するっつー話じゃないぞ？
言っていることが現実の設計や実装と一致しません
君の妄想の世界では意味のあることを話していることになっているつもりなのかもしれないけど、
現実は全くそうなっていません
.NETのイベントハンドラの代入とかだけ見てるんだったら（ｒｙ
> 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
魔女狩りでもなんでもないから証明は簡単だろ？
くどい様だけどコントロールのハンドラで親ウィンドウを識別して特定の親ウィンドウに対して
更にコールバック（ただの関数呼び出し）を起こすとかじゃくって、親ウィンドウが一括して処理って話だからな？
それがどうかしたの?
全く関係ない話のようだけど
「使う様にできる上にそうなってる」のと「使う様にできるけどそうなってない」のは全然違うぞ
まず君が何をやりたいのかコードを示して
意味のあることをやろうとしているように思えない
そうなっているから
waylandでそんな事できないんだから魔女狩りさせんな
それファイルダイアログみたいな原始的な奴だけだろ
つまりコードを示せないんですね
全部妄想や捏造だと認めると
>>49
いいえ
https://docs.microsoft.com/ja-jp/cpp/mfc/receiving-notification-from-common-controls?view=vs-2019
なんでWindowsがWM_NOTIFYでやりとりしてると思ってる？
なんでWindowsのコモンコントロール（DLL）から更に派生したカスタムコントロールをDLLにして
言語を問わずに再利用できると思ってる？
関数決め打ちのコールバックに頼ってないからだよ
だから関係ないものを出して何がいいたいの?
お前プログラミングしたことないだろ
https://mevius.2ch.sc/test/read.cgi/unix/1323873988/
Wayland の話題ならココ
DE の話を wayland のスレでやるなよ？
waylandの機構じゃコントロールの機能をsoに過不足なく詰め込んでコモンコントロールにして、
更にそのsoの”ソースも抜きに”機能を派生させたsoを作って、
その派生させたsoを言語問わずに再利用とかできないか、できるにしてもWindowsみたいな
メッセージキューみたいなのをウィンドウシステムとツールキットの間に挟まなきゃなんないだろ
ソースがありゃいじり放題だけど、多分世の多くのコーダーはそんな事は求めてない
機能が分離されてて親ウィンドウのクラスのソースにあっさりハンドラを記述したり
カスタムコントロールにするまでもないようなのはウィンドウのWndProc()で
WM_NOTIFYの時にイベントを横取りして工数を削減したいだろう
もう一度言うよ
お前プログラミングしたことないだろ
デタラメ書くのやめて
https://docs.microsoft.com/ja-jp/cpp/mfc/receiving-notification-from-common-controls?view=vs-2019
おまえ、なんでMSがこんな事してるか未だに理解してないんだろ？
みたいなありふれた実装でもお世話になる筈なんだがな・・・
あれ、内部だとコントロール本体は殆ど空のウィンドウ（コントロール）だから、
コントロール自体はエディットコントロールでもアップダウンコントロールでもないから
そのつもりでコントロールを派生して云々しようとしても上手くいかない
上下ボタン付きのコントロールが保持してる子コントロールのウィンドウクラスを識別した上で
その子コントロールに対して直接干渉しないと思った通りの動作はさせられない
その子コントロール（しかもDLLでしかないただのコモンコントロール）を２つ積んだコントロールの機能を
たった１つのDLLに詰め込んで、派生してる訳でもないのに更に言語を問わず再利用できるってのも
Windowsの強みの１つだろ
内部のミクロな話じゃなくて
> たった１つのDLLに詰め込んで、派生してる訳でもないのに更に言語を問わず再利用できるってのも
> Windowsの強みの１つだろ
XやWayland上のQtやgtk+でコントロールの制御ができないわけないだろう
プログラミングしたことない人間が想像でデタラメ書くのやめて
>>58
KDEに関して完全にWaylandにできるのはDebianに限らずもう少しかかる
ttps://community.kde.org/Plasma/Wayland_Showstoppers
相手してくれてありがとう
KDE好きだけど、しばらくGNOME on Waylandで過ごすわ
ただの制御の話なんてしてない
例えば上下ボタン付きエディットコントロールで例えれば、コントロールがフォーカスを受け取った時に
全選択するハンドラをコンストラクタで設定してやれば目的は達成できる
ただしそのクラスを再利用する側はフォーカスを受け取った時のハンドラを設定してはならない、
若しくはsoの類にひとまとめにするとすれば、ハンドラを設定したらsoでexportされてるそのハンドラの関数を
名指しで呼び出さなければならない
んな事意識しなきゃ再利用できないとか時代遅れと言わざるを得ない
補足
技術的に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
技術的にデタラメな話をするのやめて
デマが広まると迷惑なの
何がデタラメ？
waylandなら後からハンドラを上書きされても元のハンドラを自動的に呼び出してもらえたりすんのか？
しかも.NETでいうとこのNumericUpDownコントロールみたいに、DLLの中でウィンドウクラス決め打ちで
newされた様なエディットコントロールでも、waylandならインスタンスの元になったクラスの動作そのものを
改変できたりするのか？
何度も書くけどお前プログラミングしたことないだろ
プログラム関係の技術用語それっぽく並べても現実と対応しないから全く意味不明なの
何がデタラメなのか欠片も言わねえのな
numericupdown フォーカス 選択 とかでｇｇると、構造を理解してない人の
「フォーカスを受け取った時に〜どうすればいいですか？」みたいな質問がいっぱい引っ掛かる
じゃあタブキーでのフォーカス移動で自動的に全選択してくれる様な、世のアプリは一つ一つに
ハンドラ設定して全選択してるか、カスタムコントロールがフォーカス移動のハンドラを隠蔽してるのか？
んなわきゃねえ
Windowsなら２つの子コントロールを保持してるクラスでWM_NOTIFYを処理すればトリッキーな事をせずに済むし、
それに頼らなくてもサブクラス化みたいな手法もあるし、WndProc()のオーバーライドって手もある
（.NETの類でWndProc()貪るのもどうかと思うが）
これを放っておくとこのスレだけでなく板全体が崩壊し人がまったく寄り付かなくなります。必要な情報を探す（共有する）のが非常に困難になるからです。
バトルしながら貴重な情報も提供してくれてありがとう。
晩メシ食ってたんだけど気になって気になってｗ
今日は書いてくれた情報と貼ってくれたURLを読みながら過ごし、明日KDE環境を作って検証してみるよ。
片方は脱線しつつも有り難い最前線のDebian情報提供してくれたけど、もう片方はもう全然このスレに関係ないよね
せめてWindowsでは○○が出来るけどDebianでは●●が出来ないから▲▲すればどうだと言う書き方にすればいいのに
その要因がコモンコントロールとソースの無いコントロール（DLL）からの更に派生したコントロールの再利用みたいな
仕組みの提供が無い事じゃないかって言ってる
俺は現場のSEじゃないから野蛮で低レベルな切り口でしか話が出来ないけど、Xはまだまだ使われるもののもう過去の遺産の為の維持営業になって、余計な拡張を削ぎ落としたWaylandにリソースが注がれる世の流れなんじゃないの？
で、貴方の言いたい事は俺みたいなシロートでも分かるように言い換えるならば、「ライブラリの類がLinuxはWindowsに比べて汎用的な実装が遅れてるから良いところは取り入れた方がいい」と言う意味で解釈した。
現場の人間ならではの熱い議論と提案、実は興味深かった。今日の激論、掘り下げるとすごい勉強になりそう。
ありがとう。激論は自治警察に睨まれない程度にね。
悪いけど何の役にも立たない
>>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を比較されても
全くとんちんかんなのよ
お前、Windowsでの.Netの話しかしてないじゃん
Windowsのウィンドウシステムやイベントハンドラの話してないだろ
それがデタラメなんじゃねーの？
お前、.NETでVBあたりでポトベタしてるだけで、OSの内部構造とかきちんと把握してないんじゃねいのか？
俺もそんなにきちんと勉強してるわけじゃないけど、あなたの言おうとしていることはわかるよ
> WaylandのAPIはWindows上だと非公開APIであるDWM.exeへのAPIに対応するもの
> DWM.exeがwestonやmutter等のWayland Compositorに対応する
ツールキット類を実装する人はそれを直接叩けって？
んなわきゃねえ
更に付け加えると事実上xlibがuser32.dllみたいなもんだろ
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の場合は必ず２つ以上の子ウィンドウが列挙される
コントロールが必ず１個のウィンドウだけでできてると思うなよ？
nvidiaがガン無視してる内はWaylandとかどうでもいい
涙拭けよ知ったか野郎
dselect でパッケージ入れようとしたら、同時に沢山インストールしようとするので、apt で入れたいものだけインストールしたけど、それが原因か。
さすがにそれはオーバーキルだし、そもそもOSやカーネルが違うシステムでの互換性を保証出来なくなるからやるべきではないと思うよ(´･ω･`)
>>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と関係ないこと書いているの?
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と同じことができるって言いたかったのか？
それを使ってるツールキット類があるんならリポジトリ名書いてみ
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が全然違う次元の存在なのわかった?
>>83じゃなくて>>88へね
>>88
> それを使ってるツールキット類があるんならリポジトリ名書いてみ
DWM.exeへのAPIを使っているのはWPFとかDirect2DとかWindowの現行の
システムそのものだよ
どういう仕組みでWindows Vista以降のグラフィックシステムが動いていると
思っているの?
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」はどれだ？
こういう奴がバグの数を増やすんだ
外から内側のコントロールの動作に介入できる機構かどうかと
作り手がバグを作り込むかどうかは別問題
すまん
的外れなことを言ってるバカが、実際にはVBか何かのポトペタコピペしかできない無能なんだろうなあと
Xlib で書けるだけでもエライこっちゃ。。。
Windowsアプリはwineで大体動くし
プリンタドライバがショボくてふち無し印刷が出来ないくらいしか思いつかん
‥それもGUIとは関係ないかｗ
WindowsUpdate
レベルが低くて失笑ものなのは承知での質問何だけど、それが出来ると何か便利になるの？
実用的な例を上げてくれるととても嬉しい
(お陰でWindowsの○○では●●と言う操作が出来て大変有用だが、
Linuxの同類アプリ■■では残念ながらそれが出来なくて非常に不便だ。
みたいなかみ砕いた話もしてくれると実に面白いと思う)
100〜のスレッドの続きを読む
