jmoenig / Snap

a visual programming language inspired by Scratch
http://snap.berkeley.edu
GNU Affero General Public License v3.0
1.51k stars 745 forks source link

How to open a shared project saved by another user is not documented #1238

Closed kbakalar closed 5 years ago

kbakalar commented 8 years ago

It's clear from the SnapManual.pdf p. 59 how to share a project from the Save Project dialog and how to recognize and open a shared project in the Open Project dialog.

However, shared projects of user A do not automatically appear in the Open Projects dialog of an arbitrary user B. How does user A make his shared project visible to user B?

brianharvey commented 8 years ago

You grab the URL from the browser's URL bar and email it to your friend. We're hoping for a better solution at some point.

kbakalar commented 8 years ago

Can we assume the URL syntax is stable?

http://snap.berkeley.edu/snapsource/snap.html#present:Username=<user name>&ProjectName=<project name>

That is to say, if I give my friend my user name and a list of my shared projects, can he confidently load a project by constructing the required URL on this pattern?

brianharvey commented 8 years ago

Yes.

kbakalar commented 8 years ago

I have muddled things by reporting two problems at once. One was the functional question (how to...) and the other was the documentation issue (...is not documented [in SnapManual.pdf]). The question has been resolved, but not the documentation issue. Is this the appropriate forum for recording documentation issues?

brianharvey commented 8 years ago

Yes. The manual is way out of date, I know. It'll be my big project for next month. Thanks for pointing this out.

Klortho commented 8 years ago

Is the manual source hosted anywhere in the open? A lot of software projects are moving to open formats like Markdown, and hosting their documentation just as they do their source code. That way, you can benefit from pull requests, when people notice things that are out of date.

brianharvey commented 8 years ago

Short answer: No, not at this time.

Longer answer: Yeah, I see the advantages, and maybe after the major revision that we need to accompany the 4.1 release I'll try it. About open formats, though, I have to say, I first tried doing it in Open Office, and found that it was even worse than Word about not putting things where I wanted them. If I have to switch formatters, it'd be to TeX, which does exactly what you tell it to. (Not LaTeX, just TeX.) But there would be a huge startup cost, which I'm reluctant to undertake.

Klortho commented 8 years ago

I just came back to this page to apologize for my ignorance, because I just found the help/manual-LaTeX folder, and it looks like that is the source for the reference manual -- but now I'm confused.

brianharvey commented 8 years ago

That's a volunteer project. I'd sorta forgotten about it -- I should try printing that version and see how it looks. The pdf we have online came from MS Word. (Plus a lot of Acrobat fu to make it two orders of magnitude smaller than the version MS generates.)

cycomachead commented 8 years ago

@brianharvey @kbakalar I also have the following version, which is pretty much straight markdown

https://github.com/cycomachead/snap-manual

Viewable online here: https://www.gitbook.com/book/cycomachead/snap-manual/details

It was an auto-converted project so it's not perfect, but it could be an interesting format to consider.

I'm happy to consider pulling this into the same repo, or working on tweaking the settings / display, or whatever. IMO, in this case the lighter we go on customizations, the easier it will be to write. The GitBook format is pretty nice, and in it's current setup just doesn't take much to move to another format.

Klortho commented 8 years ago

Gitbook -- what a coincidence! I've just been playing with that for another application recently.

I really like this, but I would hesitate to use it unless it were officially adopted, or some automated way to pull in changes. But if the master copy is in Word, I think that would be unlikely.

@brianharvey , any chance you might give it a look? If your main concern is about layout, though, then you will be disappointed. Markdown doesn't do layout without extra layers or plugins. But, it's excellent for technical/reference documentation. And, actually, OTOH, looking at the existing manual, it doesn't seem like there's any fancy layout -- just inline and block-display images, mainly.

brianharvey commented 8 years ago

Most of the layout effort is invisible, but would be visible if I didn't do it -- bad page breaks, illustrations not on the same page as the related text, things like that. I do a lot of tweaking vertical spacing between paragraphs, and in a few extreme cases within paragraphs.

(I'm a typesetting fanatic. One of my first jobs was writing software to typeset mathematical equations, long before TeX. So things like bad kerning jump out of the page at me. And everything I write is set in Baskerville. :-) )

Don't get me wrong -- I hate Word. Every time I redo the table of contents I have to have a huge fight with it about where to put the column break. And I hate how it increases the line spacing when I put a picture of a block in a paragraph. But in my old age I'm too tired to tell TeX where to put pictures; I blush to admit that I've come to depend on WYSIWYG, which I hated when it was invented at PARC.

cycomachead commented 8 years ago

Most of the layout effort is invisible, but would be visible if I didn't do it -- bad page breaks, illustrations not on the same page as the related text, things like that. I do a lot of tweaking vertical spacing between paragraphs, and in a few extreme cases within paragraphs.

If we move to an online / electronic format, then most of the layout troubles go away. There's no need to worry about layout too much if we have screen-based reading. Personally, I find it WAY easier to read that way, and reflowing is a huge boon for accessibility because it's easier to change the font size.

brianharvey commented 8 years ago

Okay, then we need a solution that allows for great printed layout and also decent HTML. That could mean Word->{pdf,html} or TeX->{pdf,html} (using latex2html or something). Any other candidates?

Sorry, you youths have to put up with an old fogy who likes to curl up with the manual in bed. (And don't tell me about flexible displays.)

cycomachead commented 8 years ago

GitBook has a decent PDF exporter but it's not 100% perfect. I think we can probably make a workable PDF with it. You can view the automatic no frills one at the link jIshared but the page breaks are probably off. 

Michael Ball michaelball.co From a small device...

On Mon, Jun 13, 2016 at 4:26 PM -0700, "Brian Harvey" notifications@github.com wrote:

Okay, then we need a solution that allows for great printed layout and also decent HTML. That could mean Word->{pdf,html} or TeX->{pdf,html} (using latex2html or something). Any other candidates?

Sorry, you youths have to put up with an old fogy who likes to curl up with the manual in bed. (And don't tell me about flexible displays.)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

bromagosa commented 5 years ago

(trying to unclutter gh issues a little bit)

Closing this as the forum is a much more appropriate space for Q&A :)