Use QProcess instead of subprocess, add log area

[thrimbor]

This has been lying around for a while. It adds a log area where xqemu output is displayed, a message that is displayed if xqemu quits with a non-zero return value, and generally improves keeping track of the subprocess.

/edit:

Screenshot after starting & stopping xqemu:

Screenshot after xqemu exiting with a non-zero return value (note that the Start/Stop button was updated correctly when xqemu quit):

[JayFoxRox]

Looks great! I have tried this now and got some feedback:

(All points in this comment have been addressed since then)

• Is there an unused status-bar at the bottom of the Window? The distance of the log to the bottom of the window would suggest it, which is a bit confusing. Yes, separate issue
• The log window is empty and unlabeled at XQEMU-Manager startup; this is potentially confusing for new users. It should be labeled as "XQEMU Messages" or something. Done.
• When restarting XQEMU, the log window is not cleared. This makes it harder to see new messages. Fixed.
• The log in my terminal looks like this:

  dsp_init
  dsp_init
  gloffscreen: GLX_VERSION = 1.4
  gloffscreen: GLX_VENDOR = Mesa Project and SGI
  ac97: invalid bm_index(3) in voice_set_active
  ac97: invalid bm_index(3) in voice_set_active
  ac97: invalid bm_index(3) in voice_set_active
  ac97: invalid bm_index(3) in voice_set_active
  ac97: invalid bm_index(3) in voice_set_active
  ac97: invalid bm_index(3) in voice_set_active
  ac97: invalid bm_index(3) in voice_set_active
  ac97: invalid bm_index(3) in voice_set_active
  ac97: invalid bm_index(3) in voice_set_active
  ac97: invalid bm_index(3) in voice_set_active
  

  The equivalent log in XQEMU-Manager looks weird (contains empty lines): Fixed, looks fine now.

  dsp_init
  dsp_init
  gloffscreen: GLX_VERSION = 1.4
  gloffscreen: GLX_VENDOR = Mesa Project and SGI
  
  ac97: invalid bm_index(3) in voice_set_active
  ac97: invalid bm_index(3) in voice_set_active
  ac97: invalid bm_index(3) in voice_set_active
  ac97: invalid bm_index(3) in voice_set_active
  
  ac97: invalid bm_index(3) in voice_set_active
  ac97: invalid bm_index(3) in voice_set_active
  
  ac97: invalid bm_index(3) in voice_set_active
  
  ac97: invalid bm_index(3) in voice_set_active
  
  ac97: invalid bm_index(3) in voice_set_active
  
  ac97: invalid bm_index(3) in voice_set_active
  
  

[thrimbor]

* Is there an unused status-bar at the bottom of the Window? The distance of the log to the bottom of the window would suggest it, which is a bit confusing.

There is. I'm not sure whether it's required in order to have that little triangle thing that helps you resize the window.

* The log window is empty and unlabeled at XQEMU-Manager startup; this is potentially confusing for new users. It should be labeled as "XQEMU Messages" or something.

I added a label above it now.

* When restarting XQEMU, the log window is not cleared. This makes it harder to see new messages.

Fixed.

* The equivalent log in XQEMU-Manager looks weird (contains empty lines):

Ah, I didn't notice that appendPlaintext always adds a newline - I replaced it with insertPlainText and moveCursor, which fixes this.

/edit:
Updated screenshot:

[JayFoxRox]

According to docs, this adds text at current cursor position. Would a user selecting text mean that text is added in wrong location?

[thrimbor]

You're correct (just confirmed it by testing). The recommendation where I took that from actually set the cursor before and after, so I changed the code to do that as well. It has the downside of resetting a selection the user made whenever log output is added, but it seems like this is the only way how the additional whitespaces can be avoided.

[JayFoxRox]

I'm sure there's a better way. We should create an issue after merge, so we can improve this later.

[JayFoxRox]

nit: Somehow this also doesn't scroll all the way to the bottom. There appear to be 2 blank lines at the end.

[mborgerson]

Thanks!

In terms of the UI, I think having a general log window on the main screen may be unnecessary. Generally, I think "no news is good news" and the user should not be presented with these details until an error occurs. What I had in mind was moving this log window to the error dialog, and providing a button there for the user to "copy to clipboard," or something to that effect.

That said, this is an improvement over what we have now and we can refine the UX going forward. I think it's ready to merge, but I'll let @JayFoxRox merge it once he feels his nits are addressed.

[JayFoxRox]

In terms of the UI, I think having a general log window on the main screen may be unnecessary. Generally, I think "no news is good news" and the user should not be presented with these details until an error occurs.

Agreed.

What I had in mind was moving this log window to the error dialog, and providing a button there for the user to "copy to clipboard," or something to that effect.

I think we should have something like MSVS error list (but much simpler), in a separate window:

So, a list with each log entry, icons would show wether it's a note (stdout), a warning (stderr) or error (crash/exit error message). Anyhow we can iteratively improve this.

I'll let @JayFoxRox merge it once he feels his nits are addressed.

I don't care about the nits (as they also add risk of another review pass); I'll merge and move nits into issues.