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
>
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Reply via email to