GNOME Bugzilla – Bug 709519
Remove gconf from gnome-panel and applets
Last modified: 2015-03-24 13:01:17 UTC
Created attachment 256580 [details] [review] remove gconf Patch to remove gconf from gnome-panel and applets. Patch removes gnome-panel-add too. It is written to work with gconf, but panel does not use gconf anymore. so it is useless.
Does that obsolete bug 638688?
(In reply to comment #1) > Does that obsolete bug 638688? Yes and no. 1) yes because there is no gconf after this patch, so nothing to port. 2) no because I did not port anything to gsettings. for example panel-bindings.c I just removed gconf part.
Hi Alberts, I have been reading through this very long patch just now. I have a question: Does this patch remove any kind of functionality that we should maybe reimplement using GSettings, or are all the GConf settings that are being removed unused? Could you maybe explain what the those settings were being used for? From what I can see the settings were related to metacity, nautilus and some desktop stuff, right? If none of this functionality is needed anymore, then I think the patch is fine. Otherwise maybe I can help to provide some patches for GSettings? Cheers Sebastian
Review of attachment 256580 [details] [review]: I don't think this proposal is particularly well-though-out. I'm willing to consider the "eliminate gconf" route in the long run, but this will need a lot more preparation work than a quick one-off patch. ::: gnome-panel/gnome-panel-add.in @@ -323,3 @@ - sys.exit(1) - except KeyboardInterrupt: - pass This script shouldn't be too hard to port to PyGObject / GSettings. ::: libpanel-applet/libpanelapplet-4.0.pc.in @@ +11,3 @@ Name: libpanel-applet-4 Description: libpanel-applet-4 +Requires: glib-2.0 gtk+-3.0 This will ofcourse create an API- and ABI-inompatible version of libpanel-applet, so can only be landed when we decide to break ABI for libpanel-applet. ::: libpanel-applet/panel-applet-gconf.h @@ -84,3 @@ -G_END_DECLS - -#endif /* __PANEL_APPLET_GCONF_H__ */ Dito as above: breaks ABI and API. We need a review, which external applets (at least the ones in gnome-applets) use this functionality in what way, and what to replace it with. Can current GSettings / dconf provide all this functionality to applets with the same convenience ? How is the dconf path passed to the applet ? etc.
(In reply to comment #4) > Review of attachment 256580 [details] [review]: > > I don't think this proposal is particularly well-though-out. I'm willing to > consider the "eliminate gconf" route in the long run, but this will need a lot > more preparation work than a quick one-off patch. I think we should do it for 3.10. Really, it is two weeks since you released 3.8 which basically is 3.6.3. And nothing has happened... When you want release 3.10? With speed like this 3.10 will be same 3.8. > ::: gnome-panel/gnome-panel-add.in > @@ -323,3 @@ > - sys.exit(1) > - except KeyboardInterrupt: > - pass > > This script shouldn't be too hard to port to PyGObject / GSettings. How long panel is using gsettings? Till now no one cares about it (script), currently it is useless. Are you going to port it, than ok. No? Than who will do it? If no one is willing to do it, than remove it. Really we don't need stuff that does not work anymore. > ::: libpanel-applet/libpanelapplet-4.0.pc.in > @@ +11,3 @@ > Name: libpanel-applet-4 > Description: libpanel-applet-4 > +Requires: glib-2.0 gtk+-3.0 > > This will ofcourse create an API- and ABI-inompatible version of > libpanel-applet, so can only be landed when we decide to break ABI for > libpanel-applet. And when we will do? After year, two, ten? Lets do it for 3.10. > ::: libpanel-applet/panel-applet-gconf.h > @@ -84,3 @@ > -G_END_DECLS > - > -#endif /* __PANEL_APPLET_GCONF_H__ */ > > Dito as above: breaks ABI and API. We need a review, which external applets (at > least the ones in gnome-applets) use this functionality in what way, and what > to replace it with. Can current GSettings / dconf provide all this > functionality to applets with the same convenience ? How is the dconf path > passed to the applet ? etc. all applets in gnome-applets currently use gconf, but MATE developers have ported gnome-applets (mate-applets) to gsettings. So this wont be a problem. About what functionality you are speaking? libpanel-applet is already made to work with gsettings. gconf functions is marked as deprecated... gsettings path is passed to the applet same way as gconf path was passed. prefs-key is for gconf, settings-path is for gsettings.
(In reply to comment #3) > Hi Alberts, > > I have been reading through this very long patch just now. I have a question: > > Does this patch remove any kind of functionality that we should maybe > reimplement using GSettings, or are all the GConf settings that are being > removed unused? gnome panel itsef stores settings in gsettings. So everything releated to gconf does not work. For example bindigs are just generating errors for panel and each applet. > Could you maybe explain what the those settings were being used for? From what > I can see the settings were related to metacity, nautilus and some desktop > stuff, right? 1) bindings.c (metacity keys) does not exist in gsettings nor in gconf (at least i cannot find in dconf editor end gconf editor). so at least for now i think best way is to remove. 2) panel-util.c - i see that in gsettings key home-icon-name exist. So this could be ported. This should not be hard, will you do it? that key is under org.gnome.nautilus.desktop. 3) panel-menu-items.c - home_icon_name exist in gsettings, but desktop_is_home_dir and computer_icon_name does not exist. 4) workspace-switcher.c - it uses gsettings now. so no need to use panel_applet_add_preferences. it was only for gconf. 5) window-list.c - same as workspace-switcher. > If none of this functionality is needed anymore, then I think the patch is > fine. Otherwise maybe I can help to provide some patches for GSettings? You can try, but there is almost nothing to change to gsettings. Ok, I guess for 4. and 5. point we could create separate patch, but for it we dont need create bug report. that is something we could directly commit, but i dont have commit rights, I guess you don't have to?
(In reply to comment #5) > > I think we should do it for 3.10. Really, it is two weeks since you released > 3.8 which basically is 3.6.3. And nothing has happened... When you want > release 3.10? With speed like this 3.10 will be same 3.8. You're welcome to help with patch review, refinement, and also with release planning. You're not welcome however to tell me how much work I should put into gnome-panel, and where my priorities should lie. Please learn that most everybody here is a volunteer. > How long panel is using gsettings? Since 3.0. And since then the GConf API for out-of-tree applets has been deprecated - but not removed. > Till now no one cares about it (script), > currently it is useless. Maybe it's used by deployments of out-of-tree applets ? Have you even bothered googling for that kind of use case ? > Are you going to port it, than ok. No? Than who will > do it? I think that is a question you should ask on the mailing list. > > This will ofcourse create an API- and ABI-inompatible version of > > libpanel-applet, so can only be landed when we decide to break ABI for > > libpanel-applet. > > And when we will do? After year, two, ten? Lets do it for 3.10. Well I don't see any patch here actually doing this ABI bump. But what's more important, I don't see this proposed on the ML. An ABI bump will create a lot of follow-up work for distribution packagers (parallel installation of libraries, rebuilding and retesting other applet packages etc.). So far, I don't see a lot of distribution guys shipping the 3.8.0 release, or even volunteering to help us with out g-s-d troubles. However, we are de-facto in a state of doing feature based releases in the flashback project. I don't like it, but I also cannot catch up with gnome's time-based releases on my own. Proper release planning should be done on the mailing list, so let's take this discussion there. So, _if_ you think you have a good case for an ABI bump, propose it on the ML, and make a strong case for it. But not if you just want to increase the speed of your git checkout and compile.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.