Hi Christian, This is a good overview of the problematic.
I think we can split it in two cases: 1) Enhancing the base client by adding new features at runtime such as a graphical login prompt, message boxes, etc. 2) Enhancing the base client by embedding it into a graphical (Qt, Gtk+) front-end that deeply integrates with it and adds a graphical login prompt, message boxes, etc. I'm working on case 2) right now with one of my employees. We are splitting existing clients into a library + executable, where most of the client is implemented within the library. I have a "libxfreerdp-client" library on my branch which exports very basic functions for launching xfreerdp as a simple function. The goal is to then extend this basic API to provide means of receiving notifications of certain events, overriding certain functionality like the graphical prompt, etc. My employee has been working mostly with wfreerdp while developing in parallel a C# interface that also abstracts the Microsoft ActiveX client, allowing to switch between the Microsoft implementation and FreeRDP smoothly on Windows. I have started doing similar modifications on xfreerdp last week. So far we can launch the client and have it embedded into another window. This approach is better on the long term than re-implementing a client like what Remmina is doing, since we are reusing *a lot* more code from each of the platform specific clients, and leveraging them as much as possible. If you are interested in this approach, let me know and I'll get you in the loop. Our goal is to provide a simple interface that "drives" an existing client rather than implement one, pretty much like what the ActiveX interface to the Microsoft RDP client is doing. This way, we can easily reuse our multiple platform-specific clients (xfreerdp, mfreerdp, wfreerdp). Best regards, - Marc-Andre On Fri, Apr 5, 2013 at 8:22 AM, Christian Steinle < christian.stei...@unicon-software.com> wrote: > 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 > ------------------------------------------------------------------------------ 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
