On Fri, 3 Jun 2011, Chris Muller wrote:

> It's a shame that Seaside has a dependency on a particular UI tool
> framework at all.  Why?  For my own personal image-build, I simply
> exclude the few packages that initiate this dependency.  e.g., I have
> a (near) full-running Seaside without OmniBrowser.

Seaside itself doesn't depend on OmniBrowser, just the developement tools.

>
> Another problem:  Seaside also still references #tempScopedNames, a
> method that Pharo renamed from #tempNames.

Since it's being used from one of the platform specific packages for Pharo 
(Seaside-Pharo-Developement), I don't expect it to be fixed in the near 
future.

>
> The Seaside maintainers might be able to be convinced to remove
> Pharo-specific code.  If not, perhaps it can at least be split into
> separate platform-specific packages to help (although that might not
> help with the #tempScopedNames).

http://code.google.com/p/seaside/issues/detail?id=650

>
> Finally, Levente you're right.  The script provided by Seaside
> maintainers was not sustainable because it always loads "the latest"
> rather than a specific configuration.  We need both, and that is a
> practice I've been trying to advocate for a long time with use of
> SqueakMap.  Create one release called head which loads the latest and
> then other releases which are for legacy Squeak images (e.g., 4.2,
> 4.1) which load specific named versions.

I guess you're mixing things here. A Metacello configuration contains 
information for loading code into various smalltalks (Squeak, Pharo, 
Gemstone) and various versions per smalltalk (Squeak 4.1, 4.2, Pharo 1.1, 
1.2, etc). The real problem is MetacelloRepository, or the way it's being 
used. Since it's an MC repository, people can ignore or break other's 
work (both happened) resulting in issues like this.

So the simple solution is to be explicit and change the installer script 
from loading ConfigurationOfOmniBrowser, to load 
ConfigurationOfOmniBrowser-xyz.123. The same configuration should be able 
to load OB into Squeak 4.1, 4.2, head, etc.

What SqueakMap scripts lack and Metacello does pretty well is proper 
dependency handling. It's not enough to check if you have a given class in 
the system to decide if you have the proper version of the dependency 
loaded or not. E.g.: if I have some version of OCompletion loaded into my 
image and I want to load the latest OB, then I expect the loader script to 
update OCompletion to the minimal required version if my version is not 
sufficient.


Levente

>
> That way, we can minimize these kinds of stupid "I can't load XYZ"
> conversations which consume our community's bandwidth..
>
>  - Chris
>
>
> On Fri, Jun 3, 2011 at 3:28 AM, Levente Uzonyi <leves at elte.hu> wrote:
>> On Fri, 3 Jun 2011, Hannes Hirzel wrote:
>>
>>> On 6/3/11, Levente Uzonyi <leves at elte.hu> wrote:
>>>>
>>>> On Thu, 2 Jun 2011, Chris Muller wrote:
>>>>
>>>>> Extending the System workspace is obsolete and will be removed soon.
>>>>> You may load Seaside from SqueakMap.
>>>>
>>>> That doesn't solve this problem. The loader script on SqueakMap uses
>>>> an unspecified version of ConfigurationOfOmniBrowser. This shouldn't
>>>> really be a problem, but the version where I fixed the Squeak (and some
>>>> Pharo) part of it was simply ignored by others (Pharo devs). So loading
>>>> the newest version of ConfigurationOfOmniBrowser via Installer won't
>>>> work for Squeak. Other than that, the configuration is still loading the
>>>> same old mczs, which don't include the fix for the button bar.
>>>>
>>>>
>>>> Levente
>>>>
>>>>>
>>>
>>>
>>> Colin Putney wrote on the 19th of April in this thread that he has
>>> included the fix of Andreas.
>>
>> In that case ConfigurationOfOmniBrowser should be updated with the fixed
>> versions, then the SqueakMap script has to be changed, to explicitly load
>> that version of ConfigurationOfOmniBrowser.
>>
>> Is the list of the updated mczs available?
>>
>>
>> Levente
>>
>>> So either he has not published his update of OmniBrowser yet
>>> (upstream?) or the configuration script takes a copy from another
>>> repository.
>>>
>>> A note aside:
>>> OmniBrowser has its own UI construction framework which is the only
>>> one portable between Squeak and Pharo. Seaside uses it for the control
>>> panel
>>>
>>> Colin Putney (one of the original authors who still maintains
>>> OmniBrowser) keeps a repository of OmniBrowser at the wiresong
>>> repository.
>>>
>>> Lukas Renggli does a fork from time to time to his own repository and
>>> adds Pharo-specific things and other enhancements.
>>>
>>> And I think there is even a third one maintained by Pharo developers
>>> as Pharo is a moving target (Not sure, needs checking).
>>>
>>> So we need
>>>
>>> 1) That the fix by Andreas is included in OmniBrowser
>>> 2) That the load script picks the right version of OmniBrowser
>>>
>>> BTW it does not matter if the load script resides on Squeak map or is
>>> in the "Extending the system workspace". We need to make it work again
>>> in either case.
>>>
>>> --Hannes
>>>
>>>
>>
>