Re: Properties

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 2 Dec 2010 01:57:49 -0800 (PST), Maciej Sobczak wrote:

> On Dec 1, 10:45�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> And how is this any different from, say, printing exactly the same log
>>> messages on standard output?
>>
>> It is just same. You can safely call Put_Line from any task.
> 
> Wrong (AARM Annex A, 3.a):
> 
> "simultaneous calls to Text_IO.Put will work properly, so long as they
> are going to two different files. On the other hand, simultaneous
> output to the same file constitutes erroneous use of shared
> variables."

OK, I let us consider only "reasonable" implementations of Put.

>> But if you do
>> Set_Text in GTK, that will crash your program.
> 
> You mean - that will lead to erroneous execution? So it is exactly the
> same as with printing on standard output.

I don't know if there is an Ada implementation working this way.

> Why do you expect to get better guarantees from GUI than from stdout?

Because in all Ada compilers I used so far this was safe.

>>> How do you solve this problem with Ada.Text_IO? Why the same solution
>>> cannot apply to GUI?
>>
>> I would like to have a similar solution, i.e. GUI things working without
>> switching the contexts.
> 
> "Switching the contexts" is a technical term that relates to some
> platform implementation details. I don't see why this is relevant to
> GUIs, certainly not for performance reasons.

A "reasonable" implementation of Text_IO queues I/O requests to some
internal or external task/driver. I want same sort of design for graphical
requests.

>> On the context of the main GTK task you just call Set_Text. From an alien
>> task you need to instantiate a generic, or pass a closure, or override a
>> primitive operation of a query object and from the callback call to
>> Set_Text. The router calls the callback on the context of the main task.
>> You would not do this for each graphic operations. Instead you have a sort
>> of transactions, sets of operations executed in a group. This makes the
>> code look very different. As I said it is obtrusive.
> 
> Is this a GUI problem or a general language problem?

It is a problem of the GTK library design.

> And is this really a proper design?

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

No, single thread GUI is bad design practice, that is when you block the
GUI when your dialog has a progress bar. A good design practice is that the
application does nothing functional on the context of the message loop. Any
action on this context must be a subject of design rules similar to ones
for the protected actions: non-blocking, atomic, short, semantically
instant.

> Having arbitrary application tasks calling Set_Text
> directly on some widget sounds like spaghetti.

On the contrary, spaghetti is poor man's multitasking implemented by
callbacks from timer messages on the context of the messages loop.

GUI is natively multitasking:

1. actions invoked by its controls are not instant: progress bar
2. some controls are active objects: animation widgets, visual effects,
tooltips, hovering etc
3. indication of asynchronous events and data: oscilloscope

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de