#1 Disabled plugins get re-enabled

open
nobody
None
5
2012-10-09
2009-03-23
svat
No

Each time I disable the OTR plugin, it gets disabled for that session, but when I restart Pidgin the plugin is again enabled. (I have tried deleting prefs.xml, and it doesn't help.)

The situation is the same with other plugins as well.

Pidgin 2.5.5 Mac

Discussion

  • Albert Zeyer
    Albert Zeyer
    2009-03-23

    Yes I know, that is because I am loading some of them explicitly (was easier the first time I fixed the static linking of the plugins). I thought I'll just load some of the plugins which most user want to use probably and which are not too annoying. Seems I was wrong with OTR. :)

    I didn't found a way to load plugins by default (and not load them if the user unchecked them once). Another way would be to just doesn't load any plugin and you have to set that yourself. Whereby I thought it would perhaps be more the Mac way if some usefull plugins are already enabled right at the beginning.

    (If you are looking at the source, this is in pidgin-macosx/config.h, there I specify which plugins are loaded and which not.)

     
  • svat
    svat
    2009-03-23

    Ah ok :)

    I certainly agree that it's a good idea (and the Mac way) to enable some useful plugins by default, but it can be quite an inconvenience if the users cannot turn them off... which is not the Mac way ;-)

    Is it possible to ship a script that creates a default prefs.xml the first time Pidgin is run? That would not affect the preferences of users who already have them, and new users would get the "default" plugins. [There could even be a special plugin, enabled-by-force, which checks this :)]

    [I had left this comment earlier, but it seems to have disappeared. So retyped it, into a different box.]

     
  • Albert Zeyer
    Albert Zeyer
    2009-03-23

    Yes, that was also my idea if I could just not force load all the plugins but just create a good default prefs.xml. That's probably not that complicated. Whereby I was afraid that I had to do much changes in this file over the time. And I was also a bit lazy to create one (I had already all my settings and didn't wanted to edit that file by hand to delete them).

    But if you want to help, you can perhaps create such a file. :) (Just attach it here to that bug.)

     
  • svat
    svat
    2009-03-30

    I still haven't got around to this, but it seems that the cleanest way to do this would be to make a plugin that enables all the other default plugins. I actually asked on the Pidgin mailing list: http://pidgin.im/pipermail/devel/2009-March/007855.html

    So it seems best to rewrite the existing config.c as a plugin instead. Sometime "soon"...

     
  • Albert Zeyer
    Albert Zeyer
    2009-03-30

    So, it is not possible somehow to give a default prefs.xml which is ignored once the user has its own?

    If we would have config.c as a plugin, what exactly should it do? Should that config-plugin be loaded by default? (I am not sure if I really understand it correctly. It seems more that we move the problem of automatic loading to another plugin but don't really solve it.)

    I think another easy hack would be to just make a small check somewhere in the config loading part, iff the file is not available, then it loads the default plugins.

     
  • svat
    svat
    2009-03-30

    The plugin idea was that it would be a "plugins loader plugin" which loads the other set of plugins but which the user can disable if he doesn't want them. The other (better) alternative is what you suggested: have the config loading part run only once, by setting a preference for itself the first time it is run. I was thinking of the issue where if someone has ever used Pidgin before (either the X11 version, or the Fink/MacPorts version, or whatever) they will have a prefs.xml and not get the plugins loaded. But I'm not sure that's an issue; that's probably how it should be. Their old preferences should not be clobbered even once, probably.

    Pidgin reads /etc/purple/prefs.xml if the user has no prefs.xml. It should be possible to put the equivalent of that in the app. If you think this is okay, this should be easy to do [I think to load plugins, we need to put something like the following

                <pref name='plugins'>
                        <pref name='loaded' type='pathlist'>
                                <item value='/path/to/plugin.so'/>
                        </pref>
                </pref>
    

    in prefs.xml]