> >> So how does your implementation work for the DirectFB UI that I'm >> working with currently? >> >> Or for any of the other UI's that are here or may be here in the >> > future? > >> I think it is good if things can stay as common as possible to be >> shared by the various UI's. >> >> Less code and overall maintenance that way. >> > Hi Gerry, > > I was the original author of the DirectFB UI in rdesktop and I have > many changes planned for the FreeRDP DirectFB implementation to use > hardware acceleration. That would be really nice.
> The current one is all software rendered. > DirectFB has poor support for windows and I'm not sure you can > implement RemoteApp in all DirectFB devices. There is a sample > application in DirectFB that shows it's window capability. It's > nothing like XWindow because DirectFB is targeted for set top devices > that are only full screen. > Yes, I discovered that already. Not an immediate issue for me. > The code for the channel part for remote app is so UI specific, I > don't know how valuable common code will be. > > >> BTW, isn't RemoteApp just a desktop that has been cropped? >> > No, RemoteApp as I know it is not just clipping, it's true > local(client) windows. > If you are in an app and you open a Help | About diaog, you can drag > it beyond the bounds of the original app. > So as long as the window is a child window of the original remote app it grabs the screen region and sends it to the client for display by the local window manager. That's nice. My only concern is that if it gets coded only for one UI then the others get left behind. If it could be common, then even if a UI cannot immediately take advantage of it, when it is able to take advantage of it, the functionality is ready and waiting for it. Gerry ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel