Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of jogischmidt@googlemail.com
 designates 209.85.210.48 as permitted sender)
Message-ID: <4F8C16F7.9060800@googlemail.com>
Date: Mon, 16 Apr 2012 14:56:23 +0200
From: =?ISO-8859-1?Q?J=FCrgen_Schmidt?= <jogischmidt@googlemail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: Cannot select a different icon set
References: <4F8369D1.3040003@apache.org> <20120415183301.GA26110@localhost>
 <4F8B441E.3000108@apache.org> <20120416020633.GB22611@localhost>
 <4F8B8842.5000006@apache.org> <20120416040855.GC31544@localhost>
 <4F8BAB95.7090606@apache.org> <20120416100656.GB17087@localhost>
In-Reply-To: <20120416100656.GB17087@localhost>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 4/16/12 12:06 PM, Ariel Constenla-Haile wrote:
> Hi Pedro,
>
> On Mon, Apr 16, 2012 at 12:18:13AM -0500, Pedro Giffuni wrote:
>>> IMHO we shouldn't remove anything, on the contrary we should revert all
>>> changes: the list of icon styles is filled in the constructor of
>>> OfaViewTabPage. Ultimately, the existence of an icon set is checked on
>>> bool ImplImageTree::checkStyle(rtl::OUString const&   style) so that
>>> non-existent icon styles are removed from the list box.
>>>
>>> IMO we should keep all the list as it was before, with all icon styles,
>>> so that the user can install by herself/himself the ones AOO can't ship
>>> due to license issues.
>>>
>>> This means reverting changes in
>>> ::rtl::OUString StyleSettings::ImplSymbolsStyleToName( sal_uLong nStyle ) const
>>> sal_uLong StyleSettings::ImplNameToSymbolsStyle( const ::rtl::OUString&rName ) const
>>> sal_uLong StyleSettings::GetAutoSymbolsStyle() const
>>>
>>> and some other places.
>>
>> That is not a bad idea, but still that would mean changing again the menus
>> to bring back the Crystal icons, which would not be there by default.
>
> Bringing back the string item list as it was before, will imply
> translation work, so it must be done on trunk after AOO340 is branched.
>
>> At the very least the crystal and Tango icons should be left towards
>> the end of the list and not in the middle as they were originally.
>
> Why? The order on the list box has to do with the constants order. If
> the icon set is not present, the corresponding list box item is removed
> at runtime,  in the constructor of OfaViewTabPage.
>
>
> Regards

I think we will move forward with the RC as proposed and will 
fix/cleanup this asap. But we should in the future be more careful and 
communicate clearly the consequences of such changes. And building and 
testing before we commit such changes will probably also help to get an 
overview if it works as expected and if all necessary places are changed.

Related to the icon sets we should think about some better or general 
approach to introduce some themeing mechanism.

Juergen