Kylix3

C# がいまだ未知数な以上 mono もどうなることやら、って感じだな。
mono で GUI となると、5 年後に存在してるのかどうかすら怪しい。

頑張ってる人は頑張ってるんだろうけど。

>>485
それもそうだけど、Borland PascalコンパイラもLinux版メンテしてほしい。
FPCは遅い。Lazarusの最大の問題点はVCLとの互換性じゃなくコンパイラの遅さ。
速くないならPascalつかうメリットない。

そうなんか？ Pascal 好きな人って文法とかを偏愛してるのかと思ってた。

>>483
javaだとパフォーマンスがとか思う私は旧人類でしょうか･･･

>>484
そう、そうなんです。
GUIをどうするか。
はたまたIDEはということになるし･･･

>>486
正直それは追いかけていませんorz

ああ、そろそろ決めなければいかんな･･･
どうせどうころんでも私の責任にされるだろうし･･･
会社やめようかな･･･

>>489
文法を偏愛している人はModulaを(ry

>>490
Javaのパフォーマンスは昔ほど気にならない。最初にロードする時間さえ
我慢すればその後の動きは割と快適。GCで引っかかったような動きになる
のはあるけどね。

でも俺はQt4を狙ってる。まだ出たばかりなのであまり詳しく見てないけど
Qt3よりはだいぶ進化してる。やっとWinでもフリーになったし。

このスレで聞くのがいいかわからないんですが、他に適当なスレがない
のでここで質問します。

Delphi5で構築したC/Sシステムがあります。DBはFirebirdです。
10プロジェクト(exe)、200ユニットで、ストアドやビューよりは
TQuery（実際はIBO）にSQLを直に書く方法を主にとっています。

が、今度クライアントマシンがLinuxになるということになりました。
最短、最小限の労力で上記システムを移植したいのですが、
みなさんならどうしますか？　現在のところ考えている選択肢は

・Kylix3
・Lazarus
・JBuilder

です。ちなみに当方は2年まえにKylix3でのC/Sシステムが１プロジェクト
だけ経験があります。LazarusはWindowsで入れてみてちょっと弄った程度、
JBuilderはServlet/JSPはよくやっていますが、クライアントアプリはDBを
使わない簡単なツール程度しか経験ありません。

Qtなどでやるのが完成度は高いのは想像できますが、工数がかかりすぎる
のではないかと思い、上記３案を考えています。他の案も含めアイデアが
あればご教授ください。

>>493

・Wine

Wineがついにベータ段階へ。Ver.0.9リリース
ttp://slashdot.jp/articles/05/10/26/0735259.shtml

Wineは厳しいだろうなあ。Delphiで作った単体アプリがWineで動く可能性は高いけど、
DB系はどうかな。Windows用のFirebirdクライアントもWineで動かす必要があるんだよな。

じゃ、クライアントがWin以外になるわけだから、
ウェブブラウザアプリじゃね？

ウェブアプリなら、Delphiでも作れるから工数削減じゃん。
本当にDelphiのまんまだとHTMLを文字列処理だからイマイチだけどね。

IntraWebだとポトペタかなぁ？

>>496
それじゃC/Sじゃないじゃんｗ

Delphiのソース（DBアクセス）をそのままJNIにコンパイルできるよ。
で、Javaから呼び出す事も可能。

>>499
そのコンパイルされたネイティブコードがLinuxで動くと思う？

サーバーで動かして、サーバーJavaからクライアントに結果表を渡してみてはどうでしょう？
ただ、DB部分のソースが生きるだけで、残念ながら開発が楽じゃあないな。

そりゃあKylixでやるのが一番楽そうだけど実際に使用する
Linuxのカーネルやライブラリのバージョンでの動作検証を綿密に行う必要ありそうだあな。

あと、帳票をどうするか。Delphi5だとまだRaveReportじゃないだろうからそこは最低作り直しだな。

>>502
RaveReportへの書き直し程度は覚悟しています。要はトータルでの工数が
ある程度削減できればいいんです。Kylixで作ったバイナリ、最近のLinuxでも
問題なく動いてますか？

それはこのスレのログを見ればわかると思うが。
特に>>475のリンク先の情報は重要だろう。

Kylix3を使用して，フォーム上で複数のフレームをnewで生成しようとしてい
ます．
しかし，TFrameから派生させたフレームTFrame1を1つのフォーム上で複数生成
するとランタイムエラーが発生してしまいます。 下記のプログラムですと、1
つめのフレーム生成は成功するのですが、2つめのフレームframe2の生成がで
きません。 
TForm1のコンストラクタ{
    TFrame1 *frame1,*frame2;
    frame1 = new TFrame1(this);
    frame2 = new TFrame1(this);
}


実行すると
Systemファイルが表示され「->」の位置で実行が止まっているようです。
    procedure _DbgExcNotify(
    NotificationKind: Integer;
    ExceptionObject: Pointer;
    ExceptionName: PShortString;
    ExceptionLocation: Pointer;
    HandlerAddr: Pointer); cdecl; export;
->  begin

解決方法をご存知の方がおられましたら，ご教授ください．

Kylixは知らないけど、Nameプロパティを変えていかないと、
設計時のNameプロパティがそのままロードされてて、
衝突してるとかじゃなくて？

kylixで作ったプログラムってLinux上で動くの？？

>>507
むしろLinux以外では動かないと思うけど。

Linux でも動かない事例が増えてんじゃないの？カーネル違いやらライブラリのバージョンやらで。

そもそも使っている人を見かけないから情報が少なすぎる。

IDEが動かなくなった。たぶん、qtとかのバージョンのせいだと思うのだが………
かくなる上はchroot環境で古い環境を再現して、Xを飛ばすという裏技しかないかなぁ

Kylix on Eclipseが噂されてるけど、

CLX
-----------------------
OS依存レイヤ(SWTのDLL, so)

で再構成してくれんかなあ。

SWTのdll,doって、JNI用に作られてるんじゃないのか？
その構成だとJVMが常にロードされてしまいそうな…

>>512
QtがTrollTechという１企業でメンテされてるのに対して少しは将来的不安がなくなりそうなので。
Qtも最近少しはライセンス緩くなったけどね。

将来的不安って、そもそも Kylix に将来はあるのだろうか

Kylix自体じゃなくってKylixで作ったアプリがOSのバージョンが上がって動かなくなるといった意味ね。

ところで、オマイらkylixをどんな環境で動かしてる？
最新の環境にすると挙動が怪しくなるのだが。

駄目じゃん、ちゃんと RedHat 7.2 で動かさなきゃ。

>>513
> QtがTrollTechという１企業でメンテされてるのに対して少しは将来的不安がなくなりそうなので。
> Qtも最近少しはライセンス緩くなったけどね。
ボーランド1社がクローズドソースで管理しているKylixを使うぐらいだったら
Qtの将来を心配する必要はないね。

つか、QtはTroll以外でもメンテされているし。

x86_64対応マダー？

忘れない為に貼っておく。

How To run Kylix on a 2.6.x Linux kernel ? KLX3
http://support.borland.com/entry.jspa?externalID=16983&categoryID=102

Kylix を買ってくれるような奇特な企業はあるんかいな
Qt 作ってる Trolltech とかが買えばよさそうだけど、そんな体力ないか

http://japan.zdnet.com/column/interview/story/0,2000053136,20098072,00.htm

現在、ボーランドのIDE製品にかかわっているメンバー、開発担当者、サポートエンジニア部隊、そして私自身も、引き続き製品にかかわっていきます。 Delphi、C++ Builder、C# Builder、JBuilder、InterBaseなどの将来については、安心していただきたいと思っています。

Kylixは？…orz

Ｋｙｌｉｘがダメになった原因って難だろう？

復活は無いのかなぁ？

様々な環境に対応させるためにQTが必要だったから｡
それにｌｉｎｕｘ使うならソースで配布する方が利用者にとってはなじみが深いから｡
Windowsべったりを避けるなら今はＰＣ−ＵＮＩＸとなったＭａｃに行った方がいいと思う｡
ここならソース配布しなくても受け入れられるし､
とりあえずＯＳのバージョンごとにＧＵＩも単一で互換性を考えなくても良いと思う｡

個人的には復活して欲しいなぁ｡

>>524
CocoaもC++用のラッパー作れそうだしな。

またマカーか！

>>524
ダメだった理由だよね。
> 様々な環境に対応させるためにQTが必要だったから｡
これはどういう意味だろうか。Qtが必要だったらからダメってことはないよね。
KDEはQtを使っているけれど、おそらくKylixで作ったソフトウェアより多く使われている。

> それにｌｉｎｕｘ使うならソースで配布する方が利用者にとってはなじみが深いから｡
これもちょっと違う。たとえば、Linuxのアプリを使っている人がどれぐらい自分で
日常的にコンパイルしているかというと、ま、ほとんどしていないね。
Linuxそのものが多くの環境で動作しているとはいえ、大半がx86といって差し支えない
と思う。だからうまく作れば、FirefoxやOOoと同じようにバイナリで配布することも可能
だったはずだ。要はKylixの出来が悪かったのが最大の問題じゃないかと思う。

> Windowsべったりを避けるなら今はＰＣ−ＵＮＩＸとなったＭａｃに行った方がいいと思う｡
> ここならソース配布しなくても受け入れられるし､
有償版Kylixならソース配布は必要ないからこれもズレている。
あえて言うなら、「Mac環境ならLinuxとよりも有償ソフトが受け入れられるし」だろうな。

> とりあえずＯＳのバージョンごとにＧＵＩも単一で互換性を考えなくても良いと思う｡
QtがOSのバージョン間でトラブルを多発したことを考えれば、Macだから互換性を
考えなくても良いってことはないだろうな。

こっちをがんばりましょう

【Delphi互換!?】FreePascal【GPL】
http://pc8.2ch.net/test/read.cgi/tech/1137051510/

Linux で Kylix (C++ の部分) する人すらほとんどいなかったのに、
Linux でわざわざ Pascal する人はさらに少ないのでは。
さらに言えば Linux では C++ 人口も少なくて未だに生 C 好きが多いんだよな。

＞Linux で Kylix (C++ の部分) する人すらほとんどいなかったのに、

デスクトップアプリが少ないんだお。
それをポトペタで解消しる！

Ｋｙｌｉｘ復活お願いします。

生Cはエロイ

>>527
Qtのライセンスがらみでのゴタゴタはあったよ。商用Qtを使用しているにもかかわらず
Qt単体ライセンスより低額であることで制限を受けることになった。

あとソース配布じゃないというよりソース公開じゃないことが普及の妨げにはなった。
FirefoxやOOoはバイナリー配布されてようとオープンソースじゃん。いろんなディストリ
いろんな環境で動作させるにはユーザによるパッチとフィードバックが必要だったのに
オープンソースじゃないからユーザは手を出せなくて、ベンダーがそれを負わざるを得なく
なったが実際はそれを怠った。

Mac云々は問題外だな。企業でも個人でもUNIXとしてMacを使うメリットが全くない。

kylix・・・
すっかり廃れたな

そんなことない。みんなの心の中には永遠に刻まれてるさ。

昨日、Kylix 3をDebian Sargeにインストールしてみたけれど、ライブラリの
シンボリックリンクをいくつも作らないと行けない。ちょっと面倒だね。

そりゃそうだ。ユーザ環境で動かすのも大変。