- Set the software as `initialized` later, and in particular after all
recovered images (from crash) then all command line images were
opened. The reason is that the DBus calls have necessarily been made
after GIMP was started (typically could be images double-clicked
through GUI). We don't want them to appear before the images given in
command line (or worse, some before and some after).
- Process DBus service's data queue as a FIFO. The image requested first
will be loaded first.
- When a DBus call happens while GIMP is not initialized or restored,
switch to a timeout handler. The problem with idle handlers is that
they would be attempted too often (probably even more during startup
when no user event happens). This is good for actions we want to
happen reasonably quickly (like would be normally DBus calls), but not
when we are unsure of program availability schedule (i.e. at startup).
Here not only the handler would run a lot uselessly but it would
likely even slow the startup down by doing so. So while GIMP is not
initialized, switch to half-a-second timeout handler, then only switch
back to idle handler when we are properly initialized and GIMP is
ready to answer calls in a timely manner.
… DBus calls.
In particular, Aryeom would start GIMP and directly double click some
image to be loaded in GIMP in the very short while when splash is
visible. Previous code would wait for the `restored` flag to be TRUE.
This was nearly it as we can actually start loading images as soon as
the 'restore' signal has passed. Yet the flag is set in the main
handler, but we actually also need the <Image> UI manager to exist,
which is created in gui_restore_after_callback() (so also a 'restore'
handler, yet after the main signal handler, i.e. after `restored` is set
to TRUE). Without this, gui_display_create() would fail with a CRITICAL,
hence file_open_with_proc_and_display() as well.
I could have tried to set the `restored` flag later, maybe with some
clever signal handling trick (and handle both the GUI and non-GUI cases,
i.e. I cannot set the flag inside gui_restore_after_callback() as it
would break the non-GUI cases). Instead I go for a simpler logics with a
new `initialized` flag which is only meant to be set once, once
everything has been loaded, i.e. once you can consider GIMP to be fully
running hence ready to process any common runtime command.
Drop the glib-dbus dependency and port stuff to GDBus. Use it
unconditionally if not on Windows or OSX. It seels to work just like
before but I have no idea if everything is really correct.
create a dummy indexed format if neccessary, which can only be used
for checking with babl_format_is_palette(). Port the rest of
GimpImageFile from GimpImageType to Babl*.
2009-01-17 Michael Natterer <mitch@gimp.org>
* all files with a GPL header and all COPYING files:
Change licence to GPLv3 (and to LGPLv3 for libgimp).
Cleaned up some copyright headers and regenerated the parsers in
the ImageMap plugin.
svn path=/trunk/; revision=27913
2008-10-17 Sven Neumann <sven@sven>
* app/core/gimp.[ch]: added signal Gimp::image-opened to
announce
that an image has been loaded and a display was created for it.
* app/file/file-open.c (file_open_with_proc_and_display): call
gimp_opened() to emit the new signal.
* app/gui/dbus-service.xml
* app/gui/gimpdbusservice.[ch]: propagate the 'opened' signal to
listeners of the "org.gimp.GIMP.UI" DBus service.
* app/gui/gui-unique.c: formatting.
svn path=/trunk/; revision=27297
2008-09-25 Sven Neumann <sven@gimp.org>
* app/core/gimp.[ch]: added a 'restored' flag to the Gimp object
and set it in gimp_real_restore(). Added method
gimp_is_restored().
* app/gui/gui.c: call gui_unique_init() in gui_init() instead of
that later in gui_restore_after_callback(). By doing so we start
our DBus service (or message proxy window on Win32) much earlier
in the start process, thus reducing the time frame where two
instances of gimp can be launched.
* app/gui/gui-unique.c
* app/gui/gimpdbusservice.c: wait handling the queued file-open
requests until gimp is fully restored.
* app/gui/splash.c (splash_update): only run one iteration of
the
main loop. Doing it in a while loop can cause us to get stuck if
the gimp-unique service already added an idle handler.
svn path=/trunk/; revision=27049
2008-08-05 Sven Neumann <sven@gimp.org>
* app/gui/gimpdbusservice.[ch]: changed refcounting and fixed a
bug that I had introduced with the latest changes.
svn path=/trunk/; revision=26391
2008-08-05 Sven Neumann <sven@gimp.org>
* app/gui/gimpdbusservice.[ch]: keep a queue of D-Bus requests
and
work on them one after another instead of handling them all in
parallel. Complements the fix for bug #546426.
svn path=/trunk/; revision=26386
2008-08-05 Sven Neumann <sven@gimp.org>
* app/gui/gimpdbusservice.c: open the files from an idle
handler.
Opening a file may take a while (in particular if it involves
asking the user for input) and we need to respond to the D-Bus
call before it times out.
svn path=/trunk/; revision=26370
2008-07-13 Sven Neumann <sven@gimp.org>
* app/widgets/Makefile.am
* app/widgets/gimpdbusservice.[ch]
* app/widgets/dbus-service.xml: removed here ...
* app/gui/Makefile.am
* app/gui/gimpdbusservice.[ch]
* app/gui/dbus-service.xml: ... and moved here.
(gimp_dbus_service_activate): raise the first display instead of
the toolbox.
* app/gui/gui-unique.c (gui_unique_win32_idle_open): same change
here, raise the display instead of the toolbox.
* app/unique.c: changed accordingly.
svn path=/trunk/; revision=26184
Jehan