Re: [dconf][vino server] Vino server configuration control problem

[Bastien Nocera]

Hey,

First, please avoid HTML e-mails to mailing-lists, especially with the
way your email was formatted...

On Thu, 2015-11-26 at 15:16 +0300, John Depp wrote:
> Hello Gnome Developers!
> You're my last hope since I can't get the asnwer for my question
> anywhere.
> Here's my task:
>   I have to enable Desktop Sharing for my users, and set it to lo
> interface, for Helpdesk and administrative purposes to connect via
> SSH only.
>   I used do run
>     gsettings set org.gnome.Vino enabled=true
>     gsettings set org.gnome.Vino network-interfaces=lo
>   and that seemed to work.
> Now, some settings were moved to (dconf path) 
>   /org/gnome/settings-daemon/plugins/sharing/vino-server, where
> enabled-connections parameter accepts NetworkManager connection UUID.
> Unfortunately, lo interface is not managed by NetworkManager, nor I
> intend it to do so.
> Is there any way to enable the vino server "old way"?
> Imagine pretty large network with hundreds of workstations connected.
> In the past it was a quastion of running one script to get acces for
> all users desktops...
> If I'm writing to wrong mailing list, correct me, please.
> Thanks in advance!

If you don't want to use the sharing plugin and its features, and want
to start vino at the start of the session, you'd add the vino-
server.desktop file to the xdg-autostart directory, either
in /etc/xdg/autostart/ for all users, or ~/.config/autostart for
particular users.

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

Re: [dconf][vino server] Vino server configuration control problem

[Bart Mariën]

Hi,

We had a very similar issue when swithing from Debian 7 to 8. With gnome 
3.14 we also missed a couple of gsettings options to enable the vino 
server using the sharing tools.


What we ended up using is following:

Add vino a  startup application:
link: "/usr/share/applications/vino-server.desktop" to your user 
".config/autostart"


We then set
org.gnome.Vino authentication-methods
org.gnome.Vino notify-on-connect
org.gnome.Vino prompt-enabled
org.gnome.Vino vnc-password
org.gnome.Vino require-encryption

We don't specify what interface te listen on. We use firewall and VPN 
for that.
I've checked and don't see the network-interfaces option. There is a 
network-interface option(without the s). If i set this option to tun0 
and disable the firewall, i can confirm vino only accepts connection on 
the tun0 interface. Setting the setting to blank make vino accept 
connections on all interfaces.



Bart



On 26-11-15 13:16, John Depp wrote:

Hello Gnome Developers!
You're my last hope since I can't get the asnwer for my question 
anywhere.

Here's my task:
  I have to enable Desktop Sharing for my users, and set it to lo 
interface, for Helpdesk and administrative purposes to connect via SSH 
only.

  I used do run
gsettings set org.gnome.Vino enabled=true
gsettings set org.gnome.Vino network-interfaces=lo
  and that seemed to work.
Now, some settings were moved to (dconf path)
/org/gnome/settings-daemon/plugins/sharing/vino-server, where 
enabled-connections parameter accepts NetworkManager connection UUID.
Unfortunately, lo interface is not managed by NetworkManager, nor I 
intend it to do so.

Is there any way to enable the vino server "old way"?
Imagine pretty large network with hundreds of workstations connected.
In the past it was a quastion of running one script to get acces for 
all users desktops...

If I'm writing to wrong mailing list, correct me, please.
Thanks in advance!


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


--
--

2014_logoBN.jpg*Bednet vzw - synchroon internetonderwijs*

**

*Bart Mariën - ICT Medewerker *

Jean Jaureslaan 108 / 001 ,9050 Gentbrugge

GSM: 0476/ 053 358

www.bednet.be - bart.mar...@bednet.be 



//

/Dankzij de vrijgevigheid van velen is Bednet gratis omdat onderwijs een 
recht is van ieder kind, ook als het ziek is. Wil u mee dit recht 
beschermen, surf dan naar //www.bednet.be/ /en 
ontdek hoe u ons kan helpen./


/
/


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

Re: dconf path name standard

[Luca Ferretti]

Il giorno mar, 08/02/2011 alle 12.30 +0100, Alexander Larsson ha
scritto:
 I see a bunch of stuff is now in /org/gnome/appname
 and /org/gnome/desktop/*, whereas it used to be in /apps and /desktop.
 
 Have we decided to change this now, and if so, should I change nautilus
 to /org/gnome/nautilus (possibly losing some settings from early
 adopters that got stuff in /apps).
 

Yes, the official and release team approved path name is /org/gnome/*

Communicating this change and opening relevant bugs was entrusted to me,
but until now I've spent my hacking time on different stuff.

My own current plan is open a page for a GNOME Goal on wiki this week,
stay tuned.

Cheers, Luca

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

Re: dconf path name standard

[Javier Hernandez Antúnez]

2011/2/8 Luca Ferretti lferr...@gnome.org

 Il giorno mar, 08/02/2011 alle 12.30 +0100, Alexander Larsson ha
 scritto:
  I see a bunch of stuff is now in /org/gnome/appname
  and /org/gnome/desktop/*, whereas it used to be in /apps and /desktop.
 
  Have we decided to change this now, and if so, should I change nautilus
  to /org/gnome/nautilus (possibly losing some settings from early
  adopters that got stuff in /apps).
 

 Yes, the official and release team approved path name is /org/gnome/*



Since you're talking about dconf paths, I take the opportunity for doing the
next question.
I know that the official path is /org/gnome/* but, app's name must be
capitalized? eg: /org/gnome/Application1

Thanks!




 Communicating this change and opening relevant bugs was entrusted to me,
 but until now I've spent my hacking time on different stuff.

 My own current plan is open a page for a GNOME Goal on wiki this week,
 stay tuned.

 Cheers, Luca

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




-- 
Javier Hernández Antúnez
Área de Operaciones

Emergya Consultoría
Tlfno: +34 954 51 75 77
Fax: +34 954 51 64 73
http://www.emergya.es
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: dconf/GSettings namespace

[Łukasz Jernaś]

On Fri, Jul 2, 2010 at 6:30 PM, Milan Bouchet-Valat nalimi...@club.fr wrote:
 Le vendredi 02 juillet 2010 à 11:02 -0400, Ryan Lortie a écrit :
 11:00  shaunm btw, gnome as a project should probably decide on a policy
                 w.r.t. /apps/yelp/ vs. /org/gnome/yelp/ for paths, for
                 consistency
 See
 http://mail.gnome.org/archives/desktop-devel-list/2010-June/msg00104.html

If my voice would count I'd go for
org.gnome.name_of_git_module{.subapp/module} This way we can
easily avoid name clashes...

-- 
Łukasz [DeeJay1] Jernaś
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: dconf 0.3.1 released

[Łukasz Jernaś]

On Tue, May 25, 2010 at 5:42 AM, Ryan Lortie de...@desrt.ca wrote:
 dconf 0.3.1 has been released.

Hi!

I wanted to update http://live.gnome.org/dconf (pointed to by some
Ubuntu docs) but I'm not seeing any tag for the 0.3.1 version in git -
a missed push?

Regards,
-- 
Łukasz [DeeJay1] Jernaś
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: dconf

[Rodrigo Moya]

On Tue, 2009-04-07 at 10:23 -0400, Ryan Lortie wrote:
 Callum McKenzie wrote:
  Can current gconf settings be easily loaded into dconf? e.g. can someone
  launching into a gnome 3.0, dconf-based, system for the first time still
  have the same wallpaper settings as they did before?
  
  I'm assuming that a) the settings still make sense and b) that the
  application can provide a mapping between old and new settings.
 
 Yes, but currently this would have to be completely manual and would 
 require the application to link to both dconf and GConf.  This sucks.
 
 I guess a good solution would be to provide some easy-to-use framework 
 by which applications could have migration scripts in python or 
 something.  That way the application itself doesn't need to do GConf, 
 but the python script can if GConf is still installed.
 
 Ideas are definitely welcome in this direction.
 
there could be a process started by gnome-shell that just migrates the
whole GConf database to dconf? or is this automatic migration not
possible?
-- 
Rodrigo Moya rodr...@gnome-db.org

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

Re: dconf

[Behdad Esfahbod]

On 04/16/2009 06:17 PM, Rodrigo Moya wrote:

On Tue, 2009-04-07 at 10:23 -0400, Ryan Lortie wrote:

Callum McKenzie wrote:

Can current gconf settings be easily loaded into dconf? e.g. can someone
launching into a gnome 3.0, dconf-based, system for the first time still
have the same wallpaper settings as they did before?

I'm assuming that a) the settings still make sense and b) that the
application can provide a mapping between old and new settings.

Yes, but currently this would have to be completely manual and would
require the application to link to both dconf and GConf.  This sucks.

I guess a good solution would be to provide some easy-to-use framework
by which applications could have migration scripts in python or
something.  That way the application itself doesn't need to do GConf,
but the python script can if GConf is still installed.

Ideas are definitely welcome in this direction.


there could be a process started by gnome-shell that just migrates the
whole GConf database to dconf? or is this automatic migration not
possible?


Definitely possible.  But I'm yet to see a reason why a fully API-compatible 
gconf client can't be written on top of dconf.  And when that happens, we can 
mount the current gconf tree under dconf's /org/gnome transparently and not 
have to worry as much.


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

Re: dconf

[A. Walton]

2009/4/10 Josselin Mouette j...@debian.org:
 Le vendredi 10 avril 2009 à 15:15 +0200, Vincent Untz a écrit :
 Just a stupid question... Why should we switch to GSettings? Ie, what
 does it bring us that we can't do with gconf?

 So far, I heard a performance argument. Anything else?

 Getting rid of the ORBit dependency?

 (if GSettings goes in glib, then things will obviously be different
 since it will consolidate our stack)

 That would mean making glib depend on D-Bus, unfortunately.

It was already announced that we are heading this direction:
http://www.mail-archive.com/gtk-devel-l...@gnome.org/msg09502.html

-A. Walton


 --
  .''`.      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.

 ___
 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

[Havoc Pennington]

Hi,

On Fri, Apr 10, 2009 at 9:15 AM, Vincent Untz vu...@gnome.org wrote:
 So far, I heard a performance argument. Anything else?


* The API for gconf is pretty awful, and could be a lot better for app
developers.

* Installing schemas into the config db is a big mess for
distributions and sysadmins.

* gconf is one of the last things using ORBit

* gconf is not really maintained, and the codebase is a mess

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

Re: dconf

[Vincent Untz]

Le jeudi 02 avril 2009, à 11:37 -0400, Ryan Lortie a écrit :
 Ideally, I'd like to see GNOME using GSettings for 3.0.  Rob Taylor (my  
 boss) has indicated that I will definitely be able to spend time  
 addressing issues that may arise with dconf and GSettings in the lead-up  
 to 3.0.

Just a stupid question... Why should we switch to GSettings? Ie, what
does it bring us that we can't do with gconf?

So far, I heard a performance argument. Anything else?

(if GSettings goes in glib, then things will obviously be different
since it will consolidate our stack)

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: dconf

[Josselin Mouette]

Le vendredi 10 avril 2009 à 15:15 +0200, Vincent Untz a écrit :
 Just a stupid question... Why should we switch to GSettings? Ie, what
 does it bring us that we can't do with gconf?
 
 So far, I heard a performance argument. Anything else?

Getting rid of the ORBit dependency?

 (if GSettings goes in glib, then things will obviously be different
 since it will consolidate our stack)

That would mean making glib depend on D-Bus, unfortunately.

-- 
 .''`.  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

[Jamie McCracken]

On Fri, 2009-04-10 at 17:11 +0200, Josselin Mouette wrote:
 Le vendredi 10 avril 2009 à 15:15 +0200, Vincent Untz a écrit :
  Just a stupid question... Why should we switch to GSettings? Ie, what
  does it bring us that we can't do with gconf?
  
  So far, I heard a performance argument. Anything else?
 
 Getting rid of the ORBit dependency?
 
  (if GSettings goes in glib, then things will obviously be different
  since it will consolidate our stack)
 
 That would mean making glib depend on D-Bus, unfortunately.

I would imagine it being a compile time option with Gsettings falling
back to simple text files if neither dbus nor dconf were present

we badly need a configuration facility in glib so all glib apps can use
it much like gio does to gnome-vfs. That in itself is a good enough
reason for the change

jamie

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

Re: dconf

[Michael Meeks]

Hi Ryan,

On Thu, 2009-04-02 at 11:37 -0400, Ryan Lortie wrote:
 dconf is very efficient.  The majority case in accessing settings is 
 reading (think about desktop login: 1000s of settings read, none 
 written).

I'm sold on the efficiency win of d-conf's design; but there is at
least a chunk of work here needed to stop people writing settings on
login; if you checkout:
http://www.gnome.org/~michael/gconf-login-trace.txt

grep for -set and we have ~200+ hits during login; most of these are
from the panel (now I believed ~fixed), and NetworkManager (AFAIR not
addressed), but others are scattered around the place.

   Reading in dconf is done directly from a memory-mapped file 
 containing the settings in an efficient tree format and doesn't require 
 an extra service to be running.  The service is only needed for writes. 
   Communication occurs over DBus, of course. :)

What was the final answer wrt. NFS ? I was wondering - assuming writes
are as infrequent and temporally grouped as we hope they will be; could
we not simply re-write the whole binary file after some suitable delay
and do some write, [fsync to taste], rename, thing ? Presumably that
would remove any chance of setting D/B corruption over NFS (?).

I look forward to playing with d-conf; I was wondering - how do you
deal with the separation of l10n data - not just schema key
translations, but localised default values: gconf goes to some effort to
split out the first (but sadly not the second) - it'd be great to see
that done well.

Another thing that perhaps isn't as easy as it could be around gconf is
packaging, cleanly capturing the difference between a make install
style developer use - where you want to merge settings to the prefix,
and the rpmbuild style packager use where you want to defer that until
package install time. Having simple, and nicely documented analogs of
the various interesting gconftool-2 --makefile-install-foo type options
would be great.

HTH,

Michael.

-- 
 michael.me...@novell.com  , Pseudo Engineer, itinerant idiot

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

Re: dconf

[Havoc Pennington]

Hi,

On Wed, Apr 8, 2009 at 6:16 AM, Michael Meeks michael.me...@novell.com wrote:
        Another thing that perhaps isn't as easy as it could be around gconf is
 packaging, cleanly capturing the difference between a make install
 style developer use - where you want to merge settings to the prefix,
 and the rpmbuild style packager use where you want to defer that until
 package install time. Having simple, and nicely documented analogs of
 the various interesting gconftool-2 --makefile-install-foo type options
 would be great.


This should be designed out; the schema install silliness in gconf
was just not a good idea. The way I think dconf works (and the
recommendation on
http://projects.gnome.org/gconf/plans.html) is that schemas are
basically part of the app, much as glade files are, though in this
case they may be shared among apps. Anyway, hopefully installing
schemas just dist_schemas_DATA = foo.schemas in Makefile.am and
that's it.

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

Re: dconf

[Ryan Lortie]

Havoc Pennington wrote:

This should be designed out; the schema install silliness in gconf
was just not a good idea. The way I think dconf works (and the
recommendation on
http://projects.gnome.org/gconf/plans.html) is that schemas are
basically part of the app, much as glade files are, though in this
case they may be shared among apps. Anyway, hopefully installing
schemas just dist_schemas_DATA = foo.schemas in Makefile.am and
that's it.


That is approximately correct.

It's an open question if there will be a update-dconf-schema-cache 
program that you should run for optimum performance (compare: font 
cache, icon cache, etc).


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

Re: dconf

[Ryan Lortie]

Alberto Ruiz wrote:

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?


The single backend database file is maintained in such a way that it's 
always completely safe to make a copy of it and have the latest contents 
of the database.


It would also be possible to make a very slight modification to the code 
that causes every single write to the database to create a new tree (git 
style) and store all of the old copies of the tree.  This is close to 
how it already works, except currently there's an optimisation that 
allows directories to be reused if they can be atomically updated (ie: 
only one word-sized value needs to be changed).


Some mix could be possible: only write the totally new copies of the 
tree sometimes (every nth write, or once a day?).


Did you have something more specific/better in mind?

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

Re: dconf

[Ryan Lortie]

Callum McKenzie wrote:

Can current gconf settings be easily loaded into dconf? e.g. can someone
launching into a gnome 3.0, dconf-based, system for the first time still
have the same wallpaper settings as they did before?

I'm assuming that a) the settings still make sense and b) that the
application can provide a mapping between old and new settings.


Yes, but currently this would have to be completely manual and would 
require the application to link to both dconf and GConf.  This sucks.


I guess a good solution would be to provide some easy-to-use framework 
by which applications could have migration scripts in python or 
something.  That way the application itself doesn't need to do GConf, 
but the python script can if GConf is still installed.


Ideas are definitely welcome in this direction.

Cheers

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

Re: dconf

[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

[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

[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

Re: dconf

[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: dconf

[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

Re: dconf

[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

[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

[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: dconf

[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

[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

[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

[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

[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

[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: dconf

[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

[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

[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

[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

[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

[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

Re: dconf

[Ronald S. Bultje]

Hi,

On Thu, Apr 2, 2009 at 11:37 AM, Ryan Lortie de...@desrt.ca wrote:
 first: GVariant.

For those of us who are ignorant, like me: what is GVariant, how does
it relate to GValue, will it deprecate GValue and if so, why is it not
possible to just fix GValue instead? It's not in your email which I am
responding to, and it's not in the email which announces the existence
of GVariant either.

(The answer might be long and inappropriate for this mailinglist, so
how about a blog post instead?)

Thanks for your work,
Ronald
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: dconf

[Ryan Lortie]

Ross Burton wrote:

Is a GConf compatibility layer possible, or are there too many semantic
differences?


The type system of dbus (and therefore GVariant and dconf) is a superset 
of the type system of GConf -- any value that can be stored in GConf can 
be stored in dconf.  Due to the simple nature of GConfValue, making this 
bridge would be trivial.


The namespace is also essentially the same: a hierarchy of keys with no 
particular restrictions.


It would be very easy to use dconf with the GConf API with a very thin 
client-side compatibility layer.


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.


It might be possible to come up with a temporary hack to deal with 
schemas.  Something like having the compatibility layer insert responses 
 from the schema files where appropriate and dealing with dynamic 
application-installed schema entries (think: panel) with extra keys in 
the dconf database.


Like if you add a schema for some foo key maybe you could get a 
.foo.schema extra entry that contains all of the information required...


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


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

Re: dconf

[Brian Cameron]

I think dconf is a great project, but I do have one question.  Will the
new dconf address the sorts of D-Bus problems raised in these GConf
bugs?

  http://bugzilla.gnome.org/show_bug.cgi?id=555745
  http://bugs.freedesktop.org/show_bug.cgi?id=17970

Thanks,

Brian


On 04/02/09 10:37, Ryan Lortie wrote:

Hello, d-d-l.

I'm a long-time listener, first time caller.

Many of you are probably aware of two things about me:

0) I'm that guy who is working on that weird cloud of dbus-ish stuff
involving GVariant and dconf and GSettings, etc.
1) A few months ago I started working for Codethink

This email is a statement of status, of direction and of intention. A
lot of people have been asking what is going on, so this is an update.
It's not really an attempt to start a discussion, but if that happens,
then I'm happy to answer any questions. :)


first: GVariant.

GVariant has been in an essentially-complete state for quite a long time
now. I recently rolled a tarball of it and announced it to the
announcement list. It is available here:

http://www.gnome.org/~ryanl/src/

GVariant is currently hosted as a totally separate project in a git
repository on git.desrt.ca:

https://desrt.ca/gitweb/?p=gvariant

The intention is that it be merged with glib (into the base libglib
library). Now that glib is in git I will be making a branch and
performing the merge. This should be complete within a couple of days. I
will then propose it for inclusion in the next release of glib.

GVariant is reasonably well-tested and is being used in a number of
other projects that I'm working on. Of course, it surely has some bugs
hiding in it. I believe that the API is more or less stable at this
point, but I welcome constructive criticism and feedback. There are
plans to add more functionality (such as the ability to print/parse
pythonic text strings).

You can read more details about how GVariant works in the release
announcement here:


http://mail.gnome.org/archives/gnome-announce-list/2009-March/msg00103.html


second: dconf and GSettings

For some time I've been talking about these pair of projects as a
proposed replacement for GConf. The reasons that we might want to
replace GConf are well understood and widely documented and I won't talk
about them here.

A while ago there was even a reasonably-working implementation of dconf.
This was based on a different value system (ie: before I started writing
the more-generally-useful GVariant). I stopped working on dconf when I
shifted focus to GVariant and when school started consuming a lot of my
time.

Recently, sponsored by Codethink (now my employer), I have resumed work
on dconf. This has come in the form of a total rewrite (and
simplification) based on GVariant. This rewrite (along with another
project, GBus) is doing a lot to convince me of the stability and
usability of GVariant.

Briefly, dconf is a simple untyped hierarchy of keys. It is used as the
backend storage for GSettings which is a very strictly typed high-level
settings system intended to be used by GNOME applications. The API is
much nicer than GConf.

dconf is very efficient. The majority case in accessing settings is
reading (think about desktop login: 1000s of settings read, none
written). Reading in dconf is done directly from a memory-mapped file
containing the settings in an efficient tree format and doesn't require
an extra service to be running. The service is only needed for writes.
Communication occurs over DBus, of course. :)

The rewrite of dconf is currently extremely unstable and incomplete, but
it is currently being hacked on (along with GSettings) full-time.
Progress is good. In a week or two I will have something to show for
this and I intend to have a stable release to go along with 2.28. Stay
tuned. :)

Ideally, I'd like to see GNOME using GSettings for 3.0. Rob Taylor (my
boss) has indicated that I will definitely be able to spend time
addressing issues that may arise with dconf and GSettings in the lead-up
to 3.0.


So that's it. That's what I'm up to.

Have a good day :)
___
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

[Brian Cameron]

Ryan:


I was not familiar with these bugs.


I'm glad to bring them to your attention, then, since I think it
relates to the work in dconf.


One thing is definitely true: for reading from the configuration
settings, these bugs will not be an issue because you don't need to use
the bus or launch the service at all for this to work.

For writing, it's really hard to say. This seems like a wider DBus issue
affecting all things that use it. Depending on how those bugs are
resolved upstream, the result will be different for dconf. It seems, in
general, we need to have a better-defined idea of what a session is.

I assume the reason that these bugs bother you is because GConf used to
work properly under 'su' when it was straight-up CORBA?


Many people have complained to me about the fact that the configuration
management can't start unless D-Bus is running.  People don't
understand the need to run dbus-launch when they just want to run some
program which uses GConf or dconf.  It makes it awkward to run programs
outside of normal D-Bus enabled user sessions.  The fact that this
causes problems with su is just an example of a wider problem and
probably the most annoying aspect of the bug to normal users.

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

Re: dconf

[Rob Taylor]

Brian Cameron wrote:
 
 Ryan:
 
 I was not familiar with these bugs.
 
 I'm glad to bring them to your attention, then, since I think it
 relates to the work in dconf.
 
 One thing is definitely true: for reading from the configuration
 settings, these bugs will not be an issue because you don't need to use
 the bus or launch the service at all for this to work.

 For writing, it's really hard to say. This seems like a wider DBus issue
 affecting all things that use it. Depending on how those bugs are
 resolved upstream, the result will be different for dconf. It seems, in
 general, we need to have a better-defined idea of what a session is.

 I assume the reason that these bugs bother you is because GConf used to
 work properly under 'su' when it was straight-up CORBA?
 
 Many people have complained to me about the fact that the configuration
 management can't start unless D-Bus is running.  People don't
 understand the need to run dbus-launch when they just want to run some
 program which uses GConf or dconf.  It makes it awkward to run programs
 outside of normal D-Bus enabled user sessions. 

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.

 The fact that this
 causes problems with su is just an example of a wider problem and
 probably the most annoying aspect of the bug to normal users.

Actually, no, the su problem is completely orthogonal, this is something
that needs addressing in DBus itself and is fixable.

Thanks,
Rob

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


-- 
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

[Brian Cameron]

Rob:


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.


I monitor opensolaris user list discussions, and it does cause
some confusion and problems for users when they are working in certain
setups.  As an example, I remember one user who was setting up a
multi-user kiosk environment, and only wanted the browser and a few
other applications launched with particular geometries.  They had some
trouble figuring out they needed to use dbus-launch to run one of the
programs that was GConf based.

It isn't the worst bug in the world, and the workaround is usually
not bad.  I just wanted to find out if there were any plans to make
dconf autostart itself and the services it needs more nicely than
what we have today.

However, if you want to discuss this bug more, lets discuss it in
the bug report rather than clutter this discussion further.


The fact that this
causes problems with su is just an example of a wider problem and
probably the most annoying aspect of the bug to normal users.


Actually, no, the su problem is completely orthogonal, this is something
that needs addressing in DBus itself and is fixable.


Yes, they are two different bug reports.  Just something I wanted to
highlight to people's attention.

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

Re: dconf

[Hubert Figuiere]

On 04/02/2009 02:39 PM, Rob Taylor wrote:

My question would be is why do these People have a desktop in which
there isn't a DBus session bus?



The case were people in corporate Microdows environment have to manage a 
Linux box, and have to run UI application to the X11 server on the 
Windows PC they use to do that. In that case you don't have a session.


FWIW, my Debian server does not have dbus running. I never use any X 
program from it, but I wonder how it would behave in that situation.



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

Re: dconf

[Xavier Bestel]

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).

Xav


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

Re: dconf

[Martin Meyer]

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?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: dconf

[Callum McKenzie]

Can current gconf settings be easily loaded into dconf? e.g. can someone
launching into a gnome 3.0, dconf-based, system for the first time still
have the same wallpaper settings as they did before?

I'm assuming that a) the settings still make sense and b) that the
application can provide a mapping between old and new settings.

Gnome 3.0 is of course an invitation to break everything, but I'm
wondering if its possible to not break absolutely everything from the
users perspective?

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