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 |
In reply to this post by Hannes Hirzel
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 > |
In reply to this post by Andreas.Raab
On Tue, Apr 19, 2011 at 8:26 AM, Andreas Raab <[hidden email]> 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 |
In reply to this post by Dale Henrichs
On Tue, Apr 19, 2011 at 8:31 AM, Dale Henrichs <[hidden email]> 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 <[hidden email]> wrote: > On Tue, Apr 19, 2011 at 8:31 AM, Dale Henrichs <[hidden email]> 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 > > |
In reply to this post by Colin Putney-3
On 04/19/2011 09:59 AM, Colin Putney wrote:
> On Tue, Apr 19, 2011 at 8:31 AM, Dale Henrichs<[hidden email]> 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 Henrichs<[hidden email]> 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 |
In reply to this post by Colin Putney-3
> 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 |
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 >> >> > > |
In reply to this post by Andreas.Raab
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 > > |
In reply to this post by Levente Uzonyi-2
On 6/3/11 4:07 AM, "Levente Uzonyi" <[hidden email]> 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 |
In reply to this post by Levente Uzonyi-2
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 <[hidden email]> wrote: > On Fri, 3 Jun 2011, Hannes Hirzel wrote: > >> On 6/3/11, Levente Uzonyi <[hidden email]> 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 >> >> > |
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 <[hidden email]> wrote: >> On Fri, 3 Jun 2011, Hannes Hirzel wrote: >> >>> On 6/3/11, Levente Uzonyi <[hidden email]> 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 >>> >>> >> > |
Free forum by Nabble | Edit this page |