Re: GNU talk, now with GTK interface!

[Owen Taylor <otaylor gtk org>]

"Eric M. Ludlam" <zappo@ultranet.com> writes:

> I'd like to announce the first version of GNU talk that includes a
> GTK+ interface for the talk client.  (I used 1.0.0).  Despite the fact
> that it is possible to use this interface to do things, I doubt you'd
> want to at this stage.  (The curses and other interfaces still work
> fine though...) I've got a couple problems with GTK I'm hoping you
> guys can help with.
> 
>   I'll start by saying that the GNU talk web page where you can
>   download the program is at this location:
>   http://www.ultranet.com/~zappo/gtalk.shtml
> 
> The first obvious problem is with my event loop.  Since I come from a
> Motif/Xaw/Xlib specific background, I used X calls when I wasn't sure
> what to do w/ GTK, and copied code from the GTK source at other times.
> 
> In order to support emacs and curses interfaces in the same program, I
> have my own select loop, in which I add the X socket.  In the handler,
> I strip all keypress events.  (An idea that is used by emacs) This
> gives the application the same feel as the emacs or curses interfaces
> of every other stock talk app, and I think that's important.  The side
> effect is that GTK has a mysterious updating cache of some sort so
> things don't update well, and I get lost mouse events.

I don't have a very good feel for the problem you are seeing, but in
general I would say that it is going to be quite difficult to get
a GTK+ program running without using the GTK+ main loop. I suspect
it isn't necessary:

- If you need to select() on filehandles other than the X socket,
  use gdk_input_add().

- If you need to intercept X events below the level of GTK+, use
  gdk_window_add_filter(). If you simply need to prevent key
  presses from reaching a widget, it is probably better to
  connect to "key_press_event", and use gtk_signal_emit_stop() in
  your callback to prevent further processing.

  Note that intercepting the key press events will prevent standard
  X dead-key handling from working, among other things, so it
  may not make you popular with people outside the U.S.

> My second problem is with geometry management.  I'm using nested boxes
> to manage data in a fashion I'm used to with Motif and Athena, and I'm
> having bad luck.  I've tried all sorts of flag combinations and am
> confused.  Here is my setup with brief descriptions of what is broken.
> 
> Main-window:
> 
>   +-----------------
>   | File ...                <- menubar
>   +-----------------
>   |
>   |                         <- area for talk windows
>   |
>   |
>   +-----------------
>   | M-x foo                 <- minibuffer/status text
>   +-----------------
> 
> The talk area is a vbox, organized like this w/ sub boxes.
> 
>   +-----------------  vbox1
>   | text                    <- local user space
>   |
>   |-- status line --
>   +-----------------  box2
>   | text                    <- first remote users' space
>   |
>   |-- status line --
>   +-----------------
> 
> So now I have a bunch of nested boxes.  My problem is that resizing
> the talk_vbox w/ the text windows will overlap the minibuffer and menu
> bar w/out resizing the top level window. 

How are you resizing the talk_vbox? It sounds a bit like you are
calling gtk_widget_size_allocate() directly, or something - which
will cause many strange effects. The effect should not happen
if you call gtk_widget_set_usize().
 
> The next problem is that the status line tries to take on the same
> dimensions as the text widget.  If I set various fill flags, the
> text widget overlaps the status line.

This sounds like you are making creating vbox1/vbox2 with homogeneous
= TRUE (the first parameter to gtk_vbox_new()). Since you don't want
the Text and status line to have the same size, try setting that to
FALSE. I've never seen boxes overlap with any combination of
parameters, so I suspect that the problem with overlapping here is the
same as that above.

Regards,
                                        Owen