Scratch 3.0 への提案

itta611

hhayyatto wrote:
逆にサロゲートペアをわざわざ書けなくする相応の理由があるのでしょうか。

調べると出てくると思うのですが、技術的に少し難しいみたいです。
問題は、Scratchチームが時間を使ってプログラムを書き換えるほど必要かということです。

hhayyatto

それはひどい誤解です。
俺が言っているのは「ソースコードをちょちょいと書き換えれば普通に書けるようになるのに、なぜそうしないのか」
ということです。

hhayyatto

#5242
技術的に難しい点はどこですか。

abee

#5243
「ソースコードをちょちょいと書き換えれば」と書いたのはhhayyattoさんなので、技術的な議論をするのであれば、その変更点を示さないと話が進まないと思います。
先に書いた2.0のペイントエディターの日本語入力のケースでは、変更点のソースコードを示してプルリクエストしたにも関わらず、採用されることはありませんでした(採用されなかったのには合理的な説明がありました)。一般的な話として、世界中で7000万人が使っているシステムに手を入れるのに「ちょいちょい」はありえません。

hhayyatto

その「合理的な説明」はなんですか。

Poteto143

なお、質問を提示されたのであればそれを新たな質問で返すのではなく回答で返すことを強く推奨します。
#5235の質問について、一切回答にあたる投稿がないように思えます。

Last edited by Poteto143 (March 27, 2021 05:33:19)

abee

#5246
今回の話題と直接関係ありませんが、2.0の場合、ペイントエディターで使うフォントはそれぞれのプラットフォームが持っているものではなく、swfの中に組み込まれていました。提案は軽量のCJKフォントを組み込んで使うものだったのですが、そのフォントを必要としないすべてのユーザーが毎回それを読み込むことによる世界的なトラフィックの増大によるデメリットと、そのフォントを必要とするユーザーのメリットを比較した場合、前者のデメリットの方が大きいという判断でした。根本的にはswfにフォントを組み込む設計の問題ですが、そこまで手を入れると大手術にになり、影響が大きすぎるということで、3.0まで持ち越しになったわけです。
GitHubのissuesには、すでに大量の提案やバグレポートがあり、その重大性や必要性、実現可能性などをもとに優先順位が付けられています。それを実現するためにかかるリソースは有限なので、仮に実現コストが低かったとしても、メリットを受ける人の数が限られるなら、優先順位は下がります。

Last edited by abee (March 27, 2021 05:27:27)

hhayyatto

なるほど。つまりたとえこの件をissuesに報告しても、優先順位は低く、なかなか実装されないということですね。

itta611

#5244:
繰り返しですが、調べれば出てきます。
これを見てみてください

hhayyatto

#5250
つまりScratchが「二文字で一文字」に対応していないということですか?

itta611

実験してみたところ、Scratchは上の記事の★6なので2文字で1文字の扱いで正しい取り扱いができていないということです。
あと#5243の「ひどい誤解」というのはどこがどのように誤解されているのか教えて下さい。

abee

#5249
そう思います。ただ、これはissueにあげない方が良いという意味ではありません。そこになければ、そもそも問題は存在しないとみなされます。
(話が飛びますが、みなさんにScratch Labのレビューを書くようにすすめているのも同じ理由です。)
単に不満をぶつけるだけでは提案は通らないので、地道な活動が必要です。特に日本の場合、全ユーザーのわずか1.2%しかいないので、日本のユーザーがコミュニティーに貢献していることを示さなければなりません。それは、みなさんが良い作品やスタジオを作ったり、地域や学校などで活躍することなどです。そして、それをScratch Teamの皆さんに伝えること、可能なら日本に来てもらって見てもらうこと、日本の人が海外のカンファレンスに参加することなど、すべてがつながっています。そういうことを続けた結果、今の状況、つまり、わずか1.2%にも関わらず他の国や地域に比べて多くのサポートを受けているわけです。

Last edited by abee (March 27, 2021 05:53:42)

hhayyatto

すみません。その時はまだ「二文字で一文字」に対応していないということを知りませんでした。

inoking

仕事で既存のプログラムを UNICODE 対応した経験もありますが
「二文字で一文字」のような対応は非常に大変です。

1. 影響箇所の洗い出し（全ソースコードの検索と怪しい箇所の調査）
2. 対応策の検討、試作
3. 全影響箇所の変更、テスト
といった流れになるでしょう。

yukku

再描画なしのブロックの定義を直接クリックしたときも再描画なしで実行してほしいです。

ringoumai

yukku wrote:
再描画なしのブロックの定義を直接クリックしたときも再描画なしで実行してほしいです。

クリックしたときって再描画ありになるのですね。それだとややこしいので賛成です。

Last edited by ringoumai (March 30, 2021 10:16:09)

TOMO1260

(複素数 () + () i::operators)
< <> と <> のどちらか1つ::operators>
( () の [sec v]::operators)
( () の [csc v]::operators)
( () の [cot v]::operators)
( () ^ () ::operators)
(log () ()::operators)

ringoumai

#5258 何故ほしいのか、理由もお願いします。

inoking

sec などについては
以前も同様のコメントをされていますが代用方法も示されています。#4812
他の方からも出ています #5033

理由などを書くこともそうですが
出された返答をふまえたうえ投稿をお願いします。

yuikunyeah

ringoumai wrote:
yukku wrote:
再描画なしのブロックの定義を直接クリックしたときも再描画なしで実行してほしいです。
クリックしたときって再描画なしになるのですね。それだとややこしいので賛成です。

クリックした時にだけ採苗がありにされるのではないですか？
(#5256には賛成です。)

Discuss Scratch