Hendrik,
Thanks for all the help.
It seems that changing the category programmatically like this works:
((SystemOrganization listAtCategoryNamed: 'Zinc-HTTP-New-Client-Server')
collect: [ :className | Smalltalk globals at: className ])
do: [ :each | each category: 'Zinc-HTTP-Client-Server' ]
Now MC did pick up the changes.
Sven
On 06 Dec 2010, at 16:07, Henrik Johansen wrote:
>
> On Dec 6, 2010, at 3:52 08PM, Sven Van Caekenberghe wrote:
>
>>
>> On 06 Dec 2010, at 15:42, Henrik Johansen wrote:
>>
>>> If you create a new package with the proper name in the monticello browser
>>> (+Package) though, the recategorized class definitions should end up in the
>>> correct place.
>>
>> OK, Hendrik, +Package might indeed add them to a new Package, and yes one
>> has to do that manually (no problem there), but are they then removed from
>> their original Package ?
>>
>> And what about just renaming a category, these changes do not seem to be
>> picked up. Is there a way to force this ?
>>
>> Or do I have to do a fileout and manually delete each class, even edit the
>> fileout's source code ?
>>
>> Anyway, thanks for the reply.
>>
>> Sven
>
> IIRC, (big if), the package corresponding to the category that was renamed
> will not contain any code if you browse it, but neither is it marked as dirty.
> So by default, you probably wouldn't publish the new, empty version of the
> package unless you looked for it specifically.
> New packages created before or after renaming an existing category will not
> be marked dirty as a consequence of the category rename either.
>
> If you change the category of a single class however, both old and new
> package will be marked dirty. (Except if you create the new package after
> performing the rename)
>
> TLDR;
> The packages will contain the correct code, if you publish them.
> Marking packages as dirty does not work for category renames, but do work for
> single class renaming done by recompiling class definition.
>
> Cheers,
> Henry
