こんなの作り始めました

しばらく前から色々考えていたんだけど、とりあえず
動くものが無いと話が進まないかと思い、こんなのを
作りはじめた。



どんな感じで作ろうかという方針が自分の中では大体
決まってきたので、まずは画面のデザインから；

要は vine のリポジトリには無い外部のアプリケーションを
容易にインストールしやすくする画面。

これがうまく動くようになったら、OOo のように Project 外
で使えるものがある時はそちらを使うようにして、できるだけ
開発リソースを本体に集中したいなと。

# でも今日はもう寝る。

コメント 6

私は似たようなものを zenity で考えています。

GUIフロントエンドがあれば嬉しいものは？
http://groups.google.co.jp/group/vine-linux-develop/browse_thread/thread/f8443edbd92ccc96#
に、サンプルイメージとして投稿したのですが、
これは何の言語で書いているのですか？
もし可能でしたら、オフィスとかマルチメディアなどの
タブをつけて選択できるようになれば、
外部アプリケーションを含む、
主要なおすすめアプリケーションを
お手軽にインストールできるフロントエンドになりますね。

上記より抜粋：
> [システム] -> [システム管理] -> 主要アプリのインストール
のイメージと申しますか、こんなんんです。
http://f.hatena.ne.jp/munepi/20081116202902
zenity で作りました。まだ中途半端なのと、記事にしていないので、
イメージ画像だけでっちあげました。
こういうのって嬉しいか嬉しくないかなのですが、
作っている私自身にとっては、
すべてシェルスクリプトで済ますので、恩師は何もありません。
しかしながら、膨大な synaptics の海で、
何もオススメ度の強弱が無いよりかは良いと思っていますし、
それが作ってみようと思っている動機です。
by munepi (2009-02-02 09:38) 

gambas2 で書いてます。

実は私も最初 zenity でできそうかなと思ったんですが、どうせならインストール/アンインストールだけじゃ無くてアップデートにも対応させたいとか、見た目も少しは見栄えが良いものにしたいとか考えていたら、ちょっと厳しく思えてきたので gambas2 に switch しました。

で、gnome-app-install みたいに主要アプリケーションとセットで扱えるようにするというのも考えてみたのですが、
・apt/rpm 管理とそれ以外が混在すると複雑になりそう
・apt-get update でアップデートが確認できるものとできないものが混在することによってユーザーが混乱しそう
・「外部」アプリであることを明確にしておいた方が良さそう
といった辺が気になったので敢えて外部アプリケーションに特化した感じで作業を初めています。

by kazu (2009-02-02 17:18) 

確かに zenity は見た目に欠けるので，
こちらの方が良いですね．
gambas2 は全く無知ですが，
たしか Basic ライクな言語でしたよね？
簡単に理解できそうでしたら，私もかじってみます．

これは考え方と申しますか，
管理の方法の違いなのかもしれませんが，
外部アプリケーションを取得し，インストールし，
微調整も，さらにアンインストール時の処理も，
このフロントエンドの裏で処理されるのでしたら，
私ならそれらの処理はやはり rpm を作って，
すべて rpm で管理するというのが好みです．
アップデートに対しても rpm ならば，
パッケージを用意しておけば，問題ないと思います．
すでに self-build というのがありますので，
外部アプリケーション用に別の名前を用意すれば，
「おすすめデスクトップアプリケーション」として
1つのフロントエンドで済みます．
私個人的には，できれば一つでおすすめデスクトップ
アプリケーションがすべて済むアプリケーションの方が
嬉しいです．いかがでしょうか?
by munepi (2009-02-02 20:30) 

いやー、おっしゃりたいことはすごーーーーくよく分かります。
私もかなり悩みましたから^^。

ただ self-build って仕組みを考えている時に苦しかったのは、
・apt (という rpm)のトランザクション中で別の rpm をインストールできない(当たり前ですが)
・インストール中にインタラクティブな対応を取るのが難しい(Xの有無を判定したりすれば可能でしょうが面倒かなと)
・何より誰かが self-build-*.spec を維持/更新し続けないといけない。
ですね。

で、特に3番目のやつをなんとかできないかなと色々悩んだ結果、今回は別の仕組みに挑戦してみようかと思った次第です。

でも munepi さんのおっしゃる方向性も理解できるので、まずは外部アプリのインストールから始めますが、後で別アプリケーションも対応する、なんてのもありだと思うんで、気長に見守ってもらえると助かります。
by kazu (2009-02-03 12:59) 

いえ，私もこの手のことは，すでに Windows に作成していた TeX に特化した某ネットインストーラーを作成していた時代から，この手のものについてずーっと悩んでいますので，ハラダさんの実装している方向も十分に承知しているつもりです．

> ・apt (という rpm)のトランザクション中で
> 別の rpm をインストールできない(当たり前ですが)
そうなんですよね．私もこれについてなんとかならないかと思っていて，結局のところ，別途 self-build 用にパッケージ管理システム(Gentoo Linux の Portage のようなソースビルドに特化したパッケージ管理システム)を作ってあげないといけないのかなという考えに至っているんです．

つまり，self-build のビルドや rpm ビルドまで管理できれば，あとは apt まかせで自動的に /var/ のどこか忘れましたが，self-build によってビルドされた rpms がインストールされるので，そういったことができるシステムをつくれば，rpm をビルドするまでは，apt の rpm トランザクションは解放されますよね．

> ・インストール中にインタラクティブな対応を取るのが
> 難しい(Xの有無を判定したりすれば可能でしょうが面倒かなと)
%post での処理なので interactive な処理は厳しいですね．

私も動作テストや外部アプリケーションへの対応がプラグイン方式ならば，でご協力できることがあれば，お手伝い致します．
と同時に，私も今 Python + gtk2 で作ろうと思い始めています．

プロトタイプができるのを楽しみにしています！
by munepi (2009-02-03 13:28) 

方向性を理解してもらえていて良かったです。

> (Gentoo Linux の Portage のようなソースビルドに特化した
> パッケージ管理システム)を作ってあげないといけないのかな
> という考えに至っているんです．

それも面白そうですねぇ。
kernel module なんかだと dkms みたいにクライアント側で自動的にコンパイルする仕組みもある用ですし、うまく apt/rpm と連動できればとても便利なものになる気がします。

> 私も動作テストや外部アプリケーションへの対応がプラグ
> イン方式ならば，でご協力できることがあれば，お手伝い
> 致します．
> と同時に，私も今 Python + gtk2 で作ろうと思い始めてい
> ます．

よろしくお願いします。

色々試してみて使い勝手の良いものを提供できるように頑張りましょう！
by kazu (2009-02-03 21:46)