Re: gtk strange behavior



i thought it was best to have all the gui code in one thread, and all the
core or processing in another ?

matt

On Sat, 28 Jan 2006, kornelix wrote:

I got no help so far on the questions below. Perhaps they were too naive
for this group.

Re: multi-thread GTK apps

I found some help in the online GTK FAQ about implementing
multi-threaded apps. It seems messy and fragile. Since multi-threaded is
the normal and expected way to write GUI apps when significant
processing time is required, it seems GTK should be thread-aware,
thread-safe, and functionally correct by default. The suggested
additional code should be in there already. Any opinions about this? Is
the FAQ up-to-date or is this leftover baggage from the past?

Re: failure of a text view window to visually update when modified from
a non-owner thread

I tried adding  gdk_flush()  in the updating thread, as suggested in the
FAQ.
Result: "Xlib: unexpected async reply (sequence 0xe8c)!"  and the thread
was killed.

I stumbled on a funny work-around for this problem. If I make the window
editable via gtk_text_view_set_editable() after creating it, then window
updates from non-owning threads become normal and fast. This only works
if the owner thread makes the call. Doing this from a non-owning thread
is ineffective. Strange. Any comments?

=============================================

kornelix wrote:

I am learning GTK-2+ programming in Linux, and I have developed a
sample application which almost works correctly.

I built a main window containing a scrolling window containing a text
view window.
The main window also has a menu bar.

issue # 1
The menu bar has both single menu-items and items that hold sub-menus.
The sub-menus work normally. The single menu-items need two mouse
clicks to activate: the 1st click highlights the menu, the 2nd click
activates the menu.

issue # 2
I am writing to the scrolling text window from a 2nd thread which was
created by the initial thread that created the window. This basically
works, but the window is not updated visually until some other action
affects the window, such as a mouse rollover, change in focus, etc.
The window will sometimes sit there and do nothing until an unrelated
window in another application is jogged (e.g. by clicking on its title
bar), then the "hung" window will spring into action and update itself
correctly with all the text that had been written much earlier.

A search of the online docs turned up nothing relevant AFAIK.

I just now subscribed to this mailing list.

My GTK version seems to be 2.6.10. My system is Fedora Core 4.



_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list




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