Re: Win32 - invalid cast GdkPixmap to GdkWindow in gdk_event_translate

Thanks, plain text from now on.

Upgrading to a newer version of Gtk would be the preferable option
from a development standpoint, but unfortunatly doesn't hold true from
a business perspective.

I have tried the following pre-compiled Gtk binares and noted the
following issues:
2.16 - Can't multi-select in tree view without tree-items
expanding/collapsing by themselves
2.18 - Doesn't paint properly with wimp theme
2.20 - Tree view isnt reorderable

I had some other issues with 2.22 and 2.24 but neglected to take notes.
Ultimatly, we will need to upgrade the Gtk version we use but for now
there is still weight on trying to fix 2.4.

I should have also added that the issue we see manifests in a widget
not repainting by itself nor responding to UI, yet still responding to
gtk calls to repaint, press, etc.

As a side note, I could run newer windows builds through the
application I work with as a part of QA if that would be helpful.

On Mon, May 16, 2011 at 1:10 PM, Maarten Bosmans <mkbosmans gmail com> wrote:
> Just a note: plain text emails are preferred on this list.
> See answers inline below.
> 2011/5/16 Ryan Krumins <ryan krumins gmail com>:
> > Hi Guys,
> >
> > I have a fairly substantial Gtk application im working with that is
> > experiencing some seemlingly randomly timed, but consistent in
> > symptoms, crashes on Windows.
> >
> > We are considering the obvious option of moving to a newer version of Gtk on
> > windows in the hope that will fix the issue, but to be prefectly honest, we
> > have found it difficult to get a version for windows that doesnt contain a
> > show stopping bug. Our approach there has been to repair the bugs and submit
> > patches once everything is up to speed, but in the meantime, we still have
> > some resources to continue looking at this issue as the preferred solution.
> What's there to consider? Just try it with a newer version and see if
> the problem is fixed there. That should take too long, right?
> Besides, that version of Gtk is ancient, so even if you find the issue
> and make a patch, it either is already in a newer version or the patch
> most likely will not apply to the current git tree.
> In general it is true that Gtk on non-linux/X11 platforms is lagging a
> bit. So the more people/projects we have that use the latest version
> on Windows and submit patches for things that are not up to par, the
> better.
> > We have had issues with the use of focus-out handlers before but have always
> > been able to find the offending code/programmer through valgrind on linux.
> > This problem, obviously eludes our focus-out handler search.
> >
> > Would anyone be able to provide some insight into where we could focus our
> > efforts ?
> You could try downloading the precompiled windows binaries from the
> latest version before the csw (client side windows) branch was merged.
> I think that would be Gtk 2.16.
> If that all works out, you can try moving up to the most recent (and
> last) Gtk2 series: 2.24.
> > Could the use of GtkFixed and its realize-on-pack operation cause some sort
> > of race condition here ?
> Maarten

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]