[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: [otaylor@redhat.com: .desktop files and encodings]
From:       Owen Taylor <otaylor () redhat ! com>
Date:       2001-02-28 23:25:15
[Download RAW message or body]


David Faure <david@mandrakesoft.com> writes:

> On Wednesday 28 February 2001 20:06, Owen Taylor wrote:
> > David Faure <david@mandrakesoft.com> writes:
> > 
> > > On Wednesday 28 February 2001 18:31, Navindra Umanee wrote:
> > > > 
> > > > Hi, Owen sent this patch for the Desktop Entry Spec to the xdg list.
> > > > I don't know enough to understand the ramifications of such a patch
> > > > for KDE.  
> > > > 
> > > > Could someone look into it?
> > > 
> > > This change to the standard looks ok to me - especially if nobody expects
> > > KDE to support the Legacy-Mixed encodings (strange name, we call that 
> > > "locale-8-bit" :)
> > 
> > It's explicitly optional in the spec, because it is pretty hideous. 
> 
> Yes, and that's also why other developers (who didn't Cc you) thought that
> this is probably too ugly to even be part of the SPEC at all. And I would
> tend to agree with that. A spec must define a clean solution - current hacks
> are another matter. And the clean solution here is UTF-8.

We can move the definition of Legacy-Mixed to an appendix,
to make it clearer that it is not a proposal for new systems
but simply describing and formalizing existing practice.

There reason I want the definition to exist is:

 - There are large numbers of desktop files in this format.

 - Without a definition of the format, it is impossible to 
   write reliable conversion tools, or for systems that 
   desire to support this encoding to support it.

> > Since gnome-1.4 probably won't have support for UTF-8 encoding (Sigh,
> > but we don't have an XP framework for encoding conversion in a place
> > we can depend on for this)
>
> It's never too late to switch to Qt :) Sorry, couldn't resist :)

I guess not...

[ 
  To make the point clear, the problem is not that we don't now
  solutions for code conversion, but rather, that in GNOME-1.4, which
  does not change our development platform, we cannot add these
  facilities as dependencies of the base gnome-libs.

  It may be possible to add code to handle Encoding: UTF-8 on some
  subset of our supported platforms for GNOME-1.4, and I'll look into
  this.
]
 
> > > The one change it means for KDE, is to add
> > > Encoding=UTF-8 
> > > to all the desktop files it creates.
> > > Shouldn't be too hard, I'll look into that.
> > > 
> > > Another missing bit in KDE would be to recognize
> > > Name[de_DE] and prefer it over Name[de].
> > 
> > That's in there - both expressed formally and with an example: [...]
> 
> I know. I said that KDE didn't support it at the moment.

Ah, sorry, I misunderstood :-). 

Yes, you'll certainly want to fix that, since the choice of wording
can differ significantly between, say, es_ES and es_MX.

> All encoding considerations aside, KDE wouldn't do anything from a
> Name[de_DE] entry, AFAIK. But I expect input from Stephan Kulow about this
> (whether it's already supported, and whether we should add support for it).
> 
> To conclude, I think that we can add Encoding=UTF-8 in KDE to help
> with encoding-determination, but this whole encoding mess might not be
> a good idea for the SPEC, especially since we all know that the future
> is UTF-8.

An alternate method of handling this would be to say that the
Version field is mandatory, and that if the version is greater than
0.x.y, for some x, y, then the file is encoded in UTF-8, otherwise
the encoding is undefined.

However, I think this is worse than adding the Encoding field:

 - It causes entanglement between the encoding problem and other
   aspects of getting the spec adopted.

 - The check is more obscure.

 - It is just as much work to fix the .desktop files, since the KDE
   files currently don't have the Version field either.

Regards,
                                        Owen

[prev in list] [next in list] [prev in thread] [next in thread]