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.
_______________________________________________
[email protected]: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: [email protected]
