trash-0.0.1

Linux で端末から trash というコマンドでファイルをゴミ箱に捨てるアプリを新規公開。
いや自分で使いたかったんで、ちなみに中身はコレだ。

Linux でファイルをゴミ箱に捨てる

たったの 19 行w
man も pydoc も絶対にイラネェw
なんと親切なことにインストールスクリプト同梱w
GNOME だけでなく Mandriva KDE でもわざわざ動作確認済みw

Linux ゴミ箱を日本語で検索すると結構ヒットするんだけど…
g_file_trash を日本語でググってもウチしか当たらないんだが…

つーか Linux アプリを更新してもアクセス数は全然カワンネェwww
私は方向を間違えたのだろうか…

IronPython CRLF

Glade の覚書がちっとも進まない。
やっぱり普段使わないものの覚書って無理があるかも。
ということで Blog でやった IronPython ネタを地味にまとめている。

覚書のページ – L’Isola di Niente

つまりほとんどコピペ、でコードが IronPython 2.6 でキチンと動くか確認してみたんだが
IronPython の \n が CR/LF になるんだが…
以前は LF のみだったような気がするんだけど違ったかな。

追記

まてよ、もしかして System.IO と組み込み open では扱いが違うのかな?
というより IronPython では内部で \n はどう保持されているんだろう?
気になったのでテストコードを作って試してみた。

# -*- coding: UTF-8 -*-

import System

crlf_test = "a\nb"

# Inside is \n==LF
bytes = System.Text.Encoding.UTF8.GetBytes(crlf_test)
for i in range(len(bytes)):
    print bytes[i]

# The following code is \n==LF write
sr = System.IO.StreamWriter("test1.txt")
sr.Write(crlf_test)
sr.Close()

# The following code is \n==CR/LF write
f = open("test2.txt", "w")
f.write(crlf_test)
f.close()

やはり open() で書き込む時にのみ LF を CR/LF に変換しているようで。
標準 Python モジュールの関係あたりで CPython に無理やり合わせたのだろうと憶測。
以前は LF のみだったような気がしたのはコレに気が付かなかっただけかな。

ついでだから C# での内部も一応探ってみる。

using System;

class Program
{
	static void Main(string[] args)
	{
		System.Byte[] bytes = System.Text.Encoding.UTF8.GetBytes("a\nb");
		foreach(System.Byte b in bytes)
		{
			Console.WriteLine(b);
		}
	}
}

当然のように LF に、つまり .NET Framework なら内部では cli 仕様の \n==LF である。
注意しておかないとハマるかも。

Y901x-0.2.2

Y901x-0.2.2 公開。

button_release_event の callback で

if self.gesture["result"] == "":
↓
if self.gesture["result"] == "" and self.w.get_title() != "":

とチェックの追加をしてみただけなんだがまだテストが足らないかもしれない。
とりあえず現在までジェスチャと右メニューは同時に出なくなったので多分大丈夫だろう。
ついでに FileChooserDialog にフィルタリングを追加して公開してみる。
とにかくトップページつか公開アプリを更新したかっただけさ。

後はフルスクリーンでボタンやシークバー表示を追加すればプレイヤー基本機能は私的に終了。
Cinema(つまり WMP11 のパクリ) みたくバーのみ浮いた表示にしたいんだがどうすれば…
でもアレって GTK+ らしくないかもしれない。

glade

覚書ページの整理が全然進まない。
PyGtk はどの順番で widget 解説を進めるか考えると頭がおかしくなりそう。
TreeView や TextView の前に Scrollbar や Scale の前に Adjustments の知識が必要で…

それより、もう使わなくなった Glade 関連の解説なんかはどうしようかと。
なんたって今では普通 libglade ではなく GtkBuilder を選ぶだろうし。
最初の GUI アプリ作りのとっかかりは Glade ほど解りやすいものは無いだろうし。

いやまてよ。
C 言語から Glade を使う方法てか GTK+ コンパイル方法も併記すればいいんでない。
なんたってソレは私自身もやったことがないので勉強にもなる。

よし Mandriva One に Glade や GTK+ ヘッダをインストールしてみよう。
C でやるには別途でコンパイラの他に GTK+ ヘッダを入れる必要があるんだよね。
Ubuntu での需要ばかりだろうから Ubuntu には後で入れる。

libgtk+2.0_0-devel を導入。
依存関係で他のパッケージも沢山インストールされるが気にしない。

devhelp も導入。
/usr/share/gtk-doc 以下の doc はコレで見られるようになる。
libgtk+ を入れた後はこんな感じになる。

glade も一応入れてと。
んで海外からチュートリアルを探してみたら強烈なとこを見つけた。

GTK+ and Glade3 GUI Programming Tutorial – Part 3

とにかく tutorial.xml を落とし C コードをコピペしてコンパイルしてみる。

普通にコンパイルが通って動かせた。
ふむふむ、C から Glade ファイルを使うにはこうすればいいのか。
しかしこんなトコを見た後では何を書くのも気後れするわ。

でもコンパイルオプションが長くてメンドクセ!
メモリの解放処理をいちいち書かなければいけないのがメンドクセ!
つーかメソッドではなく関数を使うのがメンドクセ!
PyGtk がどれほど楽チンなのか改めて思い知る。

y901x-0.2.1

y901x-0.2.1 を誰も待っていないだろうけど更新しました。

やっと compiz 3D 無効状態でリストサイズ変更グリップラインが崩れるのを修正できた!
3D で使えば問題無いけど実はずっと気にしていた私であった。

def __on_expose_event(self, widget, event):
    # GetDC()(Windows)
    gc = widget.style.fg_gc[gtk.STATE_NORMAL]
    # Draw Vertical Line
    for i in range(10):
        if i%3 == 0:
            widget.window.draw_line(
                gc,
                event.area.x+i,
                event.area.y,
                event.area.x+i,
                event.area.height)

とやっていたのを

def __on_expose_event(self, widget, event):
    # GetDC()(Windows)
    gc = widget.style.fg_gc[gtk.STATE_NORMAL]
    # Draw Vertical Line
    for i in range(10):
        if i%3 == 0:
            widget.window.draw_line(gc, i, 0, i, widget.allocation.height)

に変更したらアッサリと。
つまり引数で渡される event.area から得られる値は 2D 状態ではアテにならないぞと。
widget から直接大きさを調べて計算すれば 2D でも 3D でも対応できるね。

今まで表示されない部分に一生懸命ラインを引いていたってことか、あーあ、早く気がつけ俺。
他にステータスグリップ描写が変な位置になる不具合も同じ理由だった。

他、覚書ページ作りで思いついたことを地味に導入して本サイトにて公開中。
しかし三ヶ月も放置したのに毎月ダウンロード数が地味に増えているのは何故だろう?
といってもたった二百程度なんだが、Linux 専用だし需要は微妙だしこんなものだろう。

どうでもいいけど本サイトトップページのスクリーンショットは取っ払った。
BlackBerry で見てみたら…まぁそういうわけで。
今後はサイトデザインもスマートフォンを考慮したほうがいいかもね。