KDE developer のための FAQこれは http://developer.kde.org/documentation/other/developer-faq.html を訳したものです。
一般的な質問新しいアプリケーションを書き始めたいのですが、何かアドバイスはありますか？新たに書かなければいけない KDE アプリケーションがたくさんあるのは間違いありません。しかし、 あなたの助けを必要とする既存の KDE アプリケーションがたくさんあるのも確かです。 どの分野に助けが必要か知るには、このページをチェックしてください。 新しいアプリケーションを書き始める前に、apps.kde.com や kde-devel@kde.org のメーリングリストで、誰かが似たようなプロジェクトをしていないかどうか確かるのは良いことです。 私は開発者です。どうすれば KDE に貢献できますか？job list でオープンな仕事をチェックして下さい。あなたができる仕事は必ず１つはあるでしょう。 KOffice や Kdevelop などは高く評価されているにもかかわらず、開発者がとても少ないです。ですからそのあたりをチェックすると良いかも知れません。KDE のプロジェクトを手助けするのに、KDE のコアの開発者になる必要はりません。KDE は非常にうまくモジュール化されているので、全体のシステムがどうなっているか知らなくても、１つの分野を改良することができます。 また、kde-devel メーリングリストで、誰かがアプリケーション上での手助けを必要としているか質問することができます。 最新の KDE を使い必要とされていることを見付けて下さい。テーマジェネレータですか？konsole のスキーマエディタですか？ゲームの改良ですか？いつも小さな特徴が抜けているものです。実装してしまいましょう。 特定の分野に関してくわしかったり、興味があったりしますか？あなたの手助けが役に立つその分野に関連するアプリケーションがないかチェックして下さい。もしくはそのようなアプリを書いて下さい。KDE はおたく向けではないアプリケーションをもっと必要としています。 私は開発者ではありません。どうすればお手伝いできますか？開発者のスキルを必要としない仕事がたくさんあります。KDE の促進のためにアプリケーションのレビューを書いたり(kde-promo メーリングリストを見て下さい)、ドキュメントチームを手伝ったり(i18n.kde.org/doc を見て下さい)、翻訳を手伝ったり(i18n.kde.orgを見て下さい)、新しく出てくるバグをフィルタリングするのを手伝って下さい(bugs.kde.org を見て下さい)。 Konqui dragon の画像はどこで手に入れることができますか？ftp://ftp.kde.org/pub/kde/devel/konqi_sdk.tar.bz2 で入手可能です。 KDE に貢献するのに必要なスキルのレベルはどの程度ですか？何を学んでおくべきですか？何を読んでおくべきですか？C++ について知っている必要があります。Qt で何が可能か知るためにQt tutorials を読み、 Qt docs を拾い読みしてください。そして、KDE tutorials を読んで、アーキテクチャやドキュメントを斜め読みしてください。また KDE Book を読んでも良いかも知れません。害にはなりません。しかし、KDE の開発者になるのに、KDE 全体のアーキテクチャについて詳しくなる必要はありません。KDE のテクノロジーを利用することはとても簡単なので、本当にあなたが必要とするところだけに集中してください。他の部分については後で学べます。 developer.kde.org や doc.trolltech.com（$QTDIR/doc/html にもあります）は計り知れない程の情報源です。これらを利用してください。 その後、ソースを読んで、examples ディレクトリを探して、他人がそれらのアプリケーションをどのようにコーディングしているか見て下さい。コードを読み、書くことはいちばん良い学習方法です。 CVS って何ですか？どうやって CVS から KDE を入手することができますか？anonymous cvs page を見てください。 .cvsrc には何を書いておくべきですか？cvs -l -q -z4 自分のアプリケーションを KDE に含めたいのですが…三つの必要条件があります。
次の質問も見て下さい。 KDE の内部と外部どちらを開発したほうがいいでしょうか？どうすれば、KDE への CVS アクセスを得ることができますか？私の作ったアプリケーションは unstable ですが、KDE に含めたいのですが…まず、kdenonbeta(== kde-alpha) に入れることができます。そこで開発して下さい。そして準備ができたらそれを適当な KDE パッケージに含めるようにたのんで下さい。 KDE にアプリケーションを含める際、CVS の履歴を失いたくないのですが、どうしたらいいでしょうか？あなたの CVS レポジトリの tgz 圧縮ファイルを提供して下さい。 kde bindings の中には何が入っているのですか？Qt/KDE のクラスを Java から使うためのバインディングや、DCOP を C、Java、Perl、Python から使うためのバインディング、非 KDE アプリを KPart として扱うための XPart などが含まれています。また、KDE ではメンテナンスされていないバインディングは他にもあります。the binding page of develop.kde.org をチェックしてください。 KDE のノンベータ版に機能の凍結は適応されますか？stable な KDE と unstable な KDE をひとつのコンピュータに共存させることは可能ですか？できます。Building 2 Versions document をチェックして下さい。 使用している Qt/KDE のバージョンはどうやって知るのですか？コントロールセンターを起動してください。 そのスプラッシュ画面にKDEのバージョン情報が表示されます。 また、kde-config と全てのKDEプログラムは引数として --version を受け付けます。 Qt-copy か trolltech の Qt か？HEAD ブランチのクリーンビルドをするならどっちが良いですか？どちらでもかまいません。それらはバイナリで互換性が保たれています。しかし、後者は最新の Qt へのバグフィックスを少し含むかもしれません。 CVS のモジュールからひとつだけディレクトリを checkout するにはどうしたら良いですか？'cvs co -l modulename' でトップレベルのディレクトリをチェックアウトし、'cvs co modulename/admin' で admin/ ディレクトリをチェックアウトし、最後にあなたが欲しいディレクトリを 'cvs co modulename/subdir' でチェックアウトしてください。 （訳注：現在 admin は kde-common モジュール内にあります） たとえば、reaktivate だけを kdenonbeta から入手したい場合は コンパイルも普段と同じです。 この解決策は「kde-i18n から１つの言語だけをとってきたい場合どうするか」と言う質問の答にもなります。 もし、チェックアウトしたいディレクトリの名前がわからない場合は、webcvs.kde.org をブラウズして見付けてください。 KDE のアプリケーションのひとつをスタンダローンの tar ball にするにはどうしたら良いですか？kdesdk/scripts/cvs2pack と kdesdk/scripts/dist が KDE のソースツリーからアプリケーションを抽出し、スタンドアローンなアプリケーションとしてパッケージ化するスクリプトです。 どうやったら、自分が出したバグレポートをクローズすることができますか？技術的な質問どうやって新しいアプリケーションを作り始めるのですか？最も簡単な方法は、Makefile.am を生成するために kdesdk/kapptemplate か kdevelop を使うことです。その他の方法としては、他の KDE アプリケーションから Makefile.am をコピーし、それを今ある KDE ソースコードのトップディレクトリに組み込むことです。もっと他の方法としてはスクラッチから作るという古い方法です。しかし、この方法はautoconf/automake フレームワークの恩恵にあずかることは出来ません。 dcop、kpart、kiokdesktop、kdeinit とはなんですか？http://developer.kde.orgをチェックしてみて下さい(特にアーキテクチャに関するドキュメント)。また KDE book をチェックしてみるのも良いかもしれません。 dcop や kpart を使う必要はあるのですか？無理に使う必要はありません。しかし使ったほうがはるかに良いです。KPart は強力なコードの再利用を可能にします。DCOP はアプリケーションのスクリプトによる制御を可能にし、とても強力です。 どうやって Makefile.am を書けばいいのですか？Makefile.amをどのように書けばよいのかについての文書は他にあります。makefile_am_howtoを参照して下さい。 Makefile の生成はどうなっているのですか？am_editと呼ばれるプログラムによって書かれた別のレイヤーと共にautoconf,automakeを用いています。しかし、どのように使うかを理解しようとする必要はありません。 非常に複雑であるし、core-developerが既に理解しているので、実際しなくてよいというのがまたKDEの強みでもあります。 基本的に、automakeはMakefile.amからMakefile.inを生成します。そしてam_editがMakefile.inの中のKDE独自のタグを置き換え、そしてconfigureがMakefile.inから作り出されます。 どうして KDE は .lo ファイルや .la ファイルを生成するのですか？どうしてこれらのファイルは .lib ディレクトリに隠されているのですか？なぜならKDEは"libtool"と呼ばれるGNU toolを用いているからです。だから、この質問は次のような二つの質問に分かれます。"何故libtoolを使うのですか？"という質問と、"なぜlibtoolは.loと.laというファイルを作るのですか？"という質問です。 KDEは移植性という理由からlibtoolを用いています。libtoolは様々なプラットフォームにおけるコンパイラ、そして特にリンカの違いを配慮するため、sharedライブラリを書いている時でさえそのようなことに悩む必要が無いのです。 .loや.laといったファイルはオブジェクトファイルやライブラリの情報を加えるために用いられます(plain textなので読んでみましょう) 。実際、これらのファイルにはライブラリの依存情報が書かれています。もしなかったとしたら、link lineに-lkparts -lkio -lkdeui -lkdecore -lqt -lXext -lX11...を必ず与えなければなりません。これらのファイルが.libsディレクトリに「隠されて」いるのに違和感を覚えるかもしれませんが、多大な利益を得ているのです。つまり完全な移植性と開発者の負担を減らすことです。 make のターゲットにはどんなものがありますか？all:デフォルトターゲット('make' とタイプした時に実行されるターゲット) clean:全ての生成されたファイルを消去します。 distclean:clean で消去されるファイルに加えて Makefile.cvs から生成されるファイルも消去します。KDE ではあまり役に立ちません("dist" のコンセプトを知るには dist の項を、本当のクリーンを行なうよりよい方法を知るには cvs-clean の項をみてください)。 dist:CVS ソースから tar ball を作ることを想定しています。しかし、KDE ではあまりサポートされていません。kdesdk/scripts/cvs2pack を使った方が良いでしょう。 cvs-clean:(CVS ユーザーのみ対処)CVS に入っていないファイルを全て消去します(もし、変更をコミットしていなければこれはうまく動きません）。 force-reedit:Makefile.am を使って automake や am_edit をもう一度実行します。 install:全てをインストールします。 install-strip:全てをインストールし、バイナリファイルを strip します(デバッグシンボルを取り除きます）。 install-exec:バイナリファイルやライブラリファイルのみをインストールします。 install-data:データファイルのみをインストールします。 check:テストプログラムをコンパイルします(それらは check_PROGRAMS で定義されています)。"make check"の途中で実際にそれらのプログラムを実行することも出来ます。 kdelibs/arts/tests/Makefile.am を参照して下さい。 CVS から checkout したのですが、configure スクリプトや Makefile ファイルが見つかりませんが…"make -f Makefile.cvs" を実行してください。 どうすれば、特定のディレクトリを一時的にビルドから除くことが出来ますか？プログラムをハックする際、特定のディレクトリをビルドの対象から除くと便利かもしれません。もしそうしなければコンパイルされてしまうのですが、それは必要のないことです。 トップディレクトリで行なう方法とサブディレクトリで行なう方法の二があります。 トップディレクトリで行なう方法は、単純にコンパイルしたくないディレクトリを消去すれば良いです(または、checkout しない)。 もし何らかの理由でそのようなことをしたくないのであれば、configure を実行する前に DO_NOT_COMPILE=someapps としてみて下さい。そうすれば、configure は someapps をスキップします。もしほんの少しのディレクトリしかコンパイルしたくなければ、DO_NOT_COMPILE にほとんど全てのディレクトリを加える代わりに、コンパイルしたいトップレベルのサブディレクトリをトップディレクトリの inst-apps というファイルにリストアップしてください。 サブディレクトリを含むディレクトリをコンパイルしないで済ますには、Makefile や Makefile.am を修正しなくてはいけません。Makefile.am を修正することは推奨されていません。なぜなら、そのファイルは KDE CVS にも入っており、まちがってコミットしてしまう恐れがあるからです。よってここでは、Makefile を修正する方法を示します。 SUBDIRS = share core ui . proxy taskmanager taskbar applets extensions data コンパイルしたくないディレクトリをこの行から消して下さい。そうすれば、新しく"make "した際、そのディレクトリのコンパイルはスキップされます。 たまに、SUBDIRS が他の変数から構成されるので難しくみえることがあるも知れません。 SUBDURS = $(COMPILE_FISRT) $(TOPSUBDIRS) $(COMPILE_LAST) この場合、COMPILE_FIRST、TOPSUBDIRS、COMPILE_LAST を探して下さい。それらの中にあなたがコンパイルしたくないディレクトリが入っているはずです。それを見付けたこと呂で削除して Makefile を保存して下さい。 もし、変更を取り消したい場合は Makefile を再生成するが古い Makefile のバックアップをもどして下さい(ちゃんとバックアップしてますか?)。 Makefile を再生成するには "make force-reedit" を実行して下さい。 どのようなコンパイルオプションがありますか？--enable-debug --disable-debug --enable-final この方法はパッケージングするには有効ですが、もちろん開発者がすべきではありません。なぜなら、１つファイルを修正するだけで全部を際コンパイルしなくてはいけないからです。 どのようなコンパイルオプションが推奨されていますか？もしあなたが開発者なら、Qt や KDE を --enable-debug オプションを付けてコンパイルすべきです。そうすれば、Qt や KDE の関数呼び出しの内部まで自分のプログラムをデバッグできます。 あなたが純粋なユーザーでも、--enable-debug オプションを付けても問題ありません。KDE はより多くのディスクスペースを占めることになりますが、それでデスクトップが遅くなることはありません。このオプションを付ける利点としては、アプリケーションがクラッシュした際にスタックトレースを得ることが出来ることです。もし、クラッシュの挙動に再現性があるならば、bugs.kde.org でそのクラッシュが報告されていないことを確認した後に、提出してください。それにより、KDE を改善していくことが出来ます。 Qt に関しては、qt-copy/README.qt-copy でコンパイルオプションの説明がされています。 コンパイルを速く済ますための Tips はありますか？上にある"--enable-final"を読んで下さい。"make final"は--enable-final なしでも現在のディレクトリに関して all-in-one-file トリックを使います。"make no-final"は--enable-final を付けていても現在のディレクトリを普通の方法でコンパイルします。 moc ファイルをインクルードして下さい！QObject の派生クラスを定義しているヘッダファイルは .moc ファイルを生成するために moc を通さなくてはいけません。.moc ファイルもコンパイルしなくてはいけませんが、方法は２つあります。ひとつは別々にコンパイルする方法、もうひとつはクラスを実装しているファイルにインクルードする方法です。後者の方がコンパイルスピードの点で効率的です。kdesdk/scripts/includemocs ではこの方法が自動的にこれを行ないます。 また、現在では gcc-2.95 が gcc の最新版より速くコンパイルことが出来ることも知っておいて下さい。 Makefile の中で STRIP 変数がセットされていますが、どこでも使われていないようですが…strip はコンパイル時に行なわれます。これを使うには "make install" の代わりに "make install-strip" を使ってしてください。 ソースコードを書く際、どんなインデントを使えばいいんですか？もしあなたが、今あるアプリケーションで仕事をするなら、そのアプリの作者のインデントを尊重してください。そうでなければ、あなたの好きなインデントを使って良いです。 i18n と I18N_NOOP の違いは何ですか？QString translatedStuff=i18n("foobar"); そのため、普通は i18n を使いたいとおもいます。しかし、絶対に翻訳をさせずに後で翻訳したい場合や、KInstance が存在する前に翻訳したいものを持っておきたい場合は、I18N_NOOP を使って下さい。 What is this bug thing with QSpinNumber??QSpinNumber? にはバグがあります。KSpinNumber? を使って下さい。それらは同じ特徴を持っています。 "virtual table error"というエラーが出ます。このエラーは、.moc ファイルがソースファイルと同期していない場合や、リンクされていない場合に多く起こります。正しく moc を使っているかどうか確かめて下さい。"which moc" で分ります。また、moc ファイルを再生成して下さい(make force-reedit;make clean;make)。 dcop を使おうとして k_dcop を myClassHeader?.h に加えましたが、何もおこりません。myClassHeader?.kidl を Makefile.am に加えた後に、再び make を実行して下さい。 いくつかの Makefile.am の中には .stub ファイルがありますが、これは何のためですか？スタブはあまり使われません。スタブは dcop に登録されたアプリケーションをメソッドが dcop スロットであるオブジェクトとして見せることを可能にします。普通、アプリケーションはすべての dcop スロットを含む appnameIface.h を持っています。Makefile.am の中に appnameIface.stub を加えて、オブジェクト appnameIface を使って下さい。具体例として konqueror スタブを使っている kdebase/kdehelpcenter を参照して下さい。 Q_OBJECT を myClassHeader?.h に加えましたが、mocファイルが生成されません。正しく Makefile を生成できるように Makefile.am をパーズするために am_edit を実行して下さい。もし加えた Q_OBJECT がそのディレクトリで最初なら、Makefile.cvs を実行するか、または kdesdk/scripts の中にある create_makefile を実行して下さい。他の方法として、単に make force-reedit しても良いです。 簡単に済ませるために、自分のクラス全体をひとつの cpp ファイルにコーディングしました。どうすれば moc ファイルと kidl ファイルを生成することが出来ますか？もし Q_OBJECT を使っているクラスがあるなら、そうするのはやめて下さい。KDE のフレームワーク（am_edit)はその方法をあまりうまくサポートしません。ただ、METASOURCE=file.cpp とすれば moc ファイルにたいしてはうまくいくかも知れません。 kpart（つまりプラグイン）を作りましたが、まだ完成していないのでインストールしたくありません。KTrader や KLibLoader? を利用してその kpart にリクエストした際に KDE がそれを見つけられるようにするにはどうしたらよいですか？KDE は KDE ライブラリを $KDEDIR/lib と$KDEDIRS の各要素内の lib ディレクトリの中で探します。よって、あなたがライブラリを開発していてそれをインストールしたくないのならばこのトリックが使えます。
これで KTrader や KLibLoader? を使ったときに KDE はあなたのライブラリを見付けるはずです。 root になれない場合に、どうすれば追加の KDE ソフトをインストールできますか？アプリケーションを個人的にインストールしたい場合、普段とは違う prefix でそのアプリを configure してください。たとえば、configure --prefix=$HOME/kdeprefix などです。その後に KDE にこの prefix を教えましょう。KDEDIRS に $HOME/kdeprefix:$KDEDIRS をセットします。KDE に新しい prefix を教えるもう１つの方法は、/etc/kderc を編集して以下の記述を加えます。 私の作った kpart ライブラリが KTrader を通してリクエストをするとリストに表示されません。新しいサービス（アプリケーションやプラグインなど）がインストールされた場合、mime データベースを再構成しなくてはいけません。理論的にはそれは勝手に行われます（kded がインストールディレクトリを監視しています）が、もし不確かなら kbuildsycoca を実行してください。 trader に関する問題をデバックする一番良い方法は ktradertest を使うことです。kdelibs/kio/tests に移動して ./ktradertest を実行してください。 kdelibs を変更してインストールしましたが、新しい KDE アプリケーションがそれを使っているように見えません。解決策は簡単です。新しいアプリをコマンドラインから実行してみてください。そうすれば新しいライブラリを使うでしょう。 KParts とスタンドアローンアプリケーションの両方を作成していますが、どうすればコードの重複を避けることが出来ますか？アプリケーションをしばしば Part とリンクしたくなります。なぜなら、それらは多くの共通の機能を持っているからです。しかし、それは以下の理由からやってはいけません。
上で言っていることを理解できなくても心配しないで下さい。要はアプリケーションを KParts や、 dlopen されるべきモジュールにリンクしてはいけないということです。 解決策
外部のアプリケーションを起動する一番良い方法は何ですか？kde2 porting instructions によい解決策があります。kdelibs/KDE2PORTING.html をチェックしてみてください。またここも参照してください。 どうやって KDE へのパッチを作成し提出すれば良いですか？バグを見つけて修正コードを書きたいと思ったり、新しい機能をコーディングしたいと思ったら、パッチを送ってください。開発者に喜ばれるでしょう。以下にあなたがすべきことを記して起きます。
これで OK です。あなたのコードは KDE に含まれました。これであなたもれっきとした KDE プロジェクトの一員です。ありがとうございました。 How do I make my application Xinerama and multi-head safe?KDE に関して UIC プラグインが見つからないというエラーが出ましたが、それらはインストールされています。何が悪いのでしょうか？それはほとんど間違いなく KDE のコードには問題なく、インストールの仕方に問題があります。たくさんの問題がこの障害を起こしえますが、ほとんどの場合、Qt が複数バージョンインストールされていて、configure スクリプトが呼び出すものと、KDE が使っているものが違うことが原因です。 この問題を解決する手助けとなるもう１つの方法は、kdewidget を再コンパイルすることです。これは kdelibs/kdewidget ディレクトリにあります。ただ、複数の Qt を持った状態でこれを行うと、間違った Qt に対してコンパイルしてしまうかもしれないことは注意してください。 この問題は、さまざまなメーリングリストで何回も投稿されています。よって lists.kde.orgのアーカイブをみれば役に立つでしょう。 デバッグDr Konqi が出ないようにするにはどうしたら良いですか？KDE_DEBUG 環境変数を(1に)セットしてください。 core ファイルって何ですか？どうすれば core ファイルを得ることができますか？core ファイルとはアプリケーションがクラッシュしたときのメモリイメージです。これを使うことによって、どの変数がセットされていたり、どこでアプリがクラッシュしたかを知ることができます。 いくつかのディストリビューションでは core ファイルの生成を不可にしています。ふたたび、生成ができるようにするには "ulimit -c unlimited" を実行してください。 いったん core ファイルが手に入ったら、"gdb appname core" で調べることができます。これで gdb は与えられたアプリケーション用に core ファイル上でオープンできます。gdb のプロンプトが出たら、"bt" というコマンドが役に立ちます。これはクラッシュのバックトレースを生成することができます。 gdb の使い方についてもっと情報がほしいなら、このページ を見て下さい。 デバッグ用の出力を標準エラーに出す１番良い方法は何ですか？kdDebug() を使うべきです: #include <kdebug.h> 文法は cout とほとんど同じで、多くのネイティブな型を << の間に使えます。これはデバッグメッセージを出力しますが、リリース時に(--disable-debug で)自動的に無効にすることができます。もし、メッセージをリリース中も出力したいならば、それらは警告やエラーなので kdWarning() や kdError() を使って下さい。 コンポーネントやライブラリなどは kdDebug(1234) などのようにデバッグエリアナンバーを使うようにアドバイスされています。このためには、kdelibs/kdecore/kdebug.area にその数字が登録されていなければいけません。デバッグエリアのお陰で、特定のエリアナンバーのデバッグ出力を無効にすることができます。そのためには "kdebugdialog" という kdebase の一部であるプログラムを使います。"kdebugdialog --fullmode" によってまた、デバッグ出力のログをどこに取るか制御することもできます。普段、スタンドアローンなアプリケーションのためにエリアナンバーを登録することは、そのアプリケーションが複雑で出力をいくつかのエリアに分割したいと思うことが無ければ、必要ありません。 qDebug() を使ってはいけないということだけははっきり覚えておいて下さい。それはリリース時に無効になりません。また、assert() や kdFatal() を使うことも避けて下さい。それらは何かアプリケーションないでまずいことが起きた場合、アプリをクラッシュさせてしまいます。決してユーザーにとって良いものではないのです。エラーを発見する良い方法は kdWarning や kdError を使って下さい。そして、できる限りそのエラーから回復させて下さい。 私のアプリケーションをデバッグするのにどんなツールが使えますか？
このページ や kdesdk をチェックして下さい。便利なスクリプトが集まっています。 QString の文字列を gdb で出力するにはどうしたら良いですか？kdesdk をチェックアウトし ~/.gdbinit に以下の行を加えて下さい。 source /path/to/kde/sources/kdesdk/scripts/kde-devel-gdb そうすれば、gdb で printqstring myqstring とすることで内容を見ることができます。 たとえば、QString myqstring=QString::fromLatin1("contents") は次のマクロで調べることができます。 (gdb) printqstring myqstring 定義されている他のマクロを知るには kde-devel-gdb を見て下さい。 KPart を使っているアプリケーションをデバッグしているとき、デバッグシンボルがありません。どうするべきですか？main がロードされた直後にとめる必要があります。そうすれば後は普通にデバッグできます。 kpart がロードされた直度に止めるために、gdb のマクロを作ることだってできます。KWord を例にすると、わたしは以下のマクロの定義を使っています。 define startkword break main run break 'KoDocument?::KoDocument?(int, QWidget *, char const *, QObject *, char const *, bool)' cont どうやって ioslave をデバッグするのですか？kdebase/kioslave/DEBUG.howtoを参照して下さい。
Counter: 12479,
today: 1,
yesterday: 0
|
