Basic question re: Editor plugins

[jackie_w]

I decided to try to write my first Editor plugin but I seem to be missing something very basic. I'm using Windows 7.

If I put some print() statements in my code to help debug, where is the output supposed to appear? I've started calibre using:

c:\program files (x86)\calibre2\calibre-debug -g

then opened my test file with the Editor and run the Editor test plugin but I don't see any print output on the console. The last thing shown in the console window is

Worker Launch took: 0.171999931335

I also tried opening a CMD window and typing

ebook-edit "path_to_my_epub"

The Editor opens my epub and I can run the test plugin but I still don't see any print() output.

What am I missing?

[kovidgoyal]

You need

calibre-debug -t

When you launch the editor from within calibre, its output is nulled.

[jackie_w]

Ah, OK. Thanks

[jackie_w]

I thought I'd drop by to say thanks for the Editor plugin feature.

Now I finally bit the bullet and read through the demo I realise it is not nearly as difficult as I had anticipated. In fact I think the endless [code - test ...] loop is faster than with the User Interface Action plugins.

This is really going to speed up my incessant book tweaking as I no longer need to keep switching between the Editor and my UIA plugins. What a joy!


I've been using the excellent Container classes for quite a while now and I wonder whether you might consider adding some convenient extra properties. For example, anyone who regularly tweaks ebooks is likely to need:

for name in [n for (n, lin) in container.spine_names]:
    do stuff to an HTML page

on a regular basis. It would be convenient to just code something like:

for name in container.spine_list:
    do stuff to an HTML page

I also use a spine list when I want to make sure a selection of tweaked names is displayed in spine order.

Similarly properties for the following may be useful to other tweakers:

• list of CSS names
• list of all image names
• list of raster image names
• list of svg image names
• cover image name
• cover page name
• NCX name
• nav name
• list of spine names which appear in the TOC

If you're amenable to the general idea but lack the time, I'd be happy to have a first stab at the code for your consideration.

[kovidgoyal]

You can just do

for name, lin in container.spine_names:
   Do something with name

Although you should not rely on the fact that all html files will be in the spine, there exist books where that is not true. It's better to iterate over all items that have a mimetype in OEB_DOCS. See below:

For ToC you dont want to be using NCX/nav, instead use the functions in polish.toc, like find_existing_toc etc. Similarly for covers, you should use the functions in polish.cover


For the general request for iterating over "types of files", I can easily add an fucntion

def names_that_match_type(self, predicate):
    where predicate is an arbitrary function that takes a single argument, the media-type

To get HTML documents, you do

container.names_that_match_type(OEB_DOCS.__contain s__)

To get raster images you do

container.names_that_match_type(OEB_RASTER_IMAGES. __contains__)

for style sheets

container.names_that_match_type(OEB_STYLES.__conta ins__)


and so on...

[kovidgoyal]

Here you go,

https://github.com/kovidgoyal/calibr...f5a8083ad6b6e7


I mafe it even simpler, so you can

container.manifest_items_of_type(OEB_STYLES)
or
container.manifest_items_of_type('image/svg')
or
container.manifest_items_of_type(lambda mt: mt.startswith('image/'))

and so on...

[jackie_w]

First off, thank you for the new addition

Originally Posted by kovidgoyal

Although you should not rely on the fact that all html files will be in the spine, there exist books where that is not true.

I guess that can be true, but for my own purposes I only want to tweak HTML files which are in the spine. The rest I'll leave well alone.

Originally Posted by kovidgoyal

For ToC you dont want to be using NCX/nav, instead use the functions in polish.toc, like find_existing_toc etc. Similarly for covers, you should use the functions in polish.cover

I've been using find_existing_ncx_toc, find_existing_nav_toc to get the NCX, nav names. Also more recently get_toc and the attribute toc_file_name.

I've also been using find_cover_image to get the name for cover_image, although perhaps I should be using get_raster_cover_name.

Getting the name for cover_page is a little trickier. I've been using a combination of find_cover_page and find_cover_image_in_page which so far has been OK for my own epubs (which all have a calibre-SVG-style cover) but perhaps too simplistic for a general solution. Do you have a more robust suggestion?

The point I'm trying to make is that although the functionality is probably already available, if you're just starting out with personal tweaking, finding it can be a bit daunting Gathering it all together in plain view in the Container would have been very helpful to me in the early days - reduced thinking time - or maybe that's not such a good idea after all.

[kovidgoyal]

It's a tradeoff, put too many thing ins Container and it becomes too unwieldy and no one will be able to find anything there.

My philosophy is too put the basic building block stuff, and OPF related stuff, on the container, and everything else in the polish.* modules.

I agree that discovery of the stuff in the modules is harder, but I think that's more a problem to address via documentation.

[jackie_w]

I'm having a problem with an Editor plugin Tool which changes CSS rules.

If I have an HTML file open in the Editor and run the CSS-changer plugin I can see from Show Diffs that the changes have been made, however the new CSS has not been applied to the Preview panel for the open HTML editor. The changes don't show in the Live CSS panel either.

I can reproduce this by installing your sample Editor 'Magnify fonts' Tool.

• Install demo 'Magnify fonts'
• Open an epub in the Editor and open an HTML file
• Run 'Magnify fonts'. The Preview panel remains unchanged

I can manually kick-start Preview and Live CSS by any of these methods, but I'd rather not have to if there's a better way:

• double-clicking the CSS file in the Files Browser
• typing something (even a space) in the already-open HTML editor
• opening a new HTML file, then tabbing back to the original HTML

Any suggestions?

ETA: In case it matters calibre v2.62 Win10

[kovidgoyal]

If your plugin does not make any changes to the file currently displayed in the preview panel, then it will not refresh automatically, you'd have to force it to refresh, by doing:

self.boss.gui.preview.start_refresh_timer()

after the call to

apply_container_update_to_gui()

Or you could just wait for the next release, where I have apply_container_update_to_gui() do that automatically.

https://github.com/kovidgoyal/calibr...136e9a0fdd5192

[jackie_w]

Originally Posted by kovidgoyal

Or you could just wait for the next release, where I have apply_container_update_to_gui() do that automatically.

This option is fine by me. Thank you

[jackie_w]

I thought I'd give some feedback on this. Although I can see that the update works fine on the 'Magnify fonts' demo, I can't get it to work as-is on my own CSS tweaker Editor plugin. I *can* get it to work with a small kludge so I'm not too worried but I wondered if you may be able to shed some light - no rush if you're busy.

Background: I'll try to avoid too much detail...
My Editor plugin calls one huge QDialog (which I've been using in a User Interface plugin for years). It tweaks a single CSS file using loads of GUI widgets. Tweaks are done via cssutils on a parsed sheet. It has its own simple preview QWebView pane for instant feedback of changes to text appearance, so every single CSS change needs to be immediately written to disk (using container.open method ATMO). My original hope was to be able to get rid of my QWebView and use the Editor's Preview. ATMO I think that may be a bit ambitious.

Whichever style rule I'm currently tweaking has a temporary highlight applied ('background-color:aqua') so it's easy to see which text is affected in the HTML preview. The very last tweak before saving the QDialog is always the same, i.e. to make sure any remaining highlights are removed. This happens in the QDialog self.accept() method immediately before QDialog.accept(self).

Now to the crux of the problem:
Running from source, including the new self.boss.gui.preview.start_refresh_timer() addition. No matter whether I make 1 or 101 CSS tweaks the result is always the same, namely, after hitting the Tool dialog's Save button, Preview/LiveCSS show all changes except that last remove-the-highlights change. The file on disk is correct and Show Diffs shows that the highlights are indeed gone but Preview/LiveCSS don't think so.

If I force the highlights to be removed before pressing the Save button, the problem goes away. I could easily add an extra button to the QDialog to do this, but 4-years of previously *not doing it* means I'm going to forget to press it.

My current kludge is to add the red bit to the Editor plugin Tool code which also seems to fix it:

dlg = CSSTweakerDlg(...)
if dlg.exec_():
    try:
        self.boss.close_editor(cssname)
    except:
        pass
    self.boss.edit_file(cssname)
    ... etc ...

Do you think this may just be a timing problem, i.e. the file isn't being saved to disk quite fast enough for Preview/LiveCSS to see it? Or something else ...

[kovidgoyal]

You are calling apply_container_update_to_gui() somewhere in there?

[jackie_w]

Yes. I've used a fairly similar structure for all the Editor plugins I've done. Summarised below.

Once ResultsDlg (and optional Show Diffs dialog) are closed:

• With red bit - all tweaks show in Preview/LiveCSS, no highlight, all OK.
• Without red bit - all tweaks show in Preview/LiveCSS, but highlight also still visible in both, but not in Show Diffs.
  Double-clicking CSS file (as long as it wasn't already open) makes highlight disappear.

Spoiler:

class CSSTweakerTool(Tool):
    name = 'CSSTweaker'
    ...

    def create_action(self, for_toolbar=True):
        ...
        ac.triggered.connect(self.do_the_action)
        return ac

    def do_the_action(self):
        self.boss.commit_all_editors_to_container()
        
        try:
            show_changes, dirty = self.css_tweaker()
        except Exception:
            import traceback
            msg = 'Failed to Tweak CSS file'
            error_dialog(self.gui, _(msg), ...)
            self.boss.revert_requested(self.boss.global_undo.previous_container)
        else:
            if show_changes:
                self.boss.show_current_diff()
            if dirty:
                self.boss.apply_container_update_to_gui()
            else:
                self.boss.rewind_savepoint()

    def css_tweaker(self):
        log = []
        self.boss.add_savepoint('Before: CSS Tweaker')
        container = self.current_container
        
        ... find container cssname ...
        ... some container checking ...
        if not OK to proceed:
            return False, False

        dlg = CSSTweakerDlg(...)
        if dlg.exec_():
            
            try:
                self.boss.close_editor(cssname)
            except:
                pass
            self.boss.edit_file(cssname)
            
            log.extend(dlg.csslog)
            resdlg = ResultsDlg(self.name, log, show_changes_button=True, parent=self.gui)
            return resdlg.exec_(), True
        else:    
            return False, False

ETA: Extra info. I should have tried this sooner - without the red bit I can also "fix" things by right-clicking Preview and selecting 'Refresh Preview"

ETA2: Replacing the red bit with the single command you spoke of above, self.boss.gui.preview.start_refresh_timer() also fixes things. This is neater.

In the production version of 2.62 adding that command twice, fixes things:
1st - where the red bit is
2nd - immediately following the self.boss.apply_container_update_to_gui()

[kovidgoyal]

I need an actual plugin to see whats going on.