53f7005ca6
2002-01-24 Tor Lillqvist <tml@iki.fi> Committing now to get a huge amount of changes checked in. There might be some silly debugging printouts left, or stuff like that. But everything does seem to work as well as before. Much cleanup and refactoring still do to. * gdk/gdkprivate.h: There is no gdk_debug_level variable. * gdk/gdkimage.h (enum GdkImageType): Remove GDK_IMAGE_SHARED_PIXMAP. Was used by the long abandoned gdk-imlib port. * gdk/gdk.def * gdk/win32/gdkimage-win32.c * gdk/win32/gdkpixmap-win32.c: Remove gdk_image_bitmap_new() and gdk_pixmap_create_on_shared_image() which also were used only by the gdk-imlib port. * gdk/win32/gdkcursor-win32.c (gdk_cursor_new_from_pixmap): Add verbose debugging output of the source and mask images. * gtk/Makefile.am: Let gtk-win32res.lo depend on gtk.def and the libgtk_la_OBJECTS. * gtk/gtk.def: Export the private (but still used by some apps) _gtk_private_signals and _gtk_private_n_signals. Re-sort the file. * gtk/gtkfilesel.c: Silence some gcc -Wall warnings. * gtk/gtkmain.c: If we HAVE_BIND_TEXTDOMAIN_CODESET, tell libintl to use UTF-8. 2002-01-22 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkgc-win32.c (gdk_colormap_color): For (single-bit depth) bitmaps (recognized by having a null colormap), use DIBINDEX. * gdk/win32/*.c: Always use format %p instead of %#x in debugging output of GDI HANDLEs. 2002-01-21 Tor Lillqvist <tml@iki.fi> Big cleanups and fixes to 256-colour mode: Too many changes to list here in detail, partial list below. All GIMP features now seem to work as previously in 16- and 32-bit colour mode, plus also in 256-colour mode. The Win32 pixmap and image code is still very ugly. Lots of duplicated code snippets that create DIB sections, select and realize palettes, etc. Now when I finally got 256-colour mode working, I really need to go through the code and factorize out such common snippets. Probably it would be a good idea to keep the pointer to the DIB section's pixels also for GdkPixmaps, and not just GdkImages (where it of course is visible to the application, even). Maybe even have a GdkImage struct as such as a part of the private data for Win32 GdkPixmaps? Having the pixel data accessible would simplify gdk_win32_bitmap_to_region() a lot. Perhaps gdk_image_get() and _put() between pixmaps and images, too, and maybe even gdk_win32_draw_drawable(). We could skip all the HDC and palette setup and the BitBlt, and just copy the bits ourselves. Hmm. It might seem silly to roll your own BitBlt, but if we did that, we wouldn't have to bother about HDCs and palettes at all when blitting between bitmaps (pixmaps and/or images). OTOH, when blitting to/from a window, we still would need the palette setup. Maybe just some nice refactoring. * gdk/win32/gdkprivate-win32.h: Remove definitions of the X11 structs ColormapStruct, Visual and XStandardColormap. (GdkGCWin32Data): Add field holdpal to hold the previous palette selected into the DC. (GdkVisualPrivate): No need for a poiner to an X11 Visual emulating struct. (GdkWin32PalEntryState): New enum, describing the state of logical palette entries: static (the 20 static colours), available or in use. (GdkColormapPrivateWin32): Instead of the X11 emulation Colormap struct pointer, store the Windows logical palette HPALETTE directly here, plus its current size and the state of its entries. * gdk/win32/gdkcc-win32.c: Don't use the removed XStandardColormap or Visual structs. * gdk/win32/gdkcolor-win32.c: Rename static functions to shorter names. Add much debugging output. (create_colormap): As we implement both "shared" and "private" colormaps identically on Win32, always allocate a Windows logical palette containing the (presumably 20) static colours from the system palette, marked as such. (gdk_win32_print_paletteentries, gdk_win32_print_system_palette, gdk_win32_print_hpalette): New debugging functions. (gdk_colormap_free_colors): Instead of keeping two essentially identical functions "in sync" (this and gdk_colors_free()), build a table of the pixel values and call gdk_colors_free from here... * gdk/win32/gdkdrawable-win32.c (gdk_win32_draw_drawable): In 256-colour mode, when blitting from a window, select and realize palette. * gdk/win32/gdkevents-win32.c (update_colors): New function. Call UpdateColors() on a window and all its descendants. (synthesize_expose_events_children): New function: Synthesize expose events for a window and all its descendants, in order to realize our palettes and redraw everything. (gdk_event_translate): Handle WM_QUERYNEWPALETTE: Call synthesize_expose_events_children(). Handle WM_PALETTECHANGED: Call update_colors(), or if we have done that three times already (a randomly chosen limit), generate expose events. * gdk/win32/gdkwindow-win32.c (gdk_window_get_children): Implement, using EnumChildWindows(). 2002-01-21 Tor Lillqvist <tml@iki.fi> * gdk/gdkprivate.h: Add new flags to GdkDebugFlag: GDK_DEBUG_COLORMAP, GDKRGB, GC, PIXMAP, IMAGE, INPUT and CURSOR. * gdk/gdk.c: Handle them. (gdk_init_check): Check also for '/'-delimited argv[0]. * gdk/gdkrgb.c: Indentation fixups. Add some logging messages using GDK_NOTE (GDKRGB, ...). Seg gdk_rgb_verbose if GDK_DEBUG_GDKRGB is turned on. * gdk/win32/gdkcursor-win32.c * gdk/win32/gdkgc-win32.c * gdk/win32/gdkinput-win32.c * gdk/win32/gdkimage-win32.c * gdk/win32/gdkpixmap-win32.c: Use the new flags instead of MISC. 2002-01-13 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkgc-win32.c (get_bw_palette): New function, factored out from: (predraw_set_foreground, BitmapToRegion): Use it. * gtk/Makefile.am (gtk-win32res.lo): Depend on gtk.def and libgtk_la_OBJECTS. * gtk/gtk.def: Add _gtk_private_signals and _gtk_private_n_signals to really export them. Some applications apparently use these private variables.
General Information =================== This is GTK+ version 1.3.0. GTK+, which stands for the Gimp ToolKit, is a library for creating graphical user interfaces for the X Window System. It is designed to be small, efficient, and flexible. GTK+ is written in C with a very object-oriented approach. The official ftp site is: ftp://ftp.gtk.org/pub/gtk The official web site is: http://www.gtk.org/ A mailing list is located at: gtk-list@redhat.com To subscribe: mail -s subscribe gtk-list-request@redhat.com < /dev/null (Send mail to gtk-list-request@redhat.com with the subject "subscribe") Installation ============ This is the gtk-1-3-win32-production branch, intended only for Windows. See README.win32. How to report bugs ================== Bugs should be reported to the GNOME bug tracking system. (http://bugs.gnome.org). To report a problem about GTK+, send mail to submit@bugs.gnome.org. The subject of the mail should describe your problem. In the body of the mail, you should first include a "pseudo-header" that gives the package and version number. This should be separated by a blank line from the actual headers. Package: gtk+ Version: 1.3.0 [ Please substitute 1.3.0 with the version of GTK+ that you have installed ] Then describe the bug. Include: * Information about your system. For instance: - What operating system and version - What version of X - For Linux, what version of the C library And anything else you think is relevant. * How to reproduce the bug. If you can reproduce it with the testgtk program that is built in the gtk/ subdirectory, that will be most convenient. Otherwise, please include a short test program that exhibits the behavior. As a last resort, you can also provide a pointer to a larger piece of software that can be downloaded. (Bugs that can be reproduced within the GIMP are almost as good as bugs that can be reproduced in testgtk. If you are reporting a bug found with the GIMP, please include the version number of the GIMP you are using) * If the bug was a crash, the exact text that was printed out when the crash occured. * Further information such as stack traces may be useful, but is not necessary. If you do send a stack trace, and the error is an X error, it will be more useful if the stacktrace is produced running the test program with the --sync command line option. An example of a bug report: ==== To: submit@bugs.gnome.org From: yourname@your.address.org Subject: handlebox test in testgtk is misnamed. Package: gtk+ Version: 1.3.0 When I run gtk/testgtk, the button "handle box" is misnamed. There are multiple handle boxes in the demo, so it should be "handle boxes", to be like "buttons" or "check buttons". === Patches ======= Patches can be uploaded to the incoming/ directory on ftp.gtk.org. Please follow the instructions there, and include your name and email address in the README file. If the patch fixes a bug, it is usually a good idea to include all the information described in "How to Report Bugs".