Re: desktop schemas review [was: Re: GSettings migration status]

[Russell Shaw]

Alexander Larsson wrote:

On Sat, 2010-07-03 at 13:25 -0400, Ryan Lortie wrote:

On Sat, 2010-07-03 at 13:37 +0200, Christian Persch wrote:

This is a common error. Filenames need to be stored as ay and *NOT*
s (since s is UTF-8). (I think this needs some enhancement in
glib-compile-schemas to be able to still put a string in default.)

I'm not sure I buy into your hardline stance on this one.

I think it's not unreasonable to require that all filenames specified in
the settings be in a valid encoding (whatever that encoding is) on their
own filesystem (where in a valid encoding means converts correctly to
and from unicode).  In that case, utf8 is appropriate here.


This is not right at all. Anything that does that is broken for two
reasons:

1) Technically for unix all filenames are valid if they are byte
strings without the characters zero and '/'. If you enforce anything
else on your filenames there *will* be actual files on the system that
you can't store references too. I've fixed soo many bugs from people
thinking filenames are utf8 strings, they are just not, they are byte
arrays. This sucks, but its reality and we have to handle it.

2) Storing a converted pathname (for instance from filename encoding
to utf8) is a bad idea, even if it succeeds. First of all, the encoding
is runtime dependent (env vars) so may change over time, secondly
roundtripping to unicode and back does not necessarily get you the same
exact bytes back, so you might not be able to actually open the file.

I've spent lots of work getting this right in e.g. gvfs, where raw
filenames are G_FILE_ATTRIBUTE_TYPE_BYTE_STRING, but e.g.
standard::display-name is G_FILE_ATTRIBUTE_TYPE_STRING. Please don't
break this. Filenames are not unicode strings, they are byte array
identifiers.


Given that users may store file names in arbitrary encodings,
what is the best way to determine the encoding for display in
a file viewer?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New Control Centre

[Russell Shaw]

Federico Mena Quintero wrote:
 El lun, 05-02-2007 a las 19:19 +, Alex Jones escribió:
 It's slow.
 
 Yes.  No one has done any profiling work on it yet.  Want to start?
 
 It's no slower than the old panel menus, which get purged from memory
 after a few minutes --- when popping them up, my laptop churned for
 about 7 seconds before the menus would appear.
 
 I want my menus back. Changing settings just isn't the quick
 in-and-out-in-5-seconds-flat job it used to be.
 
 Why are you going into the capplets all the time?  Do we have such a
 shitty system that it needs to be reconfigured regularly and often?
 
 Don't worry about the control center per se; worry about making the
 whole system better so that one does not have to babysit it all the
 time.

If profiling has to be done to make a menu faster, it is pretty obvious
the system it is built on is stupidly inefficient and broken, especially
if said menu is slow on a 10 year old pc.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Colormaps

[Russell Shaw]

Hi,
Is there any set standard for the colors in a default colormap installed
by the window manager? Where can i find the spec?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list