There's a couple of places where we do menu_launch_type in KDE
without doing this workaround first, and they do run into the
bug sometimes. Let's factor it out from the few places it's
already repeated, and add it to the places it is missing.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This test is failing a lot recently on KDE because when we try
to launch konsole immediately after returning from a console to
the desktop, it is mistyped and we get a browser instead. Let's
try a little sleep after the switch back in case KDE just needs
to settle down a bit.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It seems like in current Rawhide (since about Saturday - possibly
due to new mesa?), g-t-e quite often dies after we print. This
messes up the test because we wind up quitting the terminal
instead of g-t-e. Let's handle it as a soft failure instead,
until we can figure out why g-t-e is dying.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
desktop_printing is failing a lot in recent Rawhide (and so are
some other tests, but this one is nice and easy to target). Add
some wait_still_screens and save_screenshots to try and see
exactly what's going on when we exit gnome-text-editor before
switching to a VT.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2 seconds isn't enough to be sure it opened, which is causing
some weird failures in KDE Rawhide update tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Seeing a failure quite often lately where when we try and hit
ctrl-p to print, we just type a p. There's no wait between
maximizing and trying to print, and only a short wait on
launch, so let's try being a bit more defensive there.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
script_output has no arg to make it type slowly, and I'm seeing
that the test often fails trying to do full-speed script_output
at a desktop terminal. Let's do this part from a VT.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
When the printing_builtin test ran on an F35 respin compose it
failed; it turns out the target filename was different for the
built-in print-to-PDF on GNOME on F35. So let's just always
use the 'ls' output to find the file, but pick the directory
to check based on whether we're using cups or not.
Also rename the needles to have unique names, and add one for
F35 GNOME.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The PR introduces an improved logic to the desktop_printing.pm
that allows to use the USE_CUPS variable in templates to trigger
the installation of cups-pdf prior to the actual test.
The cups-pdf is then used as an alternative PDF printer
instead the built-in Save As PDF method.
Remove a whole chunk of needles that haven't matched for more
than 3 months. Also move a few needles to appropriate locations,
simplify some code chunks that relied on removed needles (if
we're not matching the needles, we don't need those chunks any
more), and drop some other no-longer-needed conditionals for
older releases.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
A recent cups-pdf build changed the default filename for files
output by cups-pdf. We need to have the test look for the
correct filename based on the cups-pdf version.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In F34+, print-to-PDF in KDE is printing to /home/test , not
/home/test/Desktop. Not sure why. But let's deal with it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We're getting issues with KDE's crazy-slow alt-f2 behaviour
here. So try and be even more conservative.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
