[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
|