For a while, I've heard user complaints aired about the size of the panel being an issue when resource pages or popups are being designed. As the PEP editors don't allow the concept of a popup, I've been contemplating a standardized design pattern that could be used by all to make management of popups easier.

And, as it would be a recognized and standardized design pattern, would hopefully allow someone modifying a configuration to easily recognize the practice that was followed which will hopefully make looking at others configurations a bit easier..

With the advent of dynamic widgets, many of the ideas i've toyed with for a while have now become possible. What I'd like to do is to lay out some of the basic concepts here and ask other developers as well as graphic designers to chime in with some of their ideas as to what the XML Descriptor (may not actually be XML when final design is achieved) should look like.

Before I dive in head-first, let me take a moment to describe the overall philosophy of what I believe to be involved.

1. A WidgetSet class - Already developed (by me) but needs to be made more lightweight.

The WidgetSet is used for managing a set of widgets. Widgets can be moved as a set and made visible as a set. The WidgetSet, in short, can "proxy" as a single widget for Movement and Visibility control.

2. Hidden Popup Page - A page in the configuration where popup information (Set of Widgets and Popup Descriptor Widget) is contained.

3. Sets of Widgets (a popup) are assembled (with Prontoscript names) on a hidden page (#2) and optionally grouped together to be moved as a set, with ease, during editing. Images, Colors, Font Sizes, Text, could be also be assigned statically here. Basically, this set of widgets would be "cloned" for use on a regular UI page.

4. Popup Descriptor Widget - A panel is placed on hidden popup page with well-defined ProntoScript name - ie something like "POPUP_DESCRIPTOR".

The label of this panel would contain markup (XML most likely) that would provide information to call out the named widgets included in popup as designed in #3 as well as information as to what widget should do. For example, a button on a popup could issue "schedule/executeActions" on some other widget or could result in dismissal of the popup. Additional information such as starting location of the popup, font colors, sizes, and text for labels could could also be contained here. The descriptor could also contain inactivity timers to automatically dismiss popup after predetermined time. And yes, Barry, I know you have a MessageBox function so I'd like your input either publicly or privately as I'd want to include that type of logic here.

5. A Popup class - This is a javascript class that creates a popup from the information contained in the Popup Descriptor widget (#4). It would basically build a WidgetSet (#1) with dynamically created widgets that are "clones" of widgets called out in the Popup Descriptor.

So, this is where you guys come in. I'd like to open up the design a bit andl also make this a community effort. I will also make Philips aware of what I am trying to achieve hereas I personally would like some sort of ZOrder control via ProntoScript to ensure that widgets can be brought to front/sent to back as needed.

Comments are welcome here but please limit posts on this thread to those which are relevant to functionality you'd like to see or design of the Popup Descriptor. Let's try and keep this thread pure without extra comments such as "Attaboy" or "Yes, I agree this is needed".