Kita - 2ch client for KDE part2
■ このスレッドは過去ログ倉庫に格納されています
0001kitaの中の人 ◆KITAulkOso
04/07/16 00:31ID:IZzU7SYf名前の由来はKDEの'K'に「板(board)」を加えたのと、キターー（゜∀゜）ーー!!から来てます。
Kitaのウェブサイト
http://kita.sourceforge.jp/
http://sourceforge.jp/projects/kita/
Kita Wiki
http://kita.sourceforge.jp/cgi-bin/hiki/hiki.cgi
前スレ
Kita - 2ch client for KDE
http://pc5.2ch.net/test/read.cgi/linux/1069738960/
前々スレ(DAT落ち)
おいお前ら！ GTK+使ってLinux版かちゅーしゃ作れや
http://pc.2ch.net/test/read.cgi/linux/1022744633/
0643login:Penguin
04/12/03 21:52:55ID:Kh8u1cQiところで最近、キテガイが張り付けた画像を何回も踏んでしまって頭を抱えています。
Linuxデスクトップ画像のスレにもありました。
個人的な要望で流れを止めてスマソですが、
>>601 の最後に書かれている。
画像あぼーん機能 "優先" キボンヌです。
0644421
04/12/04 00:06:13ID:QtPpS60z> 画像あぼーん機能
モザイク機能があるので画像あぼーんの優先度は割と低めです。というのは
口実で、他に片付けなきゃいけない事が山積みなので、特に問題の無い画像
関係には単に時間を割けないってだけなんですが・・・
という訳で画像関係のメンテナ募集中w
関数とか変数の意味が分からないとかいった質問があったら教えますんで。
それとレンダリング高速化計画ですが、なんとか0.173.0の2倍(状況によっては
3,4倍)までは速く出来ました。まあ結局レンダリングまわりをほとんど書き直す
羽目になった訳ですがorz 完成は明日の夜あたりかな。
それでも(一方的にw)ライバル視してるOpenJaneと比べると同スペックのPCで
4倍位遅いんだよなあ・・・。ほんと、化け物ですかw＞OpenJane
0645641ではないですが
04/12/04 00:21:18ID:lFcZHSka個人的には
・"アプリケーションで開く"
・"名前を付けて保存"
が欲しいです。(ﾟ ﾟ)
0646login:Penguin
04/12/04 00:46:54ID:Y5bXkGLi私に出来るかどうかはわかりませんが。
マターリと画像関係の調査からやってみます。
0647login:Penguin
04/12/04 00:59:27ID:Y5bXkGLi0648login:Penguin
04/12/04 03:05:48ID:yS3e6jTa0649641
04/12/04 09:00:20ID:4KUf6oSh641です。遅くなりました。
> 1-clickでクリックボードへURLをコピーできるようにするということですよね？
そうです。
> > ブラウザを選んだり細かい設定ができる。
> の「細かい設定」は具体的にどんな作業で、頻度はどれくらいだと思います？
具体的には、
* ブラウザの選択
* クリックしたURLをタブで開く
です。
klipperの 「設定」->「動作」->「^https?://.」 の中のmozilla用コマンド(確かdefaultで設定済)を見て頂くとわかりますが、
pgrep firefox && firefox -remote 'openURL(%s,new-tab)' || firefox %s (%sは、URLに置換)
のようになっていて、該当ブラウザが既に起動している時は、タブで開く設定になっています。
これによって、クリック毎に新規windowが開かなくするといった使い方をしますので、
頻度の答えとしては、「URLをクリックする度」となります。
0650421
04/12/04 23:21:50ID:rHUEAtjXdatinfo.{h,cpp} kita_misc.{h,cpp} parsemisc.h datmanager.{h,cpp} kitaconfig.cpp
kitawriteview.cpp kitahtmlpart.cpp kitadomtree.{h,cpp}
ttp://www.geocities.co.jp/SiliconValley-Bay/7435/patch-1204.txt
(おおまかな説明) 一番大きな変更点はパースエンジンを書き直してDOM系のクラスを除いたこと。
いままではHTMLDocument::createElement()を使ってノードを作ってましたが、KHTMLが最適化
されたKDE3.2以降はHTMLを丸投げしてKHTMLにレンダリングしてもらった方が速いことが分かったので、
DatInfo以下のクラスではHTMLテキストだけを扱うことにして、HTMLElement::setInnerHTML()を
使ってレンダリングすることにしました。( KitaDomTree::createResElement() のところ)。
これによってパース関係の関数が見やすくなりました。またハース関係の関数を一ヶ所
(kita_miscの700行以下あたり)にまとめて、パースの流れが分かり易くなるように整理しました。
その他、必要ないコードを削除したりメモリ消費量を減らしたり等。
(もうちょっと詳しい説明) 心臓となる関数はKita::parseResDat()で、 datinfo.hで定義されている
ResDat構造体のnumにレス番号、linestrにレスの生データをセットしてKita::parseResDat()に送れば
ResDatの各項目に生データが入ります。例えばKita::DatToHtml()を見ると分かり易いかも。
実際にキャッシュの中にあるレスが表示されるまでの流れはこんな感じ。
(1) KitaHTMLPart::setup()のKita::DatManager::createDatInfo()でDatInfoクラスが
作られる際にDatInfo::initPrivate()の中のm_access->getcache()により、Accessクラスから各行の
生データ(unicodeにエンコード済み)がDatInfo::slotReceiveData()に送られて来て、行ごとに
DatInfo::copyOneLineToResDat()を呼んで、そこで resdat.num = num;、resdat.linestr = line;
とレスの番号と生データがResDat構造体にセットされる。
つづく
0651421
04/12/04 23:24:44ID:rHUEAtjX(2) その後 KitaHTMLPart::load()、KitaHTMLPart::showResponses() 経由でKitaHTMLPartクラスから
レスを表示するためKitaDomTree::appendRes()が呼ばれると、そこからレスのDOMエレメントを作るため
KitaDomTree::createResElement()が呼ばれ、さらにHTMLテキストを得るためにDatInfo::getHTML()が呼ばれる。
(3) DatInfo::getHTML()からResDat構造体をパースするためDatInfo::parseDat() が呼ばれ、そこから
さらに Kita::parseResDat()が呼ばれてResDat構造体にHTMLなどがパースされて入る。
(4) あとはKitaDomTree::createResElement()に戻って、setInnerHTML()でHTMLがレンダリングされ、
KitaDomTree::appendRes()でレスがappendされて表示される。
(5) リロードで鯖からデータが送られて来たときも同じ感じでパースされる。
(注意点) DIVの中にTABLEやDIVがあると致命的に速度が遅くなることが分かったのでレスのDOMツリー構造を
DIV
|-TABLE タイトル
|-DIV 本文
から
DIV タイトル
DIV 本文
に簡略化してます。ただし、スタイルシートを使用する場合は速度より見た目を重視するということで、
DIV-TABLE タイトル
DIV 本文
とタイトルノードでTABLEタグを使用してます。タイトルノードの詳しい構造については
Kita::createTitleHTML()を参照してください。デフォルトのスタイルシートも多少変更してます。
0652421
04/12/04 23:35:57ID:rHUEAtjXしばらくはコードの内部の方に引きこもってUIとかの外部仕様はいじる予定は無いです。
あと>>650で間違った記述があったので少し修正
> ResDat構造体のnumにレス番号、linestrにレスの生データをセットしてKita::parseResDat()に送れば
> ResDatの各項目に生データが入ります。
-> ResDatの各項目に生データがパースされてHTMLなどのデータが入ります。
0653421
04/12/05 00:30:55ID:7ft/edw3*** part/kitadomtree.cpp.org 2004-12-04 23:02:26.000000000 +0900
--- part/kitadomtree.cpp 2004-12-05 00:28:22.255368280 +0900
***************
*** 77,83 ****
else{
if ( m_bufLng == 0 ) m_bufLng = mrg;
! else while ( num >= m_bufLng ) m_bufLng += delta;
m_titleElm.resize( m_bufLng );
m_bodyElm.resize( m_bufLng );
--- 77,83 ----
else{
if ( m_bufLng == 0 ) m_bufLng = mrg;
! while ( num >= m_bufLng ) m_bufLng += delta;
m_titleElm.resize( m_bufLng );
m_bodyElm.resize( m_bufLng );
0654kitaの中の人 ◆KITAulkOso
04/12/05 00:58:47ID:cOV8aKgn・登録/削除のタイミングでお気に入りを保存(>>581)
・お気に入り周りのコード整理をちょっとだけ
DQ8という誘惑に負けてるのでコードあまり書いてませんorz
>>645
これは左クリックの話？右クリックメニューでいいのならそちらに入れたいです。
>>649
なるほど。それなら1-clickでコピー出来る方が便利ですね。
最悪configファイルを直接いじる形になるかもしれませんが、機能は入れます。
# たぶんKitaMainWindow::slotOpenURLRequestExt()をいじればいいので自分が担当かな。
>>650>>653
merged. めちゃくちゃ高速化されてますねぇ。とりあえず気になったのは
・「名前」の前にスペースが欲しい。
・検索したときの移動場所がおかしい(前にも同じ問題があったような)。
くらいです。
0656421
04/12/05 01:41:05ID:7ft/edw3作りかけだからなのでとりあえず気にしないでおいて下さい。
>>654
> 最悪configファイルを直接いじる形
結構イレギュラーな設定だと思うので、プリファレンスには項目を作らないに一票
> ・「名前」の前にスペースが欲しい。
> ・検索したときの移動場所がおかしい(前にも同じ問題があったような)。
あれ、うちの環境(KDE3.3)だと問題無いんですが、Turbo10Fって確かKDE3.1だから
それが悪さしてるのかなあ・・・。明日にでもKDE3.1のマシンで確認しときます。
0657421
04/12/05 23:38:22ID:4Ipjwlc1access.{cpp,h} datinfo.{cpp,h} kita_misc.cpp thread.{cpp,h} datmanager.cpp threadindex.{cpp,h}
kitadomtree.cpp
ttp://www.geocities.co.jp/SiliconValley-Bay/7435/patch-1205.txt
・KDE3.1対策
>>654は>>93の「KDE3.1のバグ」が原因だったので、 KDE3.1の場合はタイトルノードでデフォルトで
TABLEタグを使って、本文ノードはHTMLの前後に<div>タブを付けることに( Kita::parseBody()と
Kita::createTitleHTML()の先頭と最後の#ifのところ )
それとKDE3.1の場合はAAも崩れていたのですが、こっちの方は Kita::parseBody() で
<span style=\"color: white\"></span>みたいに空白のspanタブを行の先頭に追加しても
setInnerHTML()でレンダリングするとspanノードを作ってくれないらしいことが原因だったので、
<span style=\"color: white\">_</span>みたいに適当に空白ではない文字を入れて、
setInnerHTML()してから"_"を取り除くことに( KitaDomTree::createResElement() の#ifのとこ)。
当然ですが、上の処理をしているためKDE3.1で、かつAA表示設定にしているとレンダリング速度は
がくっと落ちます(というかノーマル0.173.0程度の速度に戻ります)。その他、
・datのサイズをAccessクラスから取るように( DatInfo::getDatSize() のとこ )
・レスのマーク情報の管轄をThreadクラスに移動( Thread::isMarked() のあたり )
・レスのマーク情報をidxに保存するように( ThreadIndexに関数追加 )
これでやっとマーク機能がまともに使えるようになったかな・・・。とりあえず全マーククリア
機能とマークしたレスを抽出して表示する機能は近々付ける予定。
次はThreadクラスの管轄をBoardManagerに移す作業に移ります。Threadクラスの検索速度の
向上とデータベースの一意性の確保が狙い。
0658421
04/12/06 00:41:37ID:Ywt3GBNw書かれてないので消して良いです。
それとソースのディレクトリ構造なんですが、libkitaとprefsは良いのですが、
KitaThreadPartが無くなった今partの意義が薄れている気がします。それに
Kita*tabwidget、Kita*viewがsrcとpartにちらばっているのもあまり綺麗じゃ無い
ので、ぼちぼちディレクトリ構成を再構成した方が良い様な希ガス。
0659kitaの中の人 ◆KITAulkOso
04/12/07 23:19:51ID:OFJ0xJoo>>657
merged.
あと>>624のパッチ入れるの忘れてたと思ったら>>636で入ってますね。
> ぼちぼちディレクトリ構成を再構成した方が良い様な希ガス。
これは自分も思ってたんですが、どういう風に構成した方がいいかなぁ。
Dock単位あたり？
0660421
04/12/08 01:03:33ID:pzIIB6zG(1)板dock、スレッドdock、画像dockみたいに機能別に分ける
(2)タブ、Viewみたいに階層別に分ける
って方法が考えられますが、まあ普通に機能別が分かりやすいんじゃ
ないすかねえ。
> お気に入り関連の整理中。
wikiのお気に入りの移行のところ見ましたが、階層型のデータを
保存する場合はKConfigよりもXMLの方が良い気がします。
今更そんなこと言うなって気もしますがw
というのも、いまBoardManagerの仕上げの最中で、BoardViewの
bbsmenuのダウンロード処理とか外部板の登録まわりをBoardManager
に移しているところなんですが、試しに外部板のファイル形式をXMLに
してみたらListViewと非常に相性が良かったもので。あとXMLなら視覚的
に階層構造が分かりやすい、多階層が扱える、手動で編集するのが楽
だってこともあります。
0661421
04/12/08 01:25:18ID:pzIIB6zG感じのXMLになります。まあちょっと拡張して、ぬるぽディレクトリの中に
ぬるぽ2ディレクトリがある構造にしてますが。それと、ぬるぽ2の中では
お気に入り板が登録されてます(boardタグ)
<thread url="http://pc5.2ch.net/linux/dat/1000000000.dat" name="とあるスレ" />
<thread url="http://pc5.2ch.net/linux/dat/1111111111.dat" />
<dir name="ぬるぽ">
<thread url="http://pc5.2ch.net/prog/dat/1097151856.dat" />
<thread url="http://pc5.2ch.net/software/dat/1085660776.dat" />
<dir name="ぬるぽ2">
<board url="http://pc5.2ch.net/linux/" name="リナックス板" />
</dir>
</dir>
<thread url="http://pc5.2ch.net/linux/dat/1234567890.dat" />
こんな感じでお気に入りスレとお気に入り板の情報を同時に扱えば、このXMLを
そのまま板タブにも適用できるので、favoriteboardクラスとfavoritethreadクラスを
区別しないで統合することも出来ます。
0662login:Penguin
04/12/08 01:51:34ID:iTUuYtH+>661=421殿
ｶﾞｯ
0663421
04/12/09 22:30:35ID:wppuibumスナップショットを。まだ全然未完成ですが。
ttp://www.geocities.co.jp/SiliconValley-Bay/7435/snap-20041209.tar.gz
更新内容を簡単に説明すると、まあ主にBoardManagerの仕上げなのですが、
ユーザー的には板ビューを拡張して自由にお気に入りでディレクトリを作ったり
並び替えたり改名が出来るようになったことが大きいですかね。例えばこんな感じ。
ttp://www.geocities.co.jp/SiliconValley-Bay/7435/ss-1209.png
具体的には2つの関数
・KitaBoardView::XML2ListView()・・・XMLをListViewに変換
・KitaBoardView::listView2XML()・・・ListViewをXMLに変換
でListViewとXMLを直接変換するように変更してます。それで、直接ListViewがXMLに
アクセスするようになったのでFavoriteBoardsクラスはもう無くても良いです。今までは
KitaBoardView <-> FavoriteBoards <-> favorite_boards.xml
みたいにFavoriteBoardsクラスが間に入っていたのですが、今回からは(内部実装の都合で)
メイン、外部、お気に入りという3つのタブに板タブを分けて、
KitaBoardView <-> board_main.xml, board_external.xml, board_favorite.xml
みたいにタブ別にXMLにアクセスするようにしてます。お気に入りを増やすときも
SignalCollectionにaddListViewItemシグナルを追加して、そのシグナル経由で
板ビュー自体が追加するようにしています( KitaBoardView::slotAddListViewItem()のあたり )。
リストビューの並び方がそのままXMLになってるので手動でXMLを編集するのも楽だと思います。
まあ他にもThreadクラスの管理をBoardManagerに移動したりとか大きい変更点があるんですが、
その説明はおいおい完成してからってことで・・・
0664kitaの中の人 ◆KITAulkOso
04/12/11 21:50:37ID:fMRaUF5g>>660
> 階層型のデータを
> 保存する場合はKConfigよりもXMLの方が良い気がします。
> 今更そんなこと言うなって気もしますがw
最初はXMLにするつもりだったんですけどねぇ…。XMLをやめてKConfigにしようと思った理由は、
・XMLのAPI(DOM)はめんどい。これはまあたいした理由ではないです。
・普通にコード書くと、「知らない項目」が入ってるとそれが消えてしまう。
具体的には、新しいバージョンAでXMLに拡張があった場合、
そのファイルを古いバージョンBで読み込んで書き込むと、Aでの拡張が認識できないので消えてしまう。
・逆に新しいバージョンCで項目が減った場合に、古いバージョンDで認識できない
要するに>>533であった問題。これは元のコードがヘボかったのが問題なので大きな問題ではないです。
懸念しているのは2番目ですね。レアケースなのでそういうポリシーだと決めてしまえば問題ないですが、
今後同じことで悩むのもどうかと思うので、互換性についてのポリシーを決めてしまいたいと思います。
あとでWikiに書きます。
あと、肝心のKConfigを使う件ですが、どうやらKConfigでも問題があるのに気づいたので、
やっぱりXMLにしようと思います。
0665rpmpoint
04/12/11 23:37:00ID:QbBc9Kw0本年度中の復活を目指します。
suseユーザーの皆様に大変御迷惑を御掛けしていることをお詫びします。
0666login:Penguin
04/12/12 00:29:02ID:myzQvVjjpgrep firefox && firefox -remote 'openURL(%u,new-tab)' || firefox %u
にしたらすむ話じゃないのかな…
非HTMLなファイルを開いたときに、KonquerorとかFirefoxみたいに
開くか保存かを尋ねてくれるUIは欲しいけど。
0667login:Penguin
04/12/13 00:03:18ID:sweIMb0Gスレがあるのです。両方ともかつて一度は見たことのあるスレについてなのですが、例えば
オープンソース版Solarisに前もって文句を言うスレ
http://pc5.2ch.net/test/read.cgi/unix/1101841777/
はロードできる（続きが追加される）のに、
\chapter{\TeX} % 第三章
http://pc5.2ch.net/test/read.cgi/unix/1059616013/
アンチウィルスソフト総合スレ
http://pc5.2ch.net/test/read.cgi/unix/1046547211/
などで続きが追加されません。未読襴もそのままです。
kita が古いせいでしょうか? kita のバージョンは 0.160.0 です。
0668421
04/12/13 00:22:28ID:NBA0XXftあぼーんがあってスレが壊れてるだけだと思うので削除してリロードしてください。ちなみに下の
proto-1212.txtを当てるとあぼーんがあったときに「壊れてる」旨の表示をするようになります。
で、帰ってきたのでお気に入り板まわりのプロトタイプ。まあこれもパッチじゃなくて仕様を確定する前
に試してもらいたいってことで、バグもちょっと残ってますがとりあえずこんな感じでどうですかね > 中のひと
cvs差分のkitaで-p0。多分大丈夫だと思いますが、.kde/share/apps/kitaはバックアップしておいて下さい。
ttp://www.geocities.co.jp/SiliconValley-Bay/7435/proto-1212.txt
(仕様)
詳しい話は>>663。お気に入りでの右クリックメニューに新規ディレクトリ作成、リネームメニュー追加。
ドラッグで項目移動。.kde/share/apps/kitaの boardview_main.xml、boardview_external.xml、
board_favorite.xmlがそれぞれ板一覧、外部板、お気に入り板に対応しています。もしこれらのファイルが
もうあるなら消してからkitaを起動してください。フォーマットは暫定仕様ですが
ディレクトリ・・・<dir open="0か1" name="名前" >
板・・・<board url="URL" name="名前" />
(まだ実装してないけど将来的に)スレ・・・<thread url="URL" name="名前" />
って感じ。もしかしたら<root>タグも加えるかも。
板一覧と外部板の場合(boardview_main.xmlとboardview_external.xml)は板を登録するため板のname属性は
必須ですが、その他の板(とスレッド)のXMLの場合はname属性は不要です(ある場合はエイリアスになる)。
互換性の問題はなかなか難しいんですが、今回はKitaBoardView::slotShowBoard()でお気に入り板を
表示するときに、新XML(boardview_favorite.xml)が無いときは旧XML(favorite_boards.xml)を
新XMLに変換して(BoardManager::convertOldFavoriteXML())、逆にお気に入り板を閉じるときは
古いフォーマットのXMLでも保存するようにして解決しています(BoardManager::saveOldFavoriteXML())。
まあ力ずくで2度手間なコーディングになりますが、一番てっとり早い方式なのでw
0669667
04/12/13 08:17:12ID:Y81Fg/YO# その後 FC2からFC3 にアップグレードしました（クリーンインスコです）。
でいきなりなのですが。。。kita0.173.0 (KDE3.3.0.5 Red Hat) でソース tar ボールを取って来て、一般ユーザで
tar xvfz kita-0.173.0.tar.gz
cd kita-0.173.0
./configure --prefix=$HOME/.kde
make
make install
してからシェルで
cd kita-0.173.0/kita/src/
./kita
として起動しました。書き込みウィンドウを開いて、Ctrl+Space で IIimf を起動し Insert キーを押すと、
kita とターミナル がクラッシュしてしまいます（ 一緒に起動していた konqeror もクラッシュしました。emacsは大丈夫でした。)。
何か回避できる方法はありまつか? よくわからないけれどクラッシュハンドラの言い分を↓にコピペしてみますネ。
0670667
04/12/13 08:25:00ID:fzpVDMU2Using host libthread_db library "/lib/tls/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -178792768 (LWP 13102)]
[KCrash handler]
#4 0xf5cfa42d in QObject::activate_signal ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#5 0xf6031409 in QInputContext::deletionRequested ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#6 0xf51fd9e5 in QXIMInputContext::close ()
from /usr/lib/qt-3.3/plugins/inputmethods/libqxim.so
#7 0xf51fd62e in QXIMInputContext::close_xim ()
from /usr/lib/qt-3.3/plugins/inputmethods/libqxim.so
#8 0xf51fc246 in ?? () from /usr/lib/qt-3.3/plugins/inputmethods/libqxim.so
#9 0x00000000 in ?? ()
アプリケーション Konsole (konsole) はクラッシュしシグナル 11 (SIGSEGV) を発行しました。
Using host libthread_db library "/lib/tls/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -172775744 (LWP 5442)]
[KCrash handler]
#4 0x09a4f25d in ?? ()
#5 0xfeecc150 in ?? ()
#6 0x09a43980 in ?? ()
#7 0xf6258cab in QObject::activate_signal ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
0671667
04/12/13 08:41:41ID:gwfRXkyh(同上)
[New Thread -172775744 (LWP 5413)]
[KCrash handler]
#4 0x099f72cd in ?? () #5 0x099f76c0 in ?? () #6 0xf5f3f207 in XDestroyIC () from /usr/X11R6/lib/libX11.so.6
#7 0xf4d750d8 in QXIMInputContext::~QXIMInputContext ()
from /usr/lib/qt-3.3/plugins/inputmethods/libqxim.so
#8 0xf6256449 in QObject::event () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#9 0xf61fa249 in QApplication::internalNotify ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#10 0xf61fa3da in QApplication::notify ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#11 0xf68294c8 in KApplication::notify () from /usr/lib/libkdecore.so.4
#12 0xf61fb3a6 in QApplication::sendPostedEvents ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#13 0xf61fb432 in QApplication::sendPostedEvents ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#14 0xf61aa005 in QEventLoop::processEvents ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#15 0xf620f875 in QEventLoop::enterLoop ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#16 0xf620f7ce in QEventLoop::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #17 0xf61f944b in QApplication::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#18 0xf5790d75 in kdemain () from /usr/lib/libkdeinit_kio_uiserver.so #19 0xf6fe7678 in kdeinitmain () from /usr/lib/kde3/kio_uiserver.so
#20 0x0804dfb1 in ?? () #21 0x00000001 in ?? () #22 0x097cd568 in ?? () #23 0x00000001 in ?? () #24 0x097ceb8d in ?? () #25 0x00000000 in ?? ()
うーん意味ないかもこれの分まででやめときますねm(_ _)m
0672667
04/12/13 10:04:39ID:WY8ndmBF0673login:Penguin
04/12/13 20:30:16ID:eaY3Cl5T0674login:Penguin
04/12/13 23:17:28ID:6djY9gTX環境: Debian Sarge (KDE3.2.3), kita 0.173.0
症状: 「ファイル」→「板一覧の読み込み」を選択したとき、移動した板の情報ウインドウを
閉じることができず、本体も終了できない。
killで終了して、~/.ked/share/apps/kita/board_listを削除後、再起動すれば問題はないのですが。。
0675login:Penguin
04/12/14 17:57:44ID:25igtLht□▽ ?/32 | ?/2048 OK キャンセル
↑
このリストボックスって何するものなんですか？
0676login:Penguin
04/12/14 18:26:31ID:Dh76sXcAmenu Settingの"Config Kita"内のAsciiArtにAAを登録すれば
そこから呼び出せる。
0677421
04/12/15 23:44:57ID:5kVcSJciあれ便利ですよねえ。私も欲しい機能なんですけど今は内部整理を優先してるので
そういう拡張はそれが全部終わってからかなあ・・・。ちなみに内部の話をすると
>>650のパッチは将来的にその機能に対応できるように設計済みだったりします。
>>674
それだけでは分からないので、ダイアログの内容を教えてもらいたかったり。
で、ちびちび作ってた奴が大体出来たのでパッチ。srcで-p0。変更したソースは
access.{h,cpp} datinfo.cpp boardmanager.{cpp,h} thread.{cpp,h} kita_misc.{cpp,h}
kitaboardtabwidget.cpp kita.{cpp,h} kitasubjectview.{h,cpp} threadlistview.{cpp,h} favoritelistview.cpp
さらに favoriteboards.{cpp,h}, kitaboardview.{h,cpp} を差し替え
listviewitem.{cpp,h} も差し替えて、さらに libkita以下に移動
ttp://www.geocities.co.jp/SiliconValley-Bay/7435/patch-1215.tar.gz
内容は一言で言えば板まわりの仕上げなのですが、予想よりも難航したorzために
かなり内部をいじってます。詳しい変更点はこちらを見てください。
ttp://www.geocities.co.jp/SiliconValley-Bay/7435/readme-1215.txt
XMLのフォーマットはとりあえず暫定的なものなので、こっちの方が良いという場合は
修正かけます。
あとはしばらくバグ潰しやソース整理をしつつlibkita以下に残っているobsoleteな
関数の削除をおこなう予定。
0678kitaの中の人 ◆KITAulkOso
04/12/16 00:12:40ID:JSm9Gs4X以下でいろいろ書いてますが、とりあえず実用的に問題ない状態ならCVSに入れます。
が、はっきり言って今のコードは不満だらけなので開発辞めたい気分です。
「私」の方は大体片づいたのですが、「公」の方がさらに酷くなったので
まだ触る気がしないですが、とりあえず。
>>663>>668
一応ポリシー書きました。文体がアレなのは仕事が忙しい影響ですｗ
http://kita.sourceforge.jp/cgi-bin/hiki/hiki.cgi?Kita%A4%CE%B8%DF%B4%B9%C0%AD%A5%DD%A5%EA%A5%B7%A1%BC
互換性については問題ないです。
パッチも試しましたが、FavoriteThreads::readFromXMLから辿って
Thread::setThreadName()で落ちますね…。
既に移転した板がお気に入りに入ってるとまずいような気が。
とりあえずUIについてコメント。
・External/お気に入りは似たような感じなので一つにまとめた方がいいと思います。
・フォルダだけ編集可能なのが分かりにくい(2chの板も編集出来ますね)。
あと編集可能にするなら右クリックメニューがいいですね。
・スレッドも統合した方がいいですね。そこらへんはやります。
つづく。
0679kitaの中の人 ◆KITAulkOso
04/12/16 00:13:08ID:JSm9Gs4Xディレクトリサポートするなら古いフォーマットと互換性がなくなるので無理にやらなくてもいいかと。
importがあれば十分だと思います。理由はポリシーから。
XMLについて。
・dirのopenは0/1でなくtrue/falseにしてください。
・ぱっとコードを見た限り大丈夫だと思うけど、url以外は必須項目でないようにしてください
(FavoriteThreadsではnameやresnumも必須だったのでそれの反省)
・登録時にファイルに書き込みした方がいいと思います。落ちたときにorzにならないために。
> Threadクラスの管理をBoardManagerに移動したり
あと今更ですが、BoardDataがThreadのリストを持ってる構造になってますが、
これはやめてください。以下理由。
・以前自分がやって失敗した。
・スレの情報だけあって板の情報がない場合の処理がややこしくなる(はず)。
datURLだけあれば板 <-> スレのやりとりは可能なので、クラス間は疎結合にした方がいいです。
ThreadManagerみたいなのを作れば十分でしょう。
0680kitaの中の人 ◆KITAulkOso
04/12/16 00:43:48ID:JSm9Gs4X入れようと思ったけどコードが足りないです。差し替え分しかないです。
あと前も言いましたが、パッチが大きすぎて面倒見切れません。
仕様の合意もないし、accept/rejectしか選択肢がないパッチは嫌です。
普通ならこういうでかいパッチはrejectします。
http://www.winehq.com/?issue=205#Shell32%20Update%20&%20Patch%20Submission%20Process
この記事を何度も読んでください。一つのパッチに一つの機能にしてください。
内部構造のせいでパッチが大きくなるならrefactoringだけのパッチを送ってださい。
それが嫌ならsf.jpのアカウント取ってください。それなら好きに出来ますから。
もう嫌です。Kitaのコードはもう見るに耐えません。
次のバージョンは出すかどうか分かりません。
0681login:Penguin
04/12/16 01:06:15ID:DtmMjzDLｶﾞﾝｶﾞﾚｰ
0682kitaの中の人 ◆KITAulkOso
04/12/16 01:12:31ID:JSm9Gs4Xそろそろ入院した方がいいですかね。
例えばcommitしていて何ですけど、以下の点がイライラします。
・ThreadIndex::loadIndex, saveIndex: Kita::Threadは原則廃止のはずなのに(>>237)復活してます。
こんなことやってたらいつまで経ってもコードがよくなりません。
・タブの空白への変換くらいしてください。前も言いましたが。いちいちこっちでやってられません。
・簡単にファイルのreplaceなんてしないでください。自分の書いたコードは全否定ですか。
・500行以上のファイルはそれだけでイライラします。
0683login:Penguin
04/12/16 01:15:30ID:mMVbC1o+おつかれ。
後のことは一切気にせず
しばらくゆっくり休むべし。
0684kitaの中の人 ◆KITAulkOso
04/12/16 01:28:19ID:JSm9Gs4Xありがとう。とりあえずしばらくおとなしく休みます。
# とりあえず21日までは正常な状態になりそうにないので…
>>421さん
いろいろ言いましたが、パッチについては感謝してます。
ただ、今までの自分の行動はオープンソースの開発としては「お人好し」なのだけは理解してください。
とりあえず今日は寝ます…。
0685login:Penguin
04/12/16 02:20:43ID:HtOSZb1F>> kitaの中の人
肉の日とか期限を切らないで
ゆっくり、のんびりで良いから・・・
kitaがなくなっちゃうのは嫌ｽﾞﾗ
ゆっくりお正月を過ごしてリフレッシュするｽﾞﾗ
0686421
04/12/16 03:46:44ID:ygQuE+6tもう遅いので詳細のネゴシエーション(＆謝罪＆弁解)は明日にしますが1点だけ。
> 入れようと思ったけどコードが足りないです。差し替え分しかないです。
パッチ分はtarの中に含まれてるpatch-1215.txtです。最初はいつも通り
全部でdiffしてgeocityに上げようと思っていたのですが、一部のファイル
はリプレスした方がサイズが小さかったので別にしたのですが、拡張子を
直すのを忘れてました。なお.txtという拡張子なのは.diffとか.patchだと
geocityに蹴られるからです
それから個人的な話になるのであまり話したく無かったのですが、先月あたり
から急にパッチ量が増えたり、ユーザーの要望にあまり積極的に答えていない
理由は、実は来月から転勤で部署が変わってかなり仕事が増える(多分)ことに
なりそうなため駆け込みでパッチを書いているためです。恐らく来月以降は
デバッグ関係とか>>673みたいな小さいパッチくらいしか出せなくなるんじゃ
ないかなあ・・・。ちなみに最近パッチの内容説明がやたらくどくて長々と
してたのは、引継ぎとかこれから開発に参加希望の開発者育成のためという
のも理由の一つだったりします。
0687login:Penguin
04/12/16 03:58:28ID:mpC2bEIr感謝！感謝！
0688login:Penguin
04/12/16 04:10:51ID:GBMiZfvt0689login:Penguin
04/12/16 09:45:47ID:vD8VKRVjここしばらくずっと追わせてもらってます。感嘆そして感謝を。
つか、しばし休息が必要なのでわ＞おふたり様
勢いあるのはいいことだけど、
たったふたりかつ仕事もちの方同士とは思えんペースではないかと。
0690login:Penguin
04/12/16 13:18:50ID:xZ7oekdgkitaに危機がｷﾀ━━━(ﾟ∀ﾟ)━━━!!!!なのか？
そりは勘弁しちくりorz.... お気に入りの改善ずっと待ってるのに.....
とはいえ、無理は言えませんので
一旦開発停止してお二人でよく話し合ってみては？（お忙しいでしょうが）
お互い顔見ずにやってると思い込みが先走りがちだから、
一回言いたいこと言い合えば結構何でもなかったりするんじゃないかと淡い期待をしたりw
素人目には、>>682に書かれた点は、イラつく気持ちは分かりますが、三つ目以外は
「言えば済む」程度の些細なことに見えます。少なくとも、これらが原因で開発終了に
なったとしたら、ユーザとしては切なすぎる......
（どっかの人みたいにソースごとPC盗まれたとかで終了ならまだ諦めもつきますがw）
仕事抱えながら合間にコード書いて、コミュニケーションまで取ってる余裕がない、
っていうのが問題なんじゃないのかなぁ。>>689さんが言うように、もっとゆっくりでもいいのでは？
「待て」って言ってもらえれば待つし。
「作ってて楽しくなきゃやってられない」ものだと思いますし。
というか、「作者さんたちが開発を楽しんでいるところが見れる」のが自分にはkitaの魅力の
一つだったりするんですが。
0691login:Penguin
04/12/16 13:43:21ID:2ctboU/xという印象はありません。むしろ「え!? いいの?」ってくらいすぐ答えてくれてる希ガス。
0692691
04/12/16 17:17:58ID:SwHUIxc4激しく同意です
俺がパッチ書くのやめたのも
> 自分の書いたコードは全否定
だったことが大きかったですし、実際当ててたパッチの機能で死んでるのありますし
>>686
> なお.txtという拡張子なのは.diffとか.patchだと
> geocityに蹴られるからです
.gzが蹴られないので圧縮すると言う手もありますがね...
どっちにしろ、パッチの作り方そのものを見直す方がいいでしょう
man patch でもパッチは機能別に分けることを推奨してますしね
0693421
04/12/16 22:17:51ID:ygQuE+6t> http://www.winehq.com/?issue=205#Shell32%20Update%20&%20Patch%20Submission%20Process
オープンソースの世界では良くある話でなかなか興味深い話ですね。でかいパッチの弊害は
私も知っているので、いつも悪いなあ、また怒られるかなあと思ってたのですが、結果的に何回か
でかいパッチが続いてしまったことは申し訳なく思ってます。夏の頃みたいに、割と時間に余裕が
あれば一気にじゃなくて段階的に更新して行きたかったのですが・・・
また、kitaの様に開発者が実質数人だけの小規模プロジェクトの場合は、まず実装ありきの
ラウンドトリップ型で開発を進めた方が話が早いと思っていたため、つい大きいパッチに
してしまいがちでした。開発者が少ないため、何か問題や疑問が生じたら>678や>>679の
ように直接それを伝えてもらって修正していけば良いやと思ってたため中の人に甘えていた
のかもしれません。
> それが嫌ならsf.jpのアカウント取ってください。それなら好きに出来ますから。
以前もコミッタにならないか誘われたときに辞退した覚えがありますが・・・
確かにコミッタになったり派生ブラウザを作成した方が好き勝手にソースを改変出来る
ので私も作りやすいのですが、コミッタになると好き勝手に作る可能性があるため一度
目を通してチェックしてもらいたい、下手に派生ブラウザを作ってOpenJaneみたいな状況にしたく
ない、UI設計やシンプル路線などの方向性で中の人に賛同しているため、好き勝手に作る
よりも方向性を示してもらってそれに沿って作って行きたいetc.という理由からコミッタに
なることは乗り気ではありませんでした。
ただ、実際に中の人を怒らせてしまった以上、もうパッチを出さないでくれと言われるなら
そうするつもりです。またkitaのプロジェクト自体を終了させるというならば私が原因で
ある以上私がプロジェクトを引き継ぐことは無いです。もちろんそれでは無責任すぎるの
で誰か他の人が引き継ぐというならばコードの説明などの引継ぎは行うつもりですが。
つづく。あと4つほどあるので連投規制に引っかからないかなあ・・・
0694421
04/12/16 22:20:48ID:ygQuE+6t> ・ThreadIndex::loadIndex, saveIndex: Kita::Threadは原則廃止のはずなのに(>>237)復活してます。
Kita::Threadはスレッド情報のキャッシュとして使っているだけでクラスとしては事実上廃止にしました。
今はまだクラスの形態になっていますが、qdictや主要なメンバ関数は他に移したのでただの構造体にする
予定でした。その辺りの詳しくは下の方で。それとThreadIndex::loadIndex,saveIndex廃止というのは今
始めて聞いたような気がするのですが・・・
> ・タブの空白への変換くらいしてください。前も言いましたが。いちいちこっちでやってられません。
そういや怒ってたなあと思い出して、先月あたりから.emacsを書き換えてタブじゃなくて
空白を使うようにしていました。
> ・簡単にファイルのreplaceなんてしないでください。自分の書いたコードは全否定ですか。
全否定ということは決して無いです。確かにFavoriteBoardみたいに内部機構が完全に変わった場合は
ごめんなさいという感じでリプレスしていましたが、あくまで完全リプレスは最後の手段ということで、
基本的にはオリジナルコードを再利用する方向で作っていました。ではなぜリプレスになるかと
いうと-cオプションでdiffするとパッチよりもリプレスした方がサイズが小さい時が多かったから
なのですが・・・。例えば今回もkitaboardview.cppの場合は中を見ると分かるようにオリジナル
の部分がかなり残っています。
それと>>691氏が怒ってらっしゃるのは多分埋め込みパートまわりの件だと思うのですが、埋め込み
パートのコードは個人的には非常に勉強になったのでありがたく思っているのですが、元々画像
ビュワーを実装するまでの暫定仕様という位置付け(だと自分は思っていた)ため、画像ビュワーが
実装された以上はセキュリティやコード量の面から削除しても良いかなと思っていました。もし
埋め込みパートを発展させて画像ビュワーを作る予定だったならばお詫びします。
つづく
0695login:Penguin
04/12/16 22:20:57ID:CT++Z2pb> またkitaのプロジェクト自体を終了させるというならば私が原因で
> ある以上私がプロジェクトを引き継ぐことは無いです。
逆に、原因を作った以上責任をとって引き継ぐという考え方もあるのでは。
ムリにやれとは言わんが。
0696421
04/12/16 22:22:10ID:ygQuE+6t> ・500行以上のファイルはそれだけでイライラします。
個人的には1000行までならOKかなと思っていますが、確かにlibkita内のコードが肥大気味なのは
気になるところでした。とはいえ*Manager系はマネージャーという性質からある程度大きくなるの
は仕方ないかなあと。ただkita_misc.cppは一般関数とパース系の関数に再分離した方が良かった
かもしれませんね。
残りは問い合わせに対する返答です。
> FavoriteThreads::readFromXMLから辿ってThread::setThreadName()で落ちますね…。
これは事実上廃止されたKita::Thread::getByURL()を使ってポインタを取ってるのが
原因ですので対処自体は楽だと思います。
> ・External/お気に入りは似たような感じなので一つにまとめた方がいいと思います。
別にしてるのは理由があるのですが、下の方で書きます。
> ・フォルダだけ編集可能なのが分かりにくい(2chの板も編集出来ますね)。
> ・スレッドも統合した方がいいですね。そこらへんはやります。
この辺は私も気になっていたので修正しました。
> > 古いフォーマットのXMLでも保存するようにして解決しています
> ディレクトリサポートするなら古いフォーマットと互換性がなくなるので無理にやらなくてもいいかと。
ここは私も迷っていたところで、古いフォーマットに変換しなくてよいならコード量も
減って良いと思います。
> ・dirのopenは0/1でなくtrue/falseにしてください。
これは数箇所変えるだけで対処できます。
つづく
0697421
04/12/16 22:24:07ID:ygQuE+6t> ・ぱっとコードを見た限り大丈夫だと思うけど、url以外は必須項目でないようにしてください
External/お気に入りが別になってる理由にも関わるのですが、xmlには2種類あって、板登録に使う
xml(boardview_main.xml, boardview_external.xml)は登録時に板名が必要になるためnameも必須
項目になります。それ以外はurl以外は必要ありません(nameはエイリアスになる)。以上の理由から
External/お気に入りを同じにする場合には「登録する」という項目も必要になるためとりあえず
External/お気に入りは別にしました。
> ・登録時にファイルに書き込みした方がいいと思います。落ちたときにorzにならないために。
セーブはどのタイミングが良いかは模索中でとりあえず登録時、クリック時が良いかなと思います。
> あと今更ですが、BoardDataがThreadのリストを持ってる構造になってますが、これはやめてください
> ThreadManagerみたいなのを作れば十分でしょう。
ThreadManagerではDatManagerと被るのでThreadCacheManagerの方が良いと思います。
ここもかなり悩んだ部分で、最初はThreadクラスを上で言ったように構造体に格下げして、
ThreadManagerを新設してそこで一括管理しようと思っていたのですが、BoardManagerで管理
すれば移転の問題はとりあえず考えなくても済むし、検索も早くなると思って今のように
しました。ただ思ったよりも検索が早くならなかったのと、コードが煩雑になりすぎたのと、
そもそもBoardManagerでThreadを管理する事に違和感を感じてたので突っ込まれたら直そうと
思ってました。
>>695
確かにそうとも考えたのですが、中の人の心情を考えるとそれは無理です。
0698紛らわしい2ctboU/x
04/12/16 22:46:03ID:4N1B5iqj0699kitaの中の人 ◆KITAulkOso
04/12/17 00:38:43ID:kFwSghsY昨日と内容はかぶります。
・一年前は一週間に一度リリースしてたんだなぁと今更ながら驚きました。
・今のKitaにどんな機能があるか把握してません。これは何とかしたい。
・開発をやめることはないと思います。今止めたら自分も含めて不幸になるだけなので。
・毎月リリースにこだわり過ぎてた気がします。プレッシャーがかかるんですよね…。
リリーススケジュールは一旦見直します。不定期かもしれないし、2ヶ月ごとの肉の日かもしれない。
・CVSは>>657まで当たった状態なのですが、安定していてしかも
スレ表示が高速化されているのでこれはリリースしたいんですよね。
>>677に入っているバグ修正だけ当ててリリースしたいのが本音。
・パッチの受付方針は確実に変えます。機能追加とバグ修正/リファクタリングが
混ざってるコードは却下か少なくとも採用率が低くなります。複数のバグ修正はOKか？というのは
結局個別判断になりますが、分からなければこちらが質問するパターンになると思います。
あと、こういうときのためにBug Tracking System使った方がいいかもしれませんが、どうですかね？
>>690
> 「言えば済む」程度の些細なことに見えます。
いやぁ、それが性格上なかなか出来ないんですよね…。
言わないと今回みたいに問題になるのは分かっていても。
>>692=691さん
これはcommitしてしまった自分も悪いですね…ごめんなさい。
正直このあたりのコードは全然把握してないので、
どうするかは421さんと話し合ってくれると助かります。
つづく
0700kitaの中の人 ◆KITAulkOso
04/12/17 00:43:42ID:kFwSghsY前の2つについては1.0 branchを切って対応しようかなと思ってます。
Codeについてはそもそも話し合い不足の気がするので話し合いを増やす方向で。
>>677のパッチについては先のコメントでも書きましたが、
機能追加とバグ修正が混じってるのと、ファイルのreplace(次のコメントで書きます)
があるので分割してください。時間がない場合はそのままにしてくれれば
必要な箇所だけ引っ張ってきて入れる予定ですが、その場合いつになるかは分からないです。
以下421さんへのコメント。
>>693
> まず実装ありきのラウンドトリップ型で開発を進めた方が話が早いと思っていたため
codeやUIはまだしも、ファイルはまずいと思います。実際互換性で揉めたわけですし。
ただこれはbranch切って開発版を分ければいいかなとは思います。
> sf.jpのアカウント
これは自分の認識と違ってて、421さんは実質共同開発者という認識です。
コミッタにならない選択でも構いませんが、その場合はパッチの作り方は変えてください。
そもそも自分が勝手に「コミットしなければいけない」と思い込んでた気もしますが…。
>>694
> それとThreadIndex::loadIndex,saveIndex廃止というのは今
> 始めて聞いたような気がするのですが・・・
これは誤解を招く表現でしたが、「ThreadIndex::loadIndex,saveIndexの引数で
Kita::Threadを使わないで欲しい」ということです。
つづく
0701kitaの中の人 ◆KITAulkOso
04/12/17 00:46:14ID:kFwSghsY> ファイルのreplace
やっぱりreplaceはだめです。理由を挙げると、
・パッチのサイズが問題でなく、元のコードがなくなるのはプライドを傷つけます。
・多少サイズが大きくてもdiffの方がコードレビューしやすい。
・そもそもdiffの方が大きくなるということは、複数の修正が入ってしまってるので、
別々のパッチにすべき。
>>696
500行というのはかなり暴言だった気がします。ごめんなさい。
ただ、執拗にコードの品質にこだわるのは理解してください。
(理由は察してください…)
あとkita_misc.cppは結局単体で完結している関数なのであまりサイズは気にしないです。
BoardManagerがやっぱり一番気になります。ですがすぐにどうしろという話はないです。
とりあえず今すぐに何とかしたいのはタブですね…これは1時間あれば出来ますが…
土曜日の昼あたりにやるかなぁ。
0702login:Penguin
04/12/17 00:52:15ID:Jc0ucoTd>>693
> 一度目を通してチェックしてもらいたい、
チェックしてもらった方がいいとことそうでないとこの区別くらいつくっしょ。
ノーチェックでも問題なさそうなとこまで
中の人氏の手をわずらわせるってのはどうなのよ。
> 好き勝手に作るよりも方向性を示してもらってそれに沿って作って行きたい
コミッタになってもそれは可能でしょ。
0703login:Penguin
04/12/17 02:07:49ID:pgnUlbM+とりあえず (*´∀｀)ﾎｯ
0704421
04/12/17 03:05:54ID:06WWdl93にして寝る前に少しだけ。
まず今回の騒動は話し合いもせずに性急に事を進めすぎた自分が悪いです。上で
理由を書きましたが、来月中旬あたりからコードを書く時間があまり取れなくなるため
コードフリーズ日までに行けるとこまで行こうと少し焦っていたのだと思います。
それで来月以降は新規に大規模なコードを起こすよりも、デバッグのパッチや小さい
パッチを書いたり、
> ・今のKitaにどんな機能があるか把握してません。
実は自分も把握しきれてないので、readmeやFAQを書くとか各クラスの仕様を書く
とかの後方支援の方にウェイトを移そうと思っていました。それを予め言っとけば
良かったのですが、個人的な話だったものでつい言いそびれてしまいました。
ちなみに先週末にいなかったのは転勤先にあいさつや住居探しに出かけていたから
だったりします。
それともう一点だけ。多分今回の騒動の原因の根源だと思うのですが、
> ・パッチのサイズが問題でなく、元のコードがなくなるのはプライドを傷つけます。
この辺は自分でも良くないなあと思っているのですが、(多分お気づきだと思いますが)
私は割とコードに愛着を持っていないタイプの人間なので自分とか他人のコードとかを
区別せずに平気で改変したり削ったりします。この前の高速化パッチも2ヶ月かけて書いた
コードを2,3日で書いたコードに差し替えてますし・・・。まあ逆に自分のコードが削られたり
改変されてもあまり気にしないという利点(？)でもあるのですが、これも自分がコミッタ
とかプロジェクトリーダには絶対向かないなと感じてる理由の一つかもしれません。
0705login:Penguin
04/12/17 03:20:35ID:pgnUlbM+0706login:Penguin
04/12/17 08:26:20ID:yosA87Y1File->Load board list をしたとき、更新のある板が多い場合、
その次の次あたりに出てくる更新のある板一覧のウインドウが、
画面下をはみだして、ずっと下まである感じで、そのウインドウを
閉じることができません。スクロールもできなず、おそらく下の方に
OK とか確認でもあるのかと思い Enter でも押してみたのですが
閉じることができません。
もし、お暇なら改善でもしてもらえたらうれしいです。
0707login:Penguin
04/12/17 08:52:31ID:bAb0ZHzXALT押しながらグリって上にズラす。
ってそういう問題じゃないか。
0708login:Penguin
04/12/17 14:38:28ID:6se+y8n+C++もQt/KDEもサパーリわからんので、手助けはできない。
つーか、日本中でKDEのアプリ開発出来る人って何人位いるんだろ？
0709login:Penguin
04/12/18 15:43:14ID:sThLm87rしばらくこのままでも不満はありません。
Windows のときは OpenJane を使っていますが、
kita は既にこれに比肩するものだと思います。
というか、Linux における OpenJane 的なものをずっと
探し求めていました。kita 登場以前〜kita 黎明期のころは
わざわざ VMware 起動して、仮想マシンの中のWindows で
OpenJane を使ってました。
同等の使い勝手となった現在ではもうしませんが。
いちユーザーの立場からいえば、これ以上の機能追加、
OpenJane よりも多機能になるのは、望むところではありません。
されたとしても使わないと思います。
お疲れさまでした。ありがとう。
0710login:Penguin
04/12/18 17:49:31ID:GkugkQkI自分とこでもでかいダイアログがでてEnterで閉じれず、強制終了させた。
次回起動から、毎回同じ板の更新通知が出る。
0711421
04/12/18 22:12:45ID:sDw6JatMとりあえずバグ報告への返答から
>>706,710
それは私の設計ミスで、数行程度の修正で直るので明日あたり直します。
とりあえずダイアログが大きくて下のOKボタンが見えないときはTabを一回
押してボタンのフォーカスをOKに移してからEnterを押してください。
本題に入りますが、中の人がプロジェクトを続行するならば、私も無責任に
プロジェクトから抜けるということはありません。ただ、今回の反省もこめて
次のようなガイドラインを考えてみたのですがどうでしょうか。私も今後は
このガイドラインに従ってパッチを上げるつもりです。
パッチのコミットまでのガイドライン
(1) 基本的にパッチは誰からでも受け入れるが、必ずパッチに関して説明をおこなうこと
(2) 新機能の場合は1パッチに1機能、デバッグの場合は2,3つ程度に抑える
(3) 改変の行数が数行〜数十行程度と小さい場合は事前予告なしでアップしても良い。ただし
なるべく事前予告すること
(4) それ以上の場合は事前にパッチの内容とその時点で影響があると予想されるクラス名を
挙げて他の開発者の了承を得てから開発を始めること。新機能追加の場合はユーザーにも
その機能が必要か意見を求める
(5) パッチがアップされたら開発者間でレビューをおこない、修正またはリジェクトをおこなう
(6) 最終的に中の人が判断してコミットする
つづく
0712421
04/12/18 22:16:25ID:sDw6JatMコメントや異存は無いという部分です。
> 毎月リリースにこだわり過ぎてた気がします。
私的にはフィーチャーフリーズ日までの期間が短かったのが気になるところでした。
リリース日〜フィーチャーフリーズ日が短期間だったため、その間に一気にパッチを
書いてアップする必要があったので・・・
> どうするかは421さんと話し合ってくれると助かります。
埋め込みパートの部分は以前削除するかと打診したときに反応が無かったので
削除する方向でいたのですが、>>691氏が残して欲しいと言うならば残します。
> そもそも話し合い不足の気がするので話し合いを増やす方向で
問題点はお互いがいま何をやっていて何をする予定なのか分からないことだと
思うのでこちらからももう少し打ち合わせを密にすることをお願いしたいです。
責任転嫁をするわけではありませんが、今回の騒動でもプロトタイプ案を出したときに
一言少し待ってと言ってもらえれば待ったのですが、数日反応が無くてこちらから
どうですかと催促する訳にもいかず、そのうちある程度の形が出来てしまったので
チェックポイントとして先走ってパッチを出してしまったという経緯があります。
つづく
0713421
04/12/18 22:20:26ID:sDw6JatM> 機能追加とバグ修正が混じってるのと、ファイルのreplaceがあるので分割してください
バグ修正部分は割と排他的な部分なので簡単に分離できますので分離しておきます。
機能追加部分は一気にやらずに段階的に分けてやることになると思います。とりあえず
上で言ってたThread(Cache)Managerの部分からかな・・・。Kita::Threadはデータ
ベースの実体としていずれただの構造体に格下げにする予定です。
> ThreadIndex::loadIndex,saveIndexの引数でKita::Threadを使わないで欲しい
クラスの結合度の問題もありますが、ポインタ渡しはセグフォの危険がありますしね・・・。
Kita::Threadに限らず、スピードが必要ない部分ではコードが冗長になるとしても基本的に
関数へはポインタ渡しではなくて値か参照渡しを使用することにします。
> BoardManagerがやっぱり一番気になります。ですがすぐにどうしろという話はないです。
BoardManagerの肥大は私も気になるところなのでスリム化を検討してみます。
0714kitaの中の人
04/12/19 00:11:13ID:C6KKHIagなのでトリップなしですが、作業が重複しないようにしたいので。
>>713
バグ修正のうち２つは677のパッチから抜き出して
CVSにcommit済みです。1つ(からむのサイズが保存されない問題)
は同様に修正中ですが、optionが必要かもしれないので
まだcommitしてません。
あと機能追加についてはUIをどうするか悩んでいるので
パッチを作成しても次のバージョンには入れないつもりです。
421さん他にはお手数をかけると思いますが、
xfree86やthunderbirdみたいにはしたくないので
なるだけ考慮しますのでよろしくお願いします。
0715login:Penguin
04/12/19 00:25:21ID:g7lO/Qd0やっぱkitaって(・∀・)ｲｲ!!
0716421
04/12/19 00:37:16ID:wlRqxRzWこっちも多分明日の昼間では脳が使い物にならないので全然作業
してないためバッティングはしてないです。UIの件は了解。明日は
とりあえず>>706,710対策をする予定です。
0717login:Penguin
04/12/19 10:07:03ID:oGcA5ka20718421
04/12/19 14:00:04ID:7LnV2u96これから外出するので手短に。
中の人はどう思っているかは分かりませんが、少なくとも私は
IRCやMLみたいに閉鎖的な「ほげほげコミュニティー」につながる
ようなコミュニケーション手段を好みません。2chの掲示板みたいに
通りすがりの人でも気軽にコメント(時には煽りとかも)を書き捨て
られるようなオープンな環境が好きなもので。
かと言ってこのスレだけで開発を進めても話題が分散するし、wikiも
決定事項をメモるのには良いけど議論するには向かないので、外部に
開発用の板を作るってのもひとつの手ですかね・・・。極端な話、クラス別に
スレを立てることも出来ますし。
0719kitaの中の人 ◆KITAulkOso
04/12/19 16:15:35ID:R5OKXlxx基本的にはそれでいいと思いますが、
自分が作成したパッチをcommitする場合も同じようにするのかなという点です。
もちろん大きな変更についてはあらかじめ予告＆相談しますが、
割と細かい変更(ファイルの整形やリファクタリング)もあるので、
ある程度は自由にやりたいのが本音です。
もちろんそれで問題が出た場合、例えばパッチの不整合があった場合は
こちらに責任があるので調整する予定です。
# でもパッチは作っておいた方がrejectするときにも楽なのでいいかな。
# ちょっとここは考えがまとまってないです。
>>712
> 問題点はお互いがいま何をやっていて何をする予定なのか分からないことだと
> 思うのでこちらからももう少し打ち合わせを密にすることをお願いしたいです。
そうですね。本当はWikiに書くはずだったんですが、あちらの方は更新してないので…。
やっぱりこのスレ(か別に板を立ててそのスレ)で書いた方が良さそうな気がします。
> 今回の騒動でもプロトタイプ案を出したときに
> 一言少し待ってと言ってもらえれば待ったのですが
個人的に忙しくてパッチを試す暇もなかったのですが、
2chへの書き込みは出来る環境だったので、少なくともそれは伝えるべきでした。反省します。
717,718へのコメントはまた後で書きます。まだ眠い…。
0720login:Penguin
04/12/19 19:39:35ID:oGcA5ka2開発者同士の緊密なコミュニケーションが必要ということを言いたかったのです。
コミュニティの一つとしてwikiも結構ですが、開発者の間には
プッシュ型的な情報交換機構(IRC,MLなど)があるべきだと思っています。
# 外野が出しゃばって申し訳ありません
0721421
04/12/19 23:00:26ID:7LnV2u96前から付けようと思ってた画像ビュワーのドラッグスクロールのコードも
書く予定。あわせて1,2時間くらいあれば書けるかな・・・
>>719
> 自分が作成したパッチをcommitする場合も同じようにするのかなという点です。
これは流れのパッチ書きみたいに非コミッタに適用するガイドラインなので
コミッタは自由にしてよいと思いますが、小さい作業ならともかく、大きい
作業の場合はバッティングすると悪いので作業前に何をするか簡単に言って
もらえるとありがたいです。
> やっぱりこのスレ(か別に板を立ててそのスレ)で書いた方が良さそうな気がします。
>>720氏への返答にもなりますが、wikiは2,3日更新が無いとチェックをサボる
ようになるので情報交換には向かない、IRCはお互い仕事持ちなので時間を合わ
せるのが困難、MLはぶっちゃけるとMLというシステム自体が持つ閉鎖性が嫌い
なので、やっぱり外部板が現実的な選択な気がします。Kitaの板一覧の一番上に
でも表示するようにしとけば誰でも読み書きできますし。
0722421
04/12/19 23:43:06ID:7LnV2u96KMessageBox::informationListを使って更新した板名を表示するようにしただけ。
というか移転が多い場合は何げに致命的な不具合ですね・・・。現バージョンで
ダイアログが大きくて消せないという人はTabを一回だけ押して隠れてるボタンの
フォーカスをOKに移してからEnterを押してください。
ttp://www.geocities.co.jp/SiliconValley-Bay/7435/patch-1219-1.txt
0723421
04/12/19 23:50:47ID:7LnV2u96いちいちスクロールバーまでマウスを移動するのが面倒だったので。
void KitaImgView::contentsMouseMoveEvent()でマウスが動くイベントを
フックして画面をスクロールさせてるだけ。QScrollView::scrollBy()
という関数があったので意外に簡単でした。
ttp://www.geocities.co.jp/SiliconValley-Bay/7435/patch-1219-2.txt
0724login:Penguin
04/12/20 01:43:01ID:X3g/kOyx乙。
0725kitaの中の人
04/12/20 03:05:19ID:EGxl8Fk9とりあえず>>717-718は自分としても外部板で対応したいと考えてます。
詳しくはまた明日あたりに…。
0726login:Penguin
04/12/20 07:48:27ID:CwOocf8Zまぁ、まったりいきましょう
( ・∀・)つ旦
0727login:Penguin
04/12/20 07:53:23ID:CwOocf8Z>>722のパッチでは、>>710の
>次回起動から、毎回同じ板の更新通知が出る。
も直ってるのかな？ウチでも出てるんで。
0728727
04/12/20 08:01:14ID:CwOocf8Z出るのは、「市況1」と「市況2」の2つ
0729login:Penguin
04/12/20 12:20:24ID:kI2eY6VL検索機能についての質問なのですが、".config"を検索したかったので、
".config"と入れたのですが、"."の部分が任意の一文字に置き換わって
検索されますね。"\.config" とするとうまくいくようです。
これは仕様ですか？
0730729
04/12/20 12:29:12ID:kI2eY6VLうまく検索できないようです。
0731login:Penguin
04/12/20 22:06:25ID:Oy6kZu930732421
04/12/20 22:14:55ID:8nCovuJh今のところは面倒でもkitaを終了してから.kde/share/apps/kita/board_list
を開いて
item22=http://live14.2ch.net/liveplus/,ニュース実況+
item23=http://live19.2ch.net/livemarket1/,市況1
item24=http://live19.2ch.net/livemarket2/,市況2
item25=http://live13.2ch.net/livemarket1/,市況1
item26=http://live13.2ch.net/livemarket2/,市況2
となっていたらitem25,item26の行を手動で削除してください。
原因はちょっと上の方で話題にしていたKConfigの問題で、カテゴリ内の
項目数が減っても板の設定ファイル(board_list)内に既に存在するitem*
の行が消えないために起動時に板が移転したと誤判定します。そのうち
板の設定ファイルがXML化されれば直ります。
>>729
デフォルトで正規表現で検索するので(も\(で検索して下さい
0734kitaの中の人 ◆KITAulkOso
04/12/21 01:27:27ID:iBHoWzChmerged. これくらいのサイズだとやっぱり分かりやすいですね。
>>710>>727>>732
ああ、ごめんなさいorz
確かにKConfigを使ってるのが原因です。
(ちなみに>>664の最後の2行で書いたのはこのこと)
回避方法は>>732に書いた通りですが、ばっさりboard_listを削除した方が早い気もします。
板更新をしないと起きない現象ですし。
あと根本的にはXML化が必要ですが、今度同じ問題が起きても大丈夫なように
以下のパッチのように書き込み部分をKConfigの代わりに
KSimpleConfigにしようと思うのですがどうでしょう？
(再現条件が面倒なのでテストしてませんが…)
http://kita.sourceforge.jp/patches/boardview_1221.patch
0735kitaの中の人 ◆KITAulkOso
04/12/21 01:46:39ID:iBHoWzCh自分としては、
・IRC: 入っててもログを見ない可能性大。
あとよく閉鎖的と言われて叩かれるのを見かけるので重要な話には向いてないかなと。
・ML: 堅苦しいので苦手。あと最近SPAM多すぎて見るのも大変orz
あとおまけ。・IM(not Input Method): アカウントすらない
プッシュ型というのはそれほど本質的ではないような気がします。
自分の場合はMLは入っててもほとんどみないし、逆にこのスレは基本的に毎日1回は見ます。
なので個人的には2ch形式がいいです。
ただ、緊密という意味だとこのスレだと細かい話はやっぱり書きにくいし、
KitaスレでLinux板を埋めるわけにはいかないのでｗ、外部板を立てるつもりです。
ただ、今開発してるのが2chブラウザだからこういう形式がいいなと思ってるのもあるので、
全く別のプロダクトを作るとしたらMLをメインにするかもしれません。
0736kitaの中の人 ◆KITAulkOso
04/12/21 01:55:43ID:iBHoWzChあと>>714のUIについての考えはたぶん数日後に。
>>721
了解です。多分大きな変更とか
外部仕様が変わるとかいう時にはあらかじめ書くつもりです。
0737login:Penguin
04/12/21 09:31:28ID:QWquiNQiせめてスレビューと同じフォントを使ってほしい。
書き込みドックのところもかな。
0738421
04/12/21 22:22:53ID:9V6mwTza時間は1,2時間ってところで、DatInfo, KitaDomTreeクラスのあたりを触ります。
・・・みたいに、今後は出来るだけ作業前に作業内容を簡単に見積もって連絡する
癖をつけようと思ってます。
>>734
> KSimpleConfigにしようと思うのですがどうでしょう？
試してみましたが効き目無かったです(相変わらずitem25,26が残る)
ざっとKSimpleConfigのソースをみた限りでは既存の項目の削除は行わないっぽいです。
ところで移転した板が多いとお知らせメッセージボードがいっぱい出てエンターを
連打するのがちょっとウザいのでメッセージボードは出さない方が良いかも。
0739kitaの中の人 ◆KITAulkOso
04/12/22 00:00:36ID:XVvu/MUsすんません、>>732のようにitem25,26を削除した上で、
もう一度同じ現象が起きないようにするという意味です。
KSimpleConfigだと設定がマージされないのでKConfig使うよりはマシだと思うので…。
ちゃんと再現させた方がいいのかな。
0740421
04/12/22 00:28:25ID:r+gIWIGFそれだと今度はカテゴリ内のアイテム数が増えたときに問題あるような気が。
いや、KSimpleConfig使ったこと無いので良く分からないで書いてますがw
で、>>673対応パッチ。追加行数は50行くらいで済むかなと思ったけど grep "+ " | wc -l
してみたら90行でした・・
ttp://www.geocities.co.jp/SiliconValley-Bay/7435/patch-1221.txt
kitaで-p0。変更は kitaconfig.{h,cpp} datinfo.{cpp,h} kitahtmlpart.cpp kitadomtree.{h,cpp}
流れはこんな感じ。
(1)Accessクラスから行データが送られてきたらDatInfo::copyOneLineToResDat()で
すぐさまパースしてアンカーリスト(AncList)を作ってリストの範囲内のレスの、レスされてる
ことを示すパラメータ(RESDAT.isResponsed)をtrueにする
(2)レス描画の最後にKitaHTMLPart::updateScreen()が呼ばれたらそこから
KitaDomTree::changeColorOfAllResponsedNumber()を呼ぶ
(3) KitaDomTree::changeColorOfAllResponsedNumber()で
KitaDomTree::changeColorOfNumber()を呼んで番号に色をつける
(4) KitaDomTree::changeColorOfNumber()ではレス番号のAノードに
coloredLink というクラス名を付ける。KitaConfig::defaultStyleSheetText()で
色を設定している(a.coloredLink:linkのとこ)
色はとりあえずの暫定的なもの。それとデフォルトでこの機能をONにするかどうか
(KitaConfig::defaultCheckResponsed)悩み中。やっぱりレスポンスが若干落ちるので。
それと次のリリース版が出るまでしばらくは新機能のパッチじゃなくてデバッグの
パッチに集中する予定。
0741kitaの中の人 ◆KITAulkOso
04/12/22 00:57:39ID:XVvu/MUsとりあえずkitasubjectview.{cpp,h}とあとkitaconfig.{cpp,h}で合計20〜30行の予定。
ただ週末まで作業出来ないかも。
>>723
merged. 中クリックでもドラッグ出来ますが、これは仕様と言うことでいいでしょう。
右クリックは問題ないですね。
>>740
ありゃ。そうでしたか。KSimpleConfigはbackendまでは見てないですが、ドキュメントを見る限りでは、
KConfigは既存のファイルがある場合はそれとマージして、
KSimpleConfigはファイルがあろうと新規作成するようなイメージがあります。
乱暴な言い方をすると、KConfigがfopen(file, "a"), KSimpleConfigがfopen(file,"w")みたいな感じ。
で、KitaBoardView::downloadBoardList()では板リストをを解析して
categoryListに一旦格納して、その内容をboard_listファイルに格納するので、
「board_listの中身＝＝ダウンロードした板リストの解析結果」となるはずなので多分問題ないかと。
# 何か勘違いしてるかもしれませんが酔っぱらいなので勘弁。
0742421
04/12/22 01:43:09ID:r+gIWIGFcontentsMouseMoveEvent()ではe->button()は常にNoButtonを返すので
そうなりますが、明日あたり直すかも。
> KConfigがfopen(file, "a"), KSimpleConfigがfopen(file,"w")
私の勘違いで、まじめにソースをみたらその解釈で良いみたいです。でも
KSimpleConfig config( configPath );の段階でitem25,26が既にメモリに
ロードされてるのでdeleteEntryしないとそのままitem25,26が書き出される
という問題が。
■ このスレッドは過去ログ倉庫に格納されています