Tagger3 changed it's behaviour

This refers to the script Tagger3 for DOpus 12.
The behaviour of the script changed with DOpus v13. I just want to report the changes because it may show something that needs to be fixed in v13 (or v12).

1) The Tagger dialog contains a checkbox "check1". In the german dialog ressource I entered the title "lock" for this checkbox. DOpus v12 didn't show this title. Dopus v13 shows it, moving the input field to the right:
v12:


v13:

2) Tagger couldn't read existing Tags of files unless applied in the current session. I could fix this by un-commenting lines 252 and 257:

For i=0 To all -1
    Set itemData  = DOpus.FSUtil.GetMetadata(cmd.sourcetab.all(i))
    'If Not IsEmpty(itemData.tags) Then
        For Each tag In itemData.tags
            tagString = tagString & tag & ";"
        Next
        If itemData.tags.count >1 Then tagString = StringSort(tagString)
    'End If

I've no idea why this worked with v12 but not with v13.

3) Opening Tagger with e.g. the following button code always opened 2 instances of the viewer. One of them linked to Tagger, the other one useless.

Show FULLSCREEN
[
Tagger OPACITY=180 VIEWER NOFOLDERS FILTER *.(jpg|png) CLOSEAPP CONFIRMDELETE
]

To fix this I have to activate the option "Use existing Viewer window" in Preferences/Standalone Viewer.
However, when I change the first line of the button code to e.g.

Show FULLSCREEN LISTERLINK

the issue reappears.

The first 2 issues are fixed in the current download-version of Tagger3 because the fixed version seems to work with both v12 and v13.

1 Like
  1. Opus 13 will automatically fix certain layout issues, like checkboxes that aren't wide enough or overlapping controls. (Things that are impossible to get exactly right in the resources, since you can't know the font or DPI anyone's using, which makes a big difference to how wide text is.)

  2. Checking if GetMetadata returned anything seems sensible, whether 12 or 13.

  3. Don't know, without studying the script's source, but presumably it is running the viewer twice. There's a Preferences option for reusing viewer windows, so that may just be set differently. It sounds like a bug in the script (running the viewer twice instead of just once) that just wasn't noticed before due to config.

1 Like

Yes, Tagger opens the viewer twice. Once from the button-code and from inside the script (lines 280-289) with the argument USEEXISTING. I can't say why this was necessary after all these years. FWIW, the script still works as long as the option to reuse an existing viewer in preferences is activated and the argument LISTERLINK, which doesn't make sense for Tagger anyway, is not used in the button-code.

If arg.got_arg.viewer = True Then
If IsObject(data.Func.viewer) Then
Script.vars.Set "viewer", data.Func.viewer
cmd.RunCommand("Show " & """" & lastFile & """" & " USEEXISTING AUTOFILELIST")
data.Func.viewer.title = "Tagger - %T"
Else
If IsObject(DOpus.viewers.lastactive) Then
DOpus.viewers.lastactive.Command "close"
End If
End If
End If

1 Like

I could fix the double-instance-issue by simply out-commenting line 283. It now works fine. No need to change any option in preferences, no second instance even if the argument LISTERLINK is used.
The fixed version is available in the Tagger3-thread mentioned above.

'cmd.RunCommand("Show " & """" & lastFile & """" & " USEEXISTING

Unfortunately, the Tagger turns out to be broken again (not sure if it's since the newer Betas). I can add tags, but Enter won't do its job, not going to the next image. Instead it clears the input field, but remains at the already edited image. My workaround so far is to escape tagger, and to restart it. Interestingly, even though it didn't go to the next image in Tagger mode, it moved to the next image underneath. But it doesn't help much, because the old image will be seen in Tagger mode, and no navigation (PgDn or mouse wheel) is possible, when i need to see the next image. So i will have to take the longer way.