GTK Win32 update

11:15 pm General

Last night I committed the patch for #164537 that I believe will finally solve the remaining transient and modal window problems that have been affecting GTK on Windows for years. I think this was the last really critical blocker for GTK being usable on Windows, at least that I’m aware of.

4 Responses

  1. Snark Says:

    As far as I know, gtk on win32 has issues with threads (yes, even with explicit locking), so I think you may be forgetting a pretty big blocker there!

  2. bratsche Says:

    Do you have a Bugzilla bug report? I don’t remember seeing one.

  3. Snark Says:

    Uh… I always assumed that was a long-known issue ; I think I heard about it from Tor Lillqvist, long before the port of ekiga to win32!

  4. bratsche Says:

    I got an email from John Ehresman, who pointed out that the Bugzilla bug is http://bugzilla.gnome.org/show_bug.cgi?id=60620

    I never noticed it because it has been closed for so long, and I’m a relative newcomer to GTK on Win32. But regardless, I don’t think it is something that I would try to fix. Quite frankly, the main reason why I have been doing so much Win32 hacking on GTK is because we develop a GTK-based application at work and need it to work on Windows. We don’t do any sort of threading, though, so this bug doesn’t affect us.

    So, I guess my definition of “blocker” was way off. I have never really done any sort of threading stuff on Linux or Windows, so for me the kind of things that block me on Windows are when widgets don’t look or behave correctly, or if windows appear under modally-blocked parents and there is no way to raise them. That’s the kind of stuff I’ve been working on fixing.

Leave a Comment

Your comment

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.