On Fri, 2010-01-29 at 18:17 +0100, Wolfram Kleff wrote:
Request for Comments/Standards update suggestion:
I would like to suggest a .log directory in the $HOME directory like the
.cache directory.
The .log directory would be a good place for all the log, history and
recent
files which
On Thu, 2009-12-10 at 21:07 +0100, Kenneth Wimer wrote:
On Tuesday 08 December 2009 03:38:15 pm Rodney Dawes wrote:
On Sun, 2009-12-06 at 16:43 +, Matthew Paul Thomas wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jakub Steiner wrote on 02/12/09 22:55:
...
What
On Thu, 2009-12-10 at 21:01 +, Nuno Pinheiro wrote:
this may be a very silly idea but i thought i should share, couldn't it make
sense to simply make a font with all the symbols you need,
as i told you guys KDE is probably going to implement this type of icons
inside plasma specific
On Sun, 2009-12-06 at 16:43 +, Matthew Paul Thomas wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jakub Steiner wrote on 02/12/09 22:55:
...
What the important part here is that the color isn't defined in the
icon itself, it's up to the widget theme to define in all sorts of
On Wed, 2 Dec 2009 17:52:13 +0100
Jakub Steiner jim...@gmail.com wrote:
On Wed, Dec 2, 2009 at 5:11 PM, Kenneth Wimer kw...@sinecera.de
wrote:
Most important will be the foreground colors like normal, prelight,
active, selected and insensitive.
To keep things simple, we should treat the
On Thu, 2009-09-03 at 11:17 +, Aceler wrote:
John Tapsell johnflux at gmail.com wrote at Tue Sep 1 07:00:55 PDT 2009:
Another issue - stealing focus. In X Window, every app that requests
focus, gets it.
I think KWin disables focus stealing by default. Either way, you can
turn it on
On Thu, 2009-07-23 at 20:00 -0600, Aaron J. Seigo wrote:
On Thursday 23 July 2009, Michael Pyne wrote:
hearing someone from a i18n who has actually had a problem completing the
translation because the current means available are insufficient.
The i18n issues aren't in translating the text.
I generally disagree with the idea that in order to use the
org.freedesktop namespace for DBus interfaces, you must first gain
acceptance through having multiple desktops use your interface.
This means that it will be much harder to gain acceptance (as I'm sure
that lots of KDE developers are
I've created a project [1] on Launchpad for this now. Please go ahead
and file some requests there as separate bugs for each icon name. Both
Ken [2] and myself should be notified of new bugs against the project.
Thanks.
[1] http://launchpad.net/icon-naming-spec
[2] Ken Wimer is now a
On Tue, 2009-06-30 at 13:02 +0100, Simon McVittie wrote:
ia64-linux-gnu (is the word size/endianness differentiation really necessary,
or is there one endianness and word size that, in practice, everyone uses?
If you really need to distinguish, talk to config-patc...@gnu.org, without
which
On Mon, 2009-06-29 at 23:09 +0200, Lennart Poettering wrote:
On Sun, 28.06.09 18:10, Aaron J. Seigo (ase...@kde.org) wrote:
The big problem is that noone else but Rodney is willing to maintain
the spec.
so, i should have asked this the first time, but i figured maybe an irc
meet-
On Tue, 2009-06-30 at 03:58 +0200, Lennart Poettering wrote:
On Mon, 29.06.09 21:40, Rodney Dawes (dobey.p...@gmail.com) wrote:
Another reason to suggest using Launchpad Bugs to track their status.
It provides meaningful status field information, priority, and threaded
comments via
On Fri, 2009-06-26 at 15:19 +0200, stefan.k...@nokia.com wrote:
hi,
the spec [1] only talks about
XDG_DATA_DIRS/HOME - e.g. icons, docs, ... equiv of e.g. /usr/share
XDG_CONFIG_DIRS/HOME - settings, equiv of /etc
XDG_CACHE_DIRS/HOME - e.g. a plugin cache, equiv of /var/cache
but there
On Sun, 2009-06-28 at 14:31 -0600, Aaron J. Seigo wrote:
On Sunday 28 June 2009, Lennart Poettering wrote:
The big problem is that noone else but Rodney is willing to maintain
the spec.
if someone was found who would maintain it and had the appropriate experience
to do so, would such a
On Fri, 2009-06-26 at 19:21 -0600, Aaron J. Seigo wrote:
a couple of people have offered this POV now. this concerns me deeply, as KDE
just recently adopted this spec. the only reason we went through all that
work[1] was to gain the benefits of a shared spec. if the spec dies now, then
our
On Thu, 2009-06-25 at 20:32 +0200, Julien Danjou wrote:
At 1245949338 time_t, Nicolò Chieffo wrote:
There is the possibility to subscribe a new launchpad project about
the icon naming spec, to better follow versions, bugs, feature
requests, user questions.
In my opinion we should go,
On Thu, 2009-06-25 at 17:20 -0400, Matthias Clasen wrote:
On Thu, 2009-06-25 at 15:02 -0600, Aaron J. Seigo wrote:
my only question is whether or not this is something that the various
participants in working on the icon spec are in favour of? i assume/hope
so,
but as it hasn't been
On Thu, 2009-06-25 at 15:02 -0600, Aaron J. Seigo wrote:
On Thursday 25 June 2009, Rodney Dawes wrote:
Bugzilla and MoinMoin don't provide useful work-flow for maintaining
status and discussion of something like icon names. They are not
particularly great for task oriented work-flows, while
As I already stated elsewhere, I think folder-foo is better here, absent
the usage of emblems on the normal folder icon, which would be more
appropriate.
Though, I think there are some oddities in the naming of the folders
themselves, which we might want to avoid duplicating in the icon names
for
Hi,
The Recent Files spec isn't XBEL. I don't know how implementable this
is, but I think it would be better to store configuration in config
somewhere. Perhaps this could be implemented via dconf (when it is
available) or with an XSetting, so that it will work for both desktops.
-- Rodney
On
content folder base quite problematic.
So this needs to get somehow dealt with.
Regards,
Torsten
Am Samstag 06 Juni 2009 11:04:40 schrieb Stephan Arts:
On Thu, Jun 4, 2009 at 3:59 PM, Rodney Dawes dobey.p...@gmail.com wrote:
On Wed, 2009-06-03 at 09:19 +0200, Stephan Arts wrote
Popularity contests are not the way to solve design issues. Also, we
already have a forum for voting on these issues. It's called mailing
list discussion. Having a straight yes/no vote on the issues doesn't
dissect the issues that may in fact cause other issues, which is why
they aren't getting
On Wed, 2009-06-03 at 09:19 +0200, Stephan Arts wrote:
On Tue, Jun 2, 2009 at 7:47 PM, Rodney Dawes dobey.p...@gmail.com wrote:
The biggest issues I see, are icon themes, cursor themes, and sound
themes. These are currently installed in separate paths from other
theme bits, and cursors
On Thu, 2009-05-14 at 11:25 +0300, Marius Vollmer wrote:
True, but what might work is to have a second Extra Icons spec that
works together with the base icon spec.
This Extra Icon spec would, by design, have the same goals as the base
spec, but would be maintained in a more 'reasonable'
On Thu, 2009-05-14 at 11:55 -0700, Brian J. Tarricone wrote:
and has been for a long while now. And the base spec clearly identifies
how to name these device icons anyway, for specific types of devices,
with only the base types being in the base spec, so everything falls
back to those base
On Thu, 2009-05-14 at 16:08 -0700, Brian J. Tarricone wrote:
Rodney Dawes wrote:
On Thu, 2009-05-14 at 11:55 -0700, Brian J. Tarricone wrote:
No. I never actually denied these icons, or specifically stated they
were a bad idea. I asked questions about how they would be used, and
what
On Tue, 2009-05-12 at 23:19 +0200, Lennart Poettering wrote:
On Sat, 02.05.09 16:14, Lennart Poettering (mz...@0pointer.de) wrote:
On Tue, 21.04.09 01:41, Lennart Poettering (mz...@0pointer.de) wrote:
I am still convinced that having these four (or five) icon names for
all things
On Fri, 2009-04-10 at 03:33 +0200, Lennart Poettering wrote:
On Wed, 18.03.09 21:56, Lennart Poettering (mz...@0pointer.de) wrote:
May I suggest the following names?
audio-card (as it exists right now, intended for the generic idea of
'audio')
I really want to change this, but I'm
On Mon, 2009-03-30 at 19:25 +0200, Patryk Zawadzki wrote:
On Mon, Mar 30, 2009 at 4:34 PM, Pat Suwalski p...@suwalski.net wrote:
Daniel Bo wrote:
That said, I wonder why the choice was to set a default application
for opening when most file types have view and edit modes. Why are
there
On Mon, 2009-03-16 at 18:36 +0100, Sanel Zukan wrote:
Does this mean that when $HOME/.icons/foo-theme/index.theme was read,
all other directory entries from
/usr/share/pixmaps/foo-theme/index.theme are ignored, except 48x48/apps?
Yes.
___
xdg
On Wed, 2009-03-11 at 11:08 +, Bastien Nocera wrote:
they both require a jack-plug, bluetooth- or irda
interface to send audio from a machine to your ear.
Given that thinking, a scanner, a camera and a webcam are the same thing
as well :)
I certainly use my DSLR to scan receipts for
This is handled through categories. Of course Rhythmbox doesn't play
multiple types of media yet afaik. It only does music. :)
If the categories in the .desktop file for the app, and the .menu file
match up, then the app shows up in that menu, unless the implementation
is doing something
On Wed, 2009-01-14 at 20:21 +0100, schoappied wrote:
Rodney Dawes wrote:
This is handled through categories. Of course Rhythmbox doesn't play
multiple types of media yet afaik. It only does music. :)
If the categories in the .desktop file for the app, and the .menu file
match up
On Sat, 2009-01-10 at 22:09 +0100, Dieter Plaetinck wrote:
Hi all,
at http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
it is explained that $XDG_DATA_{HOME,DIRS} is for (user specific) data
files and $XDG_CONFIG_{HOME,DIRS} for (user specific) configuration
files.
On Mon, 2009-01-05 at 07:03 -0500, Fred Drake wrote:
On Mon, Jan 5, 2009 at 4:13 AM, Matthew Smith indig...@blogistan.co.uk
wrote:
The problem is that none
of the registered categories actually cover blogging clients, as it's
not a web browser nor a web development application (let alone
The Icon Naming Specification itself only provides the minimal list of
names. I've changed the text you referenced, to clarify this, in CVS.
There will be addendums to provide lists of names for extra icons, such
as devices[1] and MIME types.
The names in the spec itself are intended to be the
On Sun, 2008-12-07 at 13:52 +0200, Ville Skyttä wrote:
On Sunday 07 December 2008, Rodney Dawes wrote:
On Sat, 2008-12-06 at 01:05 +0100, Jakob Petsovits wrote:
Yes, of course. I'm aware that gnome-icon-theme has little relevance to
spec issues, and did not intend to imply any connection
On Sat, 2008-12-06 at 01:05 +0100, Jakob Petsovits wrote:
Yes, of course. I'm aware that gnome-icon-theme has little relevance to spec
issues, and did not intend to imply any connection, just that it's not
currently possible to use an application-octet-stream icon while assuming
that
it
On Thu, 2008-11-27 at 20:39 +0200, Ville Skyttä wrote:
Hi,
I think the icon naming spec is lacking a generic binary MIME type icon. For
example, recent shared-mime-info has set text-x-generic for a lot of file
types that have nothing to do with text, I suppose because there's no better
On Thu, 2008-12-04 at 10:26 +0100, Jakob Petsovits wrote:
On Tuesday 02 December 2008, Rodney Dawes wrote:
It is maintained. And I am very easily contacted.
You might consider to reply to the original post in this thread.
I believe the lack of feedback about past proposals contributes
It is maintained. And I am very easily contacted.
On Tue, 2008-12-02 at 21:51 +0800, PCMan wrote:
Second that!
Forking is needed if the original spec is no more maintained and the
original maintainer cannot be contacted.
On Tue, Dec 2, 2008 at 9:07 PM, Richard Hughes [EMAIL PROTECTED]
On Mon, 2008-12-01 at 20:09 +0100, Jakob Petsovits wrote:
Although, didn't someone propose a distinction between specifications that
have
generally been agreed upon, and specifications that have not?
The Specifications wiki page should have that already, listing the
specifications in such
On Wed, 2008-11-12 at 11:10 -0500, Liam R E Quin wrote:
Certainly nowhere starting with a . -- I don't want to be
carrying binaries around in hidden directories in 10 years' time.
Luckily the world is going to end in ~4 years, so we won't have to
worry about what the convention is 10 years from
On Mon, 2008-11-10 at 11:30 +0100, Thiago Macieira wrote:
Orion White wrote:
Hi--
I've begun to use the XDG base directory standard for my projects, and I
am very happy with it.
However, I do not understand the rational behind .local/share. I have
searched the Internet for some
The details are in the spec. The problem with file type icons is people
assign arbitrary things as the MIME type. Like application/foo for
audio files, or text types. It seems like most new things just end up
under application/ when they would be better suited to other groups,
or perhaps should
On Thu, 2008-09-25 at 15:38 +0100, Richard Hughes wrote:
On Wed, 2008-09-24 at 11:30 +0200, Stephan Arts wrote:
I noticed system-suspend system-hibernate and system-reboot are
missing from 0.8.90, is that is CVS?
I've given up on the icon-naming-spec, it's just too hard for developers
to
On Thu, 2008-09-25 at 21:05 +0200, Jakob Petsovits wrote:
And a staging area. Like, a place where developers can list their icons
regardless of applicability in other desktops, and other devs list theirs
too,
and everyone can have a look at what similar applications use and
consequently
Do you know of some way to make the -latest.html link get generated
from the spec in cvs, rather than just pointing at the latest version
that was released? There hasn't been a release since the 0.8 version
of the spec.
I suppose I can make an 0.9 version if there is some immediate pressing
need
Hi,
On Mon, 2008-09-22 at 16:41 +0200, Stephan Arts wrote:
gnome-fs-blockdev
gnome-fs-fifo
gnome-fs-socket
gnome-fs-chardev
gnome-fs-regular
As you can see, I found replacements for the top 7 icons pretty
easilly. But the last 7 confuse me, which icon-names should be used
for that?
On Mon, 2008-09-22 at 11:03 -0400, Matthias Clasen wrote:
On Mon, 2008-09-22 at 10:56 -0400, Rodney Dawes wrote:
Hi,
On Mon, 2008-09-22 at 16:41 +0200, Stephan Arts wrote:
gnome-fs-blockdev
gnome-fs-fifo
gnome-fs-socket
gnome-fs-chardev
gnome-fs-regular
As you can
On Thu, 2008-09-04 at 17:53 +0200, Matej Tyc wrote:
Hello,
I am developing an aplication that could use a menu entry. I have
learned that I have to drop an appropriate .desktop file
to /usr/share/applications, but I have problems with icons.
If I write Icon=foo, then where to put the actual
On Thu, 2008-09-04 at 11:28 -0500, D. Marlin wrote:
Matej Tyc wrote:
Hello,
I am developing an application that could use a menu entry. I have
learned that I have to drop an appropriate .desktop file to
/usr/share/applications, but I have problems with icons.
If I write Icon=foo, then
On Tue, 2008-06-17 at 09:14 -0400, Matthias Clasen wrote:
On Tue, 2008-06-17 at 12:35 +0200, Jakob Petsovits wrote:
As long as providing such a [base]+[emblem] icon is always optional for the
icon theme, this might work out nicely. I think the language in your patch
is
not optimal
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 sensible because
On Sat, 2008-04-26 at 15:55 +0200, Vincent Untz wrote:
Hi,
I've asked for the creation of a git repository to host all fd.o specs
(will make things much easier). I think it'd make sense to send commit
notifications to this list since it will help people track the progress
and the changes.
On Wed, 2008-04-23 at 22:49 +0800, 洪任諭 wrote:
No, lxsession and lxsession-lite don't do that.
lxde-settings, however, map a simple config file with ini format to
xsettings for LXDE.
Besides, xsettings is NOT practically desktop-neutral.
Currently only GTK+ programs use it.
Not true.
No
On Mon, 2008-04-21 at 03:09 +0800, 洪任諭 wrote:
2008/4/21, [EMAIL PROTECTED] [EMAIL PROTECTED]:
洪任諭 wrote:
We should have only one set of common theming API for all toolkits.
Then some backends for every toolkits should be created by the developers
who master these toolkits.
I would vote for having it be either Philosophy or Theology.
-- dobey
On Wed, 2008-04-16 at 14:57 +0200, Vincent Untz wrote:
Le lundi 14 avril 2008, à 21:47 +0800, Toma a écrit :
Well there is a growing number of Religious software about and it
should have a home in the menu. Its a matter
On Thu, 2008-04-10 at 23:31 +0200, Jakob Petsovits wrote:
On Thursday, 10. April 2008, Aaron J. Seigo wrote:
On Thursday 10 April 2008, jmehdi wrote:
Hi Mehdi,
Out of curiosity, what software are you thinking of having in
there? :)
Softwares used to study the Quran and
On Fri, 2007-04-27 at 22:34 +0200, Kenneth Wimer wrote:
On Friday 27 April 2007 21:39:48 James Richard Tyrer wrote:
Patryk Zawadzki wrote:
HiColor is not default, it is fallback.
Semantics
Failing to follow the semantics of a specification means you fail to
follow the specification.
On Fri, 2007-12-28 at 23:14 +0100, Jakob Petsovits wrote:
On Friday, 28. December 2007, Jan Claeys wrote:
Op woensdag 26-12-2007 om 01:02 uur [tijdzone +0100], schreef Jakob
Petsovits:
application-x-zerosize
The icon used for empty files.
Why do those need a different icon?
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 addendum specifications
point. If you want to, I can add the pages in the
wiki. Please let me know which other areas are needed.
Christopher
2007/12/12, Rodney Dawes [EMAIL PROTECTED]:
- Programming
- Graphic Design
- Data Management
- Device Icons
- Audio Production
On Thu, 2007-10-18 at 17:55 +0900, Takao Fujiwara - Tokyo S/W Center
wrote:
Some of the applications are used on one locale only, e.g. Chinese
dictionary application, Japan road map application.
The situlation is, those applications are used for one country only,
the native persons require to
I have to agree with Matthias here. Icons should a) be in the theme, and
b) be in US-ASCII. The prior part is specified in the Icon Theme Spec,
and the latter in the Icon Naming Spec. An application's icon should be
named the same as the binary which is run to use the application.
The behavior is
On Tue, 2007-10-09 at 21:25 +0200, Patryk Zawadzki wrote:
2007/10/9, Thiago Macieira [EMAIL PROTECTED]:
Patryk Zawadzki wrote:
2007/10/9, Takao Fujiwara - Tokyo S/W Center [EMAIL PROTECTED]:
I think users want to use their icons and it depends on each user
whether they use the simple
On Thu, 2007-10-04 at 18:52 +0200, Sanel Zukan wrote:
There are a number of locale specific problems for .desktop spec.
#1. Language specific launcher options.
I'ld like to switch the command options by languages.
E.g.
Name=Document
Exec=gnome-open
On Fri, 2007-08-10 at 15:59 +0200, Stanislav Brabec wrote:
Rodney Dawes wrote:
On Fri, 2007-08-10 at 13:10 +0200, Stanislav Brabec wrote:
Rodney Dawes wrote:
This would also solve the Accessibility issue that Stanislav brought
up in his mail, wanting a category for something
On Fri, 2007-08-10 at 13:10 +0200, Stanislav Brabec wrote:
Rodney Dawes wrote:
This would also solve the Accessibility issue that Stanislav brought
up in his mail, wanting a category for something that provides an
additional service, but isn't a standalone app 'window'.
It still does
Dock as in WM dock/system tray? or Dock as in desktop
widget/gadget/whatever?
-- dobey
On Wed, 2007-08-08 at 17:11 +0200, Philipp Thomas wrote:
I need categories for a dock type application and its settings tool and non
of the available ones seem to fit. After discussing this with a collegue,
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
to indicate that a physical object has been passed: I passed the ball; I
passed the car. But, an account
On Mon, 2007-07-16 at 12:23 +0200, 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
On Mon, 2007-07-09 at 11:57 +0200, Patryk Zawadzki wrote:
On 7/9/07, Rodney Dawes [EMAIL PROTECTED] wrote:
One very important design heuristic that should be followed here is
Always let the user feel in control.
I'd rather word that differently. For me user in control means
ignoring any
On Sat, 2007-07-07 at 09:53 +, Thomas Leonard wrote:
How can a type be safe or unsafe? Safeness depends on the application.
E.g. a python script is safe if you open it with a text editor, but not if
you use a python interpreter.
Perhaps applications that are designed to handle untrusted
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 not include
On Fri, 2007-07-06 at 07:57 -0700, James Richard Tyrer wrote:
Rodney Dawes wrote:
Everything in Tango isn't in the spec, and isn't meant to go in the
spec.
The Tango group might not agree with that, but anyway. It certainly is
starting to look like this isn't going to be simple
On Sat, 2007-06-23 at 23:10 -0700, James Richard Tyrer wrote:
The Icon Naming Spec currently lacks icon names for the last two.
Should we call these:
view-previous
view-next
of are there better ideas?
media-skip-backward
media-skip-forward
On Mon, 2007-06-18 at 11:48 -0700, James Richard Tyrer wrote:
IIUC, we are currently working on an icon naming standard:
http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
KDE will use this standard for the icon names in KDE4. I don't know
what GNOME's plans
This bug is about GTK+ theme paths, not Icon Themes. The argument of GTK
following the Icon Theme spec is irrelevant here.
-- dobey
On Sat, 2007-06-16 at 09:53 +0200, Stephan Arts wrote:
Hi,
I am sending this mail in response to this bug[0], regarding the
lookup if themes and icons inside
On Sat, 2007-04-28 at 09:33 +0200, Kenneth Wimer wrote:
On Saturday 28 April 2007 08:03:27 Rodney Dawes wrote:
On Fri, 2007-04-27 at 22:34 +0200, Kenneth Wimer wrote:
On Friday 27 April 2007 21:39:48 James Richard Tyrer wrote:
Patryk Zawadzki wrote:
HiColor is not default
On Mon, 2007-01-29 at 18:19 +0100, David Faure wrote:
On Monday 29 January 2007, Brian Mattern wrote:
Would it make sense to require $XDG_DATA_DIRS/pixmaps as an additional
fallback to handle installations outside of /usr?
We added this directory in kde's implementation
On Wed, 2007-01-17 at 15:50 -0800, Daniel Yek wrote:
What kind of response were expected? Response from desktop implementors? Or
Software Vendors?
People subscribed to this mailing list. Preferably people involved in
the development of applications or libraries that implement the specs in
On Mon, 2006-10-16 at 19:46 +0300, Kustaa Nyholm wrote:
My extensions (*.jdwg) are now correctly associated by installer with my mime
types (application/vnd.jdwg) and my jDraft.desktop shows the icon I specified
for my application and my documents also show the icon I want. The
application
On Thu, 2006-10-12 at 17:24 +0200, Magnus Bergman wrote:
On Wed, 11 Oct 2006 21:25:22 +0300
Kustaa Nyholm [EMAIL PROTECTED] wrote:
Magnus Bergman wrote:
The icon for a mimetype is expected to be in
DATADIR/icons/THEME/*/mimetypes. In other words, the icon used
depends on the
On Mon, 2006-08-28 at 14:45 +1000, Andy Fitzsimon wrote:
There's no information at http://ixons.info/ whatsoever.
Right. I looked at the web site, and it seems like there is absolutely
no content about what the goals are here. It mentions an IRC channel
on freenode (#ixons) which I also
On Fri, 2006-06-30 at 12:41 -0700, Bastian, Waldo wrote:
I don't have a real opinion on that, you may be able to just add an
$appname subdir to the existing icon-spec directory hierarchy.
You mean something like $XDG_DATA_DIRS/icons/$appname? I don't think
that's appropriate, as it would
On Thu, 2006-06-29 at 11:44 -0600, Aaron J. Seigo wrote:
On Thursday 29 June 2006 09:09, you wrote:
On Thu, 2006-06-29 at 01:47 -0600, 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
On Fri, 2006-06-30 at 07:59 -0700, Bastian, Waldo wrote:
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?
There needs to be standard so
On Fri, 2006-06-30 at 08:18 -0700, Bastian, Waldo wrote:
http://portland.freedesktop.org/wiki/
Portland is a new Free Desktop initiative coming out of the OSDL
Desktop
Architects' Meeting (hosted in Portland, Oregon in December 2005).
Portland intends to generate a common set of Linux
On Thu, 2006-06-29 at 00:00 -0600, Aaron J. Seigo wrote:
I don't see KDE needing to do a bunch of work
erm. i do. and i'm going to guess i'm a bit more familiar with the code base?
Well, my patch to implement this feature in GTK+ is a grand total of 4
lines of changes. The first of those is
On Thu, 2006-06-29 at 16:30 +0200, Stephan Kulow wrote:
Am Donnerstag, 29. Juni 2006 16:23 schrieb Rodney Dawes:
On Thu, 2006-06-29 at 06:56 +0200, Stephan Kulow wrote:
Am Donnerstag, 29. Juni 2006 00:54 schrieb James Richard Tyrer:
This probably doesn't make much difference (at least
On Thu, 2006-06-29 at 01:47 -0600, 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
On Thu, 2006-06-29 at 17:09 +0200, Stephan Kulow wrote:
Am Donnerstag, 29. Juni 2006 16:42 schrieb Rodney Dawes:
Then why do we have a specification that says where to put icons at all?
Why isn't this all just part of the loader documentation?
Because we expect all desktops to show menus
On Thu, 2006-06-29 at 17:39 +0200, Stephan Kulow wrote:
Am Donnerstag, 29. Juni 2006 17:16 schrieb Rodney Dawes:
On Thu, 2006-06-29 at 17:09 +0200, Stephan Kulow wrote:
Am Donnerstag, 29. Juni 2006 16:42 schrieb Rodney Dawes:
Then why do we have a specification that says where to put
On Wed, 2006-06-28 at 10:08 -0700, Bastian, Waldo wrote:
Sure, that's a problem, but you have that problem nowadays as well. Look
at the usability of the system as a whole and you will find that it is
horrible as long as you have different themes and button order settings
between Gtk and Qt
On Wed, 2006-06-28 at 10:59 -0700, 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
The information here doesn't explain *why* the
On Wed, 2006-06-28 at 22:18 +0200, Thiago Macieira wrote:
Thiago Macieira wrote:
Are you opposed to moving the stuff in share/apps to the share/
directory directly? Or were you just pointing out the page that
contains some information about the KDE directory layout? Just
wondering, as I am
On Thu, 2006-06-29 at 00:26 +0200, Kenneth Wimer wrote:
If they are privately themed icons (your words) why should it matter
where they put them?
They are privately installed themable icons. If they are private, and it
doesn't matter, then they aren't themed.
Perhaps they are private for a
On Thu, 2006-06-29 at 00:49 +0200, Thiago Macieira wrote:
Sorry, I completely disagree.
Why should application A care about application B's private files? They
are *private* so they can:
a) disappear from one version to the next
b) change names
c) be in a completely different format
On Fri, 2006-06-23 at 23:44 -0700, James Richard Tyrer wrote:
and to standardize this they would go in:
$XDG_DATA_DIR/apps/app_name/icons/theme/size/type
If this is not part of the standard, SMcC's posting illustrates that
GNOME does not have a standard way to deal with this and
1 - 100 of 130 matches
Mail list logo
