calibre's new plugin API

[Cheddarchick]

You know....you guys speak a different language than me.....LOL...I'm lucky to open the book and read it....It does make me crazy not to be able to understand what you are trying to do. All I want is to be able to read all books (insert: library books) on my kindle....

[Manichean]

Originally Posted by Cheddarchick

It does make me crazy not to be able to understand what you are trying to do.

You only need to understand this if you're trying to develop a plugin. If you're not, you can just ignore these things.

[kovidgoyal]

@meme: An error involving calibre_plugins.dummy.* means you have an old style plugin that is causing the error. The name dummy is used when a plugin does not have a plugin-import-name-*.txt file in its zip file.

[meme]

Thanks. I must not have deleted all the old plugins.

My global variables are killing me on this re-organization

[meme]

In my ConfigWidget class I need to call another routine outside the class to initialize data - the routine is used when you run actions other than configuration as well. That routine needs the Calibre gui object in order to get information from Calibre. How do I refer to that gui object? e.g.

def ConfigWidget(QWidget):
...
       my_initialize_routine()


def my_initialize_routine():
    model = self.gui.library_view.model()

self.gui does not exist. I used to have the routine as part of the base object and could call it as self.plugin_action.my_initialize_routine().

Help

I know, I should just wait for kiwidude to release his updated plugins and then copy him

[kiwidude]

You can pass self.actual_plugin_ from the config_widget() method in your __init__.py file to your ConfigWidget initializer. Or if you really just want the gui passed in you could pass self.actual_plugin_.gui

[meme]

Thanks. I knew it was something simple. I was trying to use self.actual_plugin_ but from inside ConfigWidget(). Duh Just one of those moments I guess.


Now I'm back to another issue - when my init routine fails and I want to return from ConfigWidget without doing customization I have been returning a tuple as was added some versions ago. Now I get:

calibre, version 0.7.53
ERROR: Unhandled exception: <b>TypeError</b>:__init__() should return None, not 'tuple'

Traceback (most recent call last):
  File "site-packages/calibre/gui2/preferences/plugins.py", line 261, in customize_plugin
  File "site-packages/calibre/gui2/preferences/plugins.py", line 332, in modify_plugin
  File "site-packages/calibre/customize/__init__.py", line 150, in do_user_config
  File "calibre_plugins.kindle_collections.__init__", line 61, in config_widget
TypeError: __init__() should return None, not 'tuple'

I haven't had a chance to look at the source yet but maybe you've seen this?

[kiwidude]

I believe you will need to change the point at which you return the tuple. Of course now we are creating a ConfigWidget class instance, and doing stuff inside the __init__() function of it, whereas previously you were directly inside the config_widget() function itself.

So if I were you I would not put the code in ConfigWidget() at all. Instead put the check in the config_widget() function in your InterfaceActionBase class.
ie.

def config_widget(self):
    if self.not_valid_to_configure()
        return ('My message', 'My details')
    from calibre_plugins.kindle_collections.config import ConfigWidget
    return ConfigWidget(self.plugin_action_)

[meme]

Kiwidude, thanks. Makes perfect sense. There's obviously a lot more changed than I thought, and the previous approach of copy/paste has its limits.

So now in __init.py__:

    def config_widget(self):
        if self.actual_plugin_:
            error_tuple = self.actual_plugin_.is_configurable()
            if error_tuple:
                return error_tuple

            from calibre_plugins.kindle_collections.config import ConfigWidget
            return ConfigWidget(self.actual_plugin_)

and in ui.py:

    def is_configurable(self):
        if not initialize_data(self.gui):
            (info, error, detail) = msg.message.get_all()
            return (error, detail)
        return None

where I use message to save messages.

I'm still working out how best to handle global variables. I've removed quite a few already by using them as arguments but still have several. Splitting into files means I have one file with just global variables. Which works, but just doesn't 'feel' right. The issue is the routines have interdependencies, but I'll continue to look at the structure.

Kovid, thanks for updating the plugin api. I know its a bit of work now, but I can already see its a lot easier to work with my code now that I can split it up and do away with extra layers of proxy classes.

[kiwidude]

Well strictly speaking we could "always" have had a separate ConfigWidget class, so that isn't new to Kovid's changes. Speaking for myself I didn't before now because stuff just kind of evolved organically and it was easier for me to find when you only had one file to "go to the bottom". Similarly you don't "have" to have a separate one now (if you inline all your imports). It is just an awful lot nicer

As for globals, I feel your pain. Having rediscovered the world of circular dependencies in Python when I did my first semi-complex plugin migration I decided not to get too carried away with splitting stuff out at this point. Particularly when the IDE isn't cooperating in telling you about stuff that isn't referenced correctly etc, just way too much re-testing involved.

I'll describe what I have done - if someone has a better suggestion please feel free to suggest it as I would love to feel better about it. The general pattern in my plugins is:

common_utils.py - utility functions commonly accesed (no constants/variables though). This is linked and shared across my plugins.
config.py - contains my ConfigWidget class for customization, the JSON config file global reference, any constants related to keys within it, and all dialogs that configuration requires. No dependencies other than common_utils.py.
action.py - my InterfaceAction class, depends on config.py for JSON file/constants (and dialogs below)
dialogs.py - if the InterfaceAction launches any dialogs, I put them in here.

Now if I move the JSON file reference and related constants into a separate file (which sounds like you have done), then it would make it possible for me to split further without the circular references. So for instance dialogs launched by the ConfigWidget could be split out.

However, this is not C# (where I put every class in its own file) so I'm prepared to compromise with the above. I'm not exactly in love with Python - as far as I am concerned it is a necessary "evil" that has made possible writing plugins. Far too unproductive to develop with thanks to it's everything is an object/weak typing etc that makes the IDE support abysmal for part-timers like me!

[t3d]

I feel like the API Documentation needs adding a section describing StorePlugin.

I just got an issue creating such plugin (https://www.mobileread.com/forums/sho...d.php?t=132393).

[kiwidude]

@t3d - I know there is documentation within the classes and obviously a bunch of ready-made examples, I'm not sure what more you could need. I'm sure user_none will add more if needed, though the API has only just been released. I will move your other thread into the Development Forum, it is probably a better place for it than in here anyways.