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