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.   
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.

This tool was created over an evening and part of the next day, so the  
effort is insignificant.  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.

>
> 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.
>
>> 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
>