Re: ./teststatusicon (was Re: A cross-platform status icon api)

[Hans Breuer <hans breuer org>]

On 19.09.2005 00:38, Tor Lillqvist wrote:
> Hans Breuer writes:
>  > BTW: I'd appreciate if somebody with a deeper understanding of gtk internals
>  > could do a review of gtktrayicon-win32.c. Maybe what I've done is considered
>  > too much of a hack ;-)
>
> I appreciate your work, but why the rush?
>
> Isn't it better to wait some time and let the X11 implementation
> mature first? 
Having HEAD broken - i.e not even compile - for a long time does
not look right to me, no. Also silently agreeing on an API - without
trying it - up until short before a release doesn't either. If it
turns out that there are cross-platform issues I think the earlier they
are detected the better.

> It isn't exactly like GTK 2.10 would be close to
> release. GTK+ 2.8 is the stable version, and 2.6 is even more stable
> on Win32. (At least, unless you use a fresh CVS snapshot of
> pango-1-10). Are you using HEAD as your "production" environment?
At least I try. Usually starting to build from cvs from from GLib over
Pango up to Gtk+. [So I'm using Pango cvs as of yesterday.] If I find
problems I usually report them, try to solve them or run out of
spare time. So yes, I try to use cvs HEAD as "production" environment.
At least for programs I don't use in production ;-)

> Didn't we have some problems in the last cycle when gtkfilesystemwin32
> was copy-pasted from gtkfilesystemunix before the latter was "ready",
Copy and pasting always is a problem. But merging one function twice
when the original became more mature IMO isn't.

> and then subsequent improvements to gtkfilesystemunix didn't get
> mirrored in gtkfilesystemwin32? I don't recall the details, sorry.
Looking at http://cvs.gnome.org/viewcvs/gtk%2B/gtk/gtkfilesystemwin32.c
it seems as if most 'subsequent improvements' were win32 specific.

> 	* gdk/win32/gdkwindow-win32.c(gdk_window_set_urgency_hint) : only use
> 	only use (WINVER >= 0x0500) when available from the SDK. Otherwise fall
> 	back to true dynamic linking of FlashWindowEx. Makes gtk+ work on NT4.0
> 	again - if compiled properly.
>
> Hmm, why should we use different *code* depending on the *compilation*
> environment? (I understand ifdefs for preprocessor defines or type
> definitions that aren't present in older headers.) Wouldn't it be
> better here to use the dynamic lookup of FlashWindowEx() all the time
> then, so that the code would work on NT4 even if built against fresher
> headers? (Is FlashWindowEx() really the only Win32 API we use that
> isn't present in NT4?)
The only benefit I see is letting the compiler check the compatibility
with the newer API. Especially FlashWindowEx appears to have had some
brokeness in it's history. But feel free to remove the non dynamic part.
BTW: simply defining some high WINVER at the start of a .c or worse a .h
file never does look right to me. But Microsoft will love it.

	Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert