danielv at netvision.net.il wrote:
> =?ISO-8859-1?Q?G=F6ran_Hultgren?= <goran.hultgren at bluefish.se> wrote:
> > Hi all!
> > 
> > Just released SqueakMap with some nice/cool additions:
> > http://anakin.bluefish.se:8000/gohu/11
> > 
> > Don't miss the additional fix I threw up there too. Daniel - I have not
> > integrated you Loader yet
> That's okay, the nice thing about packages IMO is that they *can* be
> interdependent without being one huge integrated ball of mud... let
> them.

Sure.

> > - but this release should be interesting for you (a
> > number of the things we have been talking about are now reality).
> Yup, I saw, I liked, I integrated :-)
>  
> > I haven't updated the entry in SqueakMap itself yet though because this release
> > contains some fairly new code that I haven't had time to bang my keyboard on. :-)
> Well, you should, otherwise upgrading versions doesn't work. OTOH, maybe
> that's what you want...

I will package up release 6 and update the entry today.

> > - A new button has appeared in SMSqueakMapBrowser called "fast install package".
> > It has a menu (ripped off) similar to the "new morph..." menu. You simply select
> > the package you want and bam, there you go! Can't get any faster than that!
> > (need to add some "Cursor sleep" stuff there...)
> I like the way it clusters names. I think that's a much better way to
> cluster long menus than what is used in the World menu>open>file...
> thing (also used adding attachments in Celeste). We should switch to
> using that more often.

Then we really should refactor out that code - now it is too much of a
copy from "new morph...".

> [SqueakMap current-version information and upgrading]
> Unfortunately, this doesn't work too hot with optional version fields. I
> propose to either make versions mandatory (nahh...) or automatically
> substitute a server based time stamp when a version is missing. Or
> always?

Hmmm. I agree about the problem - I also noticed the problem but
"ignored" it to give it more thought.
I am not sure about the timestamps though...

> This also makes versionLabels less meaningful. Currently, for JDepper,
> #versionLable -> (->) if it is uninstalled. It would be better if there
> was always something on the right, and always something on the left if
> the package is installed. Which would automatically happen if time
> stamps were used when needed.

Yes, but the problem I have with stamps is that just correcting a
spelling mistake in a registration would trigger a "new version". I
don't like that. Making version mandatory would of course solve it, but
as you say - it feels a bit tough to require that field. Or?

Perhaps not. A simple checkbox could make SqueakMap copy the
documentpart of the download url (before known extensions) automatically
into the version field.

So, when you register a package you could use an url like:

ftp://yaddayadda/dir/mycoolthing.1.cs.gz

...and if you check "Use download filename as version name" then the
version field would become "mycoolthing.1".

And then make the version field mandatory of course. What do you say? I
think this is good - having an undisputed version field is probably a
good thing as long as people don't find it annoying to update it. This
way it is simple even for very small packages like single small
changesets.

> Probably the time stamps should be quite short, though, or it'll make a
> mess. (04aug02 is pretty complete, unambigous on both sides sides of the
> atlantic, and pretty short).

How about then having a third checkbox. No, wait. Let's make it a three
choice radio button instead! :-)

[ ] Pick version name from document name in download url (without
extensions).
[ ] Autogenerate version name from current time and date when dowload
url changes.
[ ] Enter version name manually, Version: [XXXXXXXXXXXXXX]

Or something like that.

> > Currently it shows installable packages (packages that some installer says it
> > can install), installed packages and upgradeable packages. Any choice tries to
> > install the latest version of that package - even if it is already installed.
> > Rather neat. The label between parentheses shows installed and/or available version.
> In SMLoader you can show a list of packages that are either uninstalled
> or upgradable (this will probably be my default view, since it seems the
> most useful, and I allow the composition of filters).

Sounds good.

> > Now I am off to Greece! Will be back on monday.
> Good release, I liked many things.

Thanks!

> About the installers and handling of existing changesets - 
> a. It would be nice to have the option of reusing the same changeset (by
> leaving the name unchanged).

Do you mean when an install of a cs clashes with an existing cs of same
name?
So are you proposing to install the cs "into" the existing one? Explain
further, please.

> b. Design wise, I think a tool class should probably not refer to
> FillInTheBlank. It should definitely not default to raising a GUI

Oops. Or not very OOPsy at all. :-)

> dialog, because that makes it un-reusable from other tools. It could,
> for example, raise an exception, and let the GUI set policy by catching
> it. A decorator could be used to set policy without knowing about the
> exception.

I will look into that. Could you elaborate on that last sentence?

> I'll post my updated SMLoader up for review soon. This time I'll add a
> SqueakMap entry :-)

:-)

> While I'm at it, about the package registration form - can you please either 
> hide mail addresses or not make the mandatory, or something similarly 
> protective of our privacy?

I have a plan for the emails - read on:
http://anakin.bluefish.se:8000/gohu/15

> Thanks.
> 
> > regards, Gsran
> 
> Daniel Vainsencher

regards, Göran