Kevin Kofler wrote:
> Adam Williamson wrote:
> > Would it make sense just to put the hicolor directory into filesystem?
> > It seems silly to have every single graphical app in the distro depend
> > on a package simply for the provision of the directory...
>
> There are also all the subdirectories
Adam Williamson wrote:
> Would it make sense just to put the hicolor directory into filesystem?
> It seems silly to have every single graphical app in the distro depend
> on a package simply for the provision of the directory...
I agree.
-- rex
--
devel mailing list
devel@lists.fedoraproject.
Adam Williamson wrote:
> Would it make sense just to put the hicolor directory into filesystem?
> It seems silly to have every single graphical app in the distro depend
> on a package simply for the provision of the directory...
There are also all the subdirectories such as
/usr/share/icons/hicol
On Wed, 2012-01-11 at 16:03 -0800, Toshio Kuratomi wrote:
> If you'd like to propose a new guideline/change to the existing one, that
> would be great. It sounds like the consensus here for #1 is to deprecate
> absolute paths. And to explain why the Requires are needed for #2.
The wiki does in
On Wed, Jan 11, 2012 at 5:03 PM, Kevin Kofler wrote:
> Richard Shaw wrote:
>> 1. If installing icons into in to /usr/share/pixmaps is indeed
>> deprecated.
>
> It's not installing into /usr/share/pixmaps which is deprecated, but the
> whole concept of unthemed, fixed-size icons.
>
>> Then we need
On Wed, Jan 11, 2012 at 09:22:34AM -0600, Richard Shaw wrote:
> Hmm.. Where to start. A recent discussion[1] and package review got me
> thinking. I'll divide this into two problems/proposals.
>
> 1. If installing icons into in to /usr/share/pixmaps is indeed
> deprecated. Then we need to update t
Richard Shaw wrote:
> 1. If installing icons into in to /usr/share/pixmaps is indeed
> deprecated.
It's not installing into /usr/share/pixmaps which is deprecated, but the
whole concept of unthemed, fixed-size icons.
> Then we need to update the packaging guidelines for the Desktop Files
> secti
Richard Shaw wrote:
> Nowhere did I suggest that the "Short name without extension" example
> should be removed, only that the full pathname example should be
> updated to use /usr/share/icon/hicolor over /usr/share/pixmaps.
The point is that it makes no sense whatsoever to reference /usr/share/ic
On Wed, Jan 11, 2012 at 11:07 AM, Petr Pisar wrote:
> On 2012-01-11, Richard Shaw wrote:
>> On Wed, Jan 11, 2012 at 10:05 AM, Petr Pisar wrote:
>>> On 2012-01-11, Richard Shaw wrote:
1. If installing icons into in to /usr/share/pixmaps is indeed
deprecated. Then we need to update the
On 2012-01-11, Richard Shaw wrote:
> On Wed, Jan 11, 2012 at 10:05 AM, Petr Pisar wrote:
>> On 2012-01-11, Richard Shaw wrote:
>>> 1. If installing icons into in to /usr/share/pixmaps is indeed
>>> deprecated. Then we need to update the packaging guidelines for the
>>> Desktop Files section[2].
On Wed, Jan 11, 2012 at 10:05 AM, Petr Pisar wrote:
> On 2012-01-11, Richard Shaw wrote:
>> 1. If installing icons into in to /usr/share/pixmaps is indeed
>> deprecated. Then we need to update the packaging guidelines for the
>> Desktop Files section[2]. In the "Icon tag in Desktop Files" section
On 2012-01-11, Richard Shaw wrote:
> 1. If installing icons into in to /usr/share/pixmaps is indeed
> deprecated. Then we need to update the packaging guidelines for the
> Desktop Files section[2]. In the "Icon tag in Desktop Files" section
> it explicitly shows a full path to an icon file in /usr
Hmm.. Where to start. A recent discussion[1] and package review got me
thinking. I'll divide this into two problems/proposals.
1. If installing icons into in to /usr/share/pixmaps is indeed
deprecated. Then we need to update the packaging guidelines for the
Desktop Files section[2]. In the "Icon t
13 matches
Mail list logo
