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!news4.google.com!proxad.net!feeder1-2.proxad.net!news.in2p3.fr!in2p3.fr!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Properties Date: Thu, 2 Dec 2010 22:24:18 -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> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1291350261 15257 69.95.181.76 (3 Dec 2010 04:24:21 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 3 Dec 2010 04:24:21 +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:16735 Date: 2010-12-02T22:24:18-06:00 List-Id: "Maciej Sobczak" 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.