Rodney Dawes wrote:
That would be like having user-trash, user-bookmarks, user-online,
user-desktop, and whatever else there might be, fall back to user.
Not very sensible at all is it?
No it isn't very sensible because the icons in your example should be
named: trash-user, bookmarks-user,
Rodney Dawes wrote:
On Thu, 2008-05-29 at 06:45 -0700, James Richard Tyrer wrote:
Rodney Dawes wrote:
That would be like having user-trash, user-bookmarks, user-online,
user-desktop, and whatever else there might be, fall back to user.
Not very sensible at all is it?
No it isn't very
Rodney Dawes wrote:
While having a list of icons that are not in the base specification is
great, I don't think we should list icons as a per-desktop thing. The
goal of icon themes, and the naming spec in particular, is that we can
use the same icons on all desktops.
I would much prefer the
Kai-Uwe Behrmann wrote:
Date: Mon, 15 Oct 2007 13:18:49 -0700
From: James Richard Tyrer [EMAIL PROTECTED]
What concerns do you see with recursive directory scanning?
The only issue is what should be done when there are two profiles with
the same name in different subdirectories which
Fosstux wrote:
Hi!
Well this document contains a list of icon names as a base of an icon
theme - but all the apps icons and the distribution specific icon names
are not included.
Yes, I agree. In fact, I suggested previously that in addition to to
icons included in the standard that a date
Patryk Zawadzki wrote:
. . . just pick two RPM-based distributions and try to install
packages from one in the other.
Fragmentation will kill Linux and that is what we are here to fix.
Yes You have correctly stated the problem which XDG needs to address
and solve. If 3rd party
Patryk Zawadzki wrote:
2007/12/11, James Richard Tyrer [EMAIL PROTECTED]:
It is really the same issue as with icons (and other things): what do we
do if two apps try to put something with the same name in the same
place. We really need to address that issue and although in this case
Cyrille Berger wrote:
On Monday 15 October 2007, Sven Neumann wrote:
Hi,
On Fri, 2007-10-12 at 15:10 -0700, James Richard Tyrer wrote:
I presume that these should go in:
/usr/share/color/profiles
I suggest that you follow the OpenICC Directory Proposal
http://www.oyranos.com/wiki
Cyrille Berger wrote:
Hello,
It comes to my attention today (thanks to breakage in building Krita that
lead
Zagge to skip Krita on a fresh install) that the CMYK color spaces (which are
shared in koffice/plugins/colorspace and one of them is required by the color
selector) require a
Ted Gould wrote:
Hello all,
In the Inkscape project we're constantly butting up against the problem
where there simply aren't enough modifiers for everything we'd like to
implement. This means for most of our tools there is a constant battle
to figure out how we can fit everything into
We are doing more work on KDE icon names and it has become very apparent
to me that KDE has a lot more icon names than the spec. I mean a LOT of
icons. I have a list of 128 KDE Control Module 'desktop' files that use
icons and although there are currently some duplications, this is still
a
Rodney Dawes wrote:
On Thu, 2007-08-02 at 10:34 -0700, James Richard Tyrer wrote:
Rodney Dawes wrote:
On Wed, 2007-07-18 at 11:34 -0700, James Richard Tyrer wrote:
I think that proper US English would be past due
Yes, the work 'passed' exists but it has a different use. Normally used
I think that proper US English would be past due
Yes, the work 'passed' exists but it has a different use. Normally used
to indicate that a physical object has been passed: I passed the ball; I
passed the car. But, an account is: 'past due'. This might be
different in British English.
And
x-office-document
The description for this:
The icon used for generic document and letter file types
is a bit ambiguous. If this is intended as a generic word processing
document, the description should clearly state this.
--
JRT
___
xdg
Jakob Petsovits wrote:
* Add a new icon
The icon for the create action.
Consequences for existing icons in the spec:
address-book-new - new-address-book
appointment-new - new-appointment
contact-new - new-contact
document-new - new-document
folder-new -
Jakob Petsovits wrote:
jimmac the major part of that all making sense is the generic type fallback
Hi list,
yesterday I started to tackle KDE's actions icons for icon naming spec
compliance, and I stumbled across a major bug in the spec, so to say, or at
least something that will make
Brian J. Tarricone wrote:
Not to sound flippant or dismissive, but... who cares?
You do sound flippant and dismissive. :-D
It's already how it is, so why make extra work for something that's
purely an implementation detail that end-users won't see anyway?
As a retired EE, I have to tell
KDE is NOW in the process of implementing the Icon Naming Spec.
Unfortunately, up until just recently, we basically said 'well that is
nice' and didn't pay much attention to it.
So, I think that you can expect a lot of suggestions and issues from KDE
in the next month or so. I'm sorry that we
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
Rodney Dawes wrote:
I had no knowledge of how Firefox does the spinner
image, when writing the specification.
I used this only as an example. Actually, I should have referred to my
copy of the Firefox spinner which I attached to the original posting.
The important point is that there are
Jakob Petsovits wrote:
On Friday, 13. July 2007, James Richard Tyrer wrote:
IAC, these view-fit-* icons are for applications that display documents
or photos. For example, a PDF viewer. Whether an application uses all
three depends on the application. view-fit-window view-fit-width
Jakub Steiner wrote:
On Thu, 2007-07-05 at 19:27 -0700, James Richard Tyrer wrote:
You are correct that it isn't in the spec (yet?). It is in the Tango
icons. Part of the problem, I guess. Tango and the Icon Naming spec
aren't 100% the same.
The reason for tango icon theme shipping
Jakub Steiner wrote:
On Tue, 2007-06-26 at 18:03 -0700, James Richard Tyrer wrote:
I have posted three needed icons to:
http://www.freedesktop.org/wiki/Specifications/icon-naming-spec/to-be-named
view-fit-window
view-fit-height
view-fit-width
How do I go about getting
Rodney Dawes wrote:
On Thu, 2007-07-05 at 19:27 -0700, James Richard Tyrer wrote:
Jakob Petsovits wrote:
On Wednesday, 4. July 2007, James Richard Tyrer wrote:
I note that the Icon Naming spec includes:
animations/process-idle animations/process-working
Er, no, the naming spec does
Rodney Dawes wrote:
On Fri, 2007-07-06 at 07:57 -0700, James Richard Tyrer wrote:
Unfortunately, KDE doesn't fit with either of these. That is, KDE
doesn't have an idle image. It cycles through all of the images in
the PNG. So, we are going to have to change something in the code
either
Jakob Petsovits wrote:
On Wednesday, 4. July 2007, James Richard Tyrer wrote:
I note that the Icon Naming spec includes:
animations/process-idle
animations/process-working
Er, no, the naming spec does not include process-idle.
Instead, it says in the description of process
I note that the Icon Naming spec includes:
animations/process-idle
animations/process-working
With KDE, these would replace the multiple image PNG called:
actions/kde. With cross platform themes and icon naming, this raised
the question of whether this icon should incorporate
Bastien Nocera wrote:
On Sun, 2007-06-24 at 16:23 -0700, James Richard Tyrer wrote:
Diego Iastrubni wrote:
(a little off topic)
I have found that the icons used in Qt3 (amarok, kaffeine) look funky on
RTL
(right to left) desktops. Has anyone started thinking about a fix for that
problem
I have posted three needed icons to:
http://www.freedesktop.org/wiki/Specifications/icon-naming-spec/to-be-named
view-fit-window
view-fit-height
view-fit-width
How do I go about getting these blessed and added to the Icon Naming spec?
--
JRT
Diego Iastrubni wrote:
ביום שני, 25 ביוני 2007, נכתב על ידי James Richard Tyrer:
I am aware of this issue and these two KDE3 icons: previous next
shouldn't be interchanged for RTL language/locales. Since these are not
the icons for a KDE Standard Action, this is an issue with individual
In KDE3, we have 4 arrow icons:
up
forward
down
back
That move step wise and the corresponding 4 arrow icons:
top
finish
bottom
start
that go all the way in that direction.
We also have two additional icons:
next
Patryk Zawadzki wrote:
On 6/18/07, James Richard Tyrer [EMAIL PROTECTED] wrote:
or that the DeskTop supplies an icon for that MIME type in the
HiColor theme.
It is this last case that is the problem and it does need to be
solved.
There is nothing to be solved.
You are partially
Matthias Clasen wrote:
SNIP
The spec simply states that hicolor will always be tried, and that it
will be the last.
Well maybe. It clearly states that, but I think that it also states
additional things.
That means that it is a good place to install icons to, which you
need to be available
Aaron J. Seigo wrote:
On Sunday 03 June 2007, James Richard Tyrer wrote:
Oswald Buddenhagen wrote: SNIP
my first idea was to have hicolor Inherits: kdeclassic,
crystalsvg. however, this leads to desktop-specific versions of
hicolor. so i would suggest inverse inheritance: once we arrive
Oswald Buddenhagen wrote:
SNIP
my first idea was to have hicolor Inherits: kdeclassic, crystalsvg.
however, this leads to desktop-specific versions of hicolor.
so i would suggest inverse inheritance: once we arrive at hicolor
(possibly through auto-add) and the icon is not found there, we
Kenneth Wimer wrote:
On Tuesday 01 May 2007 03:38:27 James Richard Tyrer wrote:
Yes, you are absolutely correct about that. So I made the neutral,
unthemed, generic icons and installed them in HiColor. They were
removed from SVN without even consulting me. I was told that I could
install
Matthias Clasen wrote:
On Mon, 2007-04-30 at 11:57 -0700, James Richard Tyrer wrote:
It is recommended that the icons installed in the hicolor theme
look neutral, since it is a fallback theme that will be used in
combination with some very different looking themes.
My reading
Patryk Zawadzki wrote:
Even if there was I strongly believe that no particular desktop
should place a full-blown icon theme in a shared path.
I agree that this is an issue that needs to be addressed. At the
present time it isn't much of a problem. However, when we all start to
use icon
Patryk Zawadzki wrote:
On 4/27/07, James Richard Tyrer [EMAIL PROTECTED] wrote:
As I see it, the problem is that we don't have a proper set of
HiColor icons. Someone moved all the existing HiColor icons to
KDEClassic and for some reason all new HiColor icons were removed.
Then some HiColor
Kenneth Wimer wrote:
You say yourself that icon themes will never be complete...so the hicolor
theme you desire also fails in this way...not sure what you want exactly.
Yes, a complete icon set should never be presumed, that is why I have
clearly stated that there needs to be a way to
Behdad Esfahbod wrote:
On Sun, 2006-09-03 at 01:18 -0400, James Richard Tyrer wrote:
So, there are 16 selections available in the: Style window
and they are NOT sorted into any logical order:
Condensed Light
Light
Condensed Light Oblique
Light Oblique
Jan Claeys wrote:
IMHO those TrueType font files have incorrect font family fields.
(But the reason for that is that the foundries have to do this because
Windows font family handling is broken--Mac TrueType fonts might have
this different!)
IIUC, Qt reads the Mac data from TrueType font
Christopher R. Parr wrote:
Hello!
I'm trying to start a new project - Ixons (Icons on Unix). Its aim is
to think about a way to manage all the icons for any desktop.
Interested?
Then have a look at http://ixons.info
Please tell me what you think about this.
1. There is a standard for
Jonathan Riddell wrote:
What is the best practice for having two desktops each with their own
preferences for the applications menu?
Currently it seems to me its a choice between one desktop using a
non-standard applications.menu file (e.g. in Kubuntu I use
/etc/xdg/menus/kde-applications.menu)
Marcus Grassinger wrote:
Hi Folks,
I'm evaluating whether KDE 3.5.1 (Level a) respects the icon-lookup-spec.
I concluded that it doesn't. Do you think that is due to SuSE-specific
changes in the kde-configuration?
The only time when icons get shown in KDE is when I place them in
nf2 wrote:
James Richard Tyrer wrote:
Getting back to this actual question:
If different DeskTops install icons in HiColor there is going to be a
problem.
Currently, GNOME prefixes their icon names with: gnome and by so
doing avoid this issue. KDE naturally presume that you will only use
Getting back to this actual question:
If different DeskTops install icons in HiColor there is going to be a
problem.
Currently, GNOME prefixes their icon names with: gnome and by so doing
avoid this issue. KDE naturally presume that you will only use KDE so
they just have simple icon names
Travis Watkins wrote:
On 7/9/06, James Richard Tyrer [EMAIL PROTECTED] wrote:
Getting back to this actual question:
If different DeskTops install icons in HiColor there is going to be a
problem.
Perhaps something like the tango icons could be the hicolor theme?
Yes, if we had a central
Rodney Dawes wrote:
We're probably certainly talking about different things. Given that you
already pointed out that kde stores data in ~/.kde/something, this new
argument about .local and .config is irrelevant. The Icon Theme
specification clearly defines ~/.icons as the home search path. This
Aaron J. Seigo wrote:
as has been covered infinitely elsewhere, unless we are trying to
solve the problem of third party icon sets being able to add to
application's private icons, then this is a spurious conclusion.
I see that as an issue that needs to be addressed. Cross platform icon
Bastian, Waldo wrote:
[I]t is undesirable for applications to install icons into
$XDG_DATA_DIRS if there is no actual requirement for doing so.
Why?
IIUC, an app would be installing its theme-able icons in:
$PREFIX/share/app_name/icons/theme/...
or
Shaun McCance wrote:
KDE and GNOME aren't toolkits, per se. QT is a toolkit. GTK+ is a
toolkit.
You are correct. However, KDE functions as a TookKit even though it is
actually a wrapper for Qt. That is, KDE apps generally call KDELibs
functions rather than calling Qt directly. OTOH, it is
Aaron J. Seigo wrote:
On Wednesday 28 June 2006 23:21, James Richard Tyrer wrote:
Aaron J. Seigo wrote: There *is* KDE GUI configuration in
$PREFIX/share/config/. There may also be other information, but it
is the GUI information that I am concerned with.
please realize that it's more than
Aaron J. Seigo wrote:
On Thursday 29 June 2006 01:22, Bastian, Waldo wrote:
icons into a $XDG_DATA_DIRS location. It's ok to add these locations to
the search path
... aside from the performance penalty of having yet more paths to look at? we
already look at a rather large number of
Bastian, Waldo wrote:
I don't know why KDE chose: apps for the subdirectory when: kde
would have been a better choice.
KDE's file hierarchy is explained here:
http://www.kde.org/areas/sysadmin/fsh.php
That doesn't really explain the choice of names for:
share/apps/
Thiago Macieira wrote:
James Richard Tyrer wrote:
That doesn't really explain the choice of names for:
share/apps/
share/config/
which are KDE specific but don't include 'kde' in the name.
Those are straightforward: application-specific files and configuration
files.
Why
Rodney Dawes wrote:
The stuff in config, should probably actually be in /etc or such.
Since this is GUI configuration information and GNOME also puts it as a
subdirectory of 'share', I would keep it where it is and just change the
name of the subdirectory -- kde-3 in the current case.
--
Thiago Macieira wrote:
Rodney Dawes wrote:
James and I agreed that app-specific icons should be installed to the
$XDG_DATA_DIRS/$appname/icons/$theme/... path structure, and that these
such paths should be added automatically to the search list by the icon
theme implementation. I already have a
Kenneth Wimer wrote:
On Jun 29, 2006, at 12:20 AM, James Richard Tyrer wrote:
Thiago Macieira wrote:
Rodney Dawes wrote:
James and I agreed that app-specific icons should be installed to the
$XDG_DATA_DIRS/$appname/icons/$theme/... path structure, and that these
such paths should be added
Aaron J. Seigo wrote:
On Wednesday 28 June 2006 16:10, James Richard Tyrer wrote:
Rodney Dawes wrote:
The stuff in config, should probably actually be in /etc or such.
Since this is GUI configuration information and GNOME also puts it as a
subdirectory of 'share', I would keep it where
Stephan Kulow wrote:
Am Donnerstag, 29. Juni 2006 00:54 schrieb James Richard Tyrer:
This probably doesn't make much difference (at least for now) for KDE
apps and GNOME apps because they will continue to use their respective
icon loaders to load the icons. But, what about third party apps
Rodney Dawes wrote:
GNOME is not the only thing that doesn't have automagical lookup of
app-specific icons in a private directory that mimics the layout of
icon themes. GNOME simply implements the Icon Theme Specification,
which clearly does not state any way to do this. KDE implements
things
Rodney Dawes wrote:
On Mon, 2006-06-26 at 08:41 -0700, James Richard Tyrer wrote:
Yes, KDE's icon names are a mess. But, I don't know of anything
that can't be fixed by renaming them all.
The names aren't really the problem. Names are easily solved with
symlinks and trivial patches to apps
Bastian, Waldo wrote:
I am picky about the difference between
$KDE_PREFIX/share/apps/app_name/icons/theme/size/type And
$XDG_DATA_DIRS/apps/app_name/icons/theme/size/type
Because the latter should only be used if there is a specification
that describes its use. And yes, I agree that this is
Alexander Larsson wrote:
On Thu, 2006-06-01 at 13:32 -0700, James Richard Tyrer wrote:
This paragraph:
The lookup inside a theme is done in three phases. First all the
directories are scanned for an exact match, e.g. one where the allowed
size of the icon files match what was looked up
Rodney Dawes wrote:
Hi,
Sorry for the slow reply. I was on vacation last week, and have been
a bit busy this week.
On Tue, 2006-06-06 at 08:11 -0700, James Richard Tyrer wrote:
We need a common place to install menu icons (i.e. apps icons).
We have one. The hicolor icon theme is where app
Steve Frécinaux wrote:
James Richard Tyrer wrote:
I hope that the above contradiction in your own statements will
start you thinking -- that you will think about design before you,
and other developers, do any more stupid things.
Sorry, I didn't see any contradiction in the above. Icons
Alexander Larsson wrote:
On Tue, 2006-06-20 at 17:11 -0700, James Richard Tyrer wrote:
With something like this in place the mime spec for the
application/x-scribus mimetype could specify a generic icon name that
all icon themes have, and then the file conflict issue is much less
problematic
Waldo Bastian wrote:
On Friday 16 June 2006 06:04, Mike Hearn wrote:
This wasn't written by me but apparently it works:
http://cvs.sunsite.dk/viewcvs.cgi/autopackage/main/share/apkg-mimetype.xsl?
rev=1.3content-type=text/vnd.viewcvs-markup
Bear in mind they aren't an exact match. You have to
Steve Frécinaux wrote:
James Richard Tyrer wrote:
But, I have to wonder, is this icon name going to be used by
multiple DeskTops? Won't all DeskTops with a menu have a Menu
Editor app? Will the same be true for Control Center and Theme
Manager?
If they are well behaved,
Ah yes, if only
Pascal De Vuyst wrote:
SNIP
Clarify what Type=Threshold means.
If I understand correctly this is used to match icon sizes that differ
plus or minus the Threshold value from the requested size.
I also have a question about Threshold since (some of) the original KDE
HiColor icons (now
Travis Watkins wrote:
On 6/6/06, Waldo Bastian [EMAIL PROTECTED] wrote:
Is menu-editor supposed to be an apps icon or an actions icon here?
In Tango it's in the apps directory.
Then it is a bad example. I should have switched to an icon that wasn't
an app icon since there shouldn't be a
Travis Watkins wrote:
On 6/6/06, James Richard Tyrer [EMAIL PROTECTED] wrote: [massive snip]
Not sure I see a problem. Icon themes shouldn't install icons for
applications in hicolor, applications should install their own icons.
Yes application specific icons installed in the apps private
This paragraph:
The lookup inside a theme is done in three phases. First all the
directories are scanned for an exact match, e.g. one where the allowed
size of the icon files match what was looked up. Then all the
directories are scanned for any icon that matches the name. If that
fails we
The Icon Naming Spec lists four left and right arrows:
go-first
go-previous
go-next
go-last
I question whether go-previous and go-next are the correct names for
these two icons. In KDE, they are called: back and forward so using
this, the standard would use the names: go-back and go-forward.
Stephan Kulow wrote:
Am Mittwoch, 19. Oktober 2005 04:52 schrieb James Richard Tyrer:
I suggest that it is possible that recursion is not a good idea,
but that is the current standard.
OK, then I suggest we change the standard to say that KDE does not
support multiple inheritance
I
Rodney Dawes wrote:
On Sun, 2005-10-16 at 02:00 -0700, James Richard Tyrer wrote:
SNIP
You shouldn't need to create a symlink to hicolor, nor should you need
to provide hicolor in the Inherits= list for your theme, as it must be
the absolute last theme in the theme tree, according to the spec
The spec states:
The name of the theme that this theme inherits from. If an icon
name is not found in the current theme, it is searched for in
the inherited theme (and recursively in all the inherited
themes).
But exactly how should the inheritance tree be
78 matches
Mail list logo
