[GUI Plugin] Action Chains

[chaley]

Originally Posted by capink

After testing some more, I think I found the culprit. The chain loop makes this call between actions:

QApplication.processEvents()

If I comment this out, the problem does not happen anymore. I don't know calling processEvents() leads to this?

You are diving deep into Qt event management.

The "normal" reason for calling that method is that you are doing something on the GUI thread that takes a *long* time, or that your code is on a separate thread without normal event management. Making the call forces processing of queued GUI events, but it is doing so in the middle of processing some other event.

My experience is that it is rare that such a call is needed, and if it is needed then it is often a programming error where long-running "jobs" are running on the GUI thread. One must ask:

• Is the processing really so long?
• If it is so long, should we fork a subprocesses or is the "fork a subprocess" cure worse than the disease?
• If it is so long, is there some way to chain the processing based on events, for example progress timers?

[capink]

Originally Posted by capink

The "normal" reason for calling that method is that you are doing something on the GUI thread that takes a *long* time, or that your code is on a separate thread without normal event management

I am running in the main gui thread because I think I have to, otherwise some actions might fail.

Originally Posted by capink

Is the processing really so long?

Not always, but it can be. Running long search and replace chain on huge libraries can take hours. I've done this when I was testing the plugin at the beginning.

Originally Posted by capink

If it is so long, should we fork a subprocesses or is the "fork a subprocess" cure worse than the disease?

I will admit that this is beyond my knowledge. I don't know much about threads and subprocesses and I am not sure I know the difference between them. With how little I know, I am inclined to think this is not possible because the plugin has to run in the main gui thread, as a lot of actions (e.g. search and replace, single field) make certain calls like db.set_field. I am not sure whether this can be done from a separate thread or a subprocess.

Originally Posted by capink

If it is so long, is there some way to chain the processing based on events, for example progress timers?

This is an interesting idea that I have not thought of. I can try this using QTimers. But it will only alleviate the problem for shorter chains, because with long chains I will still be making the call to processEvents, albeit with much less frequency.

A temporary solution besides the timers, would be to turn this off for chains that are activated by that particular event. I will also test without the call to processEvents and see how much of a difference does it make.

[ownedbycats]

Originally Posted by chaley

You are diving deep into Qt event management.

The "normal" reason for calling that method is that you are doing something on the GUI thread that takes a *long* time, or that your code is on a separate thread without normal event management.

On Windows, if a process goes five seconds without reading the event queue, the OS will assume it's hung and make the window white out and offer to end the process. I am unsure how other OSes handle this though.

[ownedbycats]

Keyboard shortcuts will ignore conditionals and run the chain; I accidentally hit my shortcut for "update fanfic on device" (which is set to a connected_device_name('main') and greyed out in the menu) and got four messages in a row telling me the device wasn't connected before it updated my #onkobo column. Is this something that can be fixed, or outside of AC's control?

[capink]

This is a regression from some code refactoring I did. I have it fixed and will post a new version later today.

[capink]

Originally Posted by capink

Note: Also you can convert the above scope into selections, using these steps:

• Apply the above scope to single field edit action. In the single field action, choose the column "marked", and set it to predefined value with text marking you choose e.g. my_temp_marking
• Use a selection modifier action with the search 'marked:="my_temp_marking"' + select all books in current view to select the target books.
• (Important) Whenever you use marks in chain, it is advised to insert a single filed edit action at the start of the chain that removes all marks that might have been lingering from a previous runs of the chain. You set the scope of this action to all books in library. It is fast so no worries about performance here.

Instead of making the user go through the hoops, I can enable scopes for selection modifier and add an option to convert a scope into selection. Would that be counterintuitive?

[chaley]

Originally Posted by capink

Instead of making the user go through the hoops, I can enable scopes for selection modifier and add an option to convert a scope into selection. Would that be counterintuitive?

I don't think converting a scope into a selection is counterintuitive. It is the reverse of turning a selection into a scope, which the basic scope manager already supports.

A thought: both the basic scope manager and the selection modifier support searching, but with different options. They also have options that appear to do the same thing. Perhaps the visual presentation and option descriptions should be made the same?

Or perhaps embed the scopes dialog into the selection modifier, replacing the search part? If you did this then you wouldn't need to add "scopes" to the selection modifier because they would be built into it.

[capink]

Originally Posted by chaley

A thought: both the basic scope manager and the selection modifier support searching, but with different options. They also have options that appear to do the same thing. Perhaps the visual presentation and option descriptions should be made the same?

They do have the same functionality. I will try to make them look as close as possible. However, there are some differences between "Basic Scopes" and "Selection Modifier". One thing is that "Selection Modifier" can only select books within the confines of the current view (virtual library + current search), so I have to give users the option to change this (clear virtual library, clear search ... etc). Basic scopes is not bound by the current view in the library, although it has an option to respect the current virtual library.

Another limitation of the Selection Modifier is that the search entered by the user has to be validated or else the settings dialog will print an error message. This is done because if the user combines a search with the option to select all books in current view, and the search turns out to invalid, all books in current view (the whole library most likely) will be selected and acted upon by subsequent actions.

The above point is whey I had to introduce the "Search Using Templates" as separate action because the search cannot be validated ahead of time as required by the selection modifier validator, since it results from a template that can only be evaluated at runtime

I didn't have to bother with search validation in Basic Scopes, because if the user enters an invalid search it will simply return an empty book ids list, with no harmful consequences.

Originally Posted by chaley

Or perhaps embed the scopes dialog into the selection modifier, replacing the search part? If you did this then you wouldn't need to add "scopes" to the selection modifier because they would be built into it.

I was thinking more about converting "Template Scopes" into selection (as in the template I posted for @Terisa de May) because everything you can do with Basic Scopes you can already do with the Selection Modifier, except for the book vars option.

But your point made me realize that I can modify the "Search Using Templates" action to actually make it use and call "Template Scopes", thus removing the need to add an option to the selection modifier.

[Venia Legendi]

Originally Posted by capink

Also another way to do this more easily is by using only two single field edit actions, and do away with the first chain variables.

Took me some time to understand this, smart solution, thank you.

[ownedbycats]

Originally Posted by capink

This is a regression from some code refactoring I did. I have it fixed and will post a new version later today.

Fixed!

[ownedbycats]

Question: I have a 'view' action (bound to V and limited to 1 book to prevent mass-opening accidents) to open a book and populate a few columns:

{
  "ActionsChainMenus": {
    "Menus": [
      {
        "active": true,
        "chain_settings": {
          "chain_links": [
            {
              "action_name": "Calibre Actions",
              "action_settings": {
                "disable_busy_cursor": false,
                "selection": [
                  {
                    "display": "View",
                    "path": [
                      "View",
                      "View"
                    ],
                    "paths_text": "View"
                  }
                ],
                "wait_jobs": false,
                "wait_progress": false
              },
              "comment": "Open book"
            },
            {
              "action_name": "Single Field Edit",
              "action_settings": {
                "col_name": "#read",
                "template": "program:\n\n\tif and(check_yes_no('#read', '', '', 1),) then \t'No'\n\telse $#read\n\tfi",
                "value_type": "template"
              },
              "comment": "Set #read column (TEMPLATE)"
            },
            {
              "action_name": "Single Field Edit",
              "action_settings": {
                "col_name": "#percentread",
                "template": "program:\n\tif raw_field('#percentread', '1') ==# '0' then '1'\n\telse raw_field('#percentread')\n\tfi",
                "value_type": "template"
              },
              "comment": "Set #percentread to 1 (TEMPLATE)"
            },
            {
              "action_name": "Single Field Edit",
              "action_settings": {
                "col_name": "#lastread",
                "value": [
                  {
                    "__class__": "datetime.datetime",
                    "__value__": "2021-03-30T00:13:43.637933+00:00"
                  },
                  true
                ],
                "value_type": "predefined"
              },
              "comment": "Set #lastread to current time"
            },
            {
              "action_name": "Refresh View",
              "action_settings": {},
              "comment": "Refresh view"
            }
          ],
          "refresh_gui": true
        },
        "condition_settings": {
          "affect_menu": false,
          "cmp_type": "=",
          "datatype": "number",
          "icon": "",
          "template": "program: selection_count()",
          "tooltip": "",
          "value": 1.0
        },
        "image": "",
        "menuText": "View",
        "subMenu": "Invisible"
      }
    ]
  },
  "schemaVersion": 1.5
}

If the only available format is PAPERBOOK (a zero-length file I use to identify physical copies), I'd want to skip the "View" action. What would be the best way to do that?

[capink]

Two options:

• If the zero length format has a unique extension (I imagine it must have), use the following condition (will assume unique extension is 'abc'):
  
  Template:
  

  {formats}

  Datatype: text
  Comparison: !=
  Condition Value: ABC
  
• If they have no unique extension, you have to tag these books with a unique tag (e.g zero-length), then use the following condition:
  
  Template:
  

  program: 'zero-length' inlist $tags

  Datatype: text
  Comparison: !=
  Condition Value: 1
  
  

[ownedbycats]

That worked. My books are .paperbook files. I didnt realize the validation work would for formats.

[capink]

It works for anything the template language can access. I have a similar chain that takes different actions depending on what formats are present. I have it connected to the "double click" event + a custom "enter pressed" event.

[ownedbycats]

Something I am curious about: I have a custom module to display a confirmation prompt. I mostly use it to avoid accidentally activations of chains I am testing.

would it be possible, with the vars or something, to prompt for a specific action in a chain? If you press 'yes,' it runs the next action; if you press 'no' it skips over that specific action but runs the rest.