Hi
As Enrico mentioned that Pier does not load anymore in Squeak I did a test if Seaside loads and runs.
I could load Seaside into Squeak4.3-11321 (as of today) with the script taken from 'Extending the System'
"Seaside 3.0 http://www.seaside.st" (Installer ss project: 'MetacelloRepository') install: 'ConfigurationOfSeaside30'. (Smalltalk at: #ConfigurationOfSeaside30) load. (Smalltalk at: #WAPharoServerAdaptorBrowser) open.
I run all the test of the category Seaside-Tests
834 of 834 run and passed
However I cannot start an adaptor
menu 'Apps' / 'Seaside control panel'
add 'Adaptor' , e.g. WAComanceAdaptor
clicking on the 'start' button has no effect.
The feedback still says 'stopped'
Any suggestions how to proceed?
Thank you for the answer in advance
--Hannes
Hi Am 2011-04-19 um 16:34 schrieb Hannes Hirzel:
[…]
However I cannot start an adaptor
menu 'Apps' / 'Seaside control panel'
add 'Adaptor' , e.g. WAComanceAdaptor
clicking on the 'start' button has no effect.
The feedback still says 'stopped'
Any suggestions how to proceed?
Curously, the buttons and the righ-click commands do not work, I suspect some OB-proelems there.
What works is right-clik -> 'inspect' and then do-it 'self start'
the same holds for stopping.
So Long, -TObias
On 4/19/2011 17:06, Tobias Pape wrote:
Curously, the buttons and the righ-click commands do not work, I suspect some OB-problems there.
Yes, definitely. It appears as if the culprit is in the combination of OBButtonBar>>buttonFor: aCommand which will substitute #yourself as action selector when the button is inactive. However, later, when the button should be updated we hit an optimization in OBButtonBar>>updateCommands which attempts to avoid the full recreation of the buttons and uses OBButtonBar>>updateButton:for: which does not update the action selector. Curiously, the latter method has my initials on it :-) so I'm taking a bit responsibility here. I think we should change OBButtonBar>>updateButton:for: to say:
updateButton: aButton for: aCommand
^aButton model: aCommand; setBalloonText: aCommand longDescription; action: (aCommand isActive ifTrue: [ #execute ] ifFalse: [ #yourself ]); yourself
I'm not sure where to push this fix.
Cheers, - Andreas
On Tue, Apr 19, 2011 at 8:26 AM, Andreas Raab andreas.raab@gmx.de wrote:
On 4/19/2011 17:06, Tobias Pape wrote:
Curously, the buttons and the righ-click commands do not work, I suspect some OB-problems there.
Yes, definitely. It appears as if the culprit is in the combination of OBButtonBar>>buttonFor: aCommand which will substitute #yourself as action selector when the button is inactive. However, later, when the button should be updated we hit an optimization in OBButtonBar>>updateCommands which attempts to avoid the full recreation of the buttons and uses OBButtonBar>>updateButton:for: which does not update the action selector. Curiously, the latter method has my initials on it :-) so I'm taking a bit responsibility here. I think we should change OBButtonBar>>updateButton:for: to say:
updateButton: aButton for: aCommand
^aButton model: aCommand; setBalloonText: aCommand longDescription; action: (aCommand isActive ifTrue: [ #execute ] ifFalse: [ #yourself ]); yourself
I'm not sure where to push this fix.
The best place would be the OmniBrowser project on SqueakSource. It's world writable.
In this case though, don't bother, I'll just harvest the method above.
Colin
Hi - I just tested loading Seaside 3 from the "Extending the system" instructions in the latest 4.3 alpha (#11453), and the result is the same, the buttons in the seaside control panel are ineffective. The patch of Andreas solves it, is there a reason not to include this to trunk?
Stephane
Le 19 avr. 2011 à 17:26, Andreas Raab a écrit :
On 4/19/2011 17:06, Tobias Pape wrote:
Curously, the buttons and the righ-click commands do not work, I suspect some OB-problems there.
Yes, definitely. It appears as if the culprit is in the combination of OBButtonBar>>buttonFor: aCommand which will substitute #yourself as action selector when the button is inactive. However, later, when the button should be updated we hit an optimization in OBButtonBar>>updateCommands which attempts to avoid the full recreation of the buttons and uses OBButtonBar>>updateButton:for: which does not update the action selector. Curiously, the latter method has my initials on it :-) so I'm taking a bit responsibility here. I think we should change OBButtonBar>>updateButton:for: to say:
updateButton: aButton for: aCommand
^aButton model: aCommand; setBalloonText: aCommand longDescription; action: (aCommand isActive ifTrue: [ #execute ] ifFalse: [ #yourself ]); yourself
I'm not sure where to push this fix.
Cheers,
- Andreas
Extending the System workspace is obsolete and will be removed soon. You may load Seaside from SqueakMap.
On Thu, Jun 2, 2011 at 2:21 PM, Stephane stephane.schitter@free.fr wrote:
Hi - I just tested loading Seaside 3 from the "Extending the system" instructions in the latest 4.3 alpha (#11453), and the result is the same, the buttons in the seaside control panel are ineffective. The patch of Andreas solves it, is there a reason not to include this to trunk?
Stephane
Le 19 avr. 2011 à 17:26, Andreas Raab a écrit :
On 4/19/2011 17:06, Tobias Pape wrote:
Curously, the buttons and the righ-click commands do not work, I suspect some OB-problems there.
Yes, definitely. It appears as if the culprit is in the combination of OBButtonBar>>buttonFor: aCommand which will substitute #yourself as action selector when the button is inactive. However, later, when the button should be updated we hit an optimization in OBButtonBar>>updateCommands which attempts to avoid the full recreation of the buttons and uses OBButtonBar>>updateButton:for: which does not update the action selector. Curiously, the latter method has my initials on it :-) so I'm taking a bit responsibility here. I think we should change OBButtonBar>>updateButton:for: to say:
updateButton: aButton for: aCommand
^aButton model: aCommand; setBalloonText: aCommand longDescription; action: (aCommand isActive ifTrue: [ #execute ] ifFalse: [ #yourself ]); yourself
I'm not sure where to push this fix.
Cheers, - Andreas
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
On Thu, Jun 2, 2011 at 2:21 PM, Stephane stephane.schitter@free.fr wrote:
Hi - I just tested loading Seaside 3 from the "Extending the system" instructions in the latest 4.3 alpha (#11453), and the result is the same, the buttons in the seaside control panel are ineffective. The patch of Andreas solves it, is there a reason not to include this to trunk?
Stephane
Le 19 avr. 2011 ˙˙ 17:26, Andreas Raab a écrit :
On 4/19/2011 17:06, Tobias Pape wrote:
Curously, the buttons and the righ-click commands do not work, I suspect some OB-problems there.
Yes, definitely. It appears as if the culprit is in the combination of OBButtonBar>>buttonFor: aCommand which will substitute #yourself as action selector when the button is inactive. However, later, when the button should be updated we hit an optimization in OBButtonBar>>updateCommands which attempts to avoid the full recreation of the buttons and uses OBButtonBar>>updateButton:for: which does not update the action selector. Curiously, the latter method has my initials on it :-) so I'm taking a bit responsibility here. I think we should change OBButtonBar>>updateButton:for: to say:
updateButton: aButton for: aCommand
^aButton model: aCommand; setBalloonText: aCommand longDescription; action: (aCommand isActive ifTrue: [ #execute ] ifFalse: [ #yourself ]); yourself
I'm not sure where to push this fix.
Cheers, - Andreas
On 6/3/11, Levente Uzonyi leves@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. 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
On Fri, 3 Jun 2011, Hannes Hirzel wrote:
On 6/3/11, Levente Uzonyi leves@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
- That the fix by Andreas is included in OmniBrowser
- 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
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..
- Chris
On Fri, Jun 3, 2011 at 3:28 AM, Levente Uzonyi leves@elte.hu wrote:
On Fri, 3 Jun 2011, Hannes Hirzel wrote:
On 6/3/11, Levente Uzonyi leves@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
- That the fix by Andreas is included in OmniBrowser
- 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
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@elte.hu wrote:
On Fri, 3 Jun 2011, Hannes Hirzel wrote:
On 6/3/11, Levente Uzonyi leves@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
- That the fix by Andreas is included in OmniBrowser
- 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
----- Original Message ----- | From: "Levente Uzonyi" leves@elte.hu | To: "Chris Muller" ma.chris.m@gmail.com | Cc: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org | Sent: Friday, June 3, 2011 9:49:46 AM | Subject: Re: [squeak-dev] Re: Testing Seaside in Squeak4.3alpha-11321 | | On Fri, 3 Jun 2011, Chris Muller wrote: | <snip> | 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.
Levente,
I have been toying with the idea of making it possible to specify the version of the configuration along with the version of the package in Metacello, for exactly the reasons you are describing ...
Dale
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.
Lacking for what use-case? There are two use-cases which I've always said are being handled by properly-written SqueakMap installer scripts:
1) Merge latest code of a package and all of its dependencies into my image. 2) Load an exact version of a particular package as well as exact-versions of all of its dependencies into my image.
At the end of the day, these are the two use-cases that matter for most projectsand are handled fully by the SM installer scripts.
Just to be explicit, here is the loader script for the head release of Magma:
======= Magma load script ======== "Merge the latest Ma client server code." SMSqueakMap default installPackageNamed: 'Ma client server' version: 'head'.
"Merge the latest Magma client packages." MCMcmUpdater updateFromRepositories: #('http://www.squeaksource.com/Magma'). ===============================
It's a similar script for the dependent package, "Ma client server":
======= Ma client server load script ======== "Merge latest MaBase code." SMSqueakMap default installPackageNamed: 'MaBase' version: 'head'.
"Merge the latest Ma client server packages." MCMcmUpdater updateFromRepositories: #('http://www.squeaksource.com/MaClientServer'). ===============================
and so on for MaBase.
Now, maybe there are some projects which want to maintain _multiple branches_ and, therefore, another use-case is, 3) load the latest code of branch XYZ into my image, but not the latest code from branch ABC. Projects which need this are free to use Metacello, but that does not mean one should not refer to these branches (as well as prior versions) with scripts in the Catalog.
- Chris
On 6/3/11 4:07 AM, "Levente Uzonyi" leves@elte.hu wrote:
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
So do a thing which works in current Squeak via SqueakMap. If Pharopatas rip SqueakMap, good for they, we need concentrate on our own affairs.
Edgar
I have noticed that certain buttons in OmniBrowser under Squeak4.2+ don't work when clicked while the buttons work when the same OmniBrowser-based application is running in Pharo... I'm seeing this with the MetacelloBrowser ...
Anyway, I have gotten the impression, that someone has done some fairly recent work on getting OmniBrowser to work (again?) in Squeak4.x but haven't gotten around to tracking it down ... but then I don't even know if that work would address the problem:)
Dale
On 04/19/2011 07:34 AM, Hannes Hirzel wrote:
Hi
As Enrico mentioned that Pier does not load anymore in Squeak I did a test if Seaside loads and runs.
I could load Seaside into Squeak4.3-11321 (as of today) with the script taken from 'Extending the System'
"Seaside 3.0 http://www.seaside.st" (Installer ss project: 'MetacelloRepository') install: 'ConfigurationOfSeaside30'. (Smalltalk at: #ConfigurationOfSeaside30) load. (Smalltalk at: #WAPharoServerAdaptorBrowser) open.
I run all the test of the category Seaside-Tests
834 of 834 run and passed
However I cannot start an adaptor
menu 'Apps' / 'Seaside control panel'
add 'Adaptor' , e.g. WAComanceAdaptor
clicking on the 'start' button has no effect.
The feedback still says 'stopped'
Any suggestions how to proceed?
Thank you for the answer in advance
--Hannes
On Tue, Apr 19, 2011 at 8:31 AM, Dale Henrichs dhenrich@vmware.com wrote:
I have noticed that certain buttons in OmniBrowser under Squeak4.2+ don't work when clicked while the buttons work when the same OmniBrowser-based application is running in Pharo... I'm seeing this with the MetacelloBrowser ...
Anyway, I have gotten the impression, that someone has done some fairly recent work on getting OmniBrowser to work (again?) in Squeak4.x but haven't gotten around to tracking it down ... but then I don't even know if that work would address the problem:)
Yeah, I'm bringing Lukas' work over to the Squeak version and collecting bug reports/fixes. Hope to get a solid release together soon. If we can get that SqueakMap bug fixed, I'll post it there.
Colin
Thank you Tobias for the workaround, Andreas for the analysis of the bug and the fix and Colin for adding it to his current work of updating OmniBrowser for Squeak (again).
By using 'inspect' and 'self start' it works fine. For development and testing work this is OK.
--Hannes
On 4/19/11, Colin Putney colin@wiresong.com wrote:
On Tue, Apr 19, 2011 at 8:31 AM, Dale Henrichs dhenrich@vmware.com wrote:
I have noticed that certain buttons in OmniBrowser under Squeak4.2+ don't work when clicked while the buttons work when the same OmniBrowser-based application is running in Pharo... I'm seeing this with the MetacelloBrowser ...
Anyway, I have gotten the impression, that someone has done some fairly recent work on getting OmniBrowser to work (again?) in Squeak4.x but haven't gotten around to tracking it down ... but then I don't even know if that work would address the problem:)
Yeah, I'm bringing Lukas' work over to the Squeak version and collecting bug reports/fixes. Hope to get a solid release together soon. If we can get that SqueakMap bug fixed, I'll post it there.
Colin
On 04/19/2011 09:59 AM, Colin Putney wrote:
On Tue, Apr 19, 2011 at 8:31 AM, Dale Henrichsdhenrich@vmware.com wrote:
I have noticed that certain buttons in OmniBrowser under Squeak4.2+ don't work when clicked while the buttons work when the same OmniBrowser-based application is running in Pharo... I'm seeing this with the MetacelloBrowser ...
Anyway, I have gotten the impression, that someone has done some fairly recent work on getting OmniBrowser to work (again?) in Squeak4.x but haven't gotten around to tracking it down ... but then I don't even know if that work would address the problem:)
Yeah, I'm bringing Lukas' work over to the Squeak version and collecting bug reports/fixes. Hope to get a solid release together soon. If we can get that SqueakMap bug fixed, I'll post it there.
Colin
If you supply me with the magic formula, I can update the ConfigurationOfOmniBrowser with the correct packages ... which is what Seaside30 and MetacelloBrowser and others will need ...
Dale
Am 2011-04-19 um 19:45 schrieb Dale Henrichs:
On 04/19/2011 09:59 AM, Colin Putney wrote:
On Tue, Apr 19, 2011 at 8:31 AM, Dale Henrichsdhenrich@vmware.com wrote:
[…] Anyway, I have gotten the impression, that someone has done some fairly recent work on getting OmniBrowser to work (again?) in Squeak4.x but haven't gotten around to tracking it down ... but then I don't even know if that work would address the problem:)
Yeah, I'm bringing Lukas' work over to the Squeak version and collecting bug reports/fixes. Hope to get a solid release together soon. If we can get that SqueakMap bug fixed, I'll post it there.
Colin
If you supply me with the magic formula, I can update the ConfigurationOfOmniBrowser with the correct packages ... which is what Seaside30 and MetacelloBrowser and others will need ...
Hmmm progress :) how I like that smell ^.^
Thanks, y'all
So Long, -Tobias
Chris, which SqueakMap bug did you mean?
I see that somebody (Colin) has posted an OmniBrowser load script http://map.squeak.org/recentnew
What about posting the Seaside load script?
--Hannes
P.S. The script in the "extending the system" workspace for loading Seaside 3.0 works in Squeak 4.3 alpha.
On 4/20/11, Chris Muller asqueaker@gmail.com wrote:
soon. If we can get that SqueakMap bug fixed, I'll post it there.
I haven't forgotten about that Colin. Give me another day or two.. Thx..
- Chris
Great idea. It's just a matter of getting Phillip to do it or getting his permission to let the community do it.
Phillip?
- Chris
On Tue, May 3, 2011 at 5:24 AM, Hannes Hirzel hannes.hirzel@gmail.com wrote:
Chris, which SqueakMap bug did you mean?
I see that somebody (Colin) has posted an OmniBrowser load script http://map.squeak.org/recentnew
What about posting the Seaside load script?
--Hannes
P.S. The script in the "extending the system" workspace for loading Seaside 3.0 works in Squeak 4.3 alpha.
On 4/20/11, Chris Muller asqueaker@gmail.com wrote:
soon. If we can get that SqueakMap bug fixed, I'll post it there.
I haven't forgotten about that Colin. Give me another day or two.. Thx..
- Chris
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Chris Muller -
Chris Muller -
Colin Putney -
Dale Henrichs -
Edgar J. De Cleene -
Hannes Hirzel -
Levente Uzonyi -
Stephane -
Tobias Pape