Talk:Projects/Oxygen/namingSpec/places: Difference between revisions

From KDE TechBase
No edit summary
 
(Answer JRT's take on folders.)
Line 23: Line 23:


--[[User:JRT|JRT]] 18:50, 18 July 2007 (CEST)
--[[User:JRT|JRT]] 18:50, 18 July 2007 (CEST)
Ok, one by one:
* While the purpose here should not be to rewrite the existing standard, we need a place to gather our suggestions, which then will be forwarded to XDG. At least, that's the idea.
* I don't see applications using the folder icon for anything other than what inode/directory means anyways, but there are already two people bringing this argument up, and it has some merit nevertheless. Accepting that the chances on changing the spec this way are very little, and that the argument is not entirely wrong, I give in to this one, and we'll have both folder and inode-directory. Now the only thing left to do is to patch libgnomeui so that it displays inode-directory instead of, er, gnome-fs-directory, before they switch to the folder icon.
* folder-<color>: I disagree. Colored folders are not mimetypes and do not belong in the mimetype category. They are custom user icons, and should be treated as such. Just as folder is the icon for displaying folders specific to an app's user interface instead of mimetypes, the folder icons are just there for application specific usage. If application specific usage means replacing the real directory icon (inode-directory) with folder-<color>, so be it. But that's no reason to move folder-<color> into the mimetypes category. Remember, users could just as well select start-here or any other available icon as custom folder icon, and start-here is not moved into mimetypes as well.
* folder-<type>: I evaluated them on a case-by-case basis, and none of them needs to stay in places. folder-locked is the only one that refers to a directory mimetype, and will be done by using the emblem-readonly or emblem-unreadable. All the others are custom, user-specific annotations that are not in the spec, and can and should be done with emblems as well. GNOME also uses emblems for doing such stuff.
--[[User:Jpetso|jpetso]] 21:13, 25 July 2007 (CEST)

Revision as of 19:13, 25 July 2007

folder

folder                   OK with the current spec, but it
                            really belongs to mimetypes as
                            inode-directory *, in order to
                            follow the shared MIME info standard.

The purpose here should NOT be to rewrite the existing standard. That discussion takes place on the XDG mailing list at FD.o.

As I see this, "places/folder" and "mimetypes/inode-directory" might have the same image, but we should not presume that this is the case. The icon "places/folder" is to be displayed in the "places" context which IIUC would be a toolbar or menu icon. OTOH, "mimetypes' icons are to be displayed as icons in the window of a file manager or file selection dialog. These are not the same uses.

folder-<color>

These icons are to be used as MIME type icons. Therefore, they should be renamed to: "mimetypes/inode-directory-<color>"

folder-<type>

These need to evaluated on an item by item basis. If they are needed for "places" icons then they should be retained. However, if they are for MIME type icons, the ones for "inode-*" should be removed and emblems should be used instead.

Use of emblems

Emblems should only be used on MIME type icons. Icons for "places" will have an icon name and should not be 'emulated' with emblems.

--JRT 18:50, 18 July 2007 (CEST)


Ok, one by one:

  • While the purpose here should not be to rewrite the existing standard, we need a place to gather our suggestions, which then will be forwarded to XDG. At least, that's the idea.
  • I don't see applications using the folder icon for anything other than what inode/directory means anyways, but there are already two people bringing this argument up, and it has some merit nevertheless. Accepting that the chances on changing the spec this way are very little, and that the argument is not entirely wrong, I give in to this one, and we'll have both folder and inode-directory. Now the only thing left to do is to patch libgnomeui so that it displays inode-directory instead of, er, gnome-fs-directory, before they switch to the folder icon.
  • folder-<color>: I disagree. Colored folders are not mimetypes and do not belong in the mimetype category. They are custom user icons, and should be treated as such. Just as folder is the icon for displaying folders specific to an app's user interface instead of mimetypes, the folder icons are just there for application specific usage. If application specific usage means replacing the real directory icon (inode-directory) with folder-<color>, so be it. But that's no reason to move folder-<color> into the mimetypes category. Remember, users could just as well select start-here or any other available icon as custom folder icon, and start-here is not moved into mimetypes as well.
  • folder-<type>: I evaluated them on a case-by-case basis, and none of them needs to stay in places. folder-locked is the only one that refers to a directory mimetype, and will be done by using the emblem-readonly or emblem-unreadable. All the others are custom, user-specific annotations that are not in the spec, and can and should be done with emblems as well. GNOME also uses emblems for doing such stuff.

--jpetso 21:13, 25 July 2007 (CEST)