blocking gui process

[Russell Shaw]

Johannes Buchner wrote:
> 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.

X events are got by select() or poll(), so if there's no mouse
movement over an application window, the process is "blocked".

>  -- 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.

Constructing GUIs with a declarative language is all well and good
for non-programmers and artistic types, but as soon as you want to
create a custom action or widget such as eg a dynamically created
tear-off menu, it's a total pain to dig into all kinds of parser/interpreter
machinery, reverse engineer everything because it's rarely documented,
and then actually do the task that should've taken 2 hours instead
of 2 weeks or months. Forget UML XML CSS JAVA(SCRIPT) PYTHON C++ and
all kinds of OOP crap and just write the fundamentals in non-OOP C.
This is no easy task for someone starting out, but is a doable solution.
You'll end up with a fraction of the code and infinite flexibility.