Re: [rdesktop-devel] Return values of rdesktop program / Program keeps running when window closed

[Mrs. B. <mrs...@ni...>]

On Thu, 2002-12-26 at 13:18, Arend van Beelen jr. wrote:
> > I don't think libraries should draw "their own thing" to the screen, to
> > a tty, or communicate with the user at all. That's the job of an
> > application. While I'd grant exceptions to this rule, this certainly
> > doesn't seem like one of them.
> 
> > rdesktop shouldn't have/need any BSD socket code in the "back end". All
> > it should have is the glue needed to interface with the X11 server. It
> > should communicate over file descriptors to a parent process which has
> > already set up the network connect (possibly asynchronously, and
> > possibly providing feedback to the user). rdesktop should certainly
> > include one of these such programs, but I think that I should be able to
> > build my own simple front-end as easily as a shell script:
> 
> > #!/bin/sh
> > exec xalf tcpserver $1 3389 rdesktop-x11 ${1+$@}
> Okay, I agree. But then I would like to ask: Would it be possible that the 
> frontend provides the window in which the back-end can draw?

You're using too global of terms. "back end" and "front end" don't mean
anything useful, and are often a source of confusion (as they are here).

The x11 display driver in rdesktop's source should examine an
environment variable (X11WINDOWID or something similar) - this would
certainly be a very X11-specific mechanism, but since some operating
systems don't allow (BeOS), or don't make it easy (Win32) to draw in
another applications' window, you may have to read on:

 
> I still think return values are more easy here, it allows krdc to map error 
> strings to error codes, with one string for unknown error codes. No matter 
> how you do it, krdc needs modification after new error codes are introduced 
> since the i18n translations of the error strings need to be updated.

No it doesn't. Ideally, rdesktop should be internationalized.

 
> Something different, though, the author of krdc advises me to port rdesktop to 
> a Qt based class which can be included in the application. As a few 
> guidelines he told me the following things had to be done to accomplish that:
> - the rdesktop loop must run in its own thread
> - rdesktop must not poll, but instead get events from the Qt loop (for VNC I 
> do this using a few queues for the various event types, that are protected by 
> a mutex)
> - rdesktop must call KApplication::lock() before drawing (it can still draw 
> itself, but krdc provides the Window)
> This, of course, would provide the best possible integration for krdc and krdc 
> would become independent of rdesktop, a good point. But from the other side, 
> it would mean that any goodies rdesktop might bring in the future need to be 
> reimplemented by hand in the krdc tree.

I think it would be fine to make a Qt display driver. Threading is not
your issue here. However the networking code would require abstraction.
This would be easier with the changes to rdesktop that I suggested.
However, in that case, you would need to spawn a separate copy of
rdesktop-qt for each window you're going to draw onto.

I'm not familiar enough with Qt to provide sane advice here, but one of
two things is happening. Either Qt will poll() the file descriptors for
the network, or rdesktop poll()'s Qt's file descriptors. If Qt does it,
then ui_select() (as provided) will be enough. Simply pass the
rdp_socket to the Qt subsystem and you're done. If rdesktop does it,
then use the model used by xwin.c and you're fine.

If the backend is _not_ a library, then a complex IPC will be needed to
pass the QtWindow (whatever) objects around. This IMO, is a shortcoming
of Qt, and may necessitate a tighter integration (and thus, more
potential for bugs, blah)