[GUI Plugin] Action Chains

[capink]

It is not a problem for template actions because it does not result in errors if the column is missing, as you indicated.

But the validation is done by calling the validate method of each action, which will return false if custom column is not present. e.g. single field edit, search and replace ... etc validate methods check whether the column(s) is present.

Anyway, changing the check_chain() to only validate if the conditions are true is not a big deal.

[chaley]

Originally Posted by Terisa de morgan

So, essentially, instead of using "Edit Metadata", I use a function with that template that set the value of the column if it exists.

Assuming I understand you, in this case you will need to use capink's proposed solution. Reason: the Single Field Edit action specifies the destination field. If that destination doesn't exist then the action will fail regardless of what the template does or doesn't do. The action condition must check for the existence of the destination to prevent the action from running.

[capink]

Originally Posted by Terisa de morgan

So, essentially, instead of using "Edit Metadata", I use a function with that template that set the value of the column if it exists.

You keep the action that contains the custom column as it is, and set the following condition to the action:

template:
    program:
        if field_exists('#somefield') then
            'true'
        fi
datatype: text
comparison: =
Condition value = true

This will only work with the next version after I make the necessary changes.

[Terisa de morgan]

Thank you very much! I'll wait for your changes in the plugin and chaley's in calibre.

[capink]

You can test the version in the second post using the current_library_name condition until the changes made by chaley are released.

[Terisa de morgan]

Originally Posted by capink

You can test the version in the second post using the current_library_name condition until the changes made by chaley are released.

Ditto, and it works as I want, thank you very much again!

[capink]

Version 0.6.3

• Update: Prior to running a chain, only validate actions that have no conditions, or those that have conditions that evaluate to true.

Version 0.6.4

• Update: add selection_count template function instead of the old way of pre-calculating selection count as a global_var

The latest version has a change that is not compatible with previous versions. If you have chain/action conditions that check the selection count using the globals(selection_count) function, you have to change that to use the newly introduced selection_count() template function. This new template function only works with the action chains plugin. I will correct all previous posts the reference globals(selection_count) to reflect the new change.

The problem is with the old approach is that it used to pre-calculate the selection count before running every chain and every action, in case there is a template asking for the selection count. The process of calculating the selection count can be expensive if you have a lot of rows selected, which slows down things, often unnecessarily when there are no templates asking for the selection count.

With the new template function, the selection count is only calculated on demand. Also caching is used whenever possible. e.g. checking all chain conditions happens before showing the menu; to disable items with conditions that evaluate to false. Since selections are not going to change when the menu is being shown, the first time the function is called, it caches the value to be re-used when checking subsequent chains, an flushes the cache after the menu is shown.

Likewise, globals(containing_folder) is replaced by containing_folder(). The globals() function is reserved for variables set by the user using the Chain Variables action, or set programmatically (by custom actions) using chain_tools.set_chain_vars() and chain_tools.set_book_vars().

[ownedbycats]

Would the pre-calculation be why there was sometimes a little lag when I clicked on the AC menu?

[capink]

If you have conditions (for chains) actually testing for selection count, you are not going to see much of difference as far as lag, because the old approach also made sure to calculate once when pressing the menu.

The new approach will make difference for people who do not use chain conditions with selection_count. It will also shorten the time between actions because the pre-calculation had to be repeated ahead of each action, regardless of action conditions.

Edit: Also you will notice the lag is proportionate to how many rows are selected when you press the menu.

Edit2: The lag comes from testing chain conditions before showing menu items. It is usually less than a second. Having a huge number of rows selected can make it longer, for people who have conditions using the selection_count().

[ownedbycats]

I have two chains checking the connected device and one using selection count. The lag usually occurs the first time I click after launching Calibre, lasts one or two seconds depending on how many rows are selected. Maybe it's checking the device status too?

[capink]

Could be. Never used device checking before. The best way to know is to test with and without the condition and see the difference.

Maybe the solution to this is to make disabling menu items based on chains conditions optional? and if conditions are not met when the user opted not to grey out menu item and presses it, pop up an error message?

[ownedbycats]

It's not that big a problem to begin with, really. I think it is related to the device check though as I notice the momentary lag returns after I plug in my Kobo.

[chaley]

@capink: looking through your code where you use the template dialog I note that in one case case you reimplement the part that calls the formatter, and in another case you more-or-less reimplement the dialog.

Case 1 is templates.py/TemplateBox. It seems that you were forced to reimplement textbox_changed so you could call safe_format with your new functions. To avoid that I could add two parameters to init

all_functions=None, builtin_functions=None

This would do 2 things: eliminate the requirement that you override textbox_changed and make your template functions visible in the template dialog. The difference between the two arguments is how the functions are labeled in the template reference box. I suspect that you would add your functions to both the standard builtins and all_funcs, making your functions appear as builtin.

Case 2 is ConditionsEval, which reimplements the entire dialog. I think you were forced to this for the same reason as case 1, and because you wanted to add the widgets for datatype, comparison, condition value, icon, and tooltip. To get around adding the widgets I could add several empty label/QBoxLayout pairs to the base TemplateDialog that are normally invisible, named user_label_N and user_layout_N where N is 1-6. You would use these to add your own fields to TemplateDialog. This would both get rid of a lot of the semi-duplicated code and add the template reference.

If this interests you then I could give you a copy of the necessary files. If it works out for you then I would submit my changes to Kovid.

[capink]

First of all, thank you so much for continuous help, it is really appreciated.

Originally Posted by chaley

Case 1 is templates.py/TemplateBox. It seems that you were forced to reimplement textbox_changed so you could call safe_format with your new functions. To avoid that I could add two parameters to init

all_functions=None, builtin_functions=None

This would do 2 things: eliminate the requirement that you override textbox_changed and make your template functions visible in the template dialog. The difference between the two arguments is how the functions are labeled in the template reference box. I suspect that you would add your functions to both the standard builtins and all_funcs, making your functions appear as builtin.

That would really eleminate the need to re-implement the text_changed() method and and make the TemplateDialog re-usable.

Originally Posted by chaley

Case 2 is ConditionsEval, which reimplements the entire dialog. I think you were forced to this for the same reason as case 1, and because you wanted to add the widgets for datatype, comparison, condition value, icon, and tooltip. To get around adding the widgets I could add several empty label/QBoxLayout pairs to the base TemplateDialog that are normally invisible, named user_label_N and user_layout_N where N is 1-6. You would use these to add your own fields to TemplateDialog. This would both get rid of a lot of the semi-duplicated code and add the template reference.

I wonder if it is possible to add an additional nested layout instead, right above the font row, something like this

self.user_layout = QGridLayout()
self.gridLayout.addLayout(self.user_layout, row, col, 2, 1)

The self.user_layout can be used to add variable number of extra widgets. I think this might offer more flexibility when adding things in the future. For example, yesterday I added and additional checkbox that makes chain condition evaluation optional when showing the plugin menu. On the other hand, it might be difficult to keep the alignment of the labels in line with the parent layout.

I can already do something similar by adding to self.verticalLayout as in the attached screen. But it is at the bottom of dialog. Would be better If I have access right above the font row.

Edit: After thinking about it more, I think would should stick the the first point for now, which would make the template dialog re-usable for both cases. Something does not feel right about altering the template dialog that much to accommodate the plugin.

I will only be re-implementing the textbox and the template_value in the ConditionsEval. The rest I can inherit if you make the first change.

[chaley]

Originally Posted by capink

I wonder if it is possible to add an additional nested layout instead, right above the font row, something like this

That is in effect what I did.

I added 6 invisible rows above the font size line. Each row is a named label and a QBoxLayout. You can add widgets to that layout (default layout direction is vertical), or you can add a nested layout to do something more complicated. I did it this way so that the labels will line up with the existing ones. Why more than 1? So you can have multiple labels. Why 6? Felt like a nice number.

Here is an example, gui2.actions.show_template_tester.py. I used two of the 6 lines. The first is a label with a single QComboBox widget. The second is a label with an embedded grid layout.

Spoiler:

    def show_template_editor(self, *args):
        view = self.gui.current_view()
        if view is not self.gui.library_view:
            return error_dialog(self.gui, _('No template tester available'),
                _('Template tester is not available for books '
                  'on the device.')).exec_()

        rows = view.selectionModel().selectedRows()
        if not rows:
            return error_dialog(self.gui, _('No books selected'),
                    _('One book must be selected'), show=True)
        if len(rows) > 1:
            return error_dialog(self.gui, _('Selected multiple books'),
                    _('Only one book can be selected'), show=True)

        index = rows[0]
        if index.isValid():
            db = view.model().db
            t = TemplateDialog(self.gui, self.previous_text,
                   mi=db.get_metadata(index.row(), index_is_id=False, get_cover=False),
                   text_is_placeholder=self.first_time)
            t.setWindowTitle(_('Template tester'))
            #---- EXAMPLE STARTS HERE
            t.user_label_1.setVisible(True)
            t.user_label_1.setText('Example combo box:')
            from PyQt5.Qt import QComboBox
            box = QComboBox(t)
            box.addItems(['one', 'two', 'three'])
            t.user_layout_1.addWidget(box)
            #----
            t.user_label_2.setVisible(True)
            t.user_label_2.setText('Example embedded layout:')
            from PyQt5.Qt import QGridLayout, QLabel
            gl = QGridLayout()
            w1 = QLabel('Grid Row 0 Col 0')
            gl.addWidget(w1, 0, 0)
            w1 = QLabel('Grid Row 1 Col 1')
            gl.addWidget(w1, 1, 1)
            t.user_layout_2.addLayout(gl)
            #---- EXAMPLE ENDS HERE
            if t.exec_() == QDialog.DialogCode.Accepted:
                self.previous_text = t.rule[1]
                self.first_time = False