Re: Properties

["Randy Brukardt" <randy@rrsoftware.com>]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:18768dde-5817-40b9-aaa1-03c620ad7187@i32g2000pri.googlegroups.com...
...
>You might argue that by analogy two tasks should be able to modify the
>content of two distinct widgets, but that would be stretching
>definitions, as the agreement of what is "distinct" in GUI is quite
>arbitrary (ultimately, everything is a "child" of some uber-container,
>like a display and shares, so nothing is really distinct).

I wouldn't *argue* that, I'd say it ought to be a fact. And it is in Claw...

I'd also suggest that the Standard screwed up with Text_IO. It should have 
some guarantee of sanity for writing to Standard_Output (no erroneous 
execution, but no requirements of ordering, either). In practice, this is 
the case; I'm not aware of any Windows hosted compiler that really does 
anything weird with these Put_Lines.

Robert Dewar has noted in the past that there are two kinds of erroreous 
execution: those where truely bad things will happen, and those that are 
erroneous in name, but in practice will work fine. Put_Line is a clear case 
of the latter. (Almost every Ada program is full of such cases, at least in 
the runtime.)
...
>I have implemented a GUI application recently. Not in Ada, but the
>general concepts are transferrable, as the tasking constraints were
>the same.
>The design involved a separate encapsulating "gui" package that
>exposed subprograms for *logical* (ie. domain-level) manipulations of
>the displayed content. The actual domain-oriented tasks of the
>application were not concerned with "setting a new text value of some
>widget", but rather with updating the domain-level information,
>whatever it was. By doing this, I have achieved not only the physical
>encapsulation of the display part and loose coupling between
>functional modules (heck, I could change that to a web service without
>touching anything else), which solved the tasking constraints, but
>also raised the level of operation for the rest of the program. And I
>don't consider it to be "obtrusive".

It's not "obtrusive", but what it is is serializing. Essentially, all of 
your tasks have to line up to get their data updated. Depending on how much 
data they need to display, that can effectively block them from getting 
anything significant done. (I've had problems like this with logging 
facilities in our web server.)

The result is that gauges don't update when input is being solicited, and 
sometimes the tasks themselves have to be blocked. It's usually better to 
push the serialization to the lowest level (with the shortest execution 
times), and that is deep within the GUI, not at the top level.

Now, I agree that most GUIs simply don't work with tasking; to get Claw to 
work with it requires lots of locks internally, since Windows doesn't like 
multiple threads doing I/O.

> With this experience in mind, if you insist on GUI to be task-safe, I
> think it is because you want the GUI library to support poor design
> practices. Having arbitrary application tasks calling Set_Text
> directly on some widget sounds like spaghetti.
> And that's why I'm not convinced.

Fair enough, although I don't really agree. First off all, all GUI code is 
spaghetti (it's the nature of event-driven programming); it doesn't really 
matter how you do it. (If there was a better alternative to using 
event-driven systems, I'd suggest using it, but it doesn't exist so far as I 
can tell.) Second of all, one design does not fit all. Sometimes you can use 
a central data repository as you previously suggested, but it doesn't work 
very well if there is a lot of data (because of the need to provide mutual 
exclusion on the data, along with the need to give the GUI priority access 
to that data) or if the processing time is short compared to the time to 
display the data.

I prefer that my GUI framework allow *any* reasonable design, rather than 
forcing one into abstractions that may very well just bloat up the code. In 
Claw, the usual approach for simple widgets is to put all of the 
functionality directly into the widget itself (including any tasking 
needed), rather than artifically separating the data creation from the 
display. (Most of the GUI programs I've worked on have had very little data 
processing associated with them; indeed, most of them have had completely 
separate GUI management programs from the actual server simply because 
automatically running programs have to run headless.)

In any case, tasking is a critical functionality for Ada, and one of the 
most important differences between it and most other languages. Deciding to 
prevent the use of that functionality for one sort of programming is like 
cutting off a foot...

                              Randy.


                        Randy.