Sun Jan 10 23:31:45 GMT 1999 Adam D. Moss <adam@gimp.org>
* app/blend.c app/bucket_fill.c app/convert.c app/crop.c
app/cursorutil.c app/cursorutil.h app/fuzzy_select.c
app/gdisplay.c app/gdisplay.h app/gimage_cmds.c
app/gimpimage.c app/transform_core.c app/xcf.c:
Most lengthy UI-blocking operations now put up an
hourglass so the user can see that GIMP is working.
Let me know if there are other vital cases.
Sat Dec 5 21:31:57 GMT 1998 Austin Donnelly <austin@greenend.org.uk>
* app/commands.[ch]
* app/edit_selection.c
* app/gdisplay.[ch]
* app/gdisplay_ops.[ch]
* app/image_render.c
* app/info_window.c
* app/magnify.c
* app/menus.c
* app/scale.c: image rendering now happens with float scale
factors, independent in X and Y axes. Turning on dot-for-dot in view
menu does what gimp always used to do (ie one image pixel becomes
one monitor pixel). Dot-for-dot is on by default so people
shouldn't notice any difference unless they load an image that's
not at 72 dpi and also turn off dot-for-dot.
* app/app_procs.c
* app/gimprc.[ch]
* app/preferences_dialog.c: new gimprc options
(monitor-xresolution <float>) and corresponding
(monitor-yresolution <float>). Uglyness in preferences dialog to
add a "Monitor" page to the notebook, allowing user to set their
monitor's resolution or take it from the X server instead. This
badly needs cleaned up :(
* plug-ins/newsprint/newsprint.c: oops - this hasn't been working
for grayscale images since my last checkin. Now fixed.
I still don't know why those statusbar is sometimes not updated. The labels
are definitely set, but are sometimes not drawn. I guess this is a GTK
problem.
--Sven
Sat Oct 3 21:01:34 BST 1998 Adam D. Moss <adam@gimp.org>
* app/channel.c app/channel_ops.c app/disp_callbacks.c
app/floating_sel.c app/gdisplay.c app/gdisplay.h
app/gdisplay_ops.c app/gimpimage.c app/image_map.c
app/interface.c app/layers_dialog.c app/plug_in.c app/undo.c
app/xcf.c:
Resizing image canvases should be less horrible to look at.
I've removed the implicit clear of the whole area when a
window is resized by the user, and clear the exposed area around
the image manually when appropriate.
Dialogs which want synchronous updates for previews and
such use displays_update_now().
Removed some old debugging nonsense which I don't want any more.
Thu Oct 1 17:10:32 BST 1998 Adam D. Moss <adam@gimp.org>
* app/gdisplay.c app/gdisplay.h: Okay, that didn't
take quite as long as expected. This is the first cut at
a gimp-wide IdleRender in place of the previously synchronous
displays_update(). A synchronous displays_update_now() is
implemented for stuff like brushes, but it isn't used right
now. (Seems to go pretty well without.)
I need feedback and (previously nonexistant!) bug reports...
please. =)
Thu Oct 1 12:44:19 BST 1998 Adam D. Moss <adam@gimp.org>
* app/floating_sel.c app/gdisplay.c app/gdisplay.h
app/gimpimage.c app/layers_dialog.c app/undo.c:
Temporarily disabled IdleRender code whilst working
on a more centralised approach.
Sat Sep 26 20:46:18 BST 1998 Adam D. Moss <adam@gimp.org>
* app/channel.c app/channel_ops.c app/drawable.c
app/floating_sel.c app/gdisplay.c app/gdisplay.h
app/gimpimage.c app/layers_dialog.c app/undo.c:
Moved the idlerender stuff into gdisplay.c. Implemented
idlerender when doing floating_sel->layer, and undoing/redoing
layer deletion.
idlerender would be useful in many other places for improving
interactivity, if it weren't for the following problems:
* By definition, idlerender doesn't wait for a
gdisplays_update() call before starting work - it just
runs in idle time, which due to CPU contention with
plugins may not be genuinely available idle time when
things are 'noninteractive'.
* Most GIMP functions don't know whether they're
being run interactively or not. idlerender only
makes sense for interactive work. This is why
it is currently only applied to those functions which
would normally only be activated manually.
* Mixing idlerender and drawable_update() /
gdisplays_update_area() calls can lead to a region
being rerendered twice.
Hence, some slogwork is needed before idlerender can be
applied in the more general case.
Wed Jul 15 22:06:32 CDT 1998 Shawn T. Amundson <amundson@gimp.org>
* Cursor location in statusbar
* Fixed resize of window
* progressbar is smaller now
* app/gdisplay.h
* app/interface.c
* app/plug_in.c: Added the ability to cancel a running
plugin when the progress-bar has been sucked into the image
window.
* plug-ins/psd/psd.c: Turned debugging on again, since we
are in a development cycle...
Sun Jun 14 21:16:42 CDT 1998 Shawn T. Amundson <amundson@gimp.org>
* app/gdisplay.c
* app/gdisplay.h
* app/interface.c
* app/plug_in.c
* app/plug_in.h
* libgimp/gimp.c: added statusbar and progressbar, which
the plugins now use if they have a gdisp. Unfortunately
this introduces a resize bug I wasn't able to fix
immediately. ;-(
Fri Jun 5 22:37:40 1998 Owen Taylor <otaylor@gtk.org>
* app/Makefile.am app/app_procs.c app/brushes.c app/commands.[ch]
app/disp_callbacks.c app/gdisplay.[ch] app/gimprc.c
app/interface.[ch] app/menus.c app/paint_core.[ch]
app/paintbrush.c app/palette.c app/scroll.c
app/tools.[ch] app/undo.c
- Added two new dialogs - input devices; (GtkInputDialog)
and DeviceStatus - which shows the tool/color for
each device.
- Added device_status_update() call that gets called
whenever the tool/color etc. are changed.
- Added ~/.gimp/devicerc file to store settings
- Code to draw cursor on canvas for non XFree86 XInput
where device can't control cursor and extended input
device simultaneously.
- Changed input handling so that we always use the pointer
position from the device, not from gdk_input_window_get_cursor,
so that motion and cursor position sync.
- Various changes so things work with non-integer coordinates
- Pay attention to pressure and tilt in basic tool support.
- New paint mode PRESSURE that changes the brush based on
the brush pressure
- Left in a few XInput hacks that should be removed, but I no longer
remember what they are.
Manish Singh