Hide Forgot
Description of problem: When I first start up openoffice.org, it's quite rude. :) There are a couple of usability issues that occur during start-up: 1) The splash screen in the center of my desktop blocks me from getting any work done until the 30+ seconds required to start openoffice.org pass. :-p 2) Even if the splash screen wasn't blocking the center of my desktop, I still wouldn't be able to get any work done because as openoffice.org loads it constantly steals focus so it always blocks any other windows I try to work in. The most concerning issue for me is the focus-stealing; it's rather irritating. Should I file this as a bug upstream? Or is there anything that can be done about the splash & focus stealing based on how it's built for Fedora? I know other distros customize the splash screens, for example, so this is why I decided to file here first. Version-Release number of selected component (if applicable): openoffice.org-core-3.1.0-11.3.fc11.x86_64 openoffice.org-writer-3.1.0-11.3.fc11.x86_64 How reproducible: Very Steps to Reproduce: 1. launch an openoffice.org app (e.g. openoffice.org writer) 2. watch splash screen take over your screen 3. try to use other windows on the desktop in futility :) Thanks!
Nothing special about our splashscreen, its stock. What's the window manager you're using ? I've fixed this particular problem about 8 or 9 times, but the catch is that nearly all windows managers are stuffed full of brokenness so it makes it way back in again in order to not do something awesomely useless under xfce/metacity/compiz or some other window manager.
Hi Caolan! I'm using metacity & GNOME in F11. I haven't done any customization of metacity either; I'm using the default metacity theme etc - besides my wallpaper I haven't really customized anything differently than F11 desktop spin's stock settings. What do you think?
Created attachment 358050 [details] screencast Not really seeing a major problem myself. e.g. in this demo both OOo and gimp are launched from nautilus. Both whack up the slashscreen, in both cases in the demo I've clicked on nautilus immediately after the slash appears and it goes into the bg leaving me able to interact with the nautilus fg window while it continues to load. In both cases as soon as the final toplevel window appears it gains focus. That's pretty much the way I'd expect it to work I feel. We definitely don't want OOo to pop into the fg 10 times during e.g. the load of a big document, but checking a big writer document here OOo gets focus when the toplevel window that's loading the document first appears, but I can place it into the bg and it stays there during and after the document load without popping in the fg constantly during the process. As you can see from these screencasts though OOo loads pretty fast for me so I might be missing something here. Or maybe I'm just too close to things to see the obvious, or maybe its one particular application or circumstance that causes the particular misery you've got.
Hi Caolan, I looked at your screencast but I didn't see the OO.o splash pop up at all in it. I think the ideal behavior is that you try to open up a document, go about your business, and the document pops up and comes to focus when it's done. I think that makes sense and that's what seemed to happen in your screencast. I've run through it again a few times and it looks like OO.o interrupted what I was doing 4 times; what I did not really before is half the interrupts are from the 'recovery' dialog. Here's exactly what I did: - Open up evolution. Receive email with OO.o slide set. From evolution, click on slideset to open. - Splashscreen for OO.o pops up in middle of screen, blocks email, click on evolution to continue reading email but you can't because the splash blocks it. Click on splash and it does not go away. (interrupt 1) - Recovery dialog for OO.o pops up and steals focus. Click start recovery (interrupt 2) - Recovery failed since the files are from almost a year ago, another popup appears and steals focus. Click whatever button you have to click to ask it to continue open up the doc you were really interested in anyway. (interrupt 3) - Document finally loads, stealing focus and covering up my email full screen. (interrupt 4). With the slide deck I tried just now, there was a very perceptible slowness in between each the steps, much more perceptible than yours. The splash screen was up for maybe 5 seconds and very noticeable. Some differences I can think of is that I'm opening a slide deck from an email that was sent to me some time ago, from the imap server. It hadn't been copied locally to /tmp when I went to open it. The files you were working with in your screencast were local and on your HDD already. Since the recovery dialog has been cleared, there's two interrupts - the splash screen and the document itself. It seems reasonable for the document to pop up over other things when it's ready, but the splash screen behaves badly (and this is the case for the gimp too): if I'm reading my email and want to open the slide deck in the background to review when I'm done with the email... the splash screen makes this difficult, because I cannot simply click the email (or any other window) open behind it to bring it to the front. Instead, I must either click the titlebar of the window open behind it (difficult to target) or I must minimize the window open behind it and re-unminimize it so it'll go on top of the splash. Clicking the splash (again a problem with the gimp as well) does not dismiss it either. Do you think it would be reasonable to file two upstream bugs, maybe one about the clunkiness of the recovery dialog (I've suffered with that thing popping up every time until now because I thought clicking on the cancel button would cancel the opening of OO.o - not that I use OO.o tha toften), and one about making the splash screen a little friendlier? (click to dismiss, allow other windows to be clicked to focus from under it?) What do you think? Am I just making a big deal out of nothing?
(oh an p.s., I think the gimp splash screen doesn't bug me nearly as much because I've usually got it open already and do not encounter it very often. OO.o, when I open a document, is most usually not open already so I always get the splash.)
Aha, recovery dialog. Well that's (in theory) something that very rarely happens and its basically your chance to recover very-important-document-you-spent-a-week-writing so I'd prefer to just put that one aside as coming to the foreground to yell at user is not necessarily a bad thing from that pov. Otherwise, yeah, two interrupts, splash-screen and loaded-document. I did remove a stack of other "intermediate" foreground switches for 3.1 (http://qa.openoffice.org/issues/show_bug.cgi?id=93515), so two interrupts should be the state of the art alright. I get a splashscreen too, its just that my load speeds are massively lower than yours seeing as I'm always launching OOo so it probably flashed by too fast to be captured by istanbul. Yeah, click to dismiss splashscreen sounds like the way to go here. And changing "Cancel" to "Cancel Recovery" in the recovery dialog.
rats, we don't have a main loop during the splashscreen time so can't add click/key callbacks as there's nothing there to deliver them. Which makes as a prerequisite the proposed standalone splashscreen "app" which communicates by pipe to the main process to get told to "go-away". In that case the splashscreen has a main loop and can be dismissed by a click.
Caolan, is it a window manager bug that clicking to focus on windows behind the splashscreen doesn't work? That would probably address the issue just as well if not better than click-to-dismiss on the splash itself would.
Almost certainly. FWIW using F-11 compiz clicking on a window while the OOo splash is showing brings evo to the fore as expected, while instead using metacity, then clicking in the window that had focus before the splash appeared does nothing, but clicking on another brings that to the fore. So, in metacity, clicking on the splash (or any window really, but the splash is obviously most accessible) and *then* clicking on the original foreground window will bring it to the fore. At least does for me.
Attached impl to upstream OOo issue to change dialog. Its a string change so can't backport to OOo as translations would be broken. Filed standalone testcase bug against metacity about inconsistent (vs compiz) regain foreground window issue. Click-on-splashscreen to disappear would come with the standalone splashsceen app which is underway upstream (if somewhat stalled).