스냅블록

:information_source: 요약 사용자가 게시물에서 snapblocks를 사용할 수 있도록 허용합니다.
:hammer_and_wrench: 저장소 링크 GitHub - snap-blocks/snapblocks-discourse: snapblocks discourse plugin · GitHub
:open_book: 설치 가이드 Discourse에서 플러그인 설치 방법

기능

Snapblocksscratchblocks의 포크로, 텍스트를 Snap! 스크립트 이미지로 변환할 수 있도록 합니다. 이 Discourse 플러그인은 사용자가 게시물에서 snapblocks를 사용할 수 있게 해줍니다.

[snapblocks][/snapblocks] BBCode 태그 안에 snapblocks 코드를 입력하여 게시물에 snapblocks를 생성할 수 있습니다. 예를 들어:

[snapblocks]
move (10) steps
[/snapblocks]

대신 [scratchblocks][/scratchblocks]를 별칭으로 사용할 수도 있으며, 이는 비활성화할 수도 있습니다.

또한 [sb][/sb]를 사용하여 인라인으로 snapblocks 코드를 추가할 수도 있습니다.

Use the [sb]move (10) steps[/sb] block to move forward.

옵션

snapblocks가 렌더링되는 방식을 변경할 수 있는 몇 가지 설정이 있습니다.

  • 블록 스타일 (Block Style)
  • 블록 규모 (Block Scale)
  • 제브라 색칠 (Zebra Coloring)
  • 블록 줄바꿈 (Block Wrap)
  • 공백 표시 (Show Spaces)
  • 산타 모자 (Santa Hats)

많은 옵션은 snapblocks 스니펫에서도 사용할 수 있습니다.

[snapblocks blockStyle="snap-flat" wrap="true" wrapSize=100 zebra="true" showSpaces="false" santa="true"]
when flag clicked
if <[] = []> {
  forever {
    run ({} @addInput) with inputs [Hello world] @delInput @verticalEllipsis @addInput
  }
}
[/snapblocks]

기본 매개변수를 사용하여 블록 스타일을 설정할 수도 있습니다.

[snapblocks="snap-flat"]
move (10) steps
[/snapblocks]

설정

이름 설명
블록 스타일 (Block Style) 기본 블록 스타일입니다. snap, snap-flat, scratch2, scratch3, 또는 scratch3-hc일 수 있습니다.
블록 규모 (Block Scale) 기본 블록 이미지 규모입니다. 부동소수점 숫자여야 합니다.
제브라 색칠 (Zebra Coloring) 여러 블록이 동일한 색일 경우, 더 밝은 색으로 번갈아 표시합니다.
블록 줄바꿈 (Block Wrap) 블록이 너무 넓어지면 블록 부분을 새 줄로 줄바꿈합니다.
공백 표시 (Show Spaces) 입력값에서 공백을 점으로 표시합니다.
Scratchblock 별칭 [scratchblocks] 별칭을 활성화합니다.

변경 이력 (CHANGELOG)

  • 1.5.0
    • snapblocks를 v1.10.0으로 업데이트
    • snapblocks 라이브러리 로드 오류 수정 (잘못된 파일명 때문에 오류가 발생하고 있었습니다)
  • 1.4.1
    • 여러 줄 코드 스니펫 인용 수정
    • 블록 번역을 실제로 감지하도록 수정
  • 1.4.0
    • snapblocks 인용 개선
    • 블록 내 텍스트를 선택할 수 없습니다 (다만, 그 위로 드래그하여 전체 스크립트를 인용할 수는 있습니다).
  • 1.3.0
    • 설정에 “산타 모자” 옵션 추가
    • snapblocks 스니펫에 santa 옵션 추가
    • snapblocks를 1.8.0으로 업데이트
  • 1.2.0
    • [scratchblocks] 별칭을 전환할 수 있도록 허용 (마침내 방법을 찾았습니다).
    • snapblocks를 1.7.0으로 업데이트
  • 1.1.1
    • 넘치는 스크립트가 스크롤될 수 있도록 보장.
    • 툴바의 snapblocks 버튼을 사용할 때 실제 텍스트를 추가.
  • 1.1.0
    • snapblocks를 1.6.0으로 업데이트
  • 1.0.0
    • 초기 출시

할 일 (TODO)

  • [scratchblocks]에 대해 별도의 기본 스타일을 허용
14개의 좋아요

Are there any incompatibilities with scratchblocks that would suggest the need for a separate plugin for Scratch?

If not, it could be noted here and in the plugin’s README on GitHub.

1개의 좋아요

I’d say that the only incompatibilities are mainly just some minor syntax tweaks, like dropdown menus and the define block. For the most part, scratchblocks code is mostly compatible with snapblocks.

I do still think there should be a separate plugin for scratchblocks, since I know forums that are for scratch/scratch mods might not want to use snapblocks, since snapblocks is geared to work best for snap (and I have been lacking on the scratch styles polish), not to mention, I didn’t add the ability to switch the toolbar shortcut to use scratchblocks instead.

If anyone would like to try and create a scratchblocks plugin using this plugin as a base (I’m probably not going to get around to making one myself), I think it’s worth noting that the render function I used is not in the scratchblocks api, so it would take a bit more work than just dropping in scratchblocks.

1개의 좋아요

It appears, at first glance, that there is no objection to utilizing this plugin for initial experiments (my environment being a school setting) and only then investing time into a Scratch plugin should the necessity arise.

1개의 좋아요

Feature request: The block-style could be defined separately for the [scratchblocks] alias.
This would allow effortless usage of different styled Scratch and Snap! elements.

2개의 좋아요

That’s actually a good idea. I’ll look into adding that.

3개의 좋아요

서버 측 로직이 보이지 않는데, 테마 컴포넌트로 만드는 것이 더 나을 것 같습니다.

3개의 좋아요

이것은 태그 내부의 내용이 파싱되지 않도록 하기 위해 메시지 파서(message parser)에 연결되며, 동작 방식을 구성할 수 있는 다양한 옵션을 포함합니다. 또한 새로운 WYSIWYG 메시지 작성기 지원도 추가하고 싶지만, 이를 제대로 작동시키는 데 어려움을 겪고 있습니다. 그리고 포럼 관리자가 모든 테마마다 이를 개별적으로 활성화해야 하는 것은 원하지 않습니다. 그렇게 하면 문제와 혼란을 초래할 수 있기 때문입니다(이전에 그런 일이 발생한 것을 이미 목격한 적이 있습니다).

그러면 테마 컴포넌트의 기능에 대해 제가 잘못 이해하고 있는 부분이 있는 것일까요? 그리고 한 번 전역적으로 활성화하면 방치해도 되는(enable once globally and forget it) 형태로 만들 수 있을까요?

플러그인을 설치하는 것이 이보다 훨씬 번거롭고, Discourse.org 호스팅 플랜에서는 작동하지 않습니다.

게다가 대부분의 포럼은 활성 테마가 하나뿐인 것 같습니다.

테마 컴포넌트에는 설정이 있을 수 있으며, 플러그인의 자바스크립트 부분이 할 수 있는 모든 일을 수행할 수 있습니다. 현재 플러그인의 상태라면 어떤 기능도 잃지 않을 것입니다.

2개의 좋아요

플러그인 디렉터리에 리포지토리를 클론하는 것 아닌가? 그렇게 번거롭지 않다고 생각하는데. 다만 Discourse 호스팅 플랜에서는 작동하지 않는다는 점은 타당하다.

이 플러그인이 만들어졌던 포럼은 그렇지 않았다. 하지만 방금 확인해 보니, 내가 마지막으로 테마 컴포넌트를 다룰 때 이후로 테마 컴포넌트 설정 UI가 대대적으로 개편된 것 같아 기억보다 관리하기가 쉬워 보인다.

알겠다. 그러면 테마 컴포넌트로 다시 작성해 보겠지만, 다른 일정 때문에 당분간 손볼 수 없을 것 같다.

1개의 좋아요

모든 관리자가 커맨드 라인에 접근할 수 있는 것은 아니며, 접근할 수 있는 관리자들도 모두 그 사용에 익숙한 것은 아닙니다.

또한 재빌드가 필요하며, 이는 즉시 완료되지 않고 부수적인 영향을 미치며 잠재적으로 문제를 일으킬 수 있습니다.

플러그인 업데이트에도 재빌드가 필요한 반면, 테마 컴포넌트 업데이트는 버튼 한 번 클릭으로 끝납니다.

2개의 좋아요

백엔드 로직이 실제로 없으므로 나중에 제가 한번 시도해볼 수도 있겠습니다.

3개의 좋아요

그렇게 해 주시면 도움이 될 것 같습니다. 저는 discourse에 대해 당신보다 더 잘 알 수 있으니까요 (이 플러그인은 다른 플러그인들을 참고하면서 거의 즉석에서 만든 것입니다).

1개의 좋아요