#1225 List of issues stays hidden in the background

[msoutopico]

Preconditions

• Use one monitor only (or make sure all OmegaT windows appear in the same screen).
• Maximize OmegaT's main window (so that it covers the full screen).

Steps to reproduce

1. Run the Check Issues function (e.g. Tools > Check Issues)
2. Click on the editor or main window
3. Create a tag issue somewhere
4. Run the Check Issues function again (see ¶)

¶: Ways to run the Check Issues function in step 4:

• Ctrl+D (provided that option "Block the creation of target files with tag issues" (in Options > Preferences > Tag Processing) is checked
• Enter or (provided that option "Check issues when leaving a segment" (in Options > Preferences > Editor) is checked

Expected results

1. The Issues window appears in the foreground
2. The Issues window is sent to the background, and the main window is in the foreground
3. A tag issue is created
4. The Issues window appears in the foreground again

Actual results

1. As expected
2. As expected
3. As expected
4. The Issues window stays in the background and the user doesn't see it

[Hiroshi Miura]

Here is a change proposal to address the issue.
https://github.com/omegat-org/omegat/pull/834

Is it works for you?

[Jean-Christophe Helary]

@miurahr9 It looks like the new behavior does not work with the standard issue checking workflow.

What I have now is this:

• OmegaT main windows covers my laptop screen (macOS)
• I use Tools > Display issues
• The issue window is on the forground but does not have the focus
• The OmegaT is in the background and has the focus

-> The issue window should have the focus

There are cases when a segment is modified and the issue windows automatically comes in the foreground in the same state as above (no focus).

I guess that calls for a reverting of what Manuel requested, or for a distinction between an "internal" call to the issues (what Manuel describes) and a manual call (what I describe here).

In any case, the current implementation should be considered a bug since it does not work with the manual call that most translators are going to do.

[Hiroshi Miura]

OmegaT main windows covers my laptop screen (macOS)
I use Tools > Display issues
The issue window is on the forground but does not have the focus
The OmegaT is in the background and has the focus

-> The issue window should have the focus

This is different from the bug report expectation.

The Issues window appears in the foreground
The Issues window is sent to the background, and the main window is in the foreground
A tag issue is created
The Issues window appears in the foreground again

When I've put a commit in topic branch

• Update IssuesPanelController to prevent stealing focus

• Updates the IssuesPanelController to prevent the issues window from automatically requesting focus.

• Changes include removing the frame.toFront() call on refreshData() while adding it only when necessary, for instance when an entry is selected.

You want to steal the main window focus by issue window even when no new issue is raised?

[Jean-Christophe Helary]

The bug report does not say that it expects the issue window to not have the focus.

Not having the focus is a regression.

[Hiroshi Miura]

I feel it is bothersome the issue window steals focus that prevent main window operation, that causes a reset of input method state,
Having the focus is a regression for me.

My issue window is placed on a right of main window.

I'd like to revert the commit because of unmatched in evaluation.

[Jean-Christophe Helary]

Having the focus is the original implementation. People are used to work like that.

Your issue window is placed where you want to place it. I work with the main window fullscreen and that new implementation makes me waste my time.

Because the issue widow does not have the focus I can't even dismiss it with ESC, for ex. I need to use the mouse to activate it.

As far as I tested, Thomas patch works very well and seems to also fix the bug that Manuel reported.

[Thomas CORDONNIER]

Hi JC

I just saw your comment in the dev list,
Can you please test this branch and tell if it is better:
https://github.com/t-cordonnier/omegat/tree/1225-setIssuesVisible

Manuel and Kos asked me to do this work some months ago, but before sending a pull request I answered like that:

You can find the patch here:
https://github.com/t-cordonnier/omegat/tree/1225-setIssuesVisible

The good news is that this part of the code did not change during the six last years, meaning that the patch can apply to any OmegaT release > 4.0

However, I see in the code that this behaviour was partially intentional. I think I understand why: sometimes the calculation if issues is a long thread in background, and you may not want to see the window suddenly coming back to front while in the meantime you went back to the editor and continued your translation work, simply because in the meantime it finished a work in background.
For that reason, before accepting the patch I invite you to do the test in a very big project and play with the "Options" menu which is in the issues window itself: the idea is that if you change an option, the system starts re-calculating the issues, then you go back to the editor and you don't want to see the window suddenly appearing while you are working. Or maybe you want it?
Also, do you want to see the window immediately after clicking "OK" button of the previous one, as it is actually, or only when the calculation is finished?

Waiting for your feedback

Since that I have no news so I think it is time to ask somebody else.

[Jean-Christophe Helary]

Ok, it looks like the "old" behavior is back. When the automatic check on leaving a segment is enabled, the issue window automatically comes to the forefront with the focus on and can be dismissed with Escape.

So, for the particular issue that I mentionned earlier, I guess I can say that it is fixed.

Thank you @t_cordonnier.

[Thomas CORDONNIER]

So, what would you say to @miurahr9? rollback and apply my patch or rollback only?

[Jean-Christophe Helary]

You tell me!

If Hiroshi and Kos implemented a new behavior that your patch fixes, then let's go with your patch.

The current master is a regression.

[Hiroshi Miura]

The change is reverted.

[Jean-Christophe Helary]

Sorry I missed that. I'll remove the message on GH. Thank you.

[Jean-Christophe Helary]

What about implementing the issues window as a pane ?

[Thomas CORDONNIER]

Calculating issues takes a while, that would strongly decrease performances if it has to be refreshed each time you change current segment (even if we only refresh the last changed segment)
In any case, that would be a distinct ticket, I would not do it as a correction for this one.

[msoutopico]

I have now tested feature https://github.com/t-cordonnier/omegat/tree/1225-setIssuesVisible. It seems to cut the mustard seamlessly, congrats @t_cordonnier!

The behaviour is as expected. Whenever the issues window is called, it comes to the front, regardless of whether it is not displayed or is hidden behind the main window (or another window).

I can see a difference in the behaviour, depending on how the issues dialog is called and what issues are found:

1. If the option "Check issues when leaving a segment" is ticked:

1a. When I leave a segment that has tag issues, the issues window is called and brought to the front with the tag issue(s) in that segment -- any other issues or tag issues in other segments are not flagged. This is convenient, as only the issues in that segment are relevant in this case.

Also, in this case:

• pressing Enter when the issues window is in the front returns to the segment with the tag issue flagged (and pressing Enter again brings the issues window to the front again, very convenient)
• press Escape when the issues window is in the front dismisses that window
    

1b. When I leave a segment that issues that are not tag issues, the issues window is not called.

It seems the option's wording ("Check issues when leaving a segment") is inaccurate. Instead, it should read "Check tag issues when leaving a segment".

2. If option "Do not allow creating translated documents with tag issues" is ticked:

2a. When creating target files with Ctrl+D, then the issues window is called and all issues are flagged (also terminology, spelling, LT), regardless of in which segment the issues are,

2b. When creating target files with Ctrl+D, then the issues window is not called if the issues in the project do not include tag issues.

In this case, the option's wording ("Do not allow creating translated documents with tag issues") seems fine.

3. Calling the issues dialog in Tools > Check issues: brings up the issues window in any case (even if there are no issues in the project -- in which case the window is empty).

I think this distinction is convenient, since it's really the tag issues that are critical and should "bother" the user if they leave the segment leaving issues behind. The other issues cannot compromise the integrity of the file, and therefore it's okay to leave it up to the user to check them explicitly.

Ready to merge!

[Jean-Christophe Helary]

@t_cordonnier @msoutopico Can you take care of the new option label ?

[Thomas CORDONNIER]

@brandelune After investigation, until release 5.7.1 included the text was
Validate tags when leaving a segment

Should we rollback to this?

[Jean-Christophe Helary]

I see.

Regarding 1b, I changed the label because I was convinced that the function was checking the issues and not only the tags. For ex, if I select to check the segment for LT errors before leaving the segment, OmegaT should do it.

I registered a bug here related to that:
https://sourceforge.net/p/omegat/bugs/1158/

The explanations were not sufficient in the bug report, but that's the problem I mentioned.

This function should check all the issues and not only the tag issues. Or at least offer a possibility to select the possible checks, like the standard check issues option.

So we should keep the label, and fix the bug.

Regarding 2b, we should have a similar system.

In fact, I wonder if the checks were not implemented when we only had tag checks, and then they were not updated to the new issues checking mechanism.

I don’t see a reason why specific checks should be limited to tags. They should cover what the user has set in the issues checklist. Otherwise that creates discrepency.

[Kos Ivantsov]

This function should check all the issues and not only the tag issues. Or at least offer a possibility to select the possible checks, like the standard check issues option.

If this option really checked for all (selected) issues, it would be slow and inefficient. I think the main purpose of both this option in the Editor section, and "Allow translated tags to be in a different order" + "Block the creation of translated files with tag issues" in the the Tag Processing section is to ensure the validity of target files. The option in the Editor section follows "Allow tag editing", and these two are connected. If it said "Check tags when leaving a segment", it would be logical and consistent.

Spelling errors, terminology inconsistencies or any errors found by the LanguageTool don't result in invalid files, but tag issues often do. If you preview your target files or process them otherwise in a near-realtime manner, it becomes crucial to have them valid at all times.

As a side note, checking for spelling errors, terminology mismatches or anything else language-specific is usually done as a separate task when the whole translation or a good chunk of it is complete (this is, of course, not an objective fact but my humble experience and observations of other translators and editors in work). I would personally hate if each time I leave a segment a window would pop up showing me an error that a comma is possibly missing or a term found in glossary is not used in target when all I needed was to know if tags are OK.

[Jean-Christophe Helary]

That's exactly the reason why we have a checkbox list in the issues checking process. Users are smart enough to change what they check depending on their workflow.

[Kos Ivantsov]

It would still be very helpful it the user choices were temporarily disabled when Check Issues is triggered by the tag validation when leaving a segment or when creating target documents.

If all issues need to be checked when leaving a segment, then the Check Issues function needs to have another scope: current segment (three scopes altogether: entire project, current document, current segment), and that one-segment scope should be used.

Tag validation triggered during file generations shouldn't include anything else. Tags are critical for files validity, everything else is not. Maybe other user-selected options in the Check Issues could be kept but disabled in this case?

[Jean-Christophe Helary]

Ok, since we’re working on the 6.0.1 bugfix, I guess that label can be considered a bug. So yes, reverting that string is in order.

@kosivantsov, sorry for the discussion below. Let’s work on a reasonable implementation of checks after 6.0.1 is released.

@msoutopico, did you identifiy other strings to revert?