Icons and metacellobrowser
Locked
Icons and metacellobrowser
 
|
Hi Dale,
I feel the new version of the browser makes the whole image sluggish. Just compiling a method ask the browser to be refreshed, which is okay. But computing which icon has to be put next to the name may be costly? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
Alexandre,
There are a number of performance-related issues that I have noticed ... the primary one being that each instance of MetacelloBrowser add itself as a dependent to each package in the image, but doesn't bother to remove itself when closed .... so if you have been opening and closing MetacelloBrowsers the image gets slower and slower ... I added a class-side cleanDependents (use it only when no MetacelloBrowser window is open) to get rid of the old instances of MetacelloBrowser who are happily rebuilding themselves on each change ... I think that the whole update mechanism for MetecelloBrowser is broken ... when you load a single package there are about 8 update messages sent and MetacelloBrowser wants to refresh and rebuild on each update: ... I added a change the other day to eliminate about 1/2 of the updates, but then we wander into the territory where some updates are missed that are critical to the state of the browser ... The validation stuff just added to the burden, espeicially since I didn't cache the results in the appropriate places, yet. Before going crazy with caching and building on demand, I think that the update mechanism must be revamped ... I tried loading seaside with the original MetacelloBrowser and noticed that the system was running way too slow ... close the browser (nad remove dependents) and things were fast again ... The other reason that the update mechanism needs to be revamped is that even with all of the update messages were were receiving we were still missing important events .... I expect to look into a couple of these issues today ... Dale On Feb 27, 2011, at 6:53 AM, Alexandre Bergel wrote: > Hi Dale, > > I feel the new version of the browser makes the whole image sluggish. Just compiling a method ask the browser to be refreshed, which is okay. But computing which icon has to be put next to the name may be costly? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > |
Re: Icons and metacellobrowser
|
|
I am working on this issue. I worked some times ago on the WindowAnnouncement mechanism.
But I was wondering, I found this method: MetacelloBrowser>>buildWith: builder | windowBuilder | windowBuilder := MetacelloToolWindowBuilder builder: builder tool: self. (windowBuilder respondsTo: #startWithWindow) ifTrue: [windowBuilder startWithWindow]. ... MetacelloToolWindowBuilder is apparently missing (I checked MetacelloBrowser-AlexandreBergel.64 and MetacelloBrowser-dkh.62). Is this class supposed to be part of Metacello or MetacelloBrowser? Cheers, Alexandre On 27 Feb 2011, at 13:20, Dale Henrichs wrote: > Alexandre, > > There are a number of performance-related issues that I have noticed ... the primary one being that each instance of MetacelloBrowser add itself as a dependent to each package in the image, but doesn't bother to remove itself when closed .... so if you have been opening and closing MetacelloBrowsers the image gets slower and slower ... I added a class-side cleanDependents (use it only when no MetacelloBrowser window is open) to get rid of the old instances of MetacelloBrowser who are happily rebuilding themselves on each change ... > > I think that the whole update mechanism for MetecelloBrowser is broken ... when you load a single package there are about 8 update messages sent and MetacelloBrowser wants to refresh and rebuild on each update: ... I added a change the other day to eliminate about 1/2 of the updates, but then we wander into the territory where some updates are missed that are critical to the state of the browser ... > > The validation stuff just added to the burden, espeicially since I didn't cache the results in the appropriate places, yet. > > Before going crazy with caching and building on demand, I think that the update mechanism must be revamped ... I tried loading seaside with the original MetacelloBrowser and noticed that the system was running way too slow ... close the browser (nad remove dependents) and things were fast again ... > > The other reason that the update mechanism needs to be revamped is that even with all of the update messages were were receiving we were still missing important events .... > > I expect to look into a couple of these issues today ... > > Dale > > On Feb 27, 2011, at 6:53 AM, Alexandre Bergel wrote: > >> Hi Dale, >> >> I feel the new version of the browser makes the whole image sluggish. Just compiling a method ask the browser to be refreshed, which is okay. But computing which icon has to be put next to the name may be costly? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
Oh great,
I have been working on this issue as well and I have what I think is a good solution ... SystemChangeNotifier and fairly targetted updates plus a fairly major rework of the object model to make managing the caching of data much easier (each ConfigurationInfo holds onto the versions, packages and projects)... In the end I had to resort to using step to defer the window updates, since multiple (valid) update messages were coming in ... Dale On Feb 27, 2011, at 2:29 PM, Alexandre Bergel wrote: > I am working on this issue. I worked some times ago on the WindowAnnouncement mechanism. > > But I was wondering, I found this method: > MetacelloBrowser>>buildWith: builder > | windowBuilder | > > windowBuilder := MetacelloToolWindowBuilder builder: builder tool: self. > (windowBuilder respondsTo: #startWithWindow) > ifTrue: [windowBuilder startWithWindow]. > ... > > MetacelloToolWindowBuilder is apparently missing (I checked MetacelloBrowser-AlexandreBergel.64 and MetacelloBrowser-dkh.62). Is this class supposed to be part of Metacello or MetacelloBrowser? > > Cheers, > Alexandre > > > On 27 Feb 2011, at 13:20, Dale Henrichs wrote: > >> Alexandre, >> >> There are a number of performance-related issues that I have noticed ... the primary one being that each instance of MetacelloBrowser add itself as a dependent to each package in the image, but doesn't bother to remove itself when closed .... so if you have been opening and closing MetacelloBrowsers the image gets slower and slower ... I added a class-side cleanDependents (use it only when no MetacelloBrowser window is open) to get rid of the old instances of MetacelloBrowser who are happily rebuilding themselves on each change ... >> >> I think that the whole update mechanism for MetecelloBrowser is broken ... when you load a single package there are about 8 update messages sent and MetacelloBrowser wants to refresh and rebuild on each update: ... I added a change the other day to eliminate about 1/2 of the updates, but then we wander into the territory where some updates are missed that are critical to the state of the browser ... >> >> The validation stuff just added to the burden, espeicially since I didn't cache the results in the appropriate places, yet. >> >> Before going crazy with caching and building on demand, I think that the update mechanism must be revamped ... I tried loading seaside with the original MetacelloBrowser and noticed that the system was running way too slow ... close the browser (nad remove dependents) and things were fast again ... >> >> The other reason that the update mechanism needs to be revamped is that even with all of the update messages were were receiving we were still missing important events .... >> >> I expect to look into a couple of these issues today ... >> >> Dale >> >> On Feb 27, 2011, at 6:53 AM, Alexandre Bergel wrote: >> >>> Hi Dale, >>> >>> I feel the new version of the browser makes the whole image sluggish. Just compiling a method ask the browser to be refreshed, which is okay. But computing which icon has to be put next to the name may be costly? >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > |
|
|
I was waching for commits from you all afternoon plus the package commit comments are pretty detailed (especially for the change after the big refactoring)...
Sorry if we collided ... I didn't create a TooWindowBuilder ... I thought I had mentioned earlier that I took a different tack in the hopes that the code would be more portable to Squeak ... of course the icon code uses PolyMorph which hasn't been ported to Squeak, so it will be awhile ... Dale On Feb 27, 2011, at 7:44 PM, Dale Henrichs wrote: > Oh great, > > I have been working on this issue as well and I have what I think is a good solution ... SystemChangeNotifier and fairly targetted updates plus a fairly major rework of the object model to make managing the caching of data much easier (each ConfigurationInfo holds onto the versions, packages and projects)... > > In the end I had to resort to using step to defer the window updates, since multiple (valid) update messages were coming in ... > > Dale > > On Feb 27, 2011, at 2:29 PM, Alexandre Bergel wrote: > >> I am working on this issue. I worked some times ago on the WindowAnnouncement mechanism. >> >> But I was wondering, I found this method: >> MetacelloBrowser>>buildWith: builder >> | windowBuilder | >> >> windowBuilder := MetacelloToolWindowBuilder builder: builder tool: self. >> (windowBuilder respondsTo: #startWithWindow) >> ifTrue: [windowBuilder startWithWindow]. >> ... >> >> MetacelloToolWindowBuilder is apparently missing (I checked MetacelloBrowser-AlexandreBergel.64 and MetacelloBrowser-dkh.62). Is this class supposed to be part of Metacello or MetacelloBrowser? >> >> Cheers, >> Alexandre >> >> >> On 27 Feb 2011, at 13:20, Dale Henrichs wrote: >> >>> Alexandre, >>> >>> There are a number of performance-related issues that I have noticed ... the primary one being that each instance of MetacelloBrowser add itself as a dependent to each package in the image, but doesn't bother to remove itself when closed .... so if you have been opening and closing MetacelloBrowsers the image gets slower and slower ... I added a class-side cleanDependents (use it only when no MetacelloBrowser window is open) to get rid of the old instances of MetacelloBrowser who are happily rebuilding themselves on each change ... >>> >>> I think that the whole update mechanism for MetecelloBrowser is broken ... when you load a single package there are about 8 update messages sent and MetacelloBrowser wants to refresh and rebuild on each update: ... I added a change the other day to eliminate about 1/2 of the updates, but then we wander into the territory where some updates are missed that are critical to the state of the browser ... >>> >>> The validation stuff just added to the burden, espeicially since I didn't cache the results in the appropriate places, yet. >>> >>> Before going crazy with caching and building on demand, I think that the update mechanism must be revamped ... I tried loading seaside with the original MetacelloBrowser and noticed that the system was running way too slow ... close the browser (nad remove dependents) and things were fast again ... >>> >>> The other reason that the update mechanism needs to be revamped is that even with all of the update messages were were receiving we were still missing important events .... >>> >>> I expect to look into a couple of these issues today ... >>> >>> Dale >>> >>> On Feb 27, 2011, at 6:53 AM, Alexandre Bergel wrote: >>> >>>> Hi Dale, >>>> >>>> I feel the new version of the browser makes the whole image sluggish. Just compiling a method ask the browser to be refreshed, which is okay. But computing which icon has to be put next to the name may be costly? >>>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > |
|
|
In reply to this post by Alexandre Bergel-5
Alexandre,
Well I think that I've solved most of the performance problems ... the MetacelloBrowser opens very quickly ... no sluggishness in the system whenever a method is touched or a package loaded/saved ... all dependencies are cleaned up when the window is closed ... things also appear to be updating correctly although that will depend updating the correct pane from the commands ... there's a global flag for doing automatic validation, but by default validation is done only on demand, but the results are cached ... The big winner was caching the currentVersion (as you can imagine) ... I'm comfortable that the event tracking should refresh the currentVersion only when something changes that warrants an update ... I removed the clearCaches menu item, because things appear to work correctly ... Tomorrow I wil do some extensive work with Seaside3.0.4, working the MetacelloBrowser ... yesterday morning the browser was not usable with a large project like Seaside30 even before loading the packages, now it's it's fast ... II'll see if there are any gotchas tomorrow... Dale On Feb 27, 6:53 am, Alexandre Bergel <[hidden email]> wrote: > Hi Dale, > > I feel the new version of the browser makes the whole image sluggish. Just compiling a method ask the browser to be refreshed, which is okay. But computing which icon has to be put next to the name may be costly? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
Alexadre,
I took another swipe at the button bar this time ... i preserved the old button bar as buttonsX so you can restore the old button bar, if you hate this one ... the button bar now has these buttons across the top: Load configuration +Configuration Checkpoint save Release Help I'm trying to get the button bar to reflect process 1. load/create config I extended the old +Config command to create the config, create a baseline and then create an initial literal version in development mode...so with one button press you are ready to rumba ... the baseline and literal version are just created right out of the gate which i think will simplify things for folks ... 2. checkpoint save After a period of development, you press the checkpoint save button and all modified packages are save, the config is updated and saved as well ... 3. release When you're ready to release, you press the release button which removes the version from development and marks it as released and defines the version as a stable version. then a new version is created as the new development version and you are ready to go back to step 2 ... This is the kind of support I was imagining that there would be in the tool ... Since release automatically creates a new development version, for your style of development, you would just press the release button and skip ever doing a checkpoint ... but the option of doing a checkpoint would be there... Well its been a long day for me ... Dale On Feb 27, 9:13 pm, Dale <[hidden email]> wrote: > Alexandre, > > Well I think that I've solved most of the performance problems ... the > MetacelloBrowser opens very quickly ... no sluggishness in the system > whenever a method is touched or a package loaded/saved ... all > dependencies are cleaned up when the window is closed ... things also > appear to be updating correctly although that will depend updating the > correct pane from the commands ... there's a global flag for doing > automatic validation, but by default validation is done only on > demand, but the results are cached ... > > The big winner was caching the currentVersion (as you can imagine) ... > I'm comfortable that the event tracking should refresh the > currentVersion only when something changes that warrants an update ... > I removed the clearCaches menu item, because things appear to work > correctly ... > > Tomorrow I wil do some extensive work with Seaside3.0.4, working the > MetacelloBrowser ... yesterday morning the browser was not usable with > a large project like Seaside30 even before loading the packages, now > it's it's fast ... II'll see if there are any gotchas tomorrow... > > Dale > On Feb 27, 6:53 am, Alexandre Bergel <[hidden email]> wrote: > > > > > Hi Dale, > > > I feel the new version of the browser makes the whole image sluggish. Just compiling a method ask the browser to be refreshed, which is okay. But computing which icon has to be put next to the name may be costly? > > > Cheers, > > Alexandre > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Re: Icons and metacellobrowser
|
|
In reply to this post by Dale Henrichs
> Well I think that I've solved most of the performance problems ... the
> MetacelloBrowser opens very quickly ... no sluggishness in the system > whenever a method is touched or a package loaded/saved ... all > dependencies are cleaned up when the window is closed ... things also > appear to be updating correctly although that will depend updating the > correct pane from the commands ... there's a global flag for doing > automatic validation, but by default validation is done only on > demand, but the results are cached ... I checked. It is indeed faster. > The big winner was caching the currentVersion (as you can imagine) ... :-) > Tomorrow I wil do some extensive work with Seaside3.0.4, working the > MetacelloBrowser ... yesterday morning the browser was not usable with > a large project like Seaside30 even before loading the packages, now > it's it's fast ... II'll see if there are any gotchas tomorrow... Cool Alexandre > On Feb 27, 6:53 am, Alexandre Bergel <[hidden email]> wrote: >> Hi Dale, >> >> I feel the new version of the browser makes the whole image sluggish. Just compiling a method ask the browser to be refreshed, which is okay. But computing which icon has to be put next to the name may be costly? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Re: Icons and metacellobrowser
|
|
In reply to this post by Dale Henrichs
Hi!
I checked MetacelloBrowser-dkh.83. Maybe of the test were yellow or red. I fixed all of them. I re-introduced the method Info>>signalUpdateInfosList into Info>>signalRefresh. Why did you remove it? Was it intentional? How the browser will be updated without it? I see you introduced ConfigurationInfo>>validate and validateFull. Shouldn't these methods be defined in a command? Same for MonticelloProjectedInfo>>browseProject. This method is called nowhere apparently. Maybe a left over when I migrated from the menu to the commands. > I took another swipe at the button bar this time ... i preserved the > old button bar as buttonsX so you can restore the old button bar, if > you hate this one ... the button bar now has these buttons across the > top: > > Load configuration > +Configuration > Checkpoint save > Release > Help > > I'm trying to get the button bar to reflect process > > 1. load/create config > > I extended the old +Config command to create the config, create a > baseline and then create an initial literal version in development > mode...so with one button press you are ready to rumba ... the > baseline and literal version are just created right out of the gate > which i think will simplify things for folks ... I haven't tried, but ok. > 2. checkpoint save > > After a period of development, you press the checkpoint save button > and all modified packages are save, the config is updated and saved as > well ... Ok, I will try with this checkpoint to see how it works with me. > 3. release > > When you're ready to release, you press the release button which > removes the version from development and marks it as released and > defines the version as a stable version. then a new version is created > as the new development version and you are ready to go back to step > 2 ... By the way, maybe we can release Version 1.47? All the tests are green > This is the kind of support I was imagining that there would be in the > tool ... Since release automatically creates a new development > version, for your style of development, you would just press the > release button and skip ever doing a checkpoint ... but the option of > doing a checkpoint would be there... Thanks! > Well its been a long day for me ... I see this. Thanks for this effort. It is worth Alexandre > > On Feb 27, 9:13 pm, Dale <[hidden email]> wrote: >> Alexandre, >> >> Well I think that I've solved most of the performance problems ... the >> MetacelloBrowser opens very quickly ... no sluggishness in the system >> whenever a method is touched or a package loaded/saved ... all >> dependencies are cleaned up when the window is closed ... things also >> appear to be updating correctly although that will depend updating the >> correct pane from the commands ... there's a global flag for doing >> automatic validation, but by default validation is done only on >> demand, but the results are cached ... >> >> The big winner was caching the currentVersion (as you can imagine) ... >> I'm comfortable that the event tracking should refresh the >> currentVersion only when something changes that warrants an update ... >> I removed the clearCaches menu item, because things appear to work >> correctly ... >> >> Tomorrow I wil do some extensive work with Seaside3.0.4, working the >> MetacelloBrowser ... yesterday morning the browser was not usable with >> a large project like Seaside30 even before loading the packages, now >> it's it's fast ... II'll see if there are any gotchas tomorrow... >> >> Dale >> On Feb 27, 6:53 am, Alexandre Bergel <[hidden email]> wrote: >> >> >> >>> Hi Dale, >> >>> I feel the new version of the browser makes the whole image sluggish. Just compiling a method ask the browser to be refreshed, which is okay. But computing which icon has to be put next to the name may be costly? >> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
On Feb 28, 2011, at 5:10 AM, Alexandre Bergel wrote: > Hi! > Hey! > I checked MetacelloBrowser-dkh.83. Maybe of the test were yellow or red. I fixed all of them. > I re-introduced the method Info>>signalUpdateInfosList into Info>>signalRefresh. Why did you remove it? Was it intentional? How the browser will be updated without it? It was intentional. I moved the refresh logic to the command hierarchy plus with the new update tracking, many of the commands don't need to explicitly refresh because the browser notices the change to the system ... now the only time that an explicit refresh is needed is when a list is surgically changed ... > > I see you introduced ConfigurationInfo>>validate and validateFull. Shouldn't these methods be defined in a command? Yes, I didn't figure out how to it as a command until a bit later and it was getting late:) > Same for MonticelloProjectedInfo>>browseProject. This method is called nowhere apparently. Maybe a left over when I migrated from the menu to the commands. Don't recall that what ... I toted a lot of code yesterday:) BTW, I really like the cmd structure ... excellent job! Dale |
Re: Icons and metacellobrowser
|
|
>> I checked MetacelloBrowser-dkh.83. Maybe of the test were yellow or red. I fixed all of them.
>> I re-introduced the method Info>>signalUpdateInfosList into Info>>signalRefresh. Why did you remove it? Was it intentional? How the browser will be updated without it? > > It was intentional. I moved the refresh logic to the command hierarchy plus with the new update tracking, many of the commands don't need to explicitly refresh because the browser notices the change to the system ... now the only time that an explicit refresh is needed is when a list is surgically changed ... Ok, so should I remove this method and its caller then? > BTW, I really like the cmd structure ... excellent job! I enforced to provide a documentation for each command. You cannot instantiate a command if it has no documentation. Currently, this is not used that much. But I would like to enhance the 'Help' button with producing a nice documentation. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
On 02/28/2011 09:07 AM, Alexandre Bergel wrote:
>>> I checked MetacelloBrowser-dkh.83. Maybe of the test were yellow or red. I fixed all of them. >>> I re-introduced the method Info>>signalUpdateInfosList into Info>>signalRefresh. Why did you remove it? Was it intentional? How the browser will be updated without it? >> >> It was intentional. I moved the refresh logic to the command hierarchy plus with the new update tracking, many of the commands don't need to explicitly refresh because the browser notices the change to the system ... now the only time that an explicit refresh is needed is when a list is surgically changed ... > > Ok, so should I remove this method and its caller then? Yes, I think that's best ... the Info structure is the model that we're working off, so I don't think it should have any morphic methods... eventually:) > >> BTW, I really like the cmd structure ... excellent job! > > > I enforced to provide a documentation for each command. You cannot instantiate a command if it has no documentation. Currently, this is not used that much. But I would like to enhance the 'Help' button with producing a nice documentation. I think that's a good practice! I am cleaning up the release version stuff this morning ... starting to use MetacelloBrowser for Seaside3.0, but haven't reached point where I can do everything through the tool ... which is the goal... Dale |
Re: Icons and metacellobrowser
|
|
>> Ok, so should I remove this method and its caller then?
> > Yes, I think that's best ... the Info structure is the model that we're working off, so I don't think it should have any morphic methods... eventually:) Done, in Version 1.51 >>> BTW, I really like the cmd structure ... excellent job! >> >> >> I enforced to provide a documentation for each command. You cannot instantiate a command if it has no documentation. Currently, this is not used that much. But I would like to enhance the 'Help' button with producing a nice documentation. > > I think that's a good practice! > > I am cleaning up the release version stuff this morning ... starting to use MetacelloBrowser for Seaside3.0, but haven't reached point where I can do everything through the tool ... which is the goal... Excellent plan! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
«
Return to Metacello
|
1 view|%1 views
| Free forum by Nabble | Edit this page |