Hi Jay,
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.
BTW, isn't RemoteApp just a desktop that has been cropped?
Gerry
On 06/14/2011 02:47 AM, Jay Sorg wrote:
>> For 2.2.1 we both agree (they are new secondary orders)
>>
> Yup
>
>
>> For 2.2.2, it contains various things like reporting window movements, the
>> language bar, events like minimize, maximize, resize, etc.
>> I agree that we shouldn't register a virtual channel directly in
>> libfreerdp-core, but if the UI is to register the virtual channel, how is
>> the UI only going to have to bother to add the extra code necessary to do
>> the actions following those events?
>>
> Hum, if it's in the core how are you going to add the extra code?
> I see no benefit to the code being on the core.
> There are several ways to do this.
>
>
>> What I mean by this, is the network part of 2.2.2 should be common to all
>> UIs, and the UI should only bother implementing the part of code which
>> either gathers event data, or acts upon events sent by the server, pretty
>> much like drawing orders are currently handled.
>>
> There is not much to the network part of this extension. I don't
> think much is gained here in common code but we can do this in the UI.
>
>
>> Please describe how you see it, since it would be very helpful.
>>
>
>> Personally, I think it should go in the core, but not using the same API as
>> virtual channel plugins. Maybe we should add support in libfreerdp-chanman
>> for plugins handled in the core, not as plugins. Otherwise, what would be
>> the point of having each UI register the RemoteApp virtual channel? I think
>> we could simply this by having the UI report support for RemoteApp, and then
>> the core simply enables or does not enable it at the protocol level, just
>> like RemoteFX is just an on/off switch.
>>
>
>> Since RemoteFX support is provided with a separate library, maybe you were
>> thinking of having the UI register the virtual channel, but then make use of
>> a new library called libfreerdp-app?
>>
> I don't think your design is best, you don't think mine is. I think I
> should put together some code to show what I am talking about.
>
> One dynamic that is very important to me (and a company that really
> really wants this) is that I need to proxy this with xrdp. If you
> build the channel into libfreerdp, I will for sure have to maintain a
> fork for this. I need the channel in the UI for this to work.
>
> Jay
>
> ------------------------------------------------------------------------------
> 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
>
>
------------------------------------------------------------------------------
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
