[squeak-dev] [ANN] OmniBrowser 2.0.3

Hi all,

I'm happy to announce a new release of OmniBrowser. It's been quite a  
while since the last official release, and that has force folks that  
want to run the current code base to download and install directly  
from the Monticello repositories used for development. There have been  
a lot of contributors, each pulling in different directions, and it's  
been difficult for the various Squeak distributions that use  
OmniBrowser to put together a coherent installation. I think moving to  
more formal release practices, with explicit version numbers,  
supported platforms, release testing and so on will make it a lot  
easier to install and use OmniBrowser without having to understand the  
ins and outs of the code base and development community.

In putting together this release, I wanted to tighten up and repackage  
the existing functionality–b=new features can wait until 2.1.  I've  
tried to find the best mix of framework flexibility, browser features,  
code quality and performance that I could. This has meant cutting some  
features, and probably will mean further simplification and  
streamlining in subsequent releases. It'll also mean pulling  
OmniBrowser "extensions" into the standard distribution as the become  
stable.

This is the third release in the 2.0 series; the first two releases  
were "private" releases announced only on the omnibrowser-dev list, to  
gain feedback and flush out issues with the distribution format.

Download it from:  http://www.wiresong.ca/static/releases/OmniBrowser-2.0.3.zip

Colin

Hi Colin -

Just a small note: It would be helpful if you could provide the SAR as a
separate download instead of only packaged up inside the zip. I was
trying to create a scripted install of OB and it turned out to be a pain
because it's zipped in addition to sar-ed ;-)

Thanks,
   - Andreas

Colin Putney wrote:

On 2-Sep-09, at 10:58 PM, Andreas Raab wrote:

> Just a small note: It would be helpful if you could provide the SAR  
> as a separate download instead of only packaged up inside the zip. I  
> was trying to create a scripted install of OB and it turned out to  
> be a pain because it's zipped in addition to sar-ed ;-)

Aha, that makes sense. So you'd like to see a plain SAR as well as the  
ZIP? I had hoped to have a single distribution, but perhaps that's not  
feasible. The text files that are included now aren't a big deal, but  
I plan to add a directory of HTML documentation as well. Here's some  
options:

1. Have separate downloads for users and integrators. The user-
oriented artefact would be a ZIP file similar to the one in 2.0.3,  
while the integrator-oriented artefact would be a SAR with just the  
code.

2. Have a single SAR that includes the documentation as well as the  
code. Installing would write the documentation out to disk.

3. Have the documentation reside on the web, and just include a URL in  
the SAR.

4. Have some sort of in-image documentation rather than HTML.

Thoughts?

Colin

On 2-Sep-09, at 10:58 PM, Andreas Raab wrote:

> Hi Colin -
>
> Just a small note: It would be helpful if you could provide the SAR  
> as a separate download instead of only packaged up inside the zip. I  
> was trying to create a scripted install of OB and it turned out to  
> be a pain because it's zipped in addition to sar-ed ;-)
>
> Thanks,
>  - Andreas

The SAR-only version is now available here:

http://www.wiresong.ca/static/releases/OmniBrowser-2.0.3.sar

In the next release, I'll make a version of the SAR that doesn't  
display the release notes. That should be more useful to people who  
are building images automatically.

Colin

Colin Putney wrote:
> Aha, that makes sense. So you'd like to see a plain SAR as well as the
> ZIP? I had hoped to have a single distribution, but perhaps that's not
> feasible. The text files that are included now aren't a big deal, but I
> plan to add a directory of HTML documentation as well. Here's some options:
>
> 1. Have separate downloads for users and integrators. The user-oriented
> artefact would be a ZIP file similar to the one in 2.0.3, while the
> integrator-oriented artefact would be a SAR with just the code.

Define "user-oriented artifact" ;-) I'm not exactly used to download zip
files containing Smalltalk source any longer. I haven't used those
file-ins forever, and instead I go straight to Universes, Squeaksource,
Installer or Squeak Map.

> 2. Have a single SAR that includes the documentation as well as the
> code. Installing would write the documentation out to disk.
>
> 3. Have the documentation reside on the web, and just include a URL in
> the SAR.
>
> 4. Have some sort of in-image documentation rather than HTML.
>
> Thoughts?

Easy answer: When was the last time that you've actually went to the
disk to find some documentation instead of typing it straight into
Google? I find myself typing "man chmod" into Google! ;-)

Seriously, put it online. It's where it belongs, it's where people will
look for it, it's where they expect to find it. It also means you can
add a wiki for user comments (I *really* like the PHP documentation for
that - there is always a user-contributed example to everything).

Cheers,
   - Andreas

Hi Colin,

On 27-Sep-09, at 2:41 PM, Bernhard Pieber wrote:

> One thing I don't like at all, though: the fact that some Monticello  
> packages are dirty after I install the .sar. With the new  
> development process I got used to the fact that only the packages I  
> work on are dirty. As an old ENVY user dirty packages make me very  
> nervous. ;-)

Good point. I guess the correct thing to do would be to test for the  
presence of external packages an only load them if necessary. I'll do  
that in the next release.

> However, I loaded OB-ExtDeps and OB-Umbrella from source.wiresong.ca/
> ob as you have explained on the OmniBrowser Development group. That  
> seemed to have worked. Do I have all the code from the release now?

Yes, along with some additional packages that are only necessary for  
development of OmniBrowser, particularly running the tests.

> At first I had tried only loading OB-Umbrella which did not work.  
> Wouldn't it be the best - as in least confusing - way to just load a  
> package named OmniBrowser from the repository source.wiresong.ca/ob?

Well, yes, that would certainly be less confusing. But OB is divided  
in to multiple packages for good reason. It's important to be able to  
load some of the packages but not all of them. It would be nice if the  
umbrella package were called OmniBrowser, but for historical reasons,  
a package with that name already exists. If we rename it, we loose the  
ability to merge the existing branches.

I'm sorry it wasn't immediately obvious how to set up an OmniBrowser  
development environment, but it's not actually that hard, and it will  
get easier as we refine the development and release procedures.

Colin

Am 28.09.2009 um 07:52 schrieb Colin Putney: Ah, ok. That is a great example why I think a first class renaming  
operation is so important for a VCS - instead of just removing and  
adding. Good names are so important that nothing should stand in the  
way of improving them. We talked about that in Toronto IIRC. Of course  
I know this is a very difficult feature to implement. Is there any  
chance MC2 will support it?

Maybe it would be an improvement to rename OB-Umbrella to  
OmniBrowserFull or OmniBrowserDevelopment, assuming that there are not  
many branches of OB-Umbrella to be merged?

> I'm sorry it wasn't immediately obvious how to set up an OmniBrowser  
> development environment, but it's not actually that hard, and it  
> will get easier as we refine the development and release procedures.
Hey, no need to feel sorry! I am always finding hair in a soup. ;-)  
Thanks for all your effort and for the release!!!

Cheers,
Bernhard

On 30-Sep-09, at 12:55 PM, Bernhard Pieber wrote:

>> Ah, ok. That is a great example why I think a first class renaming  
>> operation is so important for a VCS - instead of just removing and  
>> adding. Good names are so important that nothing should stand in  
>> the way of improving them. We talked about that in Toronto IIRC. Of  
>> course I know this is a very difficult feature to implement. Is  
>> there any chance MC2 will support it?

In some cases, yes. It will certainly handle renames of packages, so  
this issue with renames of packages will go away when (!) we move  
OmniBrowser development to MC2. It doesn't support explicit renames of  
classes, which, as you noted is a very hard problem. Given MC2's fine-
grained versioning, though, this may not turn out to be a big issue.

> Maybe it would be an improvement to rename OB-Umbrella to  
> OmniBrowserFull or OmniBrowserDevelopment, assuming that there are  
> not many branches of OB-Umbrella to be merged?

Perhaps. I'm leaning towards getting rid of the umbrella package  
entirely, and relying on Metacello, MonticelloConfigurations, or  
something of the sort.

Colin

Am 01.10.2009 um 18:37 schrieb Colin Putney:
> Perhaps. I'm leaning towards getting rid of the umbrella package  
> entirely, and relying on Metacello, MonticelloConfigurations, or  
> something of the sort.
For Metacello that might be a catch 22 because it relies on  
OmniBrowser. ;-)

Cheers,
Bernhard

On Fri, Oct 2, 2009 at 5:49 PM, Bernhard Pieber <[hidden email]> wrote:
> Am 01.10.2009 um 18:37 schrieb Colin Putney:
>>
>> Perhaps. I'm leaning towards getting rid of the umbrella package entirely,
>> and relying on Metacello, MonticelloConfigurations, or something of the
>> sort.
>
> For Metacello that might be a catch 22 because it relies on OmniBrowser. ;-)

Hopefully the OB part is separately loadable... :)

Julian

On 3-Oct-09, at 3:48 AM, Julian Fitzell wrote:

It is. There's one package that extends the OB system browser with  
some commands for working with Metacello projects. Not a big deal -  
that package is optional, and can be loaded after OB.