New icon names approval: "view-fit-*
James Richard Tyrer
tyrerj at acm.org
Sun Jul 15 05:27:26 PDT 2007
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:
>> 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:
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:
>> 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:
More information about the xdg