[ENH] QuickStartMenu

goran.krampe at bluefish.se goran.krampe at bluefish.se
Wed Jul 30 22:22:32 UTC 2003


"Andreas Raab" <andreas.raab at gmx.de> wrote:
> Hi Göran,
> 
> It looks pretty good but there are a number of aspects that I don't really
> like too much.

Sigh... ;-)

> One is a conceptional problem: Unless we have cards for each
> individual version of a package, updating an SM card from the server would
> lead people to think that there's a new quickstart available. Clicking on it
> would result in DNU unless they do have the very latest (very bad in the
> light of active development).

True. In SM1.1 this will not be a problem. There resources are linked
with package *releases* and not packages (well, can be linked to
packages too but in this case it would be dumb).

> Secondly, having only a single entry in that
> list seems like it's really not enough - given the menu, I would like to be
> able hook in there a few examples, tutorials, links etc.

That was the idea of course - I just wanted to show it can easily be
done. It was not a serious ENH - more like a prototype to play with.
  
> So how about this: The SM annotation could actually be links to *external*
> documentation for this package. In other words, we might use something like:
> 
> [doc: 'The Foo Bar Tutorial' http://minnow/squeak/1234]
> [doc: 'The Foo Bar Project' http://some.other.place/myProject.pr]
> [doc: 'The Foo Bar Package' http://map.sf.org/packagebyname/FooBarPackage]
> 
> for the attributation which makes it simple for the package maintainers to
> link external documentation into the UI. In addition to this, I still think

Well, again - sure. In thinking forward an SMResource can either be a
String (and be embedded in the map) or be a URL which of course can
point to anything like the examples above. And again - they would be
linked to package releases.

This is the basis for this mechanism. Currently we are just "emulating"
this to be able to play *right now* instead of waiting for SM1.1.

> we should have a registry for "built-in" documentation/examples etc. - all
> the stuff which is shipped with the package itself should be local to the
> version of the package and not reside on some "remote card".

Well, on the other hand I don't want a package to force feed my image
with unit tests, examples, tutorials, documentation etc. when I don't
need it.

> The above would separate out the issue of "documentation shipped with" and
> "documentation provided outside" of a package. Both are useful and needed
> and having the ability to link the two should prove really helpful. In
> addition, having the package maintainer "be in control" over the links
> provided should ensure a certain quality control (which I think is good).

Right.

> Cheers,
>   - Andreas
> 
> PS. As a completely OT afterthought, but stuff like the above is why I like
> YAML. It'd be sooooo nice if you could just write
> 
> menu:
> 	- title: The Foo Bar Tutorial
> 	  url: "http://foo.bar.org/"
> 	- title: The Foo Bar Project
> 	  utl: "http://foo.bar.org/"
> 
> in the SMCard ;-) Maybe we should just define [] as "YAML quotes"? ;-)
> 
> PPS. And if we're going to use those kinds of annotations more regularly we
> _have_ to think about a better way of describing them - this was supposed to
> be a quick hack not a long-term solution ;-)

Yes. Fudging with special markup etc inside a description is a "hack".

regards, Göran



More information about the Squeak-dev mailing list