Re: Suggestions needed for gtk frontend for cdebconf
Bernhard R. Link schrieb:
> What is the current way to get some program (like a shell) working? Is
> it still the menu-items responsibility (like it was when I last looked
> quite some time ago) or was the debconf-protocol extended to allow the
> frontend to take the needed steps or was it even implemented an other
> way?
If a menu item is selected, the associated udeb's postinst is executed.
This is where all action takes place.
> > To display the log output in a gtk window, I came to the conclusion that I
> > needed threads. If control goes to some udeb postinst which produces an
> > error, the frontend code must be in control to actually display it
> > (gtkmain).
>
> Does it really need multi-threading or would multi-tasking be enough?
I don't see how spawning another process will help. Debconf calls the
frontend when it wants something done by the user (or present something to
him). This is when frontend code gets into control. What I need is, that it
stays in control so that a terminal and an error output works permanently
(not only when frontend code gets into control the next time). Since the
frontend is part of cdebconf I do not know how else than threads should
solve this.
> > However, I could use the gtk terminal widgets here. But also here I would
> > need threads, which, when introduced leaded to #192925. There are opinions
> > that this error is related to xlibs or glibc.
>
> Why does the gtk terminal widget needs threads? Is this some limitation
> in the widget or is it more immanently needed?
The terminal itself does not need threads. But as stated above, it is
necessary to be accessible all the time and that requires threads.
Sebastian
Reply to: