[squeak-dev] Re: Testing Seaside in Squeak4.3alpha-11321
ma.chris.m at gmail.com
Fri Jun 3 15:41:40 UTC 2011
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.
Another problem: Seaside also still references #tempScopedNames, a
method that Pharo renamed from #tempNames.
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).
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.
That way, we can minimize these kinds of stupid "I can't load XYZ"
conversations which consume our community's bandwidth..
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.
>> 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?
>> So either he has not published his update of OmniBrowser yet
>> (upstream?) or the configuration script takes a copy from another
>> 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
>> Colin Putney (one of the original authors who still maintains
>> OmniBrowser) keeps a repository of OmniBrowser at the wiresong
>> 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.
More information about the Squeak-dev