Scratch

bharvey wrote:

nXIII wrote:

– UTI declarations & document icons

I don't understand those.

I believe this is to register Snap! as the application to open Snap! files...

bharvey wrote:

– Native context menus
– Native menubar integration
– Native project notes editor

Ooh, you're going to have a fight with Jens about these.  I guess every free software application ends up having this conversation:  Should it look uniform across platforms, or should it look like every other application on platform P?  I confess that I use Aquamacs on my Mac, so I guess I'm on your side.

implementing your own menubar is the biggest mistake an open-source program can do. look what happens with Unity & LibreOffice, for example, not talking about all the weird bugs you have with the windows decorations when you drag tabs in chrome 

nXIII wrote:

Implementing your own anything is a big mistake when it already exists in the platform.

I don't think many projects implement their own GUI effectively, but one which DOES is Blender. The interface is so much more effective when it's platform-independent. I think Snap! has the ability to do the same.

Last edited by shadow_7283 (2012-11-25 19:11:03)

nXIII wrote:

Implementing your own anything is a big mistake when it already exists in the platform.

Umm.  This sounds like an overgeneralization to me.  What if the native whatever just isn't very good?  Like, say, what if it's a text editor that doesn't know about the proper indentation of your favorite programming language?  What if it's the MacOS support for the Airport Express that only lets it play sounds coming from iTunes?  What if it doesn't have both scroll arrows at both ends of scroll bars?  What if it doesn't give you a recursive submenu of panes under the System Preferences apple menu item?  I could go on forever.  What if the default-selected button is Don't Replace instead of Replace?  What if the OS doesn't provide keyboard shortcuts for the buttons in dialog boxes?  And, what if the company that provides the OS decides they want to make your computer behave like a d*** iPad and so you're stuck running an older version of the OS that maybe doesn't support whatever new feature you're using?

EDIT:  And why do I get "no such domain" when I click on the last button in your sig?

Last edited by bharvey (2012-11-25 20:23:56)

bharvey wrote:

nXIII wrote:

Implementing your own anything is a big mistake when it already exists in the platform.

Umm.  This sounds like an overgeneralization to me.  What if the native whatever just isn't very good?

It very rarely is (it's usually just different than whatever Microsoft decided was the best), and in most cases you'd be enhancing the functionality rather than reimplementing it.

What if it doesn't have both scroll arrows at both ends of scroll bars?

What if it doesn't need to?

What if it doesn't give you a recursive submenu of panes under the System Preferences apple menu item?  I could go on forever.  What if the default-selected button is Don't Replace instead of Replace?  What if the OS doesn't provide keyboard shortcuts for the buttons in dialog boxes?  And, what if the company that provides the OS decides they want to make your computer behave like a d*** iPad and so you're stuck running an older version of the OS that maybe doesn't support whatever new feature you're using?

These are all conscious decisions about the platform by which third-party software should abide.

EDIT:  And why do I get "no such domain" when I click on the last button in your sig?

Yeah, co.cc is down.

Last edited by nXIII (2012-11-25 20:58:45)

MathWizz wrote:

Flash isn't even required... http://www.html5rocks.com/en/tutorials/ … dia/intro/ Admittedly it's not widely supported yet, but it will be by the time Scratch 2.0 is ready to be released. 

Yes, that's been our strategy in general: do the right HTML5 thing and wait for the browsers to catch up. 

Platforms are like free lunches, making you owe favors.

Scratch is the single most awesome piece of Software I've seen, with the possible exception of Smalltalk. Scratch is remarkably popular, too. Scratch doesn't pop up OS-native menus, doesn't sport OS-native buttons, text elements, menu bars, file dialogs. Maybe Scratch is simply exceptional despite all of this. Or maybe mustering the courage to create your own platform sometimes does receive favorable user recognition.

Many commercial games I've seen use their own widgets, aren't "platform integrated", do not look and feel like MS-Excel, and are still extremely successful. Are they all making big mistakes?

I don't know.

The discussion whether it's better to be a platform team player or to *be* your own platform has been raging in the Smalltalk community forever. One of the motivations for creating Smalltalk in the first place was to get rid of the OS and make everything accessible in the programming language and its graphical IDE. That's why Smalltalk used to have its own windows, dialog boxes, menus and buttons. Historically, of course, the reason for having its own widgets was that Smalltalk was the first GUI anyway.

There are upshots and downsides to both ways.

Since Snap! is a web page and as such heavily sandboxed, we're not ever going to pretend that we're the OS, so we might as well use "native" platform stuff and not commit the "big mistake" of reinventing the wheel, right?

I don't know.

If the wheel had not been reinvented over and over again we'd still be riding Ox carts.

German author Cornelia Funke recently pointed out that readers of fantasy novels tend to be more politically active, because they are accustomed to comparing different worlds instead of accepting a single one.

Snap! is no silver bullet. It is just a world in which kids and grown-ups can safely explore aspects of computing. There are other worlds. Why don't you build one yourself!

Everything doesn't have to look like everything else.

Last edited by Jens (2012-11-26 06:37:33)

TRocket wrote:

Jens wrote:

Platforms are like free lunches, making you owe favors.

[...]

Everything doesn't have to look like everything else.

+1 I think that, especially with scratch, where it brings in a completely new block UI it makes more sense to use the, more similer feeling squeak GUI.

but the LAG -.-

This is a button. It is keyboard-accessible, shows a focus ring, and responds to mouse input in exactly the way users expect.


This is also a button. It is completely keyboard-inaccessible, doesn't have a focus ring, and responds to mouse input incorrectly.


This is a textbox. It is extensively keyboard accessible, has a focus ring, responds to mouse input correctly, and supports a huge number of input modes and sources. In addition, it offers undo/redo, clipboard access, spelling and grammar, automatic correction, text substitution, text transformations, text-to-speech, and sharing.


This is also a textbox. It is barely keyboard accessible, has no focus indicator, responds to mouse input incorrectly, and supports only a single input mode from a single input source. It doesn't support the clipboard, undo/redo, spelling and grammar, text-to-speech, or any of the others.


This is a block. This is a perfect example of an appropriate, well-implemented custom control. This block serves a purpose unique from any native control and allows users to manipulate scripts easily and intuitively.

Custom controls can be very useful if they serve a unique purpose and are well-implemented. However, if they are simply reimplementations of existing controls, users expect them to offer them all the features they get from their native counterparts. Unless they do this well on every platform, the application would be better off with native controls.

bharvey wrote:

How much of an upheaval to the Morphic underpinning of Snap! is it to use native controls?  Is this something for which there could be a checkbox in Preferences to make everyone happy?

You could probably do it just by having DOM elements follow the controls around and match their size; the preference would then just recurse through all the morphs and toggle DOM/morphic mode for everything that implemented it.

bharvey wrote:

nXIII wrote:

preferences just means I'm going to implement a native preference window rather than the current menu-based one.

Don't forget that some of the check boxes in the Edit menu are project-specific (e.g. Thread Safe Scripts) rather than user-specific.

But I suppose they could still be in the same Preferences window.

Oh, that's a good point. I'll probably do something like TextEdit (separate Document Properties and Preferences):

Last edited by nXIII (2012-11-26 14:02:50)

the upheaval would be with me.

Morphic isn't just a JavaScript library, it's Snap!'s kernel.

There are APIs for everything in HTML5, including the clipboard, files, audio, webcam, microphone, etc. etc. but they are in various states of development. I'm fine with using these APIs as they mature and become available. It's what using the web is all about.

So, someone enlightens us that no, web pages don't have to look the same in every browser. But I do want Snap! to really look the exact same everywhere.

There are also DOM elements for lots of things, with native implementations and lots of goodies (e.g. text-to-speech). And also with grave downsides. Just ask those who are really using them to build systems and not just shiny web pages. Talk about kludges like inline-SVGs to draw lines, about fiddling with CSS for all kinds of effects, talk about how different browsers interpret these things differently. Try using native text boxes in a block and then make a sprite "say" that block, or take a picture of it, scale that down to a thumbnail, so it can be used as menu item. Try making a native text element display placeholders for blanks. Yeah, you'll succeed, but that's not even starting with building a system, let alone maintaining it and taking it further.

So, some buttons in Snap! don't always have keyboard control because keyboard input is directed to somewhere else, e.g. the stage! Your Nexus 7's virtual keyboard isn't showing despite the fact that I [i]am already using native text widgets[i] for text entry capturing! Claiming that widgets respond to mouse input "incorrectly" just because it differs from what your OS does disappoints me.

Yes, technically you can mix Morphic with native controls.

The Lively Kernel 2 is a whole Morphic system made with native DOM elements. Try understanding any part of it, try creating your own world in it. Something easy like, say, a kid's programming language. Check out their forums. People have been converting to Morphic.js because it's a system that works and can be understood in a weekend.

I am keeping Snap! small, snazzy and so easy to understand, that even hobbyist kids are able to play with its source. If everybody's so excited about native platforms, what on earth are they still doing here? Scratch never was and for sure won't be "native" anytime soon!

If you start polluting Snap! with the DOM, I'm out.

Jens wrote:

Your Nexus 7's virtual keyboard isn't showing despite the fact that I am already using native text widgets for text entry capturing!

Ah.  Okay, I've never really understood this issue -- it just totally bums me out that I got this tablet and can't use it!  But if Nathan's go-native plan isn't going to fix it, then I agree that we have enough trouble trying to interface smoothly with four-plus browsers, never mind that times three-plus operating systems.

I may still find nXIII's plan useful for airplane mode on my Mac, though.  Especially if it really dynamically stays up to date with mainline Snap! updates.  Although I'd like "work offline" working smoothly even better.  (Want to do that for us, n?)