トップページ⇒tech
1001コメント321KB

Java低速GUI Swing 2

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
そんなSwingと引き続き付き合っていくみんなのスレッドです。

前スレ
http://pc5.2ch.net/test/read.cgi/tech/1062271447/l50

参考スレ
Java 高速GUI SWT　２
http://pc5.2ch.net/test/read.cgi/tech/1068349883/l50
041241105/02/04 21:31:38
あとKeyMapで変更した場合は

KeyMap keyMap = textArea.getKeyMap();
// keyMap の変更
textArea.setKeyMap(keyMap);

と，setKeyMap()しないとダメだったと思います．
(JTextComponent#setKeyMap() の内部でKeyMapを元にInputMapとActionMapを
更新していたと思います．
041340405/02/04 22:30:22
>>411
ありがとうございます！！

411の方法でバッチシ消せました。
そして412のKeymapの変更はどうやらいらないようです。

自分の方法がダメな原因がわかりました。
JComponent.WHEN_IN_FOCUSED_WINDOWとしていたからでした。
ここをJComponent.WHEN_FOCUSEDとしないと上書きが反映されないようです。

Swingも書籍はある程度出版されていて助かるのですが、
やはり細かいところになると情報がすくなくてつらいときあります。

ほんとにありがとうございました。
041441105/02/05 14:34:09
>>413
>>412 に書いたのはKeyMapを使ってキーバインディングを上書きする方法だから
InputMap を変更する場合に KeyMap を更新する必要はありません．

swing は jdk の src.zip にソースコードがあるので読んではいけない
理由(クリーンルーム実装する仕事があるとか)がないなら読んで調べる
のが一番確実です．最終手段ですけどね…
0415デフォルトの名無しさん05/02/05 22:43:58
エクスプローラの詳細ファイルリストのようなリストを作りたいんだけど、なに使えばいい？
JListだと列がないし、JTableだと行でなくフィールド一つ一つ選択できてしまう。
0416デフォルトの名無しさん05/02/06 00:23:21
>>415
jtable.setRowSelectionAllowed(true);
0417デフォルトの名無しさん05/02/06 00:55:24
>>416
うほ・・・さんくす
がんがってみます
0418デフォルトの名無しさん05/02/07 13:23:48
SWTの時代で、もうSwingは要らない時代でつか？
0419デフォルトの名無しさん05/02/07 14:04:50
Swingの時代でSWTが要らない時代になりますた。
0420デフォルトの名無しさん05/02/07 18:27:28
SWTでお仕事はまずないな
0421デフォルトの名無しさん05/02/08 02:02:32
Swingの仕事ももちろんないわな。
0422デフォルトの名無しさん05/02/08 02:34:35
おいおい、Swingの仕事やってる俺はどうなるんだ。
0423デフォルトの名無しさん05/02/08 08:37:29
某がSwing/SWTのクロスライブラリ出せばﾖｲﾝﾀﾞ



ってもうある？
0424デフォルトの名無しさん05/02/08 09:19:04
>>423
そんなん使うならSwingでよい。
SwingをSWTのインターフェイスで使うのはあほらしいし、わざわざSwingのインターフェイスでSWTを使うほどSwingとSWTの速さに差はない。
0425デフォルトの名無しさん05/02/08 10:16:30
そんなん使うならSWTでよい。
とはならないわけ？
0426デフォルトの名無しさん05/02/08 11:14:37
SWTは仕事で使う分には機能不足
Swingいまだに使えないと思っているやついるんか
0427デフォルトの名無しさん05/02/08 13:03:21
あ、そうなの？

Swingいまだに使えないと思ってたが、V2Cみたいなのは凄い。
ポトペタで作れる？
0428デフォルトの名無しさん05/02/08 13:58:37
ポトペタがないと作れない奴は使いものにならない。
0429デフォルトの名無しさん05/02/08 14:12:47
GUIで売れ行きや使われ具合が決まるんだから、
GUIはポトペタ、これ定番。
0430デフォルトの名無しさん05/02/08 14:14:39
>>429
前半と後半の論理がつながっていない。
0431デフォルトの名無しさん05/02/08 15:09:53
>>429
ポトペタで作ったら売れ行きが良くなったり使われ具合が良くなったりするのか？
逆に言うとポトペタ使えないと、売れない使われないGUIしか作れない、と。
それって >>428 を肯定しているだけでは？
0432デフォルトの名無しさん05/02/08 15:55:48
ポトペタがないと作れない奴はバカのは確かだが
ポトペタがあるのに意地でも使わないのもバカ
0433デフォルトの名無しさん05/02/08 16:45:17
バカ（良い意味で）
0434デフォルトの名無しさん05/02/08 17:51:10
おまいヴぁか>>431
DelphiのポトペタIDEはDelphiのポトペタで作られてる。

JBuilderのポトペタIDEは、、、知らん。
0435デフォルトの名無しさん05/02/08 19:04:52
ぽとぺたは開発効率という点で重要だろう
それはコストや出来具合にかかわってくる

JavaのGUI]ツールとしてのできは

NetBeans>JBuilder>JDev>EclipseVE

ってところだろう
0436デフォルトの名無しさん05/02/08 19:09:37
JDevとJBuilderって、同じものじゃないの？
NetBeansも使いづらいと思ってるんだけど、JBuilderってそれより悪い？
Delphiのアクションまとめるやつが、すげー使いやすかって忘れらんない。
0437デフォルトの名無しさん05/02/08 19:17:10
ポトペタにはNetBeansが良いわけ？
ランタイム用にインストールして起動もしなかったﾖ。

大昔にJBuilder使って最近Eclipse触っただけだったんだが、商用が良い筈と脳内で勝手に思ってたよ。
0438デフォルトの名無しさん05/02/08 20:01:20
>>436
昔は完全なOEMだった
だから今でも互換性のためにGUI部分はほぼおなじ
ただしバージョンは古いのかな

メニュー周りとかウィザードとかそういったところがJBuilderと比べて弱い
結果としてJBuilderのほうがいいというわけ

NetBeansは慣れるまで多少かかるが、慣れてくるとあふぉのようなつくり込みがイカス
ただし、Swingの仕組みをある程度知っている人向け
というか、JavaのGUIエディタすべてはSwingの最低限の知識ないときついけどな

>>437
ランタイム？JREじゃだめだよ、SDKいれないと

EclipseはJBuilder並みの親切さはないからその点はきついかな
というかJBuilderだけがとびぬけて親切度は高いと思う

初めてJavaのGUIいじるならJBuilderを進めたいけど、結局Swingを理解していないと
細かいところですぐに躓く

NetBeans以外はフレームとか地獄のサイズ指定になっているので
実際にアプリを組むときそのあたりで多少手がかかるかもしれない
0439デフォルトの名無しさん05/02/08 21:04:25
JBuilder軽いな・・・Eclipse使ってる俺が馬鹿のようだ
というか馬鹿だ
0440デフォルトの名無しさん05/02/08 21:16:23
Eclipse自体重くはないがVEは重い
JBuilderは６あたりからかな、軽く感じるようになって来たのは
NetBeansも3.6からはLAFの影響か軽く感じやすい
0441デフォルトの名無しさん05/02/08 22:20:45
>>438
解説サンクス
0442デフォルトの名無しさん05/02/08 23:45:25
ロジックをEclipseで書くからGUIもEclipseの方が楽なんだよね
確かに重いんだけど、GUIいじる時間もそんな長くないし
0443デフォルトの名無しさん05/02/09 00:37:50
業務用アプリのような膨大な項目をパネル単位で管理とか
そういったことしているとNetBeansじゃないと大変な希ガス

そもそもsetSizeしている時点でだめすぎ＞VE
0444デフォルトの名無しさん05/02/09 08:39:48
じゃ、ポトペタでJavaアプリ作るんならお金出せるならJBuilderだね。

SwingとSWTのアドバンテージが？でつ。
上ではSWTが機能不足とあるけど、自分の認識ではSwingに対して後だしジャンケンのSWTが高速、だったんだけど違うの？
EclipseとSWTがセットなんだっけ？
0445デフォルトの名無しさん05/02/09 09:38:34
ポトペタ部分をJBuilder Personalで大雑把に作り、
あとはそれを継承したクラスのイベントロジックをEclipseで作るってのはどうでしょう？

>>443
＞そもそもsetSizeしている時点でだめすぎ＞VE
詳しく教えて。setSizeってどこでされるの？
0446デフォルトの名無しさん05/02/09 10:30:11
自分でsetSizeする必要がるってことじゃないか？
0447デフォルトの名無しさん05/02/09 11:41:05
pack()とかつかってないということだろう。
JBuilderもそうだけど、JFrameとかJDialogとかはタイトルバーや
四方のインセットも含めてのサイズ指定が必要。

インセットを取得してそれを計算してサイズ調整しないと
環境によって表示が崩れる。
Swingの基本は推奨サイズを指定していってその結果
ウインドウサイズが決まるというもの。
各コンポーネントも環境によって必要サイズが違うからね。
また、環境をWindowsに固定したとしてもXPと従来のクラシックスタイルとでも
タイトルバーの太さとかかなり違うのは知っているだろう。

0448デフォルトの名無しさん05/02/09 12:00:49
>>444
機能不足と高速と、違う次元で比べて矛盾だと思ってるようでは甘いな。
0449デフォルトの名無しさん05/02/09 12:05:04
>>444
後出しじゃんけんというか、SWTがでたときはJ2SE1.3の時代。

このときのマシンパワーは低く、Pentium3/1GHzが比較的スペック高いほう。
メモリも今ほど贅沢にあったわけじゃないし、同じJREでアプリを動かしたとしても
今の環境とでは大きく差が出る。

そしてSwingも1.4になってから大幅に速度改善されて実用的になったのだが
ちょうどその直前あたりにでたのでSWTは当時としては軽かった。

ただし、どんどんSWTは重くなってるし逆にSwingはどんどん軽くなってきてる
また、ユーザーの多い環境であるWindowsは安定しているけどそれ以外が
わりと不安定だったりした。＞SWT

そしてもっとも問題なのがSWTはあくまでもWindowsのアプリをJavaで
作ろうという程度のものであって作り方からまるで方向性が違う。
感覚的にはWin32APIで作ろうとするのに似ている。
業務系に多用されるであろうテーブル系の機能不足とかほかにもコンポーネントの
機能不足がかなりの問題になる場合もある。

マシンパワーの向上とVMの大幅なパワーアップが原因だな。
現状SWTのアプリがあまり作られていないことからSWT=Eclipse専用とおもっていい。

一応両方触ってみるといい。まったくべつものでびっくりするから。
045044505/02/09 12:15:02
>>447
なるほど、普段packつかってなかったから、知らんかった。
packして推奨サイズにされる事が、「あれ？なんでちっちゃくなったの？」って思ってた。
一つ一つ推奨サイズを指定しなきゃいけなかったのか。

>タイトルバーの太さとかかなり違うのは知っているだろう。
このあたりはちょっと余裕もってsetSizeしてた。

推奨サイズを指定してレイアウトマネージャに配置を任せてはいるけど、
ウィンドウサイズは自分で指定したかったのでそうしてた。
0451デフォルトの名無しさん05/02/09 13:35:40
>>450
絶対的なサイズを扱いたいときはJFrameにJPanelをトップに貼り付ける
そのJPanelに推奨サイズを指定、JFrameにpack()をセット

あとはnullレイアウトだろうがご自由にどうぞ

余裕持ったサイズってのはWindowsだけならまだしも、Windows以外の環境を考慮すると
結構厳しいものがあったりする
Windowsでも年いった管理職の人とかタイトルバーとか外枠大きくしたりしている人も割といる
045244405/02/09 13:53:35
Swing良くなってるんだー。

自分が使ってた頃は、レイアウトマネージャとかいうのが邪魔して、
仕方ないからグリッドレイアウトを見えないように使って自由にポトペタやったんだけど、
それは今も一緒？
0453デフォルトの名無しさん05/02/09 13:56:29
Swingって遅いの？
045444505/02/09 14:07:32
>>451
>絶対的なサイズを扱いたいときはJFrameにJPanelをトップに貼り付ける
>そのJPanelに推奨サイズを指定、JFrameにpack()をセット

参考になりました。
ウィンドウサイズだけはキッチリ合わせられないもんだと思ってた。

>>452
>自分が使ってた頃は、レイアウトマネージャとかいうのが邪魔して、
>仕方ないからグリッドレイアウトを見えないように使って自由にポトペタやったんだけど、

今でもレイアウトマネージャは使うし、理解しなければGUIは面倒だよ。
VBみたいにやるのを想像しているならば、弊害も理解したうえでnullレイアウトでやればいいけど。
「グリッドレイアウトを見えないように」ってどんな使い方だ？
0455デフォルトの名無しさん05/02/09 14:48:21
>nullレイアウト
これって昔っからあったっけ？

>弊害も理解したうえで
環境変わるとコントロールがはみ出る程度の弊害、と理解したけどおｋ？
0456デフォルトの名無しさん05/02/09 15:07:23
>>455
nullレイアウトは昔からある。
Swingがでるまえから。

・絶対座標で扱うので文字のサイズとかちゃんとあわせないとダメ
・あわせたとしても特定環境でしかあわせられない

という点にきをつければいい。

VBやBCB、Delphiのように手軽に貼り付けれるし、これらもフォントサイズとか
環境をかえるとちゃんと動かないので、Windows専用とか割り切って作るなら
十分実用的。

特にWindowsとWindows以外ではOSのDPIの設定値が違うためにフォントは
問題になりやすい。

とはいえレイアウトなんて
・フロー
・ボックス
・ボーダー
の3種類の組み合わせだけで実現できるけどね。
これでできないようなのは通常の使用ではまずない。
0457デフォルトの名無しさん05/02/09 15:18:34
>>453
Swingがでたときは1.1のオプショナルパッケージで環境的に非常に遅かった。

Swingでなくともインタプリタメインで一部JITがではじめたりしたがJITも
コンパイル速度が問題になったり万能ではなかった。

マシンも２００MHｚ以下、３２MBとかの時代で特にメモリが厳しかったと思われる。
メモリが少ないとGCも頻繁に入るし、世代別GC導入前なのでループ中に
GCいれたりとかあほな環境だった。

1.2で標準で取り込まれ、クロスプラットフォームな高精度なGUIがでたのはいいのだけれども
重さは1.1以上に悪化したり。

1.3でhotspot導入などで高速化、安定化されサーブレット/JSPが流行り始めて
業務で使えるVMになってきたが、クライアント分野でのパワーアップは誰も見向きもしなかった。

1.4でさらなるクライアント方面のパワーアップに加えて描画がアクセラレーションが
環境に合わせてきくようになってSwingがはじめて実用的になる。1.4.1や1.4.2と
マイナーバージョンアップするにつれて速度が向上。
サーバーVMを筆頭にVM自体がどんどん頭よくなってきたのもこのころ。

と、Swing自体の改良もあるけどVM自体の改良や１GHｚ超えてメモリ２５６M
のってるのがすでに標準とか、そういったことも影響している。
0458デフォルトの名無しさん05/02/09 16:38:55
つーか、SWTをSwingの比較対象にもってくることが
おかしいよね。IBMですらSWTを単体で使うような真似は
ほとんどしていない。

例えばWMEではSWTの上をAWTで覆ってSWTを完全に隠蔽しているし、
SWTがメジャーになったきっかけのEclipseでもJFaceなどの
ライブラリを併用している。

SWTの単独利用をIBMが正式に打ち出したのは唯一eSWTだけ
だけど、これは組み込みのような貧弱な環境向け。
＃しかしこれもモトローラなどと共同でeJFaceの開発が始まってるらしい。

要するにSWTは各ウィンドウシステムの差異を最小限の厚さの
レイヤでおおうだけのライブラリ。Swingとくらべるようなもんじゃないよ。
0459デフォルトの名無しさん05/02/09 16:49:58
比較する位地付けとしてはAWTピアのほうが近いのだろうか?
となるとAWT-Swing, SWT-Swing, SWT-Jfaceといった使い分けになるのかな?
0460デフォルトの名無しさん05/02/09 17:32:56
>>459 そんな感じかなあ。JFace付けてもまだSwingに比べて機能的に
足らない気がするけど。
現状ではRCPのようなアプリケーションフレームワークまで含めてアプリ
ケーション全体の構築コストを考えてどっちを選ぶかって感じだと思う。

ところで、SWTってあれだけデザインパターンが多用されているEclipse API
のなかで、ぽつんと異質なものが混じってる感じなんだよね。
あと継承不可とかコーディング規約とか。エリック ガンマの本でも
SWTのとこになるとちょっと調子狂うし。あの部分だけ、
IBMから組み込み処理系を請け負っていたOTIが組み込み用に
別途作っていたライブラリを使いまわしたんじゃないかって気がする。
ってSwingの話じゃなくてすまん。
0461デフォルトの名無しさん05/02/09 19:20:19
じゃ、SWTは一時期薄いAWTのラッパとして存在したが、
異質でイビツなのでスルーでおｋ？
0462デフォルトの名無しさん05/02/09 19:25:19
まぁスルーでOKでそ。
0463デフォルトの名無しさん05/02/09 19:28:20
>>461 逆。IBMの一部処理系で、SWTをAWTで包んでいた。具体的には
Qt/motif/Win32/gtkをSWTでラップ、さらにその周りをAWTでラップ。
0464デフォルトの名無しさん05/02/09 22:53:41
まぁSWTも当時の出たばかりの勢いはないのは確かだな
Swingは立地クライアントで地味にのびてる
アプレットでもアプリケーションでもWebStartでもいいわけで
0465デフォルトの名無しさん05/02/10 01:37:23
1.4系統でJFrameの常に前面表示はできないでFA?
0466デフォルトの名無しさん05/02/10 02:28:59
NetBeans4.0日本語版リリースされた模様
これでJ2SE5のさらによくなったGUI（Swing）が組めるよ

5.0のWindowsLAFの出来のよさもすばらしい・・・
一番体感するところはJava2Dのアクセラレーションがきく描画かどうか
比較的意識しなくてもつかえるようになってるあたりか

J2SE5はGC時間も早いのですんげーべんりだな
0467デフォルトの名無しさん05/02/10 09:11:59
Swingが便利になったので、Javaでリッチクライアント作るのは楽勝でつか？
0468デフォルトの名無しさん05/02/10 10:44:15
Swingでここ3年ほどリッチクライアントつかってますが？
いまからなら1.4.2か5.0だと思うからデメリットはほとんどない

楽勝かどうかは腕次第だからなんとも
0469デフォルトの名無しさん05/02/10 11:55:08
めちゃくちゃ簡単、とか、超楽勝とか逝って、Java開発者を増やしてよ。
0470デフォルトの名無しさん05/02/10 12:09:53
SwingだろうがSWTだろうがDelphiだろうがVBだろうが、クライアントは楽勝じゃないなぁ。
細かい要望が多くて。
通信のタイミングとかも、考えるの大変だし。
0471デフォルトの名無しさん05/02/10 12:20:18
ユーザーの直接触れる部分であるからこそしっかりつくりたいところ
見た目で張ったりかましていればなんとかなるという親父もわりといる

俺はずっとクライアントサイドかいていたから慣れてるけど、WEBアプリが
流行ったのだってここ4,5年程度だし、その前はみんなC/Sだったし

実際のところWEBアプリのほうがあらゆるユーザーの挙動を考えると大変だよ
セッションなんてold世代にのこるから何も考えないとFullGC発生しやすいし
0472デフォルトの名無しさん05/02/10 13:01:13
>Delphiだろうが
>クライアントは楽勝じゃないなぁ。
これ恐ろしく楽勝だけど
0473デフォルトの名無しさん05/02/10 13:07:20
>>472
自分で考えて作るならどれも楽勝だと思うが
0474デフォルトの名無しさん05/02/10 13:15:23
>>471
そうそう、WEBｱﾌﾟﾘで良いものって面倒だよねー。

Javaで楽にC/Sなら、クライアントJDBC直接続？Java RMI？
XMLが無難なんだろうなー。
0475デフォルトの名無しさん05/02/10 13:40:16
C/SならJDBC直かと
3層式ならXMLを使うけどC/Sで業務でXML直接受けるDBってあまりきかない希ガス
0476デフォルトの名無しさん05/02/10 13:56:59
>3層式ならXMLを使うけど
やっぱ、インターネッツに出ちゃう場合は3階層が安心？
その場合はJavaにもXMLパーサーがあるからXMLが良いんだろうね。
0477デフォルトの名無しさん05/02/10 15:43:07
>>465
JNI使えばWindowsでは比較的楽に出来るよ。
0478デフォルトの名無しさん05/02/10 16:07:19
>>477
その状況で別OSでJNIのコール時点でエラーになるんだっけ？
それともJNI使うと、他OSで起動もしない？
0479デフォルトの名無しさん05/02/10 16:29:23
>>478
たぶん
1.動的ライブラリ読み込もうとする際にリンクできねーってエラーが出る。
2.それ(1.)を無視して続けるとJNIコールの時点でネイティブメソッドが見つからねーってエラーが出る。
0480デフォルトの名無しさん05/02/10 16:31:35
ｻﾝｸｽ>>479
なら、Win用にてきとーに作っといて、ライブラリのロード周りをきっちり作れば無問題だね。

で、ポトペタの動作はJavaとDelphiとどう？
D2005でかなり動作重くなったし、ｲｲ勝負かな？
0481デフォルトの名無しさん05/02/10 17:57:39
DLLやSOファイルは拡張子なしでロードするからそれぞれちゃんと用意していれば
まったく問題なく動く

また、ロードに失敗した場合の処理もトラップが必須になってるし
Windowsだけを考えてもそこの処理はちゃんとするものだろう

>>480
Delphiがいいというのは.NET前までだと思ってくれ
その後はもう別物

というかBCBやDelphiやってきた人にとってwindows.formsは操作感覚が非常に近い
Swingはまったく別物だけど、機能おっかけていけばこんなこともできるんだ、という感じで
機能の多さにびっくりするかもしれない
なんというかたとえるならオーナー描画の柔軟さがすべてのコントロールでできるとか
そういう感じ
0482デフォルトの名無しさん05/02/10 18:16:52
> DLLやSOファイルは拡張子なしでロードするからそれぞれちゃんと用意していれば
System.load(String) 使えばライブラリのフルパス指定もできるんだけどね。
0483デフォルトの名無しさん05/02/10 19:09:33
>>481
やっぱ、ヘジがいたDelphiは良かったけどいなくなったDelphiはよくないってことだね。
そして、ヘジがいなかったMFCは良くなかったけど、ヘジが入ったwindows.formsはいいってことだな。
0484デフォルトの名無しさん05/02/10 19:15:43
>>482
拡張しつきやフルパスだったらクロスプラットフォームが実現しにくいじゃないか
0485デフォルトの名無しさん05/02/10 19:49:50
>>483
そろそろDelphiスレか.NETスレ行ってくれ。
Swingとは関係ない話題だし、暇人が宗教論争をしかけてるようにも見えるし。
0486デフォルトの名無しさん05/02/10 19:53:08
Swingはヘジルスバーグのコンポーネントから非常に大きな影響受けてるわけだが。
0487デフォルトの名無しさん05/02/10 20:11:34
でも結局SwingほどのGUIライブラリはないやね
これ作ったやつ頭おかしーだろ（いい意味で）というくらいのライブラリだよな
0488デフォルトの名無しさん05/02/10 20:24:15
>>486
ヘジルスバーグのスレでも作ってそこで雑談しろ。
0489デフォルトの名無しさん05/02/10 22:46:05
ヘルシーハンバーグ
0490デフォルトの名無しさん05/02/10 22:58:44
ヘルシーハンバーグ食べながら雑談か。素敵だな。
0491デフォルトの名無しさん05/02/13 00:23:25
>>474
そこでSeasar2ですよ。
http://pc5.2ch.net/test/read.cgi/tech/1102862221/l50
0492デフォルトの名無しさん05/02/13 01:28:01
しーざーちゃんはいいものだが、そのCSクライアントという流れからは
必要性が感じられないぞ
0493デフォルトの名無しさん05/02/13 01:55:23
SpringならSpringRCPかなんかが開発中だね。
0494デフォルトの名無しさん05/02/13 14:26:53
レイアウトマネージャー、最初は
勝手に位置、サイズかえてんじゃねーとか
思ってたけど、わかると便利だね
0495デフォルトの名無しさん05/02/13 14:37:54
>>494
だんだんJavaのＧＵＩにはまってきてるわけですな
特にSwingのコンポーネントにはまると、もう抜け出せなくなるな
0496デフォルトの名無しさん05/02/14 01:49:37
質問なんですが、
Webブラウジングクラスってどうなんでしょうか？
ブラウザ作ろうかなって思ってるんですが…。
そこはSWTのBrowser クラス使うべきかな？





SwingのWebブラウジングクラスの名前忘れた。
SWTのBrowser クラスの名前も違うかも…orz
0497デフォルトの名無しさん05/02/14 02:17:25
>>496
JDIC のブラウザコンポーネント使えば？
http://jdic.dev.java.net/

javax.swing.JEditorPane もHTML表示できるEditorKit持ってるけど、
標準の奴はHTML3.2対応だしCSSも半分ぐらいしか実装してなかったと思う。
0498デフォルトの名無しさん05/02/14 08:42:59
>>494
それ、どう分かるのか教えてキボンヌ。だってここはSwingスレでそ。
0499デフォルトの名無しさん05/02/14 09:03:50
>>498
何が言いたいんだ？
050049805/02/14 09:15:58
>レイアウトマネージャー、最初は 勝手に位置、サイズかえてんじゃねーとか 思ってたけど、

これは分かる。

>わかると便利だね

これ分からないから説明しる
0501デフォルトの名無しさん05/02/14 09:23:55
>>500
レイアウトマネージャ（の使い方）が分かると、
(nullレイアウトで絶対位置を指定するよりも）便利だね
という意味では？

それともお前にレイアウトマネージャの分からない部分があるということか？
それなら何が分からないのか質問しろ。質問せずに「説明しろ」はこたえようがない。
0502デフォルトの名無しさん05/02/14 09:27:01
>>500
>>494じゃないが、Javaのレイアウトマネージャになれると便利だよ
ってことだろう、ウインドウの大きさを変えても自分で計算することなく
座標や大きさを勝手に計算してくれるし、プラットフォームを変えても
レイアウトが崩れにくいとかあるんじゃないのか？
0503デフォルトの名無しさん05/02/14 09:27:01
>>500
つまり、お前の日本語を意訳すると、

レイアウトマネージャーは、勝手に位置、サイズかえて使いもんにならない。
レイアウトマネージャーは不要で、nullレイアウト最強。
はぁ？「わかると便利だね」？あんなもののどこが便利なのか教えてくれよ

ってことか？
050449805/02/14 09:41:13
みんなボンクラ杉。

レイアウトマネージャーウィザードが居るんなら、
Swingエバンジェリストとしてレスすれば良いだけ。

大騒ぎして叩くことが良いことだと思ってるだろ。
ふつーに、静かにレスしる！
0505デフォルトの名無しさん05/02/14 09:53:47
>>504
他人に注意するなら自分も気をつけてもらいたいものだ
0506デフォルトの名無しさん05/02/14 09:54:11
GUIえぢた使ってると、NetBeansでもJBuilderでもEclipseVEのどれでも、SplitPaneの左側が使いにくくなる。（最悪アクセスできなくなる）
まぁGUIのほうでアクセスできなくても、ツリーのほうでPanel追加してサイズ指定してやればいいんだろうけど・・・

もう少しどうにかならんの？
0507デフォルトの名無しさん05/02/14 10:00:54
>>506
dividerLocationを変えておけばいいんじゃない？
0508デフォルトの名無しさん05/02/14 10:12:27
>>504
誰もたたいてないだろ。お前の質問の意図が分からないから
聞いているだけだろ。で分かったのか？
0509デフォルトの名無しさん05/02/14 10:26:29
レイアウトマネージャを使うことで、修正が楽だったりすることもある。
FlowLayoutでコンポーネント並べて配置していたとする。
「この隙間にもう1つコンポーネント追加」って場合に、普通に追加することで
影響のあるコンポーネントも勝手にずれてくれる。

nullレイアウトで、自力でキッチリ配置してた場合には、
他のコンポーネントの配置も自分でずらしたりしなければならなくて大変。
051049805/02/14 10:37:27
>>509
あ、なるほどプログラムでレイアウト処理入れるの開発効率も仕上がりも落ちし、改善大変であきらめちゃったりするよね。

Delphiのコンポーネント形式の、Align＝alNone/alTop/alBottom/alRight/alLeft/alClient/alCustomと、
AnchorsセットのakLeft/akTop/akRight/akBottom＝true/falseのんが良くない？
0511デフォルトの名無しさん05/02/14 12:12:54
うーん、それでJavaのレイアウトマネージャーと同じことができるとは思わんのだが。
それよりDelphiのActionListだったかなんだったかが欲しい。
■ このスレッドは過去ログ倉庫に格納されています