Re: gtk problems not disappearing by themselves
I very interested in having them fixed, but not at the expense of
the stability of the 21.4 line. I personally don't have the time,
nor the expertise, to work on them, and that also implies that it
would take far too much time to judge whether they're "safe" or not.
This implies draconian restrictions on the patches I can accept for
21.4.
my original set of messages were related to exact same problems
encountered on 21.5.3 builds.
The GTK stuff is explicitly listed as "experimental".
so therefore don't respond to bug reports????
just to be clear here: i am not complaining about there being bugs in
the gtk code, not complaining about perhaps needing to fix them
myself, not complaining about gtk being experimental.
am complaining about lack of response especially since i had the
intent to pitch in and help out. i'd be happy with just a pointer
like, oh, go look in the blah-blah code section, and i would be off
and running.
You might try building 21.5.3 and seeing if that
works any better.
nope. same problems. see my earlier reports.
If you really want the GTK stuff to improve soon
(2) Searching the xemacs-beta and xemacs-buildreports mailing lists
for people who post about and/or build the GTK port, and contacting
them to see if you can get a circle of active developers and testers
started to support Bill.
um, i thought thats why i posted to this list: thinking there might be
like minded people wanting to sort out the gtk stuff. if noone
responded ON THE LIST, why would they respond to offlist requests???
is the xemacs-beta list essentially now a closed list where only
select coders are collaborating on code? if so, i will unsub so as to
not disturn your efforts further.
======
anywho, anyone interested in putting heads together and ironing out
some of the gtk bugs offlist???
the two problems i see:
1.) when the buffer tab is set to top, left, bottom, i get a:
Gtk-CRITICAL **: file gtkwidget.c: line 3722
(gtk_widget_get_parent_window): assertion `widget->parent != NULL' failed.
and a seperate frame is opended for the tab instead. interestingly,
when "right" location is chosen, this does NOT happen, though the
buffer tab displays incorrectly (basically, it doesnt display
anything, just takes up space).
2.) redisplay after progress bar completion is hosed. see the pic at
http://folks.astrian.net/godzilla/xemacs-redisplay.jpg
and more complete report at:
http://list-archive.xemacs.org/xemacs-beta/200109/msg00125.html
les schaffer
