The ability to resize the working areas has made me think on alternative ways of layout to improve programming experience
At the moment, if you want to maximise the vertical script area - this is at the expense of blocks of the category selected - which is not ideal if your programming and wanting to pick and select blocks to drag down to the script area.
I'd like to suggest that the block picking area and the script area are side by side instead
This would leave the category area under used on the left so i'd propose moving that to be the top most pane across the whole screen (or if not - across the top of the blocks and script areas
Pane Layouts
Moderator: MSandro
Re: Pane Layouts
Having used and thought about this more - I've come to realise that the Scratch 1.4 layout is prob the best one as categories at the top still doesn't give full editing height to the scripting pane
With the new GP ability to resize the category/blocks panes of course, so we can widen them to see all the blocks in a category
With the new GP ability to resize the category/blocks panes of course, so we can widen them to see all the blocks in a category
Re: Pane Layouts
I'll think about other layouts. Meanwhile, I can change the resize limits so you can shrink the entire palette (and it's categories) to just 10 pixels high. If you also shrink the stage, you have a lot space for scripts. The "find" field is still available, and you can use that get blocks if you know their names. Beginners will want to keep the palette visible, but they are less likely to have a lot of scripts.
Re: Pane Layouts
Ta :)I'll think about other layouts. Meanwhile, I can change the resize limits so you can shrink the entire palette (and it's categories) to just 10 pixels high.
yes - but there seems to be limit on maximum scripting area width when GP is fully occupying the screenIf you also shrink the stage, you have a lot space for scripts.
This is as much as I can widen on on my Win10 machine
Re: Pane Layouts
Oh, right.
That width limit has to do with the maximum texture size.
Technical details: In order to get decent scrolling performance when there are a lot of scripts, GP caches an image of the entire scripting pane as a texture. However, the underlying graphics system GP uses can crash if you try to use a texture larger than that the graphics card supports. Thus, GP picks a conservative limit that should work on most graphics cards. It may be possible have GP get the actual limit from the card and allow you to go up to that limit. I can explore that option...
Meanwhile, the change I've just made will give you a bit more space in the short term.
That width limit has to do with the maximum texture size.
Technical details: In order to get decent scrolling performance when there are a lot of scripts, GP caches an image of the entire scripting pane as a texture. However, the underlying graphics system GP uses can crash if you try to use a texture larger than that the graphics card supports. Thus, GP picks a conservative limit that should work on most graphics cards. It may be possible have GP get the actual limit from the card and allow you to go up to that limit. I can explore that option...
Meanwhile, the change I've just made will give you a bit more space in the short term.