GNOME Bugzilla – Bug 721184
Startup: at all times offer a way to abort gimp during startup
Last modified: 2018-05-24 14:14:33 UTC
During startup, there is no obvious way for the user to kill gimp. It goes happily adding its plugins at the same time offering no [X] or anything to stop it. The only chance the user gets is when finally all windows are in place and he can do a ^Q etc. A browser might be invoking gimp, so one can't always use ^C.
Do any other apps implement this?
I think ever other app from birth lives in its final standard sized window with the [X] always there at the upper right.
There are a few others that have a splash screen (for example, LibreOffice). IIRC none of those implements this, but I could be mistaken. So your suggestion is that GIMP should show its interface as soon as possible?
To provide a proper solution and do the task right we should better identify the actual need behind this wish. As far as I understood jidanni is annoyed by the long startup time and the missing possibility to cancel this progress, right? The problem of a very long startup time is known and also reported in various bugs. There are some points how this could be improved, i.e. with cancel or skip buttons, lazy initialization etc. Restricting ourselves to just one arbitrary solution doesn't IMHO solve the problem as it deserves. If the need is really just an opportunity to cancel GIMP as early as possible we should better handle the bug as enhancement request. Either way I propose to discuss this first at the GIMP developer mailing list.
I have no opinions about starting times. I was just frustrated that there was no way to tell it to abort. How about making it listen for CTRL-Q even during its splash screen phase? (Best would be a little [X/cancel] in the upper right too.) Hmmm, libreoffice has the same problem, but its screen seems so fast one wouldn't have time to hit the CTRL-Q anyway...
Hi, I think that's a very minor issue, but I get what jidanni is asking for, and I personally don't see any big problem in allowing users to close GIMP at startup time. Why not? I could indeed imagine that it can be useful when GIMP gets started by mistake (using a file browser and GIMP as default program for various image formats) on OSes where the startup is long. This said, I would not bother for a UI widget (a [X] or whatever), for the simple reason that normally the startup should not be that long. The real fix will be that GIMP startup should be sped up a lot under Windows (jidanni, I guess you use Windows, don't you?). When I read sometimes that GIMP startup would take minutes on Windows, that's the real issue. I just tested GIMP master on my Linux. It took about 2 seconds (I barely see the splash screen and would have no time to interact with it if it had a close button). So listening to ctrl-q (or whatever other shortcut set by the user) should be enough in my opinion.
> The real fix will be that GIMP startup should be sped up a lot under Windows [...] > When I read sometimes that GIMP startup would take minutes on Windows, that's the real issue. Indeed, compared to Linux and OS X GIMP starts a bit slower on Windows (at least on my systems). However, I would go further and check how we can solve it more generally, because the topic is wider: - GIMP is slow on *every* first start - after each single update and on each platform. We should reconsider whether it's necessary to load all of the resources because the least people will need all assets and features everytime. So we could for instance load only recently used resources or a small default set of resources during startup and the rest silently in the background while the user can already work. - On OS X switching to another window while GIMP starts makes it impossible to switch back to the GIMP startup window. Although one can see GIMP active in the dock the GIMP windows doesn't appear anymore in the Expose view until startup is finished. Making it responding to window manager events would be a win here. Otherwise pressing a Cancel shortcut like Ctrl+Q would clearly hit the wrong program - with undefined and surprising results.
(In reply to comment #6) > jidanni, I guess you use Windows, don't you? $ uname -a Linux jidanni5 3.13-1-686-pae #1 SMP Debian 3.13.6-1 (2014-03-19) i686 GNU/Linux $ apt-cache policy gimp gimp: Installed: 2.8.6-1 Candidate: 2.8.6-1 Version table: *** 2.8.6-1 0 500 http://ftp.br.debian.org/debian/ unstable/main i386 Packages 100 /var/lib/dpkg/status
Dan > Hum... so you are on Linux and still have slow boot problem? I just tested both gimp-2-8 and master branches. They both take like 2 or 3 seconds to launch. How long does it take in your case? Or maybe I don't get why you absolutely feel the need to be able to cancel the startup... Sven > Yes the whole startup process would really gain from being rethought. Though honestly I am not that worried about the first startup being that long. On Linux at least, it is still very reasonable (a little more than 5 secs, I'd say), and especially it happens only once. If that were every time like this, that's too much, but once... But of course, even faster is better. :-) And even more obvious, the Windows one should be sped up to match Linux GIMP.
The user might be using an older or busy/loaded system.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/522.