Second try. Fixed silly bug.
from preamble:
"Change Set: QuickStartMenu Date: 30 July 2003 Author: Göran Krampe
Adds a nice little menu choice in the World menu showing all installed packages sorted by name with the version info within parentheses just like in SMLoader.
For each entry it will offer a Quickstart choice if there somewhere in the SM package description says:
[quickstart: MyFunkyClass class>>aSelectorDoingSomethingNice]
Note that only class side methods work (don't forget the 'class' word above."!
I like having the "installed packages..." item in the World menu. A command-key shortcut that brings up the installed-packages menu would be helpful.
< I'm a bug-fixing machine! >
This post brought to you by the BugFixArchiveViewer, a handy tool that makes it easy to comment on proposed fixes and enhancements for Squeak. For more information, check out the Web page for the BugFixArchiveViewer project: http://minnow.cc.gatech.edu/squeak/3214
< I'm a bug-fixing machine! >
Experimental, and I don't think it is really meant for inclusion.
< I'm a bug-fixing machine! >
This post brought to you by the BugFixArchiveViewer, a handy tool that makes it easy to comment on proposed fixes and enhancements for Squeak. For more information, check out the Web page for the BugFixArchiveViewer project: http://minnow.cc.gatech.edu/squeak/3214
< I'm a bug-fixing machine! >
Hi Göran,
It looks pretty good but there are a number of aspects that I don't really like too much. 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). 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.
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 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".
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).
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 ;-)
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of goran.krampe@bluefish.se Sent: Wednesday, July 30, 2003 2:52 PM To: squeak-dev@lists.squeakfoundation.org Subject: [ENH] QuickStartMenu
Second try. Fixed silly bug.
from preamble:
"Change Set: QuickStartMenu Date: 30 July 2003 Author: Göran Krampe
Adds a nice little menu choice in the World menu showing all installed packages sorted by name with the version info within parentheses just like in SMLoader.
For each entry it will offer a Quickstart choice if there somewhere in the SM package description says:
[quickstart: MyFunkyClass class>>aSelectorDoingSomethingNice]
Note that only class side methods work (don't forget the 'class' word above."!
"Andreas Raab" andreas.raab@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
It looks pretty good but there are a number of aspects that I don't really like too much.
Sigh... ;-)
Well, that's user interface design ;-) You do something criticize it and do it again.
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).
Interesting. Does this mean the annotations are more tightly integrated within SM1.1 than they are right now? Can you say a little more about the anticipated model we're following here (it may well be that I am just criticizing things that'll be solved by 1.1 implicitly)? I was under the assumption that these annotations would be pretty much "per package" as they are right now.
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.
I fully understand this ;-) Similarly, my critique was more along the lines of "okay, I kinda like this but..."
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.
That would be terrific.
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.
Well, that wasn't quite my point. It was more aimed at "release specific" information. If SM 1.1 is able to deal with it this wouldn't be a problem at all. I was just thinking that when you do development it would be a shame if projects which are actively documented would break first.
Yes. Fudging with special markup etc inside a description is a "hack".
Do you have a more elaborate mechanism for this already worked out?
Cheers, - Andreas
"Andreas Raab" andreas.raab@gmx.de wrote:
It looks pretty good but there are a number of aspects that I don't really like too much.
Sigh... ;-)
Well, that's user interface design ;-) You do something criticize it and do it again.
Indeed. Just kidding.
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).
Interesting. Does this mean the annotations are more tightly integrated within SM1.1 than they are right now? Can you say a little more about the
Now? Annotations? I am not sure what you mean. AFAIK there are no annotation mechanism today.
anticipated model we're following here (it may well be that I am just criticizing things that'll be solved by 1.1 implicitly)? I was under the assumption that these annotations would be pretty much "per package" as they are right now.
Nope. They are in fact per SMObject. And in SM1.1 it looks like this:
SMObject #('id' 'map' 'created' 'updated' 'name' 'summary' 'url') SMCategorizableObject #('categories' 'links') SMAccount #('initials' 'email' 'signature' 'password' 'newPassword' 'personalObjects') SMPackageRelease #('publisher' 'automaticVersion' 'version' 'note' 'downloadUrl' 'package') SMPersonalObject #('account') SMDocument #('description' 'author') SMPackage #('releases') SMResource #() SMEmbeddedResource #('content' 'version') SMExternalResource #('downloadUrl') SMCategory #('mandatory' 'subCategories' 'parent' 'objects')
The "links" instvar in SMCategorizableObject references other SMObjects. So this means SMAccounts, SMPackages, SMPackageReleases, SMEmbeddedResources and SMExternalResources can have links to other SMObjects. Typically the links refers to SMResources.
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.
I fully understand this ;-) Similarly, my critique was more along the lines of "okay, I kinda like this but..."
Goodie!
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.
That would be terrific.
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.
Well, that wasn't quite my point. It was more aimed at "release specific" information. If SM 1.1 is able to deal with it this wouldn't be a problem at all. I was just thinking that when you do development it would be a shame if projects which are actively documented would break first.
Yes. Fudging with special markup etc inside a description is a "hack".
Do you have a more elaborate mechanism for this already worked out?
Nope. Unless you are talking about the halfcooked SM1.1 on my hd. Next week will contain quite a lot of SM1.1 hacking - hopefully by the end of it a working alpha server will be up.
Cheers,
- Andreas
regards, Göran
squeak-dev@lists.squeakfoundation.org