I have two requests for packaging style, after having delved through
100+ packages for the 3.9 stable universe. First, SAR's with fancy load-time scripts are often too smart for their own good when used in a package universe. A particular example of this is load-time options. Instead of having a single SAR with a load-time option, I wish people would divide the package into smaller packages. Then people can install precisely the component packages they want. As an example, if package Foo's tests are considered optional, then just make it two packages. Post Foo and Foo-Tests, where Foo-Tests depends on Foo. Second, we have a lot of readme windows popping up. A readme popup is very friendly if you are installing 1 package. However, with a package-browsing tool, it's not uncommon to install 5 or 10 packages at a time. When you do so, you end up with more windows than the user can possibly pay attention to. I was installing 100 at a time recently, and the result was just comical. I would like it if we had a registry of readme's, so that packages do not clutter up the main screen just to announce they are now loaded. This would help at package-loading time, and also it would mean people can actually find this documentation again weeks later after the package is installed. Barring such a tool, how about we limit ourselves to one readme per program? You an always add hyperlinks to the other ones. Okay, that's my wishes. Do with them as you will. Happy Squeaking, all! I've had fun browsing through all the great things everyone has posted. -Lex |
Thanks Lex! Great work.
|
In reply to this post by Lex Spoon-3
Lex Spoon a écrit :
> I have two requests for packaging style, after having delved through > 100+ packages for the 3.9 stable universe. > > First, SAR's with fancy load-time scripts are often too smart for > their own good when used in a package universe. A particular example > of this is load-time options. Instead of having a single SAR with a > load-time option, I wish people would divide the package into smaller > packages. Then people can install precisely the component packages > they want. As an example, if package Foo's tests are considered > optional, then just make it two packages. Post Foo and Foo-Tests, > where Foo-Tests depends on Foo. > > > Second, we have a lot of readme windows popping up. A readme popup is > very friendly if you are installing 1 package. However, with a > package-browsing tool, it's not uncommon to install 5 or 10 packages > at a time. When you do so, you end up with more windows than the user > can possibly pay attention to. I was installing 100 at a time > recently, and the result was just comical. > > > I would like it if we had a registry of readme's, so that packages do > not clutter up the main screen just to announce they are now loaded. > This would help at package-loading time, and also it would mean people > can actually find this documentation again weeks later after the > package is installed. Barring such a tool, how about we limit > ourselves to one readme per program? You an always add hyperlinks to > the other ones. There is ScriptManager to do that I think. I use it for the squeak-dev image and it is very interesting. Would be cool if a system like that is integrated into Squeak so that packages could just do a: self addReadmeTitled: 'Dynamic Protocols' containing: '...' -- Damien Cassou |
Damien Cassou <[hidden email]> writes:
> There is ScriptManager to do that I think. I use it for the squeak-dev > image and it is very interesting. Would be cool if a system like that > is integrated into Squeak so that packages could just do a: > > self addReadmeTitled: 'Dynamic Protocols' containing: '...' Ohh, nice. Of course, in a package-universes image, you can depend-on the ScriptManager package, and then do exactly the above in your package's post-load code. -Lex |
20 Feb 2007 18:32:27 -0500, Lex Spoon <[hidden email]>:
> Damien Cassou <[hidden email]> writes: > > There is ScriptManager to do that I think. I use it for the squeak-dev > > image and it is very interesting. Would be cool if a system like that > > is integrated into Squeak so that packages could just do a: > > > > self addReadmeTitled: 'Dynamic Protocols' containing: '...' > > Ohh, nice. > > Of course, in a package-universes image, you can depend-on the > ScriptManager package, and then do exactly the above in your package's > post-load code. But it would be better to have that message in the base image even if ScriptManager is not loaded. Then, the image would display a Workspace if such a class exist or would put everything in the transcript. -- Damien Cassou |
"Damien Cassou" <[hidden email]> writes:
> 20 Feb 2007 18:32:27 -0500, Lex Spoon <[hidden email]>: > > Damien Cassou <[hidden email]> writes: > > > There is ScriptManager to do that I think. I use it for the squeak-dev > > > image and it is very interesting. Would be cool if a system like that > > > is integrated into Squeak so that packages could just do a: > > > > > > self addReadmeTitled: 'Dynamic Protocols' containing: '...' > > > > Ohh, nice. > > > > Of course, in a package-universes image, you can depend-on the > > ScriptManager package, and then do exactly the above in your package's > > post-load code. > > But it would be better to have that message in the base image even if > ScriptManager is not loaded. Then, the image would display a Workspace > if such a class exist or would put everything in the transcript. If your package depends on ScriptManager, then ScriptManager will always be available by the time your package loads. Assuming ScriptManager is small, it should be no big deal to depend on it. If ScriptManager is big, then it would be better to have a small subsystem just for managing these readmes. This could initially be a separate package, and could later be included in the standard image if enough people use it. -Lex |
The problem with ScriptManager is that it's graphical. It's small, 1
class, but graphical. If I'm working on a package which does not depend on a graphical framework, it would be cool to not add a dependency just for the README. What I suggest is a method on Object or Class which prints its argument to the Transcript by default. Then, ScriptManager can override this method. It's not that clean but it's the only solution I found currently. 26 Feb 2007 14:44:05 -0500, Lex Spoon <[hidden email]>: > "Damien Cassou" <[hidden email]> writes: > > 20 Feb 2007 18:32:27 -0500, Lex Spoon <[hidden email]>: > > > Damien Cassou <[hidden email]> writes: > > > > There is ScriptManager to do that I think. I use it for the squeak-dev > > > > image and it is very interesting. Would be cool if a system like that > > > > is integrated into Squeak so that packages could just do a: > > > > > > > > self addReadmeTitled: 'Dynamic Protocols' containing: '...' > > > > > > Ohh, nice. > > > > > > Of course, in a package-universes image, you can depend-on the > > > ScriptManager package, and then do exactly the above in your package's > > > post-load code. > > > > But it would be better to have that message in the base image even if > > ScriptManager is not loaded. Then, the image would display a Workspace > > if such a class exist or would put everything in the transcript. > > > If your package depends on ScriptManager, then ScriptManager will > always be available by the time your package loads. > > Assuming ScriptManager is small, it should be no big deal to depend on > it. If ScriptManager is big, then it would be better to have a small > subsystem just for managing these readmes. This could initially be a > separate package, and could later be included in the standard image if > enough people use it. > > > -Lex > > > -- Damien Cassou |
In reply to this post by Lex Spoon-3
26 Feb 2007 14:44:05 -0500, Lex Spoon <[hidden email]>:
> Assuming ScriptManager is small, it should be no big deal to depend on > it. If ScriptManager is big, then it would be better to have a small > subsystem just for managing these readmes. This could initially be a > separate package, and could later be included in the standard image if > enough people use it. The problem with ScriptManager is that it's graphical. It's small, 1 class, but graphical. If I'm working on a package which does not depend on a graphical framework, it would be cool to not add a dependency just for the README. What I suggest is a method on Object or Class which prints its argument to the Transcript by default. Then, ScriptManager can override this method. It's not that clean but it's the only solution I found currently. -- Damien Cassou |
Free forum by Nabble | Edit this page |