New icon names approval: "view-fit-*

[James Richard Tyrer]

Jakob Petsovits wrote:
> On Friday, 13. July 2007, James Richard Tyrer wrote:
>> Yes, that looks like a good possibility even though the names
>> (zoom-fit-*-page) do not appear, at first glance, technically correct --
>> they make sense only when compared to the other names (zoom-fit-*).  So,
>> perhaps if they are going to be KDE Only icons, they should be called:
>>
>> 	zoom-fit-width-kde
>> 	zoom-fit-height-kde
>> 	zoom-fit-best-kde
>>
>> since this would conform to the spec -- a brand is added last in all
>> cases although I think that they had something slightly different in
>> mind for the meaning of 'brand'.
> 
> No, I don't think that's a good idea. Icons should really only be named *-kde 
> when they are actually KDE specific, as in "adds KDE branding while the 
> meaning stays the same". This is not the case here, it is no brand but rather 
> a more specialized version of the original icon, thus it should say what it 
> is, not where it comes from.
> 
> In short, I think *-page is much more appropriate than *-kde here.
> Either way, it doesn't make a difference for the specification request:

Whatever.  As I said, that name *is* correct since "zoom-fit-*-page" is 
a variant of "zoom-fit-*", it only looks incorrect at first glance (you 
wonder why it isn't "zoom-fit-page-*").  We could also simply label them 
as a variant and call them "zoom-fit-*-1".

Perhaps this issue, the issue of variants which KDE used to deal with 
as: <name>1, <name>2, etc. isn't really covered in the spec.  A variant, 
if identified as such could be treated differently in the fall back to a 
less specific.  That is: "zoom-fit-height-1" -> "zoom-fit-1" first and 
*iff "zoom-fit-1" didn't exist, then fall back to "zoom-fit-height", 
which would only be correct if the "1" indicated that it was a variant. 
    The spec only covers a linear fall back, and this is non-linear.

With a linear fallback, you can only get 3 of these 4:

	zoom-fit-height-page
	zoom-fit-page
	zoom-fit-height
	zoom-fit

to get all 4, "page" must be somehow identified as indicating a variant.

>> IAC, this is not an issue for the spec.  If we follow this idea then we
>> would be asking only for:
>>
>> 	zoom-fit-width
>> 	zoom-fit-height
>>
>> and a correction of the name of "zoom-best-fit" to "zoom-fit-best" --
>> there is no "zoom-best-<something>" and an icon named: "zoom-fit" would
>> be legal as a fall back.
> 
> Right, that's exactly what I would ask for. Your take, dobey?
> 
>> And, is the height icon isn't thought to be popular, we could drop that
>> from the request.
> 
> I object. While fit-height is not as widely used as the other two, I think it 
> still makes sense to include it. Not having it limits the possible use to 
> document viewers only, and even there only to pages in portrait layout.
> What about image viewing/editing apps? What about any graphical visualization 
> that needs fit-height?
> 
> I don't think it makes sense to make those apps have application-specific 
> fit-height icons, especially given the minimal effort for icon designers to 
> draw a fit-height icon when they already did the fit-width one.
> Please include fit-height as well, for consistency and foresight.

Yes, I think that "zoom-fit-height" should be approved -- if I hadn't, I 
wouldn't have posted it.  There are many times that I wish that other 
apps had it.  Perhaps if it were a standard icon, they would.

OTOH, standards making is about arguing and compromising.

If it doesn't exist, we would have stuff falling back to: "zoom-fit", 
does that icon exist?  Well, KDE has this icon; the KDE3 name is: 
"viewmag".

-- 
JRT