Discuss Scratch
- Discussion Forums
- » 日本語
- » scratch2.0の提案
![[RSS Feed]](//cdn.scratch.mit.edu/scratchr2/static/__9c6d3f90ec5f8ace6d3e8ea1e684b778__//djangobb_forum/img/feed-icon-small.png "[RSS Feed]")
![[RSS Feed]](http://cdn.scratch.mit.edu/scratchr2/static/__9c6d3f90ec5f8ace6d3e8ea1e684b778__//djangobb_forum/img/feed-icon-small.png "[RSS Feed]"){kind=icon}
- inoking
-
Scratcher
1000+ posts
scratch2.0の提案
挙げられたプロジェクトで解説されているように、座標値はピクセルとピクセルの間に存在するのでその辺についてはこれを見てみてください。この場合だと中心に色が四つありません？スクリプトの中心の色を判定すればいいのでは？調べるカテゴリ<触れた色 ::sensing>//複数あるときに疑問一番上の色を判定したらいいのではないでしょうか。
こういう場合のことを言っているのですが。
画像の例では4ピクセルに接します。
※ペンで描画すると（太さ1に設定しても）指定座標をまたぐ2ピクセルにわたって描画されます。
これは署名と呼ばれるもので投稿本文とは関係ありません。
Scratch は「世界最大の子ども向けコーディングコミュニティーで、シンプルなビジュアルインターフェースを持ったコーディング言語」
つまり「子ども SNS」ではない
・「傾向」とは単に一定の基準で作品を並びかえただけのもので、ランキングでもなんでもない、ナンバーワンよりオンリーワンを目指してみては？
・「フォロー」とは他の Scratcher が何をしているかを簡単に確認するためのもので、「フォロワー」は「ファン」ではない
・「スタジオ」とは特定のテーマに沿って作品をまとめたり、共同制作したりするための場所
・「星」や「ハート」などを何かの見返りとすることは Scratch チームによって禁止されている
- itnkmkw
-
Scratcher
1000+ posts
scratch2.0の提案
話し合い。そのための裁判所的なものを作る予定です。（スタジオで）方法はいくらでもある。報告は最終手段としたいです。削除賛成。他人のプロフィールのコメント削除はST却下。そのためにどうすればよいですか？
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
もっと平和に解決したいです。
トラウマは存在しない。存在するのは今だけなんだ。過去のトラウマが原因で今の行動をとってしまったんじゃない。
今，自分でその行動をとる判断をしたんだ。過去は関係ない。だから，トラウマに取りつかれるのはやめよう。今から変われるんだ。
Start in your life…
興味のある方はこちら。itnkmkw と一緒に 心 について考えるスタジオ
※この署名のメッセージは不定期で変更されています。もしかしたらあなたへのメッセージかもよ～^^
皆さ～ん!「聖書」と言う言葉を聞いてどう思いますか?興味のある方はここやココやここへ！
@itnkmkwと申します。沖縄在住（ホームスクーラー）です。心理学と音楽やってます。MIX依頼募集中！
《コミュニティーをより良い所にするために》Scratch に関係ないトピックについての意見交換所では議事進行役を務めております（名ばかりですが）。どーぞよろしく
最近プロジェクト作ってませんが、もうすぐ聖書RPGの製作を再開しますので…いまは彩雲が忙しいのだ。
- kaaramochi
-
Scratcher
1000+ posts
scratch2.0の提案
問題はないけど、いつまでもあっても困るコメント、もう用済みのコメントについては、報告は理不尽だと思います。話し合い。そのための裁判所的なものを作る予定です。（スタジオで）方法はいくらでもある。報告は最終手段としたいです。削除賛成。他人のプロフィールのコメント削除はST却下。そのためにどうすればよいですか？
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
もっと平和に解決したいです。
- apple502j
-
Scratcher
1000+ posts
scratch2.0の提案
裁判所は荒れます。(個人の意見です。)話し合い。そのための裁判所的なものを作る予定です。（スタジオで）方法はいくらでもある。報告は最終手段としたいです。削除賛成。他人のプロフィールのコメント削除はST却下。そのためにどうすればよいですか？
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
もっと平和に解決したいです。
署名は、ディスカッションフォーラムの機能である。署名は、その人のすべての投稿の下部に追加される。署名は、BBCodeで記述できる。 署名を追加/変更/削除したい場合は、ディスカッションフォーラムのホームの一番下に行き、「Change your signature」を押す。署名の大きさは150pxまでである。これには、改行、画像を含む。- Japanese Scratch-Wiki 「署名」
- inoking
-
Scratcher
1000+ posts
scratch2.0の提案
呼び名だけのことかもしれませんが「裁判」というものは既に最終手段にあたると思います。裁判所は荒れます。(個人の意見です。)話し合い。そのための裁判所的なものを作る予定です。（スタジオで）方法はいくらでもある。報告は最終手段としたいです。削除賛成。他人のプロフィールのコメント削除はST却下。そのためにどうすればよいですか？
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
もっと平和に解決したいです。
あらためて、
略されていた元の提案を引用します。
・自分がオーナーのスタジオに投稿されたコメントの削除
削除を許してしまうと
（自分のプロフィールのコメントのように）自分に都合の悪いコメントを削除する人が現れるのでよろしくないと思います。
荒らしと思われるコメントに対しては
注意→警告→報告
で対応することはルールにのっとった真っ当なやり方だと思います。
「問題はないけどいつまでもあるコメント」は問題ないのだから放置しておけばよいと思います。
これは署名と呼ばれるもので投稿本文とは関係ありません。
Scratch は「世界最大の子ども向けコーディングコミュニティーで、シンプルなビジュアルインターフェースを持ったコーディング言語」
つまり「子ども SNS」ではない
・「傾向」とは単に一定の基準で作品を並びかえただけのもので、ランキングでもなんでもない、ナンバーワンよりオンリーワンを目指してみては？
・「フォロー」とは他の Scratcher が何をしているかを簡単に確認するためのもので、「フォロワー」は「ファン」ではない
・「スタジオ」とは特定のテーマに沿って作品をまとめたり、共同制作したりするための場所
・「星」や「ハート」などを何かの見返りとすることは Scratch チームによって禁止されている
- mochimochiking
-
Scratcher
1000+ posts
scratch2.0の提案
削除を許してしまうと自分に都合の悪いコメントを削除する人が現れるのですべてのコメントを削除不可にすべきだと思います。
（自分のプロフィールのコメントのように）自分に都合の悪いコメントを削除する人が現れるのでよろしくないと思います。
undefined
- inoking
-
Scratcher
1000+ posts
scratch2.0の提案
それは「自分のプロフィールのコメントを削除できなくする」という提案ですか？削除を許してしまうと自分に都合の悪いコメントを削除する人が現れるのですべてのコメントを削除不可にすべきだと思います。
（自分のプロフィールのコメントのように）自分に都合の悪いコメントを削除する人が現れるのでよろしくないと思います。
私もそれがよいと思いますが現状なぜできているのかが謎ですね。
理由を探したほうがよいかもしれません。
これは署名と呼ばれるもので投稿本文とは関係ありません。
Scratch は「世界最大の子ども向けコーディングコミュニティーで、シンプルなビジュアルインターフェースを持ったコーディング言語」
つまり「子ども SNS」ではない
・「傾向」とは単に一定の基準で作品を並びかえただけのもので、ランキングでもなんでもない、ナンバーワンよりオンリーワンを目指してみては？
・「フォロー」とは他の Scratcher が何をしているかを簡単に確認するためのもので、「フォロワー」は「ファン」ではない
・「スタジオ」とは特定のテーマに沿って作品をまとめたり、共同制作したりするための場所
・「星」や「ハート」などを何かの見返りとすることは Scratch チームによって禁止されている
- mochimochiking
-
Scratcher
1000+ posts
scratch2.0の提案
「自分のプロフィールおよび自分の作品のコメントを削除できなくする」という提案です。それは「自分のプロフィールのコメントを削除できなくする」という提案ですか？削除を許してしまうと自分に都合の悪いコメントを削除する人が現れるのですべてのコメントを削除不可にすべきだと思います。
（自分のプロフィールのコメントのように）自分に都合の悪いコメントを削除する人が現れるのでよろしくないと思います。
私もそれがよいと思いますが現状なぜできているのかが謎ですね。
理由を探したほうがよいかもしれません。
誰か理由を知っているかもしれませぬから、質問コーナーに投稿しました。
undefined
- itnkmkw
-
Scratcher
1000+ posts
scratch2.0の提案
呼び名だけのことかもしれませんが「裁判」というものは既に最終手段にあたると思います。裁判所は荒れます。(個人の意見です。)話し合い。そのための裁判所的なものを作る予定です。（スタジオで）方法はいくらでもある。報告は最終手段としたいです。削除賛成。他人のプロフィールのコメント削除はST却下。そのためにどうすればよいですか？
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
もっと平和に解決したいです。
あらためて、
略されていた元の提案を引用します。・自分がオーナーのスタジオに投稿されたコメントの削除
削除を許してしまうと
（自分のプロフィールのコメントのように）自分に都合の悪いコメントを削除する人が現れるのでよろしくないと思います。
荒らしと思われるコメントに対しては
注意→警告→報告
で対応することはルールにのっとった真っ当なやり方だと思います。
「問題はないけどいつまでもあるコメント」は問題ないのだから放置しておけばよいと思います。
「自分のプロフィールおよび自分の作品のコメントを削除できなくする」という提案です。それは「自分のプロフィールのコメントを削除できなくする」という提案ですか？削除を許してしまうと自分に都合の悪いコメントを削除する人が現れるのですべてのコメントを削除不可にすべきだと思います。
（自分のプロフィールのコメントのように）自分に都合の悪いコメントを削除する人が現れるのでよろしくないと思います。
私もそれがよいと思いますが現状なぜできているのかが謎ですね。
理由を探したほうがよいかもしれません。
誰か理由を知っているかもしれませぬから、質問コーナーに投稿しました。
ぼくは，削除できた方がいいと思うのですが…
トラウマは存在しない。存在するのは今だけなんだ。過去のトラウマが原因で今の行動をとってしまったんじゃない。
今，自分でその行動をとる判断をしたんだ。過去は関係ない。だから，トラウマに取りつかれるのはやめよう。今から変われるんだ。
Start in your life…
興味のある方はこちら。itnkmkw と一緒に 心 について考えるスタジオ
※この署名のメッセージは不定期で変更されています。もしかしたらあなたへのメッセージかもよ～^^
皆さ～ん!「聖書」と言う言葉を聞いてどう思いますか?興味のある方はここやココやここへ！
@itnkmkwと申します。沖縄在住（ホームスクーラー）です。心理学と音楽やってます。MIX依頼募集中！
《コミュニティーをより良い所にするために》Scratch に関係ないトピックについての意見交換所では議事進行役を務めております（名ばかりですが）。どーぞよろしく
最近プロジェクト作ってませんが、もうすぐ聖書RPGの製作を再開しますので…いまは彩雲が忙しいのだ。
- itnkmkw
-
Scratcher
1000+ posts
scratch2.0の提案
いえ。裁判と言うのは二種類有りまして，呼び名だけのことかもしれませんが「裁判」というものは既に最終手段にあたると思います。裁判所は荒れます。(個人の意見です。)話し合い。そのための裁判所的なものを作る予定です。（スタジオで）方法はいくらでもある。報告は最終手段としたいです。削除賛成。他人のプロフィールのコメント削除はST却下。そのためにどうすればよいですか？
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
もっと平和に解決したいです。
民事裁判と刑事裁判です。刑事裁判の方をみなさん思い浮かべ，報告をこちらだけでやっているようなものだと思うのかもしれませんが，僕が言っているのは，民事裁判です。和解に導くために裁判官が仲介に入るものです。ですから，報告はできるだけ避けたいので，削除可能がいいです。自分に都合の悪いコメントとはたとえばどのようなものですか？自分の個人情報を自分のプロフィールに書かれた場合，消せた方がいいではないですか。
トラウマは存在しない。存在するのは今だけなんだ。過去のトラウマが原因で今の行動をとってしまったんじゃない。
今，自分でその行動をとる判断をしたんだ。過去は関係ない。だから，トラウマに取りつかれるのはやめよう。今から変われるんだ。
Start in your life…
興味のある方はこちら。itnkmkw と一緒に 心 について考えるスタジオ
※この署名のメッセージは不定期で変更されています。もしかしたらあなたへのメッセージかもよ～^^
皆さ～ん!「聖書」と言う言葉を聞いてどう思いますか?興味のある方はここやココやここへ！
@itnkmkwと申します。沖縄在住（ホームスクーラー）です。心理学と音楽やってます。MIX依頼募集中！
《コミュニティーをより良い所にするために》Scratch に関係ないトピックについての意見交換所では議事進行役を務めております（名ばかりですが）。どーぞよろしく
最近プロジェクト作ってませんが、もうすぐ聖書RPGの製作を再開しますので…いまは彩雲が忙しいのだ。
- itnkmkw
-
Scratcher
1000+ posts
scratch2.0の提案
荒れないために裁判所があるのです。（荒れる可能性はあるけどそんなこと言ってらんない）裁判所は荒れます。(個人の意見です。)話し合い。そのための裁判所的なものを作る予定です。（スタジオで）方法はいくらでもある。報告は最終手段としたいです。削除賛成。他人のプロフィールのコメント削除はST却下。そのためにどうすればよいですか？
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
もっと平和に解決したいです。
トラウマは存在しない。存在するのは今だけなんだ。過去のトラウマが原因で今の行動をとってしまったんじゃない。
今，自分でその行動をとる判断をしたんだ。過去は関係ない。だから，トラウマに取りつかれるのはやめよう。今から変われるんだ。
Start in your life…
興味のある方はこちら。itnkmkw と一緒に 心 について考えるスタジオ
※この署名のメッセージは不定期で変更されています。もしかしたらあなたへのメッセージかもよ～^^
皆さ～ん!「聖書」と言う言葉を聞いてどう思いますか?興味のある方はここやココやここへ！
@itnkmkwと申します。沖縄在住（ホームスクーラー）です。心理学と音楽やってます。MIX依頼募集中！
《コミュニティーをより良い所にするために》Scratch に関係ないトピックについての意見交換所では議事進行役を務めております（名ばかりですが）。どーぞよろしく
最近プロジェクト作ってませんが、もうすぐ聖書RPGの製作を再開しますので…いまは彩雲が忙しいのだ。
- kan217
-
Scratcher
1000+ posts
scratch2.0の提案
mochimochiking さんからの削除対象案についての検討
赤文字がinokingのコメントです。
青文字がapple502jさんのコメントです。
橙文字がmochimochikingさんのコメントです。
緑文字がkaaramochiさんのコメントです。
オリーブ文字がfine316さんのコメントです。
灰文字がMMGISSさんのコメントです。
紫がkan217さんのコメントです。
見た目カテゴリ
スプライトのすべての部分を指定色にすると推測できます。
なるほど。しかし汎用性があるかに疑問が残りますね。
+複数の色があった場合、どう処理されるかが不明です。
スプライトの透明以外のすべてを指定色で塗りつぶすのだと思います。どういうときに必要ですか？
必要性はないと思います
調べるカテゴリ
可能性として、スペース区切りがあります。ただし、技術上できるかは不明です。
上の二つは縦に()伸びるなどのブロックと合わせて検討する方がいいと思います。
旧ブロック (note::sensing) のことでしょうか。
スペース区切りはどうでしょう。
スペース区切りを行うとき、「スペース」キーや「上向き矢印」キーなどを記述する言語(英語に揃える？)に疑問が残ります。
a b c enterといった感じでしょうか。押されている瞬間だけ反応するんですか？
押されている間ずっと反応するようにしたほうがわかりやすいと思います。
Windowsキーなど特定のプラットホームのみに存在するキーのときも疑問が残ります。
表記をany_special_keyなどとすることで無理やり押さえ込むことはできます。
ホイールがついていないマウスもあります。
ホイールがないならその機能が使えないだけなので支障はないと思います。
ホイール機能が導入されたときに、たとえばホイール機能がプロジェクトでの重要な役割を担っているプロジェクトが作成されることが考えられます。
そうすると、ホイールが使えない一部のユーザーはそのプロジェクトができなくなってしまうと思います。
現状でも例えばマイクやカメラで同様の状況が発生しています。
変数カテゴリ
他にはどのような意見がありますか。
https://scratch.mit.edu/discuss/post/2803828/ が関係するかなと。
変数やリストの表示については https://scratch.mit.edu/discuss/post/2800013/ についても考慮お願いします。
上の三つは、実装されてもいいと思います。
上の三つの実装に賛成。
上の二つは、どんなときに使うんでしょうか。
上の四つは、そこまで汎用性があるでしょうか。
上の二つは、実装されてもいいと思います。
リストの大きさなどが勝手に変わるから実装したいということだと思うので、それが変わらないようにすればいいと思います
その他 編集/実行
・コスチュームエディターの大きさを変数のスライダーみたいな感じで細かく変更できるようにしてほしい//用途不明
→提案内容の分かる方、説明お願いします。
サイズを大きくするときに端のドラッグ以外にも、スライダーでできるようにするor数値入力。SVGを読み込んで大きすぎ、エディターをはみ出して端もつかめない場合(経験済み)などに役立つ。
話す
・トピックの連続建て不可//徳子ぉがあるため不要
→提案内容の分かる方、説明お願いします。
スパム防止として、追加に賛成です。600秒などはどうでしょう。(New Scratcherの120秒ルールは過去は600秒)
60秒ではなぜ短いとおもうのですか。
10分は長すぎますよ。
10分でもいいと思います。そもそもトピックは頻繁に作るものではないと思うので1日でも構わないと思います。
600秒に賛成です。
追加賛成です。
1日に賛成
・自分がオーナーのスタジオに投稿されたコメントの削除//コメントは皆のものだから、コメントはけせなくしたほうがよいとおもう。
→削除賛成。異論なければ却下に移動したいと思います。
削除賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
その他
・リミックス時に過去の「メモと作品への貢献」が変更できないようにする//追加はできるようにすべき
→削除賛成。異論なければ却下に移動したいと思います。
これは追加に賛成です。基本、リミックスには元作品でクレジットのある素材が使われているので、クレジットが消えたら故意ではないのに削除対象となってしまいます。過去の記述の前に追加という形なら大丈夫と思います。
クレジットは残すべきだと思います。（その素材を消さない限り）しかし、合作などではメモがどんどん増えてしまいます。
「消さないように」ではなく、リミックス元のクレジットが継承できるようにしたほうがいいと思います。
追加に賛成
・私の作品で、昇順/降順の切り替え可能//人気のない作品、古い作品、リミックスされていない等の順で見る意図が不明
→提案内容の分かる方、説明お願いします。
作品の検索機能があればそれでいいのですが、要は「作品を手早く見つける手段」なのではないのでしょうか。
赤文字がinokingのコメントです。
青文字がapple502jさんのコメントです。
橙文字がmochimochikingさんのコメントです。
緑文字がkaaramochiさんのコメントです。
オリーブ文字がfine316さんのコメントです。
灰文字がMMGISSさんのコメントです。
紫がkan217さんのコメントです。
見た目カテゴリ
このスプライトの色を [#000000] にする ::looks//透明色とのグラデーションの場合、どこまでが「このスプライトなのか」→提案内容の分かる方、説明お願いします。
スプライトのすべての部分を指定色にすると推測できます。
なるほど。しかし汎用性があるかに疑問が残りますね。
+複数の色があった場合、どう処理されるかが不明です。
スプライトの透明以外のすべてを指定色で塗りつぶすのだと思います。どういうときに必要ですか？
必要性はないと思います
調べるカテゴリ
<触れた色 ::sensing>//複数あるときに疑問→提案内容の分かる方、説明お願いします。
可能性として、スペース区切りがあります。ただし、技術上できるかは不明です。
(スプライトの [縦の大きさ v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討
(スプライトの [横の大きさ v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討
上の二つは縦に()伸びるなどのブロックと合わせて検討する方がいいと思います。
(スプライトの [面積 v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討
(マイクの音の高さ ::sound)//音は複数の周波数で構成されているため何を返すのか疑問→提案内容の分かる方、説明お願いします。
旧ブロック (note::sensing) のことでしょうか。
(押されたキー :: sensing)//複数あるときに疑問→提案内容の分かる方、説明お願いします。
スペース区切りはどうでしょう。
スペース区切りを行うとき、「スペース」キーや「上向き矢印」キーなどを記述する言語(英語に揃える？)に疑問が残ります。
a b c enterといった感じでしょうか。押されている瞬間だけ反応するんですか？
押されている間ずっと反応するようにしたほうがわかりやすいと思います。
Windowsキーなど特定のプラットホームのみに存在するキーのときも疑問が残ります。
表記をany_special_keyなどとすることで無理やり押さえ込むことはできます。
<[コスチューム1 v]の[Sprite1 v]に触れた :: sensing>//簡単なスクリプトで実装可能→簡単かどうかは分かりませんが汎用性がないと思います。
(マウスホイールの移動量 :: sensing)//xかyか何を返すのか疑問→ユーザーがマウスホイールを 1 目盛り回すごとにスクロールする行数のことです。
ホイールがついていないマウスもあります。
ホイールがないならその機能が使えないだけなので支障はないと思います。
ホイール機能が導入されたときに、たとえばホイール機能がプロジェクトでの重要な役割を担っているプロジェクトが作成されることが考えられます。
そうすると、ホイールが使えない一部のユーザーはそのプロジェクトができなくなってしまうと思います。
現状でも例えばマイクやカメラで同様の状況が発生しています。
変数カテゴリ
変数 [ v] のx座標を () に、y座標を () にする ::variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
他にはどのような意見がありますか。
https://scratch.mit.edu/discuss/post/2803828/ が関係するかなと。
変数やリストの表示については https://scratch.mit.edu/discuss/post/2800013/ についても考慮お願いします。
(変数 [ v] のx座標 ::variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
(変数 [ v] のy座標 ::variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の三つは、実装されてもいいと思います。
上の三つの実装に賛成。
変数 [ v] の表示形式を [スライダー v] にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
(変数 [ v] の表示形式::variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の二つは、どんなときに使うんでしょうか。
[変数 v] のスライダーの最小値を (0) にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
[変数 v] のスライダーの最大値を (0) にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
([変数 v] のスライダーの最小値 :: variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
([変数 v] のスライダーの最大値 :: variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の四つは、そこまで汎用性があるでしょうか。
<変数 [ v] がクリックされた :: variables>//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
リスト [ v] のx座標を () に、y座標を () にする ::list//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
リスト [ v] の縦幅を () に、横幅を () にする ::list//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の二つは、実装されてもいいと思います。
リストの大きさなどが勝手に変わるから実装したいということだと思うので、それが変わらないようにすればいいと思います
その他 編集/実行
・コスチュームエディターの大きさを変数のスライダーみたいな感じで細かく変更できるようにしてほしい//用途不明
→提案内容の分かる方、説明お願いします。
サイズを大きくするときに端のドラッグ以外にも、スライダーでできるようにするor数値入力。SVGを読み込んで大きすぎ、エディターをはみ出して端もつかめない場合(経験済み)などに役立つ。
話す
・トピックの連続建て不可//徳子ぉがあるため不要
→提案内容の分かる方、説明お願いします。
スパム防止として、追加に賛成です。600秒などはどうでしょう。(New Scratcherの120秒ルールは過去は600秒)
60秒ではなぜ短いとおもうのですか。
10分は長すぎますよ。
10分でもいいと思います。そもそもトピックは頻繁に作るものではないと思うので1日でも構わないと思います。
600秒に賛成です。
追加賛成です。
1日に賛成
・自分がオーナーのスタジオに投稿されたコメントの削除//コメントは皆のものだから、コメントはけせなくしたほうがよいとおもう。
→削除賛成。異論なければ却下に移動したいと思います。
削除賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
その他
・リミックス時に過去の「メモと作品への貢献」が変更できないようにする//追加はできるようにすべき
→削除賛成。異論なければ却下に移動したいと思います。
これは追加に賛成です。基本、リミックスには元作品でクレジットのある素材が使われているので、クレジットが消えたら故意ではないのに削除対象となってしまいます。過去の記述の前に追加という形なら大丈夫と思います。
クレジットは残すべきだと思います。（その素材を消さない限り）しかし、合作などではメモがどんどん増えてしまいます。
「消さないように」ではなく、リミックス元のクレジットが継承できるようにしたほうがいいと思います。
追加に賛成
・私の作品で、昇順/降順の切り替え可能//人気のない作品、古い作品、リミックスされていない等の順で見る意図が不明
→提案内容の分かる方、説明お願いします。
作品の検索機能があればそれでいいのですが、要は「作品を手早く見つける手段」なのではないのでしょうか。
Last edited by kan217 (Sept. 26, 2017 07:59:15)
ディスカッションフォーラムを使用する前にまずはこちらをご覧ください
ディスカッションフォーラムでの非常に重要なルールが書いてあります
ディスカッションフォーラムでの非常に重要なルールが書いてあります
質問コーナー お知らせ・ニュース Scratchのコミニュティをより良い所にするために 副題用 オフトピ専 フォーラム使用時の注意について
scratch3.0への提案 scratch2.0への提案 宣伝、告知、依頼をするコーナー 公式のテストトピック バグ報告コーナー scratch以外のことの話
scratch3.0への提案 scratch2.0への提案 宣伝、告知、依頼をするコーナー 公式のテストトピック バグ報告コーナー scratch以外のことの話
5000兆円欲しい!! これは署名です。いちいち自分で書いているわけではありません。
- mochimochiking
-
Scratcher
1000+ posts
scratch2.0の提案
mochimochiking さんからの削除対象案についての検討
赤文字がinokingのコメントです。
青文字がapple502jさんのコメントです。
橙文字がmochimochikingさんのコメントです。
緑文字がkaaramochiさんのコメントです。
オリーブ文字がfine316さんのコメントです。
灰文字がMMGISSさんのコメントです。
紫がkan217さんのコメントです。
見た目カテゴリ
スプライトのすべての部分を指定色にすると推測できます。
なるほど。しかし汎用性があるかに疑問が残りますね。
+複数の色があった場合、どう処理されるかが不明です。
スプライトの透明以外のすべてを指定色で塗りつぶすのだと思います。どういうときに必要ですか？
必要性はないと思います
調べるカテゴリ
可能性として、スペース区切りがあります。ただし、技術上できるかは不明です。
上の二つは縦に()伸びるなどのブロックと合わせて検討する方がいいと思います。
旧ブロック (note::sensing) のことでしょうか。
スペース区切りはどうでしょう。
スペース区切りを行うとき、「スペース」キーや「上向き矢印」キーなどを記述する言語(英語に揃える？)に疑問が残ります。
a b c enterといった感じでしょうか。押されている瞬間だけ反応するんですか？
押されている間ずっと反応するようにしたほうがわかりやすいと思います。
Windowsキーなど特定のプラットホームのみに存在するキーのときも疑問が残ります。
表記をany_special_keyなどとすることで無理やり押さえ込むことはできます。
Scratchは配列を返す言語仕様出はないため実装は難しい。
ホイールがついていないマウスもあります。
ホイールがないならその機能が使えないだけなので支障はないと思います。
ホイール機能が導入されたときに、たとえばホイール機能がプロジェクトでの重要な役割を担っているプロジェクトが作成されることが考えられます。
そうすると、ホイールが使えない一部のユーザーはそのプロジェクトができなくなってしまうと思います。
現状でも例えばマイクやカメラで同様の状況が発生しています。
変数カテゴリ
他にはどのような意見がありますか。
https://scratch.mit.edu/discuss/post/2803828/ が関係するかなと。
変数やリストの表示については https://scratch.mit.edu/discuss/post/2800013/ についても考慮お願いします。
上の三つは、実装されてもいいと思います。
上の三つの実装に賛成。
なぜですか。
上の二つは、どんなときに使うんでしょうか。
上の四つは、そこまで汎用性があるでしょうか。
値を変更する場合が思い付かない。故に要らないと思う。
上の二つは、実装されてもいいと思います。
リストの大きさなどが勝手に変わるから実装したいということだと思うので、それが変わらないようにすればいいと思います
紫に同意
その他 編集/実行
・コスチュームエディターの大きさを変数のスライダーみたいな感じで細かく変更できるようにしてほしい//用途不明
→提案内容の分かる方、説明お願いします。
サイズを大きくするときに端のドラッグ以外にも、スライダーでできるようにするor数値入力。SVGを読み込んで大きすぎ、エディターをはみ出して端もつかめない場合(経験済み)などに役立つ。
話す
・トピックの連続建て不可//徳子ぉがあるため不要
→提案内容の分かる方、説明お願いします。
スパム防止として、追加に賛成です。600秒などはどうでしょう。(New Scratcherの120秒ルールは過去は600秒)
60秒ではなぜ短いとおもうのですか。
10分は長すぎますよ。
10分でもいいと思います。そもそもトピックは頻繁に作るものではないと思うので1日でも構わないと思います。
600秒に賛成です。
追加賛成です。
1日に賛成
皆さん作成に賛成のようですので
・自分がオーナーのスタジオに投稿されたコメントの削除//コメントは皆のものだから、コメントはけせなくしたほうがよいとおもう。
→削除賛成。異論なければ却下に移動したいと思います。
削除賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
その他
・リミックス時に過去の「メモと作品への貢献」が変更できないようにする//追加はできるようにすべき
→削除賛成。異論なければ却下に移動したいと思います。
これは追加に賛成です。基本、リミックスには元作品でクレジットのある素材が使われているので、クレジットが消えたら故意ではないのに削除対象となってしまいます。過去の記述の前に追加という形なら大丈夫と思います。
クレジットは残すべきだと思います。（その素材を消さない限り）しかし、合作などではメモがどんどん増えてしまいます。
各自が１,2行ほどで記述すればそんなに長くならないのでは
「消さないように」ではなく、リミックス元のクレジットが継承できるようにしたほうがいいと思います。
追加に賛成
・私の作品で、昇順/降順の切り替え可能//人気のない作品、古い作品、リミックスされていない等の順で見る意図が不明
→提案内容の分かる方、説明お願いします。
作品の検索機能があればそれでいいのですが、要は「作品を手早く見つける手段」なのではないのでしょうか。
それでは、この提案却下し、私の作品の検索機能を追加でいいですか。
赤文字がinokingのコメントです。
青文字がapple502jさんのコメントです。
橙文字がmochimochikingさんのコメントです。
緑文字がkaaramochiさんのコメントです。
オリーブ文字がfine316さんのコメントです。
灰文字がMMGISSさんのコメントです。
紫がkan217さんのコメントです。
見た目カテゴリ
このスプライトの色を [#000000] にする ::looks//透明色とのグラデーションの場合、どこまでが「このスプライトなのか」→提案内容の分かる方、説明お願いします。
スプライトのすべての部分を指定色にすると推測できます。
なるほど。しかし汎用性があるかに疑問が残りますね。
+複数の色があった場合、どう処理されるかが不明です。
スプライトの透明以外のすべてを指定色で塗りつぶすのだと思います。どういうときに必要ですか？
必要性はないと思います
調べるカテゴリ
<触れた色 ::sensing>//複数あるときに疑問→提案内容の分かる方、説明お願いします。
可能性として、スペース区切りがあります。ただし、技術上できるかは不明です。
(スプライトの [縦の大きさ v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討
(スプライトの [横の大きさ v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討
上の二つは縦に()伸びるなどのブロックと合わせて検討する方がいいと思います。
(スプライトの [面積 v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討
(マイクの音の高さ ::sound)//音は複数の周波数で構成されているため何を返すのか疑問→提案内容の分かる方、説明お願いします。
旧ブロック (note::sensing) のことでしょうか。
(押されたキー :: sensing)//複数あるときに疑問→提案内容の分かる方、説明お願いします。
スペース区切りはどうでしょう。
スペース区切りを行うとき、「スペース」キーや「上向き矢印」キーなどを記述する言語(英語に揃える？)に疑問が残ります。
a b c enterといった感じでしょうか。押されている瞬間だけ反応するんですか？
押されている間ずっと反応するようにしたほうがわかりやすいと思います。
Windowsキーなど特定のプラットホームのみに存在するキーのときも疑問が残ります。
表記をany_special_keyなどとすることで無理やり押さえ込むことはできます。
Scratchは配列を返す言語仕様出はないため実装は難しい。
<[コスチューム1 v]の[Sprite1 v]に触れた :: sensing>//簡単なスクリプトで実装可能→簡単かどうかは分かりませんが汎用性がないと思います。
(マウスホイールの移動量 :: sensing)//xかyか何を返すのか疑問→ユーザーがマウスホイールを 1 目盛り回すごとにスクロールする行数のことです。
ホイールがついていないマウスもあります。
ホイールがないならその機能が使えないだけなので支障はないと思います。
ホイール機能が導入されたときに、たとえばホイール機能がプロジェクトでの重要な役割を担っているプロジェクトが作成されることが考えられます。
そうすると、ホイールが使えない一部のユーザーはそのプロジェクトができなくなってしまうと思います。
現状でも例えばマイクやカメラで同様の状況が発生しています。
変数カテゴリ
変数 [ v] のx座標を () に、y座標を () にする ::variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
他にはどのような意見がありますか。
https://scratch.mit.edu/discuss/post/2803828/ が関係するかなと。
変数やリストの表示については https://scratch.mit.edu/discuss/post/2800013/ についても考慮お願いします。
(変数 [ v] のx座標 ::variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
(変数 [ v] のy座標 ::variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の三つは、実装されてもいいと思います。
上の三つの実装に賛成。
なぜですか。
変数 [ v] の表示形式を [スライダー v] にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
(変数 [ v] の表示形式::variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の二つは、どんなときに使うんでしょうか。
[変数 v] のスライダーの最小値を (0) にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
[変数 v] のスライダーの最大値を (0) にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
([変数 v] のスライダーの最小値 :: variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
([変数 v] のスライダーの最大値 :: variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の四つは、そこまで汎用性があるでしょうか。
値を変更する場合が思い付かない。故に要らないと思う。
<変数 [ v] がクリックされた :: variables>//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
リスト [ v] のx座標を () に、y座標を () にする ::list//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
リスト [ v] の縦幅を () に、横幅を () にする ::list//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の二つは、実装されてもいいと思います。
リストの大きさなどが勝手に変わるから実装したいということだと思うので、それが変わらないようにすればいいと思います
紫に同意
その他 編集/実行
・コスチュームエディターの大きさを変数のスライダーみたいな感じで細かく変更できるようにしてほしい//用途不明
→提案内容の分かる方、説明お願いします。
サイズを大きくするときに端のドラッグ以外にも、スライダーでできるようにするor数値入力。SVGを読み込んで大きすぎ、エディターをはみ出して端もつかめない場合(経験済み)などに役立つ。
話す
・トピックの連続建て不可//徳子ぉがあるため不要
→提案内容の分かる方、説明お願いします。
スパム防止として、追加に賛成です。600秒などはどうでしょう。(New Scratcherの120秒ルールは過去は600秒)
60秒ではなぜ短いとおもうのですか。
10分は長すぎますよ。
10分でもいいと思います。そもそもトピックは頻繁に作るものではないと思うので1日でも構わないと思います。
600秒に賛成です。
追加賛成です。
1日に賛成
皆さん作成に賛成のようですので
・自分がオーナーのスタジオに投稿されたコメントの削除//コメントは皆のものだから、コメントはけせなくしたほうがよいとおもう。
→削除賛成。異論なければ却下に移動したいと思います。
削除賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
その他
・リミックス時に過去の「メモと作品への貢献」が変更できないようにする//追加はできるようにすべき
→削除賛成。異論なければ却下に移動したいと思います。
これは追加に賛成です。基本、リミックスには元作品でクレジットのある素材が使われているので、クレジットが消えたら故意ではないのに削除対象となってしまいます。過去の記述の前に追加という形なら大丈夫と思います。
クレジットは残すべきだと思います。（その素材を消さない限り）しかし、合作などではメモがどんどん増えてしまいます。
各自が１,2行ほどで記述すればそんなに長くならないのでは
「消さないように」ではなく、リミックス元のクレジットが継承できるようにしたほうがいいと思います。
追加に賛成
・私の作品で、昇順/降順の切り替え可能//人気のない作品、古い作品、リミックスされていない等の順で見る意図が不明
→提案内容の分かる方、説明お願いします。
作品の検索機能があればそれでいいのですが、要は「作品を手早く見つける手段」なのではないのでしょうか。
それでは、この提案却下し、私の作品の検索機能を追加でいいですか。
undefined
- inoking
-
Scratcher
1000+ posts
scratch2.0の提案
いえ。裁判と言うのは二種類有りまして，スレ違いなので一言にしますが、民事裁判も通常の話し合いで解決できない時の「最終手段」です。
民事裁判と刑事裁判です。刑事裁判の方をみなさん思い浮かべ，報告をこちらだけでやっているようなものだと思うのかもしれませんが，僕が言っているのは，民事裁判です。和解に導くために裁判官が仲介に入るものです。ですから，報告はできるだけ避けたいので，削除可能がいいです。
自分に都合の悪いコメントとはたとえばどのようなものですか？不適切な言動を指摘した際に、後で指摘コメントごと消されていました。
それにより、指摘があった事実も もみ消されてしまいました。
自分の個人情報を自分のプロフィールに書かれた場合，消せた方がいいではないですか。その場合は即刻報告して削除してもらえばよいでしょう。
重要性の高いものはすぐ対応してくれると思われます（若干のタイムラグは発生しますが
書き込んだ相手にはアカウント凍結のような措置も取らないといけないので
書き込みがあった事実も消えてしまうのはよろしくありません）。
削除できるということは安易な書き込みを助長することにもなります。
これは署名と呼ばれるもので投稿本文とは関係ありません。
Scratch は「世界最大の子ども向けコーディングコミュニティーで、シンプルなビジュアルインターフェースを持ったコーディング言語」
つまり「子ども SNS」ではない
・「傾向」とは単に一定の基準で作品を並びかえただけのもので、ランキングでもなんでもない、ナンバーワンよりオンリーワンを目指してみては？
・「フォロー」とは他の Scratcher が何をしているかを簡単に確認するためのもので、「フォロワー」は「ファン」ではない
・「スタジオ」とは特定のテーマに沿って作品をまとめたり、共同制作したりするための場所
・「星」や「ハート」などを何かの見返りとすることは Scratch チームによって禁止されている
- itnkmkw
-
Scratcher
1000+ posts
scratch2.0の提案
最後に押されたキーにすればどうですか？僕はこれがなくて困ってます。(押されたキー :: sensing)//複数あるときに疑問→提案内容の分かる方、説明お願いします。
スペース区切りはどうでしょう。
スペース区切りを行うとき、「スペース」キーや「上向き矢印」キーなどを記述する言語(英語に揃える？)に疑問が残ります。
a b c enterといった感じでしょうか。押されている瞬間だけ反応するんですか？
押されている間ずっと反応するようにしたほうがわかりやすいと思います。
Windowsキーなど特定のプラットホームのみに存在するキーのときも疑問が残ります。
表記をany_special_keyなどとすることで無理やり押さえ込むことはできます。
トラウマは存在しない。存在するのは今だけなんだ。過去のトラウマが原因で今の行動をとってしまったんじゃない。
今，自分でその行動をとる判断をしたんだ。過去は関係ない。だから，トラウマに取りつかれるのはやめよう。今から変われるんだ。
Start in your life…
興味のある方はこちら。itnkmkw と一緒に 心 について考えるスタジオ
※この署名のメッセージは不定期で変更されています。もしかしたらあなたへのメッセージかもよ～^^
皆さ～ん!「聖書」と言う言葉を聞いてどう思いますか?興味のある方はここやココやここへ！
@itnkmkwと申します。沖縄在住（ホームスクーラー）です。心理学と音楽やってます。MIX依頼募集中！
《コミュニティーをより良い所にするために》Scratch に関係ないトピックについての意見交換所では議事進行役を務めております（名ばかりですが）。どーぞよろしく
最近プロジェクト作ってませんが、もうすぐ聖書RPGの製作を再開しますので…いまは彩雲が忙しいのだ。
- itnkmkw
-
Scratcher
1000+ posts
scratch2.0の提案
もみ消された時何がいけないのか知りたいです。その不適切な言動への指摘は，その人を傷つけた可能性はありませんか？アカウント凍結だなんて，してほしくないんです。それって，相手はもしかしたら困らせる気がなく書いてしまったのかもしれません。その責任追及は必要ですが凍結はやりすぎです。削除可能でないと。僕としては他人がやったことでも穏便にもみ消したいくらい。（第一目標は個人情報の流出を防ぐためだから。）もちろん，暴言を吐き，いくら指摘してもやめない人ならもうわかっているので別ですよ。でもそういう場合も裁判すればいいし（僕なら報告はしたくない）。裁判と言う言葉が悪いようですね。「他人の仲介がある話し合い」にしておきます。（でもそれって同じですよ。）あなたがこれ以上堂々巡りをしたくないとおっしゃるなら，これについてはもうコメントしませんが，僕は，こういう話し合いがディスカッションフォーラムの意義だと思っています。いえ。裁判と言うのは二種類有りまして，スレ違いなので一言にしますが、民事裁判も通常の話し合いで解決できない時の「最終手段」です。
民事裁判と刑事裁判です。刑事裁判の方をみなさん思い浮かべ，報告をこちらだけでやっているようなものだと思うのかもしれませんが，僕が言っているのは，民事裁判です。和解に導くために裁判官が仲介に入るものです。ですから，報告はできるだけ避けたいので，削除可能がいいです。自分に都合の悪いコメントとはたとえばどのようなものですか？不適切な言動を指摘した際に、後で指摘コメントごと消されていました。
それにより、指摘があった事実も もみ消されてしまいました。自分の個人情報を自分のプロフィールに書かれた場合，消せた方がいいではないですか。その場合は即刻報告して削除してもらえばよいでしょう。
重要性の高いものはすぐ対応してくれると思われます（若干のタイムラグは発生しますが
書き込んだ相手にはアカウント凍結のような措置も取らないといけないので
書き込みがあった事実も消えてしまうのはよろしくありません）。
削除できるということは安易な書き込みを助長することにもなります。
トラウマは存在しない。存在するのは今だけなんだ。過去のトラウマが原因で今の行動をとってしまったんじゃない。
今，自分でその行動をとる判断をしたんだ。過去は関係ない。だから，トラウマに取りつかれるのはやめよう。今から変われるんだ。
Start in your life…
興味のある方はこちら。itnkmkw と一緒に 心 について考えるスタジオ
※この署名のメッセージは不定期で変更されています。もしかしたらあなたへのメッセージかもよ～^^
皆さ～ん!「聖書」と言う言葉を聞いてどう思いますか?興味のある方はここやココやここへ！
@itnkmkwと申します。沖縄在住（ホームスクーラー）です。心理学と音楽やってます。MIX依頼募集中！
《コミュニティーをより良い所にするために》Scratch に関係ないトピックについての意見交換所では議事進行役を務めております（名ばかりですが）。どーぞよろしく
最近プロジェクト作ってませんが、もうすぐ聖書RPGの製作を再開しますので…いまは彩雲が忙しいのだ。
- fine316
-
Scratcher
1000+ posts
scratch2.0の提案
mochimochiking さんからの削除対象案についての検討
赤文字がinokingのコメントです。
青文字がapple502jさんのコメントです。
橙文字がmochimochikingさんのコメントです。
緑文字がkaaramochiさんのコメントです。
オリーブ文字がfine316さんのコメントです。
灰文字がMMGISSさんのコメントです。
紫文字がkan217さんのコメントです。
草色文字がikntmkwさんのコメントです。
見た目カテゴリ
スプライトのすべての部分を指定色にすると推測できます。
なるほど。しかし汎用性があるかに疑問が残りますね。
+複数の色があった場合、どう処理されるかが不明です。
スプライトの透明以外のすべてを指定色で塗りつぶすのだと思います。どういうときに必要ですか？
必要性はないと思います
色の効果・明るさの効果で充分と思います。
調べるカテゴリ
可能性として、スペース区切りがあります。ただし、技術上できるかは不明です。
上の二つは縦に()伸びるなどのブロックと合わせて検討する方がいいと思います。
旧ブロック (note::sensing) のことでしょうか。
スペース区切りはどうでしょう。
スペース区切りを行うとき、「スペース」キーや「上向き矢印」キーなどを記述する言語(英語に揃える？)に疑問が残ります。
a b c enterといった感じでしょうか。押されている瞬間だけ反応するんですか？
押されている間ずっと反応するようにしたほうがわかりやすいと思います。
Windowsキーなど特定のプラットホームのみに存在するキーのときも疑問が残ります。
表記をany_special_keyなどとすることで無理やり押さえ込むことはできます。
Scratchは配列を返す言語仕様出はないため実装は難しい。
最後に押されたキーにすればどうですか？ 僕はこれがなくて困ってます。
https://scratch.mit.edu/discuss/post/2812001/ に書いたとおり、3.0では作品側で用意できるようになるので不要と思います。
ホイールがついていないマウスもあります。
ホイールがないならその機能が使えないだけなので支障はないと思います。
ホイール機能が導入されたときに、たとえばホイール機能がプロジェクトでの重要な役割を担っているプロジェクトが作成されることが考えられます。
そうすると、ホイールが使えない一部のユーザーはそのプロジェクトができなくなってしまうと思います。
現状でも例えばマイクやカメラで同様の状況が発生しています。
マイク、カメラは認証が必要な特殊な機能です。しかし、マウスホイールは、すべての人がこの機能を使えると勘違いして組み込まれてしまう可能性があるかと思います。
変数カテゴリ
他にはどのような意見がありますか。
https://scratch.mit.edu/discuss/post/2803828/ が関係するかなと。
変数やリストの表示については https://scratch.mit.edu/discuss/post/2800013/ についても考慮お願いします。
上の三つは、実装されてもいいと思います。
上の三つの実装に賛成。
なぜですか。
上の二つは、どんなときに使うんでしょうか。
上の四つは、そこまで汎用性があるでしょうか。
値を変更する場合が思い付かない。故に要らないと思う。
上の二つは、実装されてもいいと思います。
リストの大きさなどが勝手に変わるから実装したいということだと思うので、それが変わらないようにすればいいと思います
紫に同意
変数・リストの見た目系ブロックは「表示する」「隠す」で充分と思います。座標や、クリックされたかどうかを判定する意図が不明ですし、そのために変数やリストがあるのではありません。
その他 編集/実行
・コスチュームエディターの大きさを変数のスライダーみたいな感じで細かく変更できるようにしてほしい//用途不明
→提案内容の分かる方、説明お願いします。
サイズを大きくするときに端のドラッグ以外にも、スライダーでできるようにするor数値入力。SVGを読み込んで大きすぎ、エディターをはみ出して端もつかめない場合(経験済み)などに役立つ。
話す
・トピックの連続建て不可//徳子ぉがあるため不要
→提案内容の分かる方、説明お願いします。
スパム防止として、追加に賛成です。600秒などはどうでしょう。(New Scratcherの120秒ルールは過去は600秒)
60秒ではなぜ短いとおもうのですか。
10分は長すぎますよ。
10分でもいいと思います。そもそもトピックは頻繁に作るものではないと思うので1日でも構わないと思います。
600秒に賛成です。
追加賛成です。
1日に賛成
皆さん作成に賛成のようですので
・自分がオーナーのスタジオに投稿されたコメントの削除//コメントは皆のものだから、コメントはけせなくしたほうがよいとおもう。
→削除賛成。異論なければ却下に移動したいと思います。
削除賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
その他
・リミックス時に過去の「メモと作品への貢献」が変更できないようにする//追加はできるようにすべき
→削除賛成。異論なければ却下に移動したいと思います。
これは追加に賛成です。基本、リミックスには元作品でクレジットのある素材が使われているので、クレジットが消えたら故意ではないのに削除対象となってしまいます。過去の記述の前に追加という形なら大丈夫と思います。
クレジットは残すべきだと思います。（その素材を消さない限り）しかし、合作などではメモがどんどん増えてしまいます。
各自が１,2行ほどで記述すればそんなに長くならないのでは
「消さないように」ではなく、リミックス元のクレジットが継承できるようにしたほうがいいと思います。
追加に賛成
・私の作品で、昇順/降順の切り替え可能//人気のない作品、古い作品、リミックスされていない等の順で見る意図が不明
→提案内容の分かる方、説明お願いします。
作品の検索機能があればそれでいいのですが、要は「作品を手早く見つける手段」なのではないのでしょうか。
それでは、この提案却下し、私の作品の検索機能を追加でいいですか。
赤文字がinokingのコメントです。
青文字がapple502jさんのコメントです。
橙文字がmochimochikingさんのコメントです。
緑文字がkaaramochiさんのコメントです。
オリーブ文字がfine316さんのコメントです。
灰文字がMMGISSさんのコメントです。
紫文字がkan217さんのコメントです。
草色文字がikntmkwさんのコメントです。
見た目カテゴリ
このスプライトの色を [#000000] にする ::looks//透明色とのグラデーションの場合、どこまでが「このスプライトなのか」→提案内容の分かる方、説明お願いします。
スプライトのすべての部分を指定色にすると推測できます。
なるほど。しかし汎用性があるかに疑問が残りますね。
+複数の色があった場合、どう処理されるかが不明です。
スプライトの透明以外のすべてを指定色で塗りつぶすのだと思います。どういうときに必要ですか？
必要性はないと思います
色の効果・明るさの効果で充分と思います。
調べるカテゴリ
<触れた色 ::sensing>//複数あるときに疑問→提案内容の分かる方、説明お願いします。
可能性として、スペース区切りがあります。ただし、技術上できるかは不明です。
(スプライトの [縦の大きさ v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討
(スプライトの [横の大きさ v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討
上の二つは縦に()伸びるなどのブロックと合わせて検討する方がいいと思います。
(スプライトの [面積 v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討
(マイクの音の高さ ::sound)//音は複数の周波数で構成されているため何を返すのか疑問→提案内容の分かる方、説明お願いします。
旧ブロック (note::sensing) のことでしょうか。
(押されたキー :: sensing)//複数あるときに疑問→提案内容の分かる方、説明お願いします。
スペース区切りはどうでしょう。
スペース区切りを行うとき、「スペース」キーや「上向き矢印」キーなどを記述する言語(英語に揃える？)に疑問が残ります。
a b c enterといった感じでしょうか。押されている瞬間だけ反応するんですか？
押されている間ずっと反応するようにしたほうがわかりやすいと思います。
Windowsキーなど特定のプラットホームのみに存在するキーのときも疑問が残ります。
表記をany_special_keyなどとすることで無理やり押さえ込むことはできます。
Scratchは配列を返す言語仕様出はないため実装は難しい。
最後に押されたキーにすればどうですか？ 僕はこれがなくて困ってます。
https://scratch.mit.edu/discuss/post/2812001/ に書いたとおり、3.0では作品側で用意できるようになるので不要と思います。
<[コスチューム1 v]の[Sprite1 v]に触れた :: sensing>//簡単なスクリプトで実装可能→簡単かどうかは分かりませんが汎用性がないと思います。
(マウスホイールの移動量 :: sensing)//xかyか何を返すのか疑問→ユーザーがマウスホイールを 1 目盛り回すごとにスクロールする行数のことです。
ホイールがついていないマウスもあります。
ホイールがないならその機能が使えないだけなので支障はないと思います。
ホイール機能が導入されたときに、たとえばホイール機能がプロジェクトでの重要な役割を担っているプロジェクトが作成されることが考えられます。
そうすると、ホイールが使えない一部のユーザーはそのプロジェクトができなくなってしまうと思います。
現状でも例えばマイクやカメラで同様の状況が発生しています。
マイク、カメラは認証が必要な特殊な機能です。しかし、マウスホイールは、すべての人がこの機能を使えると勘違いして組み込まれてしまう可能性があるかと思います。
変数カテゴリ
変数 [ v] のx座標を () に、y座標を () にする ::variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
他にはどのような意見がありますか。
https://scratch.mit.edu/discuss/post/2803828/ が関係するかなと。
変数やリストの表示については https://scratch.mit.edu/discuss/post/2800013/ についても考慮お願いします。
(変数 [ v] のx座標 ::variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
(変数 [ v] のy座標 ::variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の三つは、実装されてもいいと思います。
上の三つの実装に賛成。
なぜですか。
変数 [ v] の表示形式を [スライダー v] にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
(変数 [ v] の表示形式::variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の二つは、どんなときに使うんでしょうか。
[変数 v] のスライダーの最小値を (0) にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
[変数 v] のスライダーの最大値を (0) にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
([変数 v] のスライダーの最小値 :: variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
([変数 v] のスライダーの最大値 :: variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の四つは、そこまで汎用性があるでしょうか。
値を変更する場合が思い付かない。故に要らないと思う。
<変数 [ v] がクリックされた :: variables>//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
リスト [ v] のx座標を () に、y座標を () にする ::list//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
リスト [ v] の縦幅を () に、横幅を () にする ::list//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の二つは、実装されてもいいと思います。
リストの大きさなどが勝手に変わるから実装したいということだと思うので、それが変わらないようにすればいいと思います
紫に同意
変数・リストの見た目系ブロックは「表示する」「隠す」で充分と思います。座標や、クリックされたかどうかを判定する意図が不明ですし、そのために変数やリストがあるのではありません。
その他 編集/実行
・コスチュームエディターの大きさを変数のスライダーみたいな感じで細かく変更できるようにしてほしい//用途不明
→提案内容の分かる方、説明お願いします。
サイズを大きくするときに端のドラッグ以外にも、スライダーでできるようにするor数値入力。SVGを読み込んで大きすぎ、エディターをはみ出して端もつかめない場合(経験済み)などに役立つ。
話す
・トピックの連続建て不可//徳子ぉがあるため不要
→提案内容の分かる方、説明お願いします。
スパム防止として、追加に賛成です。600秒などはどうでしょう。(New Scratcherの120秒ルールは過去は600秒)
60秒ではなぜ短いとおもうのですか。
10分は長すぎますよ。
10分でもいいと思います。そもそもトピックは頻繁に作るものではないと思うので1日でも構わないと思います。
600秒に賛成です。
追加賛成です。
1日に賛成
皆さん作成に賛成のようですので
・自分がオーナーのスタジオに投稿されたコメントの削除//コメントは皆のものだから、コメントはけせなくしたほうがよいとおもう。
→削除賛成。異論なければ却下に移動したいと思います。
削除賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
その他
・リミックス時に過去の「メモと作品への貢献」が変更できないようにする//追加はできるようにすべき
→削除賛成。異論なければ却下に移動したいと思います。
これは追加に賛成です。基本、リミックスには元作品でクレジットのある素材が使われているので、クレジットが消えたら故意ではないのに削除対象となってしまいます。過去の記述の前に追加という形なら大丈夫と思います。
クレジットは残すべきだと思います。（その素材を消さない限り）しかし、合作などではメモがどんどん増えてしまいます。
各自が１,2行ほどで記述すればそんなに長くならないのでは
「消さないように」ではなく、リミックス元のクレジットが継承できるようにしたほうがいいと思います。
追加に賛成
・私の作品で、昇順/降順の切り替え可能//人気のない作品、古い作品、リミックスされていない等の順で見る意図が不明
→提案内容の分かる方、説明お願いします。
作品の検索機能があればそれでいいのですが、要は「作品を手早く見つける手段」なのではないのでしょうか。
それでは、この提案却下し、私の作品の検索機能を追加でいいですか。
AtCoder はいいぞ
- inoking
-
Scratcher
1000+ posts
scratch2.0の提案
もみ消された時何がいけないのか知りたいです。その不適切な言動への指摘は，その人を傷つけた可能性はありませんか？アカウント凍結だなんて，してほしくないんです。それって，相手はもしかしたら困らせる気がなく書いてしまったのかもしれません。その責任追及は必要ですが凍結はやりすぎです。削除可能でないと。僕としては他人がやったことでも穏便にもみ消したいくらい。（第一目標は個人情報の流出を防ぐためだから。）もちろん，暴言を吐き，いくら指摘してもやめない人ならもうわかっているので別ですよ。でもそういう場合も裁判すればいいし（僕なら報告はしたくない）。裁判と言う言葉が悪いようですね。「他人の仲介がある話し合い」にしておきます。（でもそれって同じですよ。）あなたがこれ以上堂々巡りをしたくないとおっしゃるなら，これについてはもうコメントしませんが，僕は，こういう話し合いがディスカッションフォーラムの意義だと思っています。この議論を続けることは私はかまいませんが、トピ違いかもしれません。
まず、
もみ消された場合、
履歴が残らないので同様のことを繰り返しているのかどうかも分かりません。
また、「誰々が悪口を言った」等の申告が某所でされていることもありますが
既に削除されているため事実関係が把握できない、といったこともあるようです。
なお、
もみ消された指摘において私の指摘が相手を傷つけたのではないとは思いますが（もしそうなら逆指摘があるでしょうから）、
消されてしまっては確認のしようもありません。
次に、
報告に対する措置は Scratch チームが判断することです。
アカウント凍結のような措置は よほどの場合でしょう。
過去の履歴はそのための材料にもなります。
最後に、
話し合いも大事ですが
自分では想像もつかないような倫理観や価値観をもった相手が存在するのも事実です。
ルールにのっとったうえで
場合によっては毅然とした態度で臨むことも肝要かと思います。
これは署名と呼ばれるもので投稿本文とは関係ありません。
Scratch は「世界最大の子ども向けコーディングコミュニティーで、シンプルなビジュアルインターフェースを持ったコーディング言語」
つまり「子ども SNS」ではない
・「傾向」とは単に一定の基準で作品を並びかえただけのもので、ランキングでもなんでもない、ナンバーワンよりオンリーワンを目指してみては？
・「フォロー」とは他の Scratcher が何をしているかを簡単に確認するためのもので、「フォロワー」は「ファン」ではない
・「スタジオ」とは特定のテーマに沿って作品をまとめたり、共同制作したりするための場所
・「星」や「ハート」などを何かの見返りとすることは Scratch チームによって禁止されている
- mochimochiking
-
Scratcher
1000+ posts
scratch2.0の提案
#2260(113p?)から書き漏れ分(#3 24 28 35 77 123 199 1340 1342 2269 他にもあるかも…)のうち改めて考えて有用だと思ったものを挙げさせてもらいます。
exe出力//sb2->swf->exeの流れで現在も可
ボカロ
細筆
プログラム内での変数宣言
≠、≦、≧
3DSとの互換性
cookie//干渉しないようにたとえばproject属性だけ変更可能にするとか。
スタジオからぬけられるボタン
<表示された::looks>音声認識//難しい&発音記号で返すのか?
[]と喋る::sound//発音記号が引数か?それとも言語指定するのか?
塗りつぶす::pen
消しゴムを下ろす::pen
消しゴムを上げる::pen
x座標(),y座標()の点に[MS明朝 v]のフォントで()ポイントの大きさで[]と表示する::pen
<変数::variables>
<>のとき::events hat
中が見られたとき::events hat//オープンソースでなくなる恐れ
(カウンター::control)
抜け出す::control cap
始めに戻る::control cap
実行し、<>まで繰り返す{}::control
<このスプライトがクリックされた::sensing>
<[上の v]端にふれた::sensing>
<Scratcher::sensing>//クラウド変数が使えるものとしての
<ターボモード::sensing>
<中を見ている::sensing>
<大画面::sensing>
(世界標準時との時差::sensing)
(現在の[ミリ秒 v]::sensing)
(使用言語::sensing)
([ v]をunicodeで[デコード v]::sensing)
([]を計算::operators)
(<>なら[]でなければ[]::operators)
exe出力//sb2->swf->exeの流れで現在も可
ボカロ
細筆
プログラム内での変数宣言
≠、≦、≧
3DSとの互換性
cookie//干渉しないようにたとえばproject属性だけ変更可能にするとか。
スタジオからぬけられるボタン
undefined