Icon renaming: links

[James Richard Tyrer]

Thiago Macieira wrote:
> James Richard Tyrer wrote:
>> I am working on icon renaming and have an issue that will probably
>> require code to resolve.
>>
>> We need different icon names in KDE than they do in GNOME and I don't
>> think that it is realistic to expect that the spec will be changed to
>> accommodate these.
>>
>> In many cases, this can be solved by using links.  However, if we use
>> symbolic links, this will only work on the icon theme that has the
>> links.  Is there some way that these links could be placed in a file and
>>  used globally on all icon themes?  Or, perhaps there is another method
>> which will work.
> 
> James, if we need different icon names, does this mean that we're talking 
> about icons that are not on the spec?

Yes, it appears that KDE used a lot more icons than GNOME so we are 
going to need additional icons not in the spec.  In some cases these can 
be made as proper subsets of the spec names, those aren't going to be a 
large problem.  E.G. we add something to the end of a spec name and 
fallback should be to a spec name.
> 
> Or are we parting from the spec on those icons?

Yes, in some cases.  This is apparent if you look at the renaming XML in 
  the Tango icon theme.  Many Tango icons are mapped to multiple KDE 
icons.  In general, the problem occurs when we can't handle things by 
falling back to a shorter name as per the spec.

Five specific examples.

1.	The spec has the icon name: "applications-other" which is one of the 
names: "applications-<type>".  These will replace the current icon 
names: "package_<type>".  We need <type>s which are currently not in the 
spec which means that there will be a need for fallback to: 
"applications".  So, at first thought, it appears that 
"applications-other" wasn't the proper choice for a name, but it doesn't 
have the same meaning as our previous icon name: "package" because 
"applications-other" is really for a heading in the menu: "Other", yet, 
we could use this for a fallback.  So, we think that there should be an 
icon name: "applications" which probably won't be in the spec.  So, this 
can be addressed by a link:

	applications -> applications-other

for non-KDE themes that lack this icon.

A similar situation exists for: "preferences-other" and "preferences"

2.	With Devices, KDE was much more specific than GNOME with the result 
that we have specific names like:

	media-flash-compact_flash
	media-flash-memory_stick
	media-flash-sd_mmc
	media-flash-smart_media

and the spec has the general icon:

	media-flash

which we don't have in any themes except Oxygen.  There is no problem 
with the fallback if we have a "media-flash" icon, but all existing 
themes will be missing it so if we switch to using the generic icon name 
(which I would vote no on) we are going to need to have a link:

	media-flash -> media-flash-<something>

using one of the specific icons for the generic icon.

It is the same with various types of disks.

3.	There has been some discussion about adding:

	view-fit-height
	view-fit-width
	view-fit-window

to the spec.  This probably isn't going to happen.  This issue could 
probably be resolved by KDE calling them: "zoom-fit-*" instead, except 
that although the spec has several icon names: "zoom-*" it doesn't have: 
"zoom" (KDE3 does have "viewmag" which will be renamed: "zoom") so we 
have the same issue where we need a fallback for non-KDE icon sets that 
isn't handled by shortening the
name.

4.	We haven't proposed a set of tab icons yet:

	tab-detach
	tab-duplicate
	tab-move-left
	tab-move-right
	tab-new
	tab-new-background
	tab-remove
	tab-remove-other

So, I don't know how this will come out.  Tango has only tab-new, so I 
don't see a complete set being added.

5.	I have proposed:

	view-next
	view-previous

If these are not added, there is no fallback to: "view" so they would 
need to link to:

	go-next
	go-previous

or to:

	media-seek-forward
	media-seek-backward
	
Either way, this would also require links.

============

There are currently a lot of icon in Oxygen that have not yet been 
mapped to the spec.  Therefore, I expect that as we work more on what to 
do about all the needed icons for KDE that aren't in the spec that many 
similar issues will come up where the KDE specific icon is not in the 
spec and we can not fallback to an icon in the spec by shortening the name.

The other issue is with MIME types.  It appears that there are many 
redundant (unofficial) MIME types and/or MIME types that can use the 
same icon.  With MIME types, it would also be good if missing MIME type 
icon names could map to a generic MIME type (could be just "empty" to 
start with) when fall back to a more generic name fails.  I also see 
problems here.  The spec and/or Tango has:

	x-office-address-book
	x-office-calendar
	x-office-document
	x-office-document-template
	x-office-drawing
	x-office-drawing-template
	x-office-presentation
	x-office-presentation-template
	x-office-spreadsheet
	x-office-spreadsheet-template

which can't be fallen back to by shortening the name of a specific type 
since the official types start with: "vnd.<brand>".

> 
> In any case, we could have an alias file (per theme) which would lessen 
> the duplication of icons in some themes.
> 
Actually, I think that it should be a general file since the purpose is 
to use themes that don't have all the needed icons because they are not 
intended as KDE themes.

-- 
JRT