Hi,
I have faced exactly the same situation as Daryl Poe posted with the
above subject on 2012-06-12, because I am working for a company, that
builds a Linux OS, and I had to integrate FreeRDP. Even if I have
implemented such a functionality, the circumstance of being just
rudimentary avoids its universal usage. However I think, I can mention
some general aspects, which I have learned from this implementation.
Maybe some of them might be a proposal.
At a first step, it seems to be adequate to implement two new optional
FreeRDP commandline parameters (--from-gui and --to-gui). The option
--from-gui is only used to trigger the user authentification analog to
the option --from-stdin, whereas the option --to-gui enables the rest of
GUI utilization. This approach is required to not break the utilization
of the option --from-stdin, which is for example needed by the VMware
client, and maybe also by REMMINA. So there should be then the
configuration possibility to realize the authentication via VMware
client, while error messages or other user requests like certificate
accepting are shown via GUI.
At a second step, a message specific library (libfreerdp-msg) seems to
be needed in the FreeRDP project, which has to feature globally
available functions encapsulating all user messages. This library might
have also a special header file defining all messages. These messages
might include the utilization of meta-characters for formatting. Further
on GETTEXT might be used additionally to enable the internationalization
of all messages (multi-language functionality). By the way, this
statically linked library has to implement an initialization function,
which can be then used later by the consecutive library libfreerdp-ui to
implement needed functionality. So the key features of this extra
library can be summarized by:
* Encapsulation of meta-formatted user messages used in the entire
FreeRDP source code
* Internationalization of the messages
At a third step, an UI specific library (libfreerdp-ui) seems to be
needed in the FreeRDP project, which has to feature the real user
interface. This library has to use obviously for default the console
output and input to interact with the user. In this situation, it is
clear that the meta-characters, which are used to format the message,
have to be interpreted somehow. Besides this, the initialization
function of this also statically linked library, which is obviously
connected to the initialization function of the library libfreerdp-msg,
can be used to attempt to dynamically open another library featuring the
GUI and load the corresponding function symbols. So in this context, it
is immediately clear that the GUI library is strongly connected to the
FreeRDP project, because the GUI library is absolutely required to
export the correct function symbols with regard to the FreeRDP
requirements. However this strong connection defines just an API and not
a dependency, because the GUI library can be built completely
independent of the FreeRDP project. This means, that everybody can
implement a GUI by the utilization of this API in whatever graphical
toolkit is preferred. And if the name of this dynamic library could be
set via cmake parameter, even the name of the GUI library would be
simply customizable (This functionality would be gratefully used by me,
because I can then use an OS wide GUI library). Of course, it is also
clear that the GUI library has to interpret the meta-characters, which
are used to format the message, but almost ever a GUI will do it
different in comparison to the console due to the available
possibilities. So the key features of this extra library can be
summarized by:
* Feature a standard user interface via console output and input
* Feature the dynamic utilization of a GUI library via dlopen and dlsym
Coming now to the GUI library itself, I decided to use the zenity
project. This project seems to be perfectly adaptable at a first glance
by simply splitting the main executable from the dialogs, which have to
be put then in a library. However this approach gets more and more
complicated, because the fact that each dialog prints to the console
requires the restructuring of the entire dialog interfaces.
Consequentially I could not avoid the violation of the zenity
implementation paradigms. Nevertheless I get finally the dialogs I need
to work, but also just rudimentary.
As a requirement of me is defined by keeping the modifications to this
newly generated zenity library as small as possible, the need for a
fourth library arises, which simply connects the zenity library
interface to the libfreerdp-ui interface. For my perspective, I had
additionally implemented the interface of this library to be usable in C
as well as C++, so that I can use this library OS wide. The only
consequence of this situation is then defined by requiring the library
libfreerdp-ui to use only standard data types.
Maybe this information is useful to get some progress into this topic.
Best regards,
Christian
--
*Dr. Christian Steinle***
System Architect Linux OS
Unicon Software GmbH
Philipp-Reis-Str. 1
76137 Karlsruhe
Germany
Tel. +49 (0)721 96451-0
Fax +49 (0)721 96451-43
Email: christian.stei...@unicon-software.com
<mailto:christian.stei...@unicon-software.com>
Web: www.unicon-software.com <http://www.unicon-software.com>
This communication contains information that is confidential,
proprietary in nature and/or privileged. It is for the exclusive use of
the intended recipient(s). If you are not the intended recipient(s) or
the person responsible for delivering it to the intended recipient(s),
please note that any form of dissemination, distribution or copying of
this communication is strictly prohibited and may be unlawful. If you
have received this communication in error, please immediately notify the
sender and delete the original communication. Thank you for your
cooperation.
------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
_______________________________________________
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel
