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:
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
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
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:
- 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.
- Have a single SAR that includes the documentation as well as the
code. Installing would write the documentation out to disk.
- Have the documentation reside on the web, and just include a URL in
the SAR.
- 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
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
Hi Colin,
Thanks for releasing a new version of OmniBrowser. I just played with it a little in the Squeak3.10.2-trunk. It looks great with the icons and the refactoring commands. I especially like the fact, that the buttons height does not change when you resize the browser. ;-)
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. ;-)
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?
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?
Cheers, Bernhard
Am 02.09.2009 um 09:33 schrieb Colin Putney:
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
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:
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.
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 pieber@mac.com 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:
On Fri, Oct 2, 2009 at 5:49 PM, Bernhard Pieber pieber@mac.com 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... :)
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.
squeak-dev@lists.squeakfoundation.org