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/

>>1乙ぱい

999login:Penguin2019/11/15(金) 13:10:59.75ID:7JCCAJD6
ありがと
やってみる

…そういうプリミティブなの試すなら gentoo とか arch とかの方が向いてるかも知れんけど…
https://mao.5ch.net/test/read.cgi/linux/1565609547/999n

もし俺がわかんない事があったら優しく教えてね。
では失礼

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

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

>>1は出来る子

>>1は勝手にワッチョイつけようとした駄目な子

ログインマネージャーじゃなかったな
DMだった
キモイと云われてもしようが無いわ
6年もDebian入れっぱだと、全てを忘れるな
しかし6年前に入れたのに、最新だなんて最高だな！と誤魔化しておく（笑）

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

そろそろ日記スレ行ってくれまいか？

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

何度か purge と install とログアウト繰り返したら日本語使えるようになったけどなんでか全く分からんわ

>>10
そいついつも後付けで威張るだけでろくな回答出さねえんだぜ
Waylandについてなんて絶対わかってねえよ

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

くれくれ乞食がうるさいぞ
Ubuntuでも使ってろ

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

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

まーwaylandはまだあちこち問題があるみたいだし、何よりネットワーク透過の為の部分を削って
ローカルでのウィンドウシステムとしての動作でオーバーヘッドを減らしつつ
GUI部品に相当する部品の単位について単純にコールバックを提供できる様にした程度

もうxlibとかとの互換とか捨ててWinMac辺りのウィンドウシステムのAPIやハンドラへの仲介の機構とか見習うべき

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

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

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

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

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

wayland + gnome のとき、libx11 に依存するアプリってどうなるの？

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

>>17
> まー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/

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

横からすみません、お詳しいようなので。
windowsからリモートデスクトップするなら、waylandかXがどちらがいいですか？

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

コレ読んで wayland でリモートデスクトップする気は起らんなあ、私なら

>>24
そういう機構じゃなくって、
ウィンドウシステム全体をカーネルのモジュールか何かにしてメッセージキューを提供するとか
GUI部品（コントロールの類）が受け取ったイベントをその持ち主のウィンドウに先にルーティングする仕組みとか
それらを組み合わせての言語を問わないGUI部品の抽象化と派生による再利用の促進とか標準化みたいな

内側の構造じゃなくって外側からのAPIの呼び出し方と
イベント時に処理を実行する機会の提供の仕方とかによるツールキット類の作り易さの向上、
強いてはツールキット類の仕様（開発時）や操作感（使用時）の統一、使いやすさの向上を促さないと

>>28
> 内側の構造じゃなくって外側からのAPIの呼び出し方

API共通なら何の問題もない

> イベント時に処理を実行する機会の提供の仕方とかによるツールキット類の作り易さの向上

これはツールキット類のコードを書く人の問題だけど
具体的にどういう悩みがあって「こんなクソコード書かせんな」と思ったのか分からん

> ツールキット類の仕様（開発時）や操作感（使用時）の統一、使いやすさの向上

これだけじゃ具体的にどういう問題点があるのか分からん上に wayland 全く関係ない

転載してなかったな

Debian GNU/Linux スレッド Ver.92
https://mao.5ch.net/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.5ch.net/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/


リンク先が切れてたっぽい

>>29
今のXのAPI（システムが提供してる訳じゃないから別プロセスへのインターフェースだけど）の形式で
どうやってウィンドウが保持してるGUI部品へのイベントを先取りできると？

>>29
>> ツールキット類の仕様（開発時）や操作感（使用時）の統一、使いやすさの向上
> これだけじゃ具体的にどういう問題点があるのか分からん上に wayland 全く関係ない

たぶんは>>28は実際にGnomeやKDEを使ったことなくて想像で言っているだけだとおもうよ

実際に使えばテーマ機構によりgtk+アプリもQtアプリも全く同じ見た目と操作感で動くから

>>31
しらんけど
xlib ができないんだったら x では出来ないし
互換レイヤーを作ってあるだけなら x で出来ないことを実装する必要はない

xlib ができないんだったら x で出来るし
互換レイヤーを作るなら x で出来ることを実装する必要がある

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

>>32
操作感が統一されてないなんてGNOMEKDE両方試せばすぐ違和感に気付くだろ

開発時の話は今時のフレームワーク類だとハンドラをウィンドウのクラスに記述するって時点で、
既にWinMacの類だとシステムがウィンドウに対してイベントをルーティングしれる事から考えると
単純なコールバックしか提供しないwaylandですら遅れてると言わざるを得ない

>>35
例えばVLCとかPhotoshop ElementとかKindleとかWindowsで動かしてみて違和感感じた?

これらはQtを使っているんだけど、Qtのような現代のクロスプラットホームのツールキットは
ネイティブなWin32のツールキットを使わず自前で描画していて、Windows上では標準で
Win風テーマエンジンでWindowsそっくりのルックアンドフィールを実現している

Linuxではどのディストリも何もいじならなければ同じテーマエンジンを使うようになっている
からQtとgtk+で違和感を感じることはない

本当は使ったことないでしょ?

それと
> 既にWinMacの類だとシステムがウィンドウに対してイベントをルーティングしれる事から考えると
> 単純なコールバックしか提供しないwaylandですら遅れてると言わざるを得ない
そんな仕組みになっていない

どっからそんなおかしな発想が出てくるの?

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

>>36
それQt限定だし、同じプラットホームでもQtとQtでしか比較しないつもりか？
GIMPのドロップダウンとか色選択のダイアログ（Winの場合は汎用ダイアログがあるんだが）の操作感は？

waylandのコールバックルーチンの設定のAPI見てこい
ウィンドウじゃなくってコントロールにはハンドラは設定できるが、
Winで例えればWM_NOTIFY〜の類はない、ウィンドウが子のコントロールのイベントを処理するっつー話だぞ？
コントロールに設定されたコールバックルーチンをコントロール（一種のウィンドウ）が処理するっつー話じゃないぞ？

>>38
> waylandのコールバックルーチンの設定のAPI見てこい
見ましたが

> ウィンドウじゃなくってコントロールにはハンドラは設定できるが、
> Winで例えればWM_NOTIFY〜の類はない、ウィンドウが子のコントロールのイベントを処理するっつー話だぞ？
> コントロールに設定されたコールバックルーチンをコントロール（一種のウィンドウ）が処理するっつー話じゃないぞ？
言っていることが現実の設計や実装と一致しません

君の妄想の世界では意味のあることを話していることになっているつもりなのかもしれないけど、
現実は全くそうなっていません

https://docs.microsoft.com/ja-jp/cpp/mfc/tn062-message-reflection-for-windows-controls?view=vs-2019

.NETのイベントハンドラの代入とかだけ見てるんだったら（ｒｙ

>>38
> 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

盛り上がってる所恐縮ですが他所でやっていただけませんかねえ？

てかコントロールのハンドラをいじらずにウィンドウ側でコントロールで発生したイベントをフックしてみろってんだよ
魔女狩りでもなんでもないから証明は簡単だろ？

くどい様だけどコントロールのハンドラで親ウィンドウを識別して特定の親ウィンドウに対して
更にコールバック（ただの関数呼び出し）を起こすとかじゃくって、親ウィンドウが一括して処理って話だからな？

>>40
それがどうかしたの?

全く関係ない話のようだけど

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

>>43
まず君が何をやりたいのかコードを示して
意味のあることをやろうとしているように思えない

>>45
そうなっているから

>>46
waylandでそんな事できないんだから魔女狩りさせんな

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

>>48
つまりコードを示せないんですね
全部妄想や捏造だと認めると

>>49
いいえ

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

なんでWindowsがWM_NOTIFYでやりとりしてると思ってる？
なんでWindowsのコモンコントロール（DLL）から更に派生したカスタムコントロールをDLLにして
言語を問わずに再利用できると思ってる？
関数決め打ちのコールバックに頼ってないからだよ

>>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ならインスタンスの元になったクラスの動作そのものを
改変できたりするのか？