Re: dconf

2009-04-03 Thread Stef Walter
Rob Taylor wrote:
 My question would be is why do these People have a desktop in which
 there isn't a DBus session bus? Its been there for a very long time now
 in most distros, afact. For gnome 3.0, running without a session bus is
 going to be like running gnome 2.0 without orbit2. i.e. it ain't gonna
 work right.

Here you go:

$ sudo gnome-terminal
[sudo] password for stef:
Failed to contact the GConf daemon; exiting.

Same applies to:

$ gksudo gnome-terminal

This bit me recently (Ubuntu Jaunty).

Cheers,

Stef

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: dconf

2009-04-03 Thread Rob Taylor
Stef Walter wrote:
 Rob Taylor wrote:
 My question would be is why do these People have a desktop in which
 there isn't a DBus session bus? Its been there for a very long time now
 in most distros, afact. For gnome 3.0, running without a session bus is
 going to be like running gnome 2.0 without orbit2. i.e. it ain't gonna
 work right.
 
 Here you go:
 
 $ sudo gnome-terminal
 [sudo] password for stef:
 Failed to contact the GConf daemon; exiting.
 
 Same applies to:
 
 $ gksudo gnome-terminal
 
 This bit me recently (Ubuntu Jaunty).

Strange, this works fine for me. The gconfd service is
session-activatable, so what should happen in this case is:

  - gnome-termial will launch, try to connect to the session bus.
  - as the bus isn't available libdbus will launch dbus-launch, which
will  start a new session bus daemon for the 'root' user.
  - gnome-terminal (via libgconf) will attempt to connect to
/org.gnome.GConf
  - as no service is availiable with this well known name, the bus
daemon will look for it in /usr/share/dbus-1/services (or as appropriate
for your distro)
  - finding the file org.gnome.GConf.service in that directory, the bus
daemon will launch gconfd, wait till then name /org.gnome.GConf is
registered and then deliver the message.

This should work on any distro with the correct version of gconf (2.24).
If this isn't working for you, my first port of call would be first to
see if you have dbus-launch installed, then check you have the
prerequisite .service file available. I would say this seems like a
distro problem, but it works fine for me on Intrepid here.

Hope that helps,
Rob

 Cheers,
 
 Stef
 


-- 
Rob Taylor, Codethink Ltd. - http://codethink.co.uk
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: dconf

2009-04-03 Thread Alexander Larsson
On Thu, 2009-04-02 at 16:58 -0400, Martin Meyer wrote:
 On Thu, Apr 2, 2009 at 4:47 PM, Xavier Bestel xavier.bes...@free.fr wrote:
  Le jeudi 02 avril 2009 à 19:39 +0100, Rob Taylor a écrit :
  My question would be is why do these People have a desktop in which
  there isn't a DBus session bus? Its been there for a very long time now
  in most distros, afact. For gnome 3.0, running without a session bus is
  going to be like running gnome 2.0 without orbit2. i.e. it ain't gonna
  work right.
 
  How about running application remotely through ssh -Y ? I do it daily,
  and I really hate when it feils because of dbus (but I must confess
  lately things got better, like if apps autostart dbus or something).
 
 
 (sorry to divert to a slightly different topic, but since we're all on
 the gnome-3.0 wagon today...)
 On a similar note, how will gtk's client-side windows affect
 performance of remote X windows, if at all? Does anyone have any
 thoughts or prediction on that?

I haven't done any measurements, but my guess it will have no effect at
all. We're still drawing in the xserver. Its just the window positions
and sizes that are client side.


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


libgnome(ui) must die - missing bits and pieces

2009-04-03 Thread Andre Klapper
Once again I'd like to ask developers to list the missing bits and
pieces required for getting rid of libgnome(ui) dependencies in their
applications at

  http://live.gnome.org/LibgnomeMustDie

to have a central place for getting an overview and to share advice,
knowledge, solutions, workarounds.

I've added a Missing bits section to that wikipage and added a few
examples. It might make more sense to add such stuff to the specific
sections on that wikipage though, but I needed a place to start.
Feel free to improve, add, update, change.

andre
-- 
 mailto:ak...@gmx.net | failed
 http://www.iomc.de/  | http://blogs.gnome.org/aklapper

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: dconf

2009-04-03 Thread Vincent Untz
Le jeudi 02 avril 2009, à 12:31 -0400, Ryan Lortie a écrit :
 One thing that dconf is missing that GConf gives you, however, is  
 schemas.  You could get this by using dconf as a backend from the gconf  
 daemon.  It seems like this is sort of missing the point, though.

[...]

 This is honestly a problem space that I haven't spent too much time  
 exploring, but there are certainly possibilities here.

Schemas are nice, IMHO, so it'd be nice to have people (not necessarily
you) explore this problem space ;-)

Quick question: does dconf support multiple sources? (so it's possible
to have default/mandatory values, for example)

Vincent

-- 
Les gens heureux ne sont pas pressés.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: Planning for GNOME 3.0

2009-04-03 Thread Vincent Untz
Hi,

Le jeudi 02 avril 2009, à 11:44 -0400, Willie Walker a écrit :
 For developers local to the Boston area, I'm happy to take a visit to  
 your sight to go over accessibility considerations and to discuss your  
 new UI's with you from an accessibility standpoint.  I promise to focus  
 solely on accessibility considerations and will avoid general armchair  
 HCI quarterbacking.   For those outside the Boston area, we can try to  
 find someone to visit you for a face-to-face and/or we could do  
 conference calls with screenshots or just shared desktops via VNC.

Wow, this is an awesome proposal! Note that we can also arrange a
special session during GUADEC or the Boston Summit for this if there's
interest!

Cheers,

Vincent

-- 
Les gens heureux ne sont pas pressés.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.

2009-04-03 Thread Vincent Untz
Le jeudi 02 avril 2009, à 11:26 -0400, Willie Walker a écrit :
 2) We are working with another organization right now to investigate  
 magnification solutions.  This may involve picking up on  
 http://projects.gnome.org/outreach/a11y/tasks/magnification/, and I  
 suspect the ultimate solution will be a combination of improvements to  
 Compiz's eZoom plugin plus a D-Bus API.  If so, this may end up as a  
 Compiz project.

I guess we'd probably want to have GNOME Shell people involved there,
since this would be something that would need to be implemented there
too...

-- 
Les gens heureux ne sont pas pressés.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: dconf

2009-04-03 Thread Alberto Ruiz
2009/4/3 Vincent Untz vu...@gnome.org:
 Le jeudi 02 avril 2009, à 12:31 -0400, Ryan Lortie a écrit :
 One thing that dconf is missing that GConf gives you, however, is
 schemas.  You could get this by using dconf as a backend from the gconf
 daemon.  It seems like this is sort of missing the point, though.

 [...]

 This is honestly a problem space that I haven't spent too much time
 exploring, but there are certainly possibilities here.

 Schemas are nice, IMHO, so it'd be nice to have people (not necessarily
 you) explore this problem space ;-)

 Quick question: does dconf support multiple sources? (so it's possible
 to have default/mandatory values, for example)

Another question that I'm curious about is, how hard would it be to
implement configuration snapshots?

I think it would be quite useful to be able to make snapshots of the
configuration for failsafe sessions or plain backup/rollbacks.

Is this something that would require big changes on the current
dconf's architecture/roadmap?

 Vincent

 --
 Les gens heureux ne sont pas pressés.
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list




-- 
Un saludo,
Alberto Ruiz
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


tag based gui

2009-04-03 Thread Wouter van Wijk
Hello,

I saw your discussion about the GUI for next-gen file-management. A while
ago, I worked out a couple of ideas. It's a tag based interface for
filemanagement. It uses a mixture of tag-clouds and old-style management.
Please take a look at:

http://www.jannemijn.nl/gui.pdf

Feel free to use the ideas. I am not a developer (anymore), but I'd like to
hear your suggestions.

Regards,
Wouter van Wijk
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: dconf

2009-04-03 Thread Havoc Pennington
Hi,

On Fri, Apr 3, 2009 at 8:27 AM, Vincent Untz vu...@gnome.org wrote:
 Le jeudi 02 avril 2009, à 12:31 -0400, Ryan Lortie a écrit :
 This is honestly a problem space that I haven't spent too much time
 exploring, but there are certainly possibilities here.

 Schemas are nice, IMHO, so it'd be nice to have people (not necessarily
 you) explore this problem space ;-)

s/nice/essential/

Otherwise as soon as two pieces of code both use a setting, you're f*d
because you have to hardcode the default value in both places. So it
breaks the idea of process-transparency (or even of using a setting
from two places in the same process) if you don't have some single
place for the default value to live.

pre-gconf we had loads and loads of bugs related to this, which is why
gconf addressed it.

(the old gnome_config_* solution was whenever you got a setting, you
had to provide the default, so the default was effectively
cut-and-pasted in N places)

Havoc
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: dconf

2009-04-03 Thread Jamie McCracken
Also I would imagine a dconf-editor app would not be practical without
schemas especially for settings of type bool/enum where you want a
checkbox/dropdown

jamie


On Fri, 2009-04-03 at 09:20 -0400, Havoc Pennington wrote:
 Hi,
 
 On Fri, Apr 3, 2009 at 8:27 AM, Vincent Untz vu...@gnome.org wrote:
  Le jeudi 02 avril 2009, à 12:31 -0400, Ryan Lortie a écrit :
  This is honestly a problem space that I haven't spent too much time
  exploring, but there are certainly possibilities here.
 
  Schemas are nice, IMHO, so it'd be nice to have people (not necessarily
  you) explore this problem space ;-)
 
 s/nice/essential/
 
 Otherwise as soon as two pieces of code both use a setting, you're f*d
 because you have to hardcode the default value in both places. So it
 breaks the idea of process-transparency (or even of using a setting
 from two places in the same process) if you don't have some single
 place for the default value to live.
 
 pre-gconf we had loads and loads of bugs related to this, which is why
 gconf addressed it.
 
 (the old gnome_config_* solution was whenever you got a setting, you
 had to provide the default, so the default was effectively
 cut-and-pasted in N places)
 
 Havoc
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: dconf

2009-04-03 Thread Havoc Pennington
Hi,

On Thu, Apr 2, 2009 at 2:39 PM, Rob Taylor rob.tay...@codethink.co.uk wrote:
 Actually, no, the su problem is completely orthogonal, this is something
 that needs addressing in DBus itself and is fixable.


fwiw after thinking about it and colin's comments, I think the bug is
somewhat mis-filed living in dbus bugtracker; it's really not a dbus
question, it's more of a policy question or UI question for the whole
desktop.

I suggested a couple alternatives toward the end of:
http://bugs.freedesktop.org/show_bug.cgi?id=17970#c23

anyhow, I would recommend someone write down various use cases,
document something like possible direction 1 or possible direction
2 in my comment, or some other approach, explaining how
gnome-settings-daemon, screensaver inhibition, single-instance apps,
gconf/dconf, ssh, and various stuff like that should work, and then
we could commence fixing dbus, fixing apps, fixing ssh, etc. according
to the same documented scheme.

sort of like: 
http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt

This went round-and-round with various app-specific bugs until someone
documented an overall strategy, then fixing individual apps could be
converging on a single approach.

Anyway, need a doc that really explains how *everything* gets fixed,
not just specific cases, since fixing specific cases tends to break
other cases. (Which may be inevitable, so the cases that can't work
need to be documented also.)

Havoc
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.

2009-04-03 Thread Havoc Pennington
Hi,

On Thu, Apr 2, 2009 at 9:51 AM, Cosimo Cecchi cosi...@gnome.org wrote:
 I add another question here, as a complete dconf/GConf newbie:
 is depending on Bonobo/Corba vs DBus the only thing that makes GConf not
 useful towards GNOME 3.0 or are there some other
 design/preformance/whatever issues requiring a full rewrite to be
 solved?

http://projects.gnome.org/gconf/plans.html
http://projects.gnome.org/gconf/plans-spec.html

(would recommend checklisting dconf against this list, I think Ryan
and I did a couple years ago, but there's been a lot of change since)

 We learned, with the GIO transition, that porting lots of applications
 isn't fun, and is something which takes much time to be completed
 project-wide. As GConf is probably even more widely used than gnome-vfs
 was, porting could be an even bigger effort.

The only sane thing imo would be to have a gconf compatibility wrapper
around dconf.

Havoc
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: dconf

2009-04-03 Thread Michael R. Head
On Fri, 2009-04-03 at 09:40 +0100, Rob Taylor wrote:
 Stef Walter wrote:
  Here you go:
  
  $ sudo gnome-terminal
  [sudo] password for stef:
  Failed to contact the GConf daemon; exiting.
  
  Same applies to:
  
  $ gksudo gnome-terminal
  
  This bit me recently (Ubuntu Jaunty).

...

 This should work on any distro with the correct version of gconf (2.24).
 If this isn't working for you, my first port of call would be first to
 see if you have dbus-launch installed, then check you have the
 prerequisite .service file available. I would say this seems like a
 distro problem, but it works fine for me on Intrepid here.

In Jaunty:

bur...@phoenix:~$ cat /usr/share/dbus-1/services/org.gnome.GConf.service
[D-BUS Service]
Name=org.gnome.GConf
Exec=/usr/lib/libgconf2-4/gconfd-2
bur...@phoenix:~$ which dbus-launch 
/usr/bin/dbus-launch
bur...@phoenix:~$ sudo gnome-terminal
Failed to contact the GConf daemon; exiting.
bur...@phoenix:~$ gksudo gnome-terminal
Failed to contact the GConf daemon; exiting.

Filed:
https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/354543

 Hope that helps,
 Rob
 
  Cheers,
  
  Stef
  
 
 
-- 
Michael R. Head bur...@suppressingfire.org
http://www.cs.binghamton.edu/~mike/


smime.p7s
Description: S/MIME cryptographic signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: dconf

2009-04-03 Thread Ryan Lortie

Hi

Havoc Pennington wrote:

On Fri, Apr 3, 2009 at 8:27 AM, Vincent Untz vu...@gnome.org wrote:

Schemas are nice, IMHO, so it'd be nice to have people (not necessarily
you) explore this problem space ;-)


s/nice/essential/


It is true that dconf has no schemas, and I don't want for it to have 
schemas.  GSettings contains schemas.  These schemas are considered to 
be part of the application (in the same sense that you would consider a 
GtkBuilder file, for example) and therefore do not appear in any way in 
the underlying settings database (that's dconf).


Don't worry -- I'm not totally insane :)

Cheers
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: dconf

2009-04-03 Thread Behdad Esfahbod

On 04/03/2009 10:59 AM, Ryan Lortie wrote:

Hi

Havoc Pennington wrote:

On Fri, Apr 3, 2009 at 8:27 AM, Vincent Untz vu...@gnome.org wrote:

Schemas are nice, IMHO, so it'd be nice to have people (not necessarily
you) explore this problem space ;-)


s/nice/essential/


It is true that dconf has no schemas, and I don't want for it to have
schemas. GSettings contains schemas. These schemas are considered to be
part of the application (in the same sense that you would consider a
GtkBuilder file, for example) and therefore do not appear in any way in
the underlying settings database (that's dconf).


But that still doesn't solve the problem of using the same key from two 
totally different applications, which is not quite uncommon these days.

Say, font size, colors, default applications, etc.  How does that work?

behdad



Don't worry -- I'm not totally insane :)

Cheers

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: dconf

2009-04-03 Thread Behdad Esfahbod

On 04/03/2009 10:59 AM, Ryan Lortie wrote:

Hi

Havoc Pennington wrote:

On Fri, Apr 3, 2009 at 8:27 AM, Vincent Untz vu...@gnome.org wrote:

Schemas are nice, IMHO, so it'd be nice to have people (not necessarily
you) explore this problem space ;-)


s/nice/essential/


It is true that dconf has no schemas, and I don't want for it to have
schemas. GSettings contains schemas. These schemas are considered to be
part of the application (in the same sense that you would consider a
GtkBuilder file, for example) and therefore do not appear in any way in
the underlying settings database (that's dconf).


But that still doesn't solve the problem of using the same key from two 
totally different applications, which is not quite uncommon these days.

Say, font size, colors, default applications, etc.  How does that work?

behdad



Don't worry -- I'm not totally insane :)

Cheers

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: dconf

2009-04-03 Thread Ryan Lortie

Behdad Esfahbod wrote:
But that still doesn't solve the problem of using the same key from two 
totally different applications, which is not quite uncommon these days.

Say, font size, colors, default applications, etc.  How does that work?


Some library or service or core component would be responsible for 
installing the schema for these things.  The schemas are name-spaced 
like 'org.gnome.whatever', and installed in a central location, so 
applications can easily use schemas provided by other libraries.


I guess this violates the strict idea of 'part of the application' per 
se.  What I meant by that is to say 'definitely not part of the database'.


Cheers
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: dconf

2009-04-03 Thread Josselin Mouette
Le vendredi 03 avril 2009 à 12:15 -0400, Ryan Lortie a écrit :
 Behdad Esfahbod wrote:
  But that still doesn't solve the problem of using the same key from two 
  totally different applications, which is not quite uncommon these days.
  Say, font size, colors, default applications, etc.  How does that work?
 
 Some library or service or core component would be responsible for 
 installing the schema for these things.  The schemas are name-spaced 
 like 'org.gnome.whatever', and installed in a central location, so 
 applications can easily use schemas provided by other libraries.

Is it possible to have several layers of settings? Being able to
override a GConf schema or provide a mandatory value at different levels
is a popular feature among derived distributions and users with large
parks.

-- 
 .''`.  Debian 5.0 Lenny has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message numériquement signée
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.

2009-04-03 Thread Josselin Mouette
Le vendredi 03 avril 2009 à 09:48 -0400, Havoc Pennington a écrit :
  We learned, with the GIO transition, that porting lots of applications
  isn't fun, and is something which takes much time to be completed
  project-wide. As GConf is probably even more widely used than gnome-vfs
  was, porting could be an even bigger effort.
 
 The only sane thing imo would be to have a gconf compatibility wrapper
 around dconf.

AOL. The timeframe looks way too short to allow for completing dconf and
porting all applications before the 3.0 release.

-- 
 .''`.  Debian 5.0 Lenny has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message numériquement signée
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: dconf

2009-04-03 Thread Josselin Mouette
Le vendredi 03 avril 2009 à 09:40 +0100, Rob Taylor a écrit :
   - gnome-termial will launch, try to connect to the session bus.
   - as the bus isn't available libdbus will launch dbus-launch, which
 will  start a new session bus daemon for the 'root' user.

This is the part that doesn’t happen.

Add to that the fact that the dbus daemon started this way (or with
dbus-launch gnome-terminal) does not exit when the process ends.

Gustavo is working on fixing gksu so that it works with D-Bus but some
bugs remain.

-- 
 .''`.  Debian 5.0 Lenny has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message numériquement signée
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: dconf

2009-04-03 Thread Havoc Pennington
Hi,

2009/4/3 Josselin Mouette j...@debian.org:
 Gustavo is working on fixing gksu so that it works with D-Bus but some
 bugs remain.


Just a .02, I don't see how any bugs can be fixed here in anything
until there's some documentation on what's supposed to work, what
isn't, and how...

Havoc
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: dconf

2009-04-03 Thread Ryan Lortie

Josselin Mouette wrote:

Is it possible to have several layers of settings? Being able to
override a GConf schema or provide a mandatory value at different levels
is a popular feature among derived distributions and users with large
parks.



Yes.  Of course.

The concept of mandatory keys is actually being cribbed from the way 
that KDE does it more or less.  ie: you have an ordering of databases. 
The user one being on one extreme end and the distro default or 
whatever being on the other.  In between maybe you have site default 
host default, however, as you please.


distro   site  host user
default default   default settings

The setting is taken from the rightmost database that has the key set. 
However, if there is a 'mandatory' key set somewhere, then the leftmost 
takes precedence.  This allows the 'site' admin to set mandatory keys 
that even the 'host' defaults cannot override, for example.


Lockdown is essentially a list of patterns (stored in the same tree 
structure as the keys).  Each pattern has one of the following forms:


  /one/specific/key/to/lock
  /path/to/lock/

with the following rule: if a lockdown list item exactly matches a key 
name then that key is locked down.  If a lockdown list item ends in '/' 
and is a prefix of a key then that key is locked down.


Cheers
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: dconf

2009-04-03 Thread Josselin Mouette
Le vendredi 03 avril 2009 à 15:25 -0400, Ryan Lortie a écrit :
 The concept of mandatory keys is actually being cribbed from the way 
 that KDE does it more or less.  ie: you have an ordering of databases. 
 The user one being on one extreme end and the distro default or 
 whatever being on the other.  In between maybe you have site default 
 host default, however, as you please.
 
  distro   site  host user
  default default   default settings
 
 The setting is taken from the rightmost database that has the key set. 
 However, if there is a 'mandatory' key set somewhere, then the leftmost 
 takes precedence.  This allows the 'site' admin to set mandatory keys 
 that even the 'host' defaults cannot override, for example.

Great. This should allow to do things very similar to what we currently
do with GConf.

-- 
 .''`.  Debian 5.0 Lenny has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message numériquement signée
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: dconf

2009-04-03 Thread Stefan Kost
Ryan Lortie schrieb:
 Hi
 
 Havoc Pennington wrote:
 On Fri, Apr 3, 2009 at 8:27 AM, Vincent Untz vu...@gnome.org wrote:
 Schemas are nice, IMHO, so it'd be nice to have people (not necessarily
 you) explore this problem space ;-)

 s/nice/essential/
 
 It is true that dconf has no schemas, and I don't want for it to have
 schemas.  GSettings contains schemas.  These schemas are considered to
 be part of the application (in the same sense that you would consider a
 GtkBuilder file, for example) and therefore do not appear in any way in
 the underlying settings database (that's dconf).
 
 Don't worry -- I'm not totally insane :)
 
 Cheers

There is a project GConfCleaner somewhere out there that scans gconf and offers
to purge all keys not associated with a schema - quite dangerous as there are
many apps unfortunately that do not install a schema. Because of that I would
even like to see schema being enforced. Thats one way to keep the database size
under control. Database size might matter less on the desktop, but I am thinking
about mobile devices here and there is does for sure.

Or do you have some different idea to detect unused keys (maybe atime, mtime and
ctieme attributes)?

Stefan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: dconf

2009-04-03 Thread Stefan Kost
Jamie McCracken schrieb:
 Also I would imagine a dconf-editor app would not be practical without
 schemas especially for settings of type bool/enum where you want a
 checkbox/dropdown

If there is schema support and a gconf emulation API, we don't even need to
write a new GConfEditor \o/

Stefan

 
 jamie
 
 
 On Fri, 2009-04-03 at 09:20 -0400, Havoc Pennington wrote:
 Hi,

 On Fri, Apr 3, 2009 at 8:27 AM, Vincent Untz vu...@gnome.org wrote:
 Le jeudi 02 avril 2009, à 12:31 -0400, Ryan Lortie a écrit :
 This is honestly a problem space that I haven't spent too much time
 exploring, but there are certainly possibilities here.
 Schemas are nice, IMHO, so it'd be nice to have people (not necessarily
 you) explore this problem space ;-)
 s/nice/essential/

 Otherwise as soon as two pieces of code both use a setting, you're f*d
 because you have to hardcode the default value in both places. So it
 breaks the idea of process-transparency (or even of using a setting
 from two places in the same process) if you don't have some single
 place for the default value to live.

 pre-gconf we had loads and loads of bugs related to this, which is why
 gconf addressed it.

 (the old gnome_config_* solution was whenever you got a setting, you
 had to provide the default, so the default was effectively
 cut-and-pasted in N places)

 Havoc
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list
 
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Patch to Alacarte

2009-04-03 Thread CaStarCo
Hello, I'm new in this list

I patched Alacarte to not to use libglade and instead use gtkbuilder, I have
not done the diffs because I not know very well how I must do it.

The files are atached.

Alacarte/MainWindow.py - I erased all the references to libglade.
data/alacarte.glade - erased
data/alacarte.ui - is alacarte.glade transformed with gtk-builder-convert

I've tested it a little bit and works fine, but I haven't tested it a lot
and I don't know if i introduced a bug.

Please, don't attack me if I don't follow the protocol, (because I don't
know the protocol), thanks for your attention :) .

-- 
- Per la llibertat del coneixement -
- Per la llibertat de la ment...   -


alacarte_patched.tar.gz
Description: GNU Zip compressed data
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Patch to Alacarte

2009-04-03 Thread Christian Rose
On 4/4/09, CaStarCo casta...@gmail.com wrote:
 Hello, I'm new in this list

 I patched Alacarte to not to use libglade and instead use gtkbuilder, I have
 not done the diffs because I not know very well how I must do it.

 The files are atached.

Please put patches in Bugzilla:
http://bugzilla.gnome.org/enter_bug.cgi?product=alacarte


Christian
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list