From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,36a29c2860aff686 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder3.cambriumusenet.nl!feed.tweaknews.nl!138.195.8.3.MISMATCH!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Properties Date: Fri, 3 Dec 2010 15:32:20 -0600 Organization: Jacob Sparre Andersen Message-ID: References: <3b84c8e7-1a51-4a7c-9646-119f1fc51478@s4g2000yql.googlegroups.com> <4pnv7nl4cdui$.1n28i7lqk4mek$.dlg@40tude.net> <1k7367gtebsgm$.18auo6u3nfg34.dlg@40tude.net> <1u5dftkqqi68c.10079qnqyyfwb$.dlg@40tude.net> <15tv4yga36dpi$.1hc09dlbgcmqe.dlg@40tude.net> <18768dde-5817-40b9-aaa1-03c620ad7187@i32g2000pri.googlegroups.com> <1sp30ekj4pmer$.1753nbz1zyzid$.dlg@40tude.net> <2a3219cb-5793-4e5b-97aa-036da124ccba@y31g2000vbt.googlegroups.com> <0c899bff-c580-4b9f-9c94-b9226c089cde@j29g2000yqm.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1291411942 3917 69.95.181.76 (3 Dec 2010 21:32:22 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 3 Dec 2010 21:32:22 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Xref: g2news2.google.com comp.lang.ada:16759 Date: 2010-12-03T15:32:20-06:00 List-Id: "Maciej Sobczak" wrote in message news:0c899bff-c580-4b9f-9c94-b9226c089cde@j29g2000yqm.googlegroups.com... On Dec 3, 5:43 am, "Randy Brukardt" 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.