GNOME用アプリケーションはGnomeFiles.org 33
ストーリー by Oliver
足型のコレクション 部門より
足型のコレクション 部門より
mumumu 曰く、 "GNOME Projectのサーバに侵入された形跡が見つかって以来、GNOME用アプリを配布する中心的な場所が存在しない状態になっていた。その穴を埋めるべく、OSNews LLCが、BeOS用アプリの配布場所として知られているBeBitsをモデルに、GnomeFiles.orgを構築したとアナウンスしている。ここではGNOME用アプリ、もしくはGTK+(とそのbindingも含む)で作られたアプリの登録が可能になっており、サイトオープンから一週間で、150以上のアプリが登録され、3800件を超えるダウンロードがあったという。また、オープン(6/16)から1~3週間の間に、ユーザー登録を行い、一つ以上のアプリを登録した開発者一人に対し、「自分のソフトウェアを広告できる権利」などの特典が与えられることになっている。我こそはと思うGNOMEアプリ開発者は今すぐ登録してみてはいかが。"
風博士 (スコア:3, 興味深い)
未踏プロジェクトにも採用 [ipa.go.jp]され,これからが(も)楽しみなブラウザです.
Re:風博士 (スコア:1)
登録されるのは、来年なんですかねぇ
Re:風博士 (スコア:1)
静止画も動画もシームレスに扱えるので、便利に使わせてもらっています。
このスレ・・ 寂れてるな、兄者(AA略) (スコア:0)
Re:このスレ・・ 寂れてるな、兄者(AA略) (スコア:1)
開発しようという気もうせるのでは。
アップグレードや、アップデートするたびに、日本語入力が
動かなくなるのではと心配しないといけない現状ですからね。
romfffromのコメント設定
AC-2、プラスモデ+3、閾値0、スコアを表示しない(推奨)、高い評価のコメントを親にする
Re:このスレ・・ 寂れてるな、兄者(AA略) (スコア:0)
肉好き作者
Re:このスレ・・ 寂れてるな、兄者(AA略) (スコア:0)
111438 Widget should be recieve key event before mnemonics and sccelerators
前にも書いたけど、このあたりって直ったんでしょうか?
直っていないとしたら、CTRL+Nで新しいウィンドウが開くとかCTRL+Fで検索ダイアログが出てくるとかなどの現象のため漢字入力ができず、少なくとも私にとっては、GNOMEでの日本語入力は大丈夫じゃありません。
Re:このスレ・・ 寂れてるな、兄者(AA略) (スコア:0)
GNOME vs KDE とか、
カーソル移動に矢印キーは邪道とか、
そういう話がしたいのは見え見え。
うざいからやめてちょうだい。
Re:このスレ・・ 寂れてるな、兄者(AA略) (スコア:0)
に対して「全然大丈夫じゃねーよ」って言いたいだけですが。
Re:このスレ・・ 寂れてるな、兄者(AA略) (スコア:0)
> 開発しようという気もうせるのでは。
だったら、そもそもデスクトップマシンにLinuxや*BSDを使う気がしないような気がしますが。というか実際にデスクトップマシンにしてる人が少ないのか。
日本語(だけじゃないけど)入力環境の改善に関してはscim [freedesktop.org]がuimやm17n-libに対応したり、immodule for Qtがfreedesktop.org [freedesktop.org]でホストされたり、あと
Re:このスレ・・ 寂れてるな、兄者(AA略) (スコア:0)
Re:このスレ・・ 寂れてるな、兄者(AA略) (スコア:0)
日本の開発者が増えるには (スコア:0)
とあるVB房がLinux開発環境に抱いているイメージ (スコア:2, 興味深い)
2.VBみたいに簡単にGUI作れるの?
VC++未満のWin32API叩くような感じな気がするけど・・・
そういえば、Kylixとか聞いたけど使えるようにするのは簡単?
3.KDEとGnome、gtkとかqtって何?
そもそも違っても別のLinux環境でも動くの?
4.理想は言語内ですべて済めばいいけど、そうはいかないし。
さて、日本語のAPIドキュメントってあるのか?
MSDNレベルの整理されたドキュメントは欲しいなぁ。
開発環境に統合されてれば最高!
5.IME(FEP)の制御って簡単に出来るかな?
まさかFEP毎に別のAPIをコントロールがフォーカス取得時に
手動で送信とかいう冗談みたいな事はないよね?
6.文字コード意識しないといけないの面倒。
EUCかUnicodeかなんでもいいから統一してくれ。
7.このプログラムは将来的にも一応動くの?
今作ったプログラム、とりあえず5年は動くかなぁ?
ランタイムのバージョンが新しくなって動かなくなって、
ヘルプで時間取られるの嫌だしなぁ。
8.インストーラー簡単に作れないかなぁ?
rpmやdebを自動的に構築。
必要ライブラリもインストールor警告出すようにとか。
スタートメニュー(というかランチャ?)に登録もしてくれよ~
9.このショートカットキーの組み合わせ、
この環境だとOKだけど、別の環境でも使えるんだろうか?
10.そもそも、日本語文字列の処理うまくいくのかな?
左から何文字目とかやったら、
左から何バイトに解釈されてへんな所で切れないだろうなぁ?
とか色々書いてみましたが現状どうなっているやら・・・
あと、言語と環境がごっちゃになっててすいません。
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:2, 参考になる)
> 1.開発HowToが書かれた日本語の書籍は少ない・・・気がする。
あることはあるのですが、古いものばかりですね。
KDE/Qtは2.xから大きくは変わってないので、それなりに使えますが。
> 2.VBみたいに簡単にGUI作れるの?
> VC++未満のWin32API叩くような感じな気がするけど・・・
Qtに関して言えば、Qt Designer [trolltech.com]があるので楽です。
> 4.理想は言語内ですべて済めばいいけど、そうはいかないし。
> さて、日本語のAPIドキュメントってあるのか?
> MSDNレベルの整理されたドキュメントは欲しいなぁ。
> 開発環境に統合されてれば最高!
英語なら充実してるのですが…orz
開発環境との統合については、一応KDevelopからリファレンスが見れたり、
Qtのクラス名を選択して検索などが出来ます(KDEのクラス検索はうまくいかなかった)。
> 6.文字コード意識しないといけないの面倒。
> EUCかUnicodeかなんでもいいから統一してくれ。
Qtの場合内部がUnicodeなので、コードに直接EUCで書く場合は変換する必要があるくらいかな(QString::fromLocal8Bit())。
ファイル入出力はデフォルトで設定されているロケールを利用するのでたぶんOK。
> 7.このプログラムは将来的にも一応動くの?
> 今作ったプログラム、とりあえず5年は動くかなぁ?
> ランタイムのバージョンが新しくなって動かなくなって、
> ヘルプで時間取られるの嫌だしなぁ。
同じメジャーバージョンならバイナリ互換性あったような気がするけど細かい所は忘れた。(3.1.xと3.2.xって互換性あったっけ)
まあ、static linkすれば大丈夫かと。
# ライセンスの話はここでは略。
> 8.インストーラー簡単に作れないかなぁ?
> rpmやdebを自動的に構築。
KDevelopには*.spec作成用のダイアログがあります。
動作が怪しいので使ってないですが(^^;)
> 必要ライブラリもインストールor警告出すようにとか。
rpmの機能ですね。必要ライブラリの依存関係はrpm4から自動チェックしてくれたはず。
> スタートメニュー(というかランチャ?)に登録もしてくれよ~
KDevelopで新規にプロジェクトを作成するとメニューへ登録するためのファイルも作ってくれるはず。
> 10.そもそも、日本語文字列の処理うまくいくのかな?
> 左から何文字目とかやったら、
> 左から何バイトに解釈されてへんな所で切れないだろうなぁ?
そういう酷いのはまずないです。
Unicode ←→ "Shift_JIS"のマッピングとか、フォント関連とか、地雷源は大量にありますが…。
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:1, 参考になる)
> 1.開発HowToが書かれた日本語の書籍は少ない・・・気がする。
VB 等に比べるまでもなく、実際に少ないと思います。
Web のリファレンス/チュートリアルでは不満な人には、厳しいかも知れません。
> 2.VBみたいに簡単にGUI作れるの?
> VC++未満のWin32API叩くような感じな気がするけど・・・
> そういえば、Kylixとか聞いたけど使えるようにするのは簡単?
kylix を使えるようにするのは、単にインストールするだけなので簡単でしょう。
フリーの UI ビルダも、 GTK 向けの glade があります。
Qt 向けのは知らないので、詳しい人のフォローを希望。
> 3.KDEとGnome、gtkとかqtって何?
> そもそも違っても別のLinux環境でも動くの?
KDE と gnome は、デスクトップ環境の名前です。
gtk と Qt は、 GUI を提供するライブラリの名前です。
使うライブラリさえ揃えれば、ディストリビューションが異なっても動くでしょう。
ライブラリを揃えさせるのが面倒なら、 statically linked なバイナリにすれば、何も考えずに動かせるでしょう。
> 4.理想は言語内ですべて済めばいいけど、そうはいかないし。
> さて、日本語のAPIドキュメントってあるのか?
> MSDNレベルの整理されたドキュメントは欲しいなぁ。
> 開発環境に統合されてれば最高!
MSDN のように一枚岩のドキュメントはありません。
各ライブラリの API リファレンスも、新しいものは日本語に翻訳されていなかったりします。
> 5.IME(FEP)の制御って簡単に出来るかな?
Input Method 周りは鬼門です。
最近の gtk immodule なら、だいぶ楽になってきてはいるようですが、詳しいことは分かりません。
フォロー希望。
> まさかFEP毎に別のAPIをコントロールがフォーカス取得時に
> 手動で送信とかいう冗談みたいな事はないよね?
日本語としてパースできませんでした。
> 6.文字コード意識しないといけないの面倒。
> EUCかUnicodeかなんでもいいから統一してくれ。
プログラム内部コードは、 4 byte の wchar_t で統一されています。
最近では、インストール直後からロケールが適切に設定されるので、外部コードが EUC であっても UTF-8 であっても、 (多分) 悩む必要はありません。
> 7.このプログラムは将来的にも一応動くの?
> 今作ったプログラム、とりあえず5年は動くかなぁ?
> ランタイムのバージョンが新しくなって動かなくなって、
> ヘルプで時間取られるの嫌だしなぁ。
難しい問題ですが、 statically linked なバイナリなら 5 年くらいは動くのではないかと。
# 5 年後に X が無くなっていると無理ですが…。
この辺は、 VB でも同じような物じゃないかな。
> 8.インストーラー簡単に作れないかなぁ?
> rpmやdebを自動的に構築。
> 必要ライブラリもインストールor警告出すようにとか。
> スタートメニュー(というかランチャ?)に登録もしてくれよ~
一定のルールに従ったソースコードなら、 deb はコマンド一発で作れて、ライブラリの依存関係も勝手に計算されます。
rpm は良く知りませんが、似たような仕組みはあるのではないかと。
メニューへの登録も、いくつかの簡単なテキストファイルを用意するだけです。
> 9.このショートカットキーの組み合わせ、
> この環境だとOKだけど、別の環境でも使えるんだろうか?
微妙です。この辺りは、 95 以降の Windows の方が統一されているでしょう。
ある程度安全に使える組み合わせはあると思うのですが、詳しいことは分かりません。
> 10.そもそも、日本語文字列の処理うまくいくのかな?
> 左から何文字目とかやったら、
> 左から何バイトに解釈されてへんな所で切れないだろうなぁ?
最近は wchar_t があるので、日本語を扱う程度なら、意図的に変なことをしない限りは大丈夫です。
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:1, 興味深い)
>
> VB 等に比べるまでもなく、実際に少ないと思います。
> Web のリファレンス/チュートリアルでは不満な人には、厳しいかも知れません。
手元にKDEの本が3冊、Qtの本が1冊あります。入門用には足りたけどやっぱ少ない。
>> 2.VBみたいに簡単にGUI作れるの?
>> VC++未満のWin32API叩くような感じな気がするけど・・・
>> そういえば、Kylixとか聞いたけど使えるようにするのは簡単?
KDEやQtが想定してる範囲内ならMFCより楽。
それより下の層を触るときは、X11やシステムコールはWin32APIよりプリミティブなのでどのあたりまでいじりたいかによる。
>> 4.理想は言語内ですべて済めばいいけど、そうはいかないし。
>> さて、日本語のAPIドキュメントってあるのか?
>> MSDNレベルの整理されたドキュメントは欲しいなぁ。
>> 開発環境に統合されてれば最高!
>
> MSDN のように一枚岩のドキュメントはありません。
>
> 各ライブラリの API リファレンスも、新しいものは日本語に翻訳されていなかったりします。
ドキュメントの質はMSDNに及ばないですね。細かい挙動追いたいときはソースある分楽なんですが、どこまで仕様でどこまでが現在の実装なのかはわかりにくいです。
>> 7.このプログラムは将来的にも一応動くの?
>> 今作ったプログラム、とりあえず5年は動くかなぁ?
>> ランタイムのバージョンが新しくなって動かなくなって、
>> ヘルプで時間取られるの嫌だしなぁ。
>
> 難しい問題ですが、 statically linked なバイナリなら 5 年くらいは動くのではないかと。
> # 5 年後に X が無くなっていると無理ですが…。
すくなくともMacOSXとXみたいな感じではXは残るだろうから心配要らないと思います。
>> 9.このショートカットキーの組み合わせ、
>> この環境だとOKだけど、別の環境でも使えるんだろうか?
>
> 微妙です。この辺りは、 95 以降の Windows の方が統一されているでしょう。
> ある程度安全に使える組み合わせはあると思うのですが、詳しいことは分かりません。
デスクトップ環境ごとに規約はありますが、カスタマイズ可能にしとくべきなんでしょうね。
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:1)
>> 難しい問題ですが、 statically linked なバイナリなら 5 年くらいは動くのではないかと。
>> # 5 年後に X が無くなっていると無理ですが…。
>すくなくともMacOSXとXみたいな感じではXは残るだろうから心配要らないと思います。
現状を知らないんですが、
Staticにしたら、洒落にならないサイズ…になったりはしないものですか?
Delphiとかでも(DelphiライブラリをStaticLinkした)実行ファイルは数百kbで、
更にWinだと本体据付なGUI足回りの多くの部分も、GNOME/KDEだと「StaticLink」
しないとならんわけですよね。
#いくらディスクが安くなったとはいえ、やっぱり大きい実行ファイルが山のように存在してると気が滅入るのでG7
##そのせい「も」あって、近年はめっきりScript言語野郎してます。小ささとメンテ性を考えるとScriptが一番かも。
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:0)
でも実際はGnomeにしろKDEにしろフリーソフトの99%ぐらいはソースで配布にするかパッケージで配布して依存ライブラリはパッケージングシステムに任せるかで問題にはなってない気がします。
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:1)
ソースからmakeすることの、初心者(??)に対する敷居を、下げないとアレですね。
…とはいえ、自分で考えてOptionいじる必要がある場合でもなけりゃ、
makeそのものが難しいっていう感覚はほぼゼロですね。
「インストーラー」がconfigure;makeをすればそれでいい、のかな…
>パッケージで配布して依存ライブラリはパッケージングシステムに任せるかで問題にはなってない気がします。
100個のアプリが、100個の「バージョン違いの」ライブラリを要求したら、
結構悲惨なことになりそうですね(^^;
ところで、やっぱりライブラリ間の依存関係ってのは、
ガベージコレクションみたいに
参照カウント法とかマーク&スイープ法とかで
「不要」になったことを判断して自動アンインストールする(してくれる)ものなん…ですよね??
#メモリ管理(GC)と比較して考えると、「ライブラリを置くPathはmake時に確定すべきだ」
#というUnix的(?)発想は、前近代的だなと思えてならないのでG7
#名前に束縛されることで、複数の共存がやりにくくなるじゃん。
#malloc()の出力はアドレスを問わないのが味噌なんだよね。名前空間的にも物理空間的にも"Location"の縛りが無い。
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:0)
> 現状を知らないんですが、
> Staticにしたら、洒落にならないサイズ…になったりはしないものですか?
なりますね。
Windows 環境での開発には詳しくないのですが、 Windows アプリケーションを配布する際には、 DLL の非互換性を嫌って、実行ファイルと同じディレクトリに DLL を置くのが普通になっていると聞きました。 DLL Hell と呼ばれてるとか何とか。
# 昔は、アプリケーション毎に、違うバージョンの MFC42.DLL を持ってたりしましたよね。最近は違うのかな?
こんなこ
DLL Hell (スコア:1)
インストーラーによっては、古いバージョンのMFC42.dllで
新しい物を上書きされてしまうのが問題だったと思ってます。
どちらかといえばインストーラの問題なので、
WindowsやMFC42.dll側の問題とは違う気もします。
そこらへん、Linuxだとインストールするのに、
依存関係のチェックがあるものが多いので発生しないのかも。
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:1)
現状書籍は入門用はそこそこ出ているのですね。
今度大型の書店にでも行って探してみます。
KDEやQtが想定している範囲内はMFCより楽という事なので、
難易度としては、VB以上VC未満みたいな状態かな?
# VBも凝った事をしようとした瞬間複雑化するので。
ここを見ればOKみたいなAPIドキュメントとかが、
現状少ないみたいなのがこれから作るとしたら怖い点ですかね。
困ったときに見るリファレンスが難解だとか、
必要なドキュメントが見つからないといった状態になると挫折するかも。
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:1)
> Input Method 周りは鬼門です。
> 最近の gtk immodule なら、だいぶ楽になってきてはいるようですが、詳しいことは分かりません。
> フォロー希望。
>> まさかFEP毎に別のAPIをコントロールがフォーカス取得時に
>> 手動で送信とかいう冗談みたいな事はないよね?
> 日本語としてパースできませんでした。
やりたいこととしては、名前と名前のカナを入力する欄があるとしたら、
自動的に日本語入力がONになったり、カナ入力モードになったりという、
ユーザーに対しての入力支援ですね。
Win32 APIなら統一されたAPI [microsoft.com]を使用することで、
ATOKなのかMS-IMEなのか、そもそも日本語のIMEなのかを意識しないで変更できます。
>この辺は、 VB でも同じような物じゃないかな。
たしかに、VB Runtimeが無くて動かないって場合もありますね。
一応Win95時代のアプリも一応動く実績があるので・・・
LinuxのGUIアプリってどうなのかな?と思ったり。
>メニューへの登録も、いくつかの簡単なテキストファイルを用意するだけです。
これは、環境非依存・・・
例えば~/.kde~~が/tmp/startmenu/のように変更されていてもOKなのでしょうか?
こうすると、ユーザーが好きな場所に登録が出来ない気もします。
まぁ、ここらへんはLinuxで動く対話型GUIなインストーラーが、
KDEやらGnomeが標準で用意してくれたら良いのかもしれませんが。
<おふとぴ>
# 傍から見てると、LinuxのGUIアプリってシェアを
# 身内で食い合ってる様に見えるのは気のせいなんだろうか?
</おふとぴ>
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:0)
glade休眠中…お願い復活して。
> 最近は wchar_t があるので、日本語を扱う程度なら、意図的に変なことをしない限りは大丈夫です。
cygwinでは16bitなのが泣ける (;_;)
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:0)
最近はけっこう増えてきた・・・と思う。
Re:日本の開発者が増えるには (スコア:1)
今まで見聞きしている限りでは、なんかフツーvs開発者の比率って1000:1程度の様な気が・・・・
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:日本の開発者が増えるには (スコア:1)
Re:日本の開発者が増えるには (スコア:2, すばらしい洞察)
さらに、公開するとなれば、他人が使うことを考えなければならないわけです。いろいろな人/場面を想定する必要があって、かなり気力がいると思います。
# 最近仕事?で作っているプログラムは、テキストフィルタ的なものばかり。
# モデル化データを作って、シミュレータに突っ込んで、出力切り出してグラフに加工...
# 拡張に拡張を重ねたせいで、人には見せられないプログラムに。
なんちゃってプログラマ?
Re:日本の開発者が増えるには (スコア:1)
アプリもいいんだけど、(GUIな)ライブラリ…典型的なのはWidget…も
みんな沢山作って欲しいなあ。
と、Delphi出身者な俺は思うのでした。
フリーかつソース公開(The OSI OpenSouceかどうかはさておき)な
Widget(Delphi弁だとComponent)が結構沢山あるんですよね。あれが気持ちよかった。
で、APIというかフレームワークというか…が秀逸ならば、
GNOMEの一番偉い人によれば、
「2000行で気楽にWidget作って公開!なんてのがさくさく出来るっしょ」
ってことだそうです。
プチアプリとしてのWidgetってのは、結構いいもんですよ。いろんな意味で。
で、その次の段階として、
そういったフリーのWidgetをかき集めてアプリらしきものを
とりあえず手早くでっち上げられる環境が有れば、
めでたしめでたし(=「アプリ」の生産性がshなみになる)です。
ん。たぶん、Widget作者とアプリ作者が、
(あくまで結果としてだけど)分離されるといいんだよね。
…ご健闘をお祈りします。
GUI作るのマンドラケ(AA略) (スコア:0)
Re:GUI作るのマンドラケ(AA略) (スコア:0)
似たものとなるとどうしても前のと比べちゃうし。
GTK+1.xについてたファイルマネージャーっぽいやつはよかったんだよな。
TAB補完に慣れた指で違和感なく使えるよう作ってあって。
ああいうCUI文化をうまく継承したGUIなんかがもっと増えたら
おもしろいんだけど。>PC-UNIXのGUI
Re:日本の開発者が増えるには (スコア:0)