アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
日本の開発者が増えるには (スコア:0)
とあるVB房がLinux開発環境に抱いているイメージ (スコア:2, 興味深い)
2.VBみたいに簡単にGUI作れるの？
VC++未満のWin32API叩くような感じな気がするけど・・・
そういえば、Kylixとか聞いたけど使えるようにするのは簡単？
3.KDEとGnome、gtkとかqtって何？
そもそも違っても別のLinux環境でも動くの？
4.理想は言語内ですべて済めばいいけど、そうはいかないし。
さて、日本語のAPIドキュメントってあるのか？
MSDNレベルの整理されたドキュメントは欲しいなぁ。
開発環境に統合されてれば最高！
5.IME(FEP)の制御って簡単に出来るかな？
まさかFEP毎に別のAPIをコントロールがフォーカス取得時に
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:1, 参考になる)
> 1.開発HowToが書かれた日本語の書籍は少ない・・・気がする。
VB 等に比べるまでもなく、実際に少ないと思います。
Web のリファレンス/チュートリアルでは不満な人には、厳しいかも知れません。
> 2.VBみたいに簡単にGUI作れるの？
> VC++未満のWin32API叩くような感じな気がするけど・・・
> そういえば、Kylixとか聞いたけど使えるようにするのは簡単？
kylix を使えるようにするのは、単にインストールするだけなので簡単でしょう。
フリーの UI ビルダも、 GTK 向けの glade があります。
Qt 向けのは知らな
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:1, 興味深い)
>
> VB 等に比べるまでもなく、実際に少ないと思います。
> Web のリファレンス/チュートリアルでは不満な人には、厳しいかも知れません。
手元にKDEの本が3冊、Qtの本が1冊あります。入門用には足りたけどやっぱ少ない。
>> 2.VBみたいに簡単にGUI作れるの？
>> VC++未満のWin32API叩くような感じな気がするけど・・・
>> そういえば、Kylixとか聞いたけど使えるようにするのは簡単？
KDEやQtが想定してる範囲内ならMFCより楽。
それより下の層を触るときは、X1
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:1)
>> 難しい問題ですが、 statically linked なバイナリなら 5 年くらいは動くのではないかと。
>> # 5 年後に X が無くなっていると無理ですが…。
>すくなくともMacOSXとXみたいな感じではXは残るだろうから心配要らないと思います。
現状を知らないんですが、
Staticにしたら、洒落にならないサイズ…になったりはしないものですか？
Delphiとかでも(DelphiライブラリをStaticLinkした)実行ファイルは数百kbで、
更にWinだと本体据付なGUI足回りの多くの部分も、GNOME/KDEだと「StaticLink」
しないとならんわけですよね。
＃いくらディスクが安くなったとはいえ、やっぱり大きい実行ファイルが山のように存在してると気が滅入るのでG7
＃＃そのせい「も」あって、近年はめっきりScript言語野郎してます。小ささとメンテ性を考えるとScriptが一番かも。
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:0)
でも実際はGnomeにしろKDEにしろフリーソフトの99%ぐらいはソースで配布にするかパッケージで配布して依存ライブラリはパッケージングシステムに任せるかで問題にはなってない気がします。
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:1)
ソースからmakeすることの、初心者(??)に対する敷居を、下げないとアレですね。
…とはいえ、自分で考えてOptionいじる必要がある場合でもなけりゃ、
makeそのものが難しいっていう感覚はほぼゼロですね。
「インストーラー」がconfigure;makeをすればそれでいい、のかな…
>パッケージで配布して依存ライブラリはパッケージングシステムに任せるかで問題にはなってない気がします。
100個のアプリが、100個の「バージョン違いの」ライブラリを要求したら、
結構悲惨なことになりそうですね(^^;
ところで、やっぱりライブラリ間の依存関係ってのは、
ガベージコレクションみたいに
参照カウント法とかマーク＆スイープ法とかで
「不要」になったことを判断して自動アンインストールする(してくれる)ものなん…ですよね？？
＃メモリ管理(GC)と比較して考えると、「ライブラリを置くPathはmake時に確定すべきだ」
＃というUnix的(?)発想は、前近代的だなと思えてならないのでG7
＃名前に束縛されることで、複数の共存がやりにくくなるじゃん。
＃malloc()の出力はアドレスを問わないのが味噌なんだよね。名前空間的にも物理空間的にも"Location"の縛りが無い。
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:0)
> 現状を知らないんですが、
> Staticにしたら、洒落にならないサイズ…になったりはしないものですか？
なりますね。
Windows 環境での開発には詳しくないのですが、 Windows アプリケーションを配布する際には、 DLL の非互換性を嫌って、実行ファイルと同じディレクトリに DLL を置くのが普通になっていると聞きました。 DLL Hell と呼ばれてるとか何とか。
# 昔は、アプリケーション毎に、違うバージョンの MFC42.DLL を持ってたりしましたよね。最近は違うのかな?
こんなこ
DLL Hell (スコア:1)
インストーラーによっては、古いバージョンのMFC42.dllで
新しい物を上書きされてしまうのが問題だったと思ってます。
どちらかといえばインストーラの問題なので、
WindowsやMFC42.dll側の問題とは違う気もします。
そこらへん、Linuxだとインストールするのに、
依存関係のチェックがあるものが多いので発生しないのかも。