First of all,

Thank you Steve that you reacted so quickly to my with to have a
background chooser in 4.1
Please see some more comments below

Hannes

On 4/25/10, Steve Wessels <steve at squeak.preeminent.org> wrote:
>
> On Apr 24, 2010, at 5:43 PM, Hannes Hirzel wrote:
>
>> On 4/24/10, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>> On 24.04.2010, at 01:15, commits at source.squeak.org wrote:
>>>>
>>>> A new version of DesktopBackgroundLoader was added to project The
>>>> Inbox:
>>>> http://source.squeak.org/inbox/DesktopBackgroundLoader-sbw.20.mcz
>>>>
>>>> ==================== Summary ====================
>>>>
>>>> Name: DesktopBackgroundLoader-sbw.20
>>>> Author: sbw
>>>> Time: 23 April 2010, 8:15:17.965 pm
>>>> UUID: bd0f5baa-9676-4e16-9e04-893e65f26d25
>>>> Ancestors: DesktopBackgroundLoader-sbw.19
>>>>
>>>> Published for general distribution.  See Extras menu from Dock for
>>>> access.
>>
>>> I find that duplication of FileList functionality somewhat
>>> questionable. If
>>> this became a specialized FileList for choosing images, along with
>>> its
>>> previews etc., that would be great. But all this effort just to
>>> choose a
>>> background?
>>
>> I am happy having the functionality in 4.1 with this package. For me
>> this is a need.
>>
>> But I agree that a subclass of FileList for choosing images is better


> I have published an updated version of the code to my Squeak goodies
> site this evening and will be updating
> Squeak Source again soon to match.  This new code moves the tool back
> under FileList (where I first started
> writing it) based upon feedback presented here.  And that's a smart
> move because it reduces code.  However, the
> reasons I published a version as a subclass off of Model was a
> deliberate choice because I saw a few places in FileList
> that need refactoring to make this sort of tools extension simpler.

I understand.

Stephen you background chooser is a nice  application of ToolBuilder
(the one which directly subclasses 'Model').

FileList subclasses StringHolder which subclasses Model. And it uses
ToolBuilder as well. And you say it should be reworked, to make is
easier to extend.


> And rather than spend time mucking around inside
> FileList, which I did not see as my charter for creating this tool, I
> saw that as a diversion which can be undertaken and utilized
> at a later time.

I understand.

> This tool was created over an evening and part of the next day, so the
> effort is insignificant.

I like your version of the Background chooser as another fine easy to
read example of using the ToolBuilder.

 And I wanted to try out the newer tool
> builder approach that I see newer Squeak tools using.  This tool was
> rewritten as a response to someone who wrote to me requesting that I
> bring the old utility up to date with Squeak 4.1 and I was happy to
> oblige.

That was me and I am happy with the result.

>>
>> So for including it into the image it should be that. For having as an
>> addon-package it may remain as is and people can download it from
>> Stephen's web site.

I prefer having it in the image, but if that is not possible for
whatever reason then downloading it as an addon is fine as well.

>>> In any case, to consider this for inclusion in trunk, it should not
>>> be a
>>> separate package. Packages that modify other packages are a Bad
>>> Thing. This
>>> one removes a method from the Morphic package (interestingly, the
>>> Morphic
>>> package is not marked dirty, that's a bug).
>> Yes
>
> I agree that modifying another package is a Bad Thing.  However I
> remain confused about this notion that this code
> removes a method from the Morphic package.  Not that I can tell.  I
> may need a tip on where this is.
>
> The only place where this utility collides with existing code is in
> the mechanism of adding to the dock/extras menu.  The
> current design is locked in an prohibits this sort of change without
> cross impacts - which really is a bad thing.  What I find
> disappointing is
> that we still have menu code like this in the image that does not
> support a registry.  This is not a new concept.  I'm pretty sure I have
> published an enhancement for Squeak as far back as the 2.x days that
> provided a registry for the projects, world and appearance menus,
> precisely
> because of nonsense collisions like this every time I wanted to
> publish an enhancement to Squeak's user interface.  And it has to be
> true
> that whenever we produce enhancements that support individual styles
> (like a background loader or project thumbnail artifacts or whatever)
> the user has to have the option of NOT including this capability.
> Hence a registry for these menus and now the dock.
>
>
>>
>>> My suggestion would be to make the extras menu (or rather, the
>>> whole menu
>>> bar) extensible, then this package would not have to touch that
>>> existing
>>> method. Then this could just be a loadable package.
>
> That's the correct answer.
>
>>>
>>> - Bert -
>>>
>>
>> Having an extensible extras menu is a thing Stephen prefers. Who is
>> going to do this?
>
> I could take another crack at this capability but I'm not really
> certain how the Squeak Community handles this kind of thing anymore.
> I've pretty much stayed away from the main mailing list the past few
> years so I'm coming into this sort of thing unawares of how code is
> added to the base anymore.
>
>>
>> --Hannes
>>
>
>
>