blocking gui process

[Johannes Buchner]

Hi!

I was wondering if it would be possible to architect GUIs so that their
process can be blocked while the user doesn't interact with them.
That would make it possible to swap the process out completely (e.g.
while it is on a different workspace).

In reality, a program will often have some background threads running.
But still, I'd be interested.

 -- somewhat unrelated musings follow --

I also thought a bit on how to architect GUIs with strict separation
of concern in mind: There would be a frontend concerned with the view.
A backend concerned with the control, and a shared data model. How the 
frontend is structured would be one part, how it is styled another. A
third part would be declarative rules (that idea I had from ) on how the
data may be modified, and what consequences that has for other parts of
the data (events may be launched). The frontend maybe also needs a
imperative part for events, wikipedia suggests UML state machines. 
How are desktop applications written nowadays, when compared to the web,
where separation of concern is done nicely sometimes:

 what     |  web   |  guis
 ---------------------------------------------------------------
style     |  css   |  program calls gui toolkit*
structure |  html  |  program calls gui toolkit**
behaviour |  js    |  program shows different parts when it
                   |  gets callbacks; calling gui toolkit
correctness| js    |  program has ifs in signal callbacks
backend   | server |  some tier separate from the gui code (hopefully)

* css for guis is coming, and there is glade
** sometimes there is xml. Sometimes IDEs provide a code generator.
Since it is often not roundtrip-able, eventually you edit the code and
can't use the gui editor anymore.

I would suggest that
(1) gui toolkits have a declarative styling language (like javacss)
        * reloading at runtime would be nice and possible
(2) gui toolkits have a declarative structure description language
    (like glade)
        * reloading at runtime would be nice and possible
(3) the program describes what valid operations on the data model are,
    using in a declarative rules framework / inference engine (like
    drools, see [2])
(4) the backend sees the data model and the events fired by the rules.
    The frontend also just sees the data and the events fired by the
    rules. the frontend is only represents the data (MVC).
(5) While we're at it, the frontend will need something like gettext to
    get i18n strings, stored in e.g. a text file.

That would give us a true next generation GUI toolkit. Note that at
no point I said this couldn't be built on top of an existing GUI
toolkit.

I'd be interested in feedback from Xorg and toolkit devs.

Cheers,
Johannes

[1] http://www.youtube.com/watch?v=4moyKUHApq4 and
http://stlab.adobe.com/
[2]
http://downloads.jboss.com/drools/docs/5.0.1.26597.FINAL/drools-expert/html
_single/index.html#d0e8221

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20100605/ba1294d3/attachment.pgp>