Commit bc1ec5c1 authored by Tor Lillqvist's avatar Tor Lillqvist Committed by Tor Lillqvist
Browse files

Massive changes. Too many to list here, but I'll try a summary:

2002-02-17  Tor Lillqvist  <tml@iki.fi>

	* gdk/win32/*.c: Massive changes. Too many to list here, but I'll
	try a summary:

	1) Unify GdkPixmap and GdkImage implementation: For each
	GdkPixmap, allocate a GdkImage, and vice versa.
	GdkPixmapImplWin32Data has a pointer to the GdkImage.
	GdkImage::windowing_data is a pointer to the GdkPixmap.

	This simplifies many pixmap and image related functions a lot, and
	reduces duplicated code snippets. For instance, there is only one
	place in gdk/win32 where CreateDIBSection() is called, in the
	function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap)
	to a Windows region is almost trivial, with the bitmap bits being
	readily accessible in the associated GdkImage.

	All blitting between GdkPixmaps, GdkWindows and GdkImages goes
	through handled the _gdk_win32_blit() function, which calls
	different functions to handle the cases of blitting from pixmaps,
	inside windows (scrolling), or from windows, which all require
	somewhat different handling.

	2) Support 256-color mode. This has long been very broken, now it
	works more or less OK. Keep the logical palette for each colormap
	as small as possible while allocating and freeing colors. Select
	and realize the logical palette associated with a GdkColormap into
	a DC before drawing or blitting.

	When the display is in 256-color mode, make it possible for the
	user to override the size of the palette(s) used with either the
	GDK_WIN32_MAX_COLORS environment variable, or a -max-colors
	command line option. It is possible to reduce the palette size all
	the way down to using just the 16 static colors (which causes the
	system visual to be of type GDK_VISUAL_STATIC_COLOR. This could
	possibly be useful if one desperately wants to avoid color
	flashing. (Note that in order for this to work properly, an as of
	yet not commited fix to gdkrgb.c is needed.)

	Handle the palette messages. On WM_PALETTECHANGED, call
	UpdateColors() for the given window hierarchy. Do this only if a
	window in some other top-level window hierarchy caused the palette
	change (realized a palette). Do this max five times in a row (an
	arbitrarily chosen limit), though, otherwise redraw by generating
	expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole
	window hierarchy by generating GDK_EXPOSE events.

	3) Code cleanup in general. For instance, remove the "emulated"
	X11 structs ColormapStruct, Visual and XStandardColormap. Use the
	new GDK_DEBUG_* flags for debugging output in the relevant source
	files. Remove the unused colormap hash table in gdkcolor-win32.c

	4) Plug some resource leaks.

2002-02-14  Tor Lillqvist  <tml@iki.fi>

	* gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use
	g_filename_to_uri() to actually create legal URIs in the
	text/uri-list data.
parent ff612419
2002-02-17 Tor Lillqvist <tml@iki.fi>
* gdk/win32/*.c: Massive changes. Too many to list here, but I'll
try a summary:
1) Unify GdkPixmap and GdkImage implementation: For each
GdkPixmap, allocate a GdkImage, and vice versa.
GdkPixmapImplWin32Data has a pointer to the GdkImage.
GdkImage::windowing_data is a pointer to the GdkPixmap.
This simplifies many pixmap and image related functions a lot, and
reduces duplicated code snippets. For instance, there is only one
place in gdk/win32 where CreateDIBSection() is called, in the
function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap)
to a Windows region is almost trivial, with the bitmap bits being
readily accessible in the associated GdkImage.
All blitting between GdkPixmaps, GdkWindows and GdkImages goes
through handled the _gdk_win32_blit() function, which calls
different functions to handle the cases of blitting from pixmaps,
inside windows (scrolling), or from windows, which all require
somewhat different handling.
2) Support 256-color mode. This has long been very broken, now it
works more or less OK. Keep the logical palette for each colormap
as small as possible while allocating and freeing colors. Select
and realize the logical palette associated with a GdkColormap into
a DC before drawing or blitting.
When the display is in 256-color mode, make it possible for the
user to override the size of the palette(s) used with either the
GDK_WIN32_MAX_COLORS environment variable, or a -max-colors
command line option. It is possible to reduce the palette size all
the way down to using just the 16 static colors (which causes the
system visual to be of type GDK_VISUAL_STATIC_COLOR. This could
possibly be useful if one desperately wants to avoid color
flashing. (Note that in order for this to work properly, an as of
yet not commited fix to gdkrgb.c is needed.)
Handle the palette messages. On WM_PALETTECHANGED, call
UpdateColors() for the given window hierarchy. Do this only if a
window in some other top-level window hierarchy caused the palette
change (realized a palette). Do this max five times in a row (an
arbitrarily chosen limit), though, otherwise redraw by generating
expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole
window hierarchy by generating GDK_EXPOSE events.
3) Code cleanup in general. For instance, remove the "emulated"
X11 structs ColormapStruct, Visual and XStandardColormap. Use the
new GDK_DEBUG_* flags for debugging output in the relevant source
files. Remove the unused colormap hash table in gdkcolor-win32.c
4) Plug some resource leaks.
2002-02-14 Tor Lillqvist <tml@iki.fi>
* gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use
g_filename_to_uri() to actually create legal URIs in the
text/uri-list data.
2002-02-16 Manish Singh <yosh@gimp.org>
 
* gtk/gtkfilesel.[ch]: Added multiple selection API
......@@ -1903,11 +1963,7 @@ Sat Jan 12 16:57:31 2002 Kristian Rietveld <kris@gtk.org>
cursor, set the Windows cursor to none first.
 
* gdk/win32/gdkgc-win32.c (predraw_set_foreground): Delete the old
brush that was in the DC, like the win32-production branch does. I
guess this plugs a resource leak? With the HDC cache, the old
brush might be something we created ourselves, and not a stock
brush. And it doesn't do any harm to call DeleteObject on stock
brushes.
brush that was in the DC, like the win32-production branch does.
 
* gdk/win32/gdkwindow-win32.c (gdk_window_impl_win32_finalize): If
the window has a cursor which is the current Windows cursor,
......
2002-02-17 Tor Lillqvist <tml@iki.fi>
* gdk/win32/*.c: Massive changes. Too many to list here, but I'll
try a summary:
1) Unify GdkPixmap and GdkImage implementation: For each
GdkPixmap, allocate a GdkImage, and vice versa.
GdkPixmapImplWin32Data has a pointer to the GdkImage.
GdkImage::windowing_data is a pointer to the GdkPixmap.
This simplifies many pixmap and image related functions a lot, and
reduces duplicated code snippets. For instance, there is only one
place in gdk/win32 where CreateDIBSection() is called, in the
function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap)
to a Windows region is almost trivial, with the bitmap bits being
readily accessible in the associated GdkImage.
All blitting between GdkPixmaps, GdkWindows and GdkImages goes
through handled the _gdk_win32_blit() function, which calls
different functions to handle the cases of blitting from pixmaps,
inside windows (scrolling), or from windows, which all require
somewhat different handling.
2) Support 256-color mode. This has long been very broken, now it
works more or less OK. Keep the logical palette for each colormap
as small as possible while allocating and freeing colors. Select
and realize the logical palette associated with a GdkColormap into
a DC before drawing or blitting.
When the display is in 256-color mode, make it possible for the
user to override the size of the palette(s) used with either the
GDK_WIN32_MAX_COLORS environment variable, or a -max-colors
command line option. It is possible to reduce the palette size all
the way down to using just the 16 static colors (which causes the
system visual to be of type GDK_VISUAL_STATIC_COLOR. This could
possibly be useful if one desperately wants to avoid color
flashing. (Note that in order for this to work properly, an as of
yet not commited fix to gdkrgb.c is needed.)
Handle the palette messages. On WM_PALETTECHANGED, call
UpdateColors() for the given window hierarchy. Do this only if a
window in some other top-level window hierarchy caused the palette
change (realized a palette). Do this max five times in a row (an
arbitrarily chosen limit), though, otherwise redraw by generating
expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole
window hierarchy by generating GDK_EXPOSE events.
3) Code cleanup in general. For instance, remove the "emulated"
X11 structs ColormapStruct, Visual and XStandardColormap. Use the
new GDK_DEBUG_* flags for debugging output in the relevant source
files. Remove the unused colormap hash table in gdkcolor-win32.c
4) Plug some resource leaks.
2002-02-14 Tor Lillqvist <tml@iki.fi>
* gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use
g_filename_to_uri() to actually create legal URIs in the
text/uri-list data.
2002-02-16 Manish Singh <yosh@gimp.org>
 
* gtk/gtkfilesel.[ch]: Added multiple selection API
......@@ -1903,11 +1963,7 @@ Sat Jan 12 16:57:31 2002 Kristian Rietveld <kris@gtk.org>
cursor, set the Windows cursor to none first.
 
* gdk/win32/gdkgc-win32.c (predraw_set_foreground): Delete the old
brush that was in the DC, like the win32-production branch does. I
guess this plugs a resource leak? With the HDC cache, the old
brush might be something we created ourselves, and not a stock
brush. And it doesn't do any harm to call DeleteObject on stock
brushes.
brush that was in the DC, like the win32-production branch does.
 
* gdk/win32/gdkwindow-win32.c (gdk_window_impl_win32_finalize): If
the window has a cursor which is the current Windows cursor,
......
2002-02-17 Tor Lillqvist <tml@iki.fi>
* gdk/win32/*.c: Massive changes. Too many to list here, but I'll
try a summary:
1) Unify GdkPixmap and GdkImage implementation: For each
GdkPixmap, allocate a GdkImage, and vice versa.
GdkPixmapImplWin32Data has a pointer to the GdkImage.
GdkImage::windowing_data is a pointer to the GdkPixmap.
This simplifies many pixmap and image related functions a lot, and
reduces duplicated code snippets. For instance, there is only one
place in gdk/win32 where CreateDIBSection() is called, in the
function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap)
to a Windows region is almost trivial, with the bitmap bits being
readily accessible in the associated GdkImage.
All blitting between GdkPixmaps, GdkWindows and GdkImages goes
through handled the _gdk_win32_blit() function, which calls
different functions to handle the cases of blitting from pixmaps,
inside windows (scrolling), or from windows, which all require
somewhat different handling.
2) Support 256-color mode. This has long been very broken, now it
works more or less OK. Keep the logical palette for each colormap
as small as possible while allocating and freeing colors. Select
and realize the logical palette associated with a GdkColormap into
a DC before drawing or blitting.
When the display is in 256-color mode, make it possible for the
user to override the size of the palette(s) used with either the
GDK_WIN32_MAX_COLORS environment variable, or a -max-colors
command line option. It is possible to reduce the palette size all
the way down to using just the 16 static colors (which causes the
system visual to be of type GDK_VISUAL_STATIC_COLOR. This could
possibly be useful if one desperately wants to avoid color
flashing. (Note that in order for this to work properly, an as of
yet not commited fix to gdkrgb.c is needed.)
Handle the palette messages. On WM_PALETTECHANGED, call
UpdateColors() for the given window hierarchy. Do this only if a
window in some other top-level window hierarchy caused the palette
change (realized a palette). Do this max five times in a row (an
arbitrarily chosen limit), though, otherwise redraw by generating
expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole
window hierarchy by generating GDK_EXPOSE events.
3) Code cleanup in general. For instance, remove the "emulated"
X11 structs ColormapStruct, Visual and XStandardColormap. Use the
new GDK_DEBUG_* flags for debugging output in the relevant source
files. Remove the unused colormap hash table in gdkcolor-win32.c
4) Plug some resource leaks.
2002-02-14 Tor Lillqvist <tml@iki.fi>
* gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use
g_filename_to_uri() to actually create legal URIs in the
text/uri-list data.
2002-02-16 Manish Singh <yosh@gimp.org>
 
* gtk/gtkfilesel.[ch]: Added multiple selection API
......@@ -1903,11 +1963,7 @@ Sat Jan 12 16:57:31 2002 Kristian Rietveld <kris@gtk.org>
cursor, set the Windows cursor to none first.
 
* gdk/win32/gdkgc-win32.c (predraw_set_foreground): Delete the old
brush that was in the DC, like the win32-production branch does. I
guess this plugs a resource leak? With the HDC cache, the old
brush might be something we created ourselves, and not a stock
brush. And it doesn't do any harm to call DeleteObject on stock
brushes.
brush that was in the DC, like the win32-production branch does.
 
* gdk/win32/gdkwindow-win32.c (gdk_window_impl_win32_finalize): If
the window has a cursor which is the current Windows cursor,
......
2002-02-17 Tor Lillqvist <tml@iki.fi>
* gdk/win32/*.c: Massive changes. Too many to list here, but I'll
try a summary:
1) Unify GdkPixmap and GdkImage implementation: For each
GdkPixmap, allocate a GdkImage, and vice versa.
GdkPixmapImplWin32Data has a pointer to the GdkImage.
GdkImage::windowing_data is a pointer to the GdkPixmap.
This simplifies many pixmap and image related functions a lot, and
reduces duplicated code snippets. For instance, there is only one
place in gdk/win32 where CreateDIBSection() is called, in the
function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap)
to a Windows region is almost trivial, with the bitmap bits being
readily accessible in the associated GdkImage.
All blitting between GdkPixmaps, GdkWindows and GdkImages goes
through handled the _gdk_win32_blit() function, which calls
different functions to handle the cases of blitting from pixmaps,
inside windows (scrolling), or from windows, which all require
somewhat different handling.
2) Support 256-color mode. This has long been very broken, now it
works more or less OK. Keep the logical palette for each colormap
as small as possible while allocating and freeing colors. Select
and realize the logical palette associated with a GdkColormap into
a DC before drawing or blitting.
When the display is in 256-color mode, make it possible for the
user to override the size of the palette(s) used with either the
GDK_WIN32_MAX_COLORS environment variable, or a -max-colors
command line option. It is possible to reduce the palette size all
the way down to using just the 16 static colors (which causes the
system visual to be of type GDK_VISUAL_STATIC_COLOR. This could
possibly be useful if one desperately wants to avoid color
flashing. (Note that in order for this to work properly, an as of
yet not commited fix to gdkrgb.c is needed.)
Handle the palette messages. On WM_PALETTECHANGED, call
UpdateColors() for the given window hierarchy. Do this only if a
window in some other top-level window hierarchy caused the palette
change (realized a palette). Do this max five times in a row (an
arbitrarily chosen limit), though, otherwise redraw by generating
expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole
window hierarchy by generating GDK_EXPOSE events.
3) Code cleanup in general. For instance, remove the "emulated"
X11 structs ColormapStruct, Visual and XStandardColormap. Use the
new GDK_DEBUG_* flags for debugging output in the relevant source
files. Remove the unused colormap hash table in gdkcolor-win32.c
4) Plug some resource leaks.
2002-02-14 Tor Lillqvist <tml@iki.fi>
* gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use
g_filename_to_uri() to actually create legal URIs in the
text/uri-list data.
2002-02-16 Manish Singh <yosh@gimp.org>
 
* gtk/gtkfilesel.[ch]: Added multiple selection API
......@@ -1903,11 +1963,7 @@ Sat Jan 12 16:57:31 2002 Kristian Rietveld <kris@gtk.org>
cursor, set the Windows cursor to none first.
 
* gdk/win32/gdkgc-win32.c (predraw_set_foreground): Delete the old
brush that was in the DC, like the win32-production branch does. I
guess this plugs a resource leak? With the HDC cache, the old
brush might be something we created ourselves, and not a stock
brush. And it doesn't do any harm to call DeleteObject on stock
brushes.
brush that was in the DC, like the win32-production branch does.
 
* gdk/win32/gdkwindow-win32.c (gdk_window_impl_win32_finalize): If
the window has a cursor which is the current Windows cursor,
......
2002-02-17 Tor Lillqvist <tml@iki.fi>
* gdk/win32/*.c: Massive changes. Too many to list here, but I'll
try a summary:
1) Unify GdkPixmap and GdkImage implementation: For each
GdkPixmap, allocate a GdkImage, and vice versa.
GdkPixmapImplWin32Data has a pointer to the GdkImage.
GdkImage::windowing_data is a pointer to the GdkPixmap.
This simplifies many pixmap and image related functions a lot, and
reduces duplicated code snippets. For instance, there is only one
place in gdk/win32 where CreateDIBSection() is called, in the
function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap)
to a Windows region is almost trivial, with the bitmap bits being
readily accessible in the associated GdkImage.
All blitting between GdkPixmaps, GdkWindows and GdkImages goes
through handled the _gdk_win32_blit() function, which calls
different functions to handle the cases of blitting from pixmaps,
inside windows (scrolling), or from windows, which all require
somewhat different handling.
2) Support 256-color mode. This has long been very broken, now it
works more or less OK. Keep the logical palette for each colormap
as small as possible while allocating and freeing colors. Select
and realize the logical palette associated with a GdkColormap into
a DC before drawing or blitting.
When the display is in 256-color mode, make it possible for the
user to override the size of the palette(s) used with either the
GDK_WIN32_MAX_COLORS environment variable, or a -max-colors
command line option. It is possible to reduce the palette size all
the way down to using just the 16 static colors (which causes the
system visual to be of type GDK_VISUAL_STATIC_COLOR. This could
possibly be useful if one desperately wants to avoid color
flashing. (Note that in order for this to work properly, an as of
yet not commited fix to gdkrgb.c is needed.)
Handle the palette messages. On WM_PALETTECHANGED, call
UpdateColors() for the given window hierarchy. Do this only if a
window in some other top-level window hierarchy caused the palette
change (realized a palette). Do this max five times in a row (an
arbitrarily chosen limit), though, otherwise redraw by generating
expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole
window hierarchy by generating GDK_EXPOSE events.
3) Code cleanup in general. For instance, remove the "emulated"
X11 structs ColormapStruct, Visual and XStandardColormap. Use the
new GDK_DEBUG_* flags for debugging output in the relevant source
files. Remove the unused colormap hash table in gdkcolor-win32.c
4) Plug some resource leaks.
2002-02-14 Tor Lillqvist <tml@iki.fi>
* gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use
g_filename_to_uri() to actually create legal URIs in the
text/uri-list data.
2002-02-16 Manish Singh <yosh@gimp.org>
 
* gtk/gtkfilesel.[ch]: Added multiple selection API
......@@ -1903,11 +1963,7 @@ Sat Jan 12 16:57:31 2002 Kristian Rietveld <kris@gtk.org>
cursor, set the Windows cursor to none first.
 
* gdk/win32/gdkgc-win32.c (predraw_set_foreground): Delete the old
brush that was in the DC, like the win32-production branch does. I
guess this plugs a resource leak? With the HDC cache, the old
brush might be something we created ourselves, and not a stock
brush. And it doesn't do any harm to call DeleteObject on stock
brushes.
brush that was in the DC, like the win32-production branch does.
 
* gdk/win32/gdkwindow-win32.c (gdk_window_impl_win32_finalize): If
the window has a cursor which is the current Windows cursor,
......
2002-02-17 Tor Lillqvist <tml@iki.fi>
* gdk/win32/*.c: Massive changes. Too many to list here, but I'll
try a summary:
1) Unify GdkPixmap and GdkImage implementation: For each
GdkPixmap, allocate a GdkImage, and vice versa.
GdkPixmapImplWin32Data has a pointer to the GdkImage.
GdkImage::windowing_data is a pointer to the GdkPixmap.
This simplifies many pixmap and image related functions a lot, and
reduces duplicated code snippets. For instance, there is only one
place in gdk/win32 where CreateDIBSection() is called, in the
function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap)
to a Windows region is almost trivial, with the bitmap bits being
readily accessible in the associated GdkImage.
All blitting between GdkPixmaps, GdkWindows and GdkImages goes
through handled the _gdk_win32_blit() function, which calls
different functions to handle the cases of blitting from pixmaps,
inside windows (scrolling), or from windows, which all require
somewhat different handling.
2) Support 256-color mode. This has long been very broken, now it
works more or less OK. Keep the logical palette for each colormap
as small as possible while allocating and freeing colors. Select
and realize the logical palette associated with a GdkColormap into
a DC before drawing or blitting.
When the display is in 256-color mode, make it possible for the
user to override the size of the palette(s) used with either the
GDK_WIN32_MAX_COLORS environment variable, or a -max-colors
command line option. It is possible to reduce the palette size all
the way down to using just the 16 static colors (which causes the
system visual to be of type GDK_VISUAL_STATIC_COLOR. This could
possibly be useful if one desperately wants to avoid color
flashing. (Note that in order for this to work properly, an as of
yet not commited fix to gdkrgb.c is needed.)
Handle the palette messages. On WM_PALETTECHANGED, call
UpdateColors() for the given window hierarchy. Do this only if a
window in some other top-level window hierarchy caused the palette
change (realized a palette). Do this max five times in a row (an
arbitrarily chosen limit), though, otherwise redraw by generating
expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole
window hierarchy by generating GDK_EXPOSE events.
3) Code cleanup in general. For instance, remove the "emulated"
X11 structs ColormapStruct, Visual and XStandardColormap. Use the
new GDK_DEBUG_* flags for debugging output in the relevant source
files. Remove the unused colormap hash table in gdkcolor-win32.c
4) Plug some resource leaks.
2002-02-14 Tor Lillqvist <tml@iki.fi>
* gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use
g_filename_to_uri() to actually create legal URIs in the
text/uri-list data.
2002-02-16 Manish Singh <yosh@gimp.org>
 
* gtk/gtkfilesel.[ch]: Added multiple selection API
......@@ -1903,11 +1963,7 @@ Sat Jan 12 16:57:31 2002 Kristian Rietveld <kris@gtk.org>
cursor, set the Windows cursor to none first.
 
* gdk/win32/gdkgc-win32.c (predraw_set_foreground): Delete the old
brush that was in the DC, like the win32-production branch does. I
guess this plugs a resource leak? With the HDC cache, the old
brush might be something we created ourselves, and not a stock
brush. And it doesn't do any harm to call DeleteObject on stock
brushes.
brush that was in the DC, like the win32-production branch does.
 
* gdk/win32/gdkwindow-win32.c (gdk_window_impl_win32_finalize): If
the window has a cursor which is the current Windows cursor,
......
2002-02-17 Tor Lillqvist <tml@iki.fi>
* gdk/win32/*.c: Massive changes. Too many to list here, but I'll
try a summary:
1) Unify GdkPixmap and GdkImage implementation: For each
GdkPixmap, allocate a GdkImage, and vice versa.
GdkPixmapImplWin32Data has a pointer to the GdkImage.
GdkImage::windowing_data is a pointer to the GdkPixmap.
This simplifies many pixmap and image related functions a lot, and
reduces duplicated code snippets. For instance, there is only one
place in gdk/win32 where CreateDIBSection() is called, in the
function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap)
to a Windows region is almost trivial, with the bitmap bits being
readily accessible in the associated GdkImage.
All blitting between GdkPixmaps, GdkWindows and GdkImages goes
through handled the _gdk_win32_blit() function, which calls
different functions to handle the cases of blitting from pixmaps,
inside windows (scrolling), or from windows, which all require
somewhat different handling.
2) Support 256-color mode. This has long been very broken, now it
works more or less OK. Keep the logical palette for each colormap
as small as possible while allocating and freeing colors. Select
and realize the logical palette associated with a GdkColormap into
a DC before drawing or blitting.
When the display is in 256-color mode, make it possible for the
user to override the size of the palette(s) used with either the
GDK_WIN32_MAX_COLORS environment variable, or a -max-colors
command line option. It is possible to reduce the palette size all
the way down to using just the 16 static colors (which causes the
system visual to be of type GDK_VISUAL_STATIC_COLOR. This could
possibly be useful if one desperately wants to avoid color
flashing. (Note that in order for this to work properly, an as of
yet not commited fix to gdkrgb.c is needed.)
Handle the palette messages. On WM_PALETTECHANGED, call
UpdateColors() for the given window hierarchy. Do this only if a
window in some other top-level window hierarchy caused the palette
change (realized a palette). Do this max five times in a row (an
arbitrarily chosen limit), though, otherwise redraw by generating
expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole
window hierarchy by generating GDK_EXPOSE events.
3) Code cleanup in general. For instance, remove the "emulated"
X11 structs ColormapStruct, Visual and XStandardColormap. Use the
new GDK_DEBUG_* flags for debugging output in the relevant source
files. Remove the unused colormap hash table in gdkcolor-win32.c
4) Plug some resource leaks.
2002-02-14 Tor Lillqvist <tml@iki.fi>
* gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use
g_filename_to_uri() to actually create legal URIs in the
text/uri-list data.
2002-02-16 Manish Singh <yosh@gimp.org>
 
* gtk/gtkfilesel.[ch]: Added multiple selection API
......@@ -1903,11 +1963,7 @@ Sat Jan 12 16:57:31 2002 Kristian Rietveld <kris@gtk.org>
cursor, set the Windows cursor to none first.
 
* gdk/win32/gdkgc-win32.c (predraw_set_foreground): Delete the old
brush that was in the DC, like the win32-production branch does. I
guess this plugs a resource leak? With the HDC cache, the old
brush might be something we created ourselves, and not a stock
brush. And it doesn't do any harm to call DeleteObject on stock
brushes.
brush that was in the DC, like the win32-production branch does.
 
* gdk/win32/gdkwindow-win32.c (gdk_window_impl_win32_finalize): If
the window has a cursor which is the current Windows cursor,
......
......@@ -29,7 +29,6 @@ EXPORTS
gdk_colormap_get_system_size
gdk_colormap_get_type
gdk_colormap_get_visual
gdk_colormap_lookup
gdk_colormap_new
gdk_colormap_query_color
gdk_colormap_ref
......@@ -351,7 +350,6 @@ EXPORTS
gdk_visual_get_best_with_type
gdk_visual_get_system
gdk_visual_get_type
gdk_visual_lookup
gdk_visual_type_get_type
gdk_wcstombs
gdk_win32_drawable_get_handle
......
/* Handcrafted for Win32 */
/* gdkconfig.h
*
* This is a pre-generated file.
*/
#ifndef GDKCONFIG_H
#define GDKCONFIG_H
#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */
#define GDK_WINDOWING_WIN32
#define GDK_HAVE_WCHAR_H 1
#ifdef _MSC_VER
#define GDK_HAVE_WCTYPE_H 1
#endif
#define GDK_USE_UTF8_MBS 1
#ifdef __cplusplus
}
#endif /* __cplusplus */
#endif /* GDKCONFIG_H */
This diff is collapsed.
/* GDK - The GIMP Drawing Kit
* Copyright (C) 1995-1997 Peter Mattis, Spencer Kimball and Josh MacDonald
* Copyright (C) 1998-2002 Tor Lillqvist
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
......@@ -28,7 +29,7 @@ _gdk_win32_data_to_wcursor (GdkCursorType cursor_type)
gint i, j, x, y, ofs;
HCURSOR rv = NULL;
gint w, h;
guchar *ANDplane, *XORplane;
guchar *and_plane, *xor_plane;
for (i = 0; i < G_N_ELEMENTS (cursors); i++)
if (cursors[i].type == cursor_type)
......@@ -40,10 +41,10 @@ _gdk_win32_data_to_wcursor (GdkCursorType cursor_type)
w = GetSystemMetrics (SM_CXCURSOR);
h = GetSystemMetrics (SM_CYCURSOR);
ANDplane = g_malloc ((w/8) * h);
memset (ANDplane, 0xff, (w/8) * h);
XORplane = g_malloc ((w/8) * h);
memset (XORplane, 0, (w/8) * h);
and_plane = g_malloc ((w/8) * h);
memset (and_plane, 0xff, (w/8) * h);
xor_plane = g_malloc ((w/8) * h);
memset (xor_plane, 0, (w/8) * h);
#define SET_BIT(v,b) (v |= (1 << b))
#define RESET_BIT(v,b) (v &= ~(1 << b))
......@@ -61,9 +62,9 @@ _gdk_win32_data_to_wcursor (GdkCursorType cursor_type)
if (data)
{
RESET_BIT (ANDplane[pofs], bit);
RESET_BIT (and_plane[pofs], bit);
if (data == 1)
SET_BIT (XORplane[pofs], bit);
SET_BIT (xor_plane[pofs], bit);
}
}
}
......@@ -72,11 +73,11 @@ _gdk_win32_data_to_wcursor (GdkCursorType cursor_type)
#undef RESET_BIT
rv = CreateCursor (gdk_app_hmodule, cursors[i].hotx, cursors[i].hoty,
w, h, ANDplane, XORplane);
w, h, and_plane, xor_plane);
if (rv == NULL)
WIN32_API_FAILED ("CreateCursor");
g_free (ANDplane);
g_free (XORplane);
g_free (and_plane);
g_free (xor_plane);
return rv;
}
......@@ -153,16 +154,52 @@ gdk_cursor_new_from_pixmap (GdkPixmap *source,
residue = (1 << ((8-(width%8))%8)) - 1;
source_image = gdk_image_get (source, 0, 0, width, height);
mask_image = gdk_image_get (mask, 0, 0, width, height);
source_image = source_impl->image;
mask_image = mask_impl->image;
if (source_image->depth != 1 || mask_image->depth != 1)
g_return_val_if_fail (source_image->depth == 1 && mask_image->depth == 1,