Re: Sudden Tango changes in trunk



On Wed, 2007-03-28 at 12:49 +0200, Jakub Steiner wrote:
> On Wed, 2007-03-28 at 11:45 +0200, Kristian Rietveld wrote:
> > Dear All,
> > 
> > When updating trunk over the weekend I was surprised by two commits
> > replacing/overwriting old icons with new "tango" ones.  Before I had a
> > chance to mail to this list about this I noticed a blog entry saying
> > that the whole GTK+ stock icon set will be updated.
> > 
> > I don't remember any discussion about this on the list, where have we
> > decided that we are going to update the stock icons?  From the first two
> > commits I figure that the old icons will be overwritten by the new ones.
> > 
> > I am concerned that this change will "visually break" any old
> > applications, which might have custom icons that more or less match the
> > current gtk+ icon style.  To me it feels like replacing icons is not a
> > solution here, a new icon theme with the tango icons should be created
> > instead.
>
> Hi Kris,
> I've poked Matthias Clasen on IRC about it.  If you feel like we should
> back of the changes, I'll revert.
> 
> GNOME is pretty much dealt for in the gnome icon theme, the reason for
> the gtk+ stock facelift is the Windows-ports.
> 
> To be honest I don't want to bother with all this work to provide an
> 'alternative' icon theme. The unique gnome 2.0 style make gtk apps on
> platforms such as MS Windows or Mac OS X totally out of place. I'm quite
> sad to see you hold on to that.

For anything that runs under gnome or another icon-theme-spec using
desktop, this should not be an issue, I think, because icon themes
already replace all the stock gtk icons to match their style.

It could be a concern on win32 or in embedded scenarios. Although most
embedded GTK+ uses probably have custom builds of GTK+, so they can 
easily replace the stock icons with something that works better on their
platform. We could make that easier by keeping the old icons in the tree
and adding a build-time switch to select old-style vs new-style icons.
That would certainly blow up the tarballs a bit, though.

Matthias




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]