Masaru Tsuchiyama
Masaru Tsuchiyama
https://github.com/sakura-editor/sakura/tree/v2.4.0-beta4 でいいと思います。
> 修正作業を容易にするために msbuild のビルドログを解析して artifacts に解析結果を含める対応をする。 #207 で PR を投げた。
ビルド手順というか、環境構築法です。
> 機能的に大きな変更は入らないと考えています。そういう意味では 2.3.3.0 くらいでも良いかも。 2.3.3.0 のバージョンには反対です。 また、ユーザーから見たときに特に更新したいと思う修正が 入っていない状態でのリリースにも反対です。 FFFTP が更新されてない状態が続いて、久しぶりに更新されたタイミングで 窓の社で記事になりました。 https://forest.watch.impress.co.jp/docs/news/1115458.html もし、sakura editor が 2017-05-02 から一年ぶりにリリースされた場合 同様にフリーソフトウェア関連のサイトで記事になるかもしれません。 (更新されなかった期間に違いはありますが) そのとき 2.3.2.0 → 2.3.3.0 になりました、では記事も書きにくいし 更新したいとユーザーも少なくなると思います。 一般にリリースするのであれば、ユーザーから見たときに更新したくなる修正がほしいです。 そんなに技術的に難しくなくてユーザーから見たときのインパクトのある修正は64bit 対応 だと思います。 これまで...
> しかし、実際の利用者は破壊的変更を求めてない気もするので、次のリリース時に要望の投票とか、Google Formsのアンケートとかで利用者の声を集めて見るのも良いかもしれませんね・・・ google form でアンケートを作ったことがないので試しに作ってみました。https://goo.gl/forms/M2ITr7oW4q0W4xnH3 すごく簡単に作れます。
簡単にというのは、google form の使い方の話です。
> アンケート良いですね。次リリースバージョンの初回起動時だけアンケート促すダイアログとか入れたいなーと思いました（うざいですかね。一度起動だけなら良いかな、と）。 うざいと思います。 iPhone アプリでは、レビューを要求するアプリは結構ありますが、 Windows アプリではほとんどないです。 メニューからユーザーが自分で選んで、アンケートに記載するのは問題ないと思います。 > あと、ヘルプメニューから「GitHub Issues」「アンケート」に直接飛べるリンク張りたいな、と思っています。 いいと思います。 ただアンケートは、アンケートの URL が変わったら面倒なので 直リンクではなくweb site のどこかにしたほうがいいと思います。 別件ですが、アップデートがあったときの自動更新があれば嬉しいと思います。
自動更新に関しては #78 にチケット作りました。
@berryzplus さん > 64bitOSで動かした時、たまに起動が重たくなる事象に対する暫定対応というのを週末にPR予定です。 これって何をする予定だったか、覚えてますか? 覚えているうちにチケットだけでも作っておいていただけますか?
> 素朴な疑問ですが、使用中のディレクトリが削除できないのは問題でしょうか。使用しつつ削除できるに越したことはありませんが、そうでないならば。 使用しているというのは単に sakura editor の内部構造の話なだけで、 ユーザーからしたら、すでに閉じているファイルのディレクトリなので 使用中ではないディレクトリが削除できないように見えます。