Linuxプログラミング 2
>>348 <sys/ioctl.h> ioctl()がデバイス関連 read(),write()などの統一されたインターフェースから、 はみ出した部分 Windowsみたいに、GUIプログラミングで、 キーボードイベントを取ればよいのでは? GUIプログラミングしてないの? >>355 リヤルタイムキーボード入力を期待するなら、スキャンコードで処理するんじゃね? GUIで取り込めるキーボードイベントって前処理はいってないか?日本語変換とか? >>353 autotoolsは機能が多すぎるので、どの方法がスマートなのかを私は知りません。私はLIBS=pkg-configのような泥臭い方法をよく行います。 ntch: pullしたらdisp.hまわりが更新されてたので再びビルドテストしました。以下の全てで修正無しにビルド可能でした: Debian7.3(x86, 32bit) Ubuntu13.10(x86, 32bit) Arch(x86_64, 64bit) CLFS(x86_64, 64bit) Debian7.3以外の環境でも起きるかはテストしていませんが、:w による vi 起動で書き込み後に ntch へ戻った時点で、カーソルキーが効かなくなるバグに気づきました。 X11上でWMがxmonadの環境でのテストなので、少し特殊ですが。gnome-terminal, xterm どちらでも同様に書き込み後にカーソルキーが効かなくなりました。 (なお、c,j,k ntch: (なお、c,j,k,スペース を用いての移動には問題は起きてません。認識しなくなるのはカーソルキーだけのようです) また、非X11上ではこの問題は起きないようです。(生ターミナル上のfbterm上でテストした場合はカーソルの問題は生じませんでした) もしかしたらX11 xmonad環境側の問題かもしれないので、同様の報告が他に無ければ気にしなくてもいい問題だと思います。(c,j,k,スペース のみでも使うことはできるので) >357 沢山試して頂いてありがとうございます。 こちらでもFedora+Gnome3 , Ubuntu+Unityで試したところ 同様な現象が確認出来ました。 もしかしたら初期化したkeypadのライブラリーがviを呼び出すことでリセット されてしまっているのかもしれません 少しテストしてみます。 >>348 >>355-356 端末上で、コマンドでのリアルタイムキー入力なら、 stty raw -echo で、バッファリングとエコーを無くせる ただし、使った後は、端末の設定を元に戻すこと そうしないと、端末がおかしくなる もし端末がおかしくなったら、 Ctrl-J、stty sane、Ctrl-J、と入力する この入力も端末に表示されないが、これで端末が元に戻る それと、ddで、押されたキーを取得する その方法ではキーボードデバイスの正確なキー情報を得るには不十分なのではないでしょうか。 なぜなら、この方法では左右Shift,Alt,Ctrl等の違いを判別できそうにありません。 また、キーを放した際の情報も得られそうにありません。 また、Cならば普通はこれはtermiosで行なうことだと思います。 そしてtermiosだけではキーボードデバイスの正確なキー情報を得るには不十分です。 行ないたいことは、それが本当にキーボードデバイスなのかを判断したいということです。 キーボードデバイスを直接読む為に/dev/input以下evdev)のデバイスを使用することを考えてますが、 これらのどれが本当にキーボードデバイスなのかを知る為の方法として、どのような方法で皆は行なっているのかを聞いてみたい。ということです。 (もし自分が知らない簡単な方法があるならば、それを使わないのは損なので) 自分が現状考えてる判別方法としてはA,Bの2つあります: A: evdev以下の全てのデバイスに関して、ioctlでEV_CNTとEC_KEYで確認した上で、 かつ、一般的なキーボードデバイスに備わってると想定できるキー範囲 (KEY_RESERVED ... KEY_MIN_INTERESTING) にて、 そのビットが立っているならキーボードデバイスのはずだ、というヒューリスティックな判別方法。 これはlibxkbcommonのtestソースで用いられていた方法です。 B: udevによって /dev/input/{by-id,by-path} が作られる前提で、 bi-* 以下のキーボードデバイスはサフィックスとして、(どうやら)-kbd が付くルール(のような雰囲気)なので、 単純にそのような名前のデバイスがキーボードデバイスのはずである。という判別方法。 この方法は単純で簡単なので良いのですが、これは by-* に依存してます。 by-* を作るかはudev設定に依存する(らしい)ので(最近の環境なら問題無いはずですが)動かない環境もありうるという懸念。 Aならば by-* には依存しないので、Bよりも多くの環境で動作するはずですが、方法が泥臭すぎて疲れます。 そこでもしCがあるなら聞いてみたい。ということでした。 このあたりの、/proc/ファイルから、 キーボード情報を取れないか? IRQ(Interrupt Request) 割り込み要求 割り込みコントローラ cat /proc/interrupts I/Oアドレス、ポート cat /proc/ioports DMA(Direct Memory Addressing) cat /proc/dma PCIバス、PCIデバイス lspci Linuxカーネル解析入門、平田豊、2011 という本によると、PCIの仕様書は、 PCI SIGという団体が管理していて、有料らしい PCIコンフィグレーション空間に、 デバイスの種類や機能を示す、クラスコードというのがある 基本クラス[base class:0Bh]、サブクラス[sub class:0Ah]、 プログラミング・インターフェースクラス[programing interface class:09h] 基本クラスで関係ありそうなのは、 00h クラスコードが定義される前の、古いデバイス 09h Input devices この09hで、サブクラスの値で、マウスとKBが判別できるかも? これら以外は、udev関連かな? >362 > 左右Shift,Alt,Ctrl等の違いを判別できそうにありません。 思い込みで書くなよ... つか、xev のソースでも見れば? >>367 ページの読み込み中に、進むや戻るの操作を素早く行うと(ガチャ操作すると)、内部的に現在位置的な値の整合性がおかしくなる場合があるようです。 378が起きないように修正する、バンドエイド的な修正パッチ書きました。 https://gist.github.com/takeutch-kemeco/8155579 これでとりあえずれレバガチャしても大丈夫なようにはなりますが、 ソース全体をまじめに検証したわけではないので、(ただの適当なバンドエイドなので) これによってnt_read_thread()等の動作に変な副作用が生じてしまうか等は、なにも調べてないです。 >371 ありがとうございます 2,3日中にアップデートするのでパッチ適用させていただきます 多分、今の進む操作は、スレタイの選択キーと同じなので この時に(おそらく連続ネットワーク接続で)2chから弾かれて エラーの場合におかしくなってるんですね。 ただ、この時に以前に開いていたレス一覧の情報が残ってると 良いんですが無い場合に問題があるかもしれないので レス一覧の画面情報が初期化されているか確認する処理を 追加すると思います。多分 rwinp->data の非NULLチェックを 入れれば大丈夫かな? でも根本的には「進む」と「選択」は機能を分けた方が良いのかも しれませんね。 ところで、パッチ提供してくれた人のクレジットとかって どうやって書くのが適当なんでしょう? >>372 ごめんなさい。もう一個、修正いいですか。 スレッドタイトル一覧画面で r で更新すると、← で戻れなくなる問題の修正パッチです。 (これもただのバンドエイドパッチです) https://gist.github.com/takeutch-kemeco/8156110 >>ところで、パッチ提供してくれた人のクレジットとかって >>どうやって書くのが適当なんでしょう? 私もその辺の法律的(そして面倒)な問題は、なにが最善策なのかがよくわかりませんが、 個人的には何も書かなくて結構です。些細で適当なバンドエイドパッチですし。 文句言われない為の保険としては、よく見かける方法だと、 readme.txt 的なファイルに、協力者一覧のような項を作って、パッチやデバッグなどの協力者の名前を列挙しておき、 「この人たちが協力してくれました。ありがとうございました」とか何か適当に謝礼文でも添えとけば、それをしとけば、たぶん怒る人はいないと思います。 >373 ありがとうございます 参考になりました パッチは先行して出来るだけ早めにGitリポジトリに マージします。(tgz提供は後日になります。) Gitリポジトリ(ソースフォージの)にパッチを適用しました。 協力者についてはhelpとREADMEでは名前(ID)の言及にとどめて CONTRIBUTORSファイルを作成して詳しく記述してみました。 抜けがあったら申し訳ないです。 パッチについては一部変数の初期化値チェックを追加してあります。 よろしくお願いいたします。 >>375 ありがとうございます。問題無く動作するようになってました。 ntchいいね。 fbvみたいにフレームバッファ時にサムネイルが表示出来たら最強かも。 >377 ありがとうございます フレームバッファのサムネイル表示良いですね。 すぐには出来ませんが調べてみたらおもしろそうだと思いました rdtsc読み込み@ 〜何か処理〜 rdtsc 読み込みA A-@で得られた値は、「何か処理」だけが消費したカウンタ値と考えて良いんでしょうkぁ? LinuxAPIという言葉を使ったら笑われちゃった。Linuxではシステムコールって呼ぶんですか? Windowsにもシステムコールはある 非公開だからアプリケーションプログラマが意識することが無いだけ なんか残念な人みたいだが、まぁ頑張れ LinuxAPIと言われるとLinux特有のシステムコールを思い浮かべる cloneとか >>384 Linuxって弄るのが主目的で、基本的にプログラムの作成しない奴が使うものなんだよ。 だから、プログラムスレ過疎っているだろ ユーザーの超少ないLinuxでプログラムしたいなら、WinやMacでも使っているもの(Qtとか)をつかわないと レスは期待できない。 Win,Macプのレスに期待って感じ >>384 FocusOut/FocusInイベントのmodeを見ればいい ただしそれだとタイトルバーをドラッグした時も同じ挙動になるから注意 >>384 "xlib イベント" で検索してみれば? たとえば http://7ujm.net/X/event.html とか XNextEvent関数を呼び出して、引数として指定したイベント構造体の各メンバの値を調べるのが一般的らしい >>386-387 わからないならレスしないでください。 正直ウザイです。 ひどい事を言うようですが、真剣に質問しています。 [普及しないスレから移動] ウィンドウ・サイズ変更時のドラッグ開始、終了イベントに関して、 http://tronche.com/gui/x/icccm/sec-4.html SubstructureRedirect と ResizeRedirect イベント が関連してそうな気がする。 たまたま見つけたが: http://stackoverflow.com/questions/8867715/xlib-center-window 「If you set the override redirect flag when creating a window, then the window manager won't manage its size, position, stacking order, decorations, or map state (the window manager's redirection of ConfigureRequest and MapRequest is overridden).」 とある。override redirect flag を、window 作成時にセットしておくと、 window manager が、サイズや、位置、stacking(Z-Order、前後関係)、 map state(show, hidden)を勝手にいじらなくなるそうだ。 これを使えばウィンドウ枠をドラッグされた事を自分で検出すれば、 ドラッグされ始めたタイミングが分かるようになると思われる。 さらに、サイズ変更しない選択肢も可能になると思われる。 混乱を招く元: Win32 の WM_AAAA : WM は、Windows Message の略 X の WM_AAAA : WM は、Window Manager の略 http://tronche.com/gui/x/icccm/sec-4.html#s-4.2.2 ↑の 4.2.9. Redirecting Requests に今の議題に非常に関係したことが 書かれているらしい。 SubstructureRedirect : サイズ変更時に親に通知されるイベント ResizeRedirect : サイズ変更時に自分に通知されるイベント ResizeRequest : Window Manager が送ってくるイベント In particular, clients that need to take some special action if they are resized can select for ResizeRedirect events on their top-level windows. They will receive a ResizeRequest event if the window manager resizes their window, and the resize will not actually take place. Clients are free to make what use they like of the information that the window manager wants to change their size, but they must configure the window to the width and height specified in the event in a timely fashion. To ensure that the resize will actually happen at this stage instead of being intercepted and executed by the window manager (and thus restarting the process), the client needs temporarily to set override-redirect on the window. 正しくはこうらしい: SubstructureRedirectMask : マスク値 ---> ConfigureRequest Event XConfigureRequestEvent 構造体 ResizeRedirectMask : マスク値 ---> ResizeRequest Event XResizeRequestEvent 構造体 >>393 のリンク先の4.2.9の続きの部分: [Convention] Clients receiving ResizeRequest events must respond by doing the following: ・Setting override-redirect on the window specified in the event. ・Configuring the window specified in the event to the width and height specified in the event as soon as possible and before making any other geometry requests ・Clearing override-redirect on the window specified in the event If a window manager detects that a client is not obeying this convention, it is free to take whatever measures it deems appropriate to deal with the client. ・サイズ変更の動作を帰るウィンドウに ResizeRedirectMask マスク値を 設定する。こうすると、ResizeRequest イベントが通知されるようになる。 ・イベントハンドラに、ResizeRequest イベント がやってくる。 これが欲しかったサイズ変更のドラッグ開始のイベントである。 続けて、以下の処理を行う: ・override-redirect フラグを設定する。 このフラグを設定することで ResizeRequest イベントハンドラが再帰的に 呼び出されることを防ぐ。 ・新しいWindowの幅と高さをConfigure系関数を使って設定する。 普通であれば、ここで ResizeRequest イベントが再び発生してしまうが、 今回は override-redirect フラグを設定してあるので発生しない。 ・override-redirect フラグを解除する。 http://standards.freedesktop.org/wm-spec/1.3/ar01s04.html これちょっと読んでみました。 MDIや仮想デスクトップを想定しているようです。 今回は、ちょっと関係なかったみたいです。 やっぱり、Windowsが使われる理由ってそれなりにあるんだなあ。 「普及するわけない」スレで: > 572 :login:Penguin:2014/09/07(日) 00:43:51.87 ID:NGJ74wwz > >>569 > Qtはサポートしているイベントが明らかに少ないから。 の部分に関して。FLTKを調べていたら、Win32のWM_SIZEに相当する イベントが見当たらないと思って(実はあるのかもしれない)調べていたら test(サンプル)に resize.cxx と resizebox.cxx があって、ビルドして実行 してみると、TOP LEVELのnative Windowであっても枠をマウスでドラッグ する事によるサイズ変更には一応対応していることが分かった。 Qt や wxWidgetsのようなマルチプラットフォーム・ツールキットでは、 IME 関連の共通化は難しいかもなあ。 Windows では、WM_IME_xxxx 系のメッセージや専用 API で対応している んだけど。 >>401 スマン。Windows環境では、仮想関数のresize()が、WM_SIZE が来た時に 呼び出されるようなのでここでサイがズ変化した事を知ることが出来る と思う。ただし、resize() 関数を直接呼び出すことも想定されている 気がするので注意が必要。普通、Windowsだと、イベント・ハンドラは 人間が直接呼び出すことは無いんだが、FLTK だとあるのかも知れん。 TCPソケットでサーバー書いてるんですが select(2)の仕様に心が折れそうです プロセスかスレッドに逃げてもいいすか? さっき気づいたが、Windowsにできて X11 での実現方法が分かりにくい Window関連の事柄は、WINE Emulatorのソースを見ればいいんじゃないかと 言う事。 サイズ変更のドラッギング中のメッセージ、Z-ORDERの変更を拒否または 独自仕様にする方法、OWNER WINDOW(OWNED WINDOW) の作り方、などは どれも X11 での実現方法を見出すのは難しいが、WINE では出来ている。 TOP LEVEL WINDOW の場合は、WINE も X11 の native Window を利用して いるはずで、独自にグラフィックで矩形を描画したりしているわけでは ないはず。 なので、WINEで方法を知れば、そうそう大きくないソースで自前でも実現 できるはず。 Wineのソースを調べた。CreateWindowsExA() から沢山の関数呼び出しを辿って行った先に、 XCreateWindow() を呼び出している箇所を見つけた。 そして、XCreateWindow()の引数に設定するための attr や mask を計算する次のような関数を見つけた。 こんな感じで使われている: mask = get_window_attributes( data, &attr ); ・・・ data->whole_window = XCreateWindow( data->display, root_window, pos.y, pos.y, cx, cy, 0, data->vis.depth, InputOutput, data->vis.visual, mask, &attr ); なお、data->managed の値は、is_window_managed() の値に応じて切り替えられているらしい。 static int get_window_attributes( struct x11drv_win_data *data, XSetWindowAttributes *attr ) { attr->override_redirect = !data->managed; attr->colormap = data->colormap ? data->colormap : default_colormap; attr->save_under = ((GetClassLongW( data->hwnd, GCL_STYLE ) & CS_SAVEBITS) != 0); attr->bit_gravity = NorthWestGravity; attr->backing_store = NotUseful; attr->border_pixel = 0; attr->event_mask = (ExposureMask | PointerMotionMask | ButtonPressMask | ButtonReleaseMask | EnterWindowMask | KeyPressMask | KeyReleaseMask | FocusChangeMask | KeymapStateMask | StructureNotifyMask); if (data->managed) attr->event_mask |= PropertyChangeMask; return (CWOverrideRedirect | CWSaveUnder | CWColormap | CWBorderPixel | CWEventMask | CWBitGravity | CWBackingStore); } 初歩的な話でスマンが、X でも変更要求と変更通知のイベントはちゃんと分か れているんだね。 前者が、XxxxRequest 系で、後者は XxxxNotify 系。 override_redirect を使わなくても「フック」出来るっぽいね。 で、XxxxReueset系のイベントは、他のウィンドウが状態変更系関数を(勝手に) 呼び出した場合のみに発生して、自分で状態変更系関数を呼び出した場合は発生 しない。なので、XxxxRequest系のイベントが来た時点で自分自身で状態変更系関数 を呼び出した場合は、同じイベントが再帰的に発生することは無い。 したがって、 他のウィンドウBがウィンドウAに対して状態変更系関数を呼び出す --->Aに対してXxxxRequest系のイベントが発生 --->Aのイベントハンドラ到達 --->必要に応じて、パラメータを変えたりして同じ状態変更系関数を呼び出すか、 または、呼び出さない。 --->呼び出した場合は、(好きなように)状態が実際に変わる。 --->Aに対してXxxxNotify系のイベントが発生 こんな感じかな。 誤:他のウィンドウ 正:他のクライアント クライアント=プロセス の意味っぽいね。 ここはググレ無い人が書き込むと叩かれるスレですか? >>411 おいらは絶対叩かないが、2ch全般に叩く人がいるので、それを止める事は 出来ないと思う。「聞くは一時の恥」を真っ向否定するような掲示板だ。 調査結果によると、2chは低学歴な人が多いらしいが、人を馬鹿にしたり 意外な意見を全否定したりすることが勉強を出来なくしてきたのかも知れ ないと思う。自分の周りを見て経験的に馬鹿が多いので「馬鹿」とすぐ言って しまうとかも考えられる。2chを見ていると、 「自分がよく言われている事を人に言う」 という法則はつくづく正しいと思う。 >>414 聞く価値がなければ聞かないが、価値があれば聞く。 どんな意味の薄い話でも全部フォローしろというのは自分勝手な意見だよ。 >>413 言ってることにはだいたい賛成だが学歴を引き合いに出してるところがちょっと痛い 大部分の雰囲気は、2chの管理サイドの人間が作り出している。 実際に2chで質問に答えている一般人は非常に小数で、ほっておくと 掲示板として成り立たなくなるため、人を雇って質問に答えさせている。 そしてその人たちは一般人の振りをしてIPアドレスにもとづいて好き勝手に 反論を繰り返したりしている。 時々、すれ違いだとか>>417 のような書き込みがあるのは、管理サイドの 人間の都合によっている。 日本のほとんどの掲示板は、「ですます調」で話されているのに2chだけが 「ため口」なのも、管理サイドの人間がそうしているからである。「ですます調」 で話す人間がいると攻撃対象にするため、どうしても「ため口」ばかりになる。 これは、管理サイドの人間の生まれや育ちが「ですます調」の人間に支配される 側であったことと関連しているように思える。なので「ですます調」口調の人間 には悪意を抱いてしまうのだろう。 いや、おれ管理サイドなんかじゃないよ。 言っても信用しないだろうけど。 >>415 あんたの激しい思い込みのせいで、どう考えても客観的事実として明らかなことが「聞く価値がない」と断定されてしまっているケースを何度も見てるんで、 あんたはもっと自分の考えを疑って他人の言っていることが正しい可能性も検証したほうがいいよ JavaがC++の1000倍メモリ食う、なんてのは明らかに客観的事実と反してるから 価値があるかないかを判断するのが自分である以上、下手に自分は正しい他人は間違ってると断じて耳をふさいでたら、 事実を受け入れられない裸の王様になる可能性が高いのはさすがに京大卒だったらわかるだろ? >>422 あんたは、自分が信じられないような結果が出たら信用できないだけ。 歴史上そういうことは何度もあった。 >>422 実験したら、必ずJavaがメモリ大食いな事は証明できる自身があるから、 言ってるだけだ。自分の人生はいつもそうだった。 まず最初は、人が信用しない ---> 面倒だから放置 ---> 後で詳しく実験 ---> 実際にそうだったので否定していた人も認めざるを得なくなる こうなるのが目に見えているが、実験するのは貴重な時間の浪費になるだけなのでしないだけだ。 人に信じてもらっても何も得することはないから。 Jazelleがあるから今時ならC++の方がずっと食うだろうに >>424-425 そうだよ。信じられないようなことを言ってる奴が居るから信用できないだけ。 データを出せば信用するかもしれない、と言っているのに、データを出さないんだから信用できなくて当然。 人に信じてもらっても得することはない、と言うのなら、その事実は自分の心の中にしまっておけよ。他人を説得できるほどの客観性を持ってないことを言い続けるのは妄言にほかならないだろ。 現状、何もデータも検証方法も示さずにJavaのメモリ使用量の話をするのは、「STAP細胞はあります」と同じレベルの真実味しかないよ。 >>429 あなたに納得できる検証方法がないからと言って、間違っているというわけではないんだよ。 こちらの中では、まず間違いないと確信しているレベルには達している。 なんというか信仰心のある人は、根本的には嘘付かない。 なので、STAP細胞関係者とは全く異なる話になる。 >>430 誰もお前が正直者かどうかも分からないし スキルがどの程度で本当に分かっていっているのかもわからない だから>>430 の内容は意味ないよ >>430 再現可能な検証が出来ないのであれば その仮説が正しいか正しくないかは誰にもわからないはずだが。 >>430 「こちらの中では間違いないと確信いているレベル」←STAP細胞も小保方氏のなかでは確信してるだろう 「信仰心のある人は嘘はつかない」←STAP細胞も小保方氏は嘘をついているつもりはないだろう ということで、同じだよ。 あんたが嘘つきだ、正直者でないと人格を否定しているわけではなくて、検証方法や確信するまでの論理展開がおかしいんじゃないの、と言ってるだけにすぎない。 つまり、あんたがどの程度確信しているかなんて他人には無意味なんで、客観的に評価できる方法やその結果を提示してくれ、って言ってるのが理解できないのかな。 そこがわからない限り、>>414 であんたに>指摘した「人の話を聞く耳を持たない」という状態だよ、あんたは どんだけ自分がこれは真実だろうと確信していたところで、その確信なんて結局脳内の妄想が暴走した結果に過ぎない可能性がある。 その可能性を排除するために、科学的、工学的には、検証したい仮説が間違ってるかもしれない、と幅広い条件でテストする検証手順があるわけだろ。 その検証手順を「目に見えてるから貴重な時間の浪費になる」と省いてるくせに、「これが真実なんだ」と吹聴して回るのは、疑似科学や宗教の類と全く同じ構造。 小保方は単なるうそつき。 事件を起こした女の内、自白した人はほとんどいない。 カレー砒素事件の林真澄もいまだに自白はない。自分の子殺しの犯人も 自白してないはず。 小保方本人も確信していたわけではなく、うそ付いている自覚があってやって いたのに自白しないだけ。 >>433 オイラは間違いが少ないタイプなんだよ。 おっと、「確信したものに関しては」という但し書きが必要だけどもね。 まあ、何を言われようが人生の貴重な時間を、他人に信じてもらうためだけ に浪費するのは御免だ。 各自がちゃんと実験してみれば分かることだ。 >>434-437 あんたが間違いが少ないと主張したところでこっちはそれを確かめる手段は何もないし、 他人に信じてもらえなくてもいいのならチラシの裏にで書いてろよ。ネットに書き込まなくたっていいだろ。 つーか、「他人に信じてもらえなくてもいい」というのはコミュニケーションの拒絶であって、「人の話を聞く耳を持たない」と同じってことがわからないのかな。 結局あんたは井の中の蛙ってわけ。 オイラの名前と経歴を知ってたらそんなこと絶対に言えないよ って言い出すに100ペリカ >>440 それは本当にそうだね。自分で「自分は間違いが少ない、優秀だ」とこっそり思ってるぐらいならともかく、こんなところで公言して信頼を得ようと思うような人は どう考えても客観的に自分を見てない。 一般的にGUIの座標系は左上が原点になっています。 XlibでRTL環境の場合、座標系はミラーリングされますか? RTL環境、例えばロケールをサウジアラビア、アラビア語などに設定した場合の スクリーンショットがどこかに有ったら教えてください。 http://www.langbox.com/images/xlng_img.gif この程度のものは見つけたのですが、古すぎるせいか、RTL環境になっていません。 RTL環境では、例えば、ボタンの「はい」と「いいえ」でも配置が逆になります。 スクロールバーは通常左に配置されます。 そうなっているスクリーンショットを見たいのです。 >>445 どうも。 ブラウザはRTLになっているのに、デスクトップは文字の表示すらまともにできていないですね。 arabian.pngという名前から考えて、一番RTL出来てるぽく見えるスクショをとったんだろうけど。 やはり、アプリケーション側で個別に実装するしかないのかな。 WindowsはミラーリングとコントロールのRTL化で過去に作られたLTR製品も勝手に RTL対応になった経緯があるのですが、Linuxではそういうことしないのですかね? ミラーリングも良し悪しで、本格的にRTL化しようとすると、頭が混乱しますが。 一般ユーザが使えるRAM disk的なものってありますか? ありがとうございます。私の環境だとroot持っている人の裁量次第かも。 >>449 ああ、一般ユーザってそういう。 そりゃ一般ユーザが勝手にメモリを大量に消費しちゃアカンよね。 windowsもバカ!だがubuntuを始めlinuxもただだけでバッカ!! 素人を騙してPCを買わせているが、災害が起きたらタダのガラクタ! つまらん物に時間をかけるのでは無く、基本の大事な人との出会い、話し合い が本物、こんなバカタレPCは破棄し、最先端と言って洗脳され PCや製造企業に支配されてはならん! 本来の人間社会を取り戻せ! 一理あると思うんだよね バーチャルな世界で生きていくのはそれなりにストレスがかかるし、なにより生き物らしくない感じがするよ 日本中で税金を使って、やっている災害時対策は、 電気が止まると、何もできない それを知っているけど、官僚と、 ゼネコンなど官僚の取り巻き連中は、 税金を使いたくて、しょうがない 税金を使わずに残すと、自分達の権力が減るから、 絶対にそのことを、大衆のブタどもには教えない 本当は、予算は半分以下でも十分。 橋下がそれを民衆に教えようとしたら、 自公民などの既成政党は、必死に隠そうとする。 既成政党も官僚の手下だからだ 大阪はひどい。無人の市営バスが走り回る。 運転手の給料は一千万円 誰も渡らない、歩道橋ばかり作っている。 既成政党はそれらを、必死に隠す >>410 epollわからんのでスレッドにしました read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる