Re: Properties

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

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:0c899bff-c580-4b9f-9c94-b9226c089cde@j29g2000yqm.googlegroups.com...
On Dec 3, 5:43 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

>> When it comes to GUI programming, this supposedly "good design principle"
>> often doesn't make any sense.
>>
>> For example, consider the series of SLED (Simple Little EDitor) examples 
>> in
>> Claw. These show how a Notepad-like editor could be constructed using 
>> Claw.
>
>Yes. There are two points, however:
>
>1. Text editors (in particular text widgets) are both sources and
>destinations of data. That is, they not only display something, they
>also control the content by allowing the user to interact with it and
>modify it. Thanks to this coupling of functionality (content control
>and rendering) it makes sense to delegate the data structure
>management to the same component as well. In this regard text widgets
>are self-contained.

Right. My point is that is the quite natural to have widgets like that. Text 
processing surely is not the only example.

>Unfortunately this reasoning has no applicability in a real-time
>oscilloscope display, where such coupling does not occur - data source
>is definitely separate from the rendering component so there is no
>justification for coupling data model with widgets. On the contrary,
>it makes perfect sense to decouple them - for starters, did I mention
>several displays showing the same signal, but with different filtering
>settings?

Possibly, but irrelevant. My point was that the "good design principle" is 
nowhere near absolute when it comes to GUIs. It makes just as much sense for 
some applications to have a control (widget) that does everything. I never 
claimed that you should *never* separate these things, only that claiming 
that a design that does not do so is somehow wrong is simplistic.

>2. Your text-editing example has little relation to multitasking as a
>general GUI feature. Of course one can imagine, for example, a
>background spellchecker task or something in this area, but this is so
>particular to the text editing domain that is hardly a justification
>for requiring that the whole GUI framework must be task-safe.

I don't believe that a general-purpose library should be telling people how 
to design their software. (This is very similar to the issue of almost never 
using access types in the interface -- the library should not be telling 
people how to do memory management.)

Indeed, I think that *any* library intended for general Ada usage ought to 
be task-safe to the extent that Ada.Text_IO and Ada.Containers are (access 
to different objects of the library by different tasks always work). That 
surely includes GUI libraries. That's all that Claw guarantees (that two 
tasks can access different controls/windows without interference). Libraries 
that don't meet those basic Ada requirements are very constraining, lead to 
the sort of problems that Dmitry mentioned (accidental use from the wrong 
task causes crashes and no clear indication of the mistake). Sometimes you 
have to use such things, but they then require wrapping in the Ada 
environment (unless you like debugging!).

                                    Randy.