embedding traditional gui kit as RDP resource

[Robert Majewski]

Hi,
I wander what could be the "correct" way of embedding retained gui library (wxWidgets, gtk etc.) as resource inside RDP application?
Is that possible at all? These gui libraries are designed for imperative code. I don't know how to make them idempotent and commutative.

How to create popup dialog? By connecting signal describing the dialog structure (s1) (widgets hierarchy) to some kind of "UI manager"?
How to connect signal to particular button inside it (s2), that we are interested in?
I'm worried that s1 and s2 will interfere with each other (in s1 button could be setup to "enabled" state, but s2 will demand "disabled" state)

Br,
Robert

[David Barbour]

Rather than embedding libraries that are awkward for RDP, I would prefer to develop an API suitable for RDP then shift the awkwardness to an adaptation layer (which may involve the compiler). 

UI is an interesting subject because there isn't much agreement on how to do it "correctly" even for imperative code. There's thick client vs. thin client, retained mode vs. immediate mode, issues regarding distribution, maintenance, mashups, macros, extensions, multiple views, disruption tolerance, mobility between devices,  bookmarks, undo, history, CSCW, security, transclusion, language translations, zoomability, level-of-detail... and so on. 

I have some ideas about what I want for a new UI model. What I envision involves zoomable scene-graphs, web services, and mashups. I'll probably target asm.js and perhaps WebGL for early RDP UIs, but I'd also like to implement a new client/browser. By nature, UI is a pretty good fit for RDP. 

Setting aside UI, I think you're concerned about integrating RDP with imperative systems in general. For this, a few approaches I've been contemplating include:

* use intermediate publish-subscribe protocol for time-series data (e.g. DDS, ROS, MQTT). Most of these are easy to adapt to RDP, UI, and imperative control systems. As a significant advantage, these adapters can be relatively generic and enable a high level of extensibility.

* use a multi-agent state model, such as a tuple space or lattice. Requests and responses can be added to this structure over time, and it can model queues and collaborative efforts. Some of the 'agents' may then be imperative in nature. E.g. we could handle print requests this way. This approach has the advantages of being highly asynchronous, disruption tolerant, and extensible; however, it can be difficult to GC.

* associate transitions in state with imperative actions, such that influence over state results in a series of events. This is close in nature to Discrete Event Simulations (DES, DEVS), but can be extended to work with term rewrite systems. Many imperative resources can be modeled this way. This design has the weakness of being very difficult to extend, but it might work well for some specialized use-cases that only need a few simple rules.

A retained-mode UI would perhaps best be integrated using the second or third options. The first option is probably better for an immediate-mode UI.

Best Regards,

Dave

--
You received this message because you are subscribed to the Google Groups "reactive-demand" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reactive-dema...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.