GNOME Bugzilla – Bug 684894
dconf-editor shouldn't be a part of dconf
Last modified: 2015-02-22 12:23:31 UTC
dconf is plumbing. The editor is an application. It doesn't make sense to bundle them together, and I don't want to see a launcher for dconf-editor if I didn't explicitly install it. Fedora and Ubuntu split dconf and dconf-editor into separate packages, which fixes this issue for their users, but that doesn't work for those of us running jhbuild, and it is desirable for jhbuild to reflect the end user experience that we are aiming for.
fwiw, Ubuntu did not split them (and dconf-editor is in the default install). I also disagree that "the default jhbuild result produces I don't personally like" is a good argument. dconf-editor ends up being installed by a massive number of our (actual, not imagined) users. Plus, it's very easy to disable the build of the editor (--disable-editor). At the same time, I think that there are other reasons that we may want to separate dconf-editor. dconf-editor is turning into more of a GSettings editor, anyway. Until such time that it's a pure GSettings editor, however, it will be using the libdconf APIs quite extensively. Those APIs are subject to change (and they just had substantial changes this cycle). Maintaining dconf-editor in a separate source package complicates that quite a bit... Long story short: I agree, but practical considerations prevent an immediate fix. In the meantime, if you don't like it, tweaking your jhbuild flags is the appropriate fix.
(In reply to comment #1) > fwiw, Ubuntu did not split them (and dconf-editor is in the default install). Haven't tried it myself, but I saw indications [1] that they had. > I also disagree that "the default jhbuild result produces I don't personally > like" is a good argument. My use of the first person was rhetorical. ;) The whole point of having applications is that, outside of the core apps, people can install and remove them. Something like dconf-editor isn't a core app, and people should have control over whether it is on their systems. > dconf-editor ends up being installed by a massive > number of our (actual, not imagined) users. There are plenty of really popular applications that we don't install by default. > Plus, it's very easy to disable > the build of the editor (--disable-editor). That's not a great solution though. Disabling the editor isn't the default, and it would be painful if it was. > At the same time, I think that there are other reasons that we may want to > separate dconf-editor. dconf-editor is turning into more of a GSettings > editor, anyway. > > Until such time that it's a pure GSettings editor, however, it will be using > the libdconf APIs quite extensively. Those APIs are subject to change (and > they just had substantial changes this cycle). Maintaining dconf-editor in a > separate source package complicates that quite a bit... I don't know much about that, but I do think it is important to prioritise the user experience that we are trying to deliver. > Long story short: I agree, but practical considerations prevent an immediate > fix. In the meantime, if you don't like it, tweaking your jhbuild flags is the > appropriate fix. Again, this isn't a personal request. My concern is to ensure that application launchers behave as expected. [1] http://www.iloveubuntu.net/how-change-your-icon-theme-dconf-editor-ubuntu-1110
(In reply to comment #2) > Haven't tried it myself, but I saw indications [1] that they had. The dconf-tools package (from your [1]) is now installed by default. > The whole point of having > applications is that, outside of the core apps, people can install and remove > them. Something like dconf-editor isn't a core app, and people should have > control over whether it is on their systems. > There are plenty of really popular applications that we don't install by > default. These are good points.
dconf has now been split up into 'dconf' and 'dconf-editor'.
[moving dconf>editor tickets to dconf-editor product. See bug 744791]