ラベル KDE の投稿を表示しています。 すべての投稿を表示
ラベル KDE の投稿を表示しています。 すべての投稿を表示

2009/01/17

Ubuntu 8.10 に KDE 4.1 をインストール

Ubuntu 8.10 に KDE 4.1 をインストールしました。
KDEを使うのは久しぶりです。

Synaptic でそれらしきパッケージ群をインストールしたところ、KDE 4.1.4 がインストールされたようです。

いくつか悩んだ箇所があったので、備忘録として書いておきます。


(1) キーボードから "|"「パイプ」や"]"「終わり大括弧、終わり角括弧」が入力出来無い

検索してみたところKDEインストール後に同様の現象の報告があるみたいなので、多分KDEインストールしたことが原因なのかなと思います。

「KDEシステム設定」ー「個人」の「国と言語」ー「キーボード配列」の「Layout」で
以下のように設定しました。
  • 「Enable keyboard layout」をチェックする

  • 「Avaliable layouts:」に「Japan」を選択

  • 「Keyboard model:」に「japanese 106-key」を選択

以上で"|"「パイプ」と"]"「終わり大括弧、終わり角括弧」は入力出来るようになりました。
他にも入力出来ないキーがあるのかもしれませんが。


(2) ファイルマネージャーの Dolphin で動画のプレビューが表示されない

MplayerThumbs」をインストールするといいようです。

ただし、Ubuntu 8.10 (Intrepid)のMplayerThumbsは0.5系でKDE4には対応していません。
Jaunty のMplayerThumbsは1.1系でKDE4に対応しているようです。

MplayerThumbsのサイトからソースをダウンロードしてビルドしようとしたのですが、失敗しました。

深く調べるのが面倒でしたので、JauntyのMplayerThumbs 1.1バイナリのインストールを試みたところ、何の問題も発生せずにインストール出来てしまいました。
動画のプレビューも出来るようになりました。


とりあえず気になる所は無くなったので、しばらくKDEを使い続けてみようと思います。
使い初めだからかもしれませんが、GNOME環境よりストレスなく動いている気がします。

2007/08/01

Krusaderを使ってみる

Krusaderというファイルマネージャーがあります。
参考記事: Linuxファイルマネージャーの比較検討(2/2) [itmedia.co.jp]

Krusader-1.8.0のRPMパッケージを作成しインストールしました。
SPECファイルは先日作成したKCheckGMailのSPECファイルをちょこちょこ修正して作りました。

今回も簡単にSPECファイルを作成することにします。
本来であれば環境変数マクロを使用したいところです。
けっしてマネしないでください。



SPECファイルのファイルリスト部を記述するため、インストールされるファイルを調べます。
まずはダウンロードしてきたkrusader-1.8.0.tar.gzを展開し、./configure,makeしました。
$ tar xzvf krusader-1.80.0.tar.gz
$ cd krusader-1.80.0
$ ./configure --prefix=/usr
$ make

そして適当な場所にインストールします。
$ make DESTDIR=$PWD/work install

インストールされるファイルを調べます。
$ cd work/
$ find . -type f -o -type l &> ~/tmp/link

~/tmp/linkというファイルには次のようにインストールされるファイルが列挙されます。
./usr/share/apps/konqueror/servicemenus/isoservice.desktop
./usr/share/apps/krusader/midnight_commander.color

〜省略〜

./usr/share/man/man1/krusader.1

〜省略〜

./usr/lib/kde3/kio_iso.la
./usr/lib/kde3/kio_krarc.la
./usr/bin/krusader


全ての行頭に"./"という余計なのがついているため一括で削除し、それをSPECファイルのファイルリスト部に張り付けます。
%files
%defattr(-,root,root)
/usr/share/apps/konqueror/servicemenus/isoservice.desktop
/usr/share/apps/krusader/midnight_commander.color

〜省略〜

/usr/share/man/man1/krusader.1

〜省略〜

/usr/lib/kde3/kio_iso.la
/usr/lib/kde3/kio_krarc.la
/usr/bin/krusader

今回も環境変数マクロは使わず、インストールされるファイルを全て列挙しました。


このようにSPECファイルを作成するためだけに一度インストール作業まで行っています。
Krusaderくらいの規模のアプリケーションではまだ許容範囲かと思いますが、もっと巨大なアプリケーションではとてもこんなことやってられないです。
何かいい方法があるのでしょうか?
よく分かりません。


さて、SPECファイルが出来上がっためパッケージの作成に移りたいと思います。
$ rpm -ba krusader.spec

ところが、失敗します。

これは、SPECファイルのファイルリスト部に/usr/share/man/man1/krusader.1を記入したのですが、krusader.1ではなくkrusaddr.1.gzに圧縮されているためでした。

Vine Linuxのオンラインマニュアルに次のような記述がありました。
rpm-3.0.5以降では、man ファイルや info ファイルは自動的にgzipで圧縮されます。 %filesにmanやinfoのファイル名を書くときには拡張子.gzをつけるのを忘れないようにしましょう。


krusader.1をkrusader.1.gzに修正したところ、無事にkrusader-1.80.0-ta1.src.rpmとkrusader-1.80.0-ta1.i386.rpmを作成できました。


krusaderのスクリーンショットです。


機能は色々ありそうなのですが、よくわかっていません。

Konquerorみたいに画像ファイル一覧時にプレビューってされないのでしょうか?
画像ファイルを「右クリック」→「プレビュー」するとプレビューされるのですが。

(2007/8/1追記)
選択したファイルのプレビューは出来ました。
Alt + 下矢印キーを押下すると3画面分割になり、そのひとつを"Preview Panel"にすると、選択している画像をプレビューしました。

2007/07/30

KCheckGMailをRPMパッケージ化

KontactのRSSリーダ(Akregator)のようにKDEのシステムトレイに入ってくれるタイプのGMailチェッカーを探したところ、KCheckGmail 0.5.5というのがありました。

KCheckGmail 0.5.7というのもあったのですが、こちらはmake出来ませんでした。
$ make
WARNING: use unsermake instead of make or
use a wrapper script, e.g. makeobj!!!
unsermake all
make: unsermake: コマンドが見つかりませんでした
make: *** [all] エラー 127

unsermakeとやらが無いというエラーのようです。
unsermakeを使わないようなオプションがあればよいのですが、ちょっと分かりませんでした。

また、usermakeを入れるのは大変らしいという情報と、調べた限りではunsermakeの入手先が見つからなかったため、0.5.7は早々にあきらめました。
KDE関連のサイトを重点的に調べてみたのですが、力及ばず見つけることが出来ませんでした。


RPMファイルの作成については、Vine Linuxのドキュメントを参考に自分でSPECファイルを作成することにしました。
随分前にもSPECファイルを作ったことはありましたが、今回以上にテキトーでした。


一番悩んだのがファイルリスト部です。
結局以下のようにファイル名をそのまま列挙しました。
%files
%defattr(-,root,root)
/usr/share/apps/kcheckgmail/eventsrc
/usr/share/apps/kcheckgmail/icons/crystalsvg/32x32/
apps/kcheckgmail.png
/usr/share/apps/kcheckgmail/icons/crystalsvg/128x128/
apps/kcheckgmail.png

〜以下省略〜


実際に配布されているSRPMファイルのSPECを見ると環境変数マクロを多用していますが、今回私は使いませんでした。
よく分からなかったもので。

標準で定義されているマクロは /usr/lib/rpm/macrosに書かれているとのことですが、見てみると結構色々あります。


出来上がったKCheckGMailのスクリーンショットです。
日本語が文字化けしていますが、まあそれほど気にならないです。

メールが届くと音声で案内されます。

2007/07/17

KDEプログラミング その5

KDEプログラミング その4」の続きです。

あいかわらずよくわからずにやっています。
どんな方法が正しいのか分かりません。


それではチュートリアルを再開します。
今回は「P3」を行いました。

とりあえずチュートリアルにあるmain.cpp, p3.h, p3.cppを作成します。
$ ls
main.cpp p3.cpp p3.h



KDEプログラミング その2」と同様の手順でmakeを行ってみます。
$ qmake -project
$ echo INCLUDEPATH += /usr/include/kde >> p3.pro
$ echo LIBS += -lkdeui -L/usr/lib/kde3 >> p3.pro
$ qmake
$ make
g++ -c -pipe -Wall -W -I/usr/include/freetype2 -O2
-m32 -march=i386 -mcpu=i686 -DQT_NO_DEBUG
-I/usr/lib/qt3/mkspecs/default -I. -I. -I/usr/include/kde
-I/usr/lib/qt3/include -o main.o main.cpp

 〜略〜

g++ -o p3 main.o p3.o moc_p3.o -L/usr/lib/qt3/lib
-L/usr/X11R6/lib -lkdeui -L/usr/lib/kde3 -lqt-mt
-lXext -lX11 -lm
p3.o(.text+0xad4): In function `MainWindow::fileOpen()':
: undefined reference to
`KFileDialog::getOpenURL(QString const&,
QString const&, QWidget*, QString const&)'
p3.o(.text+0xd64): In function `MainWindow::fileSave()':
: undefined reference to
`KFileDialog::getSaveURL(QString const&,
QString const&, QWidget*, QString const&)'
collect2: ld はステータス 1 で終了しました
make: *** [p3] エラー 1


エラーになってしまいました・・・。
今まで一度もすんなりといったことがありません。


エラーの内容を見てみると、リンク中にgetOpenURL()とgetSaveURL()が見つからないと言っている気がします。

チュートリアル
では次のような記述があります。
Note that you're encouraged to allow the user to open any URL not just local files. For this, we have used a getOpenURL dialog, which lets the user select any url. Check below for an example on how to use the KIO library.


またKFileDialog::getOpenURLの関数リファレンスはこちらにあります。

KIO Libraryに含まれるのは確かのようなので、多分リンク時に"-lkio"とか入れるのでは無いかと想像しました。
探してみると/usr/lib/libkio.soというのがありましたので、当たりかなと。


そこで最初からmakeの手順をやり直してみます。
$ make clean
rm -f moc_p3.o
rm -f moc_p3.cpp
rm -f main.o p3.o
rm -f *~ core *.core
$ ls
Makefile main.cpp p3.cpp p3.h p3.pro
$ rm Makefile p3.pro
$ ls
main.cpp p3.cpp p3.h


プロジェクトファイルから作りなおします。
$ qmake -project
$ echo INCLUDEPATH += /usr/include/kde >> p3.pro


リンクするライブラリに"-lkio"を追加します。
"-lkui"ももちろん入れておきます。
$ echo LIBS += -lkdeui -lkio -L/usr/lib/kde3 >> p3.pro


一応p3.proの確認です。
$ tail -n3 p3.pro
SOURCES += main.cpp p3.cpp
INCLUDEPATH += /usr/include/kde
LIBS += -lkdeui -lkio -L/usr/lib/kde3


一気にmakeまで行います。
$ qmake
$ make
g++ -c -pipe -Wall -W -I/usr/include/freetype2 -O2
-m32 -march=i386 -mcpu=i686 -DQT_NO_DEBUG
-I/usr/lib/qt3/mkspecs/default -I. -I.
-I/usr/include/kde -I/usr/lib/qt3/include
-o main.o main.cpp
main.cpp: function 内の `int main(int, char**)':
main.cpp:6: 警告: `__comp_ctor' is deprecated
(declared at /usr/include/kde/kapplication.h:205)
g++ -c -pipe -Wall -W -I/usr/include/freetype2 -O2
-m32 -march=i386 -mcpu=i686 -DQT_NO_DEBUG
-I/usr/lib/qt3/mkspecs/default -I. -I.
-I/usr/include/kde -I/usr/lib/qt3/include
-o p3.o p3.cpp
/usr/lib/qt3/bin/moc p3.h -o moc_p3.cpp
g++ -c -pipe -Wall -W -I/usr/include/freetype2 -O2
-m32 -march=i386 -mcpu=i686 -DQT_NO_DEBUG
-I/usr/lib/qt3/mkspecs/default -I. -I.
-I/usr/include/kde -I/usr/lib/qt3/include
-o moc_p3.o moc_p3.cpp
g++ -o p3 main.o p3.o moc_p3.o -L/usr/lib/qt3/lib
-L/usr/X11R6/lib -lkdeui -lkio -L/usr/lib/kde3
-lqt-mt -lXext -lX11 -lm
$ ls
Makefile main.cpp main.o moc_p3.cpp moc_p3.o p3*
p3.cpp p3.h p3.o p3.pro


make成功し、実行ファイルp3が作成されました。
早速実行してみます。
$ ./p3

動きました。


ソースの中身をまだ詳細を理解していないため、次はp3のソースをもっと調べることにします。
KIO Libraryを含めて。

英語だけど。

2007/07/16

日本語文字化けをどうにかする その4

日本語文字化けをどうにかする その3」の続きです。

前回まででNFSクライアントであるVine Linux 4.1では文字化けを解消できましたが、Windows PCからのアクセスを確認していません。

SambaサーバのPlamo Linux(ホスト名 JULIE)がマウントしているReiserFS領域をWindowsで参照する際に文字化けするか確認し、問題があれば対応したいと思います。


日本語文字化けをどうにかする その1」で行ったのはNTFSファイルシステムをLinuxでマウントする際のオプションを変更しただけでファイルやフォルダをいじった訳ではないので問題ありません。

気になるのは、「日本語文字化けをどうにかする その2」で行ったファイル名やフォルダ名をShift-JISからEUC-JPに変更してしまっている点です。

これをSambaでWindowsから参照できるようにした場合に、正常に読むことができるのでしょうか?


確認のため、「日本語文字化けをどうにかする その2」で行った手順を再度行います。

(1) SALIE(NFSクライアント)からNFSマウントしたReiserFSファイルシステム上のファイル名・フォルダ名が文字化けしているのを確認。
Konquerorで確認します。

(2) convmvコマンドを使用してファイル名・フォルダ名をShift-JISからEUC-JPに変換。
$ convmv -r -f sjis -t euc-jp * --notest
mv "xxx/PDF/gZ" "xxx/PDF/トラ技"
mv "xxx/Docs/Zaurus/J�txt" "xxx/Docs/Zaurus/開発環境.txt"
mv "xxx/Pictures/WallPaper/t@R" "xxx/Pictures/WallPaper/ファルコム"
mv "xxx/Movie/O/コピー ~ multimodal_arm.tar"
mv "ubN}[N/C莅lzh" "ubN}[N/お気に入り.lzh"
mv "./ubN}[N" "./ブックマーク"
Ready!


(3) SALIE(NFSクライアント)で文字化けしていないことを確認。
Konquerorで確認します。
化けていたのは「ブックマーク」というフォルダでした。

(4) Windows(Sambaクライアント)で文字化けしているかを確認。
やっぱり化けてました。


文字化けが発生していたため、JULIE(Sambaサーバ)の設定を変更することにより解決できないか検討します。

(5) Sambaの設定を変更。
smb.confの[global]に以下の記述を追加。
coding system = euc
client code page = 932


各設定値の説明はマニュアルにありました
マニュアルのcoding systemの項からの引用です。
coding system (G)

このパラメータは、 Samba が受けとった Shift-JIS の日本語文字を、 クライアントが使っているclient code pageから UNIX ファイルシステムのファイル名にどのように対応づけるかを指定する。 このパラメータは、client code page が932(日本語 Shift-JIS)の時のみ有効である。オプションは以下のとおり:



次にclient code pageの項からの引用です。
client code page (G)

このパラメータは、Samba にアクセスするクライアントが利用している DOS コードページを指定する。 Windows や DOS クライアントで利用されているコードページを確認するには、 DOS コマンドプロンプトを開いて、chcpコマンドを入力する。 これによりコードページが表示される。 USA 版の MS-DOS、Windows 95、Windows NT のデフォルトは 437 である。 西ヨーロッパ版のこれら OS のデフォルト値は 850 である。


(6) Sambaを再起動。
JULIE(Sambaサーバ)のsmbdとnmbdの両方を再起動しました。
両方再起動したのは念のためです。

(7) Windows(Sambaクライアント)で文字化けしているかを確認。

文字化けは解消されています。

(8) Windows(Sambaクライアント)が作成した日本語ファイル名・フォルダ名の確認。
Windows(Sambaクライアント)で作った日本語名のフォルダをJULIE(Sambaサーバ)へコピー。

(9) SALIE(NFSクライアント)でWindowsで作成した日本語名のフォルダを確認。
Konquerorで確認します。

OK!

文字化け対策はとりあえず一通り出来たかなと思います。
何か忘れていることはないかな?

日本語文字化けをどうにかする その3

日本語文字化けをどうにかする その2」の続きです。
ReiserFSファイルシステムでの文字化けについてです。

なお、多分重要な点として「Vine Linux 4.1はEUC-JPがデフォルトになっているらしい」ということがあります。
$ echo $LANG ja_JP.eucJP


NFSサーバのPlamo Linux(ホスト名 JULIE)がマウントしているReiserFS領域をVine Linux(ホスト名 SALIE)でNFSマウントした際の文字化けをなんとかしたいと思います。

私が使用しているのはReiserFSですが、ext2やext3でも同じではないでしょうか。
多分。
JFSやXFSはどうかな?


SALIE(NFSクライアント)のKonquerorでは次のように文字化けしていました。
ひどいありさまです。

行った対策は次の通りです。
・保存されているファイル名・フォルダ名の文字コードがShift-JISであるので、EUC-JPに変更する。
・ファイル名・フォルダ名の変更にはconvmvというツールを使用する。

convmvはSALIE(NFSクライアント)にインストールしました。
Vine Linuxにはconvmvが見つからなかったため、Fedora-JPのサイトからconvmv-1.10-2.fc6.src.rpmをいただいて、それをrpm --rebuildしました。

convmvはNFSサーバとクライアントのどちらにインストールして大丈夫ですが、書き込み権限は必要かと思います。


変換する際のコマンドは次の通りです。
$ convmv -r -f sjis -t euc-jp * --notest
mv "ル@ル@ル~@/ル~@.mdi" "ル~@/資産設計(2) 戦術編 10 万円ではじめる方法.mdi"
mv "ル~@/ル~@.pdf" "ル~@/資産設計(2) 戦術編 10 万円ではじめる方法.pdf"

~以下略~



この結果、SALIE(NFSクライアント)のKonquerorで正常に表示できるようになりました。



日本語文字化けをどうにかする その4」に続く。

日本語文字化けをどうにかする その2

日本語文字化けをどうにかする その1」の続きです。
まずはNTFSの方です。

なお、多分重要な点として「Vine Linux 4.1はEUC-JPがデフォルトになっているらしい」ということがあります。
$ echo $LANG
ja_JP.eucJP


NFSサーバのPlamo Linux(ホスト名 JULIE)がマウントしているNTFS領域をVine Linux(ホスト名 SALIE)でNFSマウントした際の文字化けをなんとかしたいと思います。

SALIE(NFSクライアント)のKonquerorでは次のように文字化けしていました。

行った対策は次の通りです。
・JULIE(NFSサーバ)でNTFSファイルシステムをマウントする際に文字コードを考慮する


文字化けしている際のJULIE(NFSサーバ)側のfstabの記述は次のようになっていました。

・変更前の/etc/fstabの記述

/dev/hda1  /mnt/share3  ntfs  defaults,umask=000  0  0


文字化け対策として、次のように記述しました。
オプションのroは、書き込み禁止を明示的に指定したくてついでに書いておきました。
・変更後の/etc/fstabの記述
/dev/hda1  /mnt/share3  ntfs  umask=000,nls=euc-jp,ro  0  0

mountのマニュアルのntfsの項には次のように書いてあります。
iocharset=name
ファイル名を返すときに用いる文字セット。 VFAT とは異なり、NTFS は変換できない文字を含む名前を抑制する。このオプションは推奨されない。

nls=name
以前は iocharset という名前であったオプションの新しい名前。

mountのマニュアルのvfatのオプションはfatと同様のものが多く、fatの項には次のように書いてありました。
iocharset=value
8ビットの文字を 16 ビットの Unicode 文字に変換する (あるいはその逆)ときに用いる文字セット (character set)。デフォルトはiso8859-1である。長いファイル名は、ディスクには Unicode フォーマットで保存されている。

JULIE(NFSサーバ)のfstabを変更後にSALIEでマウントすると、文字化けはとりあえず解消されたようです。
文字化けしていたのは「ファルコム」というディレクトリでした。


日本語文字化けをどうにかする その3」に続く

日本語文字化けをどうにかする その1

最近はノートPCにインストールしたVine Linux 4.1でKDEを使っていることが多いです。

その際はWindowsXPマシンも同時に立ち上げ、WindowsXPのVMWareにインストールしてあるPlamo LinuxもWindowsXP起動と同時に立ち上げ、ファイルサーバなどとして使用することもあります。
(うちのネットワーク環境についてはこちら)

起動しているVineとPlamoのホスト名は次のようになっています。
Plamo Linux: JULIE
Vine Linux: SALIE


JULIEではファイル共有用のハードディスクを2台マウントして、NFSやSambaでローカルネットワーク上に開放しています。

ファイルシステムは1台はNTFS, もう1台はReiserFSです。

この2台のハードディスクに入っている日本語の名前がついたファイルやフォルダがSALIEのKDE Konquerorで見ると文字化けしてしまいます。
(ちなみにGNOMEのNautilusでは、Konquerorでは文字化けしているのに文字化けしないものもありました。)

この文字化けを、今さらながらなんとかしたいと思います。


結論から言うと、問題の対策は次の通りに行いました。

・NTFSファイルシステムの文字化け
 → マウント時にオプション"nls=euc-jp"を指定する
 (「日本語文字化けをどうにかする その2」で検証)

・ReiserFSファイルシステムの文字化け
 → ファイル名やフォルダ名をShift-JISからEUCに変更する
 (「日本語文字化けをどうにかする その3」、「日本語文字化けをどうにかする その4」で検証)



なお、数年前はPCを使用する際はLinuxを使用することが多かったのに、その際はほとんど問題になりませんでした。

その理由はこんな感じでしょうか。
・Linux上で自分が作ったファイルの名前に日本語でつけることは絶対にない。

・Windowsを使っている際も自分なりのファイル命名規則があった。
 それは、日本語ファイル名は使わないということ。
 しかし、しばらくLinuxを使用していない間に日本語ファイル名を使ってしまっていた。

・iTunesで作成した音楽ファイルに日本語名がついていることが多い。
 Linuxを常用している頃はcdparanoia + LAMEでMP3ファイルを作成していた。


NTFSとReiserFSでは行った対策が異なりました。
分けて記述しておきます。


日本語文字化けをどうにかする その2」に続く。

2007/07/14

KMail + IMAP + Googleデスクトップ

現在使用しているVine Linux 4.1では、最近は主にKDEを使用しています。


Kontact 1.2.5(KMail 1.9.7)でIMAPのメールを主に読んでいますが、プロバイダからPOP3でサーバにメールを残す設定でメールを取り込むこともあります。

IMAPのメールはKMailの「cachedimap」という設定にしており、IMAPサーバからローカルにメールをコピーしています。



また、先日リリースされたGoogleデスクトップのLinux版もインストールしてあります。


Googleデスクトップで次の現象が発生していました。
KMailの設定が上手くできている自信はないので、問題がどこにあるのか分かっていません。

・KMailでPOP3で取り込んだメール
 →インデックスを作成してくれる

・KMailのcachedimapでローカルにコピーしているメール
 →インデックスを作成してくれない


KMailのcachedimapのメールは、ホームディレクトリの次の場所に保存されているようです。
  HOME/.kde/share/apps/kmail/dimap/.xxxxxxxxxx.directory (xは数字)


Googleデスクトップの設定には「次の場所を検索」という設定があり検索場所を指定できますが、上記の場所を指定してもインデックスを作成してくれませんでした。


そこで、`.' で始まる名前のディレクトリ(.kde)から出してやればインデックスを作成してくれるのではないかと考え、次の操作を行いました。

(1) ホームディレクトリにKMailというディレクトリを作成
$ mkdir ~/KMail


(2) KMailディレクトリの下にcachedimap保存ディレクトリをfoldersという名前に変えて移動
$ mv ~/.kde/share/apps/kmail/dimap/.xxxxxxxxxx.directory ~/KMail/folders


(3) ~/Kmail/foldersのシンボリックリンクを~/.kde/share/apps/kmail/dimap/.xxxxxxxxxx.directoryとする
$ ln -s ~/KMail/folders ~/.kde/share/apps/kmail/dimap/.xxxxxxxxxx.directory


これで、Googleデスクトップがインデックスを作成してくれるようになりました


スマートでないのは分かっていますが、いい情報がみつかるまでこれで我慢します。

POP3で取り込んだメールも.kdeの下にありますので、単純に`.' で始まる名前のディレクトリ以下にあると全部ダメという訳ではないと思います。


ヘルプセンターを良く読めば分かるのでしょうか?

2007/07/13

Kontact(KMail)がutf-8になる

最近KDEを常用するようになり、Kontactも使用するようになりました。
Kontact 1.2.5です。



フィード(Akregator)はとてもいい感じです。
RSSは便利だなぁと、今さらながら思います。

登録しているサイトが更新されると、ちゃんとKDEパネルに表示されます。

拡大。
時計のとなりの"1"と出ているのがそうです。
新着一件ということです。



カレンダーはiCalフォーマットを使用してGoogleカレンダーを表示させています。
Googleカレンダーの更新は出来ませんので、表示させているだけですが。

Googleカレンダー側が他のアプリケーションでGoogleカレンダーを表示させた場合に読み取り専用にしかならないようです。
  Googleヘルプセンター


メールの送受信はKontactからKMail 1.9.7を使用しています。
IMAPとPOP3のメールを取り込んでいます。

受信は特に問題は起きていないのですが、送信する際にメールがutf-8になってしまうという現象が発生しました。

ネットで検索してみたところ、KMailの設定で文字コードをiso-2022-jpを先頭に持ってくるとiso-2022-jpで送信できるようになるという情報がありましたので、そのようにしてみました。


が、やはりutf-8になってしまいます。


色々試してみたところ、うちでは現状次のような状況になってしまうようです。
以下の実験はすべて、「件名」を「テスト」、本文を「テストです」にしたメールを送信してみました。

・KontactからKMailを使用して文字コードを変えずに送信する
 →utf-8になる
  Subject: =?utf-8?b?44OG44K544OI?=
  Content-Type: text/plain;
   charset="utf-8"
  Content-Transfer-Encoding: base64


・KDEメニューからKMailを立ち上げ(つまりKontactは起動しない)、文字コードを変えずに送信する
 →iso-2022-jpになる
  Subject: =?iso-2022-jp?b?GyRCJUYlOSVIGyhC?=
  Content-Type: text/plain;
   charset="iso-2022-jp"
  Content-Transfer-Encoding: 7bit


・KontactからKMailを使用して送信する際に、「メール作成」画面で「オプション」メニューから「エンコーディングの設定」を選択し、iso-2022-jpを指定する。

→iso-2022-jpになる
  Subject: =?iso-2022-jp?b?GyRCJUYlOSVIGyhC?=
  Content-Type: text/plain;
   charset="iso-2022-jp"
  Content-Transfer-Encoding: 7bit


送信する際に文字コードを指定すれば、今のところ問題は発生していないようです。


結果として、Kontact経由でKMailからメールを送信する場合、文字コードをiso-2022-jpに明示的に指定しないとutf-8になってしまうみたいです。

KMailやKontactの設定が悪いのでしょうか?

KDEプログラミング その4

KDEプログラミング その3」の続きです。

引きつづき前々回のmake中に実行されたgcc(g++)コマンドのオプションを調べます。

(2) g++ -o p2 main.o -L/usr/lib/qt3/lib -L/usr/X11R6/lib -lkdeui -L/usr/lib/kde3 -lqt-mt -lXext -lX11 -lm

-o:
(1)でも出てきましたが、出力先を指定します。
今回の出力先はp2ということになります。

実行ファイルを作る場合、-oオプションを省略するとa.outというファイルが作成されるようです。


-L:
-Ldirという形式でdirを-lオプションにより検索されるディレクトリのリストに追加します。


-l:
フォントによっては分かりづらいですがL(エル)の小文字です。

マニュアルから抜粋します。
名前が library であるライブラリをリンク時に使用します。

リ ン カは、標準のライブラリ用ディレクトリのリスト中から、実際のファイル名が`liblibrary.a' であるファイルを検索します。リンカはこのファイルを、ファイル名で直接指定した場合と同様に使用します。

検 索するディレクトリには、いくつかの標準システムディレクトリと、`-L' によって指定したディレクトリが含まれます。


このあたりは以下のサイトでも読んで、もう少し勉強したいと思います。
  オブジェクト不指向の共用オブジェクト(developerWorks)


とりあえず、以上です。


KDEプログラミング その5」に続く。

KDEプログラミング その3

KDEプログラミング その2」の続きです。

チュートリアルはちょっと休憩して、gcc(g++)で使用していたコンパイルオプション位は調べてみます。

数年前に一通り調べたような記憶はあるのですが、すっかり忘れました。


前回make中に実行されたgcc(g++)コマンドは2つでした。

まず一つめです。
(1) g++ -c -pipe -Wall -W -I/usr/include/freetype2 -O2 -m32 -march=i386 -mcpu=i686 -DQT_NO_DEBUG -I/usr/lib/qt3/mkspecs/default -I. -I. -I/usr/include/kde -I/usr/lib/qt3/include -o main.o main.cpp

-c:
これはmanページを参照すると次にようにありました。
ソースファイルを、コンパイルまたはアセンブルまではしますが、リンクはしません。コンパイラの出力は、それぞれのソースファイルに対応したオブジェクトファイルとなります。

要するにmain.cppからmain.oを作っているようです。


-pipe:
manページからです。
コンパイル時のステージの間のデータの受け渡しに、テンポラリファイルではなくパイプを使用します。いくつかのシステムではアセンブラがパイプからの入力を受け付けることができないために、このオプションを指定すると失敗します。GNU アセンブラでは問題なく使用できます。

このオプションを使うメリットってなんなのでしょうか?
テンポラリファイルを使わないということなので、無駄な記憶領域を使わないとかかな?
そんなこともないか。

と疑問に思ったのでGoogleで調べてみると、記述のあるサイトがありました。
コンパイルにかかる時間が短縮されるが、より多量のメモリが必要。

アセンブラがパイプからの入力をサポートしていないシステムもあるということですが、前回も書いたとおりMakefileはqmakeを使用して作成していますので、もしかしたらqmakeがそのあたりを調べて-pipeオプションを付けるかどうか判断しているのかもしれません。


-Wall:
-W:
-Wallは覚えているのですが、-Wは何でしょう?
マニュアルの-Wallの項目には次のようにあります。
全ての上に挙げた `-W' オプションを結合したものです。これらのオプションは全て、たとえマクロとの組み合わせであっても、避けたほうがいいと我々が推奨する用法や、簡単に避けることができると我々が信じている用法に関するものです。

ちなみに、-Wは-Wallより先に記述されています。
ということは「-Wオプションはいらないんじゃないの?」と思い、調べたところ次のサイトで詳しく説明されていました。
  gcc の警告オプション -Wall と -W

上記サイトによると、-Wは-Wallには含まれないようです。
-W オプションは、-Wall では無視されたけどチェックした方がよい場合がある項目に対して警告を出すらしいです。


-I:
フォントによっては分かりづらいですが、i(アイ)の大文字です。
これは覚えています。
マニュアルには次のようにあります。
インクルードファイルの検索するディレクトリのリスト中に追加します。

これは必ず覚えておかなければいけないですよね。


-O2:
最適化オプションです。
-O・-O1→-O2→-O3と最適化の度合が増すようです。
マニュアルの-O2の項目には、次のようにあります。
さらに最適化を行います。サポートされている最適化手段のうち、空間と速度 のトレードオフを含まないものはほとんどの全て使用されます。例えばループのアンローリングや関数のインライン化は行われません。 -O と比較して、このオプションはコンパイル時間と生成コードの性能の双方を増加させます。


私の記憶では最適化に-O2を使用していることが多いようです。
ネットで調べたところ明確な記述は見つからなかったのですが、最適化を強くすると値が不正確になる場合があると書いてあるサイトがありました。


-m32:
-mはターゲットマシン固有のオプションのようです。
次のサイトに記述がありました。
  最新x86CPUで堪能する極上32&64ビット・ライフ Part1(1)

32ビットアプリケーションとしてビルドする場合は-m32、64ビットアプリケーションとしてビルドする場合は-m64を指定するようです。


-march=i386:
-mcpu=i686:
次のサイトに記述がありました。
  GCC: CPU に関する最適化オプション

-marchは指定した CPU だけで動作するようなコードをし、-mcpu より速いコードを生成することが出来き、-mcpuは-marchと違って同系列の CPU でも動作するようなコードを生成するらしいです。

"-march=i386 -mcpu=i686"と指定すると、
・i686向けのコードを吐き出すけど、i386でも動く。
・i386系で速く動くコードを吐き出す。
ということでしょうか?
分かるような分からないような。


-DQT_NO_DEBUG:
-Dオプションは-Dmacroという形式でmacroに文字列"1"を与えているようです。

QT_NO_DEBUGはどう見てもQtのマクロなので、ソース中で使用しているのでしょう。
QT_NO_DEBUGはデバッグコードを無効にしているようです。


-o:
出力先を指定します。
今回の出力先はmain.oということになります。



あー疲れた。
続きはまた今度。

KDEプログラミング その3」へ続く。

KDEプログラミング その2

KDEプログラミング その1」のつづきです。

チュートリアルを続けます。
今回は行ったのは次のページです。
  p2 : A simple KDE "Hello World" application (Yahoo!翻訳)

前回はQt3のみを使用していましたが、今回はKDEのライブラリを少し使うようです。


前回同様にサンプルプログラムをそのまま打ち込みコンパイル・・・しようと思ってもコンパイル方法が書いていないのは予想通りです。
その程度で慌てません。

そこでまた探してみました。


(1) KDE本家のサイトからなんとか探す
このあたりを読んでみたのですが、よく分かりません。
英語ですし。

なんか、難しそうなことが色々書いてあります。
こんなに難しそうなことをしなくても、サンプルプログラムのコンパイルぐらい出来るだろうと考え、KDE本家のサイトから探すのは保留しました。


(2) 日本KDEユーザ会からなんとか探す
KDE-Tutorial "KDEによるGUI作成"というのがあったのでちょっと読んでみたのですが、コンパイル方法らしきものが見つかりませんでした。
ちゃんと読めば見つかるのかもしれません。

サンプルプログラムがあったので、それのMakefileを(たとえば-lqtを-lqt-mtに)修正してやろうとしたのですが、上手く行きません。
これがなんで上手く行かないのかは検証していないのですが、あとで確認したいと思います。


(3) なにか参考になりそうなソースを探す

KDE本家のダウンロードサイトにkdiffdate-1.0.tar.gzというのがありました。

ファイルサイズも10KBと小さいですし、参考になりそうです。

ダウンロードしてきて解凍し、中のINSTALLファイルを参考にコンパイルしてみました。
$ ./conifugre
$ make

ところが、makeでエラーになります。

./configure で作成したMakefileを見ると、次のところの値がとれていませんでした。
 -I$(KDEDIR)/include
 -L$(KDEDIR)/lib

Makefile中でKDEDIRを設定している箇所はありませんし、環境変数も設定されていません。
しょうがないので次のように修正しました。
 -I$(KDEDIR)/include → -I/usr/include/kde
 -L$(KDEDIR)/lib → -L/usr/lib/kde3

再度makeしました。
$ make

今度は成功したみたいです。


中に入っているconfigureファイルを確認したところ、このソフトkdiffdate.pro から Makefile を作成しているようです。

.proのファイルは前回はqmake -projectコマンドで作成しました。

kdiffdate.proを見てみると、KDE関連の追加と思われる次の箇所がありました。
 INCLUDEPATH += $(KDEDIR)/include
 LIBS += -lkdeui -L$(KDEDIR)/lib

さっき$(KDEDIR)とかあったのは、どうやらkdiffdate.proに書いてあったからのようです。多分。


(4) いよいよチュートリアルのプログラム(p2)をコンパイルする

なんとなくやることが見えてきましたので、再チャレンジです。

上記のとおり、色々試行錯誤してやっています。
正しいのか分かりません。
マネしないでください。


(a) p2.proの作成
$ ls
main.cpp
$ qmake -project
$ ls
main.cpp p2.pro


(b) p2.proの修正
$ cat p2.pro

 〜(略)〜

TEMPLATE = app
CONFIG -= moc
INCLUDEPATH += .

# Input
SOURCES += main.cpp


最後に次の2行を追加します。
 INCLUDEPATH += $(KDEDIR)/include
 LIBS += -lkdeui -L$(KDEDIR)/lib

$ echo INCLUDEPATH += /usr/include/kde >> p2.pro
$ echo LIBS += -lkdeui -L/usr/lib/kde3 >> p2.pro
$ tail -n3 p2.pro
SOURCES += main.cpp
INCLUDEPATH += /usr/include/kde
LIBS += -lkdeui -L/usr/lib/kde3


(c) Makefileの作成
$ ls
main.cpp p2.pro
$ qmake
$ ls
Makefile main.cpp p2.pro


(d) make
$ make
g++ -c -pipe -Wall -W -I/usr/include/freetype2 -O2
-m32 -march=i386 -mcpu=i686 -DQT_NO_DEBUG
-I/usr/lib/qt3/mkspecs/default -I. -I.
-I/usr/include/kde -I/usr/lib/qt3/include -o main.o main.cpp
main.cpp: function 内の `int main(int, char**)':
main.cpp:7: 警告: `__comp_ctor' is deprecated (declared at
/usr/include/kde/kapplication.h:205)
g++ -o p2 main.o -L/usr/lib/qt3/lib
-L/usr/X11R6/lib -lkdeui -L/usr/lib/kde3
-lqt-mt -lXext -lX11 -lm
$


警告は出ますが、なんとか出来たみたいです。


それでは実行してみます。
$ ./p2



おおっ。
前回のQtプログラムと若干違うみたいです。
ちなみに前回はこんな感じでした。



これがKDEの底力か!

・・・警告が気になりますけど。


しかし、サンプルプログラムでこんなにてこずるとは。

ちゃんと読めば、「(1) KDE本家のサイトからなんとか探す」で分かった気がします。


KDEプログラミング その3」へ続く。

KDEプログラミング その1

最近Vine Linux 4.1でKDEを使いはじめました。

で、リハビリがてらKDEのプログラミングでもしてみようかと思い付き、KDEの本家のページのチュートリアルでもやってみることにしました。
  Development/Tutorials/KDE3 (Yahoo!翻訳)

ちなみに、うちのVine Linux 4.1に入っているKDEは3.5.7、Qtは3.3.5みたいです。


まずはこちらの「Hello World!」のmain.cppをそのまま写してコンパイル・・・、しようとしたけどコンパイル方法が書いていない。

日本KDEユーザ会のチュートリアルのこちらのページの一番下にあるのに倣い、次のようにコマンドを叩きました。

$ g++ -I$QTDIR/include -o hello main.cpp
-L$QTDIR/lib -lqt
/usr/bin/ld: cannot find -lqt
collect2: ld はステータス 1 で終了しました


・・・エラーになります。

-lqtが見付からないということなので、探してみました。

$ ls $QTDIR/lib
libdesignercore.a libqt-mt.so@ libqt-mt.so.3.3.5*
libqui.so.1.0@ libeditor.a libqt-mt.so.3@
libqui.so@ libqui.so.1.0.0* libqassistantclient.a
libqt-mt.so.3.3@ libqui.so.1@


確かにlibqt.soとかはありません。

libqt-mt.soというのがなんとなく当たりかなと想像し、これで試してみました。

(ちなみに次に打ったコマンドは試行錯誤中のものです。これが正解ではないと思います。)

$ g++ -I$QTDIR/include -o hello main.cpp
-L$QTDIR/lib -lqt-mt

$ ls
hello* main.cpp


成功したみたいです。
実行してみたところ、次のようなプログラムが動きました。



ただ、「-lqt-mt」で正しいのか分かりません。
Qt3でのコンパイル方法をGoogleで調べてみたのですが、よく分かりませんでした。


Trolltechのサイトもチュートリアルがありました。
  Qt Reference Documentation (Yahoo!翻訳)

こちらを見てみるとg++を直接叩くのではなく、qmakeを使用してMakefileを作成しています。
それに倣ってやってみました。

$ rm hello ←最初に作ったプログラムを削除
$ qmake -project
$ ls
main.cpp p1.pro
$ qmake
$ ls
Makefile main.cpp p1.pro


Makefileが出来たみたいです。

それではmakeしてみます。

$ make
g++ -c -pipe -Wall -W -I/usr/include/freetype2 -O2
-m32 -march=i386 -mcpu=i686 -DQT_NO_DEBUG
-I/usr/lib/qt3/mkspecs/default -I. -I.
-I/usr/lib/qt3/include -o main.o main.cpp
g++ -o p1 main.o -L/usr/lib/qt3/lib
-L/usr/X11R6/lib -lqt-mt -lXext -lX11 -lm
$ ls
Makefile main.cpp main.o p1* p1.pro


p1というプログラムができました。

p1という名前になったのは、カレントディレクトリがp1だからだと思います。多分。

で、実行してみました。


動きました。
最初のとまったく同じですけど。


こんな感じで、少しずつ覚えてみようかと思います。


最近できたGoogleブック検索でタイトルQtで調べると、他の国ではQt3とかQt4の本が出てきますね。

アマゾンで調べると「Qt GUIプログラミング」という本が見つかりました。

レビューを読むとQt3みたいです。

私もとりあえずKDE3とQt3を使ってみようと思っているので参考に買ってみようかな。


KDEプログラミング その2」につづく